From internet-drafts@ietf.org Tue Jan 1 19:57:51 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 9907021F8F4B; Tue, 1 Jan 2013 19:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 aLK5YwlSfPNX; Tue, 1 Jan 2013 19:57:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF321F8F50; Tue, 1 Jan 2013 19:57: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: <20130102035751.6584.6621.idtracker@ietfa.amsl.com> Date: Tue, 01 Jan 2013 19:57:51 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 03:57:51 -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 : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-07.txt Pages : 39 Date : 2013-01-01 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From turners@ieca.com Wed Jan 2 05:51:28 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 60F1D21F8A57 for ; Wed, 2 Jan 2013 05:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 ZbUKWJlHl8Op for ; Wed, 2 Jan 2013 05:51:21 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.137.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9964E21F8751 for ; Wed, 2 Jan 2013 05:51:17 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 8A9E4ECBA3F98; Wed, 2 Jan 2013 07:50:58 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 6E1F7ECBA3F51 for ; Wed, 2 Jan 2013 07:50:58 -0600 (CST) Received: from [198.180.150.142] (port=55686 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TqOiw-0002af-Ji for pkix@ietf.org; Wed, 02 Jan 2013 07:51:14 -0600 Message-ID: <50E43B52.8080504@ieca.com> Date: Wed, 02 Jan 2013 08:51:14 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20121229054011.27864.40173.idtracker@ietfa.amsl.com> In-Reply-To: <20121229054011.27864.40173.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121229054011.27864.40173.idtracker@ietfa.amsl.com> 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) [198.180.150.142]:55686 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: I-D Action: draft-schaad-pkix-rfc2875-bis-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: Wed, 02 Jan 2013 13:51:28 -0000 Some might be interested in this draft. spt -------- Original Message -------- Subject: I-D Action: draft-schaad-pkix-rfc2875-bis-05.txt Date: Fri, 28 Dec 2012 21:40:11 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diffie-Hellman Proof-of-Possession Algorithms Author(s) : Jim Schaad Hemma Prafullchandra Filename : draft-schaad-pkix-rfc2875-bis-05.txt Pages : 41 Date : 2012-12-28 Abstract: This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of-possession rather than general purpose signing. This document obsoletes RFC 2875. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-schaad-pkix-rfc2875-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-schaad-pkix-rfc2875-bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Thu Jan 3 01:52: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 7309B21F8A18; Thu, 3 Jan 2013 01:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 yi9cSoX9HF+I; Thu, 3 Jan 2013 01:52:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CAC21F8ABA; Thu, 3 Jan 2013 01:52:07 -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: <20130103095207.10511.81917.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 01:52:07 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-08.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:52:08 -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 : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-08.txt Pages : 39 Date : 2013-01-03 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkix@inbox.lv Thu Jan 3 04:02: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 6EC5021F8B5E for ; Thu, 3 Jan 2013 04:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=2.078, 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 e6Se-k7Sim4v for ; Thu, 3 Jan 2013 04:02:34 -0800 (PST) Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id E36D821F8ACE for ; Thu, 3 Jan 2013 04:02:30 -0800 (PST) Received: by shark4.inbox.lv (Postfix, from userid 1000) id 6661925E12; Thu, 3 Jan 2013 14:02:22 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id E7C1025DFF; Thu, 3 Jan 2013 14:02:21 +0200 (EET) Received: from localhost ([10.0.1.20]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id UX2CrkJ-TDyh; Thu, 3 Jan 2013 14:02:15 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 14:02:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w10.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357214535.50e573479f39c@mail.inbox.lv> Date: Thu, 03 Jan 2013 14:02:15 +0200 From: "Andris Berzins" To: "Santosh Chokhani" References: <1356638740.50dcaa146653b@mail.inbox.lv> In-Reply-To: User-Agent: Inbox.lv Webmail Cc: "pkix@ietf.org" 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: Thu, 03 Jan 2013 12:02:35 -0000 OK. Let's assume situation where end entity requests certificate to be revo= ked, but next CRL will be published only=20 after this currently valid certificate will be expired. Very interesting situation. So the goal of rfc5280 is to archive the fact t= hat it was revoked before it expired on at=20 least one published CRL. But does it make sense? Let's assume that relying party checked freshest CRL and concluded that pre= sented certificate is valid (although=20 CA already received revocation request). So the relying party did some dama= ging actions by the request of end=20 entity. Does this feature, that end entity can proof that its cert was rev= oked before it expired, makes relying party=20 to rollback that transaction although relying party checked CRL at that tim= e correctly? Perhaps I can generalize the question. Is relying party obligated to take the risk that although current CRL says = that cert is not revoked, the next published=20 CRL can tell that at that time revocation request was already received. Or is end entity liable and has to take risk that even if revocation is req= uested now, the revocation will take legal=20 effect only after CA's CRL's nextUpdate date is reached? Quoting "Santosh Chokhani" : > Andris, >=20 > The rationale behind this is to provide for archive and future verificati= on=20 >(e.g., for non-repudiation purposes) for . >=20 > Let us make the following assumptions: >=20 >=20 > 1. The CRLs are the official archive. >=20 > 2. Delta CRLs are not the official archive >=20 > 3. A new CRL Y can be built using the previous CRL X and a delta issu= ed=20 >when Y is issued. >=20 > In that case, you want a certificate on at least one CRL and maintain on = del >ta until it is recorded in a CRL that is archived. >=20 > 5280 language is unnecessarily constraining. It should state, =E2=80=9Ce= xpired cert >ificates shall be removed from the CRL, except a revoked certificate shall= a >ppear on at least one CRL. >=20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of A= ndr >is Berzins > Sent: Thursday, December 27, 2012 3:06 PM > To: pkix@ietf.org > Subject: [pkix] why revoked certificate entry has to be included in one C= RL=20 >issued beyond certificate validity period >=20 > rfc5280 states: >=20 > "An entry MUST NOT be removed > from the CRL until it appears on one regularly scheduled CRL issued > beyond the revoked certificate's validity period." >=20 > and >=20 > "If a certificate revocation notice first appears on a delta CRL, then > it is possible for the certificate validity period to expire before > the next complete CRL for the same scope is issued. In this case, > the revocation notice MUST be included in all subsequent delta CRLs > until the revocation notice is included on at least one explicitly > issued complete CRL for this scope." >=20 > Why is that required? From prvs=0715c7051b=rybar@nbusr.sk Thu Jan 3 05:13: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 B58C821E803F for ; Thu, 3 Jan 2013 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 YE-MDoneJYep for ; Thu, 3 Jan 2013 05:13:52 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id C25A221F8526 for ; Thu, 3 Jan 2013 05:13:51 -0800 (PST) Message-Id: <201301031313.r03DDmuq033169@mail.nbusr.sk> From: "Peter Rybar" To: "'Andris Berzins'" , "'Santosh Chokhani'" Date: Thu, 3 Jan 2013 14:13:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1357214535.50e573479f39c@mail.inbox.lv> Thread-Index: Ac3pqj/vVBZG/DgpQ/iltGF2KNO0zQAAb9qQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4450> : streams <885958> : uri <1309933> Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 13:13:52 -0000 Andris, For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not = used. Validation is based only on information whose status is stable and was = already finished in the past. Only thisUpdate date of CRL is used for non-repudiation purposes. The date on which the revocation occurred is specified in revocationDate = field of CRL but the real e.g. compromise was earlier than is the time = value in revocationDate. The revocationDate of a CRL does not give you = the real time when a certificate was revoked but the revocationDate is = the START of the interval since when a certificate is to be invalid = according to signed evidence created by CA. The real revocation date will be earlier than is the date in the = revocationDate field of CRL e.g. according to judgement in court. And as was it clarified by Piyush in thread 2560bis: "according to 5280, revocationDate cannot precede thisUpdate of an = earlier CRL if the revocation for the certificate is being reported the = first time. Not saying that OCSP has to follow these rules, but given that it is = deviating from CRLs on the meaning of revocationTime and = revocationReason, a separated section describing these fields should be = added. " =20 Peter Rybar National Security Authority Information Security and Electronic Signature Department -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Andris Berzins Sent: Thursday, January 03, 2013 1:02 PM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period OK. Let's assume situation where end entity requests certificate to be = revoked, but next CRL will be published only=20 after this currently valid certificate will be expired. Very interesting situation. So the goal of rfc5280 is to archive the = fact that it was revoked before it expired on at=20 least one published CRL. But does it make sense? Let's assume that relying party checked freshest CRL and concluded that = presented certificate is valid (although=20 CA already received revocation request). So the relying party did some = damaging actions by the request of end=20 entity. Does this feature, that end entity can proof that its cert was = revoked before it expired, makes relying party=20 to rollback that transaction although relying party checked CRL at that = time correctly? Perhaps I can generalize the question. Is relying party obligated to take the risk that although current CRL = says that cert is not revoked, the next published=20 CRL can tell that at that time revocation request was already received. Or is end entity liable and has to take risk that even if revocation is = requested now, the revocation will take legal=20 effect only after CA's CRL's nextUpdate date is reached? Quoting "Santosh Chokhani" : > Andris, >=20 > The rationale behind this is to provide for archive and future = verification=20 >(e.g., for non-repudiation purposes) for . >=20 > Let us make the following assumptions: >=20 >=20 > 1. The CRLs are the official archive. >=20 > 2. Delta CRLs are not the official archive >=20 > 3. A new CRL Y can be built using the previous CRL X and a delta = issued=20 >when Y is issued. >=20 > In that case, you want a certificate on at least one CRL and maintain = on del >ta until it is recorded in a CRL that is archived. >=20 > 5280 language is unnecessarily constraining. It should state, = =E2=80=9Cexpired cert >ificates shall be removed from the CRL, except a revoked certificate = shall a >ppear on at least one CRL. >=20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Andr >is Berzins > Sent: Thursday, December 27, 2012 3:06 PM > To: pkix@ietf.org > Subject: [pkix] why revoked certificate entry has to be included in = one CRL=20 >issued beyond certificate validity period >=20 > rfc5280 states: >=20 > "An entry MUST NOT be removed > from the CRL until it appears on one regularly scheduled CRL issued > beyond the revoked certificate's validity period." >=20 > and >=20 > "If a certificate revocation notice first appears on a delta CRL, then > it is possible for the certificate validity period to expire before > the next complete CRL for the same scope is issued. In this case, > the revocation notice MUST be included in all subsequent delta CRLs > until the revocation notice is included on at least one explicitly > issued complete CRL for this scope." >=20 > Why is that required? _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Thu Jan 3 05:37:51 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 F2BA521E803A for ; Thu, 3 Jan 2013 05:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 pq4iYYAnf5G6 for ; Thu, 3 Jan 2013 05:37:50 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2998C21E8034 for ; Thu, 3 Jan 2013 05:37:50 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64BA15311053; Thu, 3 Jan 2013 08:37:49 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 50E425311040; Thu, 3 Jan 2013 08:37:49 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 08:37:48 -0500 From: "Miller, Timothy J." To: 'Andris Berzins' , Santosh Chokhani Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN5G2Sn7/gW7Wk60CbQPL0xhIa3ZguqlgAgAk09YD//8Vv4A== Date: Thu, 3 Jan 2013 13:37:48 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FEF8C@IMCMBX01.MITRE.ORG> References: <1356638740.50dcaa146653b@mail.inbox.lv> <1357214535.50e573479f39c@mail.inbox.lv> In-Reply-To: <1357214535.50e573479f39c@mail.inbox.lv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" 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: Thu, 03 Jan 2013 13:37:51 -0000 Q29uc2lkZXIgdmFsaWRhdGlvbiBvZiBhbiBhcmNoaXZlZCBzaWduYXR1cmUgYW5kIGFsbCB3aWxs IGJlY29tZSBjbGVhci4gIDopICBFLmcuLCBpZiB0aGUgYWN0aW9uIGlzIHRoZSBzaWduaW5nIG9m IGEgY29udHJhY3QsIHRoZSBhY3R1YWwgdmFsaWRhdGlvbiBvZiB0aGUgc2lnbmF0dXJlIG1heSBi ZSBsb25nIGFmdGVyIGV4cGlyeSBvZiBhbGwgY2VydHMgaW4gdGhlIHNpZ25hdHVyZS0tZm9yIGV4 YW1wbGUsIHdoZW4gdGhlIGNvbnRyYWN0IGlzIGNvbnRlc3RlZCBpbiBjb3VydC4gIFByb3Zpbmcg dmFsaWRpdHkgYXQgdGltZSBvZiBzaWduaW5nIGlzIGltcG9ydGFudCBpbiB0aGlzIGNhc2UsIGFu ZCB0aGUgcmVxdWlyZW1lbnQgdG8gYXBwZWFyIG9uIGF0IGxlYXN0IG9uZSBDUkwgaXMgY3JpdGlj YWwgdG8gdGhhdCBwcm9vZi4NCg0KWWVzLCBpbiBhIFRMUyBvciB0cmFuc2FjdGlvbmFsIGNvbnRl eHQsIGFwcGVhcmFuY2Ugb24gYSBDUkwgYWZ0ZXIgZXhwaXJ5IGRvZXNuJ3QgbWFrZSBhIGRpZmZl cmVuY2UsIGJ1dCBQS0kgaGFzIG1vcmUgdXNlIGNhc2VzIHRoYW4gdGhhdC4NCg0KLS0gVA0KDQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPkFuZHJpcyBCZXJ6 aW5zDQo+U2VudDogVGh1cnNkYXksIEphbnVhcnkgMDMsIDIwMTMgNzowMiBBTQ0KPlRvOiBTYW50 b3NoIENob2toYW5pDQo+Q2M6IHBraXhAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3BraXhdIHdo eSByZXZva2VkIGNlcnRpZmljYXRlIGVudHJ5IGhhcyB0byBiZSBpbmNsdWRlZCBpbiBvbmUgQ1JM DQo+aXNzdWVkIGJleW9uZCBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBwZXJpb2QNCj4NCj5PSy4gTGV0 J3MgYXNzdW1lIHNpdHVhdGlvbiB3aGVyZSBlbmQgZW50aXR5IHJlcXVlc3RzIGNlcnRpZmljYXRl IHRvIGJlDQo+cmV2b2tlZCwgYnV0IG5leHQgQ1JMIHdpbGwgYmUgcHVibGlzaGVkIG9ubHkNCj5h ZnRlciB0aGlzIGN1cnJlbnRseSB2YWxpZCBjZXJ0aWZpY2F0ZSB3aWxsIGJlIGV4cGlyZWQuDQo+ DQo+VmVyeSBpbnRlcmVzdGluZyBzaXR1YXRpb24uIFNvIHRoZSBnb2FsIG9mIHJmYzUyODAgaXMg dG8gYXJjaGl2ZSB0aGUgZmFjdCB0aGF0IGl0DQo+d2FzIHJldm9rZWQgYmVmb3JlIGl0IGV4cGly ZWQgb24gYXQNCj5sZWFzdCBvbmUgcHVibGlzaGVkIENSTC4NCj4NCj5CdXQgZG9lcyBpdCBtYWtl IHNlbnNlPw0KPg0KPkxldCdzIGFzc3VtZSB0aGF0IHJlbHlpbmcgcGFydHkgY2hlY2tlZCBmcmVz aGVzdCBDUkwgYW5kIGNvbmNsdWRlZCB0aGF0DQo+cHJlc2VudGVkIGNlcnRpZmljYXRlIGlzIHZh bGlkIChhbHRob3VnaA0KPkNBIGFscmVhZHkgcmVjZWl2ZWQgcmV2b2NhdGlvbiByZXF1ZXN0KS4g U28gdGhlIHJlbHlpbmcgcGFydHkgZGlkIHNvbWUNCj5kYW1hZ2luZyBhY3Rpb25zIGJ5IHRoZSBy ZXF1ZXN0IG9mIGVuZA0KPmVudGl0eS4gIERvZXMgdGhpcyBmZWF0dXJlLCB0aGF0IGVuZCBlbnRp dHkgY2FuIHByb29mIHRoYXQgaXRzIGNlcnQgd2FzIHJldm9rZWQNCj5iZWZvcmUgaXQgZXhwaXJl ZCwgbWFrZXMgcmVseWluZyBwYXJ0eQ0KPnRvIHJvbGxiYWNrIHRoYXQgdHJhbnNhY3Rpb24gYWx0 aG91Z2ggcmVseWluZyBwYXJ0eSBjaGVja2VkIENSTCBhdCB0aGF0IHRpbWUNCj5jb3JyZWN0bHk/ DQo+DQo+UGVyaGFwcyBJIGNhbiBnZW5lcmFsaXplIHRoZSBxdWVzdGlvbi4NCj5JcyByZWx5aW5n IHBhcnR5IG9ibGlnYXRlZCB0byB0YWtlIHRoZSByaXNrIHRoYXQgYWx0aG91Z2ggY3VycmVudCBD Ukwgc2F5cyB0aGF0DQo+Y2VydCBpcyBub3QgcmV2b2tlZCwgdGhlIG5leHQgcHVibGlzaGVkDQo+ Q1JMIGNhbiB0ZWxsIHRoYXQgYXQgdGhhdCB0aW1lIHJldm9jYXRpb24gcmVxdWVzdCB3YXMgYWxy ZWFkeSByZWNlaXZlZC4NCj5PciBpcyBlbmQgZW50aXR5IGxpYWJsZSBhbmQgaGFzIHRvIHRha2Ug cmlzayB0aGF0IGV2ZW4gaWYgcmV2b2NhdGlvbiBpcyByZXF1ZXN0ZWQNCj5ub3csIHRoZSByZXZv Y2F0aW9uIHdpbGwgdGFrZSBsZWdhbA0KPmVmZmVjdCBvbmx5IGFmdGVyIENBJ3MgQ1JMJ3MgbmV4 dFVwZGF0ZSBkYXRlIGlzIHJlYWNoZWQ/DQo+DQo+DQo+DQo+UXVvdGluZyAiU2FudG9zaCBDaG9r aGFuaSIgPFNDaG9raGFuaUBjeWduYWNvbS5jb20+Og0KPj4gQW5kcmlzLA0KPj4NCj4+IFRoZSBy YXRpb25hbGUgYmVoaW5kIHRoaXMgaXMgdG8gcHJvdmlkZSBmb3IgYXJjaGl2ZSBhbmQgZnV0dXJl IHZlcmlmaWNhdGlvbg0KPj4oZS5nLiwgZm9yIG5vbi1yZXB1ZGlhdGlvbiBwdXJwb3NlcykgZm9y IC4NCj4+DQo+PiBMZXQgdXMgbWFrZSB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KPj4NCj4+ DQo+PiAxLiAgICAgVGhlIENSTHMgYXJlIHRoZSBvZmZpY2lhbCBhcmNoaXZlLg0KPj4NCj4+IDIu ICAgICBEZWx0YSBDUkxzIGFyZSBub3QgdGhlIG9mZmljaWFsIGFyY2hpdmUNCj4+DQo+PiAzLiAg ICAgQSBuZXcgQ1JMIFkgY2FuIGJlIGJ1aWx0IHVzaW5nIHRoZSBwcmV2aW91cyBDUkwgWCBhbmQg YSBkZWx0YSBpc3N1ZWQNCj4+d2hlbiBZIGlzIGlzc3VlZC4NCj4+DQo+PiBJbiB0aGF0IGNhc2Us IHlvdSB3YW50IGEgY2VydGlmaWNhdGUgb24gYXQgbGVhc3Qgb25lIENSTCBhbmQgbWFpbnRhaW4g b24gZGVsDQo+PnRhIHVudGlsIGl0IGlzIHJlY29yZGVkIGluIGEgQ1JMIHRoYXQgaXMgYXJjaGl2 ZWQuDQo+Pg0KPj4gNTI4MCBsYW5ndWFnZSBpcyB1bm5lY2Vzc2FyaWx5IGNvbnN0cmFpbmluZy4g IEl0IHNob3VsZCBzdGF0ZSwg4oCcZXhwaXJlZCBjZXJ0DQo+PmlmaWNhdGVzIHNoYWxsIGJlIHJl bW92ZWQgZnJvbSB0aGUgQ1JMLCBleGNlcHQgYSByZXZva2VkIGNlcnRpZmljYXRlIHNoYWxsIGEN Cj4+cHBlYXIgb24gYXQgbGVhc3Qgb25lIENSTC4NCj4+DQo+PiBGcm9tOiBwa2l4LWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPkFu ZHINCj4+aXMgQmVyemlucw0KPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDI3LCAyMDEyIDM6 MDYgUE0NCj4+IFRvOiBwa2l4QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbcGtpeF0gd2h5IHJldm9r ZWQgY2VydGlmaWNhdGUgZW50cnkgaGFzIHRvIGJlIGluY2x1ZGVkIGluIG9uZSBDUkwNCj4+aXNz dWVkIGJleW9uZCBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBwZXJpb2QNCj4+DQo+PiByZmM1MjgwIHN0 YXRlczoNCj4+DQo+PiAiQW4gZW50cnkgTVVTVCBOT1QgYmUgcmVtb3ZlZA0KPj4gZnJvbSB0aGUg Q1JMIHVudGlsIGl0IGFwcGVhcnMgb24gb25lIHJlZ3VsYXJseSBzY2hlZHVsZWQgQ1JMIGlzc3Vl ZA0KPj4gYmV5b25kIHRoZSByZXZva2VkIGNlcnRpZmljYXRlJ3MgdmFsaWRpdHkgcGVyaW9kLiIN Cj4+DQo+PiBhbmQNCj4+DQo+PiAiSWYgYSBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIG5vdGljZSBm aXJzdCBhcHBlYXJzIG9uIGEgZGVsdGEgQ1JMLCB0aGVuDQo+PiBpdCBpcyBwb3NzaWJsZSBmb3Ig dGhlIGNlcnRpZmljYXRlIHZhbGlkaXR5IHBlcmlvZCB0byBleHBpcmUgYmVmb3JlDQo+PiB0aGUg bmV4dCBjb21wbGV0ZSBDUkwgZm9yIHRoZSBzYW1lIHNjb3BlIGlzIGlzc3VlZC4gIEluIHRoaXMg Y2FzZSwNCj4+IHRoZSByZXZvY2F0aW9uIG5vdGljZSBNVVNUIGJlIGluY2x1ZGVkIGluIGFsbCBz dWJzZXF1ZW50IGRlbHRhIENSTHMNCj4+IHVudGlsIHRoZSByZXZvY2F0aW9uIG5vdGljZSBpcyBp bmNsdWRlZCBvbiBhdCBsZWFzdCBvbmUgZXhwbGljaXRseQ0KPj4gaXNzdWVkIGNvbXBsZXRlIENS TCBmb3IgdGhpcyBzY29wZS4iDQo+Pg0KPj4gV2h5IGlzIHRoYXQgcmVxdWlyZWQ/DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wa2l4IG1haWxp bmcgbGlzdA0KPnBraXhAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BraXgNCg== From pkix@inbox.lv Thu Jan 3 05:49: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 7306421E804B for ; Thu, 3 Jan 2013 05:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=1.039, 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 FMBNpJw0U+RT for ; Thu, 3 Jan 2013 05:49:29 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5121E8045 for ; Thu, 3 Jan 2013 05:49:18 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id 6CAF46D26; Thu, 3 Jan 2013 15:49:11 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 3FF0D6F72; Thu, 3 Jan 2013 15:49:11 +0200 (EET) Received: from localhost ([10.0.1.18]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id jdK-oNfADGmO; Thu, 3 Jan 2013 15:49:05 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 15:49:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w8.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357220945.50e58c51cacff@mail.inbox.lv> Date: Thu, 03 Jan 2013 15:49:05 +0200 From: "Andris Berzins" To: "Peter Rybar" References: <1357214535.50e573479f39c@mail.inbox.lv> <201301031313.r03DDmb7033171@mail.nbusr.sk> In-Reply-To: <201301031313.r03DDmb7033171@mail.nbusr.sk> User-Agent: Inbox.lv Webmail Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 13:49:30 -0000 Quoting "Peter Rybar" : > The date on which the revocation occurred is specified in revocationDate = fie >ld of CRL but the real e.g. compromise was earlier than is the time value = in > revocationDate. The revocationDate of a CRL does not give you the real ti= me > when a certificate was revoked but the revocationDate is the START of the= i >nterval since when a certificate is to be invalid according to signed evid= en >ce created by CA. Remember that there is even "invalidation date" entry extension that might = much more way back. >=20 > The real revocation date will be earlier than is the date in the revocati= onD >ate field of CRL e.g. according to judgement in court. Nice. So what the relying party should do? If the relying party checks CRL = that is current (current time between=20 thisUpdate and nextUpdate), it still risks that in next CRL revocation date= might be precede current time of check=20 or the court will rule that real revocation was much earlier and thus relyi= ng party has to take losses? >=20 > And as was it clarified by Piyush in thread 2560bis: > "according to 5280, revocationDate cannot precede thisUpdate of an earlie= r C >RL if the revocation for the certificate is being reported the first time= =2E >=20 > Not saying that OCSP has to follow these rules, but given that it is devi= ati >ng from CRLs on the meaning of revocationTime and revocationReason, a sepa= ra >ted section describing these fields should be added. " >=20 >=20 > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of A= ndr >is Berzins > Sent: Thursday, January 03, 2013 1:02 PM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] why revoked certificate entry has to be included in o= ne=20 >CRL issued beyond certificate validity period >=20 > OK. Let's assume situation where end entity requests certificate to be re= vok >ed, but next CRL will be published only > after this currently valid certificate will be expired. >=20 > Very interesting situation. So the goal of rfc5280 is to archive the fact= th >at it was revoked before it expired on at > least one published CRL. >=20 > But does it make sense? >=20 > Let's assume that relying party checked freshest CRL and concluded that p= res >ented certificate is valid (although > CA already received revocation request). So the relying party did some da= mag >ing actions by the request of end > entity. Does this feature, that end entity can proof that its cert was r= evo >ked before it expired, makes relying party > to rollback that transaction although relying party checked CRL at that t= ime > correctly? >=20 > Perhaps I can generalize the question. > Is relying party obligated to take the risk that although current CRL say= s t >hat cert is not revoked, the next published > CRL can tell that at that time revocation request was already received. > Or is end entity liable and has to take risk that even if revocation is r= equ >ested now, the revocation will take legal > effect only after CA's CRL's nextUpdate date is reached? >=20 >=20 >=20 > Quoting "Santosh Chokhani" : >> Andris, >>=20 >> The rationale behind this is to provide for archive and future verificat= ion >> (e.g., for non-repudiation purposes) for . >>=20 >> Let us make the following assumptions: >>=20 >>=20 >> 1. The CRLs are the official archive. >>=20 >> 2. Delta CRLs are not the official archive >>=20 >> 3. A new CRL Y can be built using the previous CRL X and a delta iss= ued >> when Y is issued. >>=20 >> In that case, you want a certificate on at least one CRL and maintain on= del >> ta until it is recorded in a CRL that is archived. >>=20 >> 5280 language is unnecessarily constraining. It should state, =E2=80=9C= expired cert >> ificates shall be removed from the CRL, except a revoked certificate sha= ll a >> ppear on at least one CRL. >>=20 >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Andr >> is Berzins >> Sent: Thursday, December 27, 2012 3:06 PM >> To: pkix@ietf.org >> Subject: [pkix] why revoked certificate entry has to be included in one = CRL >> issued beyond certificate validity period >>=20 >> rfc5280 states: >>=20 >> "An entry MUST NOT be removed >> from the CRL until it appears on one regularly scheduled CRL issued >> beyond the revoked certificate's validity period." >>=20 >> and >>=20 >> "If a certificate revocation notice first appears on a delta CRL, then >> it is possible for the certificate validity period to expire before >> the next complete CRL for the same scope is issued. In this case, >> the revocation notice MUST be included in all subsequent delta CRLs >> until the revocation notice is included on at least one explicitly >> issued complete CRL for this scope." >>=20 >> Why is that required? >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Thu Jan 3 06:07:42 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 D59A321F8BDB for ; Thu, 3 Jan 2013 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rkBGHgmEkTJp for ; Thu, 3 Jan 2013 06:07:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F14021F86BC for ; Thu, 3 Jan 2013 06:07:42 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA0FB43300C1; Thu, 3 Jan 2013 09:07:39 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B5A7943300C9; Thu, 3 Jan 2013 09:07:39 -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; Thu, 3 Jan 2013 09:07:38 -0500 From: "Miller, Timothy J." To: 'Andris Berzins' , Peter Rybar Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN6bkYn7/gW7Wk60CbQPL0xhIa3Zg3oZbA Date: Thu, 3 Jan 2013 14:07:38 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FF00B@IMCMBX01.MITRE.ORG> References: <1357214535.50e573479f39c@mail.inbox.lv> <201301031313.r03DDmb7033171@mail.nbusr.sk> <1357220945.50e58c51cacff@mail.inbox.lv> In-Reply-To: <1357220945.50e58c51cacff@mail.inbox.lv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" 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: Thu, 03 Jan 2013 14:07:43 -0000 Pk5pY2UuIFNvIHdoYXQgdGhlIHJlbHlpbmcgcGFydHkgc2hvdWxkIGRvPyBJZiB0aGUgcmVseWlu ZyBwYXJ0eSBjaGVja3MgQ1JMIHRoYXQNCj5pcyBjdXJyZW50IChjdXJyZW50IHRpbWUgYmV0d2Vl bg0KPnRoaXNVcGRhdGUgYW5kIG5leHRVcGRhdGUpLCBpdCBzdGlsbCByaXNrcyB0aGF0IGluIG5l eHQgQ1JMIHJldm9jYXRpb24gZGF0ZQ0KPm1pZ2h0IGJlIHByZWNlZGUgY3VycmVudCB0aW1lIG9m IGNoZWNrDQo+b3IgdGhlIGNvdXJ0IHdpbGwgcnVsZSB0aGF0IHJlYWwgcmV2b2NhdGlvbiB3YXMg bXVjaCBlYXJsaWVyIGFuZCB0aHVzIHJlbHlpbmcNCj5wYXJ0eSBoYXMgdG8gdGFrZSBsb3NzZXM/ DQoNCllvdSBjYW4gb25seSBhY3Qgb24gd2hhdCB5b3Uga25vdyBhdCB0aGUgdGltZSB5b3UgbmVl ZCB0byBhY3QuICBXaGF0IGhhcHBlbnMgaW4gYSBkaXNwdXRlIGlzIHVwIHRvIHRoZSBqdWRnZSBh dCB0aGUgdGltZSBvZiB0aGUgZGlzcHV0ZS0td2hpY2ggaXMgaW4gdGhlIGZ1dHVyZS0tc28gaXNu J3QgcGFydCBvZiB0aGF0IGNhbGN1bHVzLiAgVGhlIHNpdHVhdGlvbiBpcyBhbmFsb2dvdXMgdG8g YW4gaW4tcGVyc29uIGZyYXVkIGNvbW1pdHRlZCBieSBhIGNvbi1tYW4gd2l0aCBmb3JnZWQgY29y cG9yYXRlIGVuZG9yc2VtZW50czsgdGhlIGRlZnJhdWRlZCBwYXJ0eSBpcyBlbnRpdGxlZCB0byBy ZWNvdXAgbG9zc2VzLCBidXQgd2hldGhlciBoZSBjYW4gcmVjb3VwIGZyb20gdGhlIG1pc3JlcHJl c2VudGVkIGNvcnBvcmF0aW9uIGRlcGVuZHMgb24gdGhlIHNwZWNpZmljIGZhY3RzIG9mIHRoZSBj YXNlIChlLmcuLCBpZiB0aGVyZSB3YXMgbmVnbGlnZW5jZSBvciBjb21wbGljaXR5KS4NCg0KLS0g VA0K From pkix@inbox.lv Thu Jan 3 06:09: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 750ED21F8C12 for ; Thu, 3 Jan 2013 06:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.693, 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 PVv63U9UKdyl for ; Thu, 3 Jan 2013 06:09:20 -0800 (PST) Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6721F8BDB for ; Thu, 3 Jan 2013 06:09:19 -0800 (PST) Received: by shark4.inbox.lv (Postfix, from userid 1000) id 92FF825E21; Thu, 3 Jan 2013 16:09:15 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id 6440525D76; Thu, 3 Jan 2013 16:09:15 +0200 (EET) Received: from localhost ([10.0.1.15]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id HE9eKwTQebty; Thu, 3 Jan 2013 16:09:13 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 16:09:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w5.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357222153.50e591090e7c9@mail.inbox.lv> Date: Thu, 03 Jan 2013 16:09:13 +0200 From: "Andris Berzins" To: "Miller, Timothy J." References: <1357214535.50e573479f39c@mail.inbox.lv> <195DB2510AAA004391F58E28FCE21200066FEF8C@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066FEF8C@IMCMBX01.MITRE.ORG> User-Agent: Inbox.lv Webmail Cc: "pkix@ietf.org" 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: Thu, 03 Jan 2013 14:09:21 -0000 Quoting "Miller, Timothy J." : > Consider validation of an archived signature and all will become clear. = :)=20 > E.g., if the action is the signing of a contract, the actual validation o= f=20 >the signature may be long after expiry of all certs in the signature--for = ex >ample, when the contract is contested in court. Proving validity at time = of > signing is important in this case, and the requirement to appear on at le= as >t one CRL is critical to that proof. So this is for CA's own record keeping (assuming it has no other database o= f revocation than published CRL's). For=20 relying party it makes no sense, because relying party is not and can not b= e obligated to collect all CA's issued=20 CRLs. But even then, so what that the CA knows that the cert was revoked so= me small time before expiration, if it=20 could not distribute that information by the time when the relying party ma= de the decision? > Yes, in a TLS or transactional context, appearance on a CRL after expiry = doe >sn't make a difference, but PKI has more use cases than that. For signatures you would first need to prove the time of signing, by using = timestamp, which in most deployments=20 would also assure that on the time of timestamping the certificate was vali= d. >=20 > -- T >=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Andris Berzins >> Sent: Thursday, January 03, 2013 7:02 AM >> To: Santosh Chokhani >> Cc: pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included in = one=20 >>CRL >> issued beyond certificate validity period >>=20 >> OK. Let's assume situation where end entity requests certificate to be >> revoked, but next CRL will be published only >> after this currently valid certificate will be expired. >>=20 >> Very interesting situation. So the goal of rfc5280 is to archive the fac= t th >>at it >> was revoked before it expired on at >> least one published CRL. >>=20 >> But does it make sense? >>=20 >> Let's assume that relying party checked freshest CRL and concluded that >> presented certificate is valid (although >> CA already received revocation request). So the relying party did some >> damaging actions by the request of end >> entity. Does this feature, that end entity can proof that its cert was = revo >>ked >> before it expired, makes relying party >> to rollback that transaction although relying party checked CRL at that = time >> correctly? >>=20 >> Perhaps I can generalize the question. >> Is relying party obligated to take the risk that although current CRL sa= ys t >>hat >> cert is not revoked, the next published >> CRL can tell that at that time revocation request was already received= =2E >> Or is end entity liable and has to take risk that even if revocation is = requ >>ested >> now, the revocation will take legal >> effect only after CA's CRL's nextUpdate date is reached? >>=20 >>=20 >>=20 >> Quoting "Santosh Chokhani" : >>> Andris, >>>=20 >>> The rationale behind this is to provide for archive and future verifica= tion >>> (e.g., for non-repudiation purposes) for . >>>=20 >>> Let us make the following assumptions: >>>=20 >>>=20 >>> 1. The CRLs are the official archive. >>>=20 >>> 2. Delta CRLs are not the official archive >>>=20 >>> 3. A new CRL Y can be built using the previous CRL X and a delta is= sued >>> when Y is issued. >>>=20 >>> In that case, you want a certificate on at least one CRL and maintain o= n del >>> ta until it is recorded in a CRL that is archived. >>>=20 >>> 5280 language is unnecessarily constraining. It should state, =E2=80= =9Cexpired cert >>> ificates shall be removed from the CRL, except a revoked certificate sh= all a >>> ppear on at least one CRL. >>>=20 >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Andr >>> is Berzins >>> Sent: Thursday, December 27, 2012 3:06 PM >>> To: pkix@ietf.org >>> Subject: [pkix] why revoked certificate entry has to be included in one= CRL >>> issued beyond certificate validity period >>>=20 >>> rfc5280 states: >>>=20 >>> "An entry MUST NOT be removed >>> from the CRL until it appears on one regularly scheduled CRL issued >>> beyond the revoked certificate's validity period." >>>=20 >>> and >>>=20 >>> "If a certificate revocation notice first appears on a delta CRL, then >>> it is possible for the certificate validity period to expire before >>> the next complete CRL for the same scope is issued. In this case, >>> the revocation notice MUST be included in all subsequent delta CRLs >>> until the revocation notice is included on at least one explicitly >>> issued complete CRL for this scope." >>>=20 >>> Why is that required? >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix From pkix@inbox.lv Thu Jan 3 06: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 08F8621F8C0F for ; Thu, 3 Jan 2013 06:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, MANGLED_FROM=2.3, 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 jQaETT+mD2fO for ; Thu, 3 Jan 2013 06:22:15 -0800 (PST) Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id 476CE21F8C09 for ; Thu, 3 Jan 2013 06:22:14 -0800 (PST) Received: by shark4.inbox.lv (Postfix, from userid 1000) id 8A17725E72; Thu, 3 Jan 2013 16:22:10 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id 50E9425E64; Thu, 3 Jan 2013 16:22:10 +0200 (EET) Received: from localhost ([10.0.1.20]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id SNw52sJSx8w4; Thu, 3 Jan 2013 16:22:05 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 16:22:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w10.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357222925.50e5940d206a9@mail.inbox.lv> Date: Thu, 03 Jan 2013 16:22:05 +0200 From: "Andris Berzins" To: "Miller, Timothy J." References: <1357220945.50e58c51cacff@mail.inbox.lv> <195DB2510AAA004391F58E28FCE21200066FF00B@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066FF00B@IMCMBX01.MITRE.ORG> User-Agent: Inbox.lv Webmail Cc: "pkix@ietf.org" 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: Thu, 03 Jan 2013 14:22:16 -0000 Quoting "Miller, Timothy J." : >> Nice. So what the relying party should do? If the relying party checks C= RL t >>hat >> is current (current time between >> thisUpdate and nextUpdate), it still risks that in next CRL revocation d= ate >> might be precede current time of check >> or the court will rule that real revocation was much earlier and thus re= lyin >>g >> party has to take losses? >=20 > You can only act on what you know at the time you need to act. What happ= ens > in a dispute is up to the judge at the time of the dispute--which is in t= he > future--so isn't part of that calculus. The situation is analogous to an= i >n-person fraud committed by a con-man with forged corporate endorsements; = th >e defrauded party is entitled to recoup losses, but whether he can recoup = fr >om the misrepresented corporation depends on the specific facts of the cas= e=20 >(e.g., if there was negligence or complicity). >=20 > -- T What would you recommend for relying party? Is it safe to execute transacti= on after checking cert validity in CRL=20 who's thisUpdate is current and nextUpdate is in future? Or am I still at r= isk that in next CRL CA can declare that=20 certificate at that time was already revoked and I might have to recoup los= ses? From stefan@aaa-sec.com Thu Jan 3 06:27: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 6D98221F8C0F for ; Thu, 3 Jan 2013 06:27:23 -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 e1djw9K75UUw for ; Thu, 3 Jan 2013 06:27:22 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 77B8521F8C09 for ; Thu, 3 Jan 2013 06:27:21 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id BEA491E12826 for ; Thu, 3 Jan 2013 15:27:17 +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 x1LwEnaqx-fn for ; Thu, 3 Jan 2013 15:27:16 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A80B41E12864 for ; Thu, 3 Jan 2013 15:27:16 +0100 (CET) Received: (qmail 85615 invoked from network); 3 Jan 2013 14:27:15 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Jan 2013 14:27:15 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 03 Jan 2013 15:27:11 +0100 From: Stefan Santesson To: Peter Rybar , 'Andris Berzins' , 'Santosh Chokhani' Message-ID: Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period In-Reply-To: <201301031313.r03DDmuq033169@mail.nbusr.sk> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 14:27:23 -0000 Peter, I think you are mixing up the terminology. There is only one revocation date. Whether you can convince the court that you did not use your private key at some event is another thing. They will look at all facts of the case, technical and non-technical. /Stefan On 1/3/13 2:13 PM, "Peter Rybar" wrote: >Andris, > >For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not used. >Validation is based only on information whose status is stable and was >already finished in the past. > >Only thisUpdate date of CRL is used for non-repudiation purposes. > >The date on which the revocation occurred is specified in revocationDate >field of CRL but the real e.g. compromise was earlier than is the time >value in revocationDate. The revocationDate of a CRL does not give you >the real time when a certificate was revoked but the revocationDate is >the START of the interval since when a certificate is to be invalid >according to signed evidence created by CA. > >The real revocation date will be earlier than is the date in the >revocationDate field of CRL e.g. according to judgement in court. > >And as was it clarified by Piyush in thread 2560bis: >"according to 5280, revocationDate cannot precede thisUpdate of an >earlier CRL if the revocation for the certificate is being reported the >first time. > >Not saying that OCSP has to follow these rules, but given that it is >deviating from CRLs on the meaning of revocationTime and >revocationReason, a separated section describing these fields should be >added. " > >=20 >Peter Rybar >National Security Authority >Information Security and Electronic Signature Department > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Andris Berzins >Sent: Thursday, January 03, 2013 1:02 PM >To: Santosh Chokhani >Cc: pkix@ietf.org >Subject: Re: [pkix] why revoked certificate entry has to be included in >one CRL issued beyond certificate validity period > >OK. Let's assume situation where end entity requests certificate to be >revoked, but next CRL will be published only >after this currently valid certificate will be expired. > >Very interesting situation. So the goal of rfc5280 is to archive the fact >that it was revoked before it expired on at >least one published CRL. > >But does it make sense? > >Let's assume that relying party checked freshest CRL and concluded that >presented certificate is valid (although >CA already received revocation request). So the relying party did some >damaging actions by the request of end >entity. Does this feature, that end entity can proof that its cert was >revoked before it expired, makes relying party >to rollback that transaction although relying party checked CRL at that >time correctly? > >Perhaps I can generalize the question. >Is relying party obligated to take the risk that although current CRL >says that cert is not revoked, the next published >CRL can tell that at that time revocation request was already received. >Or is end entity liable and has to take risk that even if revocation is >requested now, the revocation will take legal >effect only after CA's CRL's nextUpdate date is reached? > > > >Quoting "Santosh Chokhani" : >> Andris, >>=20 >> The rationale behind this is to provide for archive and future >>verification=20 >>(e.g., for non-repudiation purposes) for . >>=20 >> Let us make the following assumptions: >>=20 >>=20 >> 1. The CRLs are the official archive. >>=20 >> 2. Delta CRLs are not the official archive >>=20 >> 3. A new CRL Y can be built using the previous CRL X and a delta >>issued=20 >>when Y is issued. >>=20 >> In that case, you want a certificate on at least one CRL and maintain >>on del >>ta until it is recorded in a CRL that is archived. >>=20 >> 5280 language is unnecessarily constraining. It should state, =B3expired >>cert >>ificates shall be removed from the CRL, except a revoked certificate >>shall a >>ppear on at least one CRL. >>=20 >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>Andr >>is Berzins >> Sent: Thursday, December 27, 2012 3:06 PM >> To: pkix@ietf.org >> Subject: [pkix] why revoked certificate entry has to be included in one >>CRL=20 >>issued beyond certificate validity period >>=20 >> rfc5280 states: >>=20 >> "An entry MUST NOT be removed >> from the CRL until it appears on one regularly scheduled CRL issued >> beyond the revoked certificate's validity period." >>=20 >> and >>=20 >> "If a certificate revocation notice first appears on a delta CRL, then >> it is possible for the certificate validity period to expire before >> the next complete CRL for the same scope is issued. In this case, >> the revocation notice MUST be included in all subsequent delta CRLs >> until the revocation notice is included on at least one explicitly >> issued complete CRL for this scope." >>=20 >> Why is that required? > >_______________________________________________ >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 pkix@inbox.lv Thu Jan 3 06:37: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 60AD921E8047 for ; Thu, 3 Jan 2013 06:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.646, 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 iLLDoxQO3oMj for ; Thu, 3 Jan 2013 06:37:00 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id 14BED21F859B for ; Thu, 3 Jan 2013 06:36:41 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id 60EAD6DB3; Thu, 3 Jan 2013 16:36:36 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 30E356D3B; Thu, 3 Jan 2013 16:36:36 +0200 (EET) Received: from localhost ([10.0.1.21]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id gqgQO8toLL-2; Thu, 3 Jan 2013 16:36:32 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 16:36:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w11.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357223792.50e59770b535d@mail.inbox.lv> Date: Thu, 03 Jan 2013 16:36:32 +0200 From: "Andris Berzins" To: "Stefan Santesson" References: <201301031313.r03DDmuq033169@mail.nbusr.sk> In-Reply-To: User-Agent: Inbox.lv Webmail Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 14:37:01 -0000 If talking about courts, are there any case studies available or known case= s? Quoting "Stefan Santesson" : > Peter, >=20 > I think you are mixing up the terminology. >=20 > There is only one revocation date. > Whether you can convince the court that you did not use your private key > at some event is another thing. They will look at all facts of the case, > technical and non-technical. >=20 > /Stefan >=20 >=20 > On 1/3/13 2:13 PM, "Peter Rybar" wrote: >=20 >> Andris, >>=20 >> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not use= d. >> Validation is based only on information whose status is stable and was >> already finished in the past. >>=20 >> Only thisUpdate date of CRL is used for non-repudiation purposes. >>=20 >> The date on which the revocation occurred is specified in revocationDate >> field of CRL but the real e.g. compromise was earlier than is the time >> value in revocationDate. The revocationDate of a CRL does not give you >> the real time when a certificate was revoked but the revocationDate is >> the START of the interval since when a certificate is to be invalid >> according to signed evidence created by CA. >>=20 >> The real revocation date will be earlier than is the date in the >> revocationDate field of CRL e.g. according to judgement in court. >>=20 >> And as was it clarified by Piyush in thread 2560bis: >> "according to 5280, revocationDate cannot precede thisUpdate of an >> earlier CRL if the revocation for the certificate is being reported the >> first time. >>=20 >> Not saying that OCSP has to follow these rules, but given that it is >> deviating from CRLs on the meaning of revocationTime and >> revocationReason, a separated section describing these fields should be >> added. " >>=20 >>=20 >> Peter Rybar >> National Security Authority >> Information Security and Electronic Signature Department >>=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Andris Berzins >> Sent: Thursday, January 03, 2013 1:02 PM >> To: Santosh Chokhani >> Cc: pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included in >> one CRL issued beyond certificate validity period >>=20 >> OK. Let's assume situation where end entity requests certificate to be >> revoked, but next CRL will be published only >> after this currently valid certificate will be expired. >>=20 >> Very interesting situation. So the goal of rfc5280 is to archive the fac= t >> that it was revoked before it expired on at >> least one published CRL. >>=20 >> But does it make sense? >>=20 >> Let's assume that relying party checked freshest CRL and concluded that >> presented certificate is valid (although >> CA already received revocation request). So the relying party did some >> damaging actions by the request of end >> entity. Does this feature, that end entity can proof that its cert was >> revoked before it expired, makes relying party >> to rollback that transaction although relying party checked CRL at that >> time correctly? >>=20 >> Perhaps I can generalize the question. >> Is relying party obligated to take the risk that although current CRL >> says that cert is not revoked, the next published >> CRL can tell that at that time revocation request was already received= =2E >> Or is end entity liable and has to take risk that even if revocation is >> requested now, the revocation will take legal >> effect only after CA's CRL's nextUpdate date is reached? >>=20 >>=20 >>=20 >> Quoting "Santosh Chokhani" : >>> Andris, >>>=20 >>> The rationale behind this is to provide for archive and future >>> verification >>> (e.g., for non-repudiation purposes) for . >>>=20 >>> Let us make the following assumptions: >>>=20 >>>=20 >>> 1. The CRLs are the official archive. >>>=20 >>> 2. Delta CRLs are not the official archive >>>=20 >>> 3. A new CRL Y can be built using the previous CRL X and a delta >>> issued >>> when Y is issued. >>>=20 >>> In that case, you want a certificate on at least one CRL and maintain >>> on del >>> ta until it is recorded in a CRL that is archived. >>>=20 >>> 5280 language is unnecessarily constraining. It should state, =C2=B3ex= pired >>> cert >>> ificates shall be removed from the CRL, except a revoked certificate >>> shall a >>> ppear on at least one CRL. >>>=20 >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Andr >>> is Berzins >>> Sent: Thursday, December 27, 2012 3:06 PM >>> To: pkix@ietf.org >>> Subject: [pkix] why revoked certificate entry has to be included in one >>> CRL >>> issued beyond certificate validity period >>>=20 >>> rfc5280 states: >>>=20 >>> "An entry MUST NOT be removed >>> from the CRL until it appears on one regularly scheduled CRL issued >>> beyond the revoked certificate's validity period." >>>=20 >>> and >>>=20 >>> "If a certificate revocation notice first appears on a delta CRL, then >>> it is possible for the certificate validity period to expire before >>> the next complete CRL for the same scope is issued. In this case, >>> the revocation notice MUST be included in all subsequent delta CRLs >>> until the revocation notice is included on at least one explicitly >>> issued complete CRL for this scope." >>>=20 >>> Why is that required? >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Thu Jan 3 06:39:42 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 4485A21E8047 for ; Thu, 3 Jan 2013 06:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_FROM=2.3, 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 BV+ssLNtNa9R for ; Thu, 3 Jan 2013 06:39:41 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF221E8053 for ; Thu, 3 Jan 2013 06:39:41 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 738761CEE5 for ; Thu, 3 Jan 2013 15:39:40 +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 2013010315394012-53516 ; Thu, 3 Jan 2013 15:39:40 +0100 Message-ID: <50E59827.6010908@bull.net> Date: Thu, 03 Jan 2013 15:39:35 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <1357220945.50e58c51cacff@mail.inbox.lv> <195DB2510AAA004391F58E28FCE21200066FF00B@IMCMBX01.MITRE.ORG> <1357222925.50e5940d206a9@mail.inbox.lv> In-Reply-To: <1357222925.50e5940d206a9@mail.inbox.lv> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 03/01/2013 15:39:40, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 03/01/2013 15:39:40, Serialize complete at 03/01/2013 15:39:40 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Thu, 03 Jan 2013 14:39:42 -0000 Andris, Depending upon the kind of transaction, you can apply a grace period or not. If you do not apply a grace period, you need to accept a risk. If you apply a grace period, you don't take the risk, but you must wait until the end of the grace period to validate the transaction (i.e. the signature). For details about the grace period; see, for example, ETSI TS 101 903 (pages 19 and 20). Denis > Quoting "Miller, Timothy J." : >>> Nice. So what the relying party should do? If the relying party checks CRL t >>> hat >>> is current (current time between >>> thisUpdate and nextUpdate), it still risks that in next CRL revocation date >>> might be precede current time of check >>> or the court will rule that real revocation was much earlier and thus relyin >>> g >>> party has to take losses? >> You can only act on what you know at the time you need to act. What happens >> in a dispute is up to the judge at the time of the dispute--which is in the >> future--so isn't part of that calculus. The situation is analogous to an i >> n-person fraud committed by a con-man with forged corporate endorsements; th >> e defrauded party is entitled to recoup losses, but whether he can recoup fr >> om the misrepresented corporation depends on the specific facts of the case >> (e.g., if there was negligence or complicity). >> >> -- T > What would you recommend for relying party? Is it safe to execute transaction after checking cert validity in CRL > who's thisUpdate is current and nextUpdate is in future? Or am I still at risk that in next CRL CA can declare that > certificate at that time was already revoked and I might have to recoup losses? > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From prvs=0715c7051b=rybar@nbusr.sk Thu Jan 3 06:49:29 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 05F7521F8A91 for ; Thu, 3 Jan 2013 06:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 244GbqTSG9Qu for ; Thu, 3 Jan 2013 06:49:28 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id BEA2B21F8A6C for ; Thu, 3 Jan 2013 06:49:27 -0800 (PST) Message-Id: <201301031449.r03EnNFu033604@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , "'Andris Berzins'" , "'Santosh Chokhani'" Date: Thu, 3 Jan 2013 15:49:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac3pvm+oJ88SSKWQTxG30BOd0vgQEwAARpaA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4450> : streams <885988> : uri <1310015> Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 14:49:29 -0000 OK, The compromise date will be earlier than is the date in the revocationDate field of CRL e.g. according to judgement in court. Revocation date is only ONE value (when is used only in CRL), but is it = really the same time value of revocation in CRL (revocationDate) and = also in OCSP (revocationTime)? As was indicated, OCSP definition in RFC is not precise about the value = of revocationTime when also revocationDate of CRL is used. Peter -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, January 03, 2013 3:27 PM To: Peter Rybar; 'Andris Berzins'; 'Santosh Chokhani' Cc: pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period Peter, I think you are mixing up the terminology. There is only one revocation date. Whether you can convince the court that you did not use your private key at some event is another thing. They will look at all facts of the case, technical and non-technical. /Stefan On 1/3/13 2:13 PM, "Peter Rybar" wrote: >Andris, > >For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not = used. >Validation is based only on information whose status is stable and was >already finished in the past. > >Only thisUpdate date of CRL is used for non-repudiation purposes. > >The date on which the revocation occurred is specified in = revocationDate >field of CRL but the real e.g. compromise was earlier than is the time >value in revocationDate. The revocationDate of a CRL does not give you >the real time when a certificate was revoked but the revocationDate is >the START of the interval since when a certificate is to be invalid >according to signed evidence created by CA. > >The real revocation date will be earlier than is the date in the >revocationDate field of CRL e.g. according to judgement in court. > >And as was it clarified by Piyush in thread 2560bis: >"according to 5280, revocationDate cannot precede thisUpdate of an >earlier CRL if the revocation for the certificate is being reported the >first time. > >Not saying that OCSP has to follow these rules, but given that it is >deviating from CRLs on the meaning of revocationTime and >revocationReason, a separated section describing these fields should be >added. " > >=20 >Peter Rybar >National Security Authority >Information Security and Electronic Signature Department > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Andris Berzins >Sent: Thursday, January 03, 2013 1:02 PM >To: Santosh Chokhani >Cc: pkix@ietf.org >Subject: Re: [pkix] why revoked certificate entry has to be included in >one CRL issued beyond certificate validity period > >OK. Let's assume situation where end entity requests certificate to be >revoked, but next CRL will be published only >after this currently valid certificate will be expired. > >Very interesting situation. So the goal of rfc5280 is to archive the = fact >that it was revoked before it expired on at >least one published CRL. > >But does it make sense? > >Let's assume that relying party checked freshest CRL and concluded that >presented certificate is valid (although >CA already received revocation request). So the relying party did some >damaging actions by the request of end >entity. Does this feature, that end entity can proof that its cert was >revoked before it expired, makes relying party >to rollback that transaction although relying party checked CRL at that >time correctly? > >Perhaps I can generalize the question. >Is relying party obligated to take the risk that although current CRL >says that cert is not revoked, the next published >CRL can tell that at that time revocation request was already received. >Or is end entity liable and has to take risk that even if revocation is >requested now, the revocation will take legal >effect only after CA's CRL's nextUpdate date is reached? > > > >Quoting "Santosh Chokhani" : >> Andris, >>=20 >> The rationale behind this is to provide for archive and future >>verification=20 >>(e.g., for non-repudiation purposes) for . >>=20 >> Let us make the following assumptions: >>=20 >>=20 >> 1. The CRLs are the official archive. >>=20 >> 2. Delta CRLs are not the official archive >>=20 >> 3. A new CRL Y can be built using the previous CRL X and a delta >>issued=20 >>when Y is issued. >>=20 >> In that case, you want a certificate on at least one CRL and maintain >>on del >>ta until it is recorded in a CRL that is archived. >>=20 >> 5280 language is unnecessarily constraining. It should state, = =C2=B3expired >>cert >>ificates shall be removed from the CRL, except a revoked certificate >>shall a >>ppear on at least one CRL. >>=20 >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>Andr >>is Berzins >> Sent: Thursday, December 27, 2012 3:06 PM >> To: pkix@ietf.org >> Subject: [pkix] why revoked certificate entry has to be included in = one >>CRL=20 >>issued beyond certificate validity period >>=20 >> rfc5280 states: >>=20 >> "An entry MUST NOT be removed >> from the CRL until it appears on one regularly scheduled CRL issued >> beyond the revoked certificate's validity period." >>=20 >> and >>=20 >> "If a certificate revocation notice first appears on a delta CRL, = then >> it is possible for the certificate validity period to expire before >> the next complete CRL for the same scope is issued. In this case, >> the revocation notice MUST be included in all subsequent delta CRLs >> until the revocation notice is included on at least one explicitly >> issued complete CRL for this scope." >>=20 >> Why is that required? > >_______________________________________________ >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 prvs=0715c7051b=rybar@nbusr.sk Thu Jan 3 07:07:09 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 829C721E8047 for ; Thu, 3 Jan 2013 07:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 ww-rK4Tb+WBQ for ; Thu, 3 Jan 2013 07:07:08 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 333D421F8C06 for ; Thu, 3 Jan 2013 07:07:08 -0800 (PST) Message-Id: <201301031507.r03F76bQ033657@mail.nbusr.sk> From: "Peter Rybar" To: "'Andris Berzins'" , "'Stefan Santesson'" Date: Thu, 3 Jan 2013 16:07:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1357223792.50e59770b535d@mail.inbox.lv> Thread-Index: Ac3pv74K8OYm9OTHS56b4t+gkFJrKAAAmN6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4450> : streams <885995> : uri <1310033> Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 15:07:09 -0000 > Nice. So what the relying party should do? Wait for CRL or for OCSP where the time included in thisUpdate field is = after the time to which the validation is expected (time-stamp or audit = trail). It means the grace period (mentioned by Denis) is dynamic and was = finished in the time when the time value in thisUpdate of CRL/OCSP was = greater than the time to which you validate the certificate. Some documents are at address: http://www.nbusr.sk/en/electronic-signature/verification.1.html Certificate Path Validation (pdf, 354.4 kB) http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiva/kontrola_cert_cesty_en.pdf=20 Peter Rybar -----Original Message----- From: Andris Berzins [mailto:pkix@inbox.lv]=20 Sent: Thursday, January 03, 2013 3:37 PM To: Stefan Santesson Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period If talking about courts, are there any case studies available or known = cases? > On 1/3/13 2:13 PM, "Peter Rybar" wrote: >=20 >> Andris, >>=20 >> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not = used. >> Validation is based only on information whose status is stable and = was >> already finished in the past. >>=20 >> Only thisUpdate date of CRL is used for non-repudiation purposes. >>=20 >> The date on which the revocation occurred is specified in = revocationDate >> field of CRL but the real e.g. compromise was earlier than is the = time >> value in revocationDate. The revocationDate of a CRL does not give = you >> the real time when a certificate was revoked but the revocationDate = is >> the START of the interval since when a certificate is to be invalid >> according to signed evidence created by CA. >>=20 >> The real revocation date will be earlier than is the date in the >> revocationDate field of CRL e.g. according to judgement in court. >>=20 >> And as was it clarified by Piyush in thread 2560bis: >> "according to 5280, revocationDate cannot precede thisUpdate of an >> earlier CRL if the revocation for the certificate is being reported = the >> first time. >>=20 >> Not saying that OCSP has to follow these rules, but given that it is >> deviating from CRLs on the meaning of revocationTime and >> revocationReason, a separated section describing these fields should = be >> added. " >>=20 >>=20 >> Peter Rybar >> National Security Authority >> Information Security and Electronic Signature Department >>=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >> Andris Berzins >> Sent: Thursday, January 03, 2013 1:02 PM >> To: Santosh Chokhani >> Cc: pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included = in >> one CRL issued beyond certificate validity period >>=20 >> OK. Let's assume situation where end entity requests certificate to = be >> revoked, but next CRL will be published only >> after this currently valid certificate will be expired. >>=20 >> Very interesting situation. So the goal of rfc5280 is to archive the = fact >> that it was revoked before it expired on at >> least one published CRL. >>=20 >> But does it make sense? >>=20 >> Let's assume that relying party checked freshest CRL and concluded = that >> presented certificate is valid (although >> CA already received revocation request). So the relying party did = some >> damaging actions by the request of end >> entity. Does this feature, that end entity can proof that its cert = was >> revoked before it expired, makes relying party >> to rollback that transaction although relying party checked CRL at = that >> time correctly? >>=20 >> Perhaps I can generalize the question. >> Is relying party obligated to take the risk that although current CRL >> says that cert is not revoked, the next published >> CRL can tell that at that time revocation request was already = received. >> Or is end entity liable and has to take risk that even if revocation = is >> requested now, the revocation will take legal >> effect only after CA's CRL's nextUpdate date is reached? >>=20 >>=20 >>=20 >> Quoting "Santosh Chokhani" : >>> Andris, >>>=20 >>> The rationale behind this is to provide for archive and future >>> verification >>> (e.g., for non-repudiation purposes) for . >>>=20 >>> Let us make the following assumptions: >>>=20 >>>=20 >>> 1. The CRLs are the official archive. >>>=20 >>> 2. Delta CRLs are not the official archive >>>=20 >>> 3. A new CRL Y can be built using the previous CRL X and a delta >>> issued >>> when Y is issued. >>>=20 >>> In that case, you want a certificate on at least one CRL and = maintain >>> on del >>> ta until it is recorded in a CRL that is archived. >>>=20 >>> 5280 language is unnecessarily constraining. It should state, = =C2=B3expired >>> cert >>> ificates shall be removed from the CRL, except a revoked certificate >>> shall a >>> ppear on at least one CRL. >>>=20 >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>> Andr >>> is Berzins >>> Sent: Thursday, December 27, 2012 3:06 PM >>> To: pkix@ietf.org >>> Subject: [pkix] why revoked certificate entry has to be included in = one >>> CRL >>> issued beyond certificate validity period >>>=20 >>> rfc5280 states: >>>=20 >>> "An entry MUST NOT be removed >>> from the CRL until it appears on one regularly scheduled CRL issued >>> beyond the revoked certificate's validity period." >>>=20 >>> and >>>=20 >>> "If a certificate revocation notice first appears on a delta CRL, = then >>> it is possible for the certificate validity period to expire before >>> the next complete CRL for the same scope is issued. In this case, >>> the revocation notice MUST be included in all subsequent delta CRLs >>> until the revocation notice is included on at least one explicitly >>> issued complete CRL for this scope." >>>=20 >>> Why is that required? >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Thu Jan 3 07:36: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 8387621F8CB5 for ; Thu, 3 Jan 2013 07:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.349, 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 QLbqlwEX507O for ; Thu, 3 Jan 2013 07:36:59 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF121F8CB4 for ; Thu, 3 Jan 2013 07:36:58 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DF8691DEB6DF for ; Thu, 3 Jan 2013 16:36:52 +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 7KO8JGXkN1ej for ; Thu, 3 Jan 2013 16:36:52 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A98151E00380 for ; Thu, 3 Jan 2013 16:36:52 +0100 (CET) Received: (qmail 56845 invoked from network); 3 Jan 2013 15:36:52 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Jan 2013 15:36:52 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 03 Jan 2013 16:36:52 +0100 From: Stefan Santesson To: Andris Berzins , Peter Rybar Message-ID: Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period In-Reply-To: <1357220945.50e58c51cacff@mail.inbox.lv> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org 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: Thu, 03 Jan 2013 15:36:59 -0000 On 1/3/13 2:49 PM, "Andris Berzins" wrote: >Nice. So what the relying party should do? Realize that we are not living in a perfect world. Evaluate the risk vs. the benefits from using this imperfect technology and make a reasonable decision. /Stefan From htodorov@axway.com Thu Jan 3 09:55:09 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 8E7C921F86AA for ; Thu, 3 Jan 2013 09:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[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 j74P1YaJkJfu for ; Thu, 3 Jan 2013 09:55:08 -0800 (PST) Received: from messenger2-phx.axway.net (smtp2.axway.net [208.67.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id E959D21F868B for ; Thu, 3 Jan 2013 09:55:04 -0800 (PST) X-WSS-ID: 0MG29RR-24-1JZ-02 X-M-MSG: Received: from WPHXCAS1.phx.axway.int (unknown [10.129.17.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by messenger2-phx.axway.net (Postfix) with ESMTPS id 2EF5C5F14C9 for ; Thu, 3 Jan 2013 10:55:02 -0700 (MST) Received: from WPHXMAIL1.phx.axway.int ([::1]) by WPHXCAS1.phx.axway.int ([::1]) with mapi id 14.02.0328.005; Thu, 3 Jan 2013 10:55:36 -0700 From: Hristo Todorov To: "pkix@ietf.org" Thread-Topic: time stamp verification for non repudiation (in Windows) Thread-Index: Ac3p24fNBHvjoO0YT7exR+tt/ed35Q== Date: Thu, 3 Jan 2013 17:56:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.13.115] Content-Type: multipart/alternative; boundary="_000_F725AFA617E4AE4193BEB1C8777D44E81DA705E2WPHXMAIL1phxaxw_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 03 Jan 2013 10:02:21 -0800 Subject: [pkix] time stamp verification for non repudiation (in Windows) 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, 03 Jan 2013 17:56:18 -0000 --_000_F725AFA617E4AE4193BEB1C8777D44E81DA705E2WPHXMAIL1phxaxw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This question is somewhat related to information Peter Rybar provided sever= al hours ago in the thread: why revoked certificate entry has to be include= d in one CRL issued beyond certificate validity period "The date on which the revocation occurred is specified in revocationDate f= ield of CRL but the real e.g. compromise was earlier than is the time value= in revocationDate. The revocationDate of a CRL does not give you the real = time when a certificate was revoked but the revocationDate is the START of = the interval since when a certificate is to be invalid according to signed = evidence created by CA. The real revocation date will be earlier than is the date in the revocation= Date field of CRL e.g. according to judgement in court." I am wondering how this is to be treated in light of RFC 3161, especially a= ppendix B (where it would be the judgment of the software, not of the court= ). In particular Windows verifies a timestamp by calling a revocation provider= with a call including a past time stamp. As MSDN iterates on http://msdn.m= icrosoft.com/en-us/library/aa377524.aspx pftTimeToUse : " A pointer to a FILETIME version of UTC time. When specifie= d, the handler must, if possible, determine revocation status relative to t= he time given. If NULL or the handler cannot determine the status relative = to the pftTimeToUse value, revocation status can be determined independent = of time or relative to current time." This would seem to indicate that revocation checking on windows should retu= rn a good!? status of the time specified above is before revocationDate in = the CRL, but as indicated in the previous thread, this is unreliable as the= actual key compromise time, hence validation of the past signature with a = certificate now revoked seems to be somewhat questionable. Why is then Inva= lidityDate an optional CRL entry extension? What are the reliable inputs to= RFC 3161, appendix B, B6? On a separate note, why is MS expecting a revocation provider to return goo= d status in the case when ftTimeToUse < revocationDate and is that not, n= ot following the spirit of 3161, Appendix B, B 5 and B 6? Thanks in advance, Hristo --_000_F725AFA617E4AE4193BEB1C8777D44E81DA705E2WPHXMAIL1phxaxw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This question is somewhat related to information Pet= er Rybar provided several hours ago in the thread: why revoked certificate = entry has to be included in one CRL issued beyond certificate validity peri= od

 

“The date = on which the revocation occurred is specified in revocationDate field of CR= L but the real e.g. compromise was earlier than is the time value in revoca= tionDate. The revocationDate of a CRL does not give you the real time when a certificate was revoked but the revocati= onDate is the START of the interval since when a certificate is to be inval= id according to signed evidence created by CA.

 

The real revoca= tion date will be earlier than is the date in the revocationDate field of C= RL e.g. according to judgement in court.”

 

I am wondering how this is to be treated in light of= RFC 3161, especially appendix B (where it would be the judgment of the sof= tware, not of the court).

 

In particular Windows verifies a timestamp by callin= g a revocation provider with a call including a past time stamp. As MSDN it= erates on http://ms= dn.microsoft.com/en-us/library/aa377524.aspx

pftTimeToUse : " A pointer to a= FILETIME version of UTC time. When specified, the handler must, if possibl= e, determine revocation status relative to the time given. If NULL or the handler cannot determine the status relative to the pftTimeToU= se value, revocation status can be determined independent of time or relati= ve to current time."

 

This would seem to indicate that revocation checking on w=
indows should return a good!? status of the time specified above is before =
revocationDate in the CRL, but as indicated in the prev=
ious thread, this is unreliable as the actual key compromise time, hence va=
lidation of the past signature with a certificate now revoked seems to be s=
omewhat questionable. Why is then InvalidityDate an opt=
ional CRL entry extension? What are the reliable inputs to RFC 3161, append=
ix B, B6?
 

On a separate note, why is MS expect= ing a revocation provider to return good status in the case when  ftTi= meToUse < revocationDate and is that not,  not following the spirit of 3161, Appendix B, B 5 an= d B 6?

 

Thanks in advance,

Hristo

--_000_F725AFA617E4AE4193BEB1C8777D44E81DA705E2WPHXMAIL1phxaxw_-- From pkix@inbox.lv Thu Jan 3 11:10: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 63F0E21F8D2A for ; Thu, 3 Jan 2013 11:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc0CPZy7VrdY for ; Thu, 3 Jan 2013 11:10:24 -0800 (PST) Received: from shark2.inbox.lv (shark2.inbox.lv [89.111.3.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9881B21F8D1A for ; Thu, 3 Jan 2013 11:10:23 -0800 (PST) Received: by shark2.inbox.lv (Postfix, from userid 1000) id 37E4CD66A; Thu, 3 Jan 2013 21:10:17 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark2-plain-b64d2.inbox.lv (Postfix) with ESMTP id 04182D65B; Thu, 3 Jan 2013 21:10:17 +0200 (EET) Received: from localhost ([10.0.1.21]) by localhost (shark2.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id 8ohqhwO3ve0A; Thu, 3 Jan 2013 21:10:11 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 03 Jan 2013 21:10:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w11.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357240211.50e5d7938ca92@mail.inbox.lv> Date: Thu, 03 Jan 2013 21:10:11 +0200 From: "Andris Berzins" To: "Peter Rybar" References: <1357223792.50e59770b535d@mail.inbox.lv> <201301031507.r03F76Xu033658@mail.nbusr.sk> In-Reply-To: <201301031507.r03F76Xu033658@mail.nbusr.sk> User-Agent: Inbox.lv Webmail Cc: 'Stefan Santesson' , pkix@ietf.org 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: Thu, 03 Jan 2013 19:10:26 -0000 Quoting "Peter Rybar" : >> Nice. So what the relying party should do? >=20 > Wait for CRL or for OCSP where the time included in thisUpdate field is a= fte >r the time to which the validation is expected (time-stamp or audit trail)= =2E >=20 > It means the grace period (mentioned by Denis) is dynamic and was finishe= d i >n the time when the time value in thisUpdate of CRL/OCSP was greater than = th >e time to which you validate the certificate. Greater than is not enough. Relying party is supposed to get next published= CRL or else if any of CRLs published=20 are missed then: 1. Certificate could have been revoked short before expiration and relying = party missed that single published CRL=20 beyond certificate expiration. 2. Certificate could have been "on hold" and now is released. Without parsi= ng all published CRLs relying party can=20 not detect this. By the same analogy this grace period approach should be applied to whole p= ath not only on end entity certificate.=20 For example, if root CA publishes CRL for intermediate CA's once in 3 month= , then grace period has to be 3 month=20 or else relying party takes a risk? >=20 > Some documents are at address: > http://www.nbusr.sk/en/electronic-signature/verification.1.html >=20 > Certificate Path Validation (pdf, 354.4 kB) > http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiv >a/kontrola_cert_cesty_en.pdf >=20 > Peter Rybar >=20 > -----Original Message----- > From: Andris Berzins [mailto:pkix@inbox.lv] > Sent: Thursday, January 03, 2013 3:37 PM > To: Stefan Santesson > Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org > Subject: Re: [pkix] why revoked certificate entry has to be included in o= ne=20 >CRL issued beyond certificate validity period >=20 > If talking about courts, are there any case studies available or known ca= ses >? >=20 >> On 1/3/13 2:13 PM, "Peter Rybar" wrote: >>=20 >>> Andris, >>>=20 >>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not us= ed. >>> Validation is based only on information whose status is stable and was >>> already finished in the past. >>>=20 >>> Only thisUpdate date of CRL is used for non-repudiation purposes. >>>=20 >>> The date on which the revocation occurred is specified in revocationDat= e >>> field of CRL but the real e.g. compromise was earlier than is the time >>> value in revocationDate. The revocationDate of a CRL does not give you >>> the real time when a certificate was revoked but the revocationDate is >>> the START of the interval since when a certificate is to be invalid >>> according to signed evidence created by CA. >>>=20 >>> The real revocation date will be earlier than is the date in the >>> revocationDate field of CRL e.g. according to judgement in court. >>>=20 >>> And as was it clarified by Piyush in thread 2560bis: >>> "according to 5280, revocationDate cannot precede thisUpdate of an >>> earlier CRL if the revocation for the certificate is being reported the >>> first time. >>>=20 >>> Not saying that OCSP has to follow these rules, but given that it is >>> deviating from CRLs on the meaning of revocationTime and >>> revocationReason, a separated section describing these fields should be >>> added. " >>>=20 >>>=20 >>> Peter Rybar >>> National Security Authority >>> Information Security and Electronic Signature Department >>>=20 >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Andris Berzins >>> Sent: Thursday, January 03, 2013 1:02 PM >>> To: Santosh Chokhani >>> Cc: pkix@ietf.org >>> Subject: Re: [pkix] why revoked certificate entry has to be included in >>> one CRL issued beyond certificate validity period >>>=20 >>> OK. Let's assume situation where end entity requests certificate to be >>> revoked, but next CRL will be published only >>> after this currently valid certificate will be expired. >>>=20 >>> Very interesting situation. So the goal of rfc5280 is to archive the fa= ct >>> that it was revoked before it expired on at >>> least one published CRL. >>>=20 >>> But does it make sense? >>>=20 >>> Let's assume that relying party checked freshest CRL and concluded that >>> presented certificate is valid (although >>> CA already received revocation request). So the relying party did some >>> damaging actions by the request of end >>> entity. Does this feature, that end entity can proof that its cert was >>> revoked before it expired, makes relying party >>> to rollback that transaction although relying party checked CRL at that >>> time correctly? >>>=20 >>> Perhaps I can generalize the question. >>> Is relying party obligated to take the risk that although current CRL >>> says that cert is not revoked, the next published >>> CRL can tell that at that time revocation request was already received= =2E >>> Or is end entity liable and has to take risk that even if revocation is >>> requested now, the revocation will take legal >>> effect only after CA's CRL's nextUpdate date is reached? >>>=20 >>>=20 >>>=20 >>> Quoting "Santosh Chokhani" : >>>> Andris, >>>>=20 >>>> The rationale behind this is to provide for archive and future >>>> verification >>>> (e.g., for non-repudiation purposes) for . >>>>=20 >>>> Let us make the following assumptions: >>>>=20 >>>>=20 >>>> 1. The CRLs are the official archive. >>>>=20 >>>> 2. Delta CRLs are not the official archive >>>>=20 >>>> 3. A new CRL Y can be built using the previous CRL X and a delta >>>> issued >>>> when Y is issued. >>>>=20 >>>> In that case, you want a certificate on at least one CRL and maintain >>>> on del >>>> ta until it is recorded in a CRL that is archived. >>>>=20 >>>> 5280 language is unnecessarily constraining. It should state, =C2=B3e= xpired >>>> cert >>>> ificates shall be removed from the CRL, except a revoked certificate >>>> shall a >>>> ppear on at least one CRL. >>>>=20 >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> Andr >>>> is Berzins >>>> Sent: Thursday, December 27, 2012 3:06 PM >>>> To: pkix@ietf.org >>>> Subject: [pkix] why revoked certificate entry has to be included in on= e >>>> CRL >>>> issued beyond certificate validity period >>>>=20 >>>> rfc5280 states: >>>>=20 >>>> "An entry MUST NOT be removed >>>> from the CRL until it appears on one regularly scheduled CRL issued >>>> beyond the revoked certificate's validity period." >>>>=20 >>>> and >>>>=20 >>>> "If a certificate revocation notice first appears on a delta CRL, then >>>> it is possible for the certificate validity period to expire before >>>> the next complete CRL for the same scope is issued. In this case, >>>> the revocation notice MUST be included in all subsequent delta CRLs >>>> until the revocation notice is included on at least one explicitly >>>> issued complete CRL for this scope." >>>>=20 >>>> Why is that required? >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Jan 4 00:46: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 A580121F853D for ; Fri, 4 Jan 2013 00:46:46 -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=[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 dfS84aIPoVz2 for ; Fri, 4 Jan 2013 00:46:45 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id A89C521F8526 for ; Fri, 4 Jan 2013 00:46:44 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 2AAE11CEA7 for ; Fri, 4 Jan 2013 09:46:43 +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 2013010409464246-54944 ; Fri, 4 Jan 2013 09:46:42 +0100 Message-ID: <50E696EF.5000203@bull.net> Date: Fri, 04 Jan 2013 09:46:39 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <1357223792.50e59770b535d@mail.inbox.lv> <201301031507.r03F76Xu033658@mail.nbusr.sk> <1357240211.50e5d7938ca92@mail.inbox.lv> In-Reply-To: <1357240211.50e5d7938ca92@mail.inbox.lv> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/01/2013 09:46:42, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/01/2013 09:46:43, Serialize complete at 04/01/2013 09:46:43 X-TNEFEvaluated: 1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Fri, 04 Jan 2013 08:46:46 -0000 Andris, The risk of a compromise or of a revocation of a signer's private key is=20 much higher that the risk of revocation of a CA. A signer's might even ask for the revocation of its certificate whereas=20 it is not justified by a stolen card and a stolen PIN. So applying an additional specific grace period for CAs does not make=20 sense. If revocation happens very close to the date contained within the=20 time-stamp token, some software might say: the signature is valid, some other will say the signature is not valid. In some=20 cases, the electronic signature may have been made by the right signer, but under constraints or under the use of drugs. So it is not because a signature is technically valid, that it cannot be=20 challenged by the signer. The same applies with manual signatures. Denis > Quoting "Peter Rybar" : >>> Nice. So what the relying party should do? >> Wait for CRL or for OCSP where the time included in thisUpdate field i= s afte >> r the time to which the validation is expected (time-stamp or audit tr= ail). >> >> It means the grace period (mentioned by Denis) is dynamic and was fini= shed i >> n the time when the time value in thisUpdate of CRL/OCSP was greater t= han th >> e time to which you validate the certificate. > Greater than is not enough. Relying party is supposed to get next publi= shed CRL or else if any of CRLs published > are missed then: > 1. Certificate could have been revoked short before expiration and rely= ing party missed that single published CRL > beyond certificate expiration. > 2. Certificate could have been "on hold" and now is released. Without p= arsing all published CRLs relying party can > not detect this. > > By the same analogy this grace period approach should be applied to who= le path not only on end entity certificate. > For example, if root CA publishes CRL for intermediate CA's once in 3 m= onth, then grace period has to be 3 month > or else relying party takes a risk? > > >> Some documents are at address: >> http://www.nbusr.sk/en/electronic-signature/verification.1.html >> >> Certificate Path Validation (pdf, 354.4 kB) >> http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legi= slativ >> a/kontrola_cert_cesty_en.pdf >> >> Peter Rybar >> >> -----Original Message----- >> From: Andris Berzins [mailto:pkix@inbox.lv] >> Sent: Thursday, January 03, 2013 3:37 PM >> To: Stefan Santesson >> Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included i= n one >> CRL issued beyond certificate validity period >> >> If talking about courts, are there any case studies available or known= cases >> ? >> >>> On 1/3/13 2:13 PM, "Peter Rybar" wrote: >>> >>>> Andris, >>>> >>>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not= used. >>>> Validation is based only on information whose status is stable and w= as >>>> already finished in the past. >>>> >>>> Only thisUpdate date of CRL is used for non-repudiation purposes. >>>> >>>> The date on which the revocation occurred is specified in revocation= Date >>>> field of CRL but the real e.g. compromise was earlier than is the ti= me >>>> value in revocationDate. The revocationDate of a CRL does not give y= ou >>>> the real time when a certificate was revoked but the revocationDate = is >>>> the START of the interval since when a certificate is to be invalid >>>> according to signed evidence created by CA. >>>> >>>> The real revocation date will be earlier than is the date in the >>>> revocationDate field of CRL e.g. according to judgement in court. >>>> >>>> And as was it clarified by Piyush in thread 2560bis: >>>> "according to 5280, revocationDate cannot precede thisUpdate of an >>>> earlier CRL if the revocation for the certificate is being reported = the >>>> first time. >>>> >>>> Not saying that OCSP has to follow these rules, but given that it is >>>> deviating from CRLs on the meaning of revocationTime and >>>> revocationReason, a separated section describing these fields should= be >>>> added. " >>>> >>>> >>>> Peter Rybar >>>> National Security Authority >>>> Information Security and Electronic Signature Department >>>> >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf= Of >>>> Andris Berzins >>>> Sent: Thursday, January 03, 2013 1:02 PM >>>> To: Santosh Chokhani >>>> Cc: pkix@ietf.org >>>> Subject: Re: [pkix] why revoked certificate entry has to be included= in >>>> one CRL issued beyond certificate validity period >>>> >>>> OK. Let's assume situation where end entity requests certificate to = be >>>> revoked, but next CRL will be published only >>>> after this currently valid certificate will be expired. >>>> >>>> Very interesting situation. So the goal of rfc5280 is to archive the= fact >>>> that it was revoked before it expired on at >>>> least one published CRL. >>>> >>>> But does it make sense? >>>> >>>> Let's assume that relying party checked freshest CRL and concluded t= hat >>>> presented certificate is valid (although >>>> CA already received revocation request). So the relying party did so= me >>>> damaging actions by the request of end >>>> entity. Does this feature, that end entity can proof that its cert = was >>>> revoked before it expired, makes relying party >>>> to rollback that transaction although relying party checked CRL at t= hat >>>> time correctly? >>>> >>>> Perhaps I can generalize the question. >>>> Is relying party obligated to take the risk that although current CR= L >>>> says that cert is not revoked, the next published >>>> CRL can tell that at that time revocation request was already receiv= ed. >>>> Or is end entity liable and has to take risk that even if revocation= is >>>> requested now, the revocation will take legal >>>> effect only after CA's CRL's nextUpdate date is reached? >>>> >>>> >>>> >>>> Quoting "Santosh Chokhani" : >>>>> Andris, >>>>> >>>>> The rationale behind this is to provide for archive and future >>>>> verification >>>>> (e.g., for non-repudiation purposes) for . >>>>> >>>>> Let us make the following assumptions: >>>>> >>>>> >>>>> 1. The CRLs are the official archive. >>>>> >>>>> 2. Delta CRLs are not the official archive >>>>> >>>>> 3. A new CRL Y can be built using the previous CRL X and a delt= a >>>>> issued >>>>> when Y is issued. >>>>> >>>>> In that case, you want a certificate on at least one CRL and mainta= in >>>>> on del >>>>> ta until it is recorded in a CRL that is archived. >>>>> >>>>> 5280 language is unnecessarily constraining. It should state, =C2=B3= expired >>>>> cert >>>>> ificates shall be removed from the CRL, except a revoked certificat= e >>>>> shall a >>>>> ppear on at least one CRL. >>>>> >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behal= f Of >>>>> Andr >>>>> is Berzins >>>>> Sent: Thursday, December 27, 2012 3:06 PM >>>>> To: pkix@ietf.org >>>>> Subject: [pkix] why revoked certificate entry has to be included in= one >>>>> CRL >>>>> issued beyond certificate validity period >>>>> >>>>> rfc5280 states: >>>>> >>>>> "An entry MUST NOT be removed >>>>> from the CRL until it appears on one regularly scheduled CRL issued >>>>> beyond the revoked certificate's validity period." >>>>> >>>>> and >>>>> >>>>> "If a certificate revocation notice first appears on a delta CRL, t= hen >>>>> it is possible for the certificate validity period to expire before >>>>> the next complete CRL for the same scope is issued. In this case, >>>>> the revocation notice MUST be included in all subsequent delta CRLs >>>>> until the revocation notice is included on at least one explicitly >>>>> issued complete CRL for this scope." >>>>> >>>>> Why is that required? >>>> _______________________________________________ >>>> 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 prvs=0716c546e9=rybar@nbusr.sk Fri Jan 4 00:52: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 ED5C721F8EC4 for ; Fri, 4 Jan 2013 00:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 LFizMZvhh3W0 for ; Fri, 4 Jan 2013 00:52:39 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 66DA821F8EC1 for ; Fri, 4 Jan 2013 00:52:38 -0800 (PST) Message-Id: <201301040852.r048qYtL036063@mail.nbusr.sk> From: "Peter Rybar" To: "'Andris Berzins'" Date: Fri, 4 Jan 2013 09:52:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1357240211.50e5d7938ca92@mail.inbox.lv> Thread-Index: Ac3p5fpQ8pN2GL8VQnyGc6QD6gQxnwAaDTbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4450> : streams <886396> : uri <1310646> Cc: 'Stefan Santesson' , pkix@ietf.org 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: Fri, 04 Jan 2013 08:52:40 -0000 > CA publishes CRL once in 3 month, then grace period has to be 3 month The maximum grace period when CA publishes CRL once in 3 month is 3 = month but CRL or OCSP response can be published also before the time = period indicated in nextUpdate. The value in nextUpdate is only a wish or presumption of CA when CA must = be able to publish and at least one CRL will be published. The nextUpdate value of OCSP indicates that OCSP service is not finished = and at least in nextUpdate period new request/response can be processed. CRL can be issued each 5 hours with nextUpdate set on 3 month. It means validation algorithm is based on the value included in = thisUpdate field.=20 The value in nextUpdate is only information for decision "how max long" = it is possible to wait but it is not included in validation conditions. The risk, as was pointed by Stefan, is when thisUpdate is before the = time to which validation is realized because OCSP or CRL issued later = can revoke certificate. The time line: thisUpdate-1, thisUpdate-2, time to which validation is = realized, thisUpdate-3, thisUpdate-4. Only CRLs/OCSPs issued with thisUpdate-3 or thisUpdate-4 time values are = stable. CRLs/OCSPs issued with thisUpdate-1 or thisUpdate-2 time values are used = with potential risk - certificate could be revoked before the time to = which validation is realized (TIME-STAMP or audit trail) in later = CRL/OCSP (this situation with such potential risk is always in on-line = services e.g. when SSL/TSL certificates are used and RFC5280 validation = algorithm is defined with such potential risk for on-line services based = on certificate usage). Peter Rybar -----Original Message----- From: Andris Berzins [mailto:pkix@inbox.lv]=20 Sent: Thursday, January 03, 2013 8:10 PM To: Peter Rybar Cc: 'Stefan Santesson'; 'Santosh Chokhani'; pkix@ietf.org Subject: RE: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period Quoting "Peter Rybar" : >> Nice. So what the relying party should do? >=20 > Wait for CRL or for OCSP where the time included in thisUpdate field = is afte >r the time to which the validation is expected (time-stamp or audit = trail). >=20 > It means the grace period (mentioned by Denis) is dynamic and was = finished i >n the time when the time value in thisUpdate of CRL/OCSP was greater = than th >e time to which you validate the certificate. Greater than is not enough. Relying party is supposed to get next = published CRL or else if any of CRLs published=20 are missed then: 1. Certificate could have been revoked short before expiration and = relying party missed that single published CRL=20 beyond certificate expiration. 2. Certificate could have been "on hold" and now is released. Without = parsing all published CRLs relying party can=20 not detect this. By the same analogy this grace period approach should be applied to = whole path not only on end entity certificate.=20 For example, if root CA publishes CRL for intermediate CA's once in 3 = month, then grace period has to be 3 month=20 or else relying party takes a risk? >=20 > Some documents are at address: > http://www.nbusr.sk/en/electronic-signature/verification.1.html >=20 > Certificate Path Validation (pdf, 354.4 kB) > = http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiv >a/kontrola_cert_cesty_en.pdf >=20 > Peter Rybar >=20 > -----Original Message----- > From: Andris Berzins [mailto:pkix@inbox.lv] > Sent: Thursday, January 03, 2013 3:37 PM > To: Stefan Santesson > Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org > Subject: Re: [pkix] why revoked certificate entry has to be included = in one=20 >CRL issued beyond certificate validity period >=20 > If talking about courts, are there any case studies available or known = cases >? >=20 >> On 1/3/13 2:13 PM, "Peter Rybar" wrote: >>=20 >>> Andris, >>>=20 >>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not = used. >>> Validation is based only on information whose status is stable and = was >>> already finished in the past. >>>=20 >>> Only thisUpdate date of CRL is used for non-repudiation purposes. >>>=20 >>> The date on which the revocation occurred is specified in = revocationDate >>> field of CRL but the real e.g. compromise was earlier than is the = time >>> value in revocationDate. The revocationDate of a CRL does not give = you >>> the real time when a certificate was revoked but the revocationDate = is >>> the START of the interval since when a certificate is to be invalid >>> according to signed evidence created by CA. >>>=20 >>> The real revocation date will be earlier than is the date in the >>> revocationDate field of CRL e.g. according to judgement in court. >>>=20 >>> And as was it clarified by Piyush in thread 2560bis: >>> "according to 5280, revocationDate cannot precede thisUpdate of an >>> earlier CRL if the revocation for the certificate is being reported = the >>> first time. >>>=20 >>> Not saying that OCSP has to follow these rules, but given that it is >>> deviating from CRLs on the meaning of revocationTime and >>> revocationReason, a separated section describing these fields should = be >>> added. " >>>=20 >>>=20 >>> Peter Rybar >>> National Security Authority >>> Information Security and Electronic Signature Department >>>=20 >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>> Andris Berzins >>> Sent: Thursday, January 03, 2013 1:02 PM >>> To: Santosh Chokhani >>> Cc: pkix@ietf.org >>> Subject: Re: [pkix] why revoked certificate entry has to be included = in >>> one CRL issued beyond certificate validity period >>>=20 >>> OK. Let's assume situation where end entity requests certificate to = be >>> revoked, but next CRL will be published only >>> after this currently valid certificate will be expired. >>>=20 >>> Very interesting situation. So the goal of rfc5280 is to archive the = fact >>> that it was revoked before it expired on at >>> least one published CRL. >>>=20 >>> But does it make sense? >>>=20 >>> Let's assume that relying party checked freshest CRL and concluded = that >>> presented certificate is valid (although >>> CA already received revocation request). So the relying party did = some >>> damaging actions by the request of end >>> entity. Does this feature, that end entity can proof that its cert = was >>> revoked before it expired, makes relying party >>> to rollback that transaction although relying party checked CRL at = that >>> time correctly? >>>=20 >>> Perhaps I can generalize the question. >>> Is relying party obligated to take the risk that although current = CRL >>> says that cert is not revoked, the next published >>> CRL can tell that at that time revocation request was already = received. >>> Or is end entity liable and has to take risk that even if revocation = is >>> requested now, the revocation will take legal >>> effect only after CA's CRL's nextUpdate date is reached? >>>=20 >>>=20 >>>=20 >>> Quoting "Santosh Chokhani" : >>>> Andris, >>>>=20 >>>> The rationale behind this is to provide for archive and future >>>> verification >>>> (e.g., for non-repudiation purposes) for . >>>>=20 >>>> Let us make the following assumptions: >>>>=20 >>>>=20 >>>> 1. The CRLs are the official archive. >>>>=20 >>>> 2. Delta CRLs are not the official archive >>>>=20 >>>> 3. A new CRL Y can be built using the previous CRL X and a = delta >>>> issued >>>> when Y is issued. >>>>=20 >>>> In that case, you want a certificate on at least one CRL and = maintain >>>> on del >>>> ta until it is recorded in a CRL that is archived. >>>>=20 >>>> 5280 language is unnecessarily constraining. It should state, = =C2=B3expired >>>> cert >>>> ificates shall be removed from the CRL, except a revoked = certificate >>>> shall a >>>> ppear on at least one CRL. >>>>=20 >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf Of >>>> Andr >>>> is Berzins >>>> Sent: Thursday, December 27, 2012 3:06 PM >>>> To: pkix@ietf.org >>>> Subject: [pkix] why revoked certificate entry has to be included in = one >>>> CRL >>>> issued beyond certificate validity period >>>>=20 >>>> rfc5280 states: >>>>=20 >>>> "An entry MUST NOT be removed >>>> from the CRL until it appears on one regularly scheduled CRL issued >>>> beyond the revoked certificate's validity period." >>>>=20 >>>> and >>>>=20 >>>> "If a certificate revocation notice first appears on a delta CRL, = then >>>> it is possible for the certificate validity period to expire before >>>> the next complete CRL for the same scope is issued. In this case, >>>> the revocation notice MUST be included in all subsequent delta CRLs >>>> until the revocation notice is included on at least one explicitly >>>> issued complete CRL for this scope." >>>>=20 >>>> Why is that required? >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix From prvs=0716c546e9=rybar@nbusr.sk Fri Jan 4 01:42: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 0DA0E21F8EC7 for ; Fri, 4 Jan 2013 01:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 hiBPiS3FL5dz for ; Fri, 4 Jan 2013 01:42:58 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD221F8AF4 for ; Fri, 4 Jan 2013 01:42:57 -0800 (PST) Message-Id: <201301040942.r049gtUD036273@mail.nbusr.sk> From: "Peter Rybar" To: pkix@ietf.org Date: Fri, 4 Jan 2013 10:43:00 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CDEA68.44864140" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac3p24fNBHvjoO0YT7exR+tt/ed35QAgfuJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4450> : streams <886402> : uri <1310674> Subject: Re: [pkix] time stamp verification for non repudiation (in Windows) 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, 04 Jan 2013 09:42:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CDEA68.44864140 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good observation FRC 3161, Appendix B, B 5 and B 6 "B) The validity of the digital signature may then be verified in the following way: 5) The revocation information about that certificate, at the date/time of the Time-Stamping operation, MUST be retrieved. 6) Should the certificate be revoked, then the date/time of revocation shall be later than the date/time indicated by the TSA. " Probably =E2=80=9Cshall be later=E2=80=9D must be replaced with = =E2=80=9Cshall be before=E2=80=9D in sentence B 6. The sentence with =E2=80=9Cshall be later=E2=80=9D is about the = situations when the signature is valid with revoked certificate where = the revocation is later then the time when the signature was = time-stamped. =20 Peter Rybar =20 _____ =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Hristo Todorov Sent: Thursday, January 03, 2013 6:56 PM To: pkix@ietf.org Subject: [pkix] time stamp verification for non repudiation (in Windows) =20 Hi all, =20 This question is somewhat related to information Peter Rybar provided = several hours ago in the thread: why revoked certificate entry has to be = included in one CRL issued beyond certificate validity period =20 =E2=80=9CThe date on which the revocation occurred is specified in = revocationDate field of CRL but the real e.g. compromise was earlier = than is the time value in revocationDate. The revocationDate of a CRL = does not give you the real time when a certificate was revoked but the = revocationDate is the START of the interval since when a certificate is = to be invalid according to signed evidence created by CA. =20 The real revocation date will be earlier than is the date in the = revocationDate field of CRL e.g. according to judgement in = court.=E2=80=9D =20 I am wondering how this is to be treated in light of RFC 3161, = especially appendix B (where it would be the judgment of the software, = not of the court). =20 In particular Windows verifies a timestamp by calling a revocation = provider with a call including a past time stamp. As MSDN iterates on = http://msdn.microsoft.com/en-us/library/aa377524.aspx pftTimeToUse : " A pointer to a FILETIME version of UTC time. When = specified, the handler must, if possible, determine revocation status = relative to the time given. If NULL or the handler cannot determine the = status relative to the pftTimeToUse value, revocation status can be = determined independent of time or relative to current time." =20 This would seem to indicate that revocation checking on windows should = return a good!? status of the time specified above is before = revocationDate in the CRL, but as indicated in the previous thread, this = is unreliable as the actual key compromise time, hence validation of the = past signature with a certificate now revoked seems to be somewhat = questionable. Why is then InvalidityDate an optional CRL entry = extension? What are the reliable inputs to RFC 3161, appendix B, B6? =20 On a separate note, why is MS expecting a revocation provider to return = good status in the case when ftTimeToUse < revocationDate and is that = not, not following the spirit of 3161, Appendix B, B 5 and B 6? =20 Thanks in advance,=20 Hristo ------=_NextPart_000_0006_01CDEA68.44864140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Good observation = FRC 3161, Appendix B, B 5 and B 6

"B) The validity of the digital =
signature may then be verified in =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following =
way:
 =
5)=C2=A0=C2=A0=C2=A0 The revocation information about that certificate, =
at the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 date/time of the Time-Stamping operation, MUST be =
retrieved.
 =
6)=C2=A0=C2=A0=C2=A0 Should the certificate be revoked, then the =
date/time of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 revocation shall be later than the date/time =
indicated by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 the TSA.
"

Probably = =E2=80=9Cshall be later=E2=80=9D must be replaced with = =E2=80=9Cshall be before=E2=80=9D in sentence = B 6.

The sentence = with =E2=80=9Cshall be later=E2=80=9D is about the situations = when the signature is valid with revoked certificate where the revocation is later then the = time when the signature was time-stamped.

 =

Peter = Rybar

 =

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Hristo Todorov
Sent: Thursday, January = 03, 2013 6:56 PM
To: pkix@ietf.org
Subject: [pkix] time = stamp verification for non repudiation (in Windows)

 

Hi all,

 

This question is somewhat related to information Peter Rybar = provided several hours ago in the thread: why revoked certificate entry has to be = included in one CRL issued beyond certificate validity = period

 

=E2=80=9CThe date on which the revocation = occurred is specified in revocationDate field of CRL but the real e.g. compromise = was earlier than is the time value in revocationDate. The revocationDate of = a CRL does not give you the real time when a certificate was revoked but the = revocationDate is the START of the interval since when a certificate is to be invalid according to signed evidence created by CA.

 

The real revocation date = will be earlier than is the date in the revocationDate field of CRL e.g. = according to judgement in court.=E2=80=9D

 

I am wondering how this is to be treated in light of RFC 3161, especially appendix B (where it would be the judgment of the software, = not of the court).

 

In particular Windows verifies a timestamp by calling a = revocation provider with a call including a past time stamp. As MSDN iterates on http://msd= n.microsoft.com/en-us/library/aa377524.aspx<= /p>

pftTimeToUse : " A = pointer to a FILETIME version of UTC time. When specified, the handler must, if = possible, determine revocation status relative to the time given. If NULL or the = handler cannot determine the status relative to the pftTimeToUse value, = revocation status can be determined independent of time or relative to current = time."

 

This would seem to indicate that revocation =
checking on windows should return a good!? status of the time specified =
above is before revocationDate in the CRL, but as =
indicated in the previous thread, this is unreliable as the actual key =
compromise time, hence validation of the past signature with a =
certificate now revoked seems to be somewhat questionable. Why is then =
InvalidityDate an optional CRL entry =
extension? What are the reliable inputs to RFC 3161, appendix B, =
B6?
 

On a separate note, why = is MS expecting a revocation provider to return good status in the case when  ftTimeToUse < revocationDate = and is that not,  not following the spirit of 3161, Appendix B, B 5 and = B 6?

 

Thanks in advance,

Hristo

------=_NextPart_000_0006_01CDEA68.44864140-- From stefan@aaa-sec.com Fri Jan 4 01:57: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 C411F21F8EB6 for ; Fri, 4 Jan 2013 01:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 pJTu4eYp-LiK for ; Fri, 4 Jan 2013 01:57:55 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F521F8E50 for ; Fri, 4 Jan 2013 01:57:54 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6E8B71E13CE1 for ; Fri, 4 Jan 2013 10:57:50 +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 MOnc42O5ETSN for ; Fri, 4 Jan 2013 10:57:50 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 333D71E1448B for ; Fri, 4 Jan 2013 10:57:50 +0100 (CET) Received: (qmail 42996 invoked from network); 4 Jan 2013 09:57:49 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Jan 2013 09:57:49 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 04 Jan 2013 10:57:47 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: 2560bis WGLC In-Reply-To: <50E45593.2080808@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] 2560bis 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: Fri, 04 Jan 2013 09:57:55 -0000 Forwarding Steve's WGLC on RFC 2560bis. (It was misaddressed) On 1/2/13 4:43 PM, "Stephen Kent" wrote: >Folks, > >Stefan has just published the long-awaited 2560bis update, and has >requested WGLC. > >Let's begin a slightly longer WGLC, to accommodate those who may be on a >post-New year vacation. > >the WGLC will end on 1/20/13. > >Steve From pkix@inbox.lv Fri Jan 4 03:52: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 3428D21F8650 for ; Fri, 4 Jan 2013 03:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJf4XxIje+K5 for ; Fri, 4 Jan 2013 03:52:10 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id 331E221F85EE for ; Fri, 4 Jan 2013 03:52:08 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id ABA06705D; Fri, 4 Jan 2013 13:52:03 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 8C12D6D50; Fri, 4 Jan 2013 13:52:03 +0200 (EET) Received: from localhost ([10.0.1.16]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id X83u2pfu-ZSB; Fri, 4 Jan 2013 13:51:56 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Fri, 04 Jan 2013 13:51:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w6.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357300316.50e6c25c87b52@mail.inbox.lv> Date: Fri, 04 Jan 2013 13:51:56 +0200 From: "Andris Berzins" To: "Peter Rybar" References: <1357240211.50e5d7938ca92@mail.inbox.lv> <201301040852.r048qYBv036062@mail.nbusr.sk> In-Reply-To: <201301040852.r048qYBv036062@mail.nbusr.sk> User-Agent: Inbox.lv Webmail Cc: 'Stefan Santesson' , pkix@ietf.org 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: Fri, 04 Jan 2013 11:52:11 -0000 Quoting "Peter Rybar" : > The risk, as was pointed by Stefan, is when thisUpdate is before the time= to > which validation is realized because OCSP or CRL issued later can revoke = ce >rtificate. >=20 > The time line: thisUpdate-1, thisUpdate-2, time to which validation is re= ali >zed, thisUpdate-3, thisUpdate-4. >=20 > Only CRLs/OCSPs issued with thisUpdate-3 or thisUpdate-4 time values are = sta >ble. thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have bee= n marked as "onHold" with revocation=20 date before validation is realized. >=20 > CRLs/OCSPs issued with thisUpdate-1 or thisUpdate-2 time values are used = wit >h potential risk - certificate could be revoked before the time to which v= al >idation is realized (TIME-STAMP or audit trail) in later CRL/OCSP (this si= tu >ation with such potential risk is always in on-line services e.g. when SSL= /T >SL certificates are used and RFC5280 validation algorithm is defined with = su >ch potential risk for on-line services based on certificate usage). >=20 > Peter Rybar >=20 > -----Original Message----- > From: Andris Berzins [mailto:pkix@inbox.lv] > Sent: Thursday, January 03, 2013 8:10 PM > To: Peter Rybar > Cc: 'Stefan Santesson'; 'Santosh Chokhani'; pkix@ietf.org > Subject: RE: [pkix] why revoked certificate entry has to be included in o= ne=20 >CRL issued beyond certificate validity period >=20 > Quoting "Peter Rybar" : >>> Nice. So what the relying party should do? >>=20 >> Wait for CRL or for OCSP where the time included in thisUpdate field is = afte >> r the time to which the validation is expected (time-stamp or audit trai= l). >>=20 >> It means the grace period (mentioned by Denis) is dynamic and was finish= ed i >> n the time when the time value in thisUpdate of CRL/OCSP was greater tha= n th >> e time to which you validate the certificate. >=20 > Greater than is not enough. Relying party is supposed to get next publish= ed=20 >CRL or else if any of CRLs published > are missed then: > 1. Certificate could have been revoked short before expiration and relyin= g p >arty missed that single published CRL > beyond certificate expiration. > 2. Certificate could have been "on hold" and now is released. Without par= sin >g all published CRLs relying party can > not detect this. >=20 > By the same analogy this grace period approach should be applied to whole= pa >th not only on end entity certificate. > For example, if root CA publishes CRL for intermediate CA's once in 3 mon= th, > then grace period has to be 3 month > or else relying party takes a risk? >=20 >=20 >>=20 >> Some documents are at address: >> http://www.nbusr.sk/en/electronic-signature/verification.1.html >>=20 >> Certificate Path Validation (pdf, 354.4 kB) >> http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisl= ativ >> a/kontrola_cert_cesty_en.pdf >>=20 >> Peter Rybar >>=20 >> -----Original Message----- >> From: Andris Berzins [mailto:pkix@inbox.lv] >> Sent: Thursday, January 03, 2013 3:37 PM >> To: Stefan Santesson >> Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included in = one >> CRL issued beyond certificate validity period >>=20 >> If talking about courts, are there any case studies available or known c= ases >> ? >>=20 >>> On 1/3/13 2:13 PM, "Peter Rybar" wrote: >>>=20 >>>> Andris, >>>>=20 >>>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not u= sed. >>>> Validation is based only on information whose status is stable and was >>>> already finished in the past. >>>>=20 >>>> Only thisUpdate date of CRL is used for non-repudiation purposes. >>>>=20 >>>> The date on which the revocation occurred is specified in revocationDa= te >>>> field of CRL but the real e.g. compromise was earlier than is the time >>>> value in revocationDate. The revocationDate of a CRL does not give you >>>> the real time when a certificate was revoked but the revocationDate is >>>> the START of the interval since when a certificate is to be invalid >>>> according to signed evidence created by CA. >>>>=20 >>>> The real revocation date will be earlier than is the date in the >>>> revocationDate field of CRL e.g. according to judgement in court. >>>>=20 >>>> And as was it clarified by Piyush in thread 2560bis: >>>> "according to 5280, revocationDate cannot precede thisUpdate of an >>>> earlier CRL if the revocation for the certificate is being reported th= e >>>> first time. >>>>=20 >>>> Not saying that OCSP has to follow these rules, but given that it is >>>> deviating from CRLs on the meaning of revocationTime and >>>> revocationReason, a separated section describing these fields should b= e >>>> added. " >>>>=20 >>>>=20 >>>> Peter Rybar >>>> National Security Authority >>>> Information Security and Electronic Signature Department >>>>=20 >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> Andris Berzins >>>> Sent: Thursday, January 03, 2013 1:02 PM >>>> To: Santosh Chokhani >>>> Cc: pkix@ietf.org >>>> Subject: Re: [pkix] why revoked certificate entry has to be included i= n >>>> one CRL issued beyond certificate validity period >>>>=20 >>>> OK. Let's assume situation where end entity requests certificate to be >>>> revoked, but next CRL will be published only >>>> after this currently valid certificate will be expired. >>>>=20 >>>> Very interesting situation. So the goal of rfc5280 is to archive the f= act >>>> that it was revoked before it expired on at >>>> least one published CRL. >>>>=20 >>>> But does it make sense? >>>>=20 >>>> Let's assume that relying party checked freshest CRL and concluded tha= t >>>> presented certificate is valid (although >>>> CA already received revocation request). So the relying party did some >>>> damaging actions by the request of end >>>> entity. Does this feature, that end entity can proof that its cert wa= s >>>> revoked before it expired, makes relying party >>>> to rollback that transaction although relying party checked CRL at tha= t >>>> time correctly? >>>>=20 >>>> Perhaps I can generalize the question. >>>> Is relying party obligated to take the risk that although current CRL >>>> says that cert is not revoked, the next published >>>> CRL can tell that at that time revocation request was already received= =2E >>>> Or is end entity liable and has to take risk that even if revocation i= s >>>> requested now, the revocation will take legal >>>> effect only after CA's CRL's nextUpdate date is reached? >>>>=20 >>>>=20 >>>>=20 >>>> Quoting "Santosh Chokhani" : >>>>> Andris, >>>>>=20 >>>>> The rationale behind this is to provide for archive and future >>>>> verification >>>>> (e.g., for non-repudiation purposes) for . >>>>>=20 >>>>> Let us make the following assumptions: >>>>>=20 >>>>>=20 >>>>> 1. The CRLs are the official archive. >>>>>=20 >>>>> 2. Delta CRLs are not the official archive >>>>>=20 >>>>> 3. A new CRL Y can be built using the previous CRL X and a delta >>>>> issued >>>>> when Y is issued. >>>>>=20 >>>>> In that case, you want a certificate on at least one CRL and maintain >>>>> on del >>>>> ta until it is recorded in a CRL that is archived. >>>>>=20 >>>>> 5280 language is unnecessarily constraining. It should state, =C2=B3= expired >>>>> cert >>>>> ificates shall be removed from the CRL, except a revoked certificate >>>>> shall a >>>>> ppear on at least one CRL. >>>>>=20 >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>>>> Andr >>>>> is Berzins >>>>> Sent: Thursday, December 27, 2012 3:06 PM >>>>> To: pkix@ietf.org >>>>> Subject: [pkix] why revoked certificate entry has to be included in o= ne >>>>> CRL >>>>> issued beyond certificate validity period >>>>>=20 >>>>> rfc5280 states: >>>>>=20 >>>>> "An entry MUST NOT be removed >>>>> from the CRL until it appears on one regularly scheduled CRL issued >>>>> beyond the revoked certificate's validity period." >>>>>=20 >>>>> and >>>>>=20 >>>>> "If a certificate revocation notice first appears on a delta CRL, the= n >>>>> it is possible for the certificate validity period to expire before >>>>> the next complete CRL for the same scope is issued. In this case, >>>>> the revocation notice MUST be included in all subsequent delta CRLs >>>>> until the revocation notice is included on at least one explicitly >>>>> issued complete CRL for this scope." >>>>>=20 >>>>> Why is that required? >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix From prvs=0716c546e9=rybar@nbusr.sk Fri Jan 4 05:40: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 383F021F888E for ; Fri, 4 Jan 2013 05:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 u-CcUAbEpEOo for ; Fri, 4 Jan 2013 05:40:45 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id BDDA521F888C for ; Fri, 4 Jan 2013 05:40:44 -0800 (PST) Message-Id: <201301041340.r04DefKg038160@mail.nbusr.sk> From: "Peter Rybar" To: "'Andris Berzins'" Date: Fri, 4 Jan 2013 14:40:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1357300316.50e6c25c87b52@mail.inbox.lv> Thread-Index: Ac3qcexIJAQ0UZ3VQAWdpFf+ijbskwADcJEQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4451> : streams <886430> : uri <1310809> Cc: 'Stefan Santesson' , pkix@ietf.org 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: Fri, 04 Jan 2013 13:40:46 -0000 The usage of certificateHold is forbidden in some systems and also by = legislation in some EU countries. It is unclear how long the certificate can be in certificateHold status = because the final result revoked or not revoked is after unknown period = of investigation during certificateHold. -----Original Message----- From: Andris Berzins [mailto:pkix@inbox.lv]=20 Sent: Friday, January 04, 2013 12:52 PM To: Peter Rybar Cc: 'Stefan Santesson'; 'Santosh Chokhani'; pkix@ietf.org Subject: RE: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period Quoting "Peter Rybar" : > The risk, as was pointed by Stefan, is when thisUpdate is before the = time to > which validation is realized because OCSP or CRL issued later can = revoke ce >rtificate. >=20 > The time line: thisUpdate-1, thisUpdate-2, time to which validation is = reali >zed, thisUpdate-3, thisUpdate-4. >=20 > Only CRLs/OCSPs issued with thisUpdate-3 or thisUpdate-4 time values = are sta >ble. thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have = been marked as "onHold" with revocation=20 date before validation is realized. >=20 > CRLs/OCSPs issued with thisUpdate-1 or thisUpdate-2 time values are = used wit >h potential risk - certificate could be revoked before the time to = which val >idation is realized (TIME-STAMP or audit trail) in later CRL/OCSP (this = situ >ation with such potential risk is always in on-line services e.g. when = SSL/T >SL certificates are used and RFC5280 validation algorithm is defined = with su >ch potential risk for on-line services based on certificate usage). >=20 > Peter Rybar >=20 > -----Original Message----- > From: Andris Berzins [mailto:pkix@inbox.lv] > Sent: Thursday, January 03, 2013 8:10 PM > To: Peter Rybar > Cc: 'Stefan Santesson'; 'Santosh Chokhani'; pkix@ietf.org > Subject: RE: [pkix] why revoked certificate entry has to be included = in one=20 >CRL issued beyond certificate validity period >=20 > Quoting "Peter Rybar" : >>> Nice. So what the relying party should do? >>=20 >> Wait for CRL or for OCSP where the time included in thisUpdate field = is afte >> r the time to which the validation is expected (time-stamp or audit = trail). >>=20 >> It means the grace period (mentioned by Denis) is dynamic and was = finished i >> n the time when the time value in thisUpdate of CRL/OCSP was greater = than th >> e time to which you validate the certificate. >=20 > Greater than is not enough. Relying party is supposed to get next = published=20 >CRL or else if any of CRLs published > are missed then: > 1. Certificate could have been revoked short before expiration and = relying p >arty missed that single published CRL > beyond certificate expiration. > 2. Certificate could have been "on hold" and now is released. Without = parsin >g all published CRLs relying party can > not detect this. >=20 > By the same analogy this grace period approach should be applied to = whole pa >th not only on end entity certificate. > For example, if root CA publishes CRL for intermediate CA's once in 3 = month, > then grace period has to be 3 month > or else relying party takes a risk? >=20 >=20 >>=20 >> Some documents are at address: >> http://www.nbusr.sk/en/electronic-signature/verification.1.html >>=20 >> Certificate Path Validation (pdf, 354.4 kB) >> = http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legisla= tiv >> a/kontrola_cert_cesty_en.pdf >>=20 >> Peter Rybar >>=20 >> -----Original Message----- >> From: Andris Berzins [mailto:pkix@inbox.lv] >> Sent: Thursday, January 03, 2013 3:37 PM >> To: Stefan Santesson >> Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org >> Subject: Re: [pkix] why revoked certificate entry has to be included = in one >> CRL issued beyond certificate validity period >>=20 >> If talking about courts, are there any case studies available or = known cases >> ? >>=20 >>> On 1/3/13 2:13 PM, "Peter Rybar" wrote: >>>=20 >>>> Andris, >>>>=20 >>>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is = not used. >>>> Validation is based only on information whose status is stable and = was >>>> already finished in the past. >>>>=20 >>>> Only thisUpdate date of CRL is used for non-repudiation purposes. >>>>=20 >>>> The date on which the revocation occurred is specified in = revocationDate >>>> field of CRL but the real e.g. compromise was earlier than is the = time >>>> value in revocationDate. The revocationDate of a CRL does not give = you >>>> the real time when a certificate was revoked but the revocationDate = is >>>> the START of the interval since when a certificate is to be invalid >>>> according to signed evidence created by CA. >>>>=20 >>>> The real revocation date will be earlier than is the date in the >>>> revocationDate field of CRL e.g. according to judgement in court. >>>>=20 >>>> And as was it clarified by Piyush in thread 2560bis: >>>> "according to 5280, revocationDate cannot precede thisUpdate of an >>>> earlier CRL if the revocation for the certificate is being reported = the >>>> first time. >>>>=20 >>>> Not saying that OCSP has to follow these rules, but given that it = is >>>> deviating from CRLs on the meaning of revocationTime and >>>> revocationReason, a separated section describing these fields = should be >>>> added. " >>>>=20 >>>>=20 >>>> Peter Rybar >>>> National Security Authority >>>> Information Security and Electronic Signature Department >>>>=20 >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf Of >>>> Andris Berzins >>>> Sent: Thursday, January 03, 2013 1:02 PM >>>> To: Santosh Chokhani >>>> Cc: pkix@ietf.org >>>> Subject: Re: [pkix] why revoked certificate entry has to be = included in >>>> one CRL issued beyond certificate validity period >>>>=20 >>>> OK. Let's assume situation where end entity requests certificate to = be >>>> revoked, but next CRL will be published only >>>> after this currently valid certificate will be expired. >>>>=20 >>>> Very interesting situation. So the goal of rfc5280 is to archive = the fact >>>> that it was revoked before it expired on at >>>> least one published CRL. >>>>=20 >>>> But does it make sense? >>>>=20 >>>> Let's assume that relying party checked freshest CRL and concluded = that >>>> presented certificate is valid (although >>>> CA already received revocation request). So the relying party did = some >>>> damaging actions by the request of end >>>> entity. Does this feature, that end entity can proof that its cert = was >>>> revoked before it expired, makes relying party >>>> to rollback that transaction although relying party checked CRL at = that >>>> time correctly? >>>>=20 >>>> Perhaps I can generalize the question. >>>> Is relying party obligated to take the risk that although current = CRL >>>> says that cert is not revoked, the next published >>>> CRL can tell that at that time revocation request was already = received. >>>> Or is end entity liable and has to take risk that even if = revocation is >>>> requested now, the revocation will take legal >>>> effect only after CA's CRL's nextUpdate date is reached? >>>>=20 >>>>=20 >>>>=20 >>>> Quoting "Santosh Chokhani" : >>>>> Andris, >>>>>=20 >>>>> The rationale behind this is to provide for archive and future >>>>> verification >>>>> (e.g., for non-repudiation purposes) for . >>>>>=20 >>>>> Let us make the following assumptions: >>>>>=20 >>>>>=20 >>>>> 1. The CRLs are the official archive. >>>>>=20 >>>>> 2. Delta CRLs are not the official archive >>>>>=20 >>>>> 3. A new CRL Y can be built using the previous CRL X and a = delta >>>>> issued >>>>> when Y is issued. >>>>>=20 >>>>> In that case, you want a certificate on at least one CRL and = maintain >>>>> on del >>>>> ta until it is recorded in a CRL that is archived. >>>>>=20 >>>>> 5280 language is unnecessarily constraining. It should state, = =C2=B3expired >>>>> cert >>>>> ificates shall be removed from the CRL, except a revoked = certificate >>>>> shall a >>>>> ppear on at least one CRL. >>>>>=20 >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf Of >>>>> Andr >>>>> is Berzins >>>>> Sent: Thursday, December 27, 2012 3:06 PM >>>>> To: pkix@ietf.org >>>>> Subject: [pkix] why revoked certificate entry has to be included = in one >>>>> CRL >>>>> issued beyond certificate validity period >>>>>=20 >>>>> rfc5280 states: >>>>>=20 >>>>> "An entry MUST NOT be removed >>>>> from the CRL until it appears on one regularly scheduled CRL = issued >>>>> beyond the revoked certificate's validity period." >>>>>=20 >>>>> and >>>>>=20 >>>>> "If a certificate revocation notice first appears on a delta CRL, = then >>>>> it is possible for the certificate validity period to expire = before >>>>> the next complete CRL for the same scope is issued. In this case, >>>>> the revocation notice MUST be included in all subsequent delta = CRLs >>>>> until the revocation notice is included on at least one explicitly >>>>> issued complete CRL for this scope." >>>>>=20 >>>>> Why is that required? >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Fri Jan 4 06:07: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 C7AC421F87A6 for ; Fri, 4 Jan 2013 06:07:24 -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 YDPuK1G4V6Nd for ; Fri, 4 Jan 2013 06:07:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4578E21F879E for ; Fri, 4 Jan 2013 06:07:24 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 789BB1F09FD; Fri, 4 Jan 2013 09:07:21 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 602B51F09E2; Fri, 4 Jan 2013 09:07:21 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 09:07:21 -0500 From: "Miller, Timothy J." To: Andris Berzins , Peter Rybar Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN6nHln7/gW7Wk60CbQPL0xhIa3Zg5I/UA Date: Fri, 4 Jan 2013 14:07:20 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FF81E@IMCMBX01.MITRE.ORG> In-Reply-To: <1357300316.50e6c25c87b52@mail.inbox.lv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.31.40.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EA92E063175DE4390D5B303B6619056@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Stefan Santesson' , "pkix@ietf.org" 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: Fri, 04 Jan 2013 14:07:24 -0000 On 1/4/13 5:51 AM, "Andris Berzins" wrote: >thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have >been marked as "onHold" with revocation >date before validation is realized. So what? =20 -- T From pkix@inbox.lv Fri Jan 4 06:59:09 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 B30A421F88BF for ; Fri, 4 Jan 2013 06:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2LH-seQK6dX for ; Fri, 4 Jan 2013 06:59:08 -0800 (PST) Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6421F88B4 for ; Fri, 4 Jan 2013 06:59:06 -0800 (PST) Received: by shark4.inbox.lv (Postfix, from userid 1000) id F1D9325B0F; Fri, 4 Jan 2013 16:59:00 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id C279225B0F; Fri, 4 Jan 2013 16:59:00 +0200 (EET) Received: from localhost ([10.0.1.16]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id 79HUK38h+-0n; Fri, 4 Jan 2013 16:58:57 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Fri, 04 Jan 2013 16:58:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w6.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357311537.50e6ee3107161@mail.inbox.lv> Date: Fri, 04 Jan 2013 16:58:57 +0200 From: "Andris Berzins" To: "Miller, Timothy J." References: <1357300316.50e6c25c87b52@mail.inbox.lv> <195DB2510AAA004391F58E28FCE21200066FF81E@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066FF81E@IMCMBX01.MITRE.ORG> User-Agent: Inbox.lv Webmail Cc: 'Stefan Santesson' , "pkix@ietf.org" 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: Fri, 04 Jan 2013 14:59:09 -0000 Quoting "Miller, Timothy J." : > On 1/4/13 5:51 AM, "Andris Berzins" wrote: >=20 >> thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have >> been marked as "onHold" with revocation >> date before validation is realized. >=20 > So what? So to verify revocation status, relying party is obligated to collect all c= onsecutive CRL publications without missing=20 one. Conclusion - CRLs can not be used to determine revocation status accurately= even with grace period workarounds. >=20 > -- T From stefan@aaa-sec.com Fri Jan 4 07:20: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 AD10121F88B9 for ; Fri, 4 Jan 2013 07:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 YbapxVFOA61i for ; Fri, 4 Jan 2013 07:20:08 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 08F0B21F88DA for ; Fri, 4 Jan 2013 07:20:07 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id ACA7A1E0E0FD for ; Fri, 4 Jan 2013 16:20:05 +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 coQBgL2Nd4Ho for ; Fri, 4 Jan 2013 16:20:05 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 539CF1D992DA for ; Fri, 4 Jan 2013 16:20:05 +0100 (CET) Received: (qmail 16526 invoked from network); 4 Jan 2013 15:20:05 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Jan 2013 15:20:05 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 04 Jan 2013 16:20:12 +0100 From: Stefan Santesson To: Andris Berzins , "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period In-Reply-To: <1357311537.50e6ee3107161@mail.inbox.lv> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" 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: Fri, 04 Jan 2013 15:20:08 -0000 On 1/4/13 3:58 PM, "Andris Berzins" wrote: >Quoting "Miller, Timothy J." : >> On 1/4/13 5:51 AM, "Andris Berzins" wrote: >> >>> thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have >>> been marked as "onHold" with revocation >>> date before validation is realized. >> >> So what? > >So to verify revocation status, relying party is obligated to collect all >consecutive CRL publications without missing >one. > >Conclusion - CRLs can not be used to determine revocation status >accurately even with grace period workarounds. Revocation is a reactive countermeasure. That makes it by definition imperfect. There will always be a time window before information about the breach is available and there will always be some degree of uncertainty about when the breach actually took place. Quite some security measures used today have this limitation. That does not make it useless! It just make it what it is, a tool for reducing risk, not eliminating it. For those who can mange risk, this technology is actually quite useful. /Stefan From DPKemp@missi.ncsc.mil Fri Jan 4 07:25: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 D8F4B21F8881 for ; Fri, 4 Jan 2013 07:25:36 -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 DLNKRaFxbGfY for ; Fri, 4 Jan 2013 07:25:36 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACCE21F8650 for ; Fri, 4 Jan 2013 07:25:36 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id r04FPZGT025270 for ; Fri, 4 Jan 2013 10:25:35 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.52]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0438.000; Fri, 4 Jan 2013 10:25:35 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN6owUU26+McLt7E2UTDmFrSG5HZg5R1sA Date: Fri, 4 Jan 2013 15:25:34 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC85AC67F2F@clavin.missi.ncsc.mil> References: <1357300316.50e6c25c87b52@mail.inbox.lv> <195DB2510AAA004391F58E28FCE21200066FF81E@IMCMBX01.MITRE.ORG> <1357311537.50e6ee3107161@mail.inbox.lv> In-Reply-To: <1357311537.50e6ee3107161@mail.inbox.lv> 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] 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: Fri, 04 Jan 2013 15:25:37 -0000 In order to determine revocation status accurately, an RP needs one CRL. In order to determine hold status up to a certain frequency resolution, the= RP would need samples (CRLs) above the Nyquist rate. If a certificate co= uld be put on hold and removed from it with 1 hour resolution and an RP had= some reason to collect a historical record of all the hold periods over a = one year interval, it would need a lot of samples :-). Advocates for hold = can present use cases and CRL sampling requirements to address those requir= ements, but AFAIK DoD has no requirement to ever use, much less archive, ho= ld status. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of And= ris Berzins Sent: Friday, January 04, 2013 9:59 AM To: Miller, Timothy J. Cc: 'Stefan Santesson'; pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in one= CRL issued beyond certificate validity period Quoting "Miller, Timothy J." : > On 1/4/13 5:51 AM, "Andris Berzins" wrote: >=20 >> thisUpdate-4 is not stable, because in thisUpdate-3 the cert could=20 >> have been marked as "onHold" with revocation date before validation=20 >> is realized. >=20 > So what? So to verify revocation status, relying party is obligated to collect all c= onsecutive CRL publications without missing one. Conclusion - CRLs can not be used to determine revocation status accurately= even with grace period workarounds. >=20 > -- T _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pkix@inbox.lv Fri Jan 4 09:21: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 585D921F85E6 for ; Fri, 4 Jan 2013 09:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvfbY25VCHck for ; Fri, 4 Jan 2013 09:21:40 -0800 (PST) Received: from shark3.inbox.lv (shark3.inbox.lv [89.111.3.83]) by ietfa.amsl.com (Postfix) with ESMTP id CBFCC21F8551 for ; Fri, 4 Jan 2013 09:21:37 -0800 (PST) Received: by shark3.inbox.lv (Postfix, from userid 1000) id 22F7610604; Fri, 4 Jan 2013 19:21:30 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark3-plain-b64d2.inbox.lv (Postfix) with ESMTP id ECC71FBB6; Fri, 4 Jan 2013 19:21:29 +0200 (EET) Received: from localhost ([10.0.1.18]) by localhost (shark3.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id yY79mvcS+qnm; Fri, 4 Jan 2013 19:21:29 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Fri, 04 Jan 2013 19:21:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w8.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1357320089.50e70f9945793@mail.inbox.lv> Date: Fri, 04 Jan 2013 19:21:29 +0200 From: "Andris Berzins" To: "Stefan Santesson" References: <1357311537.50e6ee3107161@mail.inbox.lv> In-Reply-To: User-Agent: Inbox.lv Webmail Cc: "pkix@ietf.org" 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: Fri, 04 Jan 2013 17:21:41 -0000 Quoting "Stefan Santesson" : > Revocation is a reactive countermeasure. That makes it by definition > imperfect. There will always be a time window before information about th= e > breach is available and there will always be some degree of uncertainty > about when the breach actually took place. >=20 > Quite some security measures used today have this limitation. >=20 > That does not make it useless! > It just make it what it is, a tool for reducing risk, not eliminating it= =2E >=20 > For those who can mange risk, this technology is actually quite useful. Or relying party can use OCSP that serves status information directly from = CA repository. >=20 > /Stefan From piyush@ditenity.com Fri Jan 4 16:38:17 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 81A3A21F8A9B for ; Fri, 4 Jan 2013 16:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yz0ykcGNV2S for ; Fri, 4 Jan 2013 16:38:16 -0800 (PST) Received: from mail-ye0-f173.google.com (mail-ye0-f173.google.com [209.85.213.173]) by ietfa.amsl.com (Postfix) with ESMTP id A0B5321F8A71 for ; Fri, 4 Jan 2013 16:38:14 -0800 (PST) Received: by mail-ye0-f173.google.com with SMTP id l5so2727276yen.4 for ; Fri, 04 Jan 2013 16:38:14 -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=TBfVxKlGkdIIHbAp8hXPdCF0np17IKAsD/XoPDZbXog=; b=AnHjC/kDSUUMFTk8TxHuAiXX7p2fMz1gpTdHC0AHVpn2TKTCWuiyHyge/X1WmrfChs xM+42jPfaBFJR54EwSvM9Ar9jeyMnI4l+wdSiweEK//hUDE5FWgVN6MY7O8q8/2HoaSi Xm5KR/5Qe/96v7bQ3Pi9GRuDeJE9IGkWLns/CooOfCS3T+bHUdeZT3mwMdzqDwaZNpW/ BN2dGaMI5CdSLRdDQgFSqoRbGhLsqBBwm1MXSs2KMH2Q6UoRAHYYY4S+ysCJW1LQUWWj QbnaCK0yf9GWGOkx1w1O3ygUPeGnIpxwikkRjPSTsfBoNyGIys2cykZCYsD6mqPpBG/Y 6cbw== X-Received: by 10.236.135.230 with SMTP id u66mr47855921yhi.119.1357346293797; Fri, 04 Jan 2013 16:38:13 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s65sm50013825yhn.19.2013.01.04.16.38.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:38:13 -0800 (PST) From: "Piyush Jain" To: "'Andris Berzins'" , "'Peter Rybar'" References: <1357223792.50e59770b535d@mail.inbox.lv> <201301031507.r03F76Xu033658@mail.nbusr.sk> <1357240211.50e5d7938ca92@mail.inbox.lv> In-Reply-To: <1357240211.50e5d7938ca92@mail.inbox.lv> Date: Sat, 5 Jan 2013 06:08:09 +0530 Message-ID: <018c01cdeadc$f1eae420$d5c0ac60$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHj4oLd5GSQ9KfaETN+4rzdkWeNEAKG10XXA3N878+X3hwZYA== Content-Language: en-us X-Gm-Message-State: ALoCoQlS1+REvIcGp+YTnplTeStP/PnrCWl9JP7gDQLEXcEAIyIqUQ73f5o9YTU0+RFVxn6rpjXP Cc: 'Stefan Santesson' , pkix@ietf.org 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: Sat, 05 Jan 2013 00:38:17 -0000 Hi Andris, Please see inline. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Andris Berzins > Sent: Friday, January 04, 2013 12:40 AM > To: Peter Rybar > Cc: 'Stefan Santesson'; pkix@ietf.org > Subject: Re: [pkix] why revoked certificate entry has to be included = in one > CRL issued beyond certificate validity period >=20 > Quoting "Peter Rybar" : > >> Nice. So what the relying party should do? > > > > Wait for CRL or for OCSP where the time included in thisUpdate field > >is afte r the time to which the validation is expected (time-stamp or = audit > trail). > > > > It means the grace period (mentioned by Denis) is dynamic and was > >finished i n the time when the time value in thisUpdate of CRL/OCSP = was > >greater than th e time to which you validate the certificate. >=20 > Greater than is not enough. Relying party is supposed to get next = published > CRL or else if any of CRLs published are missed then: > 1. Certificate could have been revoked short before expiration and = relying > party missed that single published CRL beyond certificate expiration. > 2. Certificate could have been "on hold" and now is released. Without = parsing > all published CRLs relying party can not detect this. [Piyush]True for the corner case where certificate is about to expire. = You can address it by applying the grace period to certificate expiry = i.e. prohibit the use of certificates if the time to expiry is less than = the grace period. >=20 > By the same analogy this grace period approach should be applied to = whole > path not only on end entity certificate. > For example, if root CA publishes CRL for intermediate CA's once in 3 = month, > then grace period has to be 3 month or else relying party takes a = risk? > [Piyush] The difference between thisUpdate and nextUpdate does not = necessarily maps to the frequency of CRL publishing. Most root CAs would = issue a new CRL immediately when the content of revocation list changes. = The relying parties should check for newer CRLs even if the CRL in their = possession is currently valid. =20 >=20 > > > > Some documents are at address: > > http://www.nbusr.sk/en/electronic-signature/verification.1.html > > > > Certificate Path Validation (pdf, 354.4 kB) > > http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky- > podpis/legislativ > >a/kontrola_cert_cesty_en.pdf > > > > Peter Rybar > > > > -----Original Message----- > > From: Andris Berzins [mailto:pkix@inbox.lv] > > Sent: Thursday, January 03, 2013 3:37 PM > > To: Stefan Santesson > > Cc: Peter Rybar; 'Santosh Chokhani'; pkix@ietf.org > > Subject: Re: [pkix] why revoked certificate entry has to be included = in one > >CRL issued beyond certificate validity period > > > > If talking about courts, are there any case studies available or = known cases > >? > > > >> On 1/3/13 2:13 PM, "Peter Rybar" wrote: > >> > >>> Andris, > >>> > >>> For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is = not > used. > >>> Validation is based only on information whose status is stable and = was > >>> already finished in the past. > >>> > >>> Only thisUpdate date of CRL is used for non-repudiation purposes. > >>> > >>> The date on which the revocation occurred is specified in = revocationDate > >>> field of CRL but the real e.g. compromise was earlier than is the = time > >>> value in revocationDate. The revocationDate of a CRL does not give = you > >>> the real time when a certificate was revoked but the = revocationDate is > >>> the START of the interval since when a certificate is to be = invalid > >>> according to signed evidence created by CA. > >>> > >>> The real revocation date will be earlier than is the date in the > >>> revocationDate field of CRL e.g. according to judgement in court. > >>> > >>> And as was it clarified by Piyush in thread 2560bis: > >>> "according to 5280, revocationDate cannot precede thisUpdate of an > >>> earlier CRL if the revocation for the certificate is being = reported the > >>> first time. > >>> > >>> Not saying that OCSP has to follow these rules, but given that it = is > >>> deviating from CRLs on the meaning of revocationTime and > >>> revocationReason, a separated section describing these fields = should be > >>> added. " > >>> > >>> > >>> Peter Rybar > >>> National Security Authority > >>> Information Security and Electronic Signature Department > >>> > >>> -----Original Message----- > >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf > Of > >>> Andris Berzins > >>> Sent: Thursday, January 03, 2013 1:02 PM > >>> To: Santosh Chokhani > >>> Cc: pkix@ietf.org > >>> Subject: Re: [pkix] why revoked certificate entry has to be = included in > >>> one CRL issued beyond certificate validity period > >>> > >>> OK. Let's assume situation where end entity requests certificate = to be > >>> revoked, but next CRL will be published only > >>> after this currently valid certificate will be expired. > >>> > >>> Very interesting situation. So the goal of rfc5280 is to archive = the fact > >>> that it was revoked before it expired on at > >>> least one published CRL. > >>> > >>> But does it make sense? > >>> > >>> Let's assume that relying party checked freshest CRL and concluded = that > >>> presented certificate is valid (although > >>> CA already received revocation request). So the relying party did = some > >>> damaging actions by the request of end > >>> entity. Does this feature, that end entity can proof that its = cert was > >>> revoked before it expired, makes relying party > >>> to rollback that transaction although relying party checked CRL at = that > >>> time correctly? > >>> > >>> Perhaps I can generalize the question. > >>> Is relying party obligated to take the risk that although current = CRL > >>> says that cert is not revoked, the next published > >>> CRL can tell that at that time revocation request was already = received. > >>> Or is end entity liable and has to take risk that even if = revocation is > >>> requested now, the revocation will take legal > >>> effect only after CA's CRL's nextUpdate date is reached? > >>> > >>> > >>> > >>> Quoting "Santosh Chokhani" : > >>>> Andris, > >>>> > >>>> The rationale behind this is to provide for archive and future > >>>> verification > >>>> (e.g., for non-repudiation purposes) for . > >>>> > >>>> Let us make the following assumptions: > >>>> > >>>> > >>>> 1. The CRLs are the official archive. > >>>> > >>>> 2. Delta CRLs are not the official archive > >>>> > >>>> 3. A new CRL Y can be built using the previous CRL X and a = delta > >>>> issued > >>>> when Y is issued. > >>>> > >>>> In that case, you want a certificate on at least one CRL and = maintain > >>>> on del > >>>> ta until it is recorded in a CRL that is archived. > >>>> > >>>> 5280 language is unnecessarily constraining. It should state, = =C2=B3expired > >>>> cert > >>>> ificates shall be removed from the CRL, except a revoked = certificate > >>>> shall a > >>>> ppear on at least one CRL. > >>>> > >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On > Behalf Of > >>>> Andr > >>>> is Berzins > >>>> Sent: Thursday, December 27, 2012 3:06 PM > >>>> To: pkix@ietf.org > >>>> Subject: [pkix] why revoked certificate entry has to be included = in one > >>>> CRL > >>>> issued beyond certificate validity period > >>>> > >>>> rfc5280 states: > >>>> > >>>> "An entry MUST NOT be removed > >>>> from the CRL until it appears on one regularly scheduled CRL = issued > >>>> beyond the revoked certificate's validity period." > >>>> > >>>> and > >>>> > >>>> "If a certificate revocation notice first appears on a delta CRL, = then > >>>> it is possible for the certificate validity period to expire = before > >>>> the next complete CRL for the same scope is issued. In this = case, > >>>> the revocation notice MUST be included in all subsequent delta = CRLs > >>>> until the revocation notice is included on at least one = explicitly > >>>> issued complete CRL for this scope." > >>>> > >>>> Why is that required? > >>> > >>> _______________________________________________ > >>> 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 Sat Jan 5 00:33: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 D983F21F8788 for ; Sat, 5 Jan 2013 00:33:27 -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 Rf4kN8-S-2mh for ; Sat, 5 Jan 2013 00:33:27 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5C21F8780 for ; Sat, 5 Jan 2013 00:33:27 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 4CBB71E16B8C for ; Sat, 5 Jan 2013 09:33:22 +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 HX2EzGSvMoPN for ; Sat, 5 Jan 2013 09:33:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id ED9981D9B878 for ; Sat, 5 Jan 2013 09:33:21 +0100 (CET) Received: (qmail 2878 invoked from network); 5 Jan 2013 08:33:21 -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 ; 5 Jan 2013 08:33:21 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sat, 05 Jan 2013 09:33:27 +0100 From: Stefan Santesson To: Hristo Todorov , "pkix@ietf.org" Message-ID: Thread-Topic: [pkix] time stamp verification for non repudiation (in Windows) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3440223210_13885901" Subject: Re: [pkix] time stamp verification for non repudiation (in Windows) 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, 05 Jan 2013 08:33:28 -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_3440223210_13885901 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Hristo Todorov Date: Thursday, January 3, 2013 6:56 PM To: "pkix@ietf.org" Subject: [pkix] time stamp verification for non repudiation (in Windows) > This would seem to indicate that revocation checking on windows should return > a good!? status of the time specified above is before revocationDate in the > CRL, but as indicated in the previous thread, this is unreliable as the actual > key compromise time, hence validation of the past signature with a certificate > now revoked seems to be somewhat questionable. Almost everything in PKI is questionable. The identity of the subject is questionable, verified through imperfect means. Whether the CA is compromised is questionable. It might be without you ever knowing about it. Systems process the data at hand to determine results given defined rules. That result can be used to manage trust and risks, but should not be mistaken for being a perfect reflection of reality. This is why we have courts to sort out what reasonably happened and who is responsible, if needed. /Stefan --B_3440223210_13885901 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Hristo Todorov <htodorov@axway.com>
Date: Thursday, January 3, 2013 6:56 PM
To: "pkix@ietf.org" <pkix@ietf.org>
Subj= ect: [pkix] time stamp verification for non repudiation (in Windows)=

Date: Tue, 8 Jan 2013 06:39:04 -0800 Message-ID: <032c01cdedad$e936cbe0$bba463a0$@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: Ac3trNFcqk17pinuQceuegUaqNDDqQ== Content-Language: en-us X-Gm-Message-State: ALoCoQk/y2GCK0Nvx+aGj1Mw9ARBg51WBRRvpd65mzpWxwhc4GmF/3zIfU10CbWl2HjngJnXm9jT Subject: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 08 Jan 2013 14:39:09 -0000 Hi Stefan, I was going through the spec of this extension in the latest draft and got confused about its purpose. It could be one of the following: - Indicate responder's capability of issuing revoked for fraudulently issued certificates. - Indicate that revoked is being returned because the certificate in question was fraudulently issued. What did you have in mind when you wrote the text? Thanks -Piyush From stefan@aaa-sec.com Tue Jan 8 07:03:37 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 AEF8A21F8B2E for ; Tue, 8 Jan 2013 07:03:37 -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 H8V5iLU+ZQIL for ; Tue, 8 Jan 2013 07:03:37 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C121F8A25 for ; Tue, 8 Jan 2013 07:03:37 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 585411E2209E for ; Tue, 8 Jan 2013 16:03:35 +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 860MhJH1mh2w for ; Tue, 8 Jan 2013 16:03:35 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 11A861E220F5 for ; Tue, 8 Jan 2013 16:03:35 +0100 (CET) Received: (qmail 33604 invoked from network); 8 Jan 2013 15:03:34 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.209]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Jan 2013 15:03:34 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Tue, 08 Jan 2013 16:03:40 +0100 From: Stefan Santesson To: Piyush Jain , 'pkix' Message-ID: Thread-Topic: Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <032c01cdedad$e936cbe0$bba463a0$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 08 Jan 2013 15:03:37 -0000 The extension only defines that the server supports the extended definition of revoked and thus MAY respond revoked to non issued certificates. Then of course, there is one pretty obvious way to determine that the response is related to a non-issued certificate, if the reason is certificateHold and the revoke date is 1 jan 1970. But the purpose here is just to give a red flag that prevents the certificate from being trusted. Any other semantics beyond that is up to the implementing community. I'm sure CabForum will profile this or perhaps add a new extension that gives more explicit information about e.g. A positive confirmation of existence. An alternative way of doing this would be to define an extension saying that this particular certificate has never been issued and put that as en extension to just the response for that cert. The advantage of the current solution in the draft is that it could be returned to in any certificate response so that you may know about the capability of the OCSP even if you don't ask for a non-issued certificate. /Stefan On 1/8/13 3:39 PM, "Piyush Jain" wrote: >Hi Stefan, > >I was going through the spec of this extension in the latest draft and got >confused about its purpose. > >It could be one of the following: >- Indicate responder's capability of issuing revoked for fraudulently >issued >certificates. >- Indicate that revoked is being returned because the certificate in >question was fraudulently issued. > >What did you have in mind when you wrote the text? > >Thanks >-Piyush > > > From prvs=0720b021a6=rybar@nbusr.sk Tue Jan 8 08:18: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 D3EF91F0CF5 for ; Tue, 8 Jan 2013 08:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 NXPllyTkbTak for ; Tue, 8 Jan 2013 08:18:05 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id F1CC121F85C2 for ; Tue, 8 Jan 2013 08:18:04 -0800 (PST) From: "Peter Rybar" To: "'Stefan Santesson'" , "'Piyush Jain'" , "'pkix'" Date: Tue, 8 Jan 2013 17:18:07 +0100 Message-ID: <201301081618.r08GI1l3054037@mail.nbusr.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Ac3tsWcycUn7BElJRtKm0t7EagHn8QAAuHHA In-Reply-To: Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.2.0.9309 : core <4455> : streams <887625> : uri <1313981> Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 08 Jan 2013 16:18:06 -0000 Stefan, The terminology is not clear for someone who will see: The revocation is of "non-issued certificate". Because by reading the text it is expected that the certificate was = issued, but fraudulently. The revocation with a new extension is only about fraudulently issued = certificate. It means this new extension and revocation is not used when = the certificate is not issued and only fake random certificate serial = number was created in OCSP request. While it is intended only for fraudulently issued certificate where = fraudulently issued certificate can potentially reuse any already used = certificate-serial-number the extension must contain e.g. a positive = confirmation of existence in the form of hash value of fraudulently = issued certificate. Only according to the hash value of fraudulently issued certificate = relaying party and OCSP responder is able to identify fraudulently = issued certificate because CA was compromised and serial numbers of = certificates are not any longer unique for compromised CA.=20 Conclusion: Positive statement extension as a hash value of the certificate whose = status OCSP response is providing can be used in this case:=20 when the certificate is revoked,=20 when the certificate is good and also=20 when the certificate is fraudulently issued. For that reason it can be more helpful to define in RFC one positive = statement extension as a hash value of the certificate whose status the = OCSP response is providing and define in RFC that it will support = situations when status is: -- good -- revoked And for randomly created certificate serial numbers without records in = OCSP database will be use: -- unknown Peter Rybar National Security Authority Information Security and Electronic Signature Department -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Stefan Santesson Sent: Tuesday, January 08, 2013 4:04 PM To: Piyush Jain; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 The extension only defines that the server supports the extended definition of revoked and thus MAY respond revoked to non issued certificates. Then of course, there is one pretty obvious way to determine that the response is related to a non-issued certificate, if the reason is certificateHold and the revoke date is 1 jan 1970. But the purpose here is just to give a red flag that prevents the certificate from being trusted. Any other semantics beyond that is up to the implementing community. I'm sure CabForum will profile this or = perhaps add a new extension that gives more explicit information about e.g. A positive confirmation of existence. An alternative way of doing this would be to define an extension saying that this particular certificate has never been issued and put that as = en extension to just the response for that cert. The advantage of the current solution in the draft is that it could be returned to in any certificate response so that you may know about the capability of the OCSP even if you don't ask for a non-issued = certificate. /Stefan On 1/8/13 3:39 PM, "Piyush Jain" wrote: >Hi Stefan, > >I was going through the spec of this extension in the latest draft and = got >confused about its purpose. > >It could be one of the following: >- Indicate responder's capability of issuing revoked for fraudulently >issued >certificates. >- Indicate that revoked is being returned because the certificate in >question was fraudulently issued. > >What did you have in mind when you wrote the text? > >Thanks >-Piyush > > > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ahmet.yetgin@tubitak.gov.tr Tue Jan 8 00:47:42 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 5973621F8837 for ; Tue, 8 Jan 2013 00:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TR=0.935, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 T08fBDv-7UWG for ; Tue, 8 Jan 2013 00:47:41 -0800 (PST) Received: from mta01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 24A6A21F882D for ; Tue, 8 Jan 2013 00:47:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id 7BACF1C0E28; Tue, 8 Jan 2013 10:47:28 +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 dHhYD28oQwLz; Tue, 8 Jan 2013 10:47:07 +0200 (EET) Received: from mail01.tubitak.gov.tr (mail01.tubitak.gov.tr [10.250.10.219]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id 0DCE11C0DDC; Tue, 8 Jan 2013 10:46:49 +0200 (EET) Date: Tue, 8 Jan 2013 10:46:48 +0200 (EET) From: Ahmet =?utf-8?Q?YETG=C4=B0N_=28B=C4=B0LGEM-UEKAE=29?= To: pkix@ietf.org Message-ID: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> In-Reply-To: <87401118.471748.1357633592763.JavaMail.root@tubitak.gov.tr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_477632_632280291.1357634808669" X-Originating-IP: [10.250.10.217] X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraWebClient - GC23 (Win)/8.0.0_GA_5434) Thread-Topic: Lack of AIA and/or CDP Extensions Thread-Index: odhgC324fp3dR+eD9fib+opgOzCZIg== X-Mailman-Approved-At: Tue, 08 Jan 2013 08:40:18 -0800 Subject: [pkix] Lack of AIA and/or CDP Extensions 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, 08 Jan 2013 08:58:59 -0000 ------=_Part_477632_632280291.1357634808669 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We have an disagreement between our testing group about meaning of missing extensions. For example when validation a QES, if a certificate has an AIA extension, but not CDP extension, and CA is publishing both CRL and COSP responses, 1. Can I use CRL for revocation checking as a first choice? 2. If I cant, can I use CRL if I cant reach OCSP for any technical error/reason. (Problem here is I need to know that CRL publishing address, and in our example I have it from elsewhere, from another certificates OCSPs extensions in the same path. Weird example, yes.) So rephrasing the question, do nonexistence of CDP, means dont use CRLs; and same question goes for AIA. Our collegues reason their interpretation from RFC 5280 pg94 If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. And CWA 14171 5.7.3 Rules for the use of Revocation Status information The verifier should take into account information in the certificate in deciding how best to obtain and check the revocation status (e.g. a certificate extension field about authority information access or a CRL distribution which I believe is a misinterpretation. Do we miss anything about the case here, like any other standart, spec etc? If anyone can point me the right direction, thats highly appreciated. Best Regards. Ahmet Yetgin ------=_Part_477632_632280291.1357634808669 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

We = have an disagreement between our testing group about meaning of missing ext= ensions.

For example when validation a QES, if a c= ertificate has an AIA extension, but not CDP extension, and CA is
publishing both CRL and COSP responses,

1. Can = I use CRL for revocation checking as a first choice?
2. If I cant= , can I use CRL if I cant reach OCSP for any technical error/reason.
<= div>
(Problem here is I need to know that CRL publishing addr= ess, and in our example I have it from elsewhere,
from another c= ertificates OCSPs extensions in the same path. Weird example, yes.)

So rephrasing the question, do nonexistence of CDP, means= dont use CRLs; and same question goes for AIA.

Ou= r collegues reason their interpretation from RFC 5280 pg94

If the revocation status has not been determined, repeat the =
process
   above with any available CRLs not specified in a distribution point
   but issued by the certificate issuer.  For the processing of such a
   CRL, assume a DP with both the reasons and the cRLIssuer fields
   omitted and a distribution point name of the certificate issuer.

=
And CWA 14171
 5.7.3 Rules for t=
he use of Revocation Status information

&n= bsp;Th= e verifier should = take into account information in the certificate
in deciding how best to obtain and check the revoca= tion status (e.g. a
certificate extension field about authority informa= tion access or a CRL
distribution 

which I believe is a misinterpretation.

Do we miss anything about the case here, like any= other standart, spec etc? If anyone can point me the right direction, = ;
thats highly appreciated.

Best Regards.

Ahmet Yetgin


------=_Part_477632_632280291.1357634808669-- From prvs=0720b021a6=rybar@nbusr.sk Tue Jan 8 08:58: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 ECF3511E8097 for ; Tue, 8 Jan 2013 08:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 YaTfG-lG7aQo for ; Tue, 8 Jan 2013 08:58:59 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2B21F8726 for ; Tue, 8 Jan 2013 08:58:58 -0800 (PST) Message-Id: <201301081658.r08Gwuue054201@mail.nbusr.sk> From: "Peter Rybar" To: "'Stephen Kent'" , pkix@ietf.org Date: Tue, 8 Jan 2013 17:59:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Ac3s7Bo5vU+qTK+BQgu76KwdtbmgFwA0x+3w In-Reply-To: <50EAEA5B.7050407@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4455> : streams <887629> : uri <1314017> 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: Tue, 08 Jan 2013 16:59:00 -0000 Steve, I agree, CA must be able to setup the time/date value in nextUpdate = according to conditions defined e.g. in CPS. But the background of such rules is sometimes funny like it is not only = according to max time while CA is able to recovery CA technology from = some accident but also according to a number of days in holidays :-) What is wrong when CRL is regularly published, according to CPS, each = one hour and nextUpdate is setup to 24 hours as indication that maximum = recovery period is one day? Peter -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, January 07, 2013 4:32 PM To: pkix@ietf.org; rybar@nbusr.sk Subject: Re: [pkix] why revoked certificate entry has to be included in = one CRL issued beyond certificate validity period Peter, On 1/4/13 3:52 AM, Peter Rybar wrote: > The value in nextUpdate is only a wish or presumption of CA when CA=20 > must be able to publish and at least one CRL will be published.=20 The CPS for a CA may state that the nextUpdate value is a binding=20 commitment by the CA, contrary to your comment above. In general, this value is a time/date by which the=20 CA will publish a new CRL, though that does not preclude publication prior to that time. It also would be poor CA practice to regularly publish CRLs well short=20 of the nextUpdate value, as someone has suggested. Steve From piyush@ditenity.com Tue Jan 8 09:06: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 3208E21F84C7 for ; Tue, 8 Jan 2013 09:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 dCn0TfyAGyC8 for ; Tue, 8 Jan 2013 09:06:58 -0800 (PST) Received: from mail-gg0-f180.google.com (mail-gg0-f180.google.com [209.85.161.180]) by ietfa.amsl.com (Postfix) with ESMTP id ACF7121F841B for ; Tue, 8 Jan 2013 09:06:52 -0800 (PST) Received: by mail-gg0-f180.google.com with SMTP id c4so126549ggn.11 for ; Tue, 08 Jan 2013 09:06:40 -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=6gNWfY2wIJVu8buMgUcbauCumlsPKOvFwpSFU+ilQKY=; b=XGKaCWKdxuJ7pToPZxcvZ+LL+GlQow0mMFJ97FscUupI+YWAP7Hwb4lkwOq6dY10Hw ecKa+mAIaqWIRR6A5XKHqQF8HNeQMbB7q4HTH2Z9UWDa3ZoElwY9U22lRDCEOhvJHZRY H7Tb8fJwsStF2r8zKyOl71+MGm3B5tYVD2A724tU5W0L9039LHN5RmZ0KHVl3CAjdczl 1rV71uoDtAGu/y3gaGPjC/QoaTEd24MWmnwebBJ4LVDt9nQVd13gKfd4tnxbfT58srRY fuyEPQ63/GwUtuywN/W3xnPX74CGUh7q8wRDOaY5NjKlu0vuZJd0s7zq5l1Gd/skRzHR D6Yw== X-Received: by 10.101.105.29 with SMTP id h29mr21116442anm.62.1357664799835; Tue, 08 Jan 2013 09:06:39 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id g26sm33137190yhi.15.2013.01.08.09.06.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 09:06:38 -0800 (PST) From: "Piyush Jain" To: =?UTF-8?Q?'Ahmet_YETG=C4=B0N_=28B=C4=B0LGEM-UEKAE=29'?= , References: <87401118.471748.1357633592763.JavaMail.root@tubitak.gov.tr> <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> In-Reply-To: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> Date: Tue, 8 Jan 2013 09:06:36 -0800 Message-ID: <03a901cdedc2$8540fec0$8fc2fc40$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AA_01CDED7F.771FE1A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGutVfRieUbStlIaUnGSNdzeRqvR5h+FGfA Content-Language: en-us X-Gm-Message-State: ALoCoQn6x49TNMKHmKnMBW0HHWnVgBerPelC/IsEb7H6yuT6H8ty3LMDchCLrFWmxr4XS9/BcRjN Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 08 Jan 2013 17:06:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AA_01CDED7F.771FE1A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see inline =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Ahmet YETGIN (BILGEM-UEKAE) Sent: Tuesday, January 08, 2013 12:47 AM To: pkix@ietf.org Subject: [pkix] Lack of AIA and/or CDP Extensions =20 Hi, =20 We have an disagreement between our testing group about meaning of = missing extensions. =20 For example when validation a QES, if a certificate has an AIA = extension, but not CDP extension, and CA is=20 publishing both CRL and COSP responses,=20 =20 1. Can I use CRL for revocation checking as a first choice? [Piyush] Absolutely. Use whatever is optimal for you application. The = presence (or absence) of these extension does imply importance of one = over other. Many deployments ignore these extensions completely and use = locally configured uris for fetching OCSP responses or CRLs. 2. If I cant, can I use CRL if I cant reach OCSP for any technical = error/reason. [Piyush] You can use whatever source that is available to you to = determine the revocation status as long as you make sure that the source = is trustworthy. (Problem here is I need to know that CRL publishing address, and in our = example I have it from elsewhere,=20 from another certificates OCSPs extensions in the same path. Weird = example, yes.) [Piyush] Does not matter. What matters is that you ensure that the CRL = that you fetched is authoritative to provide you the status of = certificate you are validating. =20 So rephrasing the question, do nonexistence of CDP, means dont use CRLs; = and same question goes for AIA. [Piyush] No and No Our collegues reason their interpretation from RFC 5280 pg94 =20 If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. And CWA 14171 5.7.3 Rules for the use of Revocation Status information The verifier should take into account information in the certificate in deciding how best to obtain and check the revocation status (e.g. a=20 certificate extension field about authority information access or a CRL=20 distribution=20 which I believe is a misinterpretation. [Piyush] I would agree with you. You can take into account all the = information in the certificate and still determine that a locally cached = CRL or a locally configured responder is the best means of checking the = revocation status. Please note you can that you can always have a local policy which says = prefer OCSP over CRL or vice-versa. However that policy is not = determined by presence or absence of any extension in the certificate. Do we miss anything about the case here, like any other standart, spec = etc? If anyone can point me the right direction,=20 thats highly appreciated. Best Regards. Ahmet Yetgin =20 ------=_NextPart_000_03AA_01CDED7F.771FE1A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please see inline

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Ahmet YETGIN (BILGEM-UEKAE)
Sent: Tuesday, January 08, = 2013 12:47 AM
To: pkix@ietf.org
Subject: [pkix] Lack = of AIA and/or CDP Extensions

 

Hi,

 

We have an disagreement = between our testing group about meaning of missing = extensions.

 

For example when = validation a QES, if a certificate has an AIA extension, but not CDP = extension, and CA is

publishing both CRL and = COSP responses,

 

1.      = Can I use CRL = for revocation checking as a first choice?

[Piyush] Absolutely. Use = whatever is optimal for you application. The presence (or absence) of = these extension does imply importance of one over other. Many = deployments ignore these extensions completely and use locally = configured uris for fetching OCSP responses or = CRLs.

2.      = If I cant, = can I use CRL if I cant reach OCSP for any technical = error/reason.

[Piyush] = You can use whatever = source that is available to you to determine the revocation status as = long as you make sure that the source is trustworthy.

(Problem here is I need to = know that CRL publishing address, and in our example I have it from = elsewhere,

from another certificates OCSPs extensions in the = same path. Weird example, yes.)

[Piyush] Does not matter. What matters is that you ensure that the = CRL that you fetched is authoritative to provide you the status of = certificate you are validating.

 

So rephrasing the = question, do nonexistence of CDP, means dont use CRLs; and same question = goes for AIA.

[Piyush] = No and No

Our collegues reason their = interpretation from RFC 5280 pg94

 

If the revocation status has not been determined, =
repeat the process
=C2=A0=C2=A0 above with any available CRLs not =
specified in a distribution point
=C2=A0=C2=A0 but issued by the certificate =
issuer.=C2=A0 For the processing of such =
a
=C2=A0=C2=A0 =
CRL, assume a DP with both the reasons and the cRLIssuer =
fields
=C2=A0=C2=A0 omitted and a distribution point name =
of the certificate issuer.

And CWA 14171
 5.7.3 Rules for the use of =
Revocation Status information

 The verifier = should take into account information in the = certificate
in deciding how best to obtain and check the = revocation status (e.g. a
certificate extension field about = authority information access or a CRL
distribution 

which I believe is a = misinterpretation.

[Piyush] I would agree with you. You can take into account all the = information in the certificate and still determine that a locally cached = CRL or a locally configured responder is the best means of checking the = revocation status.

Please note you can that you can always have a local policy which = says prefer OCSP over CRL or vice-versa. However that policy is not = determined by presence or absence of any extension in the = certificate.

Do we miss = anything about the case here, like any other standart, spec etc? If = anyone can point me the right direction, 
thats highly = appreciated.

Best = Regards.

Ahmet = Yetgin

 

------=_NextPart_000_03AA_01CDED7F.771FE1A0-- From kent@bbn.com Tue Jan 8 09:45: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 8B9BE1F0CFB for ; Tue, 8 Jan 2013 09:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.499 X-Spam-Level: X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 g5j-FVW+kLre for ; Tue, 8 Jan 2013 09:45:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9A1F0CFA for ; Tue, 8 Jan 2013 09:45:14 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:50504) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TsdEe-0002QK-4S; Tue, 08 Jan 2013 12:45:12 -0500 Message-ID: <50EC5B27.7090007@bbn.com> Date: Tue, 08 Jan 2013 12:45:11 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org, ahmet.yetgin@tubitak.gov.tr References: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> In-Reply-To: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> Content-Type: multipart/alternative; boundary="------------090502010809030407080904" Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 08 Jan 2013 17:45:16 -0000 This is a multi-part message in MIME format. --------------090502010809030407080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/8/13 3:46 AM, Ahmet YETGI.N (BI.LGEM-UEKAE) wrote: > Hi, > > We have an disagreement between our testing group about meaning of > missing extensions. > > For example when validation a QES, if a certificate has an AIA > extension, but not CDP extension, and CA is > publishing both CRL and COSP responses, > > 1. Can I use CRL for revocation checking as a first choice? yes. that's a local choice. > 2. If I cant, can I use CRL if I cant reach OCSP for any technical > error/reason. that's OK too. > (Problem here is I need to know that CRL publishing address, and in > our example I have it from elsewhere, > from another certificates OCSPs extensions in the same path. Weird > example, yes.) > > So rephrasing the question, do nonexistence of CDP, means dont use > CRLs; and same question goes for AIA. no, the lack of a CRLDP does not imply that the CA does not want RPs to check a CRL issued by that CA. > > Our collegues reason their interpretation from RFC 5280 pg94 > > If the revocation status has not been determined, repeat the process > above with any available CRLs not specified in a distribution point > but issued by the certificate issuer. For the processing of such a > CRL, assume a DP with both the reasons and the cRLIssuer fields > omitted and a distribution point name of the certificate issuer. > > And*CWA 14171* > * *5.7.3 Rules for the use of Revocation Status information > > The verifier should take into account *information in the certificate > *in deciding how best to obtain and check the revocation status (e.g. a > certificate extension field about authority information access or a CRL > distribution > > which I believe is a misinterpretation. > If the authors of 14171 believe that the cited text in 5280 implies the underlined and both text above, then I agree with you that they have overreached. Steve --------------090502010809030407080904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/8/13 3:46 AM, Ahmet YETGİN (BİLGEM-UEKAE) wrote:
Hi,

We have an disagreement between our testing group about meaning of missing extensions.

For example when validation a QES, if a certificate has an AIA extension, but not CDP extension, and CA is
publishing both CRL and COSP responses,

1. Can I use CRL for revocation checking as a first choice?
yes. that's a local choice.
2. If I cant, can I use CRL if I cant reach OCSP for any technical error/reason.
that's OK too.
(Problem here is I need to know that CRL publishing address, and in our example I have it from elsewhere,
from another certificates OCSPs extensions in the same path. Weird example, yes.)

So rephrasing the question, do nonexistence of CDP, means dont use CRLs; and same question goes for AIA.
no, the lack of a CRLDP does not imply that the CA does not want RPs to check a CRL issued by that CA.

Our collegues reason their interpretation from RFC 5280 pg94

If the revocation status has not been determined, repeat the process
   above with any available CRLs not specified in a distribution point
   but issued by the certificate issuer.  For the processing of such a
   CRL, assume a DP with both the reasons and the cRLIssuer fields
   omitted and a distribution point name of the certificate issuer.

And CWA 14171
 5.7.3 Rules for the use of Revocation Status information

 The verifier should take into account information in the certificate
in deciding how best to obtain and check the revocation status (e.g. a
certificate extension field about authority information access or a CRL
distribution 

which I believe is a misinterpretation.

If the authors of 14171 believe that the cited text in 5280 implies the underlined and
both text above, then I agree with you that they have overreached.

Steve
--------------090502010809030407080904-- From kent@bbn.com Tue Jan 8 09:48: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 474EB21F8542 for ; Tue, 8 Jan 2013 09:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.966 X-Spam-Level: X-Spam-Status: No, score=-105.966 tagged_above=-999 required=5 tests=[AWL=0.634, 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 cEvvLO+2-4XN for ; Tue, 8 Jan 2013 09:48:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B24801F0CFC for ; Tue, 8 Jan 2013 09:48:26 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:50505) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TsdHl-0002SD-Mk; Tue, 08 Jan 2013 12:48:25 -0500 Message-ID: <50EC5BE9.4020105@bbn.com> Date: Tue, 08 Jan 2013 12:48:25 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Rybar , pkix References: <201301081658.r08Gwu3I054200@mail.nbusr.sk> In-Reply-To: <201301081658.r08Gwu3I054200@mail.nbusr.sk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 08 Jan 2013 17:48:27 -0000 Peter, On 1/8/13 11:59 AM, Peter Rybar wrote: > Steve, > I agree, CA must be able to setup the time/date value in nextUpdate according to conditions defined e.g. in CPS. > But the background of such rules is sometimes funny like it is not only according to max time while CA is able to recovery CA technology from some accident but also according to a number of days in holidays :-) > > What is wrong when CRL is regularly published, according to CPS, each one hour and nextUpdate is setup to 24 hours as indication that maximum recovery period is one day? > > What's wrong is that RPs have no requirement to check for a new CRL before than the indicated NextUpdate. Regularly publishing a CRL 20X more frequently than the indicated nextUpdate suggests a confused CA. if the CA wants to publish CRLs regularly at 1 hour intervals, then out that info into the CRLs. Steve From tmiller@mitre.org Tue Jan 8 10:40:56 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 1DED721F8583 for ; Tue, 8 Jan 2013 10:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 uLsdhjsiw0dV for ; Tue, 8 Jan 2013 10:40:55 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28C11E80A2 for ; Tue, 8 Jan 2013 10:40:55 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB81B5311674; Tue, 8 Jan 2013 13:40:54 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D00955311668; Tue, 8 Jan 2013 13:40:54 -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; Tue, 8 Jan 2013 13:40:54 -0500 From: "Miller, Timothy J." To: =?utf-8?B?QWhtZXQgWUVUR8SwTiAoIELEsExHRU0tVUVLQUUp?= , "pkix@ietf.org" Thread-Topic: [pkix] Lack of AIA and/or CDP Extensions Thread-Index: odhgC324fp3dR+eD9fib+opgOzCZIusbd6CA Date: Tue, 8 Jan 2013 18:40:54 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200067002BF@IMCMBX01.MITRE.ORG> In-Reply-To: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.31.40.47] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 08 Jan 2013 18:40:56 -0000 T24gMS84LzEzIDI6NDYgQU0sICJBaG1ldCBZRVRHxLBOIChCxLBMR0VNLVVFS0FFKSINCjxhaG1l dC55ZXRnaW5AdHViaXRhay5nb3YudHI+IHdyb3RlOg0KDQo+V2UgaGF2ZSBhbiBkaXNhZ3JlZW1l bnQgYmV0d2VlbiBvdXIgdGVzdGluZyBncm91cCBhYm91dCBtZWFuaW5nIG9mDQo+bWlzc2luZyBl eHRlbnNpb25zLg0KPg0KPkZvciBleGFtcGxlIHdoZW4gdmFsaWRhdGlvbiBhIFFFUywgaWYgYSBj ZXJ0aWZpY2F0ZSBoYXMgYW4gQUlBIGV4dGVuc2lvbiwNCj5idXQgbm90IENEUCBleHRlbnNpb24s IGFuZCBDQSBpcw0KPnB1Ymxpc2hpbmcgYm90aCBDUkwgYW5kIENPU1AgcmVzcG9uc2VzLA0KPg0K PjEuIENhbiBJIHVzZSBDUkwgZm9yIHJldm9jYXRpb24gY2hlY2tpbmcgYXMgYSBmaXJzdCBjaG9p Y2U/DQo+Mi4gSWYgSSBjYW50LCBjYW4gSSB1c2UgQ1JMIGlmIEkgY2FudCByZWFjaCBPQ1NQIGZv ciBhbnkgdGVjaG5pY2FsDQo+ZXJyb3IvcmVhc29uLg0KPg0KPihQcm9ibGVtIGhlcmUgaXMgSSBu ZWVkIHRvIGtub3cgdGhhdCBDUkwgcHVibGlzaGluZyBhZGRyZXNzLCBhbmQgaW4gb3VyDQo+ZXhh bXBsZSBJIGhhdmUgaXQgZnJvbSBlbHNld2hlcmUsDQo+ZnJvbSBhbm90aGVyIGNlcnRpZmljYXRl cyBPQ1NQcyBleHRlbnNpb25zIGluIHRoZSBzYW1lIHBhdGguIFdlaXJkDQo+ZXhhbXBsZSwgeWVz LikNCg0KSSBndWVzcyBteSBjb3VudGVyLXF1ZXN0aW9uIGlzICJXaHkgd291bGRuJ3QgeW91PyIg IElmIE9DU1AgaXMgbm90DQpyZWFjaGFibGUsIGFuZCB5b3Uga25vdyBmcm9tIGFub3RoZXIgY29u dGV4dCB0aGF0IGEgQ1JMIGlzIGF2YWlsYWJsZSwgaXMNCnRoZXJlIGhhcm0gaW4gZ2V0dGluZyBp dD8NCg0KSG93ZXZlciwgaWYgdGhlIGlzc3VlciBpcyBpc3N1aW5nIENSTHMgYnV0IGlzbid0IHBv cHVsYXRpbmcgQ0RQLCB0aGlzDQpzb3VuZHMgbW9yZSBsaWtlIGEgbWlzY29uZmlndXJhdGlvbiBv ciBhIGNvbnRyaXZlZCB0aG91Z2h0IGV4cGVyaW1lbnQgdGhhbg0KYSByZWFsIHVzZSBjYXNlLiAg SSBjYW4ndCB0aGluayBvZiBhIHJlYXNvbiB3aHkgeW91J2QgcHJvZHVjZSBDUkxzIGJ1dCBub3QN CnB1Ymxpc2ggdGhlaXIgbG9jYXRpb25zIGZvciByZWx5aW5nIHBhcnRpZXMgKGJ1dCBJJ20gc3Vy ZSBzb21lb25lIG9uIHRoZQ0KbGlzdCB3aWxsIGVkdWNhdGUgbWUgOikuDQoNCj5TbyByZXBocmFz aW5nIHRoZSBxdWVzdGlvbiwgZG8gbm9uZXhpc3RlbmNlIG9mIENEUCwgbWVhbnMgZG9udCB1c2Ug Q1JMczsNCj5hbmQgc2FtZSBxdWVzdGlvbiBnb2VzIGZvciBBSUEuDQoNCkkgZG9uJ3QgdGhpbmsg YW55dGhpbmcgc3RvcHMgeW91IGZyb20gdHJ5aW5nLiAgQWJzZW5jZSBvZiBBSUEgZG9lc24ndCBt ZWFuDQpPQ1NQIGlzbid0IGFsbG93ZWQ7IGl0IHNpbXBseSBtZWFucyBhbiBvdXQtb2YtYmFuZCBt ZXRob2QgaXMgbmVlZGVkIHRvDQpjb21tdW5pY2F0ZSB0aGUgbG9jYXRpb24uDQoNCi0tIFQNCg0K From tmiller@mitre.org Tue Jan 8 10:48: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 EFFEF11E80BF for ; Tue, 8 Jan 2013 10:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 OhAACkNuC1mU for ; Tue, 8 Jan 2013 10:48:37 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6F611E80A5 for ; Tue, 8 Jan 2013 10:48:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E1E201FF54B; Tue, 8 Jan 2013 13:48:36 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 967CE1FF8E6; Tue, 8 Jan 2013 13:47:51 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:47:51 -0500 From: "Miller, Timothy J." To: Stephen Kent , Peter Rybar , pkix Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN7chbn7/gW7Wk60CbQPL0xhIa3Zg/tPuA Date: Tue, 8 Jan 2013 18:47:50 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200067002F5@IMCMBX01.MITRE.ORG> In-Reply-To: <50EC5BE9.4020105@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.31.40.47] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 08 Jan 2013 18:48:38 -0000 On 1/8/13 11:48 AM, "Stephen Kent" wrote: >Peter, > >On 1/8/13 11:59 AM, Peter Rybar wrote: >> Steve, >> I agree, CA must be able to setup the time/date value in nextUpdate >>according to conditions defined e.g. in CPS. >> But the background of such rules is sometimes funny like it is not only >>according to max time while CA is able to recovery CA technology from >>some accident but also according to a number of days in holidays :-) >> >> What is wrong when CRL is regularly published, according to CPS, each >>one hour and nextUpdate is setup to 24 hours as indication that maximum >>recovery period is one day? > >What's wrong is that RPs have no requirement to check for a new CRL >before than the indicated NextUpdate. Regularly publishing a CRL 20X more >frequently >than the indicated nextUpdate suggests a confused CA. if the CA wants to >publish CRLs >regularly at 1 hour intervals, then out that info into the CRLs. In practice, we found that RP software frequently attempts to find a fresh CRL at higher periodicity than nextUpdate, but also presumes stale CRLs are invalid and so will create denial of service when there's a retrieval failure. Producing CRLs at a higher frequency than indicated in nextUpdate covers for this case; a transient failure in CRL availability does not result in widespread DoS, because CRLs are valid for multiple production intervals. E.g., DoD CRLs are produced at 18 hour intervals, but nextUpdate is set as production time + 7 days. -- T From kent@bbn.com Tue Jan 8 11:12: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 3831A21F847F for ; Tue, 8 Jan 2013 11:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 GJY9EPknNSXc for ; Tue, 8 Jan 2013 11:12:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B1DAD21F8479 for ; Tue, 8 Jan 2013 11:12:06 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:50552) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tseaj-0007nO-5C; Tue, 08 Jan 2013 14:12:05 -0500 Message-ID: <50EC6F85.7020802@bbn.com> Date: Tue, 08 Jan 2013 14:12:05 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Miller, Timothy J." References: <195DB2510AAA004391F58E28FCE21200067002F5@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200067002F5@IMCMBX01.MITRE.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 08 Jan 2013 19:12:07 -0000 Tim, 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 ... Steve From tmiller@mitre.org Tue Jan 8 11:22: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 B0E0521F85D6 for ; Tue, 8 Jan 2013 11:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 EFiu+utFwwma for ; Tue, 8 Jan 2013 11:22:52 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F421F85C6 for ; Tue, 8 Jan 2013 11:22:52 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B8DE7200749; Tue, 8 Jan 2013 14:22:51 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AA4BA200723; Tue, 8 Jan 2013 14:22:51 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 14:22:51 -0500 From: "Miller, Timothy J." To: Stephen Kent Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN7chbn7/gW7Wk60CbQPL0xhIa3Zg/tPuAgABrXYD//55sAA== Date: Tue, 8 Jan 2013 19:22:51 +0000 Message-ID: <195DB2510AAA004391F58E28FCE2120006700384@IMCMBX01.MITRE.ORG> In-Reply-To: <50EC6F85.7020802@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.31.40.47] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 08 Jan 2013 19:22:52 -0000 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. -- T On 1/8/13 1:12 PM, "Stephen Kent" wrote: >Tim, > >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 ... > >Steve > > From DPKemp@missi.ncsc.mil Tue Jan 8 13:33: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 CE4C521F847F for ; Tue, 8 Jan 2013 13:33:34 -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 1-TAJuiKbub2 for ; Tue, 8 Jan 2013 13:33:34 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC621F8479 for ; Tue, 8 Jan 2013 13:33:33 -0800 (PST) Received: from clavin.missi.ncsc.mil (squid.missi.ncsc.mil [144.51.60.169]) by stingray.missi.ncsc.mil with ESMTP id r08LXWKm073838 for ; Tue, 8 Jan 2013 16:33:32 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.52]) by SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec%14]) with mapi id 14.02.0328.009; Tue, 8 Jan 2013 16:33:32 -0500 From: "Kemp, David P." To: pkix Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: AQHN7chbn7/gW7Wk60CbQPL0xhIa3Zg/tPuAgABrXYD//55sAIAAMrzw Date: Tue, 8 Jan 2013 21:33:31 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC85AC6AB66@clavin.missi.ncsc.mil> References: <50EC6F85.7020802@bbn.com> <195DB2510AAA004391F58E28FCE2120006700384@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE2120006700384@IMCMBX01.MITRE.ORG> 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] 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: Tue, 08 Jan 2013 21:33:34 -0000 To be fair, the last time this came up a few years ago PKIX missed the oppo= rtunity 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 tim= e jawboning RP software vendors to stop treating nextUpdate as an expiratio= n date.=20 Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, 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 While I appreciate and would prefer the BOFH approach to deficiency remedia= tion, practically speaking you can't push a rope. :) Absent an enforcemen= t regime (e.g., trademark licensing a la VPNC or USB-IF) we're stuck with w= hat we get. -- T On 1/8/13 1:12 PM, "Stephen Kent" wrote: >Tim, > >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=20 >the bad RP software. This is just another example of why accmmodating=20 >bad software leads to more bad software ... > >Steve > > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Tue Jan 8 15:36: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 52BC821F84D5 for ; Tue, 8 Jan 2013 15:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 SQSzF6Z4cNMd for ; Tue, 8 Jan 2013 15:36:13 -0800 (PST) Received: from mail-gg0-f181.google.com (mail-gg0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id B944121F8644 for ; Tue, 8 Jan 2013 15:36:13 -0800 (PST) Received: by mail-gg0-f181.google.com with SMTP id s6so220689ggc.12 for ; Tue, 08 Jan 2013 15:36:13 -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=RSXXB3o9sfBG9Ve6oVsu24MLC+wEaOIG0ku/MTgkYHE=; b=QgVA74MNfIPLzdQNLji91isNac0Gr1M7Z9JO4zcHLHyjI7oJ2AhYfeJxn1dEv1IqzO Y1Y3+RJIOKA0pLjhnW/tXSiLepe5lFSHiB64PB541FWljNnUJWB/BoR6Af6qZEeQ4P2L CwTcqNcd22Bcywm9/HIvq9lJJD+Ec7F/rNNhCUIVMB5XGYqek64f9BE5YrNJp30XabzH PyMnda0NdhfQIdAFKaDV5Or1keP/ShqDy56RofJMAeTnOISBWqLfcmEQBRYy3ap5+3N0 2+prUULIO3AoN2UA8YcqPxEI4/qZ8a/fTE0x7jEmAJmFdZVh6sRL86u9nh75e7raUg/Y vtcQ== X-Received: by 10.236.75.3 with SMTP id y3mr26204682yhd.66.1357688173159; Tue, 08 Jan 2013 15:36:13 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id n12sm64899788ani.7.2013.01.08.15.36.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 15:36:12 -0800 (PST) From: "Piyush Jain" To: "'Kemp, David P.'" , "'pkix'" References: <50EC6F85.7020802@bbn.com> <195DB2510AAA004391F58E28FCE2120006700384@IMCMBX01.MITRE.ORG> <5B1D7E570380A64989D4C069F7D14BC85AC6AB66@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC85AC6AB66@clavin.missi.ncsc.mil> Date: Tue, 8 Jan 2013 15:36:09 -0800 Message-ID: <043401cdedf8$f11749c0$d345dd40$@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: AQKoXDtfl0N7LF5u/tTfGbHz5keTHgIG8sgRAX/QIM2Wbv+P0A== Content-Language: en-us X-Gm-Message-State: ALoCoQlXUZ72NTOfwCI9CcRWtlSxb/GmdaHc/iEqzuWfZFhCVrZgTlRbi3GBNjD4xulVLu9u8B33 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: Tue, 08 Jan 2013 23:36:15 -0000 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. CA should not and cannot make that determination for a relying party. 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. > -----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 > > 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. > > Dave > > > > -----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 > > 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. > > -- T > > On 1/8/13 1:12 PM, "Stephen Kent" wrote: > > >Tim, > > > >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 ... > > > >Steve > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Tue Jan 8 20:39: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 54B7F21F8510 for ; Tue, 8 Jan 2013 20:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 C9S93IkzbqSd for ; Tue, 8 Jan 2013 20:39:51 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC21F0CB3 for ; Tue, 8 Jan 2013 20:39:51 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5DCD11E23858 for ; Wed, 9 Jan 2013 05:39: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 j9JLKaWu2zpb for ; Wed, 9 Jan 2013 05:39:49 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0B23A1E23857 for ; Wed, 9 Jan 2013 05:39:49 +0100 (CET) Received: (qmail 548 invoked from network); 9 Jan 2013 04:39:48 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Jan 2013 04:39:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 09 Jan 2013 05:39:47 +0100 From: Stefan Santesson To: Peter Rybar , 'Piyush Jain' , 'pkix' Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <201301081618.r08GI1x4054036@mail.nbusr.sk> X-Priority: 1 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 09 Jan 2013 04:39:52 -0000 Peter; On 1/8/13 5:18 PM, "Peter Rybar" wrote: >Stefan, >The terminology is not clear for someone who will see: >The revocation is of "non-issued certificate". >Because by reading the text it is expected that the certificate was >issued, but fraudulently. What part of the text supports that? > >The revocation with a new extension is only about fraudulently issued >certificate. It means this new extension and revocation is not used when >the certificate is not issued and only fake random certificate serial >number was created in OCSP request. What? How in this physical universe would the OCSP responder tell the difference??? Crystal ball? > >While it is intended only for fraudulently issued certificate where >fraudulently issued certificate can potentially reuse any already used >certificate-serial-number the extension must contain e.g. a positive >confirmation of existence in the form of hash value of fraudulently >issued certificate. No that is a task for another possible effort. It's not part of this update. But this update paves the way for such extension. Which I'm not against. It's just not part of this update effort. > >Only according to the hash value of fraudulently issued certificate >relaying party and OCSP responder is able to identify fraudulently issued >certificate because CA was compromised and serial numbers of certificates >are not any longer unique for compromised CA. > >Conclusion: >Positive statement extension as a hash value of the certificate whose >status OCSP response is providing can be used in this case: > when the certificate is revoked, > when the certificate is good and also > when the certificate is fraudulently issued. > >For that reason it can be more helpful to define in RFC one positive >statement extension as a hash value of the certificate whose status the >OCSP response is providing and define in RFC that it will support >situations when status is: > -- good > -- revoked >And for randomly created certificate serial numbers without records in >OCSP database will be use: > -- unknown No, we have been through this and determined WG consensus. Unknown is not the choice, since it may not have the desired effect (to indicate that a certificate with this serial number should not be trusted). It's important that this works with legacy clients. They will be around for a while. /Stefan > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > From ferda.topcan@tubitak.gov.tr Wed Jan 9 01:01: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 BDB7921F84C8 for ; Wed, 9 Jan 2013 01:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TR=0.935] 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 2xhA97TaiQKi for ; Wed, 9 Jan 2013 01:01:55 -0800 (PST) Received: from mta01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id B81FA21F8446 for ; Wed, 9 Jan 2013 01:01:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id 894821C40D4; Wed, 9 Jan 2013 11:01:38 +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 2IFCrhy3ky_7; Wed, 9 Jan 2013 11:01:17 +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 1D2E01C40B6; Wed, 9 Jan 2013 10:58:03 +0200 (EET) From: Ferda Topcan To: "'Miller, Timothy J.'" , References: <985765481.477633.1357634808670.JavaMail.root@tubitak.gov.tr> <195DB2510AAA004391F58E28FCE21200067002BF@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200067002BF@IMCMBX01.MITRE.ORG> Date: Wed, 9 Jan 2013 10:58:02 +0200 (EET) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraConnectorForOutlook/7.1.4.6356) Thread-Index: iE3wwYSSPIVOxanefIUNz0QZ6R+4mw== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Originating-IP: [10.250.10.217] Thread-Topic: Lack of AIA and/or CDP Extensions Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 09:01:55 -0000 Hello Timothy, I would like to explain my opinion about this topic: A CA can produce different types of certificates from the same Issuer. And the method of obtaining revocation information for each type of certificate may be different. For example a subCA can produce QES and OCSP Certificates. The subCA may choose to publish revocation info from OCSP for QES but CRL for OCSP Certificate for some reason. In this case how the verifier knows how to check the revocation info unless its is specified in related cerficate= ? If you would answer this question I'd appreciate it. Thanks in advance, Best Regards. Ferda TOPCAN Chief Researcher ................................................................ Disclaimer -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Tuesday, January 08, 2013 8:41 PM To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" wrote: >We have an disagreement between our testing group about meaning of >missing extensions. > >For example when validation a QES, if a certificate has an AIA extension= , >but not CDP extension, and CA is >publishing both CRL and COSP responses, > >1. Can I use CRL for revocation checking as a first choice? >2. If I cant, can I use CRL if I cant reach OCSP for any technical >error/reason. > >(Problem here is I need to know that CRL publishing address, and in our >example I have it from elsewhere, >from another certificates OCSPs extensions in the same path. Weird >example, yes.) I guess my counter-question is "Why wouldn't you?" If OCSP is not reachable, and you know from another context that a CRL is available, is there harm in getting it? However, if the issuer is issuing CRLs but isn't populating CDP, this sounds more like a misconfiguration or a contrived thought experiment tha= n a real use case. I can't think of a reason why you'd produce CRLs but no= t publish their locations for relying parties (but I'm sure someone on the list will educate me :). >So rephrasing the question, do nonexistence of CDP, means dont use CRLs; >and same question goes for AIA. I don't think anything stops you from trying. Absence of AIA doesn't mea= n OCSP isn't allowed; it simply means an out-of-band method is needed to communicate the location. -- T _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From liaquat.khan@ascertia.com Wed Jan 9 03:36: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 19DEE21F869A for ; Wed, 9 Jan 2013 03:36:08 -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 YSsiOXTmhB-w for ; Wed, 9 Jan 2013 03:36:07 -0800 (PST) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id B260621F8651 for ; Wed, 9 Jan 2013 03:36:05 -0800 (PST) Received: from [10.0.1.5] ([86.183.28.150]) by ascertia.com with MailEnable ESMTP; Wed, 9 Jan 2013 11:38:26 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 09 Jan 2013 11:35:23 +0000 From: Liaquat Khan To: Ferda Topcan , "'Miller, Timothy J.'" , Message-ID: Thread-Topic: [pkix] Lack of AIA and/or CDP Extensions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 11:36:08 -0000 I think it's also worth looking at it from a legal point of view. If the CA is wanting you to use a particular approach (OCSP or CRL) as defined in its CP then if you as a Relying Party want to show that you have fulfilled your obligations it's better to use the approach recommended by the CA. Of course in normal case this is not easy as end-users do not generally read the CP document, or have the expertise to configure their settings in the RP application - so generally it will be what's contained in the cert and local default settings in the RP application. Regards LK=20 On 09/01/2013 08:58, "Ferda Topcan" wrote: >Hello Timothy, > >I would like to explain my opinion about this topic: A CA can produce >different types of certificates from the same Issuer. And the method of >obtaining revocation information for each type of certificate may be >different. For example a subCA can produce QES and OCSP Certificates. The >subCA may choose to publish revocation info from OCSP for QES but CRL for >OCSP Certificate for some reason. In this case how the verifier knows how >to check the revocation info unless its is specified in related cerficate? > >If you would answer this question I'd appreciate it. > >Thanks in advance, >Best Regards. > >Ferda TOPCAN >Chief Researcher >................................................................ > > > >Disclaimer >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Miller, Timothy J. >Sent: Tuesday, January 08, 2013 8:41 PM >To: Ahmet YETG=C4=B0N ( B=C4=B0LGEM-UEKAE); pkix@ietf.org >Subject: Re: [pkix] Lack of AIA and/or CDP Extensions > >On 1/8/13 2:46 AM, "Ahmet YETG=C4=B0N (B=C4=B0LGEM-UEKAE)" > wrote: > >>We have an disagreement between our testing group about meaning of >>missing extensions. >> >>For example when validation a QES, if a certificate has an AIA extension, >>but not CDP extension, and CA is >>publishing both CRL and COSP responses, >> >>1. Can I use CRL for revocation checking as a first choice? >>2. If I cant, can I use CRL if I cant reach OCSP for any technical >>error/reason. >> >>(Problem here is I need to know that CRL publishing address, and in our >>example I have it from elsewhere, >>from another certificates OCSPs extensions in the same path. Weird >>example, yes.) > >I guess my counter-question is "Why wouldn't you?" If OCSP is not >reachable, and you know from another context that a CRL is available, is >there harm in getting it? > > > >However, if the issuer is issuing CRLs but isn't populating CDP, this >sounds more like a misconfiguration or a contrived thought experiment than >a real use case. I can't think of a reason why you'd produce CRLs but not >publish their locations for relying parties (but I'm sure someone on the >list will educate me :). > >>So rephrasing the question, do nonexistence of CDP, means dont use CRLs; >>and same question goes for AIA. > >I don't think anything stops you from trying. Absence of AIA doesn't mean >OCSP isn't allowed; it simply means an out-of-band method is needed to >communicate the location. > >-- T > >_______________________________________________ >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 ferda.topcan@tubitak.gov.tr Wed Jan 9 03:59: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 3E14821F8598 for ; Wed, 9 Jan 2013 03:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TR=0.935] 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 TUAQPPKEMg4p for ; Wed, 9 Jan 2013 03:59:49 -0800 (PST) Received: from mta01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 949C221F858A for ; Wed, 9 Jan 2013 03:59:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id E80611C2151; Wed, 9 Jan 2013 13:59:38 +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 83BBIZugcYlA; Wed, 9 Jan 2013 13:59:35 +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 E13BA1C2E2A; Wed, 9 Jan 2013 13:59:13 +0200 (EET) From: Ferda Topcan To: "'Liaquat Khan'" , References: In-Reply-To: Date: Wed, 9 Jan 2013 13:59:13 +0200 (EET) Message-ID: <893e0664.00000168.0000000a@UEKAE-PC> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraConnectorForOutlook/7.1.4.6356) Thread-Index: W9pKB8QWvMNGDMd28JNSbmURXJtN7A== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Originating-IP: [10.250.10.217] Thread-Topic: Lack of AIA and/or CDP Extensions Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 11:59:50 -0000 Thanks for your response to my question. As I understand from the discussions this issue is not considered in standards. And I think it is = a missing part of revocation issue. Best Regards. Ferda TOPCAN -----Original Message----- From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] Sent: Wednesday, January 09, 2013 1:35 PM To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions I think it's also worth looking at it from a legal point of view. If the CA is wanting you to use a particular approach (OCSP or CRL) as defined i= n its CP then if you as a Relying Party want to show that you have fulfille= d your obligations it's better to use the approach recommended by the CA. Of course in normal case this is not easy as end-users do not generally read the CP document, or have the expertise to configure their settings i= n the RP application - so generally it will be what's contained in the cert and local default settings in the RP application. Regards LK On 09/01/2013 08:58, "Ferda Topcan" wrote: >Hello Timothy, > >I would like to explain my opinion about this topic: A CA can produce >different types of certificates from the same Issuer. And the method of >obtaining revocation information for each type of certificate may be >different. For example a subCA can produce QES and OCSP Certificates. Th= e >subCA may choose to publish revocation info from OCSP for QES but CRL fo= r >OCSP Certificate for some reason. In this case how the verifier knows ho= w >to check the revocation info unless its is specified in related cerficate? > >If you would answer this question I'd appreciate it. > >Thanks in advance, >Best Regards. > >Ferda TOPCAN >Chief Researcher >................................................................ > > > >Disclaimer >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Miller, Timothy J. >Sent: Tuesday, January 08, 2013 8:41 PM >To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org >Subject: Re: [pkix] Lack of AIA and/or CDP Extensions > >On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" > wrote: > >>We have an disagreement between our testing group about meaning of >>missing extensions. >> >>For example when validation a QES, if a certificate has an AIA extension, >>but not CDP extension, and CA is >>publishing both CRL and COSP responses, >> >>1. Can I use CRL for revocation checking as a first choice? >>2. If I cant, can I use CRL if I cant reach OCSP for any technical >>error/reason. >> >>(Problem here is I need to know that CRL publishing address, and in our >>example I have it from elsewhere, >>from another certificates OCSPs extensions in the same path. Weird >>example, yes.) > >I guess my counter-question is "Why wouldn't you?" If OCSP is not >reachable, and you know from another context that a CRL is available, is >there harm in getting it? > > > >However, if the issuer is issuing CRLs but isn't populating CDP, this >sounds more like a misconfiguration or a contrived thought experiment than >a real use case. I can't think of a reason why you'd produce CRLs but not >publish their locations for relying parties (but I'm sure someone on the >list will educate me :). > >>So rephrasing the question, do nonexistence of CDP, means dont use CRLs= ; >>and same question goes for AIA. > >I don't think anything stops you from trying. Absence of AIA doesn't mean >OCSP isn't allowed; it simply means an out-of-band method is needed to >communicate the location. > >-- T > >_______________________________________________ >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 Jan 9 05:19:56 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 4455F21F86C8 for ; Wed, 9 Jan 2013 05:19:56 -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=[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 FGHSMGN10te3 for ; Wed, 9 Jan 2013 05:19:54 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id B394521F868D for ; Wed, 9 Jan 2013 05:19:53 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 74EF91CF38 for ; Wed, 9 Jan 2013 14:19:52 +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 2013010914195208-6320 ; Wed, 9 Jan 2013 14:19:52 +0100 Message-ID: <50ED6E74.3010209@bull.net> Date: Wed, 09 Jan 2013 14:19:48 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <893e0664.00000168.0000000a@UEKAE-PC> In-Reply-To: <893e0664.00000168.0000000a@UEKAE-PC> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/01/2013 14:19:52, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/01/2013 14:19:52, Serialize complete at 09/01/2013 14:19:52 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------030401040303030701090104" Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 13:19:56 -0000 This is a multi-part message in MIME format. --------------030401040303030701090104 Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: quoted-printable Hi Liaquat, It has been a long time since we exchanged emails. :-) You said: "it's better to use the approach recommended by the CA". I do=20 think this is the right answer. A Relying Party will apply a validation policy or a signature policy (=20 if the goal is to verifying an electronic signature). The RP will select the validation or signature policy which is adequate=20 for the context. The rules that are applied are defined in that policy. Theses rules may say at the first level : use CRLs, or use OCSP=20 responses or use any of them. At the second level, they may enforce freshness conditions such as : if you retrieve a CRL from the local cache, it MUST not be older than=20 two hours. In this way, the nextUpdate date that is included in CRLs is not=20 relevant: the CA does not dictate the validation rules. Denis > Thanks for your response to my question. As I understand from the > discussions this issue is not considered in standards. And I think it i= s a > missing part of revocation issue. > > Best Regards. > Ferda TOPCAN > > > -----Original Message----- > From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] > Sent: Wednesday, January 09, 2013 1:35 PM > To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org > Subject: Re: [pkix] Lack of AIA and/or CDP Extensions > > I think it's also worth looking at it from a legal point of view. If th= e > CA is wanting you to use a particular approach (OCSP or CRL) as defined= in > its CP then if you as a Relying Party want to show that you have fulfil= led > your obligations it's better to use the approach recommended by the CA. > > Of course in normal case this is not easy as end-users do not generally > read the CP document, or have the expertise to configure their settings= in > the RP application - so generally it will be what's contained in the ce= rt > and local default settings in the RP application. > > Regards > LK > > > On 09/01/2013 08:58, "Ferda Topcan" wrote= : > >> Hello Timothy, >> >> I would like to explain my opinion about this topic: A CA can produce >> different types of certificates from the same Issuer. And the method o= f >> obtaining revocation information for each type of certificate may be >> different. For example a subCA can produce QES and OCSP Certificates. = The >> subCA may choose to publish revocation info from OCSP for QES but CRL = for >> OCSP Certificate for some reason. In this case how the verifier knows = how >> to check the revocation info unless its is specified in related > cerficate? >> If you would answer this question I'd appreciate it. >> >> Thanks in advance, >> Best Regards. >> >> Ferda TOPCAN >> Chief Researcher >> ................................................................ >> >> >> >> Disclaimer >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >> Miller, Timothy J. >> Sent: Tuesday, January 08, 2013 8:41 PM >> To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org >> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >> >> On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" >> wrote: >> >>> We have an disagreement between our testing group about meaning of >>> missing extensions. >>> >>> For example when validation a QES, if a certificate has an AIA > extension, >>> but not CDP extension, and CA is >>> publishing both CRL and COSP responses, >>> >>> 1. Can I use CRL for revocation checking as a first choice? >>> 2. If I cant, can I use CRL if I cant reach OCSP for any technical >>> error/reason. >>> >>> (Problem here is I need to know that CRL publishing address, and in o= ur >>> example I have it from elsewhere, >> >from another certificates OCSPs extensions in the same path. Weird >>> example, yes.) >> I guess my counter-question is "Why wouldn't you?" If OCSP is not >> reachable, and you know from another context that a CRL is available, = is >> there harm in getting it? >> >> >> >> However, if the issuer is issuing CRLs but isn't populating CDP, this >> sounds more like a misconfiguration or a contrived thought experiment > than >> a real use case. I can't think of a reason why you'd produce CRLs but > not >> publish their locations for relying parties (but I'm sure someone on t= he >> list will educate me :). >> >>> So rephrasing the question, do nonexistence of CDP, means dont use CR= Ls; >>> and same question goes for AIA. >> I don't think anything stops you from trying. Absence of AIA doesn't > mean >> OCSP isn't allowed; it simply means an out-of-band method is needed to >> communicate the location. >> >> -- T >> >> _______________________________________________ >> 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 --------------030401040303030701090104 Content-Type: text/html; charset=ISO-8859-9 Content-Transfer-Encoding: quoted-printable
Hi Liaquat,

It has been a long time since we exchanged emails. :-)

You said: "it's better to use the approach recommended by the CA". I do think this is the right answer.

A Relying Party will apply a validation policy or a signature policy ( if the goal is to verifying an electronic signature).
The RP will select the validation or signature policy which is adequate for the context.
The rules that are applied are defined in that policy.

Theses rules may say at the first level : use CRLs, or use OCSP responses or use any of them.

At the second level, they may enforce freshness conditions such as :
if you retrieve a CRL from the local cache, it MUST not be older than two hours.

In this way, the nextUpdate date that is included in CRLs is not relevant: the CA does not dictate the validation rules.
=A0
Denis

Thanks for your response to my question. As I unders=
tand from the
discussions this issue is not considered in standards. And I think it is =
a
missing part of revocation issue.

Best Regards.
Ferda TOPCAN


-----Original Message-----
From: Liaquat Khan [mailto:liaquat.khan@ascertia.com]
Sent: Wednesday, January 09, 2013 1:35 PM
To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions

I think it's also worth looking at it from a legal point of view. If the
CA is wanting you to use a particular approach (OCSP or CRL) as defined i=
n
its CP then if you as a Relying Party want to show that you have fulfille=
d
your obligations it's better to use the approach recommended by the CA.

Of course in normal case this is not easy as end-users do not generally
read the CP document, or have the expertise to configure their settings i=
n
the RP application - so generally it will be what's contained in the cert
and local default settings in the RP application.

Regards
LK


On 09/01/2013 08:58, "Ferda Topcan" <ferda.topcan@tubitak.gov.tr=
> wrote:


Hello Timothy,

I would like to explain my opinion about this topic: A CA can produce
different types of certificates from the same Issuer. And the method of
obtaining revocation information for each type of certificate may be
different. For example a subCA can produce QES and OCSP Certificates. The
subCA may choose to publish revocation info from OCSP for QES but CRL for
OCSP Certificate for some reason. In this case how the verifier knows how
to check the revocation info unless its is specified in related

cerficate?

If you would answer this question I'd appreciate it.

Thanks in advance,
Best Regards.

Ferda TOPCAN
Chief Researcher
................................................................

&l=
t;http://www.tubitak.gov.tr/>

Disclaimer <http://www.tubitak.gov.tr/disclaimer>
-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On =
Behalf Of
Miller, Timothy J.
Sent: Tuesday, January 08, 2013 8:41 PM
To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions

On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)"
<ahmet.yetgin@tubitak.gov.tr> wrote:


We have an disagreement between our testing grou=
p about meaning of
missing extensions.

For example when validation a QES, if a certificate has an AIA

extension,

but not CDP extension, and CA is
publishing both CRL and COSP responses,

1. Can I use CRL for revocation checking as a first choice?
2. If I cant, can I use CRL if I cant reach OCSP for any technical
error/reason.

(Problem here is I need to know that CRL publishing address, and in our
example I have it from elsewhere,

>from another certificates OCSPs extensions in =
the same path. Weird

example, yes.)

I guess my counter-question is "Why wouldn't you?"  If OCSP is not
reachable, and you know from another context that a CRL is available, is
there harm in getting it?



However, if the issuer is issuing CRLs but isn't populating CDP, this
sounds more like a misconfiguration or a contrived thought experiment

than

a real use case.  I can't think of a reason why yo=
u'd produce CRLs but

not

publish their locations for relying parties (but I=
'm sure someone on the
list will educate me :).


So rephrasing the question, do nonexistence of C=
DP, means dont use CRLs;
and same question goes for AIA.

I don't think anything stops you from trying.  Absence of AIA doesn't

mean

OCSP isn't allowed; it simply means an out-of-band=
 method is needed to
communicate the location.

-- T

_______________________________________________
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

--------------030401040303030701090104-- From ferda.topcan@tubitak.gov.tr Wed Jan 9 05:57:51 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 5720221F8732 for ; Wed, 9 Jan 2013 05:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_TR=0.935, 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 8rk8YrGZotAJ for ; Wed, 9 Jan 2013 05:57:50 -0800 (PST) Received: from mta01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0428621F854B for ; Wed, 9 Jan 2013 05:57:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id 73E501C2080; Wed, 9 Jan 2013 15:57:41 +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 8bfCBqQea5gb; Wed, 9 Jan 2013 15:57:38 +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 5E7F31C3127; Wed, 9 Jan 2013 15:57:38 +0200 (EET) From: Ferda Topcan To: "'Denis Pinkas'" , References: <893e0664.00000168.0000000a@UEKAE-PC> <50ED6E74.3010209@bull.net> In-Reply-To: <50ED6E74.3010209@bull.net> Date: Wed, 9 Jan 2013 15:57:38 +0200 (EET) Message-ID: <5a2dc3de.00000168.0000001c@UEKAE-PC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CDEE81.F970BF00" X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraConnectorForOutlook/7.1.4.6356) Thread-Index: dct2eAY9I6Pq1VPsVwbLjiXRJE9g5w== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Originating-IP: [10.250.10.217] Thread-Topic: Lack of AIA and/or CDP Extensions Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 13:57:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01CDEE81.F970BF00 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hi Denis, Nice to see an answer from you. Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these policies in practice as Liaquat said. So, = I think it would be better if standards put rules about how to reach revocation info. Verifier has only signer's certificate in hand to validate the signature. I think signer's certificate SHOULD contain CDP o= r AIA extension or both. E-signature standards are more applicable than the policies in terms of interoperability. Thanks for your response. Ferda Topcan _____ From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Wednesday, January 09, 2013 3:20 PM To: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions Hi Liaquat, It has been a long time since we exchanged emails. :-) You said: "it's better to use the approach recommended by the CA". I do think this is the right answer. A Relying Party will apply a validation policy or a signature policy ( if the goal is to verifying an electronic signature). The RP will select the validation or signature policy which is adequate for the context. The rules that are applied are defined in that policy. Theses rules may say at the first level : use CRLs, or use OCSP responses or use any of them. At the second level, they may enforce freshness conditions such as : if you retrieve a CRL from the local cache, it MUST not be older than two hours. In this way, the nextUpdate date that is included in CRLs is not relevant= : the CA does not dictate the validation rules. Denis Thanks for your response to my question. As I understand from the discussions this issue is not considered in standards. And I think it is = a missing part of revocation issue. Best Regards. Ferda TOPCAN -----Original Message----- From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] Sent: Wednesday, January 09, 2013 1:35 PM To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions I think it's also worth looking at it from a legal point of view. If the CA is wanting you to use a particular approach (OCSP or CRL) as defined i= n its CP then if you as a Relying Party want to show that you have fulfille= d your obligations it's better to use the approach recommended by the CA. Of course in normal case this is not easy as end-users do not generally read the CP document, or have the expertise to configure their settings i= n the RP application - so generally it will be what's contained in the cert and local default settings in the RP application. Regards LK On 09/01/2013 08:58, "Ferda Topcan" wrote: Hello Timothy, I would like to explain my opinion about this topic: A CA can produce different types of certificates from the same Issuer. And the method of obtaining revocation information for each type of certificate may be different. For example a subCA can produce QES and OCSP Certificates. The subCA may choose to publish revocation info from OCSP for QES but CRL for OCSP Certificate for some reason. In this case how the verifier knows how to check the revocation info unless its is specified in related cerficate? If you would answer this question I'd appreciate it. Thanks in advance, Best Regards. Ferda TOPCAN Chief Researcher ................................................................ Disclaimer -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Tuesday, January 08, 2013 8:41 PM To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" wrote= : We have an disagreement between our testing group about meaning of missing extensions. For example when validation a QES, if a certificate has an AIA extension, but not CDP extension, and CA is publishing both CRL and COSP responses, 1. Can I use CRL for revocation checking as a first choice? 2. If I cant, can I use CRL if I cant reach OCSP for any technical error/reason. (Problem here is I need to know that CRL publishing address, and in our example I have it from elsewhere, >from another certificates OCSPs extensions in the same path. Weird example, yes.) I guess my counter-question is "Why wouldn't you?" If OCSP is not reachable, and you know from another context that a CRL is available, is there harm in getting it? However, if the issuer is issuing CRLs but isn't populating CDP, this sounds more like a misconfiguration or a contrived thought experiment than a real use case. I can't think of a reason why you'd produce CRLs but not publish their locations for relying parties (but I'm sure someone on the list will educate me :). So rephrasing the question, do nonexistence of CDP, means dont use CRLs; and same question goes for AIA. I don't think anything stops you from trying. Absence of AIA doesn't mean OCSP isn't allowed; it simply means an out-of-band method is needed to communicate the location. -- T _______________________________________________ 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 ------=_NextPart_000_0089_01CDEE81.F970BF00 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

Hi = Denis,

 

Nice to see an answer from you. =

 

Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these = policies in practice as Liaquat said. So, I think it would be better if standards = put rules about how to reach revocation info. =A0Verifier has only signer's = certificate in hand to validate the signature. I think signer's certificate SHOULD = contain CDP or AIA extension or both.

 

E-signature standards are more = applicable than the policies in terms of = interoperability.

 

Thanks for your response. =

 

Ferda Topcan

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Denis Pinkas
Sent: Wednesday, January = 09, 2013 3:20 PM
To: pkix@ietf.org
Subject: Re: [pkix] Lack = of AIA and/or CDP Extensions

 

Hi = Liaquat,

It has been a long time since we exchanged emails. :-)

You said: "it's better to use the approach recommended by the = CA". I do think this is the right answer.

A Relying Party will apply a validation policy or a signature policy ( = if the goal is to verifying an electronic signature).

The RP will select the validation or signature policy which is adequate = for the context.
The rules that are applied are defined in that policy.

Theses rules may say at the first level : use CRLs, or use OCSP = responses or use any of them.

At the second level, they may enforce freshness conditions such as : =
if you retrieve a CRL from the local cache, it MUST not be older than = two hours.

In this way, the nextUpdate date that is included in CRLs is not = relevant: the CA does not dictate the validation rules.
 
Denis

Thanks for your response to my question. As I =
understand from the
discussions this issue is not considered in =
standards. And I think it is a
missing part of revocation =
issue.
 
Best =
Regards.
Ferda =
TOPCAN
 
 
-----Original =
Message-----
From: Liaquat Khan [mailto:liaquat.khan@ascertia.co=
m]
Sent: Wednesday, January 09, 2013 1:35 =
PM
To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org<=
/pre>
Subject: Re: [pkix] Lack of AIA and/or CDP =
Extensions
 
I think it's also worth looking at it from a =
legal point of view. If the
CA is wanting you to use a particular =
approach (OCSP or CRL) as defined =
in
its CP then if you as a Relying Party want to =
show that you have fulfilled
your obligations it's better to use the =
approach recommended by the CA.
 
Of course in normal case this is not easy as =
end-users do not generally
read the CP document, or have the expertise =
to configure their settings in
the RP application - so generally it will be =
what's contained in the cert
and local default settings in the RP =
application.
 
Regards
LK
 
 
On 09/01/2013 08:58, "Ferda Topcan" <ferda.topcan@tubitak.gov.=
tr> wrote:
 



Hello =
Timothy,
 
I would like to explain my opinion about this =
topic: A CA can produce
different types of certificates from the same =
Issuer. And the method of
obtaining revocation information for each =
type of certificate may be
different. For example a subCA can produce =
QES and OCSP Certificates. The
subCA may choose to publish revocation info =
from OCSP for QES but CRL for
OCSP Certificate for some reason. In this =
case how the verifier knows how
to check the revocation info unless its is =
specified in related



cerficate?



 
If you would answer this question I'd =
appreciate it.
 
Thanks in =
advance,
Best =
Regards.
 
Ferda =
TOPCAN
Chief =
Researcher
..............................................=
..................
 
<http://www.tubitak.gov.tr/>
 
Disclaimer <http://www.tubitak.gov.=
tr/disclaimer>
-----Original =
Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] =
On Behalf Of
Miller, Timothy =
J.
Sent: Tuesday, January 08, 2013 8:41 =
PM
To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org<=
/pre>
Subject: Re: [pkix] Lack of AIA and/or CDP =
Extensions
 
On 1/8/13 2:46 AM, "Ahmet YETG=DDN =
(B=DDLGEM-UEKAE)"
<ahmet.yetgin@tubitak.gov.=
tr> wrote:
 



We have an disagreement between our testing =
group about meaning of
missing =
extensions.
 
For example when validation a QES, if a =
certificate has an AIA






extension,






but not CDP extension, and CA =
is
publishing both CRL and COSP =
responses,
 
1. Can I use CRL for revocation checking as a =
first choice?
2. If I cant, can I use CRL if I cant reach =
OCSP for any technical
error/reason.
 
(Problem here is I need to know that CRL =
publishing address, and in our
example I have it from =
elsewhere,
>from another certificates OCSPs =
extensions in the same path. Weird
example, =
yes.)
 
I guess my counter-question is "Why =
wouldn't you?"=A0 If OCSP is =
not
reachable, and you know from another context =
that a CRL is available, is
there harm in getting =
it?
 
 
 
However, if the issuer is issuing CRLs but =
isn't populating CDP, this
sounds more like a misconfiguration or a =
contrived thought experiment
than
a real use case.=A0 I can't think of a reason =
why you'd produce CRLs but
not
publish their locations for relying parties =
(but I'm sure someone on the
list will educate me =
:).
 
So rephrasing the question, do nonexistence =
of CDP, means dont use CRLs;
and same question goes for =
AIA.
 
I don't think anything stops you from =
trying.=A0 Absence of AIA =
doesn't
mean
OCSP isn't allowed; it simply means an =
out-of-band method is needed to
communicate the =
location.
 
-- T
 
______________________________________________=
_
pkix mailing =
list
pkix@ietf.org<=
/pre>
https://www.ietf.org/=
mailman/listinfo/pkix
______________________________________________=
_
pkix mailing =
list
pkix@ietf.org<=
/pre>
https://www.ietf.org/=
mailman/listinfo/pkix
 



 
 
 
______________________________________________=
_
pkix mailing =
list
pkix@ietf.org<=
/pre>
https://www.ietf.org/=
mailman/listinfo/pkix

 

------=_NextPart_000_0089_01CDEE81.F970BF00-- From denis.pinkas@bull.net Wed Jan 9 06:30: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 F3B7121F8783 for ; Wed, 9 Jan 2013 06:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 O+hlKQ9eyyN1 for ; Wed, 9 Jan 2013 06:30:24 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF721F8751 for ; Wed, 9 Jan 2013 06:30:22 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 084FA1CF41; Wed, 9 Jan 2013 15:30:22 +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 2013010915302109-6510 ; Wed, 9 Jan 2013 15:30:21 +0100 Message-ID: <50ED7EFA.9040607@bull.net> Date: Wed, 09 Jan 2013 15:30:18 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ferda Topcan References: <893e0664.00000168.0000000a@UEKAE-PC> <50ED6E74.3010209@bull.net> <5a2dc3de.00000168.0000001c@UEKAE-PC> In-Reply-To: <5a2dc3de.00000168.0000001c@UEKAE-PC> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/01/2013 15:30:21, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 09/01/2013 15:30:21 Content-Type: multipart/alternative; boundary="------------040300060604030709040107" Cc: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 14:30:26 -0000 --------------040300060604030709040107 Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: quoted-printable Ferda, RFC 5280 is a base standard. There are other standards built upon them. In France, thiis is the case for PKIs used by the Administration. Here is an example extracted from such a document (if you can read French) : Denis > Hi Denis, > > Nice to see an answer from you. > > Yes, we can solve this issue with a validation/signature policy. But=20 > no one composes and applies these policies in practice as Liaquat=20 > said. So, I think it would be better if standards put rules about how=20 > to reach revocation info. Verifier has only signer's certificate in=20 > hand to validate the signature. I think signer's certificate SHOULD=20 > contain CDP or AIA extension or both. > > E-signature standards are more applicable than the policies in terms=20 > of interoperability. > > Thanks for your response. > > Ferda Topcan > > ------------------------------------------------------------------------ > > *From:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf=20 > Of *Denis Pinkas > *Sent:* Wednesday, January 09, 2013 3:20 PM > *To:* pkix@ietf.org > *Subject:* Re: [pkix] Lack of AIA and/or CDP Extensions > > Hi Liaquat, > > It has been a long time since we exchanged emails. :-) > > You said: "it's better to use the approach recommended by the CA". I=20 > do think this is the right answer. > > A Relying Party will apply a validation policy or a signature policy (=20 > if the goal is to verifying an electronic signature). > > The RP will select the validation or signature policy which is=20 > adequate for the context. > The rules that are applied are defined in that policy. > > Theses rules may say at the first level : use CRLs, or use OCSP=20 > responses or use any of them. > > At the second level, they may enforce freshness conditions such as : > if you retrieve a CRL from the local cache, it MUST not be older than=20 > two hours. > > In this way, the nextUpdate date that is included in CRLs is not=20 > relevant: the CA does not dictate the validation rules. > > Denis > >> Thanks for your response to my question. As I understand from the >> discussions this issue is not considered in standards. And I think it is= a >> missing part of revocation issue. >> =20 >> Best Regards. >> Ferda TOPCAN >> =20 >> =20 >> -----Original Message----- >> From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] >> Sent: Wednesday, January 09, 2013 1:35 PM >> To:Ferda Topcan; 'Miller, Timothy J.';pkix@ietf.org >> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >> =20 >> I think it's also worth looking at it from a legal point of view. If the >> CA is wanting you to use a particular approach (OCSP or CRL) as defined = in >> its CP then if you as a Relying Party want to show that you have fulfill= ed >> your obligations it's better to use the approach recommended by the CA. >> =20 >> Of course in normal case this is not easy as end-users do not generally >> read the CP document, or have the expertise to configure their settings = in >> the RP application - so generally it will be what's contained in the cert >> and local default settings in the RP application. >> =20 >> Regards >> LK >> =20 >> =20 >> On 09/01/2013 08:58, "Ferda Topcan" wrote: >> =20 >>> Hello Timothy, >>> =20 >>> I would like to explain my opinion about this topic: A CA can produce >>> different types of certificates from the same Issuer. And the method of >>> obtaining revocation information for each type of certificate may be >>> different. For example a subCA can produce QES and OCSP Certificates. T= he >>> subCA may choose to publish revocation info from OCSP for QES but CRL f= or >>> OCSP Certificate for some reason. In this case how the verifier knows h= ow >>> to check the revocation info unless its is specified in related >> cerficate? >>> =20 >>> If you would answer this question I'd appreciate it. >>> =20 >>> Thanks in advance, >>> Best Regards. >>> =20 >>> Ferda TOPCAN >>> Chief Researcher >>> ................................................................ >>> =20 >>> >>> =20 >>> Disclaimer >>> -----Original Message----- >>> From:pkix-bounces@ietf.org [mailto:pki= x-bounces@ietf.org] On Behalf Of >>> Miller, Timothy J. >>> Sent: Tuesday, January 08, 2013 8:41 PM >>> To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE);pkix@ietf.org >>> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >>> =20 >>> On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" >>> wr= ote: >>> =20 >>>> We have an disagreement between our testing group about meaning of >>>> missing extensions. >>>> =20 >>>> For example when validation a QES, if a certificate has an AIA >> extension, >>>> but not CDP extension, and CA is >>>> publishing both CRL and COSP responses, >>>> =20 >>>> 1. Can I use CRL for revocation checking as a first choice? >>>> 2. If I cant, can I use CRL if I cant reach OCSP for any technical >>>> error/reason. >>>> =20 >>>> (Problem here is I need to know that CRL publishing address, and in our >>>> example I have it from elsewhere, >>> >from another certificates OCSPs extensions in the same path. Weird >>>> example, yes.) >>> =20 >>> I guess my counter-question is "Why wouldn't you?" If OCSP is not >>> reachable, and you know from another context that a CRL is available, is >>> there harm in getting it? >>> =20 >>> =20 >>> =20 >>> However, if the issuer is issuing CRLs but isn't populating CDP, this >>> sounds more like a misconfiguration or a contrived thought experiment >> than >>> a real use case. I can't think of a reason why you'd produce CRLs but >> not >>> publish their locations for relying parties (but I'm sure someone on the >>> list will educate me :). >>> =20 >>>> So rephrasing the question, do nonexistence of CDP, means dont use CRL= s; >>>> and same question goes for AIA. >>> =20 >>> I don't think anything stops you from trying. Absence of AIA doesn't >> mean >>> OCSP isn't allowed; it simply means an out-of-band method is needed to >>> communicate the location. >>> =20 >>> -- T >>> =20 >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> =20 >> =20 >> =20 >> =20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > = --------------040300060604030709040107 Content-Type: multipart/related; boundary="------------050109010104010006010003" --------------050109010104010006010003 Content-Type: text/html; charset=ISO-8859-9 Content-Transfer-Encoding: quoted-printable
Ferda,

RFC 5280 is a base standard. There are other standards built upon them.

In France, thiis is the case for PKIs used by the Administration.

Here is an example extracted from such a document (if you can read French) :

3D""

Denis


Hi Denis,

=A0<= /font>

Nice to see an answer from you.

=A0<= /font>

Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these policies in practice as Liaquat said. So, I think it would be better if standards put rules about how to reach revocation info. =A0Verifier has only signer's certificate in hand to validate the signature. I think signer's certificate SHOULD contain CDP or AIA extension or both.

=A0<= /font>

E-signature standards are more applicable than the policies in terms of interoperability.<= /span>

=A0<= /font>

Thanks for your response.

=A0<= /font>

F= erda Topcan

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of De= nis Pinkas
Sent: Wednesday, January 09, 2013 3:20 PM
To: pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions=

=A0

Hi Liaquat,

It has been a long time since we exchanged emails. :-)

You said: "it's better to use the approach recommended by the CA". I do think this is the right answer.

A Relying Party will apply a validation policy or a signature policy ( if the goal is to verifying an electronic signature).

The RP will select the validation or signature policy which is adequate for the context.
The rules that are applied are defined in that policy.

Theses rules may say at the first level : use CRLs, or use OCSP responses or use any of them.

At the second level, they may enforce freshness conditions such as :
if you retrieve a CRL from the local cache, it MUST not be older than two hours.

In this way, the nextUpdate date that is included in CRLs is not relevant: the CA does not dictate the validation rules.
=A0
Denis

Thanks for your response to my ques=
tion. As I understand from the
discussions this issue is not considered in st=
andards. And I think it is a
missing part of revocation issue.
=A0
Best Regards.
Ferda TOPCAN
=A0
=A0
-----Original Message-----
From: Liaquat Khan [mailto:liaquat.khan@ascertia.co=
m]
Sent: Wednesday, January 09, 2013 1:35 PM=

To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP Ext=
ensions
=A0
I think it's also worth looking at it from a l=
egal point of view. If the
CA is wanting you to use a particular approach=
 (OCSP or CRL) as defined in
its CP then if you as a Relying Party want to =
show that you have fulfilled
your obligations it's better to use the approa=
ch recommended by the CA.
=A0
Of course in normal case this is not easy as e=
nd-users do not generally
read the CP document, or have the expertise to=
 configure their settings in
the RP application - so generally it will be w=
hat's contained in the cert
and local default settings in the RP applicati=
on.
=A0
Regards
LK
=A0
=A0
On 09/01/2013 08:58, "Ferda Topcan" <ferda.topcan@tubitak.gov.tr> wro=
te:
=A0
Hello Timothy,
=A0
I would like to explain my opinion about thi=
s topic: A CA can produce
different types of certificates from the sam=
e Issuer. And the method of
obtaining revocation information for each ty=
pe of certificate may be
different. For example a subCA can produce Q=
ES and OCSP Certificates. The
subCA may choose to publish revocation info =
from OCSP for QES but CRL for
OCSP Certificate for some reason. In this ca=
se how the verifier knows how
to check the revocation info unless its is s=
pecified in related
cerficate?=

=A0
If you would answer this question I'd apprec=
iate it.
=A0
Thanks in advance,<=
/pre>
              
Best Regards.

              
=A0

              
Ferda TOPCAN

              
Chief Researcher
              
............................................=
....................

              
=A0

              
<http://www.tubitak.gov.tr/>

              
=A0

              
Disclaimer <http://www.tubitak.gov.tr/dis=
claimer>

              
-----Original Message-----=


              
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.or=
g] On Behalf Of

              
Miller, Timothy J.<=
/pre>
              
Sent: Tuesday, January 08, 2013 8:41 PM=


              
To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org<=
/o:p>

              
Subject: Re: [pkix] Lack of AIA and/or CDP E=
xtensions

              
=A0

              
On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM=
-UEKAE)"

              
<ahmet.yetgin@tubitak.gov.tr> wrote:<=
o:p>

              
=A0

              

                
We have an disagreement between =
our testing group about meaning of

                
=
missing extensions.

                
=
=A0

                
=
For example when validation a QES, if a ce=
rtificate has an AIA

              

            
extension,=

but not CDP extension, and CA is=

=
publishing both CRL and COSP responses,
=
=A0
=
1. Can I use CRL for revocation checking a=
s a first choice?
=
2. If I cant, can I use CRL if I cant reac=
h OCSP for any technical
=
error/reason.
                
=
=A0

                
=
(Problem here is I need to know that CRL p=
ublishing address, and in our

                
=
example I have it from elsewhere,

              
>from another certificates OCSP=
s extensions in the same path. Weird
example, yes.)=

=A0
I guess my counter-question is "Why wouldn't=
 you?"=A0 If OCSP is not
reachable, and you know from another context=
 that a CRL is available, is
there harm in getting it?<=
/font>
=A0
=A0
=A0
However, if the issuer is issuing CRLs but i=
sn't populating CDP, this
sounds more like a misconfiguration or a con=
trived thought experiment
than
a real use case.=A0 I can't think =
of a reason why you'd produce CRLs but
not
publish their locations for relyin=
g parties (but I'm sure someone on the
list will educate me :).
=A0
So rephrasing the question, do n=
onexistence of CDP, means dont use CRLs;
=
and same question goes for AIA.=

=A0
I don't think anything stops you from trying=
.=A0 Absence of AIA doesn't
mean
OCSP isn't allowed; it simply mean=
s an out-of-band method is needed to
communicate the location.<=
/font>
=A0
-- T
=A0
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
              
pkix@ietf.org

              
https://www.ietf.org/mailman/listinfo/p=
kix

              
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F

              
pkix mailing list
              
pkix@ietf.org

              
https://www.ietf.org/mailman/listinfo/p=
kix

              
=A0

            
=A0
=A0
=A0
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
            
pkix@ietf.org

            
https://www.ietf.org/mailman/listinfo/pki=
x

=A0


= --------------050109010104010006010003 Content-Type: image/png; name="efhcaagh.png" Content-Disposition: inline; filename="efhcaagh.png" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA7AAAAF6CAIAAACvMyNuAAAgAElEQVR4nOy9v4vcSPcvrH9D8WQv k03mSJGSCd4nmeA60IUOrgMHBsMVdGBwsOCgocFgWO5AQTMvBsMgaDDmmgbRYBaWBmEWzCIEy/dr TCNYhucZhFiGxhR6g6qS6rek/jXdM+cT2T3dpdKpU6c+deqcU07FwXGcCvDosSM1OK5mAQAAAAAA PBI4EpkAbgGojo25gtICAAAAAADYBBpCDAAAAAAAAAAAPC5IhHi/jBxwiNiRGhxXswAAAAAAAB4J gBADNDgu5gpKCwAAAAAAYBMAIQZocFzMFZQWAAAAAADAJgBCDNDguJgrKC0AAAAAAIBNAIQYoMFx MVdQWgAAAAAAAJsACDFAg+NirqC0AAAAAAAANgEQYoAGx8VcQWkBAAAAAABsAiDEAA2Oi7mC0gIA AAAAANgEQIgBGhwXcwWlBQAAAAAAsAmAEAM0OC7mCkoLAAAAAABgEwAhBmhwXMwVlBYAAAAAAMAm AEIM0OC4mCsoLQAAAAAAgE0AhBigwXExV1BaAAAAAAAAmwAIMUCD42KuoLQAAAAAAAA2ARBigAbH xVxBaQEAAAAAAGwCIMQADY6LuYLSAgAAAAAA2AQPkBDjDPkOgeujFN93f44Rx8Vct9csLpOx57je aFHST4osnl6PAtcdxgWo0loo4tB1HHeA0uK+u7JT3Cajc8c5HyW3+3hamcXR+1FwBibuAICLeOg6 jhtM0tI+GmYlwXkSjQLXcRzHDcaz5P+OPNfxxklLg/36WWbz6HoUuGdhfLO9Zg8czIb7KNvVVLmJ wzPHOQ3Qt7L9y/eF/Rooij0If5toJcR3GbpwdHCDUZTkh/qOpNsXKLu7754cJRQ1oBafjb2O3BDe 00Bjc5VmiR2pNUpdTsTnOo6jI6Zqb8ssRiHbFnkhmiY5vonHH7g5WaRooKxhhBDXdo1TfiDEa4KM oD+Mlw9dfLfJ6HxPvB+nyHe3tOfHZTaPUOhxhv16muR4tYzGk+yO8y9oloDrOOMZgPbLbhg/7J0Q tWPe6zhftX3ToCTlNxR4g+g7rnCZTgK3lnArw+4BbnQeDyHmbPjuOFkRh67rDWcHy4eqqtqrgaLY i/C3Csfp4CHGy2jgOgK/LLPZKHCd00H0vcdrlt9QcNrNcGyImzg8O5YxOEBo1aCqVnkSjYJTx3FM g4iX0cA1aoW+2cY1YrIpq2X03HWfR0u92ojNrvL4teecBuPfSFNN84I+kO1yB0pBHZw7IsQ38+j3 B00X7jI0OGzHyZGC7DQ2I8RlGoW+45wGoyipp3OZxZQf1wafbBT5GbTKk6vQc3Vzln3Z8cMofRTj jlN0/mwDnkGGspb2Ko9fe2ZztxmID2JHhBgX84/zXnay+D2a9+3JGk+JQ3eHnAxn6HyrW5ftYB3Z 7qIbuxX+dtGJEOtfiXgpehGFNQkx9VX0+AVOke8+As/ErmAgxJXgstWOI06R/9TkmDc3W7uK9ZwY Z8g3zyih2XIx8tShXy2j57pTm7sMPb0/QrzK49f+w9ZSnEWT5FGwon1jY0JMrLHeeU/8lBxt0i0B zFGisKvd7iEPDjj7ONnoGJpYv/2cZ+6QEON8NvRf9Rh0vIyHT/v2pPdTql1zsrssut5qZMs2sJZs d4KHR4hxhnzV8tJju11PY1ymk+C8nzRxhvxHdCq0fdgJ8Unw8qXn6k/01ifEfhA+9xxHG4nVnRCT Y0HNXgin6NlEbqH8hsJfW2zZrlb3Vb54F7iP4UAZsAtsSIjJCQkfLi9htYyGQyshriM3ZB1+ZIR4 U+xpJSXYFSHG+W/j4LTHoON8MQ7cnj3p/RSCo+JkW8Bast0Vjkr4XQgxCQS5FzcAIQ19jb50AgXo jRZCHM6WLNBN5sTrE+LzMP6LxPWqnLgvIXbcYLyQHM132fSz4N/Kv0zQNOGd3DRR6VRY4LvpOZcS 47jBeJZxDIEeTDuOF06S5e3847z4D3vTGjp15fpzmy8mNCraDyfs3XCeTK9R6HNf4OJVyiy+bvok hPy3tsxeq8zmpjaqCpdZRM/Nw6skXwrhH6JERrNMS7w0cY1NMDqb+NxrFk2zTVSMHhqx19/mgn+c 02D0OaM6vMqTTxEKPXcY3y6TSeg5jsu2fyyuk2qC2PO/DelKfDi764Uo5hWjm4iE709Cumkcf0ln CiHu3CDrvNVIFvPxhDVuI8SKfV5naeDzvZYsHoOMnTTIRRZ/4MauDvZQI/75DAT6pjhPptFl6D1p nqIEJ0iR0MwaaDIKTLPe8JQ7WUmaWHDpcYZcXtP42u2AAC0hNk0HLYosGnq1ubj9PZr/zcc9yzO3 7jA/WPR0goP3NGCzjAmcyzDxUYax8Ska1CE9jhu8W6SfFO3t/Mo22WobkdKuNGPNXtBuXauq4uOX HMcLER+y3122RHpGA2XqA2cMi7v6Td3g3aLlhN8k/E4z9H7hOK2EWB8aQXKSpFknmapayXgVIa+t RlvXQmRZkPK4WuVV640bjBd/zNQAYpwn00tqZFuX0kcPjRpQEEIcFzRU15GDHDYixDcVXsZDSs74 k9weIRP4ezToaNmlN1MNVlVVnVZ3nM+G/mC8yHHNEetVFn+PBhc0mJJs3EVGZfQQ8/0JXl1Ofs9x xeRDHHvNguG+RLN5VuSzoXdCfX7lYuSdMT2naxjdvbS3THtQJmOv3lrU8aZsr4KX0cAfRllRMc9N 8y7lNxR49Onsh8Z8g3Ix8lxhkaaDSBY87jWDXy7RdZKvDPaHl55R7DRShZp1JplBtMScdXZfoNlv WfEjHvqON06K5WKshqET3TgfJbeGdKVVHr/2PCYiEmDQKMYyHl50FRGTCdt/Fln0y8vgXwIh7tEg M7/dOauGENexwopl7k+IOQGeBsN3ZF+G89mQXxGqiji22ZJcz7U6T4h1iXu0kADT7LXOXqJP8+wm j197urx76omUKRcu4qFLKz/gMp0EJ4Fm1hue8gb9os9pkz3Ehlxe4/ha7YAMlRCbpoN2oFbL6IUf RlmJmbtKJHzCoN8mo3MWWUfXC65l1dFG8zo4k7haRs+FedcpUJPknBCtwGUWDV8OnrpiBHzXV7bI tkjR4ETfCD39U6bGTRw+YePSYl0rqv/nzIgRk1jP6H6yNRgoSx94Yxi8uURXSV5nfJrVo1X4bTP0 vuE4rYRYNoX1lkKglXRFpLtkneDIiPImFafIP/FRiqsinYzfLvKfcmzGXYYu2rSfGKMzyn6EpVT6 AtlCQQGKdnQgxFVdqEHgxBsS4orfCDWcuAchbhYzAj9EcWdazMon9SLE+Hs08DjmITSCM+Tzyoa/ R89+6USITf0Rl09q6eTyTLfJ6Fw0W2RpqedFe8uEUguMik4ubk/LDQpeRs+GjS+tjwzVRZpM0mYW U1lxb2SXnk3sy2hwwjsFxadTISgkSRtEK6il/BZ4GQ1cvh2yapJerZbR8xN+gFpEdJehC3GUyeNq EfVpsN4RdT/HlF5fcEAovoU1Dw81zkuq3vxqKjp06Wpad0x9tJ5uWmJF6M90ESlcygFOkf+E5xbi hDI9Reeg1YZMyC/SMr4GO6BCp6WW6SBLpV6yK9YrFlejUtUiDvmQMPkLKiHWGCVRAToRYpwhX5i/ jNuxRvq9skG2OEO+0A2pEV1cOL84tlhX8t8zwT2RRaHHhN9btrrXbO8DaZaTVZv8W4XfYYbeJ1oJ MbULXvhrU8fK8UMU8Wd/dCuvsdfNS6qByCzSd7mc/jpJC+6T2lHUmhtHmDdvd5S90TIauPzGqwvJ fuzoRogrzqHLJLw5IW48Q019t16EmDTBDpfpHrf9PJq9XV9CLHOv2oC6w7jARO05J3qTIr0mIRbJ or6RIg7VQCPhRVpb1sYd8b8iX+Yd+axihvp0avJMS05nQqyOi0ErzGKXeXztkKONGy0++Rpv6+8y 9Izrs/QWVjsjE4s2EWkGVGRsvRpcmxDzsNTd3B4hFhdLbe0g8VddCXGH8EryQ35Rwyk6f8VNH+Os Nz9lXULcNr4djIm2A23TQS8TLp26LmWgTpxyMfK4Pu+JEOuURLAVPV9ZL1v1KXIj1ARxOyKcoXMW LNFmXdvyoHrLtlKGvr0POmnbE0BbhX/0hLhDAizdVUg+Fd3EE9ohC0YYza4Q/aG8hLTnxpHDVoGI i40QSt1srMnhwmOoiroRuhLiinfongboW7kNQlzxxTjdAUqL3oSYtMIHWRlruslv15MQK5WSG1yg 7K4J4XCD0fU8k3wM6xBi1W5qv2DPgm1tWT/x+fWJHXXJ9WjNlWtNMX/bJ8RmsQulrwWQpswrrtyH hh7p3sK+cqv80iYi7YCKH/ZqcEMPMZ3y5gCPLRJi/kP9iIuqskVCrDt3ZoTGWJ5fjAncHiFuG991 CXHbdJDBYhic02D0QQyItyj8Kk8+MoeaZSC2QYi1SiJ82PeVdbLVBX/LjWhI6jNR7Bbr2l1LO8q2 6uTDlgTelxC3C//YCXGHDEH1NLOqlJc0SfaJH4zrLZS0vWjNjVN9NuxB7IitiIc015JlEemyNAAy ZDVooBBi3qHr+MPZ58stEOKqamKUHcd7PYvfrUGIWffqpLHWstlrEOIOETh1dpfj8MVZd0aIZTbJ wBvEtpZNRkp0M7OkOjJMJFiWm3RdsQNCXBnELtgHHWwr7k0cnnEu9le+cCDegxDr6/YYoR1QgRD3 bJBxgnVDJlg8tKHI/24IscyNKERN3iYhlg6mb+IwYGsNrwlabJkQt47vmoS4dTpoUCfVOY7jejSe 2KTwRRaj0DvxQhSnv7cNxBYIsV5JeO3t/8om49MmbdESFnHoM89du3X9p4OW9pJtZYgNs1r4noS4 XfjVkRPiDtNMv/rKolEVSJWLfCzYdrmGLs9DOUasV+sQRdEUqHA39CLEgkNX2Kd2b1YlxBUXo2zb vldylYkPY40RYddwtNjBtT3EresrX22g+ymnhbZaPEN2QtzqIXZ9lGK7uRTESOwy8RU3USJ9KsPs hhBXlU7sbVTGtuLykr+Jw2dKxkyH9YbrfOeKe+2EuGeD9bFG50VIljbzFGqDVrdPiC9QfWeenhDv wkMsPL0q4rCp/tm6Dd6Jh9gyvht5iNcIIOSqHxiP10lAXb1rah+IvRDi/q9s9BC3surmubiIX51L EQ4262qy4XUH+sq26keI1/IQP3hC3MV2aK0Y4R+1Q05DGpRVU/EHa+MgOWjUtEwuA0/Yk61jlwF9 CXElOHS3RogrLka5OyGujzXFlvSrqfytdWOINYm3OPs8ze5Egs7SgY3O3Q79EWeKthHDy/I7zNaW DRa5mZV32eRSXvz4o231qi2cTada8e8ihtgkdtKyelbAqvLZV1wSo+Wj9Ec0kIuja4PE1PG9/Rr/ UajZKjYRte+LNOkvtgbrRciaW4Z/xNM/6F810jZXMm7NoRQuUec+NxFifnnWRz2yD7dMiElSvOuj P35EL87l1co463cTQ2wb341iiC3TQZZHOhnPG7ZKzgb13kQlzmcvhFive2oMcfdX1suWiLG1ETJH LlCaRoOBHC9qs65SSHrTl/Lrl6T42V+2lWHobX1YM2TCJvyjJsSdSpyooleLgDR7Mpz/9Vddq08V tDuMiyLPS8HM4b+zvzQMR548+Pt0/PYy9B13GN+W5T9ah391QDe4HDD6E+KKc+hujxBXXIxy9zrE upNcnCF/JyETzUGEUH64/IaG7zNc4QydC7VWmjzRdatMfI8Gp/Xk0jdCI2hFg1jEoSvtUa0t02Nx /sVxEQ/ZHdp3GRrw8uQi/pk/XiicWaTojeG+SVMBpo2S6uxiF6vy4TK9Gk5Ma4Da1RPPU9VVyd+3 PagufMane5pFRIi4wIe0ZQ06N1iPrymhAi/nk49NiXGttGm9POUmHduUwWXydtA1lFy6Cp66pVVq 0qw1+tSutQlx3eATzxNvR6PNirWl2azfPiFuG991CXHbdFClcf6CU0JuHW/N6+pA2pS3UO4Mb+ck kjNOI8x+r6yXLXc/eVPFSNMI/a3neZLPosW62peVdWRrKIPToQ89kurahd9hht4nLISY8Zu2Si5E rFyBzKHHhxZVnDEt/owmX3K211fPINzwU5rETXE0dxgX//4afdLfEk6aJd0r0yn6mBZ/It91/Hez 2eevJW4MKCsljfPFZDjU1AkCiDAzV1L+0KAS1E3YnxCXi5GxcCbzQ/S6mEOwU7TEtbV6IgHz6inl vTS+Ga6DSsV4pw5tp7nGdeVOvu5po8B3+TyKNe3XR9u+WFK37oxSp1MSmlBj8lyoutDSctXsbIWy r+eMP9EqE+znS1qyl8hcLQ5vc0bS1YWVSc4Xk8txHf7rDuPiTjmgr+tZ6sfFJnYpFIeAtdxaFFO3 ipA/kDWJXwxsD1pPRHWgdpl+eDP4l9uICPdssKqaEPDTYPSeCycrsvjDeIS48vu1tKWtZq35PC80 1yemWa7WFPXmHVkpT2FjQyzMqVBgW7hDni7JhKPj/PcJGof8jQ+aupx2aFl4ZZ/1uuqf5Eeqkuh3 JhqzYxtfox2Q0VdLtT9vBogveEyG73yU3OL8y1X84yfhgmRSl9ls/NJ/QnhPnkw+ZpgVsBotSryc X82XuN74ETVb5YsPaPzSo33iQp64p2h6SQkWM03lt8mb509dvpE+r2yUbbdGtL6JqmqzrlWHZaWn bDVD39IHpplcmhbbA7cVlbcIv22GapvdFxxHQ4jVxHm7+cBl9pm7j+O9HKpLtZzb2hoKM3GXoNCy qQKxlsGO6ZsCQDdxeCbcpMKX31LS/AEmOBrmqiRWa41v+Q0Fgx6EWE7X1WfZ26/vdtQY4jqHktqp ELXGj8s9uUDZrfjK1gCeJnVPKEiFsw/j+K86yla+CogoMFtg1FapF/Al+jymNwM2zKNNdEKRDemW I3vLDfirmKQv3GWTy3iZslBC/s6wqqrEO5YsJboo6kwd4rb5J0MXjhei6FOSL8Ws8LMw/lP5RPb2 WcVe8XcpcT3vpuHVTRw+0adMaH7IB1gr9keyTi0i4sysG4xm6TIeulREBnPX0iD7yZSbKU6HmiHC ZqAuO9AZRtJGPVgv0TWrI64rIi6ote4LdTIlWXFwivwTL7yMpskyld6lm1OqiEM9iecj1Bt5KxIT S4bzcvipFitwffQ1NZkd7fh2MqG6oeQvqtBMB20T6WQcL+u3FnWMZVfXecPSpL6T1/T6MqBmlW/y dIlnFGfId/wQXdf2W3mKDmU2ozpyGow+Z8tZ6AqNdH3lFtlys9vYCC7ioWso2WG2rhWTRq1gUlmP frK1Dr22DzIJdMPZD/kTA3ltFb55ht67q9Jx2q9uBjw6bKIGLCpmu82u8uy7yfw9XKXVBo8eeMsA wHpouR8BAAAAdgogxAANdqQGx9XsAQAIMeDxAAgxAAC4TwAhBmhwXMz14SotEGLA4wEQYgAAcJ8A QgzQ4LiY68NVWlquoUM64OG0DACshdZ8HQAAANglgBADNDgu5vogldaUmnPILQMAa6FjOiMAAADs EECIARocF3MFpQUAAAAAALAJgBADNDgu5gpKCwAAAAAAYBMAIQZocFzMFZQWAAAAAADAJgBCDNDg uJgrKC0AAAAAAIBNAIQYoMFxMVdQWgAAAAAAAJtg94S4iEN235+p6GmT9i5cCvpAwd8GeajJ1MfF XO+DEJOyZdwl7zW4q2XdYDxL/u/IczV33O8N9BbrM+vt64Btg9g9d4DSLoWecZl9Hg3f1xc+p2jg Wq8Krx+TxdPrUeA+QMtpnmI7BC6zeXQ9CvR3NR8DSPU6ncHhLNNpMPqUxCPPcb3RwngB8hEDl8n4 4b7dNmDWky2BlBU/DdA3+xDg7P1w9Fm+gP2esB8PMbkFwG7fb5PR+eO5JgBnyO+04N0Pjou53hsh VulO+Q0F3iD6jitcppOg3goGk/ReJnyz++KVjfCt1l7dZeii05Qsszi6DL3mbUfXn5J8hZfTV5MD 1fAdg1g8fxh3qfK8yuPXfvBuka+4Bpbx0G/bMHPVygRC3HF8DxyGKbZLcBUJj5sQK0OPy3QSnDyP lqtaPRzCjNv4ynGCEOKH+nbbgF5PtociDl3XG87y9uaLLBp63uuYN4D3hP0QYmK4rSamiEOXX7MJ n+go0LWxn6donlvEQ/eAbe5xMdd9EOLi92jeeoGWNKyrPH7tuWQR2iJu5tHvfTiCuh2lt3I49i0Z Pduxa2mRRUPPcdxgFCX1HCqyGIWe29L+Q8ZdhgbdFmPChnXLUvkNBYN2E0Fd0Twh7ja+h4ZOU2wP IJ6twzXOInAx/zhvPxy4icOzZn+Fl/HQ3/alPB17AuiCoxcmztB5D7a9yuPXh8CJ90OIxdmogUoQ d0RVV8toPNn5U1pxl6GLQ44POS7munNCjJfx8GmHG2X3sJSu8vi13+8gxXQ+c5ehp2bCtFpGz90W UkVP9vXTp/yGgtPHc+YjAGfRJOnimsLLaHBi3DLhPH4btQVVaQgxgX18Dwxdp9gecEyEGOezof+q fR0hSrLLCL2uPQF0wPEL8y6LrnsGY6yW0fOT+745dS+EuIhD1xhAXFXVvggiLtNJcH4AYbs4Rb57 yFzhuJjrbgkxzhfjwHXO2ldrGp+wu6V0lS/eBS1TSdMtPSEuv6HwV6PNwik6H0azkec4hjgzcihp +mtVVRVeRs+Gh6vk9w/8PRpsHNttIsT28T0odJ9i+8DREGKc/zYOTrusmzQUZGeEuHtPAK14vMIs FyPvyf0agT0QYrIeW43dPggiIROHcYYox4ccHI6LuSrN4jKLUUiiAV0vRHHGa9YqT6JRcEpD6Jpw /lWefIpQ6LnD+HaZTELPcVz/+cv/cerw8FGG68wbptV8oiSDG8aFMefJ0kO+e3woAh/51xbmiHPS f8c5DcZf0plMiHH+ZYKmifF8Chfxq3OUYvpeuslL/2RX45t4/MFyLmQdJlxm82uaAySFZHAjVdzV 4nKlMNyqqsosRkQOjuOFKM54ry2XY+S4wXjGno7zZBpdht6TMF7myVXouY77PPrx38n0GoW+G8ZF 88vTYPyb4B0XGx3NMoufGGfI1wwiLxb5zTXQEWLD+Go1n9jnGmdhfGMIPV9PnvxkYfJ0HMcLJ+S1 ym8o6DDFGuFsrBXqQOSLCRG4G4wXf8xkQmyyGKQ/EYkO8sKrJF+2hTPV0USO4/ghioVcIoPy6BTy f6HPvwaCOSAjJRsc5Z52NsQ011Y5w7EMMd895zQYRUm+qsRkCUFnyjQiUvXCSbK8NcUA4LyeWbd0 IE4H0XcsPVAzEcwGRHk7ToY3TbNuMF5Ypm9jE6rur6OKqu45t0ywjpHdF6f2JmGSlzKovhk0pM1x /HCyyG/rqCTTwmRR9Y7za5PJcpehi/utNOA4JkIsDR6nRF4YcRziKpRzFaUACeb9vV1y2feCEHGG fEfHLRTR4DyZctN1IqgENz2817P4XZO1JtvcC5R+NT9Fsrn1rOBSWOhP2Ou3p0LXdrAmKPJCKLwa P1GbeTiMstsyuY5277pwjpgQk2ikYZQVFTmSdh2nCeTlE5hY/OsgWmKOFrgv0Oy3rPgRD33HGyfl Pxm64Ekht8aIq7XsITblPFl6SNyuNBkL57MhYWPsSJ08umXriL9Hg1OWLVFk0S8vg391K1nAtfAs jJar+hXUJzIhrO3Vsw8TLpOxV88COgVIigw/UsGbS3SV5HUKIx8WifPZ0DsPo7RkMqkXWvpXfzBe 5Lg20+TpTVWcs5fo0zy7yePXHr9ABb9couskr5OTmjZJSiWlyKzPzV9l6I/F8DIauCw7nqTW2YVs DJnQCFyn+bWshO0NzpAvJgWuJ09uspwGw3eTRd4odmM277pNsS1ohQq8jAYuy74q02j4Inh66oiZ AEa5LaOBz3Q4/21sjxHCy3h4zlZPGpLU9A0v4+GFRnn0Cnk+Sm6pwWmG3mRwFA+xhpm1DvFtMjp3 aJTnikwKrvNST8jPL1hT+WJsKoTSMEL3JZrNsyKfDb0Tb7Qoy8XIO6HhWHQi8LPJbEDUt2tkeBq8 +RVdLXLMWAFvXU02ocfrVFVFPJ2mntP4fk7sLDhNGh2p/XIx8s7Y9rvO3LAH6a6W0Quf6Vu+eMe2 l9aFyfHpawqs6f95+j//1WF+FSkanKw/We4/t8pxrB5iSlWj2WT06ywrmmkcxkW1yufv0exLFJ4J YpUCJMjoei9GdBWhc4mjoRopkFVBXMKJfOtdtUS7iywaenRXjcv06qX/RGxTs/xonkJ1ne3OlTlT 4RT5J2Qvnk7Gbxf5z9Z6EWUahT4j1or2853n95H0CzdxeMbMEPnaPk5SjpcQ42U0cPn9CVEbqglK yCYxx9JmTNreyKu15of02bqQCYWvWHt4EwuzSU8U2qOP1A1qH0KMM3ReP4L2X4pzrU3qmsbLPkzE +gtUki7P7At0zZAmJreK4O/R4IwrukRWuBMqBPw9Gnhc+5ROMcGSt5NrNlHh85xbGA6lKIedqgrT vEb/Ee9GiFs0v/bzUc0pUvTimSz/teWpmSwiRes2xTbXCo1cUuSfCAMt5pJa5SY7tKwxQqtl9Nzl JyZhvcy3IgdQCsOqV0j922lPDDQhE9IYtQ2xdllvppvcE/n0A3+Pnv1iGgXaPcFqyQfL0kRoMSDq 21EZ8pRa1DqrDvd5HXvP1Y4ZtitKmqy4ryNEwmrVG65S/2Q4rGeTqieKRSK1sBqVaJtfOEO+0O3e k+Xeq2/ZCTHVGD9832xEajn+Z/n1a471QlS0gR9LmTeoKXdqVQqyr+I8FkUcurVyE+Xgpoe62Gii MpSn0M0cP83k+Ev2dsvl9NdJWqjvK4NQam6qKyvcahk9d/nqQnxXpRfB6WQ830NQ5tESYnswunoi I3pA9cvndgmxvYe3yehcPl3pTY8kg9Kl6KHUh5B7BS2f3pAQ24Wg9ROIC4lmpITQT/usVGMV6Jok 8A/55xrh87lKquQtASfGocRFPHR7nQl0IhwxBjUAACAASURBVMRtml9V9RLrjX7Pk7eBZjOwtjxb J0uXKbYFrVA7rmuT/4ldbuTfvB/dXAHGHhYocxdJefQKuV1C3LaQLUYe18NOhJhPt7WVTdApOTkr a4ZG3Xxadd5EiIUDB94w2nW4z+vYe74WIdbGWLZOfOqL5Eo38IVcVE+NqiRSLmbL/DIRuT6TpT3f bLewEmJ1Q6BITWH0pHhkLTKdxZF4g2khkV3IxiLbwiEj14KiczqL3DylXg/4p+hcR24Yza4Qf9hn 5zeix1G3YeC2rYSUN0qsqtE+cKyEuMUhxAVsSSBqsAdC3OqyqhtrQmik/ZjFXmi5b09CXMTDZ7wr giXP6SzdmoS40zApMUW85WkxzQYCwVoSo2Z52H5uJ8S6YE16xKiVfDvT5as7W+LqOhHiNs2nfSIO VzXGYEN56iaL6j1qmWKba4VJLBZC3CI3elLvOG4wuo5b48XNw81dX6VTnj0QYvsQ81jlyUcWuSv5 5qWQiVMmmrn92oUW4eA8mYoTod2K9iXEbTrc53VsPV+HEBsMeHsOd10p6DQYfRAzNMweYuW0vysh 1iXS9J4suy+HYofjWAgxKa3cShD5zRB55+Z9dAXXxJFQqao8PezaTzRVYxRU1dfs/5SnaI+Ga128 icMz54kfjGuZ2CrKyScOGonVR+Q/WRIJiTfnS/STqbhXTuw8SEKsP6RWvnDPhJiFwnshiv9IBPVr ZVGSutIG+xBiLrxMhjqhnJ0QYpOh5yW5ESFuLYu+BiHukDosvqS6LjYos9kocN1gdD1Pk8uW+gBd CHGr5tdfpF4xrRlcW57bIMRb0Ar1bbVtKmu8tWAoyxNyHIekeRhInXXmtp0UHwghJpkwJ16I4vR3 QXT6sFeW/eI4Th2Z2ks4NMPPD1EsTITtE+IOVyV0fh1bz9chxFqrXgkTRNlQsfbrpDpHzP7S6olU hZbkSCgH76b51e7c7TBZumZE7AoWQtx6nKTa2SKbjYVKDhoZScuz6mFtCR6SoD1tUXqu0lb9U2Tb p3FmO8oWymTIdLZY3ABxXiXXCy+j6JM+8V8NZd4xjpsQ2x1CrWdMeyDExh6SCPv6giXZFO6cEJeL 0WCiLP+61DpqgteK97ILwU59eniITX1rJa9re4j7BWprQybomsSWrvaCWd09xK3LDP4ePXuJrn/x ZCfxhvK0EOLOIRNb0Aq1422EuKPc+NoRhi+3jGMLmdgbITYrMDm6rEP7JNEZGSpfCMIeciO/Psm8 rPPGNEcBNv66noe4dUPb7XUsPd8+IW7IqI4QV1UlVA5pPtfbjVUe//omfEoak0tZdPEQt++6rZPl gD3Euiw00eUprgGrZfw5SS75QBxdoILo0NUIUZtXZDIWOktBLumWQ2EkfZKeonXY0MPiJk1SXvOs SZHa0PjLZ15j+KxeouomHr4RM7H2F1tzrITYqC23X+M/WBiTmvh/l00/7ylkwt5D2Rz0JcR6Ne5M iFm1NfUvGuvJfMnmOsTEJnzV/LXLMGlj5tiHnWKIVYOLy69fEhoRqCk+gLPP03VDJgzZh1WFs+lU Y971Q6mPxdycELdpflVVVZGi1+PktrlvhTva2kyeZkLcI6luC1qhoCNTN8ntLptccifO1pIgpoDy 8luc/NtwPlkrz95iiE1D/FO2IW2EGGcfxk1vWVWKHl4teeB0WZgmA6J5u24xxEYd7vM69p6vE0Ns MAJt952JGUesZhFrVushVpIHpAbbY4g3nCyHG0OsJgGQq6eaSh/8KQMu00/R15xx6J//lP9gDaVW st9qc1b+MY1/4IqXyCrPvpcG1ojzL5Poz1K1aHg5R8OnpIV/yrJRQbKJ+Tv7q6g0T9HMSaXolfo6 Nasu8lzRIlnhVsvpu/Fl6DlnYZyXZbNsa3bG/qv4P38i/ymX8Nf10HMrOFpCXDvd+QqIuEyvhpPG 6pn+uhdCbOvDT1kf+hJithsUVlb7vkv8rfF6JJpaJ0bqk2Ae00WPq3z+IUr1z2wZJlpESTk4aqog tVEfFtAmFBMtv6Hhe87DZPjreoS4vjBZqN5apOjNxLJhtoaTNYLalBC3aX61yuPRsMlkICOrnJau KU9dlYllNGiyojtNsS1ohSIVyeWhPtcqt7sMDfjl35qXxjaQQnXqWj26/HW3hNg6iEoH2gkxOlcy 6XsQ4jZS2KbPvQmxXYd7vE63nnO/VZI0jAHZogIIdQW0Yk3R+QtuIRAJjD6G+MTmN2mZX+xFhALb /SbL4VaZoMNG6S8us8+j4FSsH1zTwbt88WEyX9YVJ9If8yvuv3SYWWAcVwq7PqdY5l+/5Q15dX30 Z5F+nMyXuGJrfBO1U2TxexT9WTYt0HUa58k0IlF3ro9+S6JPaYk5Pfj3V/qJ7inUdU2OhFiwCx/m os4B+smnNIl1oQ5EV8iiUmTTqyj9m2whLmefp19vq/qhTXn/VZ5cDcNfF/mKBnDTk1NykGrV/q3i eAmx7gIL3otp+yuL+tdmsrveaFHi5fxqvmwYgDAi7Odi9VZNUKa5D9TiECUsstm70CcVHv4sSP1p YsW8cVLe5fMo1oTQ1BfIEdXFZfrhzaAuIWkJF1myusvaLzC2JwXPsbg6NxhdT+vTNVxm8+vx6O3C UjnePkzMB0MNDpmP57Vgmag5xkatRD0iaol7/vvWvzKiL9pllqHSdJKJuh5c9Y4JcyqwIR+X97Lg Mvs8Dv/1hCyWxZ/T+L9MnuYO8VQWgeMynQQnmk1Uc0S+iTzr1DRPrELaMIyOU2xzrVBBFLu2tEU6 +WXwlF2LE8aFTW4045mVp7XPoDb1sPxVr5AVv8Tg/MtV/APr9aFWXa7gQO1k5UbBMogCHyiz2fil /4QQ4jyZfMyw3BNSjbQuutzUTtZAW4qU+uZJkWlxIiSTKMMtBkR5u3r33sxHVhKYfqf19Tu+TlvP qc+CzKxVvviAxi89+jhCEHXDSt1zfBHuc4MngoFWmagnHSvwTP6o6okps1Mq9mybXxtOFunIndU5 4EOfdwzH0RNiSlU974S9VYim0s0orCZxvaOiy3lNeXGZzSPusgklPZOsKHwaGduyC5fESBfSXAod ob73xjEj6m6lE6v2KYyy152V3tdQDcNyExKrP99c6lPEQ3FLwF2S5AjZlzj7OEn+TfYh/NvtB84R E+JKjFJStW7VXJfVDI2STCZk3xMdoyok1xPwUfZTTbB1ffQ1FdrklcfUwybtgCgntUHNxoyV8Tan 79TbV9r4LF3GQ9cLkSlCvXG3qP0knVUMpXjskyef6otsDDLXonWY6huP+Guo5HxwN5z9kD+hIUmc 3dDkWUtTjxYBl4tFaKsNnIXxn8onN1UlXvTVdpuUWumpYmTRcdiUl90BPCSlbfWsaDWff2Xq6dHc XbeuPKuqqn2uL9E1fTXNJW1tUwxvSytUkNQX0u3xLPsrDp944WXU2H+93KrqLptcxsuUjTj/JwP4 aE411765YLKRoEEh61+QJYaoh0YffmqKn4j3UgltWoa4Ts8iTtk7aVUVe0JCJv6qJ7hxKsilCfiL 2VgSG/Gas+RybiIYDIjc5gVafBQsmDuMf8zkT0iKv0GHu75Op54rRj5DvuOHqGEckjBr7Whuv+vC B3A6GcfLekCbTpvsxkq6hIj7yv++vv7f3eYXfxdj38kiVTmsvTD7u9TdcfSEuGMyAeBhwjluQgwA HAPkqxAeKrShugAA4KCwyuNLpLi9cf7bOPD3MXlxivwnyoNwEb8Z3jMhtlcRBzx0HBdzBUIMOFIo F6E9SAAhBgAOHLhMxr6pdAGfD7crKJc1EpTfJuNPe6s4qyfELZfWAB46jou5AiEGHC1Wefzas1Xq eAAAQgwAHDYsGXX4Rzz9Y8enWLhMJ4HPx7hXVVVk8TSSI3V3Cx0hli6IBzw+HBdzBUIMOGYQTmwJ Cj9ytGe2AQCA+wUJ2PVD9JEL7cVlNt89JS2y2Vhhw/cDDSEWcH8VkgH3iONirkCIAUcOXGafR7RI 2UOCNVcVAAAcEPhLuR1NAYPdAGfvh03tvHuGKakO8KhxXMwVlBYAAAAAAMAmAEIM0OC4mCsoLQAA AAAAgE0AhBigwXExV1BaAAAAAAAAmwAIMUCD42KuoLQAAAAAAAA2ARBigAbHxVxBaQEAAAAAAGyC NkLc3IJ48FUk+QsbIZd5MxwXc+3RbJnF0ftRcAqXzhwPSD2g85FyhdIugctsHl2PArdP9UlSX2zN osKsIMPR1CSmtyW7wSQ9jg4/DJCizqcB+vbQLzi0otNcuxfTsX8cnek4XHTxEOMyGXtHco0zzpDP 34cOWAv3z1x30Sy3ZQJCfDy4TUbnjjtA6f5GDGeIFR/qTYjXJIhFHPqvZ8nHoXd2JPV6b+LwzPEO onroI0IRh67rDWfrVsMis4lcjrhaRs/dI+WLneba/k3HfYj3+EzH4aILIb6JwzPR51qkaOA6/jDe 2416HUGcFnClyKZ4mIS4qhq31nER4uL3aH7T8sm+cTOPfj8mGfYGccVtbky6COo2Gb8hFzjjfDb0 Xwneh/sfax1wis6f7XOXcqBy2C9whs43cclTpwA57yUa/oD8R/euIVsWLy7mH+ctjkir6Xj4VnrL 6ECIizh0pUHtS4hXy2g82QdJvcvQhXMkzuxDxgEw1x01e4SEGC/j4VMhYEn9ZN9Y5fFrw8X3DwZb IcSdBIWXX6ZfGzcSzuO3EfM/3P9Y64Gzj5N9ehYPVQ77xV0WXW92LM5rNTlqP/hgyI44CA3Zpnh1 BFf5jsV0PAorvWW0E2KcIX+jOYPLdBKc7yWoF6fId4+J6xwqDoC57qjZYyPEOF+MA5efgOon+8Yq X7wL3OOR4ZrYnBBvLKj7H+vDAMhha+B9Rg/oQPVQNGRr4sX5b+PgdAPv3iOx0ltGKyHe0OdKRmVf hzIaZzZgHRwAc12/WZwn0ShgwcLBKOJvnzQQ4jKLr9lvpJ/gPJleo9B3w/g2X0xC33FOB9F3XOEy i0LPdRzXC6+SfNlyOFVmMQo90isvRHHG58TwfXaD8Swrqqqqym8oOBVuvnX/FfwP8ZM6lklsYjTL 7Dk3+icWcehyTwvjgr9910cZJqdDPGqLv8qTaEQ7fBo0t3Gu8uRThELPHcbFXf0dN3i3aMJPTcKs k9ukpQ6X2dwwYl0eZ5IJGV/HcYPx4o+ZSogtelIVWTy9HgUutZYWQakoshiFHvm6H04WOdaNvo+y nyZttMhfAZdaelu/cv1cSYa3y2QSeo7jDiJyIKjXHNpyGpHWvHCSLG/FA1/DD9vGSyuHtXSeH+lk Gl2PAtdHGW6Ezx66ypMr9onwgmbbYpOY8DMvnCRpGr0aoBRrshrINkx8zfbB7Tz0xACylnGG/Hpx 5wxd0XT4NBj/JsYrW6Yeketl6D0J45umDTcYL+wxz7jMYnZpsOuFKCYyN9peca7pNcRkOvjRcL3w Ksn+iMKXKLvjMgfYTxp7KPAK8xQwi1cP7cDhMp0Egu2wsBqd6dAbn2LNSf2Y4DgdqkzU7IHTGH6E +MUsysp/J5OPmcag8+uBcGs2t1YVWTT0yNBGaVkmk8juWa614TQYf0lnmg0ZzpNpTUTaZyagqo6a EJeLkXdCk07wMh7yjKHSE+JyMfLOmN2nGsjSNZr1yX2JZvOsyGdD78QbLYplNPCHUVZUbDdv2Yvj fDb0zsMoLauqwt+jwSnfK5zPhv5gvMgbkk3TMirduZvuJA4v4+EFfQVKSk4tCRa2J1Kh8bQjRf4J n8dD7ID4vqs8fu3TicxkOIiWmAqczL43l+gqyTGz+I05NghTs0RVFUvzZXOZvW+AvpVVp8fpZbKM Bi5L3i/TaPgieHoqWC2bnnDbBm4J1AlKRZGiZ34YZSVmji7XGy1KzVgbtbE0yl99T46EBa8uJ79z M4U8l5fhCzT7LSt+xEPf8cZJ+bNMJ8FJYNCc79Hggil5vhjXewOLyt11G68t6DwHjnR6L8foAxEa 4RDuS/R5InSjmQhG22KRGKVrbI2ruU69gJJKCLySkGQsnhAXKRqcGAe389ATsWWTZ/XajdPJeC4R cTf45RJdJ41MBPtpnno8fTwN3vyKrrh9XWPQVKzy+LXnsem/jAau47jPo+XSoO3zRDPXZA0xmo50 Erg1y6+JI5vmpHiFcCJHzHVDeKzm2iRe44sbB47M0xY+bTEdkvGxqaj9jR4V2gixxudKpiu3TvB5 r2UakS0m/ZvOwUy+w3aWXF0IMmYkNJkMzBPbCQhth+xmVCNSUSVrnpQi34WKbF1wtISYqJBsFjmF VAnxbTI6F9cPokucBSS2VShqc5ehC16X8DJ6NjTwHvw9GpzVdoptIE9o+/h7NPDMlL0LIV4to+cn /CuQlclkTFueWG9lSX40LtPJ4Jmwvqo8Dy+jwQlvQ8n6yjpJjTv3BcHc24UpNlVRYipQH7poMaPU 8jgdCOlvxqhe3WtD164nqtg7EGKlhg8lrMYwRJ02tslfeahmWyg8t/6vmCOPU+TzNlloB2fI59cF /D169gvzPlpVrn28NtZ5VQREjPxyQFtQxUheqs22aCVG+K5qOhq10YyF1DfF0SgMbs+hb5cJr+Ty O7ZOPfp2PIduCaXFy2jg8kIj1JA2qNX2qlKHW/sUrekQp7mk9hrpiePVajw7o5vNtOiz3XTojI9+ Um/tjR4A7IRYFwSj0Eqp0hnOPoyb3ZUS1Iu/R4NTvloKF6NMNI+bWpNLozaQNZubJ8rwr5bRc5cv uQIRxp1xvIS4TMYep7HthFgbZiNaWx2tIbrK55Ua83ntUfgyjajXAJ4s2gkxTpF/IryCkOzc94lV VftpvHGS/z4K3kqrkSIQmdHWHlOR8aiLOk/7TMKUlihtZJ6WYJkepxGJrk3xJx30ZC1CfBOHZ+IX +OR0IyHWaKNF/vr31ap0vfCrMtRIidccshBwJwlNjnyLyrWP16Y6rxGBSoiN3SBtttkWHYPRlQHt S4jVKk/84PYd+naZCD8kKk3b7zD1NBpLvmA69G+JyTTOoHUIsUQwyAP6EeIuxrMb1rCZEuymw0yI NSq6lTd6CLATYnUq6mY4kbKuIKVCBYj2c+cL5BCE2VDFpJqgKbgtPQtnyOf3qeSEC6pmdsPREmIO OE+mlzS4qtFhyXwbjHXrVrumjI7jBqPr2BK8aHeQcCdZMkw+QuUTMfCXg3YRan0iATty0Z2dKQLh zqAlEMm3MR6rMKUlSk9tBQ7RmxBr/6p6B1v0ZB1CzF8nJA1eE8DdSojb5K88VUeIWzcVXFiIVnOo s5CM4pwLY21TuTUIcT+d1wm+NyHmf6yzLcYthPTznoTYrCGOjzLcd+jbZWImxB2mXl9C3Eb7tkqI b+LwTH5WP0Lc0Xh2wRo2Uyc67Rzg4s3aCPEW3+ghwHEshFjjUtWv7syfJNFNZUNZxCFNe2RB8UIm R1WfQto5MeXN/MGHvPmrVf8ni6wnyTrAhjvBOWpCTNPX/BDFaXIpLntaf4ZqrMVDSb1RrkPnHcdx HBYDp8BOiHVOi5afa6PluueStj6RgRpcTVym3jdmWYDbGY9FmLqTRLX//ALZlxDr21R92C16sg4h bkyiFt0Ice9gsPUIsY5PSKiT6hyH5oE0b2FWuf6EePMLmNYkxBbbYtxCbEaI7Rqy1TjAFkLcZeod MiHWPqsfIe5sPFuxjs0U0WI6OhLi7b3Rg4CNEOuOek02UZu2IjmYeQeDH6LraJroWK8ayC9Bt7YJ G1kh+c8LL6PoE1DhXjheQozz2ZC7wUhZ9noRYpuHmIFL8tUbL9Mj+P5Yznm7eog7n5C2PpFgtYzC Z+jqjS7BQu8hbnVmtDNUrTD7EOL1PMSbEuKNPcTGdbGPh7jHEaeFEFtCJjqunXzFABps0KJy63qI N4l/W4MQt9iWHRHiFg3pO/TtMlmTEG/iITYr1YER4o7GswvWsJm6L5gpdR8P8b2XqzsUWAixzvxJ ZqiIh03uC3HuSjaLnwaWYH9cxG+GUl6nMSVIHdTb5PKZ13TsUUeFbwVHS4hl3tNGiHXrYt2OuL+S j0r4AHeacm6J2VXpMi6/fklo5KUmKxxnn6cdQybUnCTWxHSqsZZtT6yqCpfpVThelHVSvJTCpY0h 1mxi77Lp5w4M1S5MbSCgNpzXQua6hExoV1MxuceqJ2vHEDuaS45IFHWfGGKL/GVYCLGUmKg5XTVp jpA9QkoHSKe3JpVbM4a4h85rRNCbELfZFqPEthFDbBzcvkPfLhNzyESHqbdeDLFmjtx+jf/Qn/vz HVsjZGILMcR249kRa9hMCXbT0SuGeCtv9BBgIcS1rb/9Ov2yxJWwmcB/Z38VOEO+MbuOM6/47+yv wqCy5DKVjwv0lJswVleEPBNWy+m78WXoOWdhnJelOeizw70vAIJjJcTKhG8lxCzwUVTLIg5driya noIMeFtmy5xjwV5CfcfyGxq+52ME9X/tVGWCnb0IpViLFL3RXw/Z8sQK57NXw2ld1IlGMXERSpoq E/RMhq+Bisv0ajjpwlDtwpSXKFaYSWEeTf2v3kl1ZTL25FVBci+168n6VSbIoRlfBjgej5o841ZC 3CZ/5aG6KhPfo8FpS9UnWpSKqxRbNZqDM3TOC5CPuOsyBXoR4r46r4qgLyFutS1aiRGVsFWZ0CT+ UpVgqWyNhqBYHdyeQ98uEzMh7jD1ehPilv5vlRDTnlirTKjtkIQlcbNtNp7d0d9myg1YTUdXQrzF N3oAMBNi5gy+zb99pfEGtZH6O40+zHNSQrIOFCtSNJAnhjuMi39/jT7RMyY6nVgVQ5wnk9fh+Lec ZAbUgYOkcKOxkiLpBsmoK7LpVZT+TQj05ewzvcaQlXpl5QZXeXI1DH9trcwPIDhWQsy23aQkbZl9 Hof/ekKWloLUtGYOCb60UD4beq4jFNc856LYtRX9aGEEVnV12ZQd1UAttO5wKaEtf22MOF7Or+as si//ie7yAjnIvnN/ym8o8AS/BU1gYtVGK36Zv8vnUbxsyrgKYAJhOXNcFiylVoRNWoWpCWVm3se6 tmsWhd557Slpe5wWdNnzSFHPqkgnvwyeUpFSN2eLntRHAZzbUiMo06PFwaP6qY61Vhsru/xVBWCZ NL5YNphLd6YylEsKWDSHpnZQAZIx6qTkHcarp85T+1+vTSo0OaPdtNRoW37qJUYfVNfaZ5e/cASR PIUWRFrliw9o/NKjb0SYmX1wew29BUwmzW8Z5Wqk1DL16qq9nPFhhZaNC7ql/yZtV+eaTkNU06Ej BqHHE2K2NyaBMThfTC7HdVg8yUqymetesA9cw3Nw/uUq/qETnsV0aIzPGpP6scFxTISYzFIvnDSB vkT69YaG3Kt+m83GpNK44DaoHUvUPtIP6xuAHOc0GH1gF9Jk0SQpy2xG70rht8Ia0JXJOQ1GUZKv 2CZVuHSjuXTKaa0DAJDhHCsh5tJ6iOuIXxrltFzu9JO/gIq/Rk7+CXcyOLmMlym7fK5WRRP4wEpO 8+s/i+oqXq7HLk2op5L6CXmHSXMBjdiErkPaJzbvy95Uc3ddVa+LYvabNLu5uclLMJz9kD/5uDAI k0sGcByHXxf5G554y9PlcSZ/bcFMGXGW/BWHT7zwkk91MOqJXIGh1hOtoGyPlq0fP9bFnwZttMhf P/jUQ/wSfR7XV3bVMlSqSQh0hNdkQdFw9mEc/8Xd+ibroE7lOo9XL52nRNYU1i8l+Ls+ms+klH// cjETs+99lBUm2/I1sUmM16tRlPxXKgceNBmlxEuHM+Q7foiuOdXjLyRTB7f70JsgyeQsjP9UPrlh z9JOPaX0hzuMf8zkT/T+Tj55gJUosdhe7VwTNcRoOhqacRqMomT5hxLEXN8ORqjOPxm6cLwQcZlI NnPdD7aBYzzHsq+rbKZDMD5/Wyf1Ft/ouOE4LVc3Ax4jdqQGx9UsAPBA8UiyLG7i4ZvDi5GzZ9kC 9ou2rD7AowIQYoAGx8VcQWkBgD54DIQYl+mH8bTLTc57BhDiQwIQYgAHIMQADY6LuYLSAgB98NAJ cZnFkaGq5/0DCPEhAQgxgAMQYoAGx8VcQWkBgD5ozXMC7A4g/ENCe7ot4BEBCDFAg+NirqC0AEBH yMlG4BvbJ+Qbp0H49wjl1uItXfgHOF4AIQZocFzMFZQWAAAAAADAJgBCDNDguJgrKC0AAAAAAIBN AIQYoMFxMVdQWgAAAAAAAJsACDFAg+NirqC0AAAAAAAANgEQYoAGx8VcQWkBAAAAAABsgiMhxPV1 iy03oAK2g+NirveltNxFvvV95oCtgJSmOh8lt/fdk10Dl9k8uh4F7k4KDuA8mUaXofeE3bu7Czye wdoeyiyO3o+CszWrEZtvoQdsHyDtR4MjIMQ4nw298zBKy+omDs8ebDH5Q8JxMdf7UFpcppPg5Hm0 XFVVkaKBC4VFt4nbZHTuuAOUPvC5zhVB28Eq2xT5Ots5Id7nYMnFy7q/HS6Tsdfl+zhPplGEQq99 XDq32fyiJljrXs9BWnCHzcXUMmnTgXy/yzeFS1uKLEahRzvshZfTJMfFfDxJsem5veuXFVkcobCu B3gajN5Pkxzj79Gr9xkmV5nYcRbGN7ZXc4PR9Vz0WXRp1hGEXN3E4RkQ4gcMxzkcQlx+Q8Gp472O 8xX34WLknbGi2TdxSCfcMAbusUPsSA2Oq1krbuLwrLH7eBkPfSDEgLWw01WWrPo7JcRa4GL+cV7s Yj4oPKY7/aK3MLRJA6doMLykhz9t49KxTeUZRTx0t0iIWzqDyywK/VeMEBMHEwFRP+4nOF+MgxNC iPEyHvqOG4wX5Nq/VZ5Eo+BUpvJk7XYcN5ik/Q7KcJlFoec6bjCK6qsFcZnFlB83g8suNFE9YmUa hU+b/lMhNAOH88WEtCawi7sMPfXCiLFk9frGVb54F5wAIX5EuE9CjJfTVxNlUgkqu1pGz11h2hNv 3JYJsdyTR4/jYq73QIiJjwoKuQO21BujXQAAIABJREFUgAdIiHE+GxL6tXUUceiPk3XCk26TUeB5 J12l0elS355tcq3vhBCr7LbBXTa5JIR4Mp4X9p9Q16zB+Y2/RwMp2GO9+6hxmU4C15G9YBRFigbc 6m+7bxxnH8ZNJ3UTCn+PBqcin2YCYd/Qtb9aRuNJ0w4Q4geO+yPE5TcUDLpsvnceI9GlJ48Mx8Vc 90+I6Uk3EGLAFvDQCDHOfxsHpzq6tjnuMjRY65ZdXCZvg9E0MvJF9RethLh/m9xv906I69/+nf1V tP1klWffS7Py4GzybHNCTF255uhz/D169ksXQixCO6HYwUIjNPKOzcO07eP8r79K8BA/FtwPIaYW 084nyGHNjk15p548PhwXc1Wa5U7cHNcLUSwkYuIym1/T81DxpE5MQmpy5poTQ/XmW0dQ0TKLDU1z LS/z5Cr0XMd9Hv3472QaXY8C10cZbmL13ODdIl9V1Yp+03HcYDwT3qI+u3Q6pPTxX+b6xYXcsWWA WPz6JJr7L1tLuoa9cimHjhuMZlkptW9ssM4zUxbpllc2fWGVJ58iFHruMC7u6u8wIXMosxiFHumL F6I449ZL6YXE4SjTiJ7JhpNkedsWLdCc4brBePHHjK6yt00wAF22+dtlrdI29rzhNFp9VuQmqi3N /Tp1w/i27rPjh5MFd7rNDxbz+XFj7KP0p1b5l6tuw8qBRg+7XngZTZO8s9HG+WwYvE3Kv9v5YvOb FkLcu02cJxMyRqfB+Es6kwmxTcG0fVuPEMuwOpXRhX6m4Gw6zTYjxIyh2hZfXMSXzEG7JUJsfFyX 9oEQP3A4TgdCjPNkylnbiWiIhL9SU9sse1S9cL4YB65zgbK/SQYSZy6/pk1MGFE1cdV0HDeM/9Os muqsW+XJR44AXSXC7K15husNp/HlBXtKofQkxRW/tg2j7LZMrqPHp/1aNTiSZld5/Npj1UjwMhq4 Drf64jIZezUhoGN9GqBvZcUn65wGb35FV4scs0iepoWqMnmIy8XIOwvGv+W4qqoii4ZeHVTHpTe9 RJ/m2U0ev/Z4FfdejtGHRc6l6L1EnyfoKslxTTKax63y+LVPVyn2IGMEMzn3pFFGOJ8NBTqiRuat ltFzt3m7FetqvQzcZejCcMpZP3MZDy+oKJiQmWOvpUGOH/OLNPmVT2MfWcwi9zWTTDhO6QZvLgWR 8kLjknfrA9a6zyQGYDBe5LiJemQyxN+jwQX7Yb4YB67VOYqX0cBlKlem0fBF8PS02QwkY88RUnmo DtuZmbHnhAeo+tycRBvVg98vBa8uJ7/nuPZTuN5oUZoGS6JreuUnfsFemqxED3csOoS/R4Ono+S2 H1+0E+K+beLv0eCUhdgWWfTLy+BfPCG2KZipb90JscxfO/yE/I7qHr+n1aI/IWba1fkE2ERY77Lp Z/HddLSVeqMtPQRCDGgnxMRI+SGKsxLLuUTkr7VLgag4+yvOkE9zP4kNbWx686caxI7zDENsraoq tlRLip5God84RYo4dDmlL9Mo9Nluu0jRS9874dtUenITh2dsbSZvt4uDv0PH8RJivIwGLn8GRxSY 6YyQo0l+QAiESM44JqQ9dNYR4ttkdC6u5URda22kawZhEramCIEQlkPBEONlNDhR/2pakm/i8Ixb O6XX0SwDSpcIR2c9L7+hQWhcqtmLn/CioG9U96G1QTXRR7YGOEM+J8wWmVACwX1BohT4ezQ444aG kJITOnb4ezTwOJUQhIYz5PNGSTjnVYBT5J8IOkD5ImtBllUXZmbuebs+91YPpT+GwRIsp0H5+2ly /YLEJ01IcWu5t9UyCp81adlbIcR92yRbPj70mfzK7aJgxr51JcSrPP5lYCSC9v6v8sW7xuWvHJsI L9iHELOtVPefmEIaZsPBxEqIa4/YKfNW9GhfBBDiBw47ISbeIy6DrYhDt/H0LKPnLl9tB6fIr0N+ iXoRl/CrV/GP23jI1si7DF1Ik5ksb8L5kfKJhiKTbV/jrMJFPHQFz80pb4aUNpWeSI+Q8w8eC46W EGtUi0Otk3fKh7UdVOmvJtrPwGIV4y6QG31AnqYpzWrHL1p3GboQuTg72dSb8ttkdM59fw1CXG8b zkfJfyWjFy0UBKfIP9HMXIEz2RuUF2njtoF+0iYTo0jNW3T+hSTKW/enCflwveGsjiIwF1jQaqC4 yvYkxPaed9Dn3uqhsJ/uhFjqZ19Nlt6c+VmsAW94GT17Vu/NtkOIe7epMQ7CKNgVzNg3IyFWYeGd 7f1vInyos1gN59gfIdZAVgBVCKfBKEosJ1pc+0CIHzMshJjOWGlPXwNnyOcdD8Q8NdyU+JIvk8XV WKoIIfBmAjKdeD0jT1fdcvz8Idpp8hAQ/5zwV3nxMPbksZd1O1ZCbFwnCPTmTCRb6xFiQ4qMsKZu ixCb1rz2JD8uuqnuajdC3ByenranNMllYvWrsrXBDhxLIMRtMmkhxPbMM/NKTH7OEth1tU6177VF QtyaM9dJn+kfuqmH8uHahHh9TWYPko53dF94Fvb0QNe/NYi9d5tagfMftimYqW/78BBzjXCB5soS ebAe4u5F4oEQAyyEuAu3cIdx8ZMdYInBu4RrBuEblMh8Wt0um5Yrq0klM8qkvmS51dhxeU1VSQwx so+aEzsPkhCbVrgWP24XQmxaDxTP7uaEWBNK1AqWZeiFKP4jEbralRA33ru2pUVztqOHpUF1kSZR v7UjlqxzbLvbKpONCLG6XVdQJx44jlMHOpu6cXCEuJ96bI0Qr6PJMqwOcj6wgWBzQrxGm1rjwI9C BwXT9m33McQKmjRfMaarfwwxy4/ckBC3xxCzqHoatd+7fXPLgAcHIyFuoZtcipsXXkbRJ+k8gn7B UwtG6g4Nizh0dWFqgq20x7pJMDskZK+eTrl1eVSPCsdNiO1uFRMh3shDbCfEO/AQ9whtJ+lo9Xog dbWHh/jZs1+v35y3O4nV6ayDtUGTo+vXN+FTXQ2PNpl0IsSmtVlzWqV9BlfbxPDlXRFiC6to1efe 6qG0sJmHeMMkjSIO5WokdTftV7K1UTGt2Ndps5UQd1QwpW97qDIhVOpl0CSorVFlgp0PdN0RrV9l gh1G2cPNgRADjITYHsvVqjoWtiqx0kq73micTNIqq0YlCh1U7QVJplYiLpqe3MTDN1Jm96O9JvpY CbFRb2+/xn8UJqstHBSsGUNs8KryOrbVGGINiVQ9JfXbWbh7N0JcfkPhr0mJWXkH69KiZrCxdhs3 VUuDOg9x8jYwhG+1y6RTDLEasonLr18SVhhO9WTj7PM0uxMvBaA1NAymQ0s+No8hNva8XZ/7q4fi Stgshri7JuuAM+Rr3C4mbK/KRI822zcVdgUz9q03IV4tpx+U6HZ72bVn5nJsGxLi2q1mMyZ4+WX6 lfy1hXXg5efJnMsTFSMwafEWm6oAIQYYCbEpXufLJPqzrrajieahtxOZt/4N+ajLYjdfZkWwrSHF tK64wYc0/xClhbqo4PwLCi9c5yyM//6n/AerPcEp8p9yqeJbOM47XhwtIa6NLF/QFJfp1XCS4tpV IO6UhETMtZPq6MGcqJBCEuq2CHHLO0pQpqq8dClfYIsHfzH1q19qdktlaFta6hr4fKmmIkVvaEnR 9ga1HOvEsty2yKSNEDdFoPiEofIbGr5v+LThrzhD5zyV0WQmNN0kshWpj7YgBtdV5SpasUlrz9v0 uU09tFUmvkeDU+4V1ibE/TRZh9v2FE8B90KI2QgKW0RRsC2DaOhbT0KMl9GzoaqWLXWIdbcxk9zl zUImqqqp8Gio4VjzDfI/G2EVSrtoaSurL2m8XBoIMcASQ0ytcB0PV2Txe1RrZx2XQ+uYrPLkahj+ Sst3m89MWcjX3+XXjxEpT1G7KIo/o8mXHFc6L3KtiH+n0Yd5vuL2fKwUZZnFkwltU8i3W+XJp4jG xl2g5Peo4fRcT4o4dF12szkJWOyQP/RAcbyEWCkv7TiCY4A58GjpU1Kj6ryJF6eKzeeSMkvaMAC9 HWc1XPkix+dN8QHWsrhmsKa41UVzwEcnY62Q9ncUQddOUg2myGbvQp/Ue/qzIDW26WpNvrDKFx/Q +KVHGz0L479SNDjREDjL0iLVCaanyUykRXuDlB9wE9CUqNdUorXJpINI1Rsl+O/b/kqrTFDTseKK 7GpB1Kn+fpFOfhk8ZZdihHFBv0BjGHD++wSNadSmfrW29rxVn1vU4x+W7+WLhZaVAnaCo7cxvzj/ chX/wHrlbxk1GdREs0yVMpuNhkMxXJue7Bk1U0P+jD9pvUfN3KYCabXCZfrhzeBfbFCHcfHTqn5q ewZCTOed2hkS+/tE00kW/6DLnmc7W77aGr1eRFwc2Xy32QQ9aPFpxw1G11zgZZnF1+9Gb/kqaSw9 TpkCpAhG8zmb2nLQcG2U9MXj6LywbvX1wRj93xpwoHAcc5UJ8bqvy6l8H0dTisUNRtechlkSHZg3 iCuoTtdjzpmkyXVji4Rwj1Fzs5fj+CH6mKjspLmojJaPqPNdpJ7g7OMk+XeZfR7Z5sxjgXPEhLgS FEOT+M+nS4v32Emsyx3GP2bSJ7PF/1FuquPsI3fXFK9Cyv122gtoXB/NZ1LevX+5mIkZ6PV9GXV2 S0tRIVbnn/mflDmofCFDvuOH6Hqa/FdzaY62noMtbLe+l4sP+OXuVjA0KEtYvh9EAX8Xq0Ymcgq/ G85+yJ/QSpGcxTsNRh/ECw5li1dHMOPswzj+i7tlULj7UIcim40Dqp7jWfZXHD4Rrl6rU/SIVSSl i213sxl63kGf4+KnVT2Y2+wl+sy6zE8ZWbHrIvTU/PphlBZ65a/RWZPp7U70SZLBp1/ZDiFWyl/Y Ap07ep1xs7i4wWiWLuOh64WIS78xKZiuMYUQtwQ3695C8xNp2SUxxD/Fws8iGdA+t+fJKs6TadO+ o8w+5UIWDbiEY/Xz+kH1PSOOo9Se7/IKQIgfOBznPq5utkMtygjYM3akBsfVLOCQsMrjS6Q4zHD+ 2zjw+6QQAXqheyYTYI9oqQEF2BEgZOKB4wAJ8V2GnpqKHwP2g+NirgegtICdApfJ2NdzMkMiPGA7 AEJ8kABCfD8AQvzAcRiEGH+PBmf0sKZcjPwXj7be2YHguJgrEOIHDktGHf4RT/+AzfPOAIT4IAGE +H4AhPiB4zAIMaslifPFJHz2mG/EOBAcF3MFQvzQQe+QF8NGcZnNzWG1gK1AzSgFHACAEN8PgBA/ cBwGIa4TSDWXpAPuAcfFXIEQPwKs8uQjam6D06T5ArYLQyYo4AAgZ48d1NB0zoE7Fhy0tAHbxIEQ YsBh4biYKygtAAAAAACATQCEGKDBcTFXUFoAAAAAAACbAAgxQIPjYq6gtAAAAAAAADYBEGKABsfF XEFpAQAAAAAAbAIgxAANjou5gtICAAAAAADYBFsixDQN0z/Yimk0Y9p7HRtvuO2Im3g4fPBlko+L uQIhBgAAAAAAsAm2Q4hxhnzndBB9P0w2TAvBuM83JrK4TN4G7bforfLkU4RCj1ZpYTez4+/TyW8F q3Uvww1G1/NMuBJd982e18Svh+NirkCIAQAAAAAAbIKtEOK7DA0C9O1w74vCKTp/htKNKxzj79Gz X6y10HGZfR4Fp44Xoqhmt+xDx61v28L5bOi5TUVDnCeT0NMWwMffo8Gp47jecLa3sqvHxVyBEAMA AAAAANgE2yDEOIvexodcIh9n07dbiOXARfzqXHt/LAW5XsT1wkh09FZVVeFlNHC5gt4kyERw95JL oZSK5fdxKdFxMVcgxAAAAAAAADYBJNV1Bk7R4G2iMF2G1TJ67lruOMUpOn/VkNoiDl3HDWPOa00u +Gm8yOZv7hzHxVxBaQEAAAAAAGwCIMQdsVpG4TNjkDQuk7HnOLYwZZxOxvOa1OIM+bIzmBBi6UMS Rrzviy6Pi7mC0gIAAAAAANgEFkJ8E4dnNN2LuCdxvhgHrnCRd5HFH0bBKfkWDXItsziKrkfBSePU JN7TUzHOmP/taTD6rIQZrPIkIqG33nCW38ahW3tPV3lyFXqu4405l+1NHJ7JOWdlFl+PApqYxhfB KLJo6DmO4/hhlJZlMomsuWrlYhSY3cMszFd27hpBuK9wJTpeRgNXzZnTfHMPOC7mCoQYAAAAAADA JmjxEDeOTLyMh77jOA05K7+h4NQNxrOsYJT3LLz+/8K6LEIT9rrK49ceVyEB57+Nm9/iMp0Erhhs QMm3H0ZpWVU4/4LCC+YoXeXz92j2JQrPhMhaObSANMuoNuGs9PvE7Ur4MS6zKPSeWF2wq2U0HJq/ QGu6dQ/zlQKIcZ5Eo8DVVYXThBrvA8fFXIEQAwAAAAAA2AR2QkyI4wXK/k7Rq1fxj9t4eEJoa/kN BWdc3QNCiClXps5O4aB/tYxekIw0WmBBde42flCSXsbXcbuJa/qL869fc6wwRTEIgbBhziVMCDH9 vuR2vcsmlzYuW8ThuYWSktZ6FESjBFoquRbNNal4GfJ7OJ63huNirkCIAQAAAAAAbAI7ISZBCJfJ 4mosVGm4TUbnHKNlvtgmIoIQXJ7J4WL+YbpcseiC81FyKz+I0lkajyukkenpL9/+bTI6b3y05WLk nXhNweAiRQPXHdSV18jPuxUyu01GL8TeSqCxJZ3z3oSwYEKODb/VRhXvA8fFXIEQAwAAAAAA2ARW QoxT5LtuEL5BCV9jGC+jAQnnxXkyvUah77jBaJZx3yGcjyOs5R/T+Aeu+Z9UioFedHeBsjtWZUzI TlPorxxZKwbgNu5qnCfT6DL0XBaeUYN8p50T42X07JmhcITQ+e6EmPN21z/Xh1uI39wjjou5AiEG AAAAAACwCWyEmF13PBaTyViEADvpj+JMvZJDdHzefp1+WTaxCnIMAH2QjzKs9ZiSCApLEd8im42D OuWOMVTWwWmcaZkqKRtsv2Cv1T1c9fYQF3EoJM+x8GvVDSx/c384LuYKhBgAAAAAAMAmsBBi03k9 H97A464sf9b/4Xjtahl//koptfa3fMSwhjFT7y/nKBUdxqtl/DlJLv2aMRMeqTpW/ylLjIv4TZMe J2TaaYAzdN5Oc9kFy/LOgfvG8vNkfqPrfFV3WOHTiped+1OZXEe7rDtxXMz1vgkxzQpdZ+tSZnH0 fhSc7qvONJmAp+veK0lV3Q0mqbEgdyuKLJ5ejwL3Po4+7hUkGMxtQrnWGX0mvV7KVi5GctrGkYIs FudtToojhaIhgDWg13Z6bda+EnJwmc2j61Hg7qVCFOU8g7breG0KVuf2O85pMPqUxKMdqOKhG/+2 smuafmuJcpGiZ+cKyXP8yyT9PWkqJ6i/pQUoWBCFQojLPyM0Dj2XWzP4eAlcpp+ir3mGLhx3GBc/ /yn/wdoghPIbCgYou83QU0vohYibOHzWSZtpYLSeZ+A8HjcxJ9onElFLNYylREMO5WI0mOzUbXxc zLVuVs1W7BPKsgmIGve0ffxRxn4IcRGH7iZ3gN/E4ZmmFkoP8OdLB2oTt4DyGwpUg0BWI/bhOqPP Sa8/Id5sG3MgILkirQv/kULUEMB6MGk7qZS1lxNXbiXaAyHmq2a1fNOgYLhMJ8EJYSBk50CwXVU8 AuNvJsTmC9Koy9YbRiQUocxmo+EwSgXBEUJcf0f8LVNWUgyYv+uYZdQNoiWucP77ZPJlmUp3WNRM /S5ffJjMl3XFifTH/Gq+xHV8MG0Wl9nnUfhLlBVsRa97/g0Fp4a75XCZvA06b49IITnHcb0QNREa ZRZfvxu9/Y3xD+ZKlCdJ7Xh7t6BUgxWqk76J82R6GXonu97mHikhrqqquSSF1ezbF5Q9YSewod8L IcYZOt+EFeEUnT/bAhcxneHsA7iYf5zv+rnER9W+HK41+luLpLqZR78/SF4JAOhB/WL7Kepvdmlt GXcZGmzGXMU7HPAyHvrGO3c3xH0a/3YYCbHuKrUa7F4MQjvQx0T1GBnXTlxmn7n7ON5PE9FdRSsQ O44Xojgrm9JvtVaxS5LrPDnqEg7Gi5p55skk9MhexAtR/QycRZOkLLMZPRrwQxSrxc6qqqrw9+hZ aLx2Tg/+qhHl7YgemDyXyl9tsNyHtyUcMyG+vymHl/HbaU+ask9CfJdF15scmuPs42QrR9X3ZxNx Phv6r/b0XJwi/+mhEuJVHr/293shPABw78B5/NZ+CdfWsC9CTFjNJi3sM1vpSAnxwUB3/xxgxwBC vC/s1UN8KLinAaLHOHt6Li7Tq3BsP2K6L0K8yhfvAsMBIAAA2Ab25iHeFHxVg53jsFfngyfE5sgN wO7wOAhxfTe44ziOG4yixBhby+r3PQnjJT0eafz0uMxiFJKYMdcLr8QDE/4p6hXlekrE5Tc4SsVA +4vYb0GXvrDKk08RCj0SgMS+w4Xu2PvD/fx2Sc5k2EGbVbb6AWp9C3lEjCIq04gMhxdOkuXt/OO8 +MmilZpzFkvcEde464VXSfZHFL5E2R0XGshOz5qzHb7BVT5/jyR90qTQdSTEzYmcG7xbpJ8UQozL bH7dSEPSZCmRhY8RJFDWbC6+2XG4kWpe1nB4yI+KcxqMIjIXpOB+9r66mMIyi41vUicq1U+3aKAq Q51CaiK5adUgx0IRcJ5MI5baWGQxakYnX4njJU1e60gpGsKZnZtGtPxZKBnfaOg5juP44WSR3/4e zdWhUUXNcsE5Bej2uO7WaZUnn1hi2T+NkWQN4nwxYZ/wZVsFJRJk1MVemdK2mmGigsK1iK9R6Lth fEv70xSe6mmHhTcaL/6YyYS4m4kzzD6N8RH718jQ9FKqgmmybs7C+MaU79t/IVCgM/595bw7OM5B E2ISD3oPN1M8cuxIDfbUbCdCTFSLJiLQ2xNNsSgcD3iJPs2zmzx+7dFUd1ymk8AnUenU8cYlOJNY cBbNTHOteKOmoUQ4nw39wXiRs3vFzR3r9IgiRYMTumbQtdMdREvMrYhu8OYSXSU51tyjTvItAqU/ d9zPX6DZb1nxIx76jjdOyp8tstUM0CqPX/uaThoGzyIi/D0aXFBpkPirTjW/OcUg1wyNSeh/TR/r K+tJfDBnlGhOrTWBXZ9C14UQr5bRc3apEC6zaPhy8FQgxLhMxl7NWuhmoM6G0SeyWO8DIt9YxkPf Ub9TxKFrKvJALmwiOZdStnSTZSFKCRfx0K3nS7kYeWe15KkasKh3hRBgswZK42Cf7KRyBf+mNCrP QIg5xuy9HKMPRGmJnrgv0eeJMJW6jpSqIY3ZOQ3e/IquFjlmE7zp/GoZvfBptgyxP6blkiVX8GpA 75S9QNldt8d1t0484fbD8eVkwcnEfYE+vxceIcyvE5r4S5WQMNQu9sqUtlWk6BmVEo3JJPUTmqF0 X6LZPCvy2ZBd6dXTDhNhstEs02j4InjKvVcvE1cHjkoayM++8hsKPDpZmC4Nou/Y9FJvfh0Zsnhl D7Eh39cgEMtCoHs3xfj3lfNOcdCEmNnQIzh0eGB4BIRYKqLSeikgrX8il6EpFyPvXxw/EMukGG5Y 5BpRKBH+Hg08rjZ2G2dqewTOkC+IQix9qN6DI7FGnCL/CScWsT/UdOounrTIVrWJy2hwwhtBU23H dhHhDPlCzfLv0bNfehBi+ZLLSrg2SN83fXl1td/KULYTYpwhXxAvowX1iJeLkXcmFFOnBJ0Tgirw VkJcv7iwsOEiHp6YfiWd5snS1taRvOPK/twmo3ORItD0aO4nivD1GijBrpC6TWnbIbLmC1TIqhrz VM8+UmpPSFf5Yvli53GKfD7HerWMhkOTEVMNo6zbrY9byzoJKzit/Kg0QkZZuMa1UhW11V5pXhOX ydjj1Vjslf6+hXXeVLQbdIPBntLLxNU/FzUQZ8inn9xl6EKThiS5k2VWajiQ1Gh7z4Wp0zTU9LO3 nHeMQyXEcpLZ3soHAqrqURDi22R0zpmAjoRY+gIu4qF4NifwFeOqyTmNpPkv87naWhlep+0Ragg+ daIIhkzDmGlZQyWlVeyPnmK2yVYeoLsMXdg6qXllY5eUW9m5shLthFhXFfE+CbEug0IYX80AaZpd jxBr7gy6icNz4xwpFyO+AI4qbZVh4xSdsxzHIg5dRYZyzw2EeKPJviVCbJxKvD/bPlImQnym7EjF LTdfCbHQhkxohWkixMbH9bVOOkJsegR5a+LG5u6g1RNik73SvuZNHJ6Jqk5+wr+UliN2f1Pt4PId 62fiuC+ci96WZ1ykljhZqKipYA0TfH1C3CKQTtOwYj2XiHsfjdoxDpUQA+4Vj4AQN8B5MkWkJomF 02gJMXdCJ8FkJloIMX/OKMFwTmJ/hBSOxoP/gnGBMb+gcNG6+WobrWz1LMfcSbHJFhFRr5vjuMHo ei5E6bVbbV3x9XskxNr8OXXDo+iGvMKtSYiVDhRxeN4l82aVJx9ZVL2NDHE3HxnuIWoVfveVmHxd o5D7IcRdRqo/Ia6jO5zTYPTBcCcrw6aEeF3r1IMQ878lNUZdwQ6sQYjNNpA7U5Ke3vdNtYPLf9jL xLFOqJsBtnvUVtx3OK3eNiFutbrrEeL+GrVjOA4QYoCCHanBnprtSohZMpwXoviPpIXTaAmx6fIa 7hHpJGjuwiCBhpoTcDHNqJctsD6iNSe1ZYFpe0GjHbTKVrtidc1x7iCiOqnOcYRy1K1WW/uF+yPE elqm2fAo0pAkvDYhFm6Gw0X8qq3SNkldOvFCFKe/a/omKORNHAZsLphkKEl7bUJsUci9EOJOI7UG Ia64pDrHEYr6K9iUEPe3TusR4jKLUeg5fojiNLnUhLf2IsRtNlA3F3q+qX5wuY71M3FiC41uvPJp SIYcWNLtpSqTwelAiNsEsiYhXmO92y2AEAM0eASEmCT9SLlH63mI7fN5lce/vgmfkn2wUgFAuxHv m0VqfkSrIe7kIe5rB9tkq/UQd3XydRQRX/pDCph+NIR4cw8x/83WssokBaq+Rq6VJQj+Zjsh3tBD bFfIAyDE63uIGSiJdJzWA4dGqtuTAAAgAElEQVRNPcR9rFN/QkxSHuVMys09xN0dsU2XOr9pq6r3 M3FSN4jwhXtzSWCYrU7OTjzEZoFs5CE+oKoJQIgBGjxoQnwTjz9k/5EOo9cjxNRgKRe+13Grrfcd akO1NNnHOPs81XMR+yPUFBb2OtPPHUImWPdM/dHaQfmgv5UQq6k8YielF7aKCGcfxurN8MaAaa24 DiaGWKvJgngNj5ZCDDcgxLVMLqO3vs3FpRA1PUsgQaKuj/74Eb3g/c0GDipFUa9FiFsUcj8hE11G ap0Y4sl4LtQB8MzS2E4McR/r1JsQyxNwC4SYfkHN96I3NZpjiLu/qTZDTvUsdDVxDUhNGx+lP6IB H62kyeCk/ZtOsx2ETLQJZKMY4l7r3W5xzISYS7yDQsXbxcMlxLhM3g5Q+lO2F+sR4loJhfLDOJ+9 Gs0ZA7Pfs60m89KIN6EcY/kNDd8bSqLaH8FdZN1cyojL9Go44ZJyLAsMrTIm3UnO+qOzg4otbiXE dUgcX5uT66TmlY0iwhk6580rTpHvdibEuh1OO2kgcQW7SKojLYvrqLSikMpZamantc5dH0Jcq5Dd kaOIxeQTpaPwxPPEKwNp8Lf4lCIOXf711yHErQqpfIG98jYJcZeRWiup7vwFx4ruMnTRkuLG/5XO 7q6EeC3r1IcQKz3cBiGuA1W58sPVKo/HI0v+Wb83pQojEjtx9HuZuAZEXCeeJyWz0lqB7EJf+uYp ejPhSmdskRC3CGRdQtxbo3aMVkJsCgZ3vfAykq9d3j8M50eAzXDMhLhev9WVmJT/5pMAyPFukc3e hT7JO/6zSK4jdW9qrDVLfZDi5GArnOlGbo/ULa6aXGOp7q/8K3M5m/ZHqBcxNOV4WCFSrn26RtYs xNYfoY5pI6sW2bI8Yt69YeukAmuXSJWJujJrUzG64n1FOP9yFf/QLW1koOs6xPUlC01tLLr4kVNd nC8ml+M6ZLm9hAU/1uonCuhwNHWmJ2+e0+AYutYyLzgtcUpqeZ6Tmrv0nVSBE7Xxxkl5l8+j2F71 s9tqR9dgIpYym41f+k+I3PJk8pFb3mgemErHmYOTr9R7zhUMqZdP7uoErQbq+2+e7ETI9AurfPEB jV96Di9kCSyVjS/Q2z6VWkdK0QdmdrgdGquaTL5Dq0zQyY65Mro60P0VCR3B+e8TNGZ3VRA+2va4 ntaJyYTb0rQ8gnpSA/StrHCZfR6H/3riOI6PsiKZRNnPdiHrtJ0V1eZRXyFkqDnd0w6zXTGzPEU6 +WXwlF0EE8ZFPxOnyFCdfULJefocJlXTS2kNDvsyX6uk58LUaRqSVuTR6Svn3cJxOniINRuI+j6h Zt2t//QNBaeicLcETcu7Ccre3SscCbRqcPjNmnNvObBwPVoDnO1N6ZRW9VnTrHIKnH1m9w9JN9Xp 6DK1XcP4P3+K6c/cQWF945HTcoVeyyOoDeVvaarvD5MzfN1w9kP+hAaQcfG4dX+UAhT8BQRG2f4t /kq83Y3d78VfcmaCSUQ4+zCO/+IuDxOkRykXn2mnosxm9Nqk02AUJcs/FC9XncZE/D3/ZOjC8UIU fTL2WU51v0DpV9PoW/vzOVvOQtcP0TXnjuBvwBJ9+fIwNdUJqNroFF7tva38cANJLHekirAmzauI Q1f/vsItZYL3S5mG/tvo/5g0UG61bbIrX8iQ70hCriE5iVwfzWeS28i/XMzE9HnaN/NIqRqy+Cjs dd1h/GMmf/KfPyfjeMldAmc3Fk2+KbnYjFTPJb6t/8TtjyOHEp2sk1JAQJWJ+o7OBUq+ij0kBNoP oz+X7fbq48JoXopsNmaKxVzFssxlf0cfOyw8wg3Gs+yvOHwi+g37mThO357oXX5c4HjTP9NLqQom XL3JfW42TTqBWBYCCSZb1FfOO4TjdCbEmg09NSviLqc3m1wto/GkC6PVtKyr09kfeDl9xZ9cACE+ TkJ8eFjl8SVSNrs4/20c+FvKJNjDIx43TEf/jwh8OQgAAAB4mOhCiC2ZgIbru3oAl+kk6FTbUofW qlJdUH5DweARr3YaHBdzPVRCjMtk7OuV8y6bXG6j8PgeHvHoAYS4a/lhAAAAOGJ0IcT6iuIEm10r Qu5eXzsCeAs1O+jt0Bv7mB8Yjou5HightqS74R/x9I9195D7fQTgkRNivIyH55CkAQAAHjw6EGLt bUkMLAblAmW3XICINt7OD6O0LJNJlOFKDQn/f9+MnrPwfkKva7r8NdW3zDJqb5d13BnLV6iqJjBF vQeBNCIFuVseVFUVFzbtsPCmug9C6EwdJ3RvgeGb47iY64ESYppm4YfoIxcrhstsvr1s1D084tFD ydp5DGBZMsTa0aKwAAAA8IDRTojtJaA5QnxXVSyHVL6Z1h/GS0wTF57I9TuVsohuGBdNqlAdEi61 XCfYvhih6yRfNWkiPspwhfMvE/R5EYWiC1muj40z5Es+ZvVBlJrXBVMIk+YzZ2tHXZFOxm8X+c+2 utkHjuNirodKiCvxDluH1GbZNlPdwyMeLdTEoMdylMSyD/kqUQAAAPCQ0UqIDeVXGaSQCYU9S1Ug xLhGvkQoAa1S/meRXoWvZvltHJ7Q8hwqL9eUdG4ON4v867ccKzUo5CdqqjYqDyI8W4yTFr3mjFUv l9NfJ2lRaXn2UeG4mOsBE2IAAAAAAABHgDZC3FKBknlQhGuThGADWhaUryUp/Ekt0H2Bki9oHIvf V1vmgx/E3jbuaunORlJAVC7qbr/EXF9JQ72P2w2j2RVL9rdWRz8GHBdzBUIMAAAAAABgE7QR4pYy DuLFsHr2vKLVKGVOrDJawiOfhm+u5GrVpvtppBNMza2A/FWipKKhdKWNGNggP0h/46JYmPkmDs+c J34wrl3I2ykGd484LuYKhBgAAAAAAMAmsBPilnvgKC+svadG9qwE3VaVhjVS/64uF01tWfMsqbeS r5fdniDHN4s+ZqlZfYK5ePOnelGwyrOPDcfFXIEQAwAAAAAA2AT/P3tv7yI30/UN6t9QPNnLZBOt I0VKOtgrmWAn0AMdrAMHBsMt6MDgwOCgocG8hot7QNA7YPAy6KXBmNc0j+hd48U0CGMYLoQW82CM 0HIx3PcghBkaU2iDqpLqW1J/zEzPnF82Pd2lqqNTp35VdT7MhNiUcI2miaj5q5AEDRXRq1HjnPAj HB6aWaOu/IcyvZo2GE6okV27+WafZvFnPkeVfI4rPUgmuxWNOrd1zs0qnr1v2C/mCoQYAAAAAADA JjASYn3CNZK+lxR/x2gSOKD8+/fyVxqc6KPrGNaI/k6/F8akwkLLSOWkix0zmtNljqeWf4Xht6Lm 0L/KErGMfJWnP0rlg2RXDVIVvT7tlntSN1Lk+b7mgd0v5rr3hLhMo/Dt2Dva4a0C2dqxE/auAbv4 b1LlZz0UaTQ7H3v2Xfdx0suHqXdse5N5+iMeD2417eO+iLQXbks/HwiubltpAd2wB0vJ+tATYpQv J54tHNmWaRSG52PPtmzHP+MqcdfsufgrnH7K0WXkHzXF4suLwDtkMkLUPPJfX8MPSYnkhGj6lqVo uTKdjz3b9ibLnD+mPfKjS5R/mU4/NRknkjQ6+5Sj+oz57/Lr+xC/WvlBhGcfesFFWdWF4F0/TIhN lMPyyCcfkjjqVqn8LmK/mOt+E+KmxPzu3GzY7Id3Fphw0Ll2Q5DziN9ZaORTXgSeMwx/IFz107Ys 2/VO/pfbW7GUIiVJ39tSGl+nwXG3yqNFGoVMtsFDb/x2FucI/Qifv93Ne7wV/Xw4uIrHgztBs8jV N7xoJfZiKVkfSkLMWDQZjh+EsyiVtJY4EtCKFSgNp3GJqaplWZbrBxGTz5JG2vkh+VCR8EHTclWR 0gOB75DUq974fCEkyyTZIcQKGofe5HOOmC/UlF39oKqqinQ+aepxnH+QtgGKsDy2Psg+Yr+Ya59m Lxfhlz4WFxWL94ve2UL6P8XorL8xrtNgePfs+3qy3QGMtYduD13kIzhorfLohUO9ubaHvvosixSf /7Xt+vCvWvzNcD5727K9cVgn3EZlGhF+fOfeY3fIcu4v+S3j1jtw4yCFeFr1sDvukwxvfCkpvoSL m0tf25qHGPAQcQeY6y6aXeXRC7fT+RMByucj93nP9Hm9n7JzQox3p7toeQOsJdvd4E4S4m7yMYZ5 bAdr6LNOpNe8H534oCzExUoNE4GegjsvIsWJQ5EEQ3tf813Kcl5L8rvt0oMBSgL3ZBvT6n7J8IaX EpRFo5ObrOcAhBigwG0z1100i8sNGnIIiqCO8r3W195PwY/a8QnxncNast0Z7h4h7iofdRqcLWI9 fdaItLwI/D/FlJo1UBIMRuF87FhS3vemBXx6p/c0RT/Cxy/vhFL1gyzndSW/wy49HKAyOfMnmzuL P2QZbgzitXujBc6AEAMU2GdCTG9UiZt7tgi/FNSFkUFdvaUJSLKsQ28cxvmqOYhqYDveCXHRqaco ueGtz7T0T5GB8niKfX4OvcmnZC4RYrZjohuP2NIsPPWdR36U5fGZz6RAUTfSeC3jz9m83fwAqyKN 3o29Q1443MObq2rLdvyAdabiRNtccCtk6wYJIpGFh+LiUabROTOEkClLjfJ4dh74ru1HRfOwxi1K jxURlGXZ3ptl8oGwt9+NZGg38BGs1X4XX6ZR7cTl+EHEvS/+PUzmVEqqd/e/Bx//bJeP8BKbPqMy XYTnY88WFhLDm1rlcUjfMivjPvqsE2kd1ZF/mgYzfVgFKqLngyBBZFzKVZD68pleBCqi06m6k12i 4pTWo6qqOvJV0k9FC9oZoZnUspz/24n3h0by7MvqUFhb/URGqy1iAZjpfxykf+tfva4Dqzz+EAa+ Y4+i4rr+jug9SOJwLMvxp3F2RZyCDEq7MM1+Mncum1FyoUQCuvWwWuWLtwH7pObnOskXaThyLMuy XH+6zK/wLX+36cPo1VW+nBLNcf0pOwzdDDU8XQYNdbVH0VVGVx82GIyRD/1CE/dlWo8MHVhXW4gn N4N61ndeGdeAZQEhBkjYkRrcQLMoC4cu8QvHx2z1AqbK63cVjwf0+hXX6GZNgJRjhBxQscUOcbWX hsvqswcyQD/C4SENMCrS8OUz7w+OEKMsGh0TYkeWELE6DEFDyo+eBR8W6WUevXDwEVp5EXiOuhEa MqsqbVMfv13F4wG1ULXjJhv1ssqjFw71wqde+5SLl8uxc0DK8Yi5WSTZIpmJ1gI/ogSXmF0qt2ZR t72Xp8F5nK80Kc8FrLLwiU0Ggso0HD0bnjTsjXi7smd15Cpfz8NQPh85AxJrS1Si6QPK5yN3OFnm qBHjkzBbmd5dR/lIJ8SqXY35TWGaSKJkUD4fsRuqjvrcItIOQD/Cx36YrWrWq3giFcK65214J2Yi xFrroZO/COOMME5qWc4qya/y6IVLpiSdDk2oumI8+icSc8coz3UaHLO+KH06QGvWWpZle69Og7M4 r6M8GYv6Ixwe02mSLyeeLXJxrnJtGU+cmuDS/hMH1mbuHHqv/gzOljmiLErtQ9+th8Y3q5H8Kguf uiQaCh8JN6NomT6sXnnPT6dfGGtZK6p5hpqezoAJDLNPRqfvlsySZzmTuPzNyOdpMP+cFj+jkUvu agxLiakDm2kL6bOQXbfzyrgWgBADFNhbQnydBsfcuVQWPh7pCbGyDovAQuScetwU5au0dCIQeOFh L4Vxs3Ujqyx8csDaaGU+bKFB8ehLCtgXGlFdaqM0cMkneDXilhaywDe5vcOhzV5eY5OH11cxi6Io FoVsiZVk+nwVjwf8WkWCcUVpM99plT9KA5e7cxfqz8vdECpTyi3+CIdHjPAx66Upz9GPcOgwJlto X/nuOspH5zIhaqnxTQnpfcRFqAshbhNpO1AaDOpHEEUVaQ2lTTuNPdVaD7X8hVGY5NwyqbsQYpSF wwNWLLI5YtFqRvDukepeeREMfW6+9+0AUVrmC7waozRwWV3l/FuksZTLsXPEcR2x1qxcR1ZFoVi0 9VAH08BRwtc3WGXhaNRj+rTOa+MMNT5dhGId4dcvdXE041Ki78CG2qJ6m31Xxt4AQgxQYL8JMZcU ponwVdimcjl2mMl8M4RYUciQ9yEWTUxtp3SGXrUM6MqSN1/Dv2Jt33UaPKb/VZYfZ4cvZ+BmgU81 xJPLfoRYWfGxjUa0OQTrS76vS4gVRYLE/3KElbRGhqBZwrdJiM1v6ioeD5ihrUGIW0Xaiqt47DND EPaHdKw3Q4g11qMDITbKuW1SdyDEIl83naZ3eGJV1RRzMI7/Kx4/FTyze3dAazCJfuLiAOTWCIu0 yaMiKK2yvpVyM8kdKrcEY7T1UAPjwHGbbJQnkxhhTULMLSvGGWp8uggVfeSMm3J7YF5KtB3YVFsU 77f3ytgbQIgBCuwtIaanmDhFnuDHabJNqzx+Tz3/avfiXRBipcnmP2xuAwXoDL2CVDG3kNpGFCR1 8NxwfswNttvJSlVVFcrj2Sn2LmX8wFoJn2Zt4ylgb0Ks/O9GhNh8KMVcDorAQ9g9Ie78plAez4gb dN8NnlmkbSii0WP2HgDvplTXF7slxCbr0U6IzXJum9QdCDHv+MtCKeduZoQOWXHv3LsDrRSH8G9L lSlVMK1qnsrPxBsjxOaB19lRDr3xOyEj7bqEWK1sqhlqeroI5XmqeNwr6nDbUqLrwMbaIr/f3itj b1gWEGKAhB2pwY00W4fFWJbF5ZnW2KYijQLfOXD8IEq+cPRiJ4RY/D7+EWvHpWLgrdAtDK37ZvYy DhXRc5de3GsoIGOmu9AsEmfm+kGUxKdcg+2ETymoSngFfQmxelw7JMRChc7OP79RQkzjwBw/iL7F PW88OojUDEPae/nSY5uLnwpa67EhIW6d1O2EWChH1TqSrmaEnttJfrS9O9CFbtZBdZbFlbhSKq08 cThKd1OEuF3ydVSZZbHVFbZGiE0z1PB0qZtrEOIuS4mqA1vQFuVt1W5zMQEhBiiwz4QYA9NcfNqj v17H4Qt1oJhghW+JEIueze3QnRC32g72uZeR/1iMzVITYuaEWL+Q4OCPujKZ2OCmhHjNE+KdEWKd qFuXk5sixNo3hQNr6rpcvV2ANiXE5XI8nEpfUzoD0DOnnSfIU1iProRYJ+e2Sd31hLi7u2Q3M4Ky 8PHjP89fDeRD4t4d6Eo32UQcwpFwN0J8KyfErZJn8swYI7nFPukJMTmCNc9Qw9NFGAix3mWiKw0V O7C5tqhPiHeaww4IMUCBvSXE1+n0tJlgJFxXd5ooWc+bIMSt5q9+rhQrjdLZTMkEdD7EVnsjOG+G GyQ/w+GA4RnqBYl17NP5L159jb4V0jLTnxDraCjnsbqmy4RhSVjTh1gO7EDl108xjaBXHb99nN2M y4T5TYniWs8n3ixSA2i2tW7N0ttbfR7iqkLZp9lX7X+NMFmPdkJslnPbpO7qQ6zwbbhOZx8Vcu5i RurM0CTLFSfY3h1o9yF+NxEynzTtK5VWGUJQf3izPsS6gf9OppNF89ZIFgj9KYzUJ/2KcByk19JU EsPgDE8XoZ2qwtKjPELWKJK2A7821BaND3GvlbE3gBADFNhjQhwM2RnIBjxp7Ls030yEWDbBOEtX HwJBKoSzs1p5OGrxSRaLJHilSbCqJFW0WC6XE1duBP/2wHEG/M+JZ5h8RFdzO8pO2OySqEzORlOF h/EahJh6HMpE35Ssqo2KYbHwZrolUE/t0tqgTgfGJBiuyotg9Lax+7r/3gQhNr2p3+pJ0StrSrtI tSiXY201PhJax+ffoA6L6kp1Fco/TcO/1s1LarIeHQixcUa0TepOWSZM7SuHYzQjKIuev2zy62Fn Yib7Te8OdAiqG7A7Q5QErq0hxHXSOmkKNJbzxghxm60bPGWMORdbuW6WiR/h8BBbWs2yxVBY/dNF KGYlTphYZwZUuv0YlxJ9BzbUFtX77bsy9kYrIdY6eEnZoQH3B/tMiI8b1zR8xlObeGwOnElcXueL MMpWxNbga/0ynU+euY8wvcjj6fsU4fk5GMdXKP90Fv1ElBuRn6B8OT2d1C5xeG5LT5H6SwkW8VBE ZfLu1ZDm4ceNyGnJDQUFpFzIBN0aUS085B84eTCXBpgjInLm+XpBJWcqXnBRVqhMP078Px5hTlnE 0zBFlSxbhS8jPW9gc5EOmCj1mh7VqziVrToXKRYLTiZNlaS8mL56ckKGceRHl3THgh1pVvnyXTB5 5ljMF+QXKpYasZjDNuN/de+uo3xIRBSbGKFmySxD1b8psizhwRbp/I3v4gwPfxXxeVgfUJn0uYNI lRCmpwi6DHOeplXjsGh74/MPTaWPMo3O34xfG2qy0CNJ6sYjwWg99L62DAwzom0+ynJWSN7YvgzT E4skGHIZrKhHSiOfnh2g2sgcMxPFIKpIskzUOWvrrNuVUmnr98WmQh80qk7nDmPTaBJxzTtq7aEe bTOoTj6dz0fOgem1Sp2icbcun6FZIKmaGZp8NT1dHATxwne4tMHM+QKRj7Q9MCiSafgbaUu9vXHG yxJli7NFhswqTZJymryo22BZHU6IFWIq0/nYa0uALwEPRrO5B9wdKNVgH5q9TqenUZZQZyahuFqd h7yOlamjAfAu9lqYUYSQcUuy8JNfaXBsOX4Qfmjq/YhPkYHK9COp32N743mSRSOba6RiStmZdp9S CDBvy9jyadpGLiP/kfpMhas15/pBJBka1tuSjxyvo2fwbp6sXo0kOdmKddcYXwu2C9wRhRDFfORH f0mfaKgYMV/0JWZz33b94HxGxNNEVuFjXZQGrsV+QSEpxi1SFWze1KBq3oP53bXIBy+E/MLgBuTE t0Fzqq17U9JgyUlhrb1d9LlVpJK8uH5qkutxg+N9J/J4Vlcw08hcQh0Or8/WorMeev2UoJ8RlXlS y3JWSr6pCKgpHslD/UTmnItoiKJ2XZ8OiNlUbH/+U/wk+nf6bhJ9r+WjnQiN0rJ1zviyf4KG2KPo 51z8hHdh6tJDowJpJI+S6STK6unf/lrFN0ROiJ8FH3GxJLHAoXGGtjydBzkhfhp8fE3mTmNRpaNP se66ZilpHf662lJU9aEMz3G1k6jeQq+fhc2yurhMKG8hu+ddqrEmIV5l4WRbR+KALlCrwQNrFgAA 3D/wnqwAwO2i3RVna9h2GYs7CVREr7SlSdrQiRCrwwzbwsy3BFQmU2+w67BiAIf9Yq5AiAEAQDdc fQ0/aFwmAICbBxDiraK8mE4+tBXi1qILIdaEfdyEcLGPy24zzwFk7BdzBUIMAADasMrjD2G4WNu/ EADYAYAQbwtFGs1CvVtbF3QgxGrXCOwuLfgQF2n0jnr8sKGFrHsKl7OJcVWpfU2ok7XoPY1/WPvT YLeSf8XT93B4vHXsF3MFQgwAAACAPURLIOD20CHg+MGjAyEWHYhRmS7Ox57dhJ9XVVWh/PPEO6Sp hUhgNfeOcVSNK+Q6xZWpi2Q6eb3Mf4u+GVIOkSLybVoMvUxC372JfdXDw34xVyDEAAAAANgvtIRE b/NJQlQo3Lqr0UqIaeYL/8+ArbgYhGxILwmI5vK/KDPz81XUSZbHLJv9OU0K5hMuL6yUB5HNkQnh ETvBfjFXIMQAAAAAAAA2QSsh7lLpGydUEqoHKQvPsO3g018/nJ8F5IfiebDIj6s66R0kbtst9ou5 AiEGAAAAAACwCdoIcYcKnOrapB2r4D5yvcmSSyzK+GYwdWKZhkkSPuDEO8R+MVcgxAAAAAAAADZB CyHuUHhQXXNcrNRaRL6tqrAq+Qcz7Qj8uGlb4aAM2Cr2i7kCIQYAAAAAALAJzIRYk3CNg1iCvKoq qbo9PuvlviO5FEvnwQI/LqLRqObTuObQ+vVIAGbsF3Pt0WyZRuHbsXd4s7GYRRrNzseefc/y3eBK m4bKsbeOu9/DdqAyXYTnY8/uE3CzzsB7aykNCRKc5QAAAGAvYSTEnWrRyaSZliBvTnAvI/8It4Py 799LpEgf0XynyPOS48fo7/R7gdLAZU6L1bVCAFvC7TPXXTTLRNreICFmMgxyCk/qvNvedF/LBJTL sWPf6f7f/R62gYlD702I+wx8DS29jPyT0fzLfOTCZR0AALgHMBBiYgpbjxmwUy+1mEUajhyh9nTt iFz8FU4/5UiRPoJ+8iGJozhfMYz5X1/DD0n5u4hGtuX6YVLWfYN0ejvD/STEVXWjWdBZKDKi14XX t72vK76EC7g5uUWgYvF+sc2rgA6Rzd3aWYRfTGrfQ0tRGf85wheAKItGJ/xl3dYlAAAAADuHkhAT 0tA5ax0q049MPY63Yq0QfH9ne+N5SuLnRHdhSoi9N0sSKoedImpifZ2G53F5lc4nnm1Zlu34AZv3 DbBd3AHmuqNm7w4hxrhOg5NtEmIFOwHcKFA+H7nPt+obsxVCvMqjF65Z7btrKfoZzb6VzZ9Z9HrW XN9tXwIAAACwc3QozAF4eLgDzHVHzd4xQlxeBP6fW/NwRfly4oFv/S0C1yfadnHUzQnxKl++8ew2 td+Glu5GAgAAALBzACEGKHAHmOv6zaI8DscedRb2xiF7YaEhxGUandPfCD9BeTw7D3zX9qOrfDn1 XRotylYRP4vzzHQfraIaKP80DWaxmD1wlcehVP9cuLQ58qNLxiXadoMEiaXOmRwvrETYixpmaEXz Ha4CJXWCsizL9afL/Kr2x9DFYAn128NmgJ0ep5Cd3AHGs5ayfyxh7jqL76FQq4l2W2qKlT+vCy39 J9lvlBdr/BvA5TxNQETTLMv2Jstvc5EQ1+VCVTouvhrq/NZAw617aCkq04iWasL6v9JJ4Hcez8JT 33nkR1ken/mOzRSPVWo7AAAA3AKAEAMU2GNCXC7HzgEp7o2yaOQy2U4qNSEul2PniNIaQr+oTzw+ nLMsy7KfBfNFWuTzkXPgjJdFFg7dUZgWVV233HD8pr2MFrDKoxcucRyiPaERS6QeJFepMXAtdxTV EU2qtDAoi0bHZHRlEgHB05IAACAASURBVDaEnhma9/I0OI/zFSVPtcRWWfjUJW5L+JQRN66LwbqK xwPq+EQ3DPYwSIqq0+MUAtF0gDpicYUtcYUgLB9VD8kJupRYvYh8G6dKQGU8cahIicAJe+vWf1Ug MsrnI3c4WebNJsoY/4CycGgfesFFWVVVmYSjp97JIcNiURlPHNubLHNUNe+UfF/zajok0OyupahM ph5RfnL23ISaCBJoNipHz4IPi/Qyj144JDGFSdsBAADghgGEGKDA3hJiMcGfxANkQnwVjwf8Mkz8 13neKUSXXqfBMcurUBY+Hm1KiFEWDg9YqiTkNKQncKQnRRI8fcxRSUXKlyx8csCOju+JXFWHkxhK AveAcR5dZeFoVDcuDgoTNY7qkTI6VFAtj1NIxNABOeGjlBNdnexcJMRMBpsmH45Snu39lwkx+hEO nZYtmTRkZ7xsPHQJp6SEuFyOnSNuC0F2AkLOyp0R4nI5dh5pxa7YEpAvcINq13YAAAC4UQAhBiiw v4S4jCcOwwzaCbEc31lpWCNHJvAaz57OGkP4O1ENkWTXp33Mo2mw6fhLHr/2eIahIMQioaxzz5Hv KIbGUka5UjqbwkIclLKSDsdyWh4nw9SBtQgx+Q6bOvc6DR7TRq7i8YDpjIYQG/ov0UGUBi7vokD2 V2plUJbnZH2IlV9QavWOCDEqohHvJ0P9eVidUchcYLpdtB0AAABuDkCIAQrsLSFmgPJ4duo7tsVd kQvUAf8pEWK+8LiSTJCzT8uyvfF5lPLEVEInqtFcyotgeQM5DlReLkvMo7mwFkCG3MbwMP/G/p3v xLwuwqDU1JYjqb0JsakD6xFi1ZnuQJESAeXxLPAdRlaK38r9F+mgnLGnhtKRVxk/x36oDrBTVgbd DSFmXDJEnWJ8tdsJcTdtBwAAgJsCEGKAAvtNiMs0CnzHcv0gSuJTjiiIhFhdeLz9XLOqGh9ZDIf4 E6vRhWpgJtGBDdAjRtkPVXmiacqZ2IGh1jFtlqXMLy5Ep4n95wTenxAbOrAmIeb9IlARPXe5g3Ya Lub4QfQt5hvsT4hxlzoniOB3YlyHSZUi5Rc0m5OdEGLBq0QzhFZC3FnbAQAA4GYAhBigwP4SYhwI VRfWklhaL0JsOiGmKNIoILTYwBK2QjXICH6Ej58F5y8dxSGx+oTYQIO6MlSyx7As/b28kRCvfUJs 6MDahJjt0mXkP2bIJa6yKQSobX5C3NkvdkNCfHMnxHqK3+uEGLKzAQCAOwMgxAAF9pYQixfKbYRY R+M4d1i1D/H0lAmcwuks9LynB9WQUy5cp7OP9XltEryYxFc0v4EQqKT0IVblNEDpbJa2M1SUTCeL +l8064LmGFLN1Tif1zV8iPUdWJsQ0wwVbpD8DIcD5tFiZzYnxIo4PPr5x5nWZULpXYBlqNnCCa7w u/YhtmySyIX9HFen6+VD3KLtAAAAcHMAQgxQYF8JsYaOGAgxdcnlV+si8u1mqdYE1Q3ZtRylgbsp Ia5z4rIJWVGZnI2mmOis8mg8ajJ84Z4L8WHHKo5ocemHqyIJXk27MFSUBIOnDJmuC6or7+WJvy8v qMvIP2oyx60RVKftgDxYXGe4AyEmvz1wnAH7yqTubYEQ1/mPufTD5UUweqsaMo4KFQg078CDndfl sDZ227PzLBN1+m3yRJTPn48XNDNJF0Lcqu0AAABwowBCDFBgXwkxPXbygouyQmX6ceL/8QgT4iKe hmmdnpbLnEXOHdnErgPmAIzGdSki4l0/TMqKnhBzedk46L1+Bcg1FOoka6hMph6XpooGbJFEv1Vz ejdelihbnC0yVFVywY7mXJkOrek5IWSkqyTJQ51umeRgLnWDoomfuaTOTY6ItscpBGfoAOWO2D0G 5cvp6cSnRTbsUVQgg9hVtLImc1ieRTp/47tHlmW7wV9FfB6mRYf+Y/I6GMdXKP90Fv1EinIVFr+N EUBoPfWWLpLpy+EJLRTiRwXx67D4fM8DJuGJ6tVgsutM4vI6X4SRStqdtZSOmtMpvQS4/NAsDNpO 93uNbpNXVntDAQAAwHYBhBigwN4S4rpOAT0TJYux64dJKdQqYz0r2OJ2jh/UWSPEn9SL+nU6PY2y hDq28iXZOAhR+aYQt6qqqmpFqnnxzTIF1dj0WzXo8RuhpHz0G8rjKXHAZcqaCWH+R370l/jJ/P+a TqKsrknW/FY/KE6Urh9EfAyc8XHy+TpKNB3AqOPt8CnjrzQ4thw/CD/EedEm9svIfyR92ARK4gNd wpudUZh+79h/Wj+FbpaIVGjlOXkQChTpHFcQwd34HvmPHP80nNU/Ywu82Y4fMPk3dK+G0GhN9Gdf LUVl+lHTAU4CRaO3GIJHjVrbqwoIMQAAuGlYFhBigIQdqcF+NQsAAAAAAOCBAAgxQIH9Yq6gtAAA AAAAADYBEGKAAvvFXEFpAQAAAAAAbAIgxAAF9ou5gtICAAAAAADYBECIAQrsF3MFpQUAAAAAALAJ gBADFNgv5gpKCwAAAAAAYBMoCDEAAAAAAAAAAPCwIBDim2XkgLuIHanBfjULAAAAAADggQAIMUCB /WKuoLQAAAAAAAA2ARBigAL7xVxBaQEAAAAAAGwCIMQABfaLuYLSAgAAAAAA2ARAiAEK7BdzBaUF AAAAAACwCYAQAxTYL+YKSgsAAAAAAGATACEGKLBfzBWUFgAAAAAAwCYAQgxQYL+YKygtAAAAAACA TQCEGKDAfjFXUFoAAAAAAACbAAgxQIH9Yq6gtAAAAAAAADYBEGKAAvvFXEFpAQAAAAAAbAIgxAAF 9ou5gtICAAAAAADYBECIAQrsF3MFpQUAAAAAALAJgBADFNgv5gpKCwAAAAAAYBMAIQYosF/MFZQW AAAAAADAJgBCDFBgv5grKC0AAAAAAIBNAIQYoMB+MVdQWgAAAAAAAJvg7hDiIgmGtmXZflTcUg8A NfaLuW6vWVTGE8eynfGyJJ8UaTQ7H3u2PYoKtKWnPDAUkW9blj0Mkvs9s6/i8cCyBuP46iaeVqZR +HbsHblBcht6qZwXrRJAZboIz8eefRyk12s9V56hNwM6XjdI764Z0Msf5XE49mzLsizbm8zj/zl2 bMuZxOXdHYwR66nfzaJM5+OX0zX1HHA7WJcQlxfB6O22TcNVPB5YwDzuACQ1QEU0si0KJbnBvKfB kR9dtjV7GflHTaveNBENNP9cy1Kqh9zbMo0C3yU/cfxgFufoMpq8YzSWbsC4h+Ll9tALLsqqqqrr NDg2PBfQAfgNuqMou+/iw+brRng/SgIXTwv7Ngixbl60SAClAZ2TGxLieobeDJjx3n1CLMu/vAg8 Zxj+QBUqk6lH7anK3u4F1lS/mwTK5yN3OFnm+yjfh4z1CPFVPB7s5CgXZdHoRCZSgBuGRg1WeRyO vUPLsiznRZSv5G+gLBzah8Pwh9IQqJttTi9sZzRXmZBVFj6x7Sdhpnii1Owqj1441qE3+Yybaprn FjN8nNCBUpADzh0R4stF+OX27fcOcZ0Gw5ulLw8EeKdxK4S4qqq15wXeA3cnxKhYvF/chb0oHu/d IsRdrAfWk1rgqzx64eht6S57slXs1ixvBJTPR+5jnpffGTUGGLEGIV5l4ZMd+jaUF9Pg872mCHsA vRowR7ZKToySwD3RrXb6ZuujYjUnRmng6pcirtlyOXZsSTlXWfhEdd15nQYnt0eIV3n0wr3fPkIo DacxsOEd4EEQYpTPR+7zO0F67hwh7mg9+u5AdteTreLOEmL0Ixw6wpHQHVJjgBF9CTEqkzN/eOLc oiEG7B5mQnzgPXvm2OpLt/UJsev5TxzLslT3od0JMb6WVezWUBI8nootlBeB/2eLI92uLO8qX77x bHCaB6yH+0+IUf554h3eFdJztwhxZ+tBvGt2R4hvyY7dUUKsOHm5W2oMMKInIS6XY28yD31b5SEK uDdoIcT+PKO+aCInXp8QD/zoO/brlTlxX0Js2Z7kv3Wdzj7ydurTNJjF7CE3CVQ65Ix7N8vLRK1Y tjeZp8zqUCYhdmh2/GmcXS3eL4p/05HWUK1YTH+u8uWUeEW7/pSODeXx7DzwXeYLjL9KmUbnTZ/G YdxIpLVlOqwyXejaqCpUpqHv2JZlO/5ZnGfctSkvkfE8VZ4TM36l1KQ0zuiU7THDLJpmG68YNRRi r7/NOP9Yh974Y0p0eJXHH8LAd+xRdJXFU9+xLJtu/wS3Rb7nf9NwMcEwsu7stuMHEasY3UTEfX/q k03j5FMylwhxpwYZF0xW7I1fMiU3bGvWoTcOuckizgukkUCFagWzvcny25wnxNxDGg3jvF0bZVDO 0Mqo6uspT1VV1SqPz3yy83+zTD6IhLjv6yvTKMCvz7IcP4i472sMiEohh//8+E/ZevwS5c+80EaI flRoA4WLNAp8ouquH0RpqZwvrICLTnbMKC6Ux7Pw1Hce+dEl4z0nG3AeXdVPN9N52RbX9dds782S u/k0tCCPMQncA2ZKqtT4n//nP12FPWHs3pH/Pz51ss+9NNBkD/uoXyd7eKntnmxn2FAiMr+Uah/e QBiKZXUnxCiLnr8MsyINjpUhU1W1yuP3jPU/i0XF6vhfVinZRTdMy3/F0/fGPTqzAjkv5tEbl11W p74YoVxEvk2/UKZReB74g+YLWIe273F116FXA0yIo4K46lqik8NGhPiyQlk0IpOfDcPq4TKBfoTD bsZLHJk8Uauq6kSImRAKqq61zqAf4fDYD5OyqiqULyfNOqQ9zJb74z0/nX7JUUXlg3W4sSP2s2C+ SIt8PnIOiPaWy7FzRFf9Ig1HTr17aW+Z9KCMJ069MhF72uxVUBYO3VGYYu70ecLSlPIi8BzydPpD nWc59nLhTAp5iXhiMsP0Xp4G53G+oiuxvk292MkNL7EwVDLDMEOMO5D9NJh/Touf0ci1nElcZMuJ 7IaOdWMwjq8UiwF9kONQEWXh0LYYxcii0XFXEVGZ0P1nkYYvn3l/cIS4R4PkVE+iL5eR/4gqwFU8 HlC3KDLZuTWJnxcaCZCgAqIzZRKOnnonh81zy+XYOSAGhGgg02esqPWL081Qg6qvpzxVReMWcIQW KtNw9Gx4whLinq8P5fORM6AKidW7+b7GgFxrFbJEgvXQyV86IdZEpKEsGg0cP0xL1HhFkteNAxmJ QUb5fMTat1Y71rSvElfDAg+9V38GZ8scYetx2LLsdlI/rLcuETtuluC/nfzHH7URfHUanMV5HXTI 6LnOVmhGmQauTI0ENa5qVZeEhu3J8v/pZJ97aaDJHvZXvzZ72NY9EsDDDJ+onOUGqcEO7z4GtDsh XmXhy+dRhsiMkjaCeMz1xpclmt3+W+87URYO6/8WkW9TyoW/Zpp4RRqOHLIXQWVy9sx9ROIJULaY ns2X5z53uYNFf+RHl/x++jhIr5n5s1MHrLuIDoS4Yo4HGE68ISGuWLPVcOIehLi+oiIQjjrMIFOx HyEWnca4RlAauKz+oB/h45edCLGuP/wKR1YC0VhcxeMBb7ixxaknXXvLmGdwFpYs5PgL12lwzBpE lIWPR7i16zQ47iNDzFrYhQQbmcZEEFkxIzJLzyT2LBwesGst/3QiBCl5k+rGnFdLcRQoC4c22w5e UHGvVln45EDPLyVcp8Ex/5bx42oR9W1Q5brATt4i4kylvKgr2pfeI0oC90A6gKgtKmN+a3laxocq 9LZV1XsrD/0C++7oIk1PsPpJG/0Ih0fcVjMNfYceJRoNiE4hVUOQ55FMiJW9XWXhE5vVLrxek8Fe Rv4R8+Vr4USsgx0ziws3yJI58REKdFU/m7NRaeBynBIrGGMNeJVrsRUiNNRIocb0Q25Gs2trq33u p4EGe7ie+rXZQ3P3FKMjC1mz4dQ8d8foSIhRGb/2iBqpLCk+42mirFARjZq0AOb/cicfVcVvs7AG M6bt3UQ7SbAdZCTIzAeUX3zNV0JrRIMVWzfbDT4vJ88fbNqUboS4Yg506SHQ5oS4PoSwrDqHTi9C jJugl8tko91+oUlH15cQi7amntv2KCoQMcHNIXoTbrwmIebJoroRYcOpGEhry0Jwutwf/GX2IJ9G mstPJ9ZNt5B0JsTye9FohV7sIo+vz8y4BUDxuvHXWAN9nQaPmT4Lo5BsC9c/4Wq1TUSKF8r7EPdt UCYHVYXSYNCc8S/HDtPgOoRYqULs8oGPHhn3iTUIcbuq91Ye0knF6Rf9SU9pqw8Ouf9qDYhOIbdJ iFESuHIgco2reDxgpNGfELeIS6a/HfzjOxBikWNV0ntXyJbVzzZboRimynSoP8d05Yg3IAN+7ujt 8zoaaFiGeqtfiz1s6V5nQnzjjtfdCHG5nIxmWYsO6bi8+b942WDuX/L5yLGb3TzZSKmTfLHA58rc aYQ4z6UNnDIjAT4acYbj+585VYuuhLhiD3QPveCi3AYhrljXK3sYJEVvQoxbYd0TtTndxNH1JMRS puQG+GqCunDY3vh8wZ5Vr0uI5RNo5Rek5YRbGltbVgc/sWaL+ADgkTEOkcz1pQDdCrd9QqwXO5f6 mkPDddSGWEHXBs+167HZoItJu80iUr5Q/sN+DdL+cz0U+H0N1pmN0Yd2RqJUIU1QHcrj2SlxYDUt ioLedlH1/sqj/C/7YT9pm887Ww3IzglxJ58H3Fgez4gbtHFuCmgR164IsXYX15UQt9kKUTq9CLHU mSLyB3Wzbfa573zX2sM11a8y28OW7u01IW6cMtUK0eHuUj9bmos56ukveY6TddfMiXEnBfEVkW8b LlDEmzUK4YboIUKhBgQSIWYPdC13NP94ugVCXFWNjzL1Be9PiGn36qAEs9dgtRYh1lyTsaijGSzL qh3adkiIRTZJwS4YbS3rgtP5Y2bq349fE3aWFe/BO2AHhLjSiF26RRVhMsSsZUBF9Nzl6qX1IMTS VZUZyhfKkYaeDbItMLGMruB4g6OsDhw/iJIvoj60MhK1CkmEmISauX4QJfFp26Io6G0XVV/vesFE iNd6fT3v2Zve3AVCTCNzHD+IvsWtc1P4cYu4dkaIycFKfRSCffykO2QdIW61Fe1d0j0Fgy2th4ro +YCJxjPb53+vMd/Vy9Ca6ldVlcEetr3xPSbERRK8mLCHu6Ip6TLbu2yOXT84D2ex6gxPdnWXvqE9 JxPu41jH5XQ+9qQbvYqq6YNOo9GLEFdiLK12dvUhxJUYwtw1y4TSqYaW4WixbmufELdqC5ttQL9O d+mPggn1IsStJ8T1lZyeEHNiZILTGS+RPsZ6N4S4qlRib9vumgwxK/nLyH+sonpmOsh1vnOmqnZC 3LNBrhs0kIVdjyviDVXX/ZKHsw1CTO4Dqb9ch0WxFyFe84S4lRBv4/U1T2sxIDdFiPVTiZY64up3 9j4h1n9hd4QYd/7PV/4JuW4U8uR0OSHuzsn6nhCzohNvVtvs83rzXWEP11Q/sT+CPWzp3r4SYlTG f/pyAizZzUsn0N6+gwyKaDQSghD70G7suCwSd2oX0M9o9iUWPYTwkN8G83cKv7SHhJ6EuOIOdLdG iCvGR7k7IWb8INmWWow++da6PsSK3RpKP87Sa56g02h97eFuh/7wOz1lI5rBsp6RrS1rVvHGZfM6 nZ5KzvdHfnRJJSYFiaN0NlOKfxc+xDqxyxE89Ik4K5/ZEFOrkvwMhwOVeAUfYsX7vfoafSvkaB6T iNr3RYrwIFODTWfi8cCyjoMkCYdDaT1mU1j0J8Rq8y5fSYs+xH0IcRdVX9dlQnHfKPjVdJU255TJ fFx+/RQXyGxAbsyHWLEQlxdR/C/NEVgfQtwirl2eEDexT4aOGX2IDbaivTXj58zjTsPX/BVom33u rYFty1BP9SPQ2cOW7u0lIUZlcuY/F9wuZU3VbMsW78KkaPuvUuFW+fLNcBT9m3cbNR47yc5D2SIY neA9yq+yrE0YabBIwvdfi7+oh/F1Wf4mPyzjIIhL9svo7/R7z23Y/qM/Ia6YA93tEeKK8VHunodY Vc4epYG7E5eJejnh0w+XF8HoLb5dHbC2hvFrXzfLxI9weFjbL3UjxM2Jn3dF5DdVtTu0TNKESXSE mLnrNBiy8mQih+h5PJdstUiCV1O1YsgrIm5ho6A6s9j5rHyoTM5GU5ZZmj1kDhxHVldNTI/6QTT7 FRfuqRcRXni4BUZ5Vtq5QUZQrmXZjuMoLhkkf7N+hBjHzAlrLfMdSdRrEOIOqr7G9QJWP95cKBIj dJa20UR0+u9OCbFxONKD+hPiFnHt1If4wNRICyFusxXqYXbLMkH/h+eIxJFa7XM/DTTYw/XUjx+y bA9buifpDJXDHSXEJEhfzqhH8+c1wqUjoek2qzKNptOQMBLzf+tFl+Y6RXk8feFPPuckF13t6VIk wdDWJiYk8wdH1KE8noWLJD51LdsNPsfhh6REzRk+ypfTt4sm48S3n1H4n//53137SfjzvxbT90mJ Gs1OvtNPHhb0zBVnJ9VkBCTq0Z8Q43Skmq088VHuVZiDy7ZGEux3yOxNT/WkDE3GpJhy9nWrjiIl 4b00wWcevXBqJzZs051JXF7nizBStF/7FLl8Csm6M2z6RpXQuCzCAy7KuKXlqjlIIGk4scfwgKaV IFkm6M8zLlUkl/ITw9a934Y5kTTJ+XJ6Oqnd3exRVFyTYTaKRw2L5r2YxK6oJtC0TCMFtTqs2ifg f+B1hWVRpgetJ6LaUbtM3r0a1olUR1GBejZYN6wilPWKhd9Imc4nz9xHmFflOBO8Yl4oJEA2NvRF FMn05fCE1nfw3y+DY5qgBpXpx4n/xyOszEU8DVOagnowjq9Q/uks+omUM7RF1Vd9laeq6tzYTQrb 6asn5N4dy6rv69ObiBYDolNI2Xoo5F//XErrLgzfMBxCTfApQ5HO3/guzvf3VxGfh+l1Bztmbp8k HWekR/PUtjlJtqifLrRLSA3OehWT9143YpzC6l7J99iyGrO/UTK/Dva5jwYa7eFa6le3rLOH5u6R HT5WqlW+fBdMnjnka0d+dNn63B3BsiRCzAeJ17s0ob4R+y+hws17vuKG+b9NNSDLOvTG72glp+s0 PI/Lq3SOE0BLRZ4E1Hfr9FCK14B61jVbPWrx3yzzFclQUX+5quRPHhQsBXOVFEDJUMuLwBv2IMR0 eyopFfelMpl64g21ullyN0QrWlET5gdq93RDT46D9IofsunEggnd4zzVUPpuEn2vpwDvxEb9TOrt otQqOSd4FnyckMqAzURoEx2XZEOsjGVsuQFbpUn4wnU6PY2yhBbfkiqZsXW5pBp3EkjSezpDf6XB seX4QfghzjM+1vvIj/6SPhHvFoxirySzg3veTcOry8h/JIpaSKzR/JB1sBbTjHDJAdtFhMr0I3kX tjeeJ1k0somIVms1SH5TRCNbMVLhjeA9CTaJv+R58dsggTnVMG8yT79H/iPHPyXhInWgDz5JIlaa CTwlAbuuHyalYoaqyt1xqn65hvIQkCATKoFs7tuuH5w3hqT366vdN9mVrn51sgExKyRnPRQa+FsQ F35TXxOdTWMmLJ83pomdxYeINMy9tlqtdkwvLoGz2qPo51z8RJ3wixuCRv1YRz5BEv84P/8H9xx/ /pPPt0DPL5W2QjdG9Zk0p8bSb5RhOZ3sc2cNbLOHa6hfDYU97NA9SanSwLXw/PqvpNNzdwLL6lW6 GfAwsIkaoPz7d80uYoNmV3n6Q3fWdX+VVulJdsdbBgAAgLuAVR6dBlK+V5R/nnjuboLmpRIn7biM fE9KSgv2+XYAhBigwI7UYL+avQMAQgwAAABrAJXxxFXbNz4geMuPFQq/tYFLP9y0Avb5VgCEGKDA fjHX+6u0QIgBAACgPwwRdehnNPvWoXDpuk/O5yPnj041h1EWjQb6Wjxgn28aQIgBCuwXc72/Stse XHL3WgYAAIBbBzZxQtgSKtOFptzBNoHy+cgZqDyGq6qJVMO+tVNV1D7Y59sBEGKAAvvFXO+l0koF kLcWb7u7lgEAAODOgK06juPSTndPhinKdD5+qU6CRmLs2GxuzH/BPt8egBADFNgv5gpKCwAAAAAA YBMAIQYosF/MFZQWAAAAAADAJgBCDFBgv5grKC0AAAAAAIBNAIQYoMB+MVdQWgAAAAAAAJtg14S4 rq70cKu+7SP2i7kCIb6PQGW6CM/Hns3WEsNFdztUJN4z6MfFFGGzvck8/p9jxzYUj31AwNVfQRQd QYt3rpvJ6zqdvhzP0x3MO+VMB9xt3M7sK9Jodj72VJU1dei3ZOyUEK/y6IWDyzkWkQ/qvj/YL+aq aXaVxx/Ox02Rdtsbn5tjjMs0Ck9plU78gw9xvkLZ7Pm0ThXJlmCti0JfRpN3KaqYGvQSupSPvhdA eTwT5f7BVO9U2UgTai0T4kMvuNg9IUZlugjr6tON/qyycKIMHt/oWcpxlReBh5P8ozKZei2pmm4J bI1ukuXquohOty0i+bnLsWPvRhRCwecaN5umYItgql6vn9q2TEJ/4Izm2x2/ZqYD7jZ2OPt0YEpJ 9ybEXZeMDoS4vAi8Q8t5EfVb0lAZTxz7SZitqgqXLL/j2UOKJBjaljuKIPHf/hPiMgl9l6+fXpBK 7niHJqJIw5EjVlynP7Fsmjt9lUcvHOvQm3zGX2rO77gpirNI1r9iKsX3nkf7BSzGQ28cUgZc7x9c XVZOPTAvuY1lEusPNxCW+W1syoov4aJ1UHhzVT9rlUcvGou6LXTqiRY4gZTtvVliKTXz4Y5b+w7A Z2Cs/OMzbA22RAovF+GXGyy7sI1aDyiLRtvnxLc509cHKhbvF1y5O/mTG8dm03kPUES+3YsQ69pR C2pnhBj9CIdr387cCNCP8PlbRqxAiBvsNyHGK5mSOpB/DYOEVUz86jXrXHkR1PeMeFssavUqC5/w lzh47bG5EkToRzg83OiE5q4DbwMOVWVLyb96nuze0jKJLZ7aFOCT2s26hLJodNKhBTz8XTLLrj3R 4SoeDyx7JFTByUmemQAAIABJREFURVk4vOvHH12gkD8tqbC5Tq7y6IWmsPCOsKXiZ31LE3fC/hFi lM9H7nNW8+VPbrxPG07nfcBWCLFeUDtymcDH1HdZv4skeDxQ1nUE7DUhJrxTScsqqpkW4/wkfyL9 Jgsfj6KC3u4pVhSUBI+nLYS48aa4B1xBxioLn9iG0krkvG3QqaIpwa0sk+R0X+9ztsrC0WjtLqF8 OfHsLoMi19w705buPdG2kASuLRPiqrpOg+f7r+TKDQn1pthoSV7lyzeefcN7421VA8Z3v/JL3wR7 RohR/nniHbKaL39y833adDrvBTYnxEZB7YQQk0Ist6gcZhCJ3Etesh3sLyEmHmkG3SM8gzJm8qet rnpPQFyEaePeZCkcJV+ns49thLj2llNNRSbk5ar2r7Bcfyo8CZXponbQZR08FK542HZYVjM6lMez 88B3mafodg4Yqzwaj5ovoDJ+PVQKiojRYI6JBxhmzCiPZ+Gp7zzyo8vmml0UrLRMSoFB3drhQtMs 2zPEBlExGo1DsZg0PuVC25M5dchh+pbR23YJ2LIL42I8Phv3VT8q6pgSUb1r3x7Lslw/iJjw5VUe h2Pv0BIUhpyCSz3pI6t6KtUeRIwYP844AbLdYAp0qRTS+8cTRxx4xXkQ2qOo+Hd/UfQZWlVpCDHt hj2KrjLTbCrTSDlRyX0Ui/oRRRq9Y6QUSp73bACD7fhBxHl/aY0D/m8bIb5OA5/Zr66y8NVEuX1F SeAeGA2mDI0eEigJsWk4islFrgSJ8xsxnldmFwKzPJVKy3nzk+Gc/Mf/xn3COsupjUMHKTVP5ONS jvzokjERthskqP907mY5dcI0GCKNAjMzvWiepzAdKpkQ42l7b5bJB4kQG9VeMK0GQVVVZSTEjAEi M1Z2aq77Sg9+mjWYeXnqftfK0UQw0PWAEtble9oa7kCRzieebTW34eSb8nEOo+jOi3n0xiU6Kmmz GyRJzSRkViS8YGLHGfJBbBl1EuV7QjwRLcsZhelVGZ+He0LBrX0lxFRFTTtI7ozHRFJlULcHXdXN +ntGQiyRLTbkxXt+Ov2SI3ytI2gUPpuhNqv2c639EMgpLDMW0mHcE2aiPQvmi7TI5yPnwBB+i7Jw 6DYH54Y7wQ48kjkgb+b1offqz+BsmSNqqjhHF36ZlAODGmtjbAdl0eiYWF4qNM02gKE73TbzKJ+P 3OFkmaMKlWnYLMxN346eBR8W6WUevXCswTj+/9LgmH9HmoAn8YRYYIT1JiWLRgOaw0c4p8e3H8T3 g55T1JK5FnvST1ZV/TirZbFf5dELl/gZU2f9YZghrUIW+LxNecfiTOLyV39R9B1a1UKI3df/xz/0 s6lcjp0jutjX8QlNBJLqrukqHg+oN3atS6xzFxOkXjtvNG+zzTh0OSEuIt9lfCPL5dh9qvJZv4z8 o/6BTTo9rFSE2Dgc7eT6OwufulQB8uUbo3eTWZ46pcW9k+5GVLclWuOg74/uibTaM0O108Dl3Lr6 TOdOlnOlEabGEJkUmJnp3svT4DzOV3Rn2HIik4VPbNIIKtNw9Gx4whFio56oTatKUBSWZT4hxgsq q/rN7rBIppPXy/x3Gri85ULSJ4S51hsUadFCaeCSrQ/mAfXiehn5R5Y9ioqrJDybpX83gyn/Cqef 8t+yIhZpOHLIs1CZnD1zH3HnwSgJXMETFFtP3l0s/zzxDqmhJ0yauRG+ToNjyw1ShMrk3fj1Z9KT RlaXkX9Efa9xl+7qkbmEfSXEdAIYrwVZ0lOvrF2vC8jVGIF0BEW/pSLE+C5e51SgWq4ESlQux84R Zz4I3607L68reLCCGTX5hzQQHldeBN6R5lioE4/k9x74J6w1lO2UYpmUpNTazioLnxywMseLgbKr tQHtuNiL/pRC94jw+S2H0hx3ePvqzq+y8InNvk28JJD+18YTqR4t96SPrEgn8ZEEWXSkM7aqwlTj QMt+NAqpnEHXaXDSfNJPFP2HpiTEZM9J9E3T+at4POCnOV5fxGnIvG4+Br2WG7P2oywc2qzHEeZM 3Y1DF5eJ6zQ4Znq+ysInB4pMAlhzul+xmvWwUt0FtQ5HNbnEo2uTd5NZnmal7USIW4yDqj+GJ9Zn eUTZiiR4+pijkn2nc5vlNAtTnD4dFBjrPNMfrQtixX6BfUf0VKW2z+uo/QaEWKa2lLlm2ezPaVIw nwhrMEtAMceVB1a3XMdT/50Ez59HP6+iEXmRhLx+SBZhlK2YxvOvs0/1F5gFDJse5lniF+QOq76D N2ScpePtI2XVV9mHybTZjjRyF9pEyXSy2JdoKiDEJqA8njbZuFR3r3QS1pO/TOfkTkp3QqA0lyyd FXIOKH/VlRB38CO8iscDZkaow6f4p6xBiGWyy1qb7oRY3458vWvw7uhJiFEauMIumvPYUVrerRJi xd6ehfAS2whxL1k1WPEOIcLlSX1wIEiADNbkl+/yFhglwYC5oOglinWGhtWvZgx1Tn3m3E7Z+SLy bemyke+t9EPlmSur/9dpcKyfX12MQzcf4iLybYZllsux4hIJN9XdXdWsh5VM/joMR3kginWGOeTW Zl0wy7NFabsQ4jbj0POJVVVvq5zxlzx+7Ykvpe907mI59cIUCXGrAqsmS4tDsKpN7ifrqf36hFje CGI18sP5WUAYp6xYwnawfovs+1Mt5O5pvDyb8JHdKA1c69B7NZ7MGI9P9818/vFr473ArPdZOLTl XaMtikO42hB4P9lkCAFA8ts98sP3QRCXTSMyF9nLtBVAiFvBumZZYoYKZTZinKJVd1+mXK7YD9U5 B4iRZU8Et0CI8ZzlDlllDxAGd5gQi05czT5GMZx+hFifc5rzMdshIe68valQHs9Izrh64FJPeslK fgAzH5h1VJfTl/NZUg1B7B5Kg4G8mnYUxTpDU/WczyaueqjaXUp4m+IP1cyAmbza+EW2q2bj0DGo Tjg4xHNfuNfWjLEDVHpYSTO9y3CU86j24Tn0xu/kywqmrS7y1CptB0Lcahx6PpE8haYqUlwz9p3O rRbYKEyBELcq8BqEWPlf7sP11H5tQqxQmsvIP7Ieud6kZpwSiy8in42fJY0IB2P8Oo05q+e/ouSy 7kERjWz7j+H4A3n9uPHGX42n7FhdBC0Xa4LI2w6F5XVlneMsGtkiO96bOlmBYrNC1Hf/OLG1p4S4 jw+x7UfFxpkfmgTD3JqxxoLRRoh1OQc4w7QlQqw0dkYR9fAh1p6e7oQQK9y3TOiVQ6D14vguEGIa TeH4QfQt5pRBaffWYTnM05rLE5u54jPI0zQEbim5jHyPO6HoI4q1htae9k71UHHG8a2pT8v4Jbxp Xpz+OgLXyTh0zTIhHGSqzjXXSFhh0ENRON2Go6M1dRyYZRnq43aRp8EItBPinl4lrU+sv0heh3zT 2Hc6d7HAemGqZp9JgfsTYnWb7E/WVPu1CbFAbSUp0E9MDsTqUam2yyq/RsEkSTfRPLvV79cZkSnu s5QeTpqIKO1RnCbOQBEqtAfYW0LcPcuEkIqh02KJ0ncTxSwizsGsp/9WCTFzRKSb/Ds5IRZOiYzD 6Z5lQnvjucMT4s4rd68NUuvF8Q0RYv06SuvIkMgqQRnUR0o9WI7aDYzmMRSDQNRdNCokY/+LyB+o lsaOoug7NOHpGvQnxOoTYiOfME5/8sUuxuEWT4jNelj1I8SmE2IKpnqierwtOQ1blLbzCXF3r5K2 J5Kn/AgfPwvOXzqKQ+K+07mLBa6qSiPMHoR4zRPiTQnxtk+IFW9U2nPIx6LCxki9zGOLSd+ovn+i vPC0YTwZOHaragfHQIhMRbHGiO5cYn/4ogPyfo7ryWU0etX4EmXh8KZTTm6K/SXEfF4FBaTdFz1U NsWZrbLo49cSiZe2Qpu7IsTs/bvSN5FRvO36EDcyMfsQV839mo6REONVT96b9CFWBXejdDZT9ZSm 4TMk36jQz2j2rdRdJVV10rEb8iFWGM/yIor/JdnPNkK8hqxYp151z+XYHdqZ2Uejy0RFVwrbDb79 DJ+KaeN7iaLv0KpqXUKsIwfGsxv10i5Pf1lQV1+jb0Un43B7PsQtelhJM73LcNQ+xOwOzZj+tYs8 tUrb2YfYYByU/dE/saqqqkiCF5P4qqkkZY7WbdH5dstpEqZ69hkUeF2XCcWFv7Ap6qv2axLiZsuC 8u/fS3pJoXYXLvK8bOQiRrBxUpCyrmj3RpJrr9B4PS3/Lr9/z5G0fKJsEYxOMBn9VZb1ERr2XSOD YuY2+jv9XiijNfPoBbsnk9yFmZ7kf5coCdwTIanFFooN3iD2mBA3CiaUo6uqSnNgTzm0piTpKl+8 C+v4UVWz2NN9+y4TuNxjrXUkMZB0d2lKpCUVke7sdVqVF4HndMsygZvGsbPKcnRyhp2bIsSNfzMb +1gkwauphujQamQaTyeULabvSdx97bPOJh0rL4LRW/0h1nazTJhGJ73rNkLcV1YoCdwjxevGLnB8 5BkfbIfK5Gw01ZwbSU1Z9iPHkZh3H1GsoQZrE2JqT/hXXES+3ei/9EOaJI5r6jLyj7qKsd04dM4y 0aSV2E6WiTY9rOSZvpatwzs0Nk+cKXKui1rq/tsty4TZOPTrj5gSXhHm1Hc6dzhKMAhTmeOlgwL3 CapTlT4VTqbXUfv1CHHd1+KvcPopp7si2WTb/ockjki0kOyQQPx6m0xyvmNbNPlf/SB9UEUz66Tz acKk58nyfZzTMHyybUJ5PAsXSXzqWrYbfI7DD0mJmiGU38Lwr7JuBCe4CN8t8lUtZWoXsBsN60Aj TzPyCekJ3mST7+NsKeZke3cOe02Iq6quG8TlwycZ+1ndq0EzRtve+LwJmkFlujifjF/TXOXUZrHZ 1kiIPX8SQHLva8u2KVBf1rt+mJRVRTMVstydbsy4XI8DhrfRuxesuihfTk8nfp1lexQV1y3nuEKf Ouchpj/ASbjYlOx1RnA6LvJNuglpDjmktHRCCZWqas51mu90aEdOxm4+AK7NlHXojd8yMVRFGr2b jINlExmpyNLfrFLqywrGTKFscbZgbsn4nEQqXq7wIDSMjizS2PYW6fyN7x5Zlu0GfxXxeZj+UvSk l6zq03Qm2xrxquf0Vi5FUV/ItF0sqBfa/qJo/a8M8v0OaZilztM9OZsedcDtt/Hy6kzi8jrHCZTq /SSbvZiN8TeJsepgHBQ6JmK9PMQ0VIab4Jw4zHp4rZrpbcNRTi6SGIGmFm7Js26Wp/m/zWU1yj+d RT+R4hOjcejXH1QmU49LylaHZNQHNCrDYjIObZbTKEzF7GtRYDpZ5BqxBodSkuWQqlZ5MX315ITI CDPaNdReaYEJLEtHiHFX2L2FguziYLg3dIVQZsFgck6JhKOWrJKtC165cuOYEDO1Veocxo4fRCm9 02S4rGLqkl0InyqoybAjLYpyx6jQaU9Q+n4a/6tpgXZmj2DtOSGuqqqqijQKg5oOWrbjn4amF7HK 4w/nTKC8ZXvj8wUbk0F8iGnxG2qz2MBzRXBxN28ZupF9FnwkiV2VWV3ZUkbKL9RhEFilf6XBseX4 Qfghzr7x9c+6HGB3rlTHDKRMF2HApKVz/CDkxCiGP9uj6Odc+GS+/KfLfGC5QfpbqN/GFvjQtkNv 9JhMeVKZLM048njGvGWsDir9YQIrm7aZ2j20t2IaSmqXxLp0x0HyVapUZ7vB14RkRJFeH+vkx3Wy ZvbkmIqQ7HpPKPSkHnhHWZFLVVq2ir4qVTYVNjUb3S+JA9coZBH5tqY6Rg9R9BqaHPIvrVBtneey biiWALKQc/tz7jfKHOdMHT7JOpmMg6xj6lv7tSrVEdYi3W4zPzDooThTmAyquuFoJxdKppMoq2ty tc/0VnlKSlsPiVTKaLiE/EmlMQ56qJ8oFQITVpna97rzdO5ggaN//6URpn72aRVYmFBHfvSX9InG /aZhj4fe+GOazX3b9QOWRfZXe6WgqqradulmOZceYC+xmRrck2ZvFmsEbgMAAMBNA6WBq+C+XOQM ALCP2CohRkng/qG/EQDsDfaLuQIhBgAAgJuAWICNfFom70itAABgb7EpIUZZOCT3WaiMJ24Pp0nA 3cV+MVcgxAAAALB7FEnw2BWCj8s0CsNZBy8kAOCOY0NCjAP6RlFxncdnvvcy0hbiAuwT9ou53gtC LIWCAQAAwN1Bmc7HQ5ENAwD3CBu7TNBQXD4oDbDf2C/muu+E2BSABQAAALeP63T6ksneBQDcQ2w3 qA5wT7BfzBWUFgAAAAAAwCYAQgxQYL+YKygtAAAAAACATQCEGKDAfjFXUFoAAAAAAACbAAgxQIH9 Yq6gtAAAAAAAADYBEGKAAvvFXEFpAQAAAAAAbILdE2KmSKAux2oTZa+t/SgAFw+0nX1PAdOUFtSX LrwN7BdzVTZLlcpQO/4eAydx293YadZkb5psJ7cMKtNFeD72xCK9+469Gxcq44lj2c54CfkENMB1 aA+94OLmRETKxR91KLeuBC2v3XWF3TraLQbK41l46juPtroUbmUCojKZera18yq8uAi2M4khYdct 4WZOiPFk0JSqJ7iKx4OuVQlQErj2fcnYisp44sh2qlyOnYN2xl9eBKO3+lm6yuMPYUBLmVuH3vhd lBYV+jGbfjaIev8J8WXkn4zmX+Yj977oSS9cxeOBZQ+DZEdVPi4j/8hyXmwr7ziTeG5fiGMn7OG4 MCG+Wba3Xygi377Zs5jm3MS8huqAz496HTltHW0Wozk42+bZ0PYm4CqPXji7nsXlcuzY2ztlAPTG zRBiPCGNylREvs3OdrwnU9sdlAaD+6M0l5F/pNh64gTPLfbLsItAZfpx7B1ajh+EC5oimn7YZlj3 nBCjMv5zhIuLoiwanfAWFhWL94vbWRXuC1ASDB5vm23jg7cNl5zLRfjljpX628q4AHcFW1p9+ipq l0MlIzDjvC1CrLMYxZdwURtnzBO2flm6rQlYJMHjwdryB+wDboYQazhfAzzbWZU1EOLrNJzen5J4 4k6gAUqDgenIfJWFTzTFfoskGNqW7fihXC2FqbatxX4TYvQzmn1rzrdQFr2e1bqH8vnIfX5LxyT3 BCh9P92+M8bm69Yqj164d672NRDi+4TrNDzf+EZ7DUXdb0KsthjiacUdJ8TiUgK4f7gRQlxEvq11 IK6qisyEW7vNuU2gNHAVJmCVx2e++zTMdLwflcmZPzxxFCaSEmWdqwBKgkELI9xvQqwHyj9P2s/d AbeCDdetVb5847XYmVsBEGIAi/UUdb8JsQIoX048m1v77jwhBtx33AAhxjPZqOXYJ/jOrWQ3APVO AKXToX8WG07By+XYm8xDXxIsdgG0LPuJlkyjZDpZmEV968x1s2ZRmUaBj53HbIdIkgZGNLDdIPnd RHJkeXzmO3YjOpTH4Zj8xPYMZUuRoZFqlcfh2DukPty0wjnK49l54Lu2HxXNgw69yWfmSgSVaeg7 Nh1Fxl2zartXx5EIuqHpCfnXhzDwHXsUFdf112zvzZJXQv6Zk3ladP+vSm7LKX5NtjdZfpvTdYvx /KNDaFwMlZwAX4mwOP5n+JotiE3NCwnusSzLsv/xP5b/SQVFX5xlWY4/jbl7qW2Na60G19IBRruu 6s5woIJt/FMt248KErx1KFnjIo0CIh/L9YOIu3rqOlNYzVQL3DiVijR6xyhwyFhIJmjsKounOGqi nvsMyjQ6Z7oa8m+6TEIsK8efxtkV51tlmD7KsSplolBULVFDOR3IoTf5lMwlQtzZQFWVkhCzI1II g8Eqjz/Q0LRfjXW1vckyR7zCC91Qqzp2CGThBilqCHHzK/oIdiR6NagfusUJWFVlGnFxOIonMl+W VeiX5MPNWKGmY3zgIzMxmR9WnG2cf5Om+eEQ+wr2GGPHuYPKdKGcOl3MtXFe3yFYlo4QC4aS0VDm In5FxsbFRQoOEpTzXWX1+xEWWu6UlNUD0cuCeyWyhz7K41mtuNxEKtJw5FiWZbl+mJRlPA3lew8h 8qChBZYzCkVlqpcH2xnNotPaQxpvRqnQqnofrLF66+0EUBY9fxlmhWI/jX6Ew3YX4VZYe0yIUZlM PRe/MnIY0+gn1q56VWAiOZ4FHxbpZR69cHByBpRFo2NCT4mNa2wNB0Mj+G6UaDtRQnsYZojRE+/l aXAe5yu6WDIWLQuHZCDkbLtRFX33FOapqmhQiOuHSVkJC9J/O/mPP+hU916dBmdxjuj+gblnQGUy 9Q7wtKIsjTFqKJ+P3KHuvzJQFg5tGrxVJuHoqXdy2CwPOOCaHUKbbuOBs7MJ5fOR0EhVkdXImSzj f1JBHXqjN1OytOOfNAk6tjyung2upQOMdj0L5ou0yOcj58AZ/98png6iObqM/EfOeFkKNp/pRDQa ULMvXUB1nimMZmoEbppKV/F4QBeOWm44bJQ13Sej03fLfEUV3uLWpnI5do7onpPOx9ohGP0Ih8dk gmC73dDHIgmGB4qJrFUCg0xkRVW18CMcHtK+FWn48pn3B0eIuxsoDJEQ46MTdxRlzVtQ6yHL3lx/ cjpdNvbBsp8GH98GZ8sc1Val1i6zxZDPg/Enh96rP7kGORJvUINa9tucgMTsEC0iSqV9d1oVqg+q mrGgLBw2k1EV+EjIg0SEisi3B+P4/9VM82XZY4wd5w4O/aeciupbE3prNtemeX23YFnGE2JCVcP5 dPznPC14v9VVvngbzD+F/hGnsoKDBDayztMxWfWprJt3LDsQY10RVr4iCYY23YBiZWL0skjDkVNv W/BDySNw+3jmY+XQJ3YhDPX8y3QyYR7EDbBMQt+lW64iCZ65zgGrsg2/R1k0wkuAhhDrHYj1WGXh y+dRhlShimTJ2fhebI8Jcbkcc++XZOgjQhYIMfMFPs/UKgufHLALXsuFo7KRCmXh8IA1Q5ipEKtB 1kXmKfxKeZ0Gx5xeZeHjEf5Xa/e4B1WVMCPqZzEdJpJheivICiWBywqW5lEiG78f4dBh1mP+vzJQ ErgHnLiI0az1WRqC8CrlJlU8QxwmaXlAm5WfQicRltXWx9WvwfV1gIxCTOGkuj5GSeCe1CRG6s8q C5/YHK1MQt+lveo7U9oErp5KeD3mVnRimWvhKJ4rKMxVPB7wLBYvZ/QQKw1cVjLoR/j4ZSNMrmXF KBh0ejXtPoTyMVMzlr5i15iI5s82dwWyWWI1h6Sfk5SZNbZ6i6EnxEyDwnc6qMGWJ6D0shQriPBl tQopXpAsUvk7+BOeEKM0cOkn6mne12q1zp1yOXaOuO0W4bvdzbV6ibxrMBNioo6u/7YJqq1l9+/s 69ccqRfaRi7yqi/pgRxyJ1O9IgmGNnMkzDPmVRY+sdltInfyKrR2nU5PdVYDL5+PXH/a7Dj5N83t F5ufsPkxKL//OwmeP49+XkWjA/VZgmIn0AZUxq89olLy2kZ3exunS9xbQoyKaMTn2qTHG4Tf6Aix cNCeBO4BfzuJlVa3YCiXE5HN1C8Ia6ZiXeTMH/4yOcKpqqqJTG/vnmieeM4hP0spGVbBVLtWZvcl rgQtezOl5gv6vB1CTCassMYc6HcOFWegtj6ung2urwM61iXvEPjgXWntNN9i9Z4pLQLXTCVlWDbf lIoRcmqvPH1gfkUk04Rx1+lodCuUhmGs+2r4XgldlblmL7HL8rmKxwPxIrcfIZZ/wipPi8XQE2K5 wVoUrWqw9QmI5cZw9HZCrFShdQkxkQl7mHqdBo9FfqU4Beg7RsPcUUpVMBQdCfHdqrcgw0iI5UMj aWWV6CBOgNrcyyhEKeiBPPlFko2vGxidKC8Cr75Own1gVTaLRi7rUCGpqQ7yDlXoLT5R4I76pag4 PGlP4+XZJDInwG1NviGhXE5GM3pTqWMwW4gr2ltCzFwACWAds1oJMVNNRmhFw8b0q7gSbpCiVkJc 36lZtjc+j1LpzMPQPc0JseHsoYUQ6wVrHQfpL+ZSVf6vvN9ThrnshhCLayoqoudM7iTlUV/94d/b Hhfq2eD6OqBlXeKL5tZXmRC3sLfeM8Us8EvTfBRNJa8PyiPS5sPf6qA01ryTQy8s60XjIix4c7JQ Wu+1Xw33CoyEuLfYTUfIjKuh/ue9CbHZYih3Pm2EuF0Ntj8BWQmmUUhDU3Q+kBoVUsq/EyFWHVEz MfEqXeo/xpa587cyKpGngg+BEOMM5PzVlerWg/HOEe4vlJxPcX+kuEFjNOBHODy03CBFdZkJNqah vvr5TSM2ZH9wcjXWxolx8nD+9oE9QhD9NKhAJC23Pf9VELdcDfR1IK4nm84iU8P9gAmxcA8ooRsh lrZ5rdAdM9uGDU8rIa6agCrLshpf9g7dk82TkMcQ+yszW7sWQmwWbIdE49zI5cW12hkhFuo/XUb+ Y+naV8fPfm57XD0FVVVr64CedfFRzkXku6zF60eI+8+UdQix4n5D7mrLov5Lozx8f+qIKMuyaof7 9ixJ/WTSRoiVes5Rw/5iV8qHBh87fhB9i42Tqz8hbjPF/QlxuxrsZAJWVVWk84lnH3rjd1HyRfUI BkoVqtYnxLztRUX03OWvdyRd6j9G89z591/qIXO/uv+EuMO1prjkY71hJpXClAjbXznNgpiVggvF GL8NQ27jxfzXdvzTMPygiQAVI5ZUXzFfVHW6y9O47imgSbim7VwSvJiwTuiK7TKcELfZgj4nxH3E qNcN/ZLQgRCTT5sAf9xae/eUtGOVR3++8k8wtxKDyjudEOsE2yGTDPf1myXEzNth3e80T2F78mvb 4+opqAa9dcDEuho1E87LKx0h1u7res8Us8DVLhNGJtThhLjJYKAjxHwK/CZHDQ4FadnZ9pXJ5oS4 v9hl+eBgnjouqmVyrXtCbKBl2yXEthskaBcTEAf21YH16keIwhJVqNqEELNCEPbzhhPiPmM0z53f miFzq9X9J8SKjGCC/xm/T11l0cc4PmWdVxScT3DpU9gagUbo/MHRr/IXavEWR0X0aiSEPbYQFNUh H2a3CsZJ7/0lAAAgAElEQVSAfTlYI9L9rffaxqEy/tPni6ma7kr0dBxlH6eLdo3cW0JMbId0FUB9 uXr4EKvCclE6U+dl1/sQK/Zg1+nsYweXCd7ZnQRoMiu0qXuqE+LG+1yFTj7Eish6lH6c0URpuv9K D2tlRcrvrE2Ia8G+Dk9P+J/re8K6tWxvXD0bXF8HjKzrKh4PLOs4SJJwODS6BtbLtmTTyoso/lf/ mdIicNN8VHsxsq53ykXdTKfYd/1uImZlYQ479RNZxEavplK8guZDITi4u9gl+Yh7760T4haLsY7L RLsa7GACCl0yEmK9Cm1CiOkdlxskP8PhQAqwU/sQdx9j69zR6AZ3gHjvCbF8oc977vKUDpXJh/Br Tjn071/lL6Sg1JIPbi3T8tss+snvfVd5+qPUML8ymXoDjSNmVVcj+5UGJxJb1XFQubc4rwWN1ZOU BuWfAv/Yto786O9f5a9GLToleagN8dXX2SejrzEqkzP/ucTw1C5x2K2CyYfCiSWatDpyVFW1x4S4 zv/Cuc2gfP58vKChSB0Ice0Ax6XVLJLg1dSgPNJsp9cXrIcPKpOz0VTjSigG1Q3ZNZjZsLV2T+lD fKBd7dSS4RlqI9ggqrMQlhfB6G0TrWjxCS/r/0oPw0mIeJMt9FkWKaZxaxFi8lvNdaRwHpmFwzqM Zuvj6tfg+jrQwdXBsh3HUbtcsz80P6jvTGkTuHoqKatyXkb+USNqVZ7dLHxiN2nFsW2U74KafIUD KfgbczuSM4tLwNxMZAkbvZqqonON47tKZ8XuYm/NdLF1QtxmMdYJqmtVg61PQE0whpYQ61RIZWCJ fDoQYiKZA8cZKJcYKZK41xjb544i1xZxFjUk0RPM9Z4TYiJoQn9RmX4ce4d8/uCa/F3ny3fTRVZn nEh+Ls6YP8k7KNP52LO59MD12X6Wf73IUcVMgL+K5P10gZUcG7LaHadI56/9Ec2FXFNAkl1ylcdn I//PZb6iPsH0sgMTekP9NpfJaKjoLZ4bNL9s/CEkflfHQfwlDP+i3mbdXLso77/KL74asnyT3OyS GtGEbopdIC7GJpqhNDp/M379uS2skGCPCXGzejFo5m3zElH+6Sz6iXTZbeXU8YaUMdoUuXIe/vr8 nhh3Mddj01uSYYBmtcShovTL5u4Rg8icaemicGqfVBK8xYauYntdNyJXNmG/b/6vDGIuaXbbIpm+ HJ7QGgEMCyEmCOXL6emkds5T7jnxGJ1JXF7nizDiD880LIQGPjp8rl8h+/J2x9WjwbV1gGqX7qJf yQ6bJ/KGxaxsvWZKq8B1U4lYvEMuizCbip5oeC15nIOcO9al2XbZdKqD+jaJ3H/WP+dSpRomsgpm mRgVFfeUmAIiJVQm714N62Tho6hAPcVe5xmotwfselek8ze+i9O6/VXE56HE9qh9YIPXyZtiHkq2 nQ09NVoMcps3XpYoW5wtst+tDXZQgy1PQP6cu0znk2fuI8xi/05mi+/iEaxBhXDHyFkVyr9Mg0kd G8DmHVImDFZR0ko/zXtarfa5Q0+7uQzQAyb7TZu5/vd/baVCwq5hWWpCTKiq4xzQye8HM6GODd2u 1bsQMsdqEonKdBEylTLEuEvqcsAc5tVi5QqrNIVnLNvxT2diHammFBMXi43ScBqXmNpalqLAEosi 8m37kfOIapHrB+9jsfAHziFfc01+ueLOb9pAAn3Emljc4xr3aEvaaXF2UOZhTC0fC/tei2/PCGuP CXFV79+owjAbg+Ylun6YFJyELSk/a10pyjLUcULmRuriNeRF4CpHQgKKIz/6S/rkZzo9jbKEFkmS KiRpuif2h+aLJfm/Zdj/OD//B2s8bX/+k49Trsu8Mb5xCpEIM1Ff+AoDhxzgL0/m6ffIf+T4p2Gj qXU9HXzE/isNji3HD7RxAnU+ebmSTsWnH2Y/PLKso2fB+YQojMJKbHtc3Ru8XkcHxKwIykUIFdHI FtZR8YeMJjPFusR8F7puqGESeMtUYktvya+JnHI9DT6+Jt9x/CASi7dxbfBfQOm7SfS99tWWxsHW 6msrV9YiE7Oikt83Rsz2xvMki0a2oPxdxS4sGVgfmmBNvNoSyqXokpS1wD1dzoU8BsfB8j2/5aZX xwaLQdit7fhhms25n9uj6Kf0CS1XYVID/Ka2NgGrpjoGeda/eMLNf9esQnW8HT7XxymTSceU74jF ZeQ/UiXa0/6kxxg7zR22rqG4qhKxa8z18j//u3GJvEOwLDUh7n71fz+wdrDL/YS134QYIGOVR6eB dEKA8s8Tz30Qai+mU8AwV1gAbB07E3hrZQoAAKAEzB0KDSFer6TwHkMRQfiQsV/MFQhxG1AZT1xd LTR9nZp7BDmdAgYQ4hsGEGIA4I4B5g6FmhD3zAi2/3hwG4AW7BdzBULcAkNEHfoZzb7d5VqaWwHK 5yPnRHVPB4T4hgGEGAC4Y4C5Q6EixGKV6nsPrqI9oNo35gqEuA04nkNwi0dlugh7uZbvGWjECXZr U+VdkQIHATvGrgQuBKQCAICOgLnTQEGIOfQqLLyHaIuIeqDYL+YKhLgDVnn8PmhKKCmCU+8daOgS l5qqhhScet9t3W1jZwLvFEQIAAAkwNzhoQuqAzxo7BdzBaUFAAAAAACwCYAQAxTYL+YKSgsAAAAA AGATACEGKLBfzBWUFgAAAAAAwCYAQgxQYL+YKygtAAAAAACATQCEGKDAfjFXUFoAAAAAAACboBch RkX08vEN5ydqoiAhV+jNYb+YK9dsmUbh27F3eCeySpMC3XKBtO4o0mh2PvbEKrv7C6byqlCh/SY7 gavR2t40Wf/V3DugPJ6dB767y7mDczzZznh577Nf7wyoTBfh+diz18yJpKnuDmitnwy45+hDiMvl 2HvdY2kvL4LR223MNFTGEweyRt8g9pUQM0lkuEW9vAi8Q20y2t2hXI4dewPWxRjo+7FolReB5wzD H6hCZTL17NtKfnkZ+UeW8yLKH3reTQa4ZIY0d7YMTIhvfCZWdDK2DA2VaUSzE3ZMTbjGT6qqWuXx hzA89R1NxRzD8xo6uxEh5kQhpt9iaaE3Pl+krAXDdRxMkKlkkUYhk/bx0Bu/ncU5Qj/C5wJJaPRQ ZcnTKPAd/A/HDxSyXuVxOPYOrfo7kZxycZXHZ75j4y9MFe8Lb5iBED84dCfEqywcjXqc0V7F48GW DOtl5B/tjBAUSTC0LXcUZaD6NfaVEFdVc/jHmVFcDqDvEnK5CL/wCoyKxfvFDW/M8PJzHwgxfjX1 K1jl0QvnVggxSoLB4yC5/SuE29EoPRRU6WZQfAkXO70AxLVpWoaGsnAoUr2WpWGNn1TVdRo8809f ebaSO3YBZo3bI8QYxE42zaJ8OcUsVto9onw+cmzFzW2ZhP6AGRQq09B3bMv2xmHNPZldBG/ZTJUB SMkwji07oznDZ7FJ8SZL/NkqX77xbKEKTJEEQ9seBklRkW25/L6AED9QdCbEReQPui/JpEbUmoZV 2DUaCs9uAUpCvMrCyfQBV+i4b4SY/CcJXGX9XiVWefTC5RtB+XzkPr/pm4r7Q4g3WsW3CJS+n8ZX t9sHjNvRKD1uhxCjLBqd7NIjDpXx6xPnUduSdBn5rjf+iE9DGy5oupxc4yc18P3PXSLEymYpDZW+ r6/CXSwmUzwoehGkvo3B3JSV1WXke2P13ERFNDqonaxQHk/xUTHTAQVVuE6DY+Z1kAsKhiLjLwjb ciDEDxQdCfF1GvgaNZWByuTMH544a+pTkQSPB8wPURq4N+pAjMpk6vVg//cQ95EQozI58ycdPRfx 0QLXCMo/T7zDWyj4fm8IMbmWvX1CfEdwaxqlxy0QYpQvJ569UwtfLsfeZB76ZkKM0ulQ8Gxu09g1 fsJgTwhx7bglKqqeENcgR84DLXlAP8LHL+tmURoMhqH6dB0lwVDw2BQFiNLAFeUpEGLFAPGveKd2 IMQPFJ0IMcrCx481aiqjsT79bRwxjqy+oiIa2Te3ZmAm9NBnwr0jxKt88TYIRWcxJr7LYm708KUB i/91fP7G4z5irDDTCB8lRuPhau1lg5aanx16k898xxoXN9t7s0w+MIR4lccfwsB37FF0leEzEpsu IfqedESRRgFxrbNcP4g4x8GqSKN31Dnv0BuHcXPkw/SquK59+GzvzRJ/R+WhyLwgfcuMxK7I8dvh MPzxO49n4duxd+QGCWrcCqkkm9Ojw/r0Tn7jrIjQug0KLTY1olveNT05U2mUAI2WMv7lRMGI5luW 1UaVtC+6oUp6/dT0p+IUniqnZdmOf9a8UCHmlTj3M3CD9Lf6pZNL8MZDVHoXSqAsGj0Zx//SXhzR 76l8V8y8c42fsOhHiJnjZ2+y/DYXn9JDMmsSYnFP3kqIdT/k+lJEp/QylnoPO34QfoiFE2WFU41E W7GdYY970Y9weNSQXXy4INAJxYdAiB8oLKudEF/F46ddj4dRFj1/GWZFGhwLU4XOZ3azyPoUSisE mUWsA3FNFKQdZ5lG5/KyxKwQRN0bvvu78VWiei9a5+Mg/haF54E/YLePKA1cw5b3XkClBvvSrN5l QkC5HDsHxAUNZdGIXXf1cSe8MUX5fOQOJ8scNa5y2BzLfIUJWvJengbncb6i5Ju9wltl4ZPGxS0N R8+GJ4QQs/r8NJh/Touf0cjFWSz0PekGlEWjgeOHaYkal6fmtOYqHg8owa3bJ51keuW9Og3O4ryO mbPZ8x714ZmhZUZiz4L5Ii3y+cg5cJ49+w/6PMefBNMvOaon79GzIJxysq1XNVQmU+/AU4ioCRLq 1SAW2jHhi2USNtSt27tWaVQfLcX3v9xaTl1a9YTM+KKJ2ot9Ziy5tj+swp+MTt8t8xXx6bQskmhF HfN6zS8Wmpc+XpbYi4moSpGGI8fiFUyBVRY+dcfLsrtZ4HAZ+Udtj1j7Jz0IMcrCoU0jEcskHD31 Tg4t3h2/u2T6EWJyyiv3U0WIUTqbpZx6d5a55D3s+mFivNDDh2WslaP6RtyIiyR47BJVrxpLJRB0 hV0CQvxA0U6IURY+HnU0IqssfPk8yqhxZH3zP02Dj0vx2Pgy8o+49QAlgWtLLAR7BRXJdPJ6mf8W r0WI4zzdE6tXHduPinq2ND/H6wE7E5gbFvZYi11ybivu5AbxAAgx/lqjjcJr7USI0Y9w6DBcVnq0 dPZAmmXWKtVz5U0jY8SJWvJbstaetGCVhU9sNj0cpnfkoTjNC0evCfESesWdzcjiUiw8rS2TZVJM XSeTCTpklgew3iYoCdxHjPERRNS/wWqVhU8O5P/SIbe+6w6EuEVLFYdbLVf25hfd2uf+/REFK2vm teL0RPXSURYOD1hVab+yZ+421yLEReTbPc8+evykMyFGSeAecHf6ZAtH3nJfyXQmxPVNgnyLpXwK 5+5ICW5PWknvEMgG1ZSe7zLyH0lfqFf5w5Phi8mcTTFB9mziwMmUOZKMAxDiB4dWQnwZ+Y+7OSqh Mn7tEe0U5tUq/3qRI5Ely/RXdhemn2TZ7M9pUkjfwdpvK4xFvVQXkW/bbvBXkZz5z+f5VeTXtgPP BHa/KDNyKfC2qiqUTh/f66nyEAhxGU8cds/WnxCjNHAV7mgMIdARYrZZTl1VCVUEfVYeVLf2xAxZ 7Tko07zwy6GiV9Jpk4KrtbesWbwVZEIrW3sUFb/5BBeyiPo2iBQRPPzK2vauOxFis5b2JsQtL7q1 z/37U8uZttCdEPP9vE6DY15VNPymaeVH+NinNHENQnydBic98yX3+klHQoxk1eUnV2/JtBFiFoJz lPnLHP1dkxAT1LzW4MAduOoU7+z9DPXa+v/bO3vXuJW2/+vfUJ3WnbtUqtS4uZs0LrbYJkWKAykE WwRSBPzAwkIgcHgMgsVwwGAECyFgFsQ+hANhQRwC5iAE4SYEIQjm/IwQN2a5GfQrZkaaV2m0Wtur 7PWpkl1Jnp3Xr2aul7IEQQy00iyIWY3bRrGeTRZpw0Qvqk88t7K9ULB/L+mZiBcsP0zI7hd3DdlM EkYFNynT2ST67M9C0YRUssFXOfDJ8/V9Mj/fHz+Yh+AABDF7RxYtzolJpbBV1iSIWZNNATqJdxXE Sv+5dhVlUJLmCmg+9FB79fHL+XaC2ODJOxLE/+FD7stV1F0Qa6Ox6kveWRAzqHppV0HcerrVXuau 5RE/3FoQK+WXxf11jk0aeC+3PzMpURqM3W4pdTreYiiIlXa97Idda8Zwh5i4UuhNL+QdYlRE78e7 EcQlPb/V3I6+B+NT1U58Hvsv3em6ICZMluVMAuIqAIIYaMGyGgQx94bdiCJAoDK+IGt+h29p3i4i Q50Zk+w1uH8LUQaFDQksoE+9swtpnpInYuW7uHgZSj+9Xzxuur5HxzoQQUzcp1zPD+PonOk2JoJY OvGQ6SiI+a6ruEBVDLOSNNKsk9SlEup5K0Fs8uQdCeKfonWWSGdBrHJpV9TbDgSxvpc+jSDuVB7x w20FsXya14jkCN5REBc3/ths7dv+FjNBrG5QZnB1rJnS3GSCrNG6LCptNsTkjbGHrNQeaOSx/5sq aW4e++PaIoj46FdbZhobYt7+BP9hEMSHSYMgNt8ezmP/7Yx9V1NsKghrNiqS6+noiLuG2DZIR5Cs iSF7jXqmUG1cqX3gJAtm9QEuPzbQ98X7T798Do9DEMQ4sHyVRk4QZ8Y7xI2hVB5JEBuUpLkq1MK0 +VthXOxcED/EDnHDO8OWO8S9xKWBIG7updsJ4gbx1FrmzuURn9Bvh9g03NC9/kCgaeuU/vk0fPOm W96WLW7ZlSDuVjNlaS6IqzPYhgW0adqhW9fbh4y8Db1jqZybLJx6So2uGJKcV6jRBFuWIIgPFr0g RrF/YhIxHhXR70LvbH2/R+nnRfQnb4Gn2J2V9mD4a5STLzb5pRq6aUdEHjyyIq//KP58ky78xRNk mn1sDkAQS1N/Z0Gs8ECin18v+phMNOkJtYpqL0kzikPDsizLsrgJo380SzI/GLczmTB48k5tiBuq aDsbYlUoD7pJtgtB3NJLt7Mh1jZ0e5m7l6cU5tV+NsTSeWBZ3ieLawO9ZbxDTMK0dXGk2+KWsuxo MiE0mWRD3KVmukSZoJFMFNa6Bk6NxGqiycsQpZ8Xf+miFMe++y/+3k0WvtPs02mamNtE+x6Mxcjf qqMeEMQHik4Qozx8c9LeG1CBPdUato7wR2yfK/4Ogq95Za37n6Koplq8T5Z9+1YdcMhHw66foPxb 8hMp3NjFsET6nTPmK/Qz+VZFj8KHUPgTtvCW7S3T+ON89cvvDpflIQhijbrtJIjruEJs0N/ixp/8 odMHbYIDJ5jl1zbhIQ0G+g0laaGKvc9E0i3z2D+bJ/eaxJN8eKktneran7wjQYyq6FGO54eKKur+ wJZK24UgbuuliieonICletu2zK3lUQhiHEbwld65zVAQV+qKDbKLivhiMjdRLYbTQhpOXoqJfIs4 mC2042iLWwimTnVYkvLvcgrHU/Oa6RiHmGa9pscCyjJoIANck6muRNnnefC35hRaPqPeZOG70UTQ G3kSnAfsBoRiA5g5moZMdYAejSAu1tPR+xbnABKsXhoPRJWyA7hWnyj7Mp9/riNOxEl48TmjU63t hXnxNSAjRDJgINd8iqMwyjZ0sDHRGT2XD17YcJZUjfyfcXC5ymjgWHsS5v/8FXxiRz6Nzemd+VEX j+MBM2RBTD0nWkKBkm2VkX9TlKhIrmfev57jpT2P5kGC8NzqzKLiPlsFYbqhfeZkGt2h7PNF+AMp 0itw2yE0jkE121bLQ7XdUoWSpdcQQUO7cXEzP3t1Sv7EsRfeagLNNpeEuKc4dUhOCTlFAhu8hb5q 0uhLeRJMHGaRUxytkh/ChHYm1/Bp0lueTGtMDB1K08nWrdxat41VtM0DmyvN4HZFj+rYS+kbFJ4D UfZl7s9oxg2N+OtVZrNRU/c0EhNT1B+K1cF2pusCpauLVYo0ja7ImKPcuVSiEsRkv3BMTB3oyiXB RE5Ig7HNSMMtbqnBbdccWYy/ktRqHs/fjU+PmFbuVjNaQUzHrGg0XPUZx/ND8h6FjWf0FsYVJC6y ZY+mV5+4FC1XH6bvq2hut6F3bDnenKR5yZPle2/CzldV3AmJup9QSVAn0/5zNjrma/gump5QTzv8 TFd8n1EIYl5sAL8olqUQxIJ/rgI+hnbVb2TLLWoIiNfCeluCTqxVdEOyIDFyVhPViA+kkifLWZ2P 44pPb9MUY4guJPUrtV40YOOKbuHZh401UEEsZkRr9DOr3JBxtxR7YJVToHJSrtYALmJ8nUHKYvN2 CWPBdv3/W3LO4Mde+HcofnJblmVZJEuSZOZoNL1O0qVnu55/tYj+HQvjS/BbVZekrPZ42vKsVhna LHs0vQoTburnEpSx6c3EGBe2t/whfPL6f87ETHWsf63myWJr0lvE8A4v/PVH/hPb9Vd8beN7cRI6 qYq2f2DJJLFjn3grtay6rZU9qksvlS+IffeZ450HCzEvY1tDm5W5uTxkh/g3//o9aVBGQmmHJ5GV tuMFSf63utEJdRLHxohgMq2CuBojMqJNLVW3W9zCFUbuD3rqlc4ezZbJt9B7zrdyh5rRHn/pi0Tf ZnW0bKaiLFpUmbNICS9DLpUmfnciT3O8c77/0hez9j/NZuzju5+2MmWBAIL4QLEsg9TNh04eeh3j 7wydB+oGw3rsLwfKw7PJto53ANCO0oYY2DMOIbdUP8Bk4kABQdxKTm0qDohhKVfotEYUN/PZrx8g BXhKQBAPARDEbYAgPlBAEDezofajh8WwlCt02jbyJFw0naEDwE4AQTwEQBC3AYL4QAFBrAJ9D8bH rv81XV0G3UJL/iIMS7lCpwWAPUD2GgT2ERDEbYAgPlBAEKso1lPH1pjbHwTDUq7QaQHgidF5QAL7 B+8T3ydxxi+G7AkNffiwAEEMKBiWcoVOCwAAAABAH0AQAwqGpVyh0wIAAAAA0AcQxICCYSlX6LQA AAAAAPQBBDGgYFjKFTotAAAAAAB9AEEMKBiWcoVOCwAAAABAHx5BEKMiuZ6OjixlVmRgLxmWcgVB DAAAAABAH1oFsZDg3jLIus6yycK3jjMJkrzMQ8/udC/wZAxLuYIgBgAAAACgD2Y7xMV66tiWdTTy b4oOD0dFNHOqIO156Nkv/OS+T3EfmDz2x7blTsJDT3A7LOUKghgAAAAAgD6YCWKckLNr+G70PRgf 7Xc6nE0azOa1RgdBTBiWcgVBDAAAAABAH4wEMUp8t3PWFpzGc59tJFARz0cnkKRHwbCUKwhiAAAA AAD6YCKIcT7DbtYOKFtOHNuyJ2G+n3pzk60/jGzIzahmWMoVBDEAAAAAAH0wEMQ4ST2Rtkyyb2JB scmiC8+xLetkGt2VJbWvUDvhoSJZXU1H+Ht7NFsm2J6idt0jJhYoW89GtvXCT37Qr7B4rWJWHI2D 76gsqbS1LGcWcSEsUJGEvudalmU5b5fhh3qTu7jxR0dMCV/8b/Ce5naXJXKehJdTcv3RaHpNAmXg amFvQVk09xxLLsnwGJZyBUEMAAAAAEAfDARxHnq2xZkCo9h3n7l+jMo8ns/er7P/SjYVCisLrHHt 0XSZFCVVpZXLHbnl2AtvS5SGEyxQ8bY0ysOJbR174c8i/ugv4jzxXSKd8zi4XGV54r/glXeeBBOH /C1UxBev3ec2t8l9n/gv+A3sTRq84q8pUfbnbHREhTsq4vnItuxxUJkYo8R38S3FzXzqr0lJ9tx3 sJ1hKVcQxAAAAAAA9KFVEGMxKovdYy9M08Xv8zgvWS1LkKwsiMalu8iKJ+P/vvCTn7H/5k344y6c PCPSk4jXZby6CH+gWm3/nf91HaYb6c9hacv8LbybyzoFoth3bUnlc9cQqw9uuxfvZFd/iKrqu38v ZpdxgVQ6e5AMS7mCIAYAAAAAoA+GcYjlvVUvWF74RHHKKvA29I6ZT7BCtZ3pmonahhVwtfd8G3rH lnserS9mQpAHLF5Hb6ezT7U+tl6cL68Xf91VF1RaFqXB2Ob/liR/JQUvbWmj78H4iFfwVW3QG8lj L5f+HxFjR7HfgTWMGJZyBUEMAAAAAEAf2gSxIuDabegdW8/d0axSnFjLMtcIVhbECrm2jijLkura ygAXq17vzI/EUMd56NlHp+PpgtyO1TY1vRC0LBaywh6tmBOk2o3mVT4jkRG2ymCsI+ofUt2Yh55t P3fGs0o056H3SzjqDUu5giAGAAAAAKAPLYIY1da6FCyRWcUpqUBhtxU/RAxjzItLco3CHU2y2SAF qOQ1p24VBVbIX0nBi1vavFjna4PeKOxwK//QUBmWcgVBDAAAAABAH5oFsbhvWiq85XS7rdUnsnAs aZTiagtW8Ycogs0G0ceMRQSrblXPwWn2xA1sXuyKjoO8aQThLpqeMNEt5Gh0ss4eKsNSrls9Frem YBID7Aqo3kFAJ+fRPB54YByJPAkXV9OR/ageHahIVsHVdGTvcwD+LRjOcCb7ZWM/7m632H4v7VT7 u8pXPbDLxhzWSN2iY3UeX2Q/cb97UaMgxtXE/eAGc+E8y4qyVHmnSbu2NEpxtcsrbNAyiE+TZGil ZYvvSZaKQhalK39yii/4T1HUO7sv/OS+RD+TbzkTxeKWfiIL600WvnVYIwrZXLguyc9s4KvLPinX LR7LRNyzLMvx/EWUodtwdsnMYnfR9GTLeRNoZ2+ql8RY7Jp2/kC4Db1jy3kbZpv2a4cEEx70EQUx XfKlYKPxfLS1StsL9mY4t4CX8u1yzbbeK8ec3TuYHthZEHd5K9aMr6bJ9jb0TifLL8uJK1qi7hN6 QUwiAVsmwRls71MchRGeVeX9V2LXi4cTKpLAc2zLmQQJfYwc2a26VfR1E/Qx1bLLr9HHKEPc/jHK okWwiqNz17Jd/88o+MQHgvjnL/JJtQn9Mw4uV9mmJJ551cZJngQTx7IdL0hoj9G45VUl2ao19oYh CwSi2IYAABGvSURBVGL86nI0mv2JWwFlUTCVevIjkH8JVsIu0e0q+PKkS8qTF+DRwW/1XVeIBhTN OlhQ7J+8fFSV85i1J1v3PQby6SI5Dn0AIXV4w7mF+8Qfb/vqa3avwquqJyhffVztsovKgRC2onWo yuNLO9miIvp9go/WURpOTvnzk53XwPYoBXGdJqOCqFWF2MXOcB/WmcKit6ZIlnU+junVgpOMsris vhGfJhYAX1CrnzqGseP5YVJQSc1oWRryov6E2ELUSTfKsqwzgFiWdTSa/iEUWf6ZKPFdtiRDZsCC GL/sii9XmzR49ajnXIphv8nCt+5TRiB58gI8HSj23dMdCGJFsw4YlHycP+bx5SPX3r4IYgJKfHeX U9ABD2cdKAnmklP+bu/dtSBG2XLivtlpF92FIDYZqrrxJU+26Ee4+MpE/UrD9wsuvu2Oa2B7DBJz dOM+8V/s7YECYMhwBbHKqxJ/Efsv54/ULcnpCm9ys/4w0hyDPApPXoAnBBXxhTdb9zWZUDQrYMzj 195+CeI89t/Odvb6ccjD+UnZqSDGmb923UV7C2LDoaoeX90m24epge3ZtSBGse/+a5+NpgEThi6I LXs0Wws79ffJ4rqytDH1fSmS0PecyhY5TLhxXltjWJaQgpHFPbv63zGXzryarZRP0MNfTjOf88nS bS/MRXO3PPY1BSg3WRQoMpOXmyz6FPieY0/C/L66hjkLKmvzJ8t2vIsoS+kBrq56hczt04A5dUFZ tAjOPee5F97WP1PRjhUmJSzLcpOt/vADyYqpqeaxiZRlWa43X2d3X4LVrapZ5UWR/eEpzWlvWY43 Z/8++6eto9E0iNgCF3FAEs578yi90x0mFkkY/DEdHdleeJet58Ri3vXmtL5QFi2ufM9lLqgcgjUd qb0A2/YWfe01laQdtjxij9Is2HkSXjI/ga185lfcpdHccyqnEcNGKUu1IEbpaj5v64MHPpwZJy1a +bQkG+mZdHBVbkgtE2mehD4ZjJbr+WHCGsu23LupBrI9+rCOP0mCeLs6p5blTFPXgbk6DgpUzQD2 aLb+uhQFcVNLie5xRhMdvk8eX5rJlvPqqdpUWQNfU90YbG+pHWBZvQUxSoMxcWlERTRz99hiGjBk i26wL48lGVUsyQaGuUTt+yJdli0nzokXxEX92FpSlCgNJy+IhQxZL4UIJLKJuZACveEJmvK449k6 Q9XSVa8H1FKomrxQ7LvPnMmymptUe+ebLHzrkgmaqEB7HKTEFp/MO2fn/kWUISl1OUqDsUs8AUiS cy/MG1yLoplTrYj09xKjvVoEHI3Ofvcv1hlSZHdnK8OkhFqaan6TBr+5xJ4K78NVv6IhGE5dw+RX TD5gaUociGvf6rtoekL92GRX3e/B+AXtcjjXvd7VmPz6N+fzLxmq+gD2oKjN3uzX/nKV5Nly4jxz pusC19KzkaYjNRSgV29RD4qGLt0Ots0lXlCSo7Zywb6Lpie1IiF/kTi3ML/iN3/5Z5L/CCeu5cyi /N9GjULQmkyIpYfhXMM6aZ1Ozi/XzOgg0Q/qZx6/9j+tktssfOvgYVXc+CNHO5GiNJycUAtJbDDJ dMvme/H1jPvT5PX4lBPE/QYFSdHAdaeugwKlwdimNV/EweS30ekRG5irqaXU7nEtEx3B9AQGFfF8 RLoWOdmoI1pwNaAfgwXqulxuR39BjPJwYpN3oAtv9O6Xc1g+RAYsiKtTGPp6K+4HENrWLfQ9GB8z 0f3w3PSMvsRv0uDVM1Z4cbODiSBufoKyPA4z/qVohuTNHgsvVMTz8UtOFyqCvaTB+Bk71SoSMXJz MTd5icZRKA1eTvSBC4v11Dnm5i/yjsEnQufmuLZ5uaWEOhprHsW++4zxUtikwWRiJojVP7zk45er kxaRAqPEd7mM99+Dl+80v0UVztIkuDuKffe5lKXIYtSPugD9eouq9lq7dAvK4PHM88UBhZUBpy2w 8zSvO20hMlSXRpGqRQcMZxnFBCgkBCD/5VPe3if+C32qhE0avLLZIYC1FBOntSHNAkp8l+sMVLGx aXH7DAp5vuo6KPCbElsh5M2BNkR7S8k1v1NBXKynDjvhKDKy8TWgGIOdl8tt2cEOcR1rQ7MhBwyO QQvisixLlNFDN93xSsu6pXf0xF8LsqkaxvgWA0Hc8gRleWQnTm5GIKu7M4uyL9PReyGopLSCyub+ ZLeAXKMQl6x1Gr6YjVLE+rwL1av0tRXmernSpKQ8YqU0l1BDc83jf7ORyGpv6y0FMadTi/XUeSaG zeEWYJvZCGzwv1aulNxiY5aliOtI+gL07C2K2jPp0o3cRdMTKSJngyBWxolXKhh+x65Do0gP1ADD WYFK4vDJsFQDUOPozw5nrZpsvlfZYTgb4t6DQrqg46BQNgT7J0xa6kEFcbVhirhPqjbVCWLhsR2X y63ZhSAGfjkGL4jLsix5W01uSSvb1i2zzQwFeHo1EMQtTxB/Sn2WJMJOduRAUHnEJq2gimAydFdd M1XxszlZsHHcmLD5fUOtU9tWu4cRxC01T+vQOhpNL0POem9bQaz+cJNFH6ldXbVAUoMfezS9WjXu L6gTHknbvUrFrO9I2gL07S1S7Rl2aSNQFi2Irb+c05QWSe0O1bZf1a1RSjNBDMNZhVJgmZ28qbBd P/6vzsfa4F6k7DDch70HhXhB10GhbAj2Q5OWelBBrJ9w6hM5A0HcbbncHssCQQxIPFA3eJLH1g4H 3PldL0Es5Wtsv11YwNqeoHyggVAg780K4yrVFrWtdZgoTSRO5YVjWZbFRRZXbrzJ5W9Z7R5EEBvU fOVUZ1lcfMZdCWLs4vPM8fww/iLWTOW/ZVmW5RLTVdXv2EoQ61MgVSgLsIPeItSecZdugjrrOJ4f fo2443Xl8bcsiPlq1JncmDZKaSaIYTir2EYQM0m1lD+6SRAb3dskiPvXudqsyHhQqBuC+RNGLfWg grhtwjETxB2Xy+0BQQwoGK4gRsnlTDGMcahpdnYzEcQtc7fe2NF0h9jYXLJl7qZs0sB76V+cqfww 1FtKnaYqtdxkPLiF42nDFfQpdojba54JMKI/BZZpEMR4iUrDiVsn/VLXDOuUrftzDYK4wWTCcMWV C9C/tyh3iPuceNIUPJx70HaCuHGHWFsnSsx3iGE4l4rblYJYbzLRLJU0jd7jXnmHuE+dq3eIjQdF T0H8eDvE+gmnyw7xIwQZBEEMKBiyIPZPtCkPzQWxznILFX99juqDHukoEyWLRWJkMtHyBHV55PgJ KLleVBs8JAAkDWfDe1OpjQ4Vm080Pl2r0eH8nJnFsF+8cKgqbAdKaw9nw/eYNsT6mkfxfLaSksxr T2wl9ILY9RMk/SLRDY59naMxKJr2t5pMhPU2xNqOpC9Az95SamyIm7t0I+KJdosg1r17cEaW6t0p 80YpzQQxDGcVWkHc8MzqLu1wVluaFjdh9E/LvaYCvcegUNsQmw+Kttdvo5Z6eBti0V6xLCtD/A42 xB2Wy60BQQwoGLQgdqvtNwacR9DYZKJaPvkwkMWNP/mDmQoFd7089s/m9TTUHGWi+Qldy1OibPlm sqDTKE3HyHgfK9zSiQkd6w6LivhiMtftlglT7ZhdCXg3RLF6iYWi7F1Rz3GPJYibax7F/slvzLRb ZXrfXhDjuEjj4LviTUmKC3HCroVNLkHKKBPfg/FRHUhLeV5M0qvajueHUkdqKEC/3lIqaq+tSzej GVANyzwNuSXZkLSEwerQKKWhIIbhrEAV1zYNXjU+s6xP/7g48cJUrJtmm+8lKWw5vas8dth6UGhj LBgOCpIVnBfQXGMZtNQjRJnAEw4bUnr5ZrpSGympT2k6Lpfbsq0gNp62gCEybEGM7fzqaGsksrot rWqNgQzlsOEWFwtGDmBer1j0tXi6LlC6uliliE4fziwq7rNVEKabxid0LE9x448cxcRdHyirClDK Ef7rjSjqZMP+ZDy1sdqusjFN64CR6uqlW2tcFNiT2quduC6xNUCWK11c4bYS6mmoeRJlogrIWoXv 1TSrCPWzcfiQroJIHc3jApVFspy9dp9jQZxF849xzOaZ39SRVlW/nvrfuHyI3Gqdoy5ZkpFAQ0fi E90LBejTW5S119ilSX/QG+yShRO//ebJ8oPnHluW7fp/59FVkNzTQx426BXe+Dwi0UyxsTgTUYT+ CtnN37BRTCaW9lY4zOFMfyNT1esPI5uNKEyeKUrq5om017e4imi1FDfzs1enpIqxXuw5KPB0cTKN 7lD2+SL8gVrXHRFcq1Wl5fH83fiUpqrxwry1papFsx4pJhOdfJcOotr5Oq7uEmvgv6ox2NpSuKrJ vNoDy9pGEN9F0xNIGvkLY9YN9vGx5HyT5vGiM5TnLyIhpn2N1iuCtRqUYw6UXHA3MVMTzZJQu2RV ceYZb5WGJygLVDsIMpfTTYV6qVAku9IUgMnDxCTuEp2dbW/5Q/zk43p+HqYxNbStk37pq5dN6cTv UApOxPYk/LEUP+FtVwxK2DhB6WoexfNZmFbt3t6sAmR75rV/RYNhC5GwK489vKt0Tzb/vCApEEou Z+G3yoizsUfQHeLX/vUML6BMldZdwuI6Br2X6dj8r28pwNa9BbusKWpP3aXLSjo0bEHVTmB4O43G KZsEyU/et521UWFDz7BNI7nDV7FmjRvFeGKh18NwZiE7jr/51+9JAzEbt1JECF4wsSlF5RZi/QHk GBpt9y5JfzkaTa+TdOnZrudfMetJr0FBE/dwL37aQaEmT5Z0ChjNlsm30HvueOdBXUR9S4ndvjKm b57oNHdpQUVyrSkAWwN/RZoxWF2qWy6fUBArD56AXwqDbvDrPxYAumOaqKw3XdNYDJTbcHK229j7 wJ7yMKkWAMCcroIYFfGFNz51HiUEBvBUDEu5giAG9gYQxDsEFfHlbLHj7KzAngKCGHhqOgriYj0d zZaB1y9cDrDvDEu5giAG9gYQxDuiSMKAOfUFfnlAEANPTRdBjNLwzbsgzfUeiGzuJc6psOO3lQF4 yRiKYXOWf6L5R2pWUlnjuV4QF0U0D8DNbzcMS7mCIAb2BUOvvh3Q5qIEAEOCul61O2kBwENhLog3 afDuTZhSd1TZBzAOSMagpCilQHcG31ZG0ly47Dz0bBrEDl9GdkTwBgnOvY5F83PYtN4Vw1KuIIiB PUDrlbVzWhyMAGBYtPiAAsAjYSiIURG9H5EIF6pIn3hfpI5fwwe6a/4Wx85k3APZCIhCLhkmRrqg y/m44kA/hqVcQRADAAAAANAHM0FcrGdVkHBtrGldqLzmb3Hc+/qUhAT+rPKakLCgdajIChIeUsyA AuyAYSlXEMQAAAAAAPTBQBCTaNg8zGmgOh9SafQtk6I6T8LF1XRkW643X7Mal0aXlDUxzd8DmnjX DEu5giAGAAAAAKAPrYI4j/23M3ZzV51BXudVbfItkdief6VxKia5W1TuIzhPzCO4sBwWw1KuIIgB AAAAAOhDsyBGRfS7V+WKxB8JO77EHF4jeZu/bQ5RlIeTSbWvjDeD8ZUoD88m1S14AxtiteyUYSlX EMQAAAAAAPShQRCjIr7w3gjWCCTJNeMEqhS1m2x1GcR527fK/eNNFr51vfD/Jb4rGmbgv3uf+KdM ATRRL4AeDEu5giAGAAAAAKAPGkFMckZLe7ckwzVrvUDDB1YZ1YsknM+DODf4ltoH26MZNhtGWTR/ 683+zBCJqkYTfOexP6aBKW5D75h54I0/OoJgnLtlWMoVBDEAAAAAAH1QCGI+yGW1GSxF2ay/ypPQ 9xybmgJ/5DNuNH+7yaIL+u3RaHoZYplb3ifBVVTcJcvZyLYsy3Y8n3yFkmAeFUWynI5s8swwKUAO 75JhKVcQxAAAAAAA9MEwDjFwWAxLuUKnBQAAAACgDyCIAQXDUq7QaQEAAAAA6AMIYkDBsJQrdFoA AAAAAPoAghhQMCzlCp0WAAAAAIA+gCAGFAxLuUKnBQAAAACgDyCIAQXDUq7QaQEAAAAA6INCEAMA AAAAAADAYSEI4sdV5MA+8kDdYFiPBQAAAADgQLAs6/8DUEup1kb5NEQAAAAASUVORK5CYII= --------------050109010104010006010003-- --------------040300060604030709040107-- From ferda.topcan@tubitak.gov.tr Wed Jan 9 06:48: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 C21AF21F85C2 for ; Wed, 9 Jan 2013 06:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HELO_EQ_TR=0.935, HTML_FONT_FACE_BAD=0.884, 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 8AMGGlCamlQy for ; Wed, 9 Jan 2013 06:48:44 -0800 (PST) Received: from mta01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id B32C721F8596 for ; Wed, 9 Jan 2013 06:48:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mta01.tubitak.gov.tr (Postfix) with ESMTP id A11F01C30BB; Wed, 9 Jan 2013 16:48:28 +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 RbU48JyTfHd3; Wed, 9 Jan 2013 16:48:25 +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 777481C3A29; Wed, 9 Jan 2013 16:47:47 +0200 (EET) From: Ferda Topcan To: "'Denis Pinkas'" References: <893e0664.00000168.0000000a@UEKAE-PC> <50ED6E74.3010209@bull.net> <5a2dc3de.00000168.0000001c@UEKAE-PC> <50ED7EFA.9040607@bull.net> In-Reply-To: <50ED7EFA.9040607@bull.net> Date: Wed, 9 Jan 2013 16:47:47 +0200 (EET) Message-ID: <38c9f2f8.00000168.00000029@UEKAE-PC> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00A9_01CDEE88.FAC3C7B0" X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraConnectorForOutlook/7.1.4.6356) Thread-Index: L+L3ezV/y4Qe5M1CiK9k/3j+42oySA== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Originating-IP: [10.250.10.217] Thread-Topic: Lack of AIA and/or CDP Extensions Cc: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 14:48:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01CDEE88.FAC3C7B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00AA_01CDEE88.FAC3C7B0" ------=_NextPart_001_00AA_01CDEE88.FAC3C7B0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Unfortunately I don't know any French. But I think it is given how to use CDP and AIA extensions specifically, based on RFC. We have similar guides covered by regulations in Turkey. Thanks. Ferda Topcan _____ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Wednesday, January 09, 2013 4:30 PM To: Ferda Topcan Cc: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions Ferda, RFC 5280 is a base standard. There are other standards built upon them. In France, thiis is the case for PKIs used by the Administration. Here is an example extracted from such a document (if you can read French= ) : Denis Hi Denis, Nice to see an answer from you. Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these policies in practice as Liaquat said. So, = I think it would be better if standards put rules about how to reach revocation info. Verifier has only signer's certificate in hand to validate the signature. I think signer's certificate SHOULD contain CDP o= r AIA extension or both. E-signature standards are more applicable than the policies in terms of interoperability. Thanks for your response. Ferda Topcan _____ From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Wednesday, January 09, 2013 3:20 PM To: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions Hi Liaquat, It has been a long time since we exchanged emails. :-) You said: "it's better to use the approach recommended by the CA". I do think this is the right answer. A Relying Party will apply a validation policy or a signature policy ( if the goal is to verifying an electronic signature). The RP will select the validation or signature policy which is adequate for the context. The rules that are applied are defined in that policy. Theses rules may say at the first level : use CRLs, or use OCSP responses or use any of them. At the second level, they may enforce freshness conditions such as : if you retrieve a CRL from the local cache, it MUST not be older than two hours. In this way, the nextUpdate date that is included in CRLs is not relevant= : the CA does not dictate the validation rules. Denis Thanks for your response to my question. As I understand from the discussions this issue is not considered in standards. And I think it is = a missing part of revocation issue. Best Regards. Ferda TOPCAN -----Original Message----- From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] Sent: Wednesday, January 09, 2013 1:35 PM To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions I think it's also worth looking at it from a legal point of view. If the CA is wanting you to use a particular approach (OCSP or CRL) as defined i= n its CP then if you as a Relying Party want to show that you have fulfille= d your obligations it's better to use the approach recommended by the CA. Of course in normal case this is not easy as end-users do not generally read the CP document, or have the expertise to configure their settings i= n the RP application - so generally it will be what's contained in the cert and local default settings in the RP application. Regards LK On 09/01/2013 08:58, "Ferda Topcan" wrote: Hello Timothy, I would like to explain my opinion about this topic: A CA can produce different types of certificates from the same Issuer. And the method of obtaining revocation information for each type of certificate may be different. For example a subCA can produce QES and OCSP Certificates. The subCA may choose to publish revocation info from OCSP for QES but CRL for OCSP Certificate for some reason. In this case how the verifier knows how to check the revocation info unless its is specified in related cerficate? If you would answer this question I'd appreciate it. Thanks in advance, Best Regards. Ferda TOPCAN Chief Researcher ................................................................ Disclaimer -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Tuesday, January 08, 2013 8:41 PM To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions On 1/8/13 2:46 AM, "Ahmet YETG=DDN (B=DDLGEM-UEKAE)" wrote= : We have an disagreement between our testing group about meaning of missing extensions. For example when validation a QES, if a certificate has an AIA extension, but not CDP extension, and CA is publishing both CRL and COSP responses, 1. Can I use CRL for revocation checking as a first choice? 2. If I cant, can I use CRL if I cant reach OCSP for any technical error/reason. (Problem here is I need to know that CRL publishing address, and in our example I have it from elsewhere, >from another certificates OCSPs extensions in the same path. Weird example, yes.) I guess my counter-question is "Why wouldn't you?" If OCSP is not reachable, and you know from another context that a CRL is available, is there harm in getting it? However, if the issuer is issuing CRLs but isn't populating CDP, this sounds more like a misconfiguration or a contrived thought experiment than a real use case. I can't think of a reason why you'd produce CRLs but not publish their locations for relying parties (but I'm sure someone on the list will educate me :). So rephrasing the question, do nonexistence of CDP, means dont use CRLs; and same question goes for AIA. I don't think anything stops you from trying. Absence of AIA doesn't mean OCSP isn't allowed; it simply means an out-of-band method is needed to communicate the location. -- T _______________________________________________ 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 ------=_NextPart_001_00AA_01CDEE88.FAC3C7B0 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

Unfortunately I don't know any = French. But I think it is given how to use CDP and AIA extensions specifically, = based on RFC. We have similar guides covered by regulations in = Turkey.

 

Thanks.

=

Ferda Topcan

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Wednesday, January = 09, 2013 4:30 PM
To: Ferda Topcan
Cc: pkix@ietf.org
Subject: Re: [pkix] Lack = of AIA and/or CDP Extensions

 

Ferda,

RFC 5280 is a base standard. There are other standards built upon = them.

In France, thiis is the case for PKIs used by the Administration.

Here is an example extracted from such a document (if you can read = French) :



Denis

Hi Denis,

 

Nice to see an answer from you. =

 

Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these = policies in practice as Liaquat said. So, I think it would be better if standards put rules = about how to reach revocation info.  Verifier has only signer's = certificate in hand to validate the signature. I think signer's certificate SHOULD = contain CDP or AIA extension or both.

 

E-signature standards are more = applicable than the policies in terms of = interoperability.

 

Thanks for your response. =

 

Ferda = Topcan

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Denis Pinkas
Sent: Wednesday, January = 09, 2013 3:20 PM
To: pkix@ietf.org
Subject: Re: [pkix] Lack = of AIA and/or CDP Extensions

 

Hi = Liaquat,

It has been a long time since we exchanged emails. :-)

You said: "it's better to use the approach recommended by the = CA". I do think this is the right answer.

A Relying Party will apply a validation policy or a signature policy ( = if the goal is to verifying an electronic signature).

The RP will select the validation or signature policy which is adequate = for the context.
The rules that are applied are defined in that policy.

Theses rules may say at the first level : use CRLs, or use OCSP = responses or use any of them.

At the second level, they may enforce freshness conditions such as : =
if you retrieve a CRL from the local cache, it MUST not be older than = two hours.

In this way, the nextUpdate date that is included in CRLs is not = relevant: the CA does not dictate the validation rules.
 
Denis

Thanks for your response to my question. As I =
understand from =
the
discussions this issue is not considered in =
standards. And I think it is =
a
missing part of revocation =
issue.
 
Best =
Regards.
Ferda =
TOPCAN
 
 
-----Original =
Message-----
From: Liaquat Khan [mailto:liaquat.khan@ascertia.com]=

Sent: Wednesday, January 09, 2013 1:35 =
PM
To: Ferda Topcan; 'Miller, =
Timothy J.'; pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP =
Extensions
 
I think it's also worth looking at it from a =
legal point of view. If =
the
CA is wanting you to use a particular =
approach (OCSP or CRL) as defined =
in
its CP then if you as a Relying Party want to =
show that you have =
fulfilled
your obligations it's better to use the =
approach recommended by the =
CA.
 
Of course in normal case this is not easy as =
end-users do not =
generally
read the CP document, or have the expertise =
to configure their settings =
in
the RP application - so generally it will be =
what's contained in the =
cert
and local default settings in the RP =
application.
 
Regards<=
/pre>
LK
=

 
 
On 09/01/2013 08:58, "Ferda Topcan" <ferda.topcan@tubitak.gov.tr> =
wrote:
 


Hello =
Timothy,
 
I would like to explain my opinion about this =
topic: A CA can =
produce
different types of certificates from the same =
Issuer. And the method =
of
obtaining revocation information for each =
type of certificate may =
be
different. For example a subCA can produce =
QES and OCSP Certificates. =
The
subCA may choose to publish revocation info =
from OCSP for QES but CRL =
for
OCSP Certificate for some reason. In this =
case how the verifier knows =
how
to check the revocation info unless its is =
specified in =
related



cerficate?



 
If you would answer this question I'd =
appreciate it.
 
Thanks in =
advance,
Best =
Regards.
 
Ferda =
TOPCAN
Chief =
Researcher
..............................................=
..................
 
<http://www.tubitak.gov.tr/>
 
Disclaimer <http://www.tubitak.gov.tr/disclaimer>
-----Original =
Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf =
Of
Miller, Timothy =
J.
Sent: Tuesday, January 08, 2013 8:41 =
PM
To: Ahmet YETG=DDN ( B=DDLGEM-UEKAE); pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP =
Extensions
 
On 1/8/13 2:46 AM, "Ahmet YETG=DDN =
(B=DDLGEM-UEKAE)"
<ahmet.yetgin@tubitak.gov.tr> =
wrote:
 


We have an disagreement between our testing =
group about meaning =
of
missing =
extensions.
 
For example when validation a QES, if a =
certificate has an =
AIA






extension,






but not CDP extension, and CA =
is
publishing both CRL and COSP =
responses,
 
1. Can I use CRL for revocation checking as a =
first choice?
2. If I cant, can I use CRL if I cant reach =
OCSP for any =
technical
error/reason.
 
(Problem here is I need to know that CRL =
publishing address, and in =
our
example I have it from =
elsewhere,



>from another certificates OCSPs =
extensions in the same path. =
Weird



example, =
yes.)



 
I guess my counter-question is "Why =
wouldn't you?"  If OCSP is =
not
reachable, and you know from another context =
that a CRL is available, =
is
there harm in getting =
it?
 
 
 
However, if the issuer is issuing CRLs but =
isn't populating CDP, =
this
sounds more like a misconfiguration or a =
contrived thought =
experiment



than


a real use case.  I can't think of a =
reason why you'd produce CRLs =
but



not


publish their locations for relying parties =
(but I'm sure someone on =
the
list will educate me =
:).
 


So rephrasing the question, do nonexistence =
of CDP, means dont use =
CRLs;
and same question goes for =
AIA.



 
I don't think anything stops you from =
trying.  Absence of AIA =
doesn't



mean


OCSP isn't allowed; it simply means an =
out-of-band method is needed =
to
communicate the =
location.
 
-- =
T
 
______________________________________________=
_
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

 

 

------=_NextPart_001_00AA_01CDEE88.FAC3C7B0-- ------=_NextPart_000_00A9_01CDEE88.FAC3C7B0 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAF6A7ADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0PWbS a88Y6THBqNzYMNPvGMlusZYjzLbj94jDHPpnjrVn+wtR/wChs1f/AL9Wn/xii6/5HjS/+wbef+jL WtqgDF/sLUf+hs1f/v1af/GKP7C1H/obNX/79Wn/AMYraooAxf7C1H/obNX/AO/Vp/8AGKP7C1H/ AKGzV/8Av1af/GK2qKAMX+wtR/6GzV/+/Vp/8Yo/sLUf+hs1f/v1af8AxitqigDF/sLUf+hs1f8A 79Wn/wAYo/sLUf8AobNX/wC/Vp/8YraooAxf7C1H/obNX/79Wn/xij+wtR/6GzV/+/Vp/wDGK2qK AMX+wtR/6GzV/wDv1af/ABij+wtR/wChs1f/AL9Wn/xitqigDF/sLUf+hs1f/v1af/GKP7C1H/ob NX/79Wn/AMYraooAxf7C1H/obNX/AO/Vp/8AGKP7C1H/AKGzV/8Av1af/GK2qKAMX+wtR/6GzV/+ /Vp/8Yo/sLUf+hs1f/v1af8AxitqigDF/sLUf+hs1f8A79Wn/wAYo/sLUf8AobNX/wC/Vp/8Yrao oA4/w1o1/JpczJ4n1SIDUL1dqR2uCRcygnmE8kjJ7ZJwAMCtb+wtR/6GzV/+/Vp/8Yo8Kf8AIIn/ AOwlf/8ApXLW1QBi/wBhaj/0Nmr/APfq0/8AjFZPiXRr+PS4WfxPqkoOoWS7XjtcAm5iAPEI5BOR 2yBkEZFdhWL4r/5BEH/YSsP/AErioAP7C1H/AKGzV/8Av1af/GKP7C1H/obNX/79Wn/xitqigDF/ sLUf+hs1f/v1af8Axism20a/PjHUox4n1QMun2jGQR2u5gZLjAP7nGBg4wM/Mck8Y7CsW1/5HjVP +wbZ/wDoy6oAP7C1H/obNX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAYraooAxf7C1H/AKGzV/8Av1af /GKP7C1H/obNX/79Wn/xitqigDF/sLUf+hs1f/v1af8Axij+wtR/6GzV/wDv1af/ABitqigDF/sL Uf8AobNX/wC/Vp/8Yo/sLUf+hs1f/v1af/GK2qKAMX+wtR/6GzV/+/Vp/wDGKP7C1H/obNX/AO/V p/8AGK2qKAMX+wtR/wChs1f/AL9Wn/xij+wtR/6GzV/+/Vp/8YraooAxf7C1H/obNX/79Wn/AMYo /sLUf+hs1f8A79Wn/wAYraooAxf7C1H/AKGzV/8Av1af/GKP7C1H/obNX/79Wn/xitqigDF/sLUf +hs1f/v1af8Axij+wtR/6GzV/wDv1af/ABitqigDF/sLUf8AobNX/wC/Vp/8Yo/sLUf+hs1f/v1a f/GK2qKAMX+wtR/6GzV/+/Vp/wDGKP7C1H/obNX/AO/Vp/8AGK2qKAMX+wtR/wChs1f/AL9Wn/xi j+wtR/6GzV/+/Vp/8YraooAxf7C1H/obNX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAYraooAxf7C1H/ AKGzV/8Av1af/GKP7C1H/obNX/79Wn/xitqigDF/sLUf+hs1f/v1af8Axij+wtR/6GzV/wDv1af/ ABitqigDF/sLUf8AobNX/wC/Vp/8Yo/sLUf+hs1f/v1af/GK2qKAMX+wtR/6GzV/+/Vp/wDGKP7C 1H/obNX/AO/Vp/8AGK2qKAMX+wtR/wChs1f/AL9Wn/xij+wtR/6GzV/+/Vp/8YraooAxf7C1H/ob NX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAYraooAxf7C1H/AKGzV/8Av1af/GKP7C1H/obNX/79Wn/x itqigDF/sLUf+hs1f/v1af8Axij+wtR/6GzV/wDv1af/ABitqigDF/sLUf8AobNX/wC/Vp/8Yo/s LUf+hs1f/v1af/GK2qKAMX+wtR/6GzV/+/Vp/wDGKP7C1H/obNX/AO/Vp/8AGK2qKAMX+wtR/wCh s1f/AL9Wn/xij+wtR/6GzV/+/Vp/8YraooAxf7C1H/obNX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAY raooAxf7C1H/AKGzV/8Av1af/GKP7C1H/obNX/79Wn/xitqigDF/sLUf+hs1f/v1af8Axij+wtR/ 6GzV/wDv1af/ABitqigDF/sLUf8AobNX/wC/Vp/8Yo/sLUf+hs1f/v1af/GK2qKAMX+wtR/6GzV/ +/Vp/wDGKP7C1H/obNX/AO/Vp/8AGK2qKAMX+wtR/wChs1f/AL9Wn/xij+wtR/6GzV/+/Vp/8Yra ooAxf7C1H/obNX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAYraooAxf7C1H/AKGzV/8Av1af/GKP7C1H /obNX/79Wn/xitqigDF/sLUf+hs1f/v1af8Axij+wtR/6GzV/wDv1af/ABitqigDF/sLUf8AobNX /wC/Vp/8Yo/sLUf+hs1f/v1af/GK2qKAMX+wtR/6GzV/+/Vp/wDGKP7C1H/obNX/AO/Vp/8AGK2q KAMX+wtR/wChs1f/AL9Wn/xij+wtR/6GzV/+/Vp/8YraooAxf7C1H/obNX/79Wn/AMYo/sLUf+hs 1f8A79Wn/wAYraooAxf7C1H/AKGzV/8Av1af/GKP7C1H/obNX/79Wn/xitqigDF/sLUf+hs1f/v1 af8Axij+wtR/6GzV/wDv1af/ABitqigDF/sLUf8AobNX/wC/Vp/8Yo/sLUf+hs1f/v1af/GK2qKA MX+wtR/6GzV/+/Vp/wDGKP7C1H/obNX/AO/Vp/8AGK2qKAMX+wtR/wChs1f/AL9Wn/xij+wtR/6G zV/+/Vp/8YraooAxf7C1H/obNX/79Wn/AMYo/sLUf+hs1f8A79Wn/wAYraooAxf7C1H/AKGzV/8A v1af/GKyfFmjX8Xg7WpH8T6pMqafOxjeO1CuBG3B2wg4PsQfeuwrF8Z/8iPr3/YNuP8A0W1ABdf8 jxpf/YNvP/RlrVfWvEOq6f4h0/SLHSLa8+3q7JLJetFs2DLFgI2wORggnk9BVi6/5HjS/wDsG3n/ AKMtaxkS+1jx/qd3YXEEB0m2js43uIGmTe/7yTgOvONo60Lf+v63DobFhr80mtnRNTs47S+MH2iM Qz+dHJHnacMVUgg44KjrxmtuuP1lW8K2t14jnkGpa1cLHZwMyeXGpZgFRVGSq7juOSSfWoteW+0M 6LPFqd3c6td30UEimZvKmU8yDys7FAGTkDIwOaa1t939fhcHpf8Ar+utjq7m++z3trbfZbmX7SWH mxR7kiwM5c9s9B71arldPDXXjzWpEubsWdnbxwvGbqQxmZxuYhS2FIXb90Dqawre6vJPhzf3yXl+ guppVsC11KZWLybIsOzF8D5cDPPPaktg6noU9xFbRiSZwilgoJ7knAH1JNS1x2saTFrHizRNOuJr p/sVs9zO8V1JFyMIh+Rhgkljkc/LjpW9r+sReHtCuNRkRpBAoCRg8uxICrn3JAzR0uC1ZJrl1PY6 Ld3dvPBBJbxNLvniMiAKMnIDKeg9aXRLi8u9EsrnUEjS7mgWSVIlIVWIzgAknj61yHiSyu203TrO +1Gd9U1i5jt5oo5W8nyid0qiPO3AUEbsbvfmrTa42t6vqWn20WovaacwtxFYh4jNIAN2Z8qFC5Aw GB6k8Yprr/W3/DoH0/rf/hmdnRWZ4esr7T9Fgt9RuWuLldxZmkMhUFiQu48ttBA3Hk4zWnQwCiii kAUUUUAFFFFABRRRQAUUUUAYnhbP9jXG0An+0r/AJx/y9y1n23jV4fFX/CO67YRadcSorW00VyZo pic/LuKLhuOhHNaPhT/kET/9hK//APSuWs7WPDtl4nv9Z069BAaC3aKVfvROPMwyn1FHmHkaWt6r q2nXVnFY6Za3cd1IIg8t60JRsMeQI24wvXOfam+Kdx0a33ABv7RsMgHIB+1xVx+j+JNRTXdN8I+I 1b+1rO8DRXAU7buERyYfPY9M/wCOa7HxX/yCIP8AsJWH/pXFTtoD3LGu32o6bp0l3p+nwXxiVnkj luTCdoGflOxgT9cfWq/hjxPZ+KtIF9ZApKvyTW8hw0MndW4/XFXdY/5Al9/17Sf+gmuJ1/Rr/Qjb eM/DcRe5jt0Go2a9LuIAZOP7w9ev8jKe9/63G1tbz/Q6nRdV1bUL28gvtLtLSO0k8ovFetMXbarc Axrxhuuc57UWxC+NtVJOANMs8/8Afy6ql4H1q08RWuo6rYljBcXmVDLggiKMEH6EEVcgKjxrqxb7 v9mWefp5l1VS0XyJTuQ2fiO/1K0/tPT9HW400hjG4ugJ5QCRlY9u3BxxlwfYVPe65eReGYtYsNJa 8keNJTbGdYiqEZYlm4yB271zDeH9f8Kq2peC72O90qT9+dIuj8uDyfKftnsDxz3rrPD+q2niTw9Z 6lBBsguEDCJ1HyEHBH4EUW0H1J5ZdQnSxlsUgSOR1a5W5DB1jKk4XH8WcdeOtZcev6gfHz+H5ra2 S1+wm6jlR2aRvmCjOQAv8XHPbms7xxCq694VuQ8odtUSIgStsK7WPKZ25yBzjNPb/ksSf9gM/wDo 6iOr+/8AK4PZ+i/Ox2FFc/431K50vw1JPakCR54YSzSFAqvIqsdwBK8E8gHHWsuz0DWLHxNbanb2 ekaPZlHjvYrW7eT7SSPlYgxICwPc8nJpAdpVaz1C11DzzayrKIJTC7KcjcAMj8M4rhdHlXTdVsdM 1/Smtb2eUhNVgw8GpnaQPMYc7iDkBs9OKu/DnSdNto9WuoNPtYp01S6hWVIVVljD8ICBnb7dKaWv y/y/zB6f16/5HbUVxXju2Rta8Lzb5gz6mkTBZnCldrH7oOM5A5xn3qO/0uDTvHENjp8LW1lq1hcN ew2zmJSyFcSDaRtb5sEjBOeanpf1/BXDrb0/F2O5orzjQFi074W2/iZYDPqdlYTtDMzEsMk5B9Rw Dz9as69p1vYeB08SaYoTV7aCK4F6pzJP90srsOXVgSMHI6VTVm12Ba28zvqK4O00+1u/ifqEN3C0 0M+kRyyW9xI0qbmcgjaxIxwOOnHSs19QutBtda0e2aVLCPWbe0gcOR9nilCl1VuqgA4HpuFCV7L+ t7Cv/XyuenUVxmvWEPhzWNEv9DtVtWutQW2u4oF2rcI4OWcDgsCM7jz15rPjuP7H1dI9e011N1fA 2+vWpDrODJuSOUjlRyFwcr6ULX+vT/Mb0/r1/wAjtNXl1KOzVdJjhe6kkVVM4JjRc/MzAEHgZ4yM nFXhnaNxBPcgYrzoWupeL4dYJ0zS7maO8mt4Li4vnjmsyh2qUURNsPAbIYZzXb6LHex6JaQ6pNFc XkcQSeSI7ldxwTyB6elJbXB72L9Fee+HdK0/yPG2nfYoPsYvnAt/LGwfu1IwOg559qy7O2R/CXw/ m8yZWa7iiISZ1UqQx+6DjOQOcZ460LW3y/EHpf5/gerUVyFjBFpvxPubSyjWC3udLW4lijG1WkEh XfgfxEHk9TV/xhbX9zpsAsLaC+Mc4eXT5nCreRhTmPJ47g88cc0dE/63sHVr+trnQUV51L4hhHh+ 4Gk2txYTvqUFrc2N2xh+yhtq7Qw3bEYDgqON2QK0LPwzqcHiH7QLLTNJ0y6t3hvLawvpczueVcYj TDjnJByR3o/r8Lh/X4na0VwPgfw5pOs+DrOXU7RbySOW5VWnJYgNIwIOev455561BommWFv4Z1Hw VJZwGZL42xBjGZUf50lORywQHn1SnbWwHdv/AGh/akWz7N/Z/lN5m7d5vmZG3HbbjOe/SrVcP/Z1 tpfxS0yGyRooTpUuIRIxjXayAbVJwvA7AUug6dY+NPD8t/qan+0Gup0+0Rtie0KyEKsbYymAF4HX vnNC2X9dbB/X4XO3orhboXPiDxFq2mvpWm6rbWSQrGl/dtHtDJu3qoicEkk/NweOK3/CVlqmm+H4 bHWLqK5urdmTzIpWk+XOVBZgCSAQORSQM2JDIInMSq0gU7VZtoJ7ZODgfgaxvCWt3eu6XPc3sEMM 0N3LblIWLL8jbep5PT0H0rOsVtvEvijXItUtkuI9LmjhtoZRuWPKBjIAejEn73UAcd65zTb2603w qttaASfavEc1s5mnMYZTI3DOASMkAZAPWhfn+rX+YPb0/wAn/keoVS1fV7PQ9Okv76QpCmBgDLMx 4CqO5J4ArndD0HVdL8UNeJaaXpWmXEBjlsrO5dw8oORIFMSAHGQcdao/EsOuoeFZpTixj1eMzk/d B/hJ/Wi2qXf/ADDv5f5HRx6nrjp9pbQEW32bhF9sH2np02bdmf8AtpWbqPjDUbW00m7ttEhkh1SW OBVuLxoZIZGzwyiNuBjkgnntXWVxvj5WNvoK2TwxSHWodjMm9Fb5uSoIzz1GRR1XqvzDo/R/kX/+ EoubDXLLStd02KzfUCVtZ7a5M8TsBkqSUQqfTgj3qPW/E2r6X4j0/SLfRbW6GpFxbzPftHjYoZt6 +Uce2Cay7GKe++IAg8UzB77T1M2lLBGYreVCAGcAkkuOhBY46j1q34m/5KF4Q/3rr/0VTXTzDudd GXMamVVVyBuVW3AHvg4GfyFOprOqDLsFGQMk45PArl/iXAsvgLVJC8qtDCXQxysnPTnaRuHPQ5FS 3bUcVd2OqorhPENhHpdroOtaZD5Wo/a7aGSSP708b4Vkc/xDByM9McVa0a3svFs+ty6xaJcPa6i9 tCkoyYFQAKU/uE5Lbhg89elVbfyv+n+ZKeiff/g/5HY0V5LcmS90Pw7PqCefeWHiQWUV3IMyPGsj D73U9Bn1IrornT7QfF5NkIia70aXz3iJRnO9RksuDnHGevAoSv8Aj+Vx7f152O4orh/AGj2Vxo6X VxG809lqV19nlkkZmj+dl65yePXOa0fH3hu38QeHZWNnFPeWY8623oCSVIYp9GAwRSemoLV2Onqh fSan9vsobFIRCzFrqWZSdqAcBcEfMSe+QADxXPj+yfER03VrfT7eZNOsftcOYhlGYfIg9MbWOOxC msC00vXvEfhrT9YsbTR4dUcJcLqzX8hlzncysPJ+71XZuIHTtTtrr/X9WFuj06qsX9of2nP5v2b7 BsXyNm7zd/O7d2x0xj3rjrbRrLUfHuvWN6r3NrcafA8kTzu6lmZ8lSTlRxxjAHapdEsYIPiP4htA JJIHsYCY55WlHzF8j5yePbpSQ+/y/T/Mvza7rGoS6mPD0NpM2l3HkPBcAg3LbVYhXDAJjdjkNkjt W5pZ1I6dEdWW2W8OfMFqWMY54A3c9MVxHgvw/pD3nikLp1vE0epSwRyQIInijKL8qOuGUcnoRVDQ tRvLT4a6FHb4ka+1JreQzTtGGBlkOGkAYjcQBnBPNNbL5fiNrfyv+B6jRXEWfhnUbbWbmVrTTtK0 m8tGinstPvZPnlHIkXEce04yDjkipPh1pdpN4T0XVZozJfRwyKs7MdwDMcj3HA6/Whf1+P8AkJml 4v13UNAt7KeztraWKe7iglaZ2DJvYAbVA579SMcda6GuR+JH/ICsf+wra/8AowVBqZu9a8XajpL6 Vp2pW1rbQstvf3LRqN+4lwojcMcgDJxjHHWktvm/yQPf5fqztaKwvB+n6rpWifYdXuIJpYZXEflT NLsiJyqlmUEkA46dMVheJnl07W7nUtQ0d9V0zylVbq0Ia4004wxC/eAIO7cpz69qHoC1OxbULVdS j04yr9qkiaURg8hAQCT+JFWa8/h0zRdR+I+nT/Y7S8il0QTpK8CnewdQr8j72O/UVneLFtv7A13V bJDqF7aXRddVcCM2pDqPKibljtHBxhTk5Oc07bfP87AtdvL8Vc9Ik1C1i1CCwaVftM6s6R552r1P 05A/GrNcLqWlaZqPxJ0Z7zTbS4M2mTPJ5sCvuYFNpORyRk49KZ4Z0vTxrvjbThZQCzaeIG38seXz Fk/L0680nor+T/B2Fe7+78Vc7S+1C106KOS6lWMSSrEgJ5Z2OAB+JqzXkFpYWV18MfCH2m0gmxqk Uf7yMN8jTNuXnse4716zDb29jaLBa28cMMS4SKJAqqPQAcCm1ZPyf+X+Y+39dWU/EN/d6VoN5qFl BDPLbRNLsmkKKVUZPIB5wOB+oqXRr2TUdEsb6ZVWS5t45XCDgFlBOPbmuHghtvEPw31DxHeQh9Ru Le6cTnl4QNwCKf4VAUAgcHnOcmnw3F3djw5osdjZ3tvJoona3vLgxRysAi84R92AT8pGOc9qEt11 0/J/5A+j9f0/zPQqK5rwhpOqaN9vtr77JFavMJbO1trh5RbIRymWRflyMgAYHNUddsopPiVoG9pW W4t7kSxmVijBVGPlJwPvHoBnPNLql/Wwdzq7+W4gsJ5LSETXCofKjPRn7A+2aWyF2LKEXzQtdbB5 phUqm7vgEk4/GuH+wtceIL/w7baNpt7p2m20KwWd9eOioGyxcL5cm7njJwRt461V1PwdeP4GYavD Z6hqOjzm4tQrmYmFWD+SzMoJyuRgjnijTfoFtbHpNFclMdL1e5h8QW9lDcrpmn+fbv5QJ3Ou5FBx kYUZx/tisv8As+31H4bL4kUBda+wG7XUEP75ZAC+N/XbnI29McYoel2+n/B/yBe9a3X+v1PQaK4j Tr5fE/iCPTtbtY3i/seC6FnMuUd3J3sUPBxhQM5x+NWtV0zTdH0e00z7dcm2a+XbZ/61rgHJFuBk YT68ADnim01p/W9hJ3V/62udW7rGjO7BVUZLE4AFUGvZtS0M3mhSW8ks0Za2e43eU3oTt5x9K43R 7eIaz4t0aTTYLawW1hlSwGHijLI2flxtBJAJA4yKz5NI0+H4Fi7t7ZbadtPSZ5LYmJpXxjLlcb+p 4bIpdG/T8b/5FJe8l/XT/M9RTdsXfjfj5tvTPtTq4+e4W+8S6LoF3GHsZNMe4eN/uTMNqhSOjAAs cHjkHtWZqVmNO1bXdDtRNDpUmj/bY4oJXjW3lUkYTaRtBwDtHHB460S019fwv/kKKvb5fjb/ADPQ 6K82ntobPwX4R1WBAt8k1kguP49j4DJnrtIPTpXda5fvpehX+oRp5j2tvJKq+pVSRTmuW/k2vuCP vNW6lDxlrd/4e0CTUrC3t5zE6iQTuw2hiFBAA+Y5I4yPrW6pyoPqK808RaXZv8LF1coH1C5ht5Zr s8ySlnQkM3dcnheg4xjFasVnbQ/GJnit40a40QtMVUDzD5oGT6nAA/Cnaz5X3f4K4r3XMv61X+Z2 9FcX8O7WCyufE9tawpDDHrEgSNFwqjavAHYV2lT0Xy/EfVoKKKKACsXxn/yI+vf9g24/9FtW1WL4 z/5EfXv+wbcf+i2oAj1GN5vGGnRpPJAzaXegSxhSyHzLbkbgRn6g0/w94Zj8OtdmLU768F3KZpRd GM/vD1bKop7DjOPaluv+R40v/sG3n/oy1raoApatpNrrVg1leKxjZlcMjbWRlOVYHsQQDVez8P29 vfJqF1cXGoX0aGOO4uiu5FPUKqKqrnuQMnHJrVpKNgMe38NWtrFqaR3N1nUpJJJGLjMbOADt47AD Gc4qS48O2Vxpun6eTKkGnyRPEEIGTGPlB46fTFGi6/HrM99AtjdWkthKIZVuNnLFQ3BRmB4I/On6 prKaVcWUUlncTC8nECyRGPCMemQzA+p+UHgGjt8v+AD6/P8A4IseiW8Wtzasss3mzQxxNGWGzCFi p6Zz8x749qdrejWmv6VNpt5vEUuDujOGRgQQwPqCAatC6tzdG0E8RuAm8w7xvC5xnHXGe9S0AZD+ HLWa8sL24uLme5sSSsrsoMhK7fmAAHQnoB1PqaZF4ZgttVur60v722S8bfcWsTr5Uj4wW5UspPHK sOlbVFAEcMMVvCsMKBI0GFVRwKkqKa6t7Zo1nniiMz7Iw7hd7egz1PtUtABRRRQAUUVlanrqaXqV hZSWF1L9vl8mOaLyyitgnDAsG6AnIBFAGrRRRQAUUUUAFFFFAGL4U/5BE/8A2Er/AP8ASuWnWegS WmtT6oda1CdpwA8Eoh8sgZ2j5YwRjce+fXNN8Kf8gif/ALCV/wD+lctbVAGdfaHY6hqVhqM0Q+1a e5aGUdQCCCp9jn9KreK/+QRB/wBhKw/9K4q2qxfFf/IIg/7CVh/6VxUAXdW09tV0+SzF7cWaygq8 lvs3lSMEfOrAZ+mfenabYtp1hHaPeXF55YwJLgJvx2B2Ko/TNW6KAM/SNEstEW6Swj8qO5uGnaMf dViADj0HGfxqpbqH8a6sp6NplmP/ACJdVt1i2v8AyPGqf9g2z/8ARl1RvoA2LwvHa2cVjZatqdrZ xrt+zpMrhh6b3VnX/gLDHbFatnZ2+n2cNnaRLFBAgSNF6KBU9FFwMPXvDEev3VjcS6nfWhsJRNCt t5WBIM4Y70bJwcY6e1J/wiyf8JUPER1W/NyIfI8o+V5Xl5ztx5eevOc598Vu0hZQQCQC3ABPWhaA 9SvqGn2mq6fNYX0KzW06FJI26EVjaH4Ms9CkZo9S1W8UArFFeXjSxwA8YReAOOMnJx3rYivvN1Oe y+yXKeSiv57x4ifdnhWzyRjn0yKztU8VWel/aHa2u7mGzYLeTWyK4tiQD8wyGPBB+UNjvQMW38MW sD2ga8vJ7exKtbW00gZI2AIDZxuY8/xMQOwFT6XoNtpFzeS2s0/l3c7TtAzAojt94rxnnryT7Yqx peoDVNOivVtbm1WXJEV1H5cgGccr2z1q3T1uTucD8SNQ02PU/DVrdalFbSLqaSv+/CPGm1hvPPAz 3PFdLF4eQJPMdVvZry4iEX25jEZETOcKAmwDn+7z36Ctmk3KWK5G4DJGeQKXSw+tzI0Dw3b+H9GG kR3dze2igqiXflttU5yvyquQcnrmorPwlZ2cSWgu7yXTomDxWErq0UZByMHbvIB6AsR7Vu1lyeIL OPxFDoTJcfapomlVjCRGVXGcOeD1HTPXmnfUOhxxurDUvi7eQWuvfZZxpqQo9rNGWMgkYsm1gysQ OoIJHtXXnw1pb6LPpM8Jnt7os05lYl5GJyWLeucYI6YGMYqay13TNQ1O8021u1ku7EgXEWCCmenU c/UZqfUNRs9KsZb6/uEt7aIZeR+g5x/M0vspf1vcPtN/12KVloEdtLDLc313qDWxP2c3bIfJyMcb VXJxxlsnk881EPCtriOF7y9ls45BKLOSRWjMgbcGJ27vvc7d232raBDKGUggjII71n32vabp8/2a ad3uNob7PbwvPKF9SkYLAe+MUX1DoZWpeBNNv9ZbVYb7U9MuJSDcDT7swLcY6bwOv1GDXRQQx28C QxLtRAFUZzxVWz1nTr+4NtbXKtcKgkeBlKyRqem5CAV+hAq9RsrB1MX/AIRi1XUb+7iu7uFdRH+k 28bqI3bG3f8Ad3A4AHBAOOQazP8AhXdgljp1nbavq1vDpsomgCzo+JAMBvnRscZ+UYXk8V1tFC0D cwk8LKnigeITq+oPceT5BiYxeUY8524EeevOc598VoahpkWo+QzzTwyW7mSKSF9pVtpXPoeCeCCP UVdoo6WAxW8KaZcade2eoCTUP7Qx9qluCN8hAAX7oAXGBjaBjrVbSfBsGjxSrDrWszuylYpLq784 2wPH7tWBUfUqa6OigDH8N+HIvDGnmwt9QvLqDcWRboxkoSSTgqinknPOan/sKw/4SE675Z+2m3+z ls8bc56evbPpWjRRfW4GHceF0uPFEPiA6rfpPDH5SQr5XlBDglcFM4JHXOfQiqkvgHS21qXU7e81 OxNw/mXFtZ3jQwzt/eZV5z9CK6WSRYo2kc4VAWJ9AKq6VqA1XTYb5bW4tlmXcsdwoV8diQCcZ6+t C/IGZGt+CNM1q8hvkub7TLyGMRC50648l2jH8BODkVt2NlFp9oltCZGVB96WQu7HuWY8k+5pbu7g srcz3D7UBAGASWJ6AAcknsBVe91VbCK1lmtLjZcSrEzKqnyS3AL88DOBkZ60eQFe48O28usHVra6 urG6dVSc27LtnUdA6spHGeowfeqUXgPQ49Kv9MkS4uLa/lM0yzXDNhySdy84U5PUcnAzmukrJi8S WU3iaTw+sdyLuOAzszwlYyoIHDHG7k9RkcHmjy/ruHmQ+H/C0Hh/cV1PVNRcjCvqF2ZvLX0UcAfl mtPUNOs9VsZbG/t0uLaYYeNxwagstd0zUNTvNNtbtZLuxIFxFggpnp1HP1Ga0KHqC0ehjWfh+SyI jTXNUktVG1baSSNgB6b9nmf+P1DrvhOLXXsy+q39nHZSLLDFa+UFWRc4b5kYk89M49q36KAMXWfD FrrtnaRXV3dpc2biSG+hZUnRh1IIXbz3GMe1UbnwS15qNlqE/ibWXubDd9nfFsNm4YbgQ4OR65rq KKAMaLw/P9sguLvX9TvVt33rBMIFjLYwCwjjUnHUZPWsv4n3traeAdUjubmKJ7iExxK7gGRuOFHc /SutpGZVGWIGTjk96T1Vhp2dzntC0qzvLXT9SGqz6nDEitaq8qPFE23aSpVQWPUZYsRVmbw1AdVl 1KzvbvT5rnb9pFsybbjHTcGVsHHGVwfer732zVIrD7Jct5kTSfaFj/dLggbS2eGOeB7GrVU3d3JS srGRfeGdOvdGi0oCS3igdZIHhbDxOpyHBOcnPPOc5Oc1Xn8I2txqsOrSajqP2+GAwLcJMFOOuSoX aecHBG3j7tb9FIZjeHPDcfhq3lt4NSvbuKWRpNt0YztZiSxBVFPJPfPtitmisoeIbM+JP7A8u5F3 5Jm3NCyxlRjoxwG+8Ome9G+geY/RdCsNAtZrawjKRzTvOwY5+Zjkgew6AegrIh+H2lWuqNeWt7ql tbyOXfT4bxktXYnJJQevpnHtXU0UdbgYVr4XW18Sz66ur6g81woSSF/J8ooM7VwIwQBnjBz6k0lv 4VW28QXmtprGom4vE8uRD5JQKM7QB5eRtzxz9c1vUUAc3pfg7+yHvnttf1Utfu0sxk+zn94wxvH7 rg8dOntSWXgTSrXwxJ4cuJrq/wBPcllS5ZN0ZJ3ZVkVTnPOTmulooA53TPBsWl2k8MeuazPJKuxL i6uhM8C+iBlKj/vnNXPDnh+Pw1pSabb313dW8X+qFyUJjHXAKquRk981qllXGSBk4GT1NVvt3/E0 Fh9kuf8AU+b9o8v9z1xt3Z+93xjpRcCh4j8NReJYLeCfULy1jglWYLbGMbnU5UncjdD26euara34 KsNcltrqW91C01C3j8sX9lOIZ2XuCQMEE89Ppirep+I7fTXnRbS6vXtUWS5W1VWMKHOGILDP3Twu T7VPousRa5p4voLa6ghdiE+0xGNnUdHAPO09RmhAybTtPh0yzS2heaQLyZJ5TJI59WY8k1Tu/D8d zPcTR6he2v2sj7QkMi7ZAF24wynbwOq4b36VrUUPUFpsY58MWCahY3ts01o9lbm1RIWAV4uPkbIJ wCAQQQfeqc/gfTp9O1HTWu75bHUHaRrZJFCxOxyWQ7c8nnBJGe1dHuXdtyN2M4zziloDYx5vDdtN fWF79qukubFGjWRHGZEbG5WyOnAPy4IxxilPhy2XWLrUobq6ga8RVuYY3URzEDAY5G4EDjKke9a9 FD1A5qDwHpVr4fi0WC4vlihmSeGUz73ikU5DLuBUc9guOTxXRRp5cYTcz46sxyTT6KdwOfbwdZCO /t4Ly9trLUA/nWcUi+UGb7zLlSyk+gO32qG78A6Nd6PZadvvYTp+fsl1FdN58Gf7rnOBjjHTgcVu LfbtUksPslyNkQl+0GP9y2SRtDZ5YYyR6EVapDv/AF6mfo2jQ6LZ+RHc3d25+/cXk7TSv9WP8hgV S1DwuuoeILTWjq+oQT2assMcXleWobAYYaMk5x3P0xW7RRfW4uljn/EHg3T/ABBdxXzXN9p99Eux bvT5/Jl2ZztJwcitXT9Oh06yW1iaWVR9555DI7nuWZuSat0UdLB5mdomhWPh/TvsFhGVgMjyYY55 Y5x9B0HsBVGDwfY20ctrDc3a6bKxZtN3L5GScnHy7wCf4Q232rfooAwfEHg/TvEMlvcSTXdjeWwK w3djN5UqKeq5wePwpZ/CNjNYWtut1fRzWk4uIrzz/MnEmMZLOG3ZBxggjFbgZSSAQSOoz0paNgMa 28MWdtrF3qgnuZJr2JIp1kkBV9oIBxjIOGPAOPaqc3gi0l8Lnw4NT1GOxI2fK8e4R5JEeSh4GeuN 3AyTXS0UB5mJceF7a6s7GOa8u2utP5tr8FFnTjHZQpGOCCuDjkGln8NQ3Gn3ls9/eCe+jEVxegx+ c6Djb9zaowTwFHUnrzWh9u/4mgsPslz/AKnzftHl/ueuNu7P3u+MdKtUPX5gtNuhy0/gSG40Ww0h td1YW2nurwlTAGymNmT5XO3HH65rpREDbiGVjMNu1i4GX4wcgADn6VJRQ3fcDmZPAunS6PNoz32o HTJCpS085dsIDZ2q23dj2LEDtjirknhi1a9sb2C8vbe5sojAJVlDtLGSCUcuG3DIznr71cOqJ/bX 9lJbzvIIfOeZVHlxgkgAknOTg4AB6Vep36/12DyMjR/DNjol7e3dpJdNJfSGSUSzsybj3C9M8Dnr 71r1VtdQgup57ddyTwHEkTjDAHo3uD2I9+4NWqQBRRRQAVi+M/8AkR9e/wCwbcf+i2rarF8Z/wDI j69/2Dbj/wBFtQAXX/I76X/2Db3/ANGWtZ2l6v4g1NtZjWTT1WxuWhhu2tXCPtALAp5mTgkjO4dO h6CzrV5Hp/ia0vZSBHb6RfyMT6B7Y1l+HtI8QXHhKHTbtbSxivEaW4uIZnadvNJdxsKgIfmIzubH pS3vb+v6sPa1x9p4z1DUND8P30FnBHLqtysLRuS2Rlt5XkYAVS2T7DFbC668nia+sF8n7Hp9ostx JzuWRiSF64ACrk/UVBN4dnj17SbixFtHYadaSQRxMSDEzbQGUAYb5QRyR171W/4RfUZNP8RWrXVv G+rSt5coBYiMoqANwMHAPTPLZ9qp9bef+X/BEvPy/wA/+AY1rquseH/Ar+JxHbbbidr24t51YySp I42hWBAQhSoAIbp2roLtv7U8baXbgfu9PtXvXB6h3/dx/p5lOOh3uqx2dtq0Vpa2Nm6utnaytKJi mNm52VMKCM7QOSBzjip7DSL621/V9SlkhIvDGINpJIREwFYEcfMWPB70Oy2/rSyFuvP/AIOv9eZm aXrojOva1q5sDBpsptlvLe1McjqgyynLsThjgDPUHjmr8N54luDZXgsrWK2nkAltHBM0UZyd7Sbg MgY+UK3JxnvWX/whd/ceAzoVzdwR3pkE7Sx7mR5vM8wluhIJ7Y4robePVbqzKaj9ntJGQqRaSmUE kYzuZVx64x+NLZen9fiPd+v9fgZc3iK+u7O+1LS1tl0/T9+ZZ1LG6KA7wmGG0AjG45yQeMc1S1q+ 1+78NaJDFdW1lqGryRxTAW7MAGXc+35wVwob1J7EdaRfCutf8IDH4a82yiaILEXjkbbPGHBbd8uV JXOQM8nrWxdaRfT+IdMvle3+zWcEqFTkFZG2gMq4IPyhhyRjPenZXt/Wn+YX6+v/AAPuKbXN7J4w sNFuf7Mu4YbQ3cpFmyvCwwqshMjYySccZAB5NPj13Utat7u70T7LBZ2rsiT3cbSfaSmd20Ky7VyM biT0PFT2Oi3sfiTV9SupIWivBHHDsJLrEqkbTkYHzMxyCazLHwtrNr4a/wCEWF1awaeoaP7bEzGe SJiSRsKhUbBxu3N64patef8AX5Bon5APGF3d2HhvUbVYIo9XcLLbSQs7/dJO1g6gdMDKnORWtp+q 6hceJ77TZ47cW9tbRSgxg7kdy3ykk4bhQcgDr3pkXhuOLXtOuUjhWx0qyaC0iBO5HYgE9P7qgA57 mptE0m6sL7Vbq6ljdr66Mq7CSQgVVQHIGMBenPU81Wl9PP8Ar9Ra218v8/8AgEmsayNOltbOCH7R f3rlbeHOBgcs7HsqjqfoOprDWW9ufHMUGqS2rx6PZNdNLChRd0hKrlSzY2qr855z0FaN7ot+3jG0 120eB40tHtZYpmKlAWDB1wDk8YIOPrVWPwjPKviSO8u1Ya18iypneqeWFGewwd3A7EVPS/XX/Jf5 laXt6f8AB/yILrxVqVxaW97pa2YFy6/ZLKZGee7jJA3jDDyxgk5IbAwTjpV241vUj4mudKtktUMF qJ4oZwwe8JznY+cKFIAPyt17UnhzRdR0nS4bBrbS7DyMAy2AJNwB3KlAEJ78t1PPemPoOrXk+krf TWx/syVZvt0bt50pAIKbCMKDnk7jn0HatL2ROtrnTLu2jdjdjnHTNLRRUjCiiigDF8Kf8gif/sJX /wD6Vy1tVi+FP+QRP/2Er/8A9K5a2qACsXxX/wAgiD/sJWH/AKVxVtVi+K/+QRB/2ErD/wBK4qAN qiiigArnzcx2XivW7qXPlwaTaSNj0El0TXQVgpBHc+MNYglUNHLpVojqe4Ml0DSd7aDVr6lawbX9 W07TdbtNTSP7UI5ZLGWJfJETckBgu/eFPXdgkdBmqOpeJbi8udThsbzUbSSwlMMItNKkukmcKCd7 CNhjJxgFSMZzzT9B8P8Ai7RAmjrq2nS6JANsMrwubtUzwnBCjA4Dc/Sn3Wg+J9N126vvDN/p32bU JBJc22oxuRG+AC6FMEkgDgkVTs3pt/wwlfruVU8Q+IbrUPC3mgacmqrIt1aSWpWWN0RiTlj0zggY HQcnNRz6fq6ePtIs7jxNfSMbG4kMkcUKDh1x8pQjkHBPXjjHStDVdF8R3Gu6JfW40+4TTDI8rTXE kTSs6lSFUIwUDPHJ9Per+paNezeKdN1qzeAi3glt5Y5mYYV9p3LgHJBXocZz1FPS6fr+oulvJfn/ AJFTTNR1a48a63o93fI1vBbRSW5hgCGPeW9d2SAByeOOlY/gux1EXvil4dbuDLHqUqDz4YnR22Lh 3CqpJHorKOOla9lpGvW3jXU9aeDTmtryBIY1W7feNmdpI8vHJPPPHvUPh3SPE2jz6zLcWulSf2jc vdII72T5GIACHMPTj736VK2+T/Mp/qvy/wAyvo3i6/fwFp+p3kkc2oX959lRvLwgZpigO0dgBnHf HXvW9Faa9ZX0sg1FdRs2gZhFcIiSrL/CFKKo2Hn72SPU1z2neB9SbwCPDmpT21tdW83nWt3aSNJt k3l1bDKuME4xzkd61LTTfF19p11a67qenxF4njifTYpA+SpAdmY9s5wB1xzTl1t/WgK1/L/g/wCR lx+IdTsda0KC61YXU2oy+RfWixRtFayeWW2o6LkEHjDMxI5qbw1b3r+OvEjSazeyR208KiFxEVdT HkA/JkAEnG0j3zQPCutPaeHIyNNgOiXCsyRO5WVQhXcDtGDznbg/71a2m6Lfad4o1W/Elu9pqXlS E5YSI6LtI24xg8HOePQ9ael/v/T/AIJOtv68ybxFrEmmrY2tsUW71G5W2hZxlUJBJYjvgA8euKwp ba7tPiVoUdzfyXo+xXRWWZEV+qZB2Kq46Y4/OtzxLoUmtQWktpOtvfWFwtzbSOpZNw4KsB2IJFUJ tF1++8TaRrUsunWhsopI5oULz7g5XO1iE7Drjg+tKO/3/l/mN7f13OiW0jW7e6OWlZQgJ/hXrgfj z/kVzPi660DUJm0HW9VsbSD7OZJEubhIyzNlUIDEZx8zfULXUzmZYHNuiSShTsWRyisewJAOB74P 0rN8P2+rQW9wdZis1uZZmkL2szSKwPT7yLjAAXv0zU2voO9tTG8A6+dR8E5aZLm60wPbSsjhhIY/ usCOoIwc1B8KHa98InWbg773UrmWW4lPViGKgfQAYA7VPZ6L4jsPHGoarbw6WNM1DYs8JuZPMJXg SD93jdjqufx71NYeHtU8MT3KeHzZ3GnXMxmFldyNF5DH72x1VvlJx8pXj1qr31fVf8P95NrKy6P+ vuOhNlAdQW+2ATrEYtwHVSQcH8R+prO1zVpLS+0zTLdglxqczIshXd5aqpZiB0J4AGfXPOMVftVu 2xLeGNH248mFiyqe/wAxA3fXA+lZXivw9c63BaXGnXi2epafP59rM67lzjBVh/dIODS2GiK7vNT8 K6Zquo6nfrqNjbQiS3aRFSctzlW2KqkZ24IAPPNVNa1HWPDelwa/PqRvIA8QvLRoUVFRyFLREAMC Cc/MzZ9qtpoms63od3YeK7ixY3MLReXp0bqiZ/iy5JLDAxwMc9ajGh6zqOkw6LrclnJaRNH5lzE7 GS5VCCAUKgJkgZIZu/TPDW/3f8EOn3kWn3mt6j4o17SZtWWOG1jhaCS2tlVkDhj/AB7gT0ySCDjg CoNL8W3t14f0hZmT+0dQvZLIzbPlBQvufb64Tp0yfSrNhpXiKy8V6zqxttMeC/jRYUF3IGUxghd3 7rHOecdPesy08D603heOwubmzs9Ssb5r2yuraRpVDMzMQwZV4+Yjvn9KSt+QP+vu/wAzcuJ9U8NW ep6jqGo/2lp9tbGaPzURJw4BypKKqlTxjjP1rHHiPVo9S0ya1OrahFdzLHeW0mjSxRW6sP8AWI5j U4BxnczZHpWvaaTr+q6VdWfiu509luIGhMWnRuq4YYLFnOScdMAY561X0TTPGllIljqOq6ZcabAA qTxxSLdSqOgbnavoSMnHvzTW+oPYr6TceJdXudbszrcFvNp1+kcUqWQKMu1WKlC2cHOOGz7iqtpq 3iG78Ja5qEmrql3pdzcLG0NsipIIuzBg3ynHY55+9Wr4c0rX9N1XWbq+t9O8vUZ/tCCC7kYowUKF OYxxx1/Q1nWXh3xPbeGtd0ySHSTNqc08sbrdybU83OQf3Wfl7evtUu9tO346f8EpWvr3/DX/AIBL ceLBqD2lhvvbUXGnR3c8llYPdON/RQAjgDhsllOe1aXg7VdT1Kyu49Ut7hZLW4aKK4ntXtzcx9Vf YwGD2OBjI7VkDwt4mtLbTNQ0u70+21iztFsp4pGeS2uYl6EnaGBHJ4HfGa6rSItUS0D6zPbS3j43 i1RliT2UMST9T19qt2u7f1rp+Bmr2V/601/Eyprr7b8RLfTm5isLBrraehkdtin6hQ3/AH1TNfn1 D7fNBNqX9l2HkD7O8SxSy3Uvzbk2OrEgAA4Ayc9alvbYaf43tNYb5Ybu1NjK56K+4NHn0z8w+pA7 0h0TU4fFt9qkElrNb31skOZ2bfbFc/cAGGU5yRleajXlXz/Uvq/l+n/BLHg7WZvEHhPT9UuAomnj /ebBgbgSDgdulZTf8liT/sBn/wBHVpeC9EvPDvhm20q9eB5LfcA0JJDAsTnkDsRxj8TVU6NrR+IY 17yrD7CLP7Jj7S/m43bt+3y8ZzxjP49qt257rbX8mSvha/rdG5cLb2X2nVJcs0cJJY4+VF5IH8/8 iuKfxbqz22n6tYDVrtp3jM+mjR5fJETHkpJ5QO5Qeu4g44HNd7NElxBJDIMpIpVh6gjBrktF0Lxh o5j0katps2iQjZFM8L/a1j7KMELkDjcc/Spjv/XzG9iPUtQ1jw/4nC32r3Nxpepo0ViBDCvk3J+6 jNs7/wAJPHHOa0J73UdDsdJ0261E32pajcCA3UkKqFO0sxCqAMAKQPqM5o1DRb/WodVh1WysJY5E KWAW5fKjsWPl/I24A7hu7Dtk0ZPDPiLVvDFnbarfWkGt6ZMs1rfWzNIrsoxlwyr1BIOM56+1C218 vu/zB7/1vY0bifVPDVnqeo6hqP8AaWn21sZo/NREnDgHKkoqqVPGOM/Wsf8A4SPV49S0yW1Oq6hH dyrHeW8mjSxRW6sP9YjmNTgHGdzNkela9ppOv6rpV1Z+K7nT2W4gaExadG6rhhgsWc5Jx0wBjnrV fQ9M8Z2UsdjqWq6ZcaZAAqTxwuLqVR0Dc7V9CRn8+aa31B7FbQ7nxDrUuv2c+uCCawvPJhltrRFH 3AeVfdxk8jOfcVjS6tqXiSPwncvqNzYTy6hLbXCWuzZ5kauC4Dq2eV4ByBnpnmtDw22rrr3isabF ZSK2qYY3EroYz5a/MMK27/d+X61ozeEJrWy0JNNlhebSrs3Ennkos5cMJDlQcHLEjg+lC6N+QPqv X9R39o6va/EGz0eW/SewmsJJgpgCyFlKjLMOCc5PyhRz0otL3VfEmmXOraXqptFjmlS1gEKPHIEJ X95kFjkqT8pXAPeludH12Xx3Z60ItPaztrVrZs3DrIwYgswXyyBjHA3c+op2m6FrGgG7sdLezl02 4meaIzuyvaF+SAoUiRd2SBlevWl9nz1/P/IfX7vy/wAzJtfFmraxd+Fri1uIba11cSrPb+RuZHjR t3zk9MjgYB46npW1oeo33/CUaxol5dNdpaJDNBM6KrhZA2VO0AHBXjj65rOm8KapY6h4dGjxWL2O ihyxuLh0kmZ1KscLGQOpPXkntV7S9J1y38balq91FYLZ3sUcSiK5dpFEe7BIMYBzu5GePeq0v95P T7v6+4ua/q8ljcadptq6x3epzmKORl3CNQpZmx3OBge5Fc/N5+lfEa2kvb17yODRriQTSqiyEB1J B2qq9uCAP6ne8SaFPqrWN7YzRw6hps/nW7SglGyMMjY5AIPUdKoz+H9Z1DxNZ6xcyWFvElm9rcW6 b5tyuQSFYhfTqR+BqVfp5/k7Fafl+f8AkZD+LdWe20/VrAatdtO8Zn00aPL5IiY8lJPKB3KD13EH HA5q/deJJR4ivtMl1X+zL2MhbC1uI1EN2pUEMGIyW3ZGAwxjkGl0XQvGGjmPSRq2mzaJCNkUzwv9 rWPsowQuQONxz9Ksa94d1LXLG70u5TT7m1uZGMU8xbzbMHoVGDvIOSOVx05p6X02/wCG/r+kTr1O nLBVLN0Aya5ayutb8R6NDrmk6mtsZXLQWksSmF4wxGHO0vuIGcqQAT0Pfp44hHAkRJcKoXLck8d6 4/SfDfirw/cvp2lanpp0JpGeMXMLtcW4Y5KIFIUgZOCT+FLqPoTar4iafVr7S4L3UbI2QQGWx017 otIy7sMRG6hQCOOCfUVnW/iXxPcf8I09yosGvrp7W6t5bNkdiqsd43nIUgAgbfxrS1Tw/wCI7PXJ NX8LX9kHuo0ju7bUVcxuVGFcFOd2OMdDTdX0XxNeX+i3UZ0y5bT5zczNJPJCHcqV2ooR9qgHqSTT j0uD20/r+mUdcsNWj8T+GbWbxJes009x+8iihTACMVO0oQSAduSMdwAa04dT1aP4jHRJ71JbE6ab iNVgCuG3hcs3OTwTwAOenFXNc0a9vtV0XU7NoPN06Z2eKZyqsroVOGAPI6jjn2qn/Y2uf8LBXXjH p7Wa2X2TH2hxIRu3F9vlkdeNu78aFur+f5f8MD2v6fn/AJGT4YsL4ePPFO3W7t3he3BMscJWUmI4 3gIOB6KV96m0rxdqUXhS/vtRliubyPVGsIWWLYmfMCKdoOcZOeufereiaR4l0/xLrGq3FppTR6oU bZHfSFotibQOYecnGemPeqmn+CdTn8MatourvaQG8u3vILizneRopGfeOGRfukDnPPPSjt6L9P8A gg9/n+j/AFsdHbWWt2uqrI+qi9sXRvNiniRXjft5ZRR8vs2T71zF74i1bSptMuLvUwbq5v47a70x I45IrdHYgfOq7lbGD8zEHnj029Gs/F5DRa/qOmmJAVjaxicSScYDOWOB64A645rH/wCEN1tvDOna QX08Ppt9HcCUSP8A6UFfcWb5fkY5OfvZPcUL4l8vz1Do/wCuhNpFvev8RtfJ1i9eO3jt2WAiLa4Y Odh+TIAPTBB9Saf4a8Ry6xdxxHVwNQWQ/b9KuI0R7cBTkRjAYjO3klsj0rRttE1G08VahqaS2zQa jbxLISWV43jBHAxggg9c5HoarP4b1C/1DSLjUxYGbS3WT7fCW8+bCkFNpHyg5GfmbOOg7C6f1/X9 WCXX+uhpeLLu/wBP8L6hfabPFDcWsDTBpYvMBCgkjGRycdecehrPSTxGdDg1O3vo55Lm2g3QSRoq QkkeZKG4zhSTtPGRx6Vo+KbG/wBU8N3unactuZ7uFoc3ErIqBgQT8qsSR6Y/Gsu88P6vqHg2z0yU 2cV5aNCTGszvBOIyPlY7AQGxyMHHvSXX5frcH0+f6W/Uq6V4neDxHqGny6s+q2MGnC+juZIkDcEh gGRVV14BBA/E1esG1/VtO03W7TU0j+1COWSxliXyRE3JAYLv3hT13YJHQZpo8OajceLX1i8+xC3u dN+xzQIzMU+bJAJA3AgkZ+X6Gq2g+H/F2iBNHXVtOl0SAbYZXhc3apnhOCFGBwG5+lNef9av9LA+ tv60X63LFvqesv4+1LRnvYDbpp63FsBbYEbMxUbvmy2Mdiuc9BWTDrfiGbwFqGuPqqrd6dNcECO3 QJMInI2sCCcEDsQR6mtVdH1+Lx3d68lvpz20tmLWNDdyB/lJYMf3RHJOCM8deelZ1v4Y8Tx+CNU0 F4tJM99JMUlF3JtVZSxbI8rORnj19scz9nzt+un4D+1rtf8ATX8S9f8Aij7Rfpp0dxf2R+xR3LzW Ng11IC5O1cCNwo+U5yOc8dKoL4t1eLwx9q1SC9slhvmtrm/+xMjrBglZxG6nGflBypA547VYn8Oe KIHstW0i60621aK0W0ureYvJbTop+U7goYEZJ6d8Z7naWz8Q/ZbaWa9s5LxZC9xGqOkDrtI2LySO SDuOee3aqdtf66/5Erpf+tP8/wCrE2gXpv7SS4j1ODUrUuBb3EW3LLtGd23jduznAH0FQa/cXsVz bRrfDTNPZWM96rR+Yr5UIihwQd2T/CemOCab4a0BtHm1G6eG2tn1CZZWtbQkxRELg4JAySeSdo+l Jqmj6hL4o0/WbM28yW8LwvBcyMgTcQfMQhT82BjBxkdxQ91/XQa2OTufFety+CptTg1SSK60/Vfs bOLZB9oTzFXLqy/KcH+HHNdDq2oalafEDQ7KLUJBY6hFP5tsY4yAUUEENt3dT69qz/8AhBdRk8Pa 1pct3a77zUWvreVQ2N25XAYfwjKkcE9etX77Qde1LxFoestNp9q+nrKJohvmB3hQdp+TPAPJxjjg 0K2l/wCtP8xPr8/z/wAjK8PXc+jxeK9YvtXvrqHT76bdDIIsSBUXBJCAg9BgED2q/q2pa3ovh6Px O2oG5REjlurAwoIvLbG7yyAHBAOcsxBx0HazaeFZl/4SCwvDBLpurzvNlWPmDegVlIxgYIyDk/QU 2Pw/rN1oa+HdUmtJbBVWNrtHbzp41I+UxlcKSBgsGP09BdPRf8H+vuG936v/AIBrTeJtBt51t7jW tPgnYKRDLdIj/MMj5Sc85FYP/CSSy+Ir3TZNW/s/UYpdltp9xGgiuI+MOrEAsxGejYB6qa37jw3o N3dfarnRNPnuOP30tqjPx0+YjPGKx9b8NajrtnJpt4thPBJO0kV25YTWg3ZXYu0hmA4zuXHocci3 DoPj1XVV+JTaPNdRPYNpxuY4kh2lTvC8sSSe/TA56cVQutd1aa18Q6jHqH2CTRJZFjsniQpKqoGV pCRuw3ONrL+NXv7F1ofEJdd8uxNgtl9jwbl/Nxu3b8eXjOeMZ989qxZdM8V6nqU2p6bD4U1G2Nw7 2dzqUEpmRc4wpXIAGMAjr170uiXk/wA9PwH1+78tfxLh1fxKNV8Mxz31okerK5mhSxMbIRGWwd0j HuPTkfhTpvFF5oF14jt72d79dNhhntmdFV28zICHYAD8wGMDOD3pJbLxXrGq6HqkllpUTaXJKJ0+ 1yASsQUJT92cLjkZ57e5dP4U1XVNd1yTUkso9P1a2S3BguXaaLZna2DGBnJzjPGO9N/5iXn5fmMh 13U4PEGn/ZzquoW17J5d6k2jS26W5xxIrmNflzwQxbjvUul+JJb/AFeayfVRa6nHdbH0q4jRR5Qf 70ZwGYlOc7mHsKt6HY+M4Jktta1PS57GHAWa3ikFxNjpuydq++Ac89Kiv/DWpauLKDURYSfZLhJ0 1BS3nptfcECkegwW3c/3aFa6FrZljxPdf2Xq+g36kL5t79il/wBpJFPH/fSqfwrpK57XbUatr2j2 SEFbK4+3T8fdCqwQfUsePZT6VdsLnVZNYv4btLM2SEG2kt2YuPVZMjG7vx260lt/X9b3G9/68/0s alFFFABWL4z/AORH17/sG3H/AKLatqsXxn/yI+vf9g24/wDRbUAUfEWi2Ov+KNMsNSjkltm068LR pO8W795bcEoQSOeh46elbFlcaXZzLolvfxtcwpu+zSXZlnC+p3MXI56mqt1/yPGl/wDYNvP/AEZa 1Ugme68ZarepG86aXapaxxIRlpG/eOBkgZx5Y5I/CgDpaK5fTNfsYtDvfEcj6mLe4uCBBdMrlGDC MLGFJAUsOOcZOc4rTfXfLsLq4bTrtJbSESyW7+WrAHJxu3bDwMnDYoeiuw6mrRXPaL4jkm8ORarr NpNYNcMDHE4Vi4blFQISTwQOQDkHgU//AIS2zha/W/tLuwNhbi5k89UO6IkgMNjN3U8HB9qbVtAW uxvUVn6dqovyqNZXVpKY/MMc6rwpOByrMvPPAOfXFTahqNrplt593JsUsEUAEs7Hoqgckn0FIBtx q2m2d5DZ3WoWsFzP/qoZZlV5OcfKpOTz6Vcrkbi+/t3xlpFg9ncWraesl/NFOFyODHGcqWByWY9c jbzitC+8W2dlFJcJa3d3aQyeXPdQKpjibIX+JgWwTg7A2MEdafQOpvUUnWlpAFFFFABRRRQAUUUU AFFFFABRRRQBi+FP+QRP/wBhK/8A/SuWtqsXwp/yCJ/+wlf/APpXLW1QAVi+K/8AkEQf9hKw/wDS uKtqsXxX/wAgiD/sJWH/AKVxUAbVFFFABWLa/wDI8ap/2DbP/wBGXVbVYkDiPxpqzt0XTLMn/v5d UAbdRC6t2uTaieIzqu4xBxvA9cdcVzcHjGZ30q4m0wR6drEoitJ1uN0oYgld8e0BQQD0Zu1VNPtr e2+L2pmCCOHzdJjkk2IF3sZDljjqeOtFtbPz/BXE9F9352O0orm7jxVcx6c+s22lfadIi3M8y3GJ iikguse3DLxn7wOO1On8Wga3p2m2mnyXEepwNNbXXmqI3AXd2yR1HJA68ZoGdFRWBb+IL+4uhZDS Y0vYIFmvLdrsbow27AQhcOflPXaORzWzaT/arOG48to/NjV9jdVyM4NAE1FYN14hvGjubjSdK/tG 2tJGjmIn2SOy/eES7TvIORyV5HGasXOsTtMtpptmtxemBZ2iuJTCsak4G4hWIJwcDB6HOKANaiuG 1fxrfXHhhL7SLaKK4XUFsbuKeYhoX8wKVBVSDnP3uwOcE8VZu9c8Tx+L9N0v+z9NVZraWZ4xfSEM VIH3/J7buBt59Rimlf8AryuH9fodhRWBqXiK6toLy60/TVvrbTywumNx5bZUZYRjaQxA9SvPGa1t Ov7fVNOt7+0ffBcxrJG2MZBGRS8wLNFc7qfiie0s7vUrPTlvNPsWdbmX7Rsf5PvmNdpDY5Byy8g4 zUN14uubfWNJiTToH0rViog1E3ZUAldwBTZwT2GefUULUHodRRXLX3iHW4/C2ratFplpF9lWRrVn u2cTIuf3mNgxkDIHf1A5qfS9bv00LTW1C2ha+vVRbeOG5L+d8m4sxKLt4BJ4Ptk8Uf194PT8fwOi orlz4xmt/wC07a80hhqOmxLO9tb3CuskRz86u2zgYOQQD7GlHi+ZbDRtSn0wRWOqNFGX+0ZeJ5B8 vy7cFc8ZyD7UJX/ruB09QtdWy3SWjXEQuHQusJcb2UdSB1IGRzWTJ4hma4vxZ2K3UGnMY7gifbLv 2hsKm3BGG6lgeuAaifWYf+E6g0iTRys7WjyRX7lMlAVyq4y2MnnOOnQ0Lp/XQDoaKwJvEN5JFcXW l6Ut9Z2kjxyv9p2SOU4by12kNg5HzMvI4qufGsU19o0Vjp811bawjNBdCRFUYUsVxnORgZyAOepx ihahsdPRWPpOuSX+q6hpV3aLbXdgUZgkvmI6OCVYEqp7HIxx71Z1XVY9Lih/dtNcXMoht4FIBkc5 PU9AACSewBoAtG5txci2M8YnZSwi3jcQOpx1xyPzqWuFtlkHxWtpbrTbeyu5NKlaZoG3rL86AHft UtgDHIGPpita48VXMenPrNtpX2nSItzPMtxiYopILrHtwy8Z+8DjtR0T/rdoOtjekureGeKCW4iS abPlRs4DSYGTtHfA9KmrmbrxJZt4l0K1XSxcrqKPJaagWTao2Fjt6tkjbnoOepxUWia1r1/4v1mx uLWyFpZSRx5W5fcgKFgQvl/MTkZyVx745dgOnngiuYHgnjWWKQbXRxkMPQiobC6sbmArYXUVxHA3 lMY5RJtZeCpOTyPfmo9WvYrGxLS+YTKywxpGcO7scAA9uvXt1rnI9Vk0rVbzT10e1sdSayM9tHHd Fre4ROOTsBVl6Y28jHJxxN9x2OxorhbLxpq1h4Gste1TSVuVuBGd9tc5++cZdWUFeSAAu+uhk1q7 gnMFxpgjlmmEdkouA32j5dxJ4+Tbg569OM5qmrOxKdzZorE0jxA99qt5o9/aLZ6jaIsjRxzeakkb dGVtqk9MHIGKbr/iV9D1HTLT+zJrldRnECzLIiqrHJxgnJOAT0x70u3mPv5G7RXPp4luodYm0i+0 rZeeQ1xaLb3AkW6RTggMwTawyMg8c9TVfS/GMuo6RDrL6UbbTf3/ANpmkuF3W4jJAO3HzA7ex4Pr 1o8wOhkvLWK6itZLmFLiYExRNIA7gdSB1OPapWUOpU5wRg4JB/MVy0utCx1+wvdU0lbZNT22lrdf aA7xk5YI6bQE3HurNyBmr0PiKa6eaa1sFnsobk2rSJP+9EgfYxMZXAUHnO7OO1OwE+keGNK0K5uL jT4riOS5O6YyXc0okb+8Q7EbvfrWtWNfa1diW6h0mwjvnssfaBJceUASN21flbLYwcHA5HNZlv48 hvp9FWx0y4mg1hWMU5kRQjKpLKRnOQRg8AehPSktQ2OsornY/Ed7K2s2IsIItS0yNZBG1wWikRgS rbtgPY5G3qOveq3hrxHqE3hOx1LVreEy3ixi3EE5Zp3fPBBVQn5sAAeeKP8AgfiB1dFYVh4hmk19 9C1Oyjs73yPtEPlTmaOWPODhiqkEHqCPxNbtABRXP/8ACTzv4ruPD0WkyCaK2+0JNLMqpIuQoPG4 gZz2zx05qvaeLb6+0i+uoNFX7Tps0kV3BJdbVBTk7H2ndxgjIUc9RR0uHWx1FFc+PFQvYdMGk2gu bjVLY3MKTymJFQbc7mCsQfmAwAeao3Hjs2/hS51saPPI9nO9vcwJMmInU7Sdxxlc45AJ56U7O9v6 7AtTrqKw7jxBPZb2vNMZFleOOxEcys907g/LtONpGOc8Y5zUK+JL6LXbfRLzSoory6hkmhaO73xF V7FigYHJH8JHPU9KQXOiorkbfxpe3HhHUtcXR4hNps00ctsbw4YR/eIfZ+Qx+NaK+IHvrGxSztVe +1Gz+0rC02xYkwMln2njLADCnPp1o9P66h/X3Gva3lrfRGW0uYbiMMULxOHAYcEZHcVNXLaJ4i0+ 10ee0Fj9in0ydbN7GNw/7xsbArcbg2Rycd84q5a+IZx4hXQ9UsY7S5miaa2aK481JlU4YZKqQwz0 wR7mnbt/XURu0Vi+KNHl1qytIYWKtDfQTthsfKjgt+maznWfwhB4k1x7WW9jnuftIijkUERiNQT8 xAGCG6c8DilpZt/1t/n+BVruy/rf+vmdXRXON4qmhbR5rnTRFZ6syRJKJ9zxyMu5QV242nGM7s+1 W7jWbuW7urXSLCK9ezKrcGW58lQxG7apCtlsEHBwORzTasJO5sUVylz48gj0S11S20y5uEmuhazI XRDbSbwhVwTnOT2B/CtGPXpk8Sx6Le2KwG4gae2lSbfvCkBlYbRtYZHQsPei39fiH9fobVFU9U1K DSrI3M4ZsusaIv3pHYhVUZ7kkVnf23q0F1Nb3fh+RisDTQvaTiRJMHGxmcIEfnODkdcE4pAblR21 1b3kAntZ4p4myBJE4ZTg4PI965/SfFF/rOk2uq2mgySWlxDI5AuUEispwq7WwDu9c8fTmsS58WXZ 8B2Oq6BpdrYx3N4tuYXk2eWDNs42rjJ7ntn+KnbWwdLndS3VtBLFFNcRRyTsViR3AMhxnCg9TgZ4 qauZ1DXJLXW9DstT0GJri8lZY7lJlkjgfaxO0lQ5O0f3VHPWrs2t3M9/cWekWMd41mwW5eW48pEY jOxSFYs2MHBAHI5pAbNFca/j6RtCsNattI32t1e/ZJFludkkRMmwHAVg3IPcduvbVm8Q3Ft4xt9B msIxDdW7zxXS3BJ+TGQU28cn+8aP6/C/5A9P687G7RXMX3jBrGyh1iSwU6JK6p9rFx+8UM20P5e3 Gw5Bzuzg9Kr614UutSm8Sywyf8hXT4oIPnwN6h/yHK/maA62OvoqK2i8i1ihyT5aBck9cDFYGpeL JbKwm1aDThc6TauyzzifbIAp2syJtwwBz1YHg4Boe4LVHSUVyM2v61N45tdOsLeymsJbA3SFrl0L qWUbjiM8jnC9DnOR0rpb+9g06wmvLlykUKFmIGT+A7mjpcOth0N9Z3NxNbwXUMs1uQJo0kDNGT0D Acj8anrkYr5dK8QWEF5pCWMl8jx2txHc7zM33ykw2jDE85G7nPPPNbRPFWvvpms6lf6VBcRWV1Mm y1u/nXyyAQFdVG0AE7t2T/doA7espPDWlw3X2iCKe3JYsY4LuWKJiSSSY1YISSTnI5qjaeKZ5tMt 9VuNLMNhc2kcySCcM5lcgLFsIHJLDB6euKlh8Rzw+IYNG1awjtJbxHktJIrjzVkC43K2VXa2DnHI 96dmnYL6G6qqihVUKoGAAMAUtFFIAooooAht7WC18zyYwhlcu56lmPcnvU1FFABRRRQAVi+M/wDk R9e/7Btx/wCi2rarF8Z/8iPr3/YNuP8A0W1ABdnHjfSz/wBQy9/9GWtYunyapZeBdX1BdOuTqVy1 xcCDymEhdmIUbevChOnXtW1df8jxpf8A2Dbz/wBGWtbVJq9xp2sclFaw2Hhyz0K80u5n0lbHy53W B5H3DaF+Rcvk/MeASMDOKq3MWtN8PHsLuG6mlnn+y7vLZ5vsrSbd7qATu8vk/r3rt6Kpu7uJaJWO K8TWt6viHQb3bqMWmWscisLCATSRSEAKWXaxwVyMqMjPUdavmKKyWSP+xbiewvA/2yaUPPNKu3qy csRyAFGTjOFAFdNRS6WAwPB8N7b6ZNBcCf7JHOwsDcgibyMDaHDcjByBnnAGaq6rFc/8J9pdxcWk 8+nw2kvktFE0ipcEgZbA+X5MgMeOTzXU0U76p/1tb+vMOjRxUdlrl1eeLLxYpLe+mhW2sGYYUKse V2k9fmc8+oo8L6fC2j6bbS2eqTz2IRTDqMRgjgYYyQAoSTGPlIDHpyMk12tFC0/D8AeoUUUUgCii igAooooAKKKKACiiigAooooAxfCn/IIn/wCwlf8A/pXLW1WL4U/5BE//AGEr/wD9K5a2qACsXxX/ AMgiD/sJWH/pXFW1WL4r/wCQRB/2ErD/ANK4qANqiiigArAzOvizWmtlVpxpNoY1boW8y6xn8a36 xbX/AJHjVP8AsG2f/oy6pNXQI4u6tL7UbLw3qE+napPqVvqkMmoSTW75iIBDBFP8GccoNvGSc1rR NJcfE6/drLUYre40tbVZ2s5RH5gZiRv27eAeucHsTXcUVT1/H8VYP+B+DucPov27S/CL+FbrTLp7 +CGS3hZIGMFwpyFbzcbF4PIYg9eOlVRatoXibwnYi11C4h0qykt57mKymkjDMihfmCkckHp074r0 Kii+t/66/wCYraW/r+tDjfFWl2epX8kl1Y6lbXcCKtjqemxuZNxGdh2ZOAe7ALz1BzXR6ENQGhWI 1Yg34gX7QRj7+OenH5VfopLRWG97nBaPfat4QvrzRLjw7qeo2895LPZ3VjGroVc7iJCzAIQSep5p niXT3s/Ekeu6l4THiCzubNIZoYbdbmW2kViQVRuoO7BxjpXoFFHYO/n/AMOcHrGm+d4MWXSvDTaY gvre5NlFbIkxVHUsxSPILYHQZOB68Vo6gtx/wnOjastldPamzngLLCSUdipXcP4QQp5bGO+K6uin fX+u1hf1+NzzSTTrbQ9fv7fVvAb67FfXbXFrfW9jFcNhzkpIWxtwc8k4xXoOnQLbafDClrFaKq/L BEoVYx/dAHHHtVqiktFYb1dzzKHTbXQ9WvNP1bwA+tfaLuSa11C3sYp96OxbEjPjaRnHJro9SsrX W4F8J3OnTWtr9nDyNDaMIUI+6iPt2gjg8emB146qijpYOtzhbO+1XXvBOsaJdWF6NQhtpreKaezk hS7XBVHUsAATxkevtUGr6fc6h4Z8PahHoL6l/ZYX7Rpt3BtaVTHsbCOOWU8jI5xxXoNFH/A/AP8A g/icHC+nN4c1S903wTc6MZLSSEL/AGYsdxMzDAVUjy23PUnA6H3qhf3EzeAPDVoulas1zbT2hmhX TZy0YiK7yRt/L17Zr0uimnZ39PwDp9/4nn3iHTvt9xcanp1jquna/kiyurWF1W6UAFRL/CB2PmbT xxVu6mn/AOFnaZNJZXzJFp7281xHZSmESuVIG8LjHHXOB3NdtRSWlv66WB6nGeGzdeGLO70K80+8 nZbiaS0mhgaRLhHYsMuBtRskg7iBWRFp03hu98G6e9nf3H9nmaS6lt7SWaOIyKcDcqkfeOOOgGTi vSqKadget/n+Jx2jXDv8SdalNjfxwT28McU8tlKkbtHu3YYqB3GD37Zq14usbw32i61aW8l0NKuW kmt4uXaNkKkqO5Gc46nmunopdvIOr8/8rHFXRutR8d6ffW2l6g1lLpsts87Q+V5RdgckPtIxg8Yz 7GmaL9u0vwi/hW60y6e/ghkt4WSBjBcKchW83GxeDyGIPXjpXcUUdOXp/wAP/mF3e553c2Mmi+IP Bdilrf3MWkwyR3FxDZyyRrujCr8yqRyfy74rb0SC5svG/iHzrScR3zwSwTCMmNlEe0/P0BBHTOfa upop3b1fn+OoraWOb8daRc6voKfZLOK+mtLiO5FpNjZcBTyhzxyCeves3QItO1JZ5NO8CPoU6xOj TXNhFbsSVxtQj5jyeuAMV21FTbRruVfZnmN99rT4S2Gkf2TqbXsXkRtCljIxDRyKW6DpgZB6HsTW 54zsZNWstJ1i10b+14rKYyS6fcw7WljZSpwkg+8OCARniuyoqm76+dxJWOY8JLp07Pe6d4PbQF2l Ga4sY7aWTnoApzt4747Yqn8QJTDfeF5RG8u3WEOyMZY/I3QV2dc54l8OajruoabcW2q29pHp04uI 45LMyl5ACOSJF+XB6AfjRfVeq/MVtH6MrSY1PxPb+Ifst7HZaXZyqpktJFkmdyMhYiu84Cn+HnIx msrw3ptxrHwwvNBktruxu3Wddt3ayRYLuzL94AMORnGfevQBnA3EE9yBilpdLDvrc8+8PR2M91BZ z/DVdP1KAqZLttOhW2RhjLrJ1PqNoJzj60alpUsmqf2npFlqWl6+90N/kxt9mu4w+N0p5TBTnkhv Y16DRTvqmK2ljznVtPh0bxXqN1qfgpvENnqciSw3FvZx3MsLBApRg3IX5c5zjmp7/bZ+IfC32fw/ d2dtbSTSyxWmnu0dusiEKGMaldxPUAnH6nv6KS0sN63OIspJbnx34i22N+kd3ZRwwzS2cqRO6B9w DlQO4weh7ZrP/sa/vvhto1sujNcXejvE8theRbFuCmVdMMMHg5BwQeMZr0eijp934B1v/W1jjfDc 2luZdRsPAc+itbRsXeXTY4ZZOPuRhfmbP4D+nS6TqcesabFfRQXFuJMgw3MZjkjIOCGU9CCKuMod SpzgjHBwfzFNjjSJAkahVHQCmBxf2l4vizNdtYaj9l/swW32hbGYxmQOWIDBcHjv07VU0W/aHTvF nm6ZqyNdXc01uraZODKjKqqQNnr26jqeK9CoqbaW8mvvdx31v6P7lY848Py6iul+HNOvLLVYNNjs zFcpHaTI/wBoXG1XwAwTGeR8p6E4rNns72x8B+JdKGiais93qcrW8ENm75UshXG0EYwDyOOMZzXr NFW3d3/re4lpby/yscn4gW5vbLQ9bsLS6nGnXYnktTC0czJtZGwjAHcM5xjntVW4vEvviboE8Uc6 I2n3JAnhaJuq9VYAj8RXbVzl/wCHNSu/F9lr0Wq28UdnG0S27WZYsjY3ZfzBzxwccehpJ+99/wCV hNe79353Odhs76y8J+LNEbTr2S7mmu5YdluxSVJASpV8bSefu5z7VWudLure30LWb/whJqsFvp4s ruwlgjmniK4xIiZIOSCMcHBFenUUlp+H4Jr9R/8AB/Gz/Q8/1DQ49Y8JyTaL4Qh04rPDcrp9zbRw NdbGyVdVyMEEgBu/pV7wqNMvL1Z7LwG+hTQZElxc6fFARxgiMj5m69cAYzXZUU7isFYXjZn/AOEN 1WKK3uLiWe2eKOO3haV2ZlIHCgn8elbtFS1dWKTs7nnWsXkkugeE1j0vVne1u7eWdF02ctEsakMW G31/PtmtXSzP4a8QauLqzvJrLVLgXdtcQW7zEMygNG6qCUxgYJGMHrXYUVV9W+/62/yRKVkl2/S/ +Z5prOl3Wl+GWX7BezXOo62uoNBbW7zmFPNViDsBAO0D6nOM1r6hfGf4iaHcxWGpNbx2sySTf2fM ERpNhUEleOnPp3xXaUUJ2t/XS35Det/663Oc8caXf6loSPpcay3tjcxXcMTHAlKNnbn3GaZY+K7n UrKaWXw3rFgkKHzftNtkscY2xqpLvyRztxjNdNRU20aHfVM4/wABXDWXw/toruyv7eayiZZoZbKV ZM5J+VduX4P8Oa5zTbK/k+FVpaf2ZfpdWN+k81vJaSJJsE+8lVIG/wCXn5c16nRVX1v6fgLpY4nx XdvL4k8MTx6fqUkVtcvNM8djK4jQoVBO1Tg57dR3Aq1o32jQvEGsWd3Z3ckWo3Zu7W5igaRDuVQU YqDsIK/xYBHeusqK4WZ7eRbeRI5ipCPIhdVPYlQRke2RS2Tt5/p/kG/9ev8AmeYabY3V98KbVrS3 kne11Y3LRRLudlS4JbA7nGeO9buqC71Dx1o1/baVqElk1jPC8vk+X5e8qMsHKlcenXjgGtjwh4eu /DGlNp1xqMV7GJGkjZLYxFdzFmB+ds8njp+Nb9N2/r0sD1b/AK63PL9B02005IfD+qfDhbq/gHlr qCWEL28yjgSPK2MHHJHJ9u1enINqKuAMDHyjAp1FF77gJXmWn6Za6Ley6Pq/w9bVpWuJGt9RgsYZ klRmLAyO+NpGccntXp1FLqHSxyL2lxYePNNu/sDi1OlNaj7LETHHIHVgvHCjA4JwOK1fFukS674X v9OtynnTR/uw/wB0sCGAPsSMGtmih6q39b3BaO5wnhkafeX0MY+HP9j39uQZbqXT4UijYdfLkHLH 0IFMshc6V4c8UWVxp1+00t3dPEIbSSQSiX7hUqDuznnHTviu+ooeqa7/ANfoC0a9b/195wZ0y613 4U2enwWUgvLSG3zaXsDRCR4trFCHAyDgjPSp/C40y9v0e2+HzaHc25PmXNxp8UIQ4wRGw+Zs9MgA Yz9D2tFU5XbfcVtEgoooqRhRRRQAUUUUAFFFFABWL4z/AORH17/sG3H/AKLatqsXxn/yI+vf9g24 /wDRbUAF1/yPGl/9g28/9GWtX77VNO0tEfUL+2s1dtqG4mWMMfQZPJrOv3MfjLTnClyul3pCjqf3 ltxWR4MFpq3hiTWtSfzrvVjItyxY70G4qIVxyoUcYHOcnqaAOtnura2tmubi4iigVdzSyOFUD1JP GKqHxDoi2sN02s2At7htkMpuU2SN6Kc4J9hXLW7Xd342v7CCGxhttEt4o7JLmRiIsrkyiID5v7ud wxggdTTNTtI1tdJ0jT5vtM2rar9quJ3XaH8s73fb/dyqgY4Ixyc5prp/XX/IH/X3HXX+uaTpkU8l 9qNtALZQ0oeUAoD93I684OPXtWW3i2xvtFguNM1XSYry9H+iR3d0NrnIGCFOSeRkDoTiqXifSNPs dOktrOBI7zXZ4rOefPzSrklyx9dm/n/61Sa1JFe+LNA0pHUW9sGv5V7ELhIh/wB9Nkf7tC1/r5sH p/X3fiP1bxTZNrtj4ct9Vtoru4c/amSZd0SqPujPR2OAB1xk1N4Xlke5vY7XXLHVtKRgbdorhp54 WPVHcs2QOxJzyah0yRbnxjr2rynEFhFHZIzdBtHmSH82UfhXPf2ndWXw9n1aGYw3Wt36yS3C9beO ZwqsT2xGFx6cUl/XzegP+vktf8jv/wC1dN/tD+zv7QtftuN32bzl8zHrtzmlutSsLKWKK7vre3km OI0llVC/0BPNZlzY6NpWlxeXaiQaYjXcMaEklgp+c4+8Tk8nqTnrXMTTxr8N5L65cT6n4hjQM45I aYhUA9ETcAPp6mj0/q+wLpc6nV/F2iaPaW9xcalaYuyv2b9+oEoJA3A9Nozkt0FaLapp6XENu9/b LNOu+KMzKGkX1UZyR7iuelS3k8UaLpsTL9l0q0Nz143MPKix+G81UupbVtWtdXhCXul+JBHZ3Nu4 yykBtrLjt1DDt17GnZf19wtev9dfyO1BDAEEEHkEUtIAAMAYApaQwooooAKKKKACiiigAooooAxf Cn/IIn/7CV//AOlctbVYvhT/AJBE/wD2Er//ANK5a2qACsXxX/yCIP8AsJWH/pXFW1WL4r/5BEH/ AGErD/0rioA2qKKKACsW1/5HjVP+wbZ/+jLqtqucuEuJPEevpattuG0a1ER9G33WP1pN2VxpXdi8 /ibR47yO1e7KtLJ5SSGJxEz5xsEuNhbIPy5z7VLqGu6fpkhjuZZC4AZkhgkmKKc4ZginavB5OBxX LeEvE3hu68JaZp97dWn222jSJ7C4K+cJk4wIzyW3DIwKu+GLp4vFHiayv323TXa3EStxugKKqlfU DaQfQ1TVm1/XQV9LmvdeJ9DsrW1ubjVbZIb0gWzB8+dnH3cdeoqW31zTrrUJNPinb7THH5mx4nXe n95CQA491zXndzbtaeCpi7gWc/iRZLMHgeUZwRj2JDEe3NdRqrovxP0AbgGaxuhjPJ5T/ChK/wDX lcHpf+utjPj1tfFfiTVtJFxq9itsIls5ILe4hMblSxeT5QAOmFk4OOBzXRf8JHpmnLFa32omSRMR S3ZgcQmQcENIBsQk/wAJbvisTw8Xbxx40EDL5u63Cc/xeV/jUOhXFtc/Ci4tL9sTW9tNb3scn31l +bII9STkeuRSbtG/kn/X9dh2vK3y/r+u508/iTRrfUX057+M3iRmVoIwXcKADkhQT3HHU1XsfGnh zU5PLsNViupPK83y4VZ328fwgZzz93r144Nc1pENxbeK/CdtqDA3kWhyiQMcsG/d/r1/Wr8br/wu SZdw3f2IvGef9aaq2tvX8L/5E30b9Pxt/mbC+LtDfTTqKXjvbqSshS3kZosHB3qF3JjuWAxV6fVr G3s4rtpt8UwDReSjStKMZ+VVBLcc8A1yHh94hpvjUqyADUbokgjj92P/AK9YWm3y6fa+ELi+1m40 mym0hoEu41jKrLlTtYyIyrkDrgfd61K1/D8U3+g3p+P4NI9N03VLLV7T7VYTiaLcUPBUqw6qykAq R6EA0zUdYsdLKLdSSGSQEpFDC80jAYyQiAsQMjJxgZrJ8JWWlQT6leaXrU2r/bZVknuDJE8fmAY+ Uxqqg4AyPpTdRukfxtDZW0cVvepp7SPfTZO2EuMoi5AJyMknpx1zih7pf1sHRv8ArcuXPi7QrTTb fUpb0mzuX8uOaOCR13Zxhiqnac8fNjmp7jxFplrrMWkTTSrezRtJFH9nkIkVRk7WC7SQOwOa8zLb /hNfL53neVrLOXJGSguRljjAx3z0rp/Et9Z2/wAR/CjzXUMS7LkbnkAGWRQoyfU9PWmle39dLi7/ ANdTZt/G2gXWn3t/DdTtb6e2y5Y2U4MbemCmSR3wOO+K2redLq3jnjDhJFDLvRkbB9VYAj6EVw2s bNL1p/FVsvmaI0ipqUaNkSMpKicD/YOAfXGcfKM93FLHPCk0LrJHIoZXU5DA9CDR0uN72M/UvEWl 6S5W9uGQLjzHWF3SLPQuyghB7sRUd14p0ez1a10qe4lF3eY+zqttK6y+4cKVOO/PHeuLgurE3/iD R9d8Wz6PJJdyl7eQ20aSwuPlZWljJPy8cNxjtWzfaJa3XhjTNE0q6l+2WyLLp11Kw8yEIcCQ4HIw QMY5Bx6kJbJvy/r5f1YHu16mzL4l0aS31ESXz2sdifKuZ5YnhWJjxw7KATyMYz1HqKdp+o6ZZ+Gb S8GpyXFl5SCO6uWLSTZ4BORlmJ9sk1laTq8N/wCD9SgkRbe/sYpYr+AtkpLtO5s9w33ge+aw4jZL 8L/C091qEdk8EltJbyTNiIyDJw5yPlxnntT/AOB+N/6Qf8H8Ds7TxPot5cpaJqEcV25wtrcgwTn/ ALZyAN+lKfEmkrqEdi10VlmcpGzROIpHH8KyY2FuDwDmuc0+aLWtY1DVbfWNJk1F9ONtFaabfC4C gEsHZsKSckY4GPU5rD0g6Fr3hfT9P1Dxjexz2/lA6YWto5kmjxhVXyg5IYccnPrQlf8Ar1E/6/r+ tjvF8VaJJNdwQX63Mtl/r47ZGmZOvGEBJPByBkjvVqLV9On0tNTju42s5ACsueDk4A+ueMdc8Vz+ huh+I3icbgWEFpkZ5HytXKWN/wD2b4S0LU3YnTrPXZzdlOQiF5ArEegLA/lSXT5DfX+ulz0fTtd0 7VJZobWZxNAAZYZoXhkQHoSjgNg+uMUyDxJpNxqCWMd0wmlBMO+F0SbAyfLcgK/H90msfW9S0zXN A1ceHbu0vtRfT5F8yzdZHUYOFLKcjJJwD3z6Vjae/h7xJDo8jeM7y7ntpo5rew32qSrIoxtKLEr4 HIPbGT700ruwPa52j69psd21s9wysrBC5ify95OAgkxtLZ425z7Vo155cy3miefqek3lvqWiS6ji 5024GJYJTLhvLcHk78Hafw613Wo/aDpl19k/4+PJfyv97Bx+tS3aNx296xyfjzxBEvhnUl0zVrq1 u7VGIltoyEZhwY/NKlc9chWDDFb1l4i02fUf7GE8p1CK3EzxPBIMpwNwYrhhk9ia4u7urWf4ESKZ Iy8VkIpVbG5ZlI3Ag/xbgT6960bG5t7j4l6fdwTxS28+gERSo4KuRIM4PfFXaz5f62b/AEE3dJ/1 ujqdH17Tdejnk06Z5BbSmGYPC8TI45KlXAOealv9UtNNVTcu5Z8lY4YnlkYDqQiAsQMjOBxXLeAb y1k1jxTBHcxNMdVeURhwWKFVAbHXGe9Lea1baD8SZG1m6S1tL3TkS0nmYLEGV2LruPAJyDU9vNfp ce1/L/OweLtZFz4fsdX0bWZo4ft8MT+QwVXDSKrK+RuBHPGR710ttren3eoyafFO32lE8zY8TpvT +8pYAOOeqkiuU8Y3mk3PhaGbTJLZ7Z9WtiZYCvlyN5qliCOGPqfY+lXdWkRPiboPzAMbG64B5I+Q /wBKa217v8kyX/l+ZrN4o0ZbxbVrshnl8lZPJfyTJnGzzcbN2RjGc0N4p0QX9xYJfLNd2qlpYLdG ldfbagJJ9hz7VwOr3a3fgayvbMxWFjJqsTW9kvzOT9o+YuzEnOfm2gDHqa6K1nh/4W/eL5qZk0aP YNw+bEjZx60Jfr+Vwbtf5fnY0dU8ReH7rwvLeS66bKynzF9qhkMUqP3VcjcHGDxjPtRqvi2z0a/0 qwaG8nN9krJHayy/IFJz8qks3A4HIzk4rkdYhK+FvH19G6/Yrqf9wV+6zKqq5H/Asj6g1uaqQPEf glyQFzMMnp/qKF/l+KG/8/wNmTxj4fj+1g6ijNYoHuVjR3aEf7QAJBGDkdR3qxqHiLS9MUNdXDhd odmjheQRqejOVB2L7tgVi6Y8UnxR1hlZGP8AZttggg8bnP8AhWKt7aQ+IvEOm6z4rn0V5bnzFif7 Okc0LIoBDSxsT0IwG7dKX9fiHX+ux6JFLHPEksTrJG6hldTkMD0INcTr/iF9R8TnQNK8ZW2g3NsF DrJaJM07tyFBfAGBjgHJLe1dJ4ZsbTTfDtnZafcTXFpCm2GWZgzOmTg5AAI9OOmKh16y0DxDo13B qH2a6gj3I7gqzQuOOCOVYH8aJaMI6o1LKGe3soYbq6N1OiASTlAhkbu20cDPoKp69qb6bp0rWyrJ dtG5hRunAyWPsO/4DvUWiSyab4d0qDWbqOO7MUcJM0gBeTHTnq3HQe9Z2sR+IIo9WuF0/TZ4pIXS OR7+RGSIKeNnkkZ6k/NzxzwKVTS9vMcOhoeEL+51Xwjpd/eyebcXFsryPtC7mI5OBwKqePdS1PR/ Cd7qWl3UcEtsm7Lw7yckDjJwOp7Ht+NbwDeva/D7S5tTNpZ26W0YjlNzkMp4BbcqhTnjGT9af8TS P+Fd6uc9Yl/9CFXU0k7dxUtbXOmt3L20TsclkBJ/CuYTxFe3Xj+z06FlXTJbKaVflBMzKyjdnqB1 Ax16+lauoRahcaFFFpqQPI6oHE07RApj5gGVWIJHHTvXKTS62vxO0kPpmnRSLpsqrHHfuyCPeuTn yRyOwxg+opfbt6/kxL4L+n5o9Brh/GviKN9MjfSdWu4JIruFCYYysVwGkVWAkK4bAz9xuO9dD4sW 9bwlqq6cGN2bSQRBPvZ2np71yfifUNNm+FumXUM8H2cSWZU5AC7XTcPYjBz6c0lv81+LG9vkzstS 13TtJ/4+5ZAQNzCKB5Si/wB5ggO1eDycDirtvcQ3VvHcW8qSwyqGR0OQwPQg154mq2SeKtah1Dxd LpMd20c9qytbiG4gMagFXljbPIPAP4da67wnp9hpXhy2stLuprqyj3eTNMysXUsTkFQAV54IHSmt rg9zIsoG1L4h63Hc3d8YrKO1eCKO9mjjUlWJ+RWCnOBkEGobP+27rxvqujP4o1BLa1t4ZoikFruy +cgkwnIGOKt6J/yUbxP/ANcbT/0FqoRaZbap8UdcWeW6QR2Ntj7NeSwH+Lr5bLn8aS6en6DfX5fo bv8AZmspFdww+I7icyCNY5ZoYDJbndlyAsYU5UjAINY1yNbh8b2Whr4p1I21xZSXDuYbXeGVgAAf Jxjn0rodLt7LSZ5NMt55pZHLXBEszSugOB8zMSxyemT6+lYt86j4t6Uu4bv7Ln4zz99f8DQviXz/ ACf6iez/AK6oTW9W1Dwva2lve6vvS+v/ACRqVzFGDBEUzyFCrnIIBIxzkg9K17eDV7W+swNUbULC Td5rzRIJQdpKkMgVdv8AwHPTml1+40grb6XrUcD22os0QE5G1mAyBz3POPcVy9po1x4J8WaXp+h6 hPPpeou6y6ZPJv8As6hc+YhPIUHg+575oWun9bCZcsJNab4h3mlS+IrySxtbWK5WIwW4LFmIKlhH nbx2wfeu0rj9PkQ/FvV1Dru/suDjPP32/wARXYUL4V/XUPtP+uiOe8QeIJ7TVtP0DTFibUtQ3MHl BKQRKPmcgEZ9AMjJp97p/iC00+5m0/XJLu72kpFeW8Xl59F2KpB9Mlu2c1g+JIv7D+JWk+J7rK6b JbNZTzn7tuxJKlj2BJxnpXbSXcEcKzNKuxvukHO89gPU/ShbXG/iOR1abWR450rTYNfvba01GCaV 4khtyYigXAUtETjnnOTW5BpepQXgz4kvbqMxsHjnjtwVyPlZdkS8gjvkVz/iW0i1H4j+G7edp41N rdMfJuHhccL/ABIwP61v2lhp+haj+7ubp5b/AGxpHcXUk7HbuJIMjEgYJz2496Fsvn+bF1fy/JGD oUevarc65BL4r1BDp961vCy29rgrsVgWHlcn5uxFWvC+t6t4p8K3TGRLW+iuJLVbuFAUfaQPMVWy OnY5GRWBb+Hj4hl8XrZ388F6upnygl1IIWIRDtkjB2sCQQcjP5V1ng7WrHU9IS2gtorC6sv3Nzp6 AKbdxwQF/u9we9Nar5L8lr/Xf0HLR/N/8N/XYyNQGt2njLSNGTxTqRgvoJ5JWMFrvBQDGP3OMc9w a077RrsaPf8A9oavf3ZhV5baZLg2zqNnRvI2BsEE8jvVLW3UfFLw0pYAm1u+M+y10ms/8gS+/wCv aT/0E1Ev4d/X82OPx29PyKXg2ea68GaPcXErzTSWcbPJIxZmJUZJJ5Jrarm/Bt3bWvgXw+Li4ih8 20hjj8xwu9ivCjPU+1dJWtT436kR+FBRRRUFBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVi +M/+RH17/sG3H/otq2qxfGf/ACI+vf8AYNuP/RbUAF1/yPGl/wDYNvP/AEZa1fg0nTbW8kvbfT7W G5m/1k8cKq7/AFYDJqhdf8jxpf8A2Dbz/wBGWtbVAFO50nTL26iurvTrW4uIf9VLLCrOn0JGR+FT tbQPcJcNDG00alUkKgsoOMgHqAcD8qi1Ka6g0+eSyhE10ExCjZ2lzwM47Z6+1SWouRaxC8eJ7jaP MaFSqFu+ASSB+NACXNna3gjF1bQz+U4kj81A2xh0YZ6H3rP1KO5h1a0vLPSLe7Yo8Us/yLLEOq/M SCEznOMnpxWvRQBn6TpUenaabVwsrzO8twccSO5JY4PbJ6elWE0+yisRYx2cCWgXaIFjAj2+m3GM VYooArWWn2OnW/2axs7e1gH/ACygiVF/IDFRJoukxW32WPTLNIPMEvlLAoXeDkNjGM55zV6qF/Lq f22zh09IRGzlrqWZSwWMDouCPmJIxngAGjqBYNlaG7+2G1hNzs8vzjGN+zrt3dce1Mj0zT4r03sd jbJdFdhnWJRIV9N2M49qtUUAFFVJbp/7QhtIQpO0yTE/wJ0H4k9PYGjU9UstHsJL6/nEMEfViCSS eAABySTwAKALdFY6anrM4WeLQ0S1KliJ7rZcfhGFK88dXHXnFZ2o+Lb630vSb+x0VJ11SZIUiuLr yZIy/wB3ICMDwCTzx70AdTRWFZ+ILn+3U0TVrCOzu5oWmgaC4M0cqqQGGSqkEZ6FfxqC88RaxF4s XQbPRrS4DQfaPtD37IETO35l8o4JOcAE5x2o7eYdzpKKSloAKKKKAMXwp/yCJ/8AsJX/AP6Vy1tV i+FP+QRP/wBhK/8A/SuWtqgArF8V/wDIIg/7CVh/6VxVtVi+K/8AkEQf9hKw/wDSuKgDaooooAKx bX/keNU/7Btn/wCjLqtqsW1/5HjVP+wbZ/8Aoy6oAvrpWnJftqCWFqt4ww1wIVEhHoWxmi90rTdS MZv9PtbsxHdGZ4VfYfUZHFW6KAKV/oulaqsa6jplneLFnyxcQLIEz1xuBx0FQf8ACM6AbiO4Oh6d 50QURyfZI9ybRhcHGRgAY9MVqUUAZdr4Z8P2N0l1Z6FptvcIcrLFaRo6/QgZFWH0jTH1BdRfTrVr 1RhbkwqZAPZsZq5RQBnTeHtEuL/7fPo9hLebg32h7ZGkyOh3EZyMD8qR/DuhyXrXz6Np7XbElp2t UMhOMZLYz0rSooAyE8J+Go45I08PaWqSgCRVsowHAOQCMc8gH8KsR6Do0Wnvp8ek2KWch3PbrboI 2PqVxg9Kv0UARW1rb2VulvaQRW8KDCRxIFVR7AcCo7nTrG9mhmurK3nkgbdE8sSs0Z9VJHB+lWaK AKyadYxxTxJZW6x3LFpkWJQJSepYY5J96ji0bS4EiSLTbSNIVKxKkCgID1A44BwM49Ku0UAZw8O6 GunnTxo1gLNn3m3FqnllvXbjGferVpZWun2y2tlbQ20CZ2xQxhEXPJwBwKnooAp3ek6bqE8U97p1 rcywHMUk0Ku0Z/2SRx+FK2l6c2orqLWFsb1F2rcmFfNC+gbGccmrdFAGV/wi3h3Mx/sDTMz8Sn7H H+85z83HPIB57iqOq6DDb2dva6boFhPpqytJdafHFHH5xx8pAICE5A4JGeOeMHo6KAOc03w5pJub a/g8LQaLNbuWBEMKSngjGYiRg59fwrXGk6auoHURp9qL0jBuRCvmEem7GauUUAZY8M6AJ5Zxoene bMGEsn2SPdIG+9uOOc989ams9E0nToJYLHS7O1im/wBbHBboiv8AUAc/jV6igCtY6dY6ZB5FhZ29 pDnPlwRLGufoBTIdJ022vZL6DT7WK6l/1k6Qqsj/AFYDJq5RQBUOlacbxL02FqbmMEJP5K71B64b GRVuiigCk2jaU9xNctplm084AllMClpAOzHGT+NPudL0+88n7VYW0/2dg0Pmwq3ln1XI4P0q1RQB FDa29u0jQQRRNKxZyiBS59TjqajvtOsdTg+z39nb3cOc+XPEsi5+hGKs0UAULzQtH1GKKK+0qyuo 4ciJJ7dHEef7oI4/Co/+Ea0AXMdz/YenefDt8uX7Im5NvC4OMjGBj0xWnRQBQOh6QVuFOlWRF0wa cG3T96Qcgtx8xz61y/8AY1zqHxBurrUvDLS6RNZpaq1wbeRNyOWDFN5O304z7Cu3ooWjuD2sUrvR 9Lv7SO0vNNtLm3jIKQzQK6KRwMKRgUf2NpQs4bMabafZoGDxQ+QuyNgcgquMA57irtFAGdF4e0SC /wD7Qh0awjvNxf7Qlsgk3Hqd2M5OTU17pWm6i8T32n2t00J3RtPCrlD6jI4q3RQAgAAwBgCqceja XFqD6jHptol6/wB+5WBRI31bGT0q7RQBDPaW10YzcW8U3lOJI/MQNsYdGGeh96kdEkRo5FDowwys Mgj0NOooAqnTbBrBbA2NubRAAtuYl8sAcjC4xxTb/SNM1WNI9S061vUjOUW4hWQKfUBgcVcooAgt LK10+2W1sraG2gTO2KGMIi55OAOBStaWzXaXjW8RuUQosxQb1U9QG6ge1TUUAFURomkrLLKNLsxJ OweVxbpmRgcgscckH1q9RQBUvdJ03UljW/0+1uxEd0YnhV9h9RkcVaACqFUAADAA7UtFAHK21vqe neOtXvf7Hubmz1BLdI54ZIdqbQQxYM4bAz2BrRbwf4Xdi7+G9JZmOSTYxEk/981s0UAUtP0bStI8 z+zNMs7LzMb/ALNAse7HTO0DPU1BL4Y8PzXhvJdC02S5Z95ma0jLlvXdjOfetSigBkkMUv8ArI0f gj5lB4PUVWsdI0zS9/8AZ2nWln5hy/2eBY9x98AZq5RQBjP4b0CyY39r4ZsJLqI+YnkWkKyluvys cAH3JH1pP7d1H/oU9X/7+2n/AMfraooArWsz31pvubCW1L5DQXBjZse+xmXn61DY6HpGlyvLp+lW VnI/3nt7dIy31IHNX6KAMq68L+Hr65e5u9B024nkOXlltI3Zj7kjJp1r4Z0Cxd3tND063Z0MbNFa RoWU9VOByD6Vp0UAZ1j4e0PS7j7Rp+jWFnNgr5lvbJG2PTIGcVIdF0o6kNTOmWZvh0ujAvm9Mffx npx1q7RQBl3Hhjw/eXTXd1oWmz3Dnc00lpGzsfUkjNGvy3SaXNBaaXc3zzxPGBA8S7MrgE+Y68c9 s1qUUmrqw07O5h+G9H+z+FNGstUs4jc2UEeUkCv5UirjIPIyOeRW5RRVN3bZKVlYKKKKQwooooAK KKKACiiigAooooAKKKKACiiigAooooAKxfGf/Ij69/2Dbj/0W1bVYvjP/kR9e/7Btx/6LagAuv8A kd9L/wCwbe/+jLWue0izvtfg8QRWWs6hZWsl88UNx57yugQBSIy5OBu3E4x2AIxx0F2M+NtMGSM6 Ze8j/rpa1d0fSrfRNLh061LtHED80hBZySSSSAMkkk0Le4HJxatP4njvxaJqk0UErW1tHbu9srFT gyvONueQeFJwByCTii+j1zQNX8LST6/c3kc8y2d3C4URuxjOGGACeQTyT2roLTwxbWM1z9nvLxLS 5dpJLIOvlbmOWIO3eMnsGxyeKtajoljqkdnHcRny7KdZ4kQ7QGUEDp2GelNaW+X/AAQfX5/8A57V 72+0e9ZbC9mmn169jgtFuG3x22FO91HpgZx0J+tJfyS6H4v0S2tb+8nN4JmvluLhpEMSJnzNpO1D ux90AHPSuh1bRbbV47cSPLBNayCW3ngIDwvgjIyCDwSMEEe1NstAs7See6kMl3eXMYjmubggu6j+ HgAKO+FAGe1Jf19wHL/2zPd+GL7xlfXk9vbIrvpttDKYwFGVRnAPzsx7NkDjjvU066nbweFNIOo3 RvppEkuXEpyyRrvlLHqwJwuDxzWdrUeg6JFpPhFNZV99/GPJubhM20IPmbeAODgKN2Sd2M12d1oV vd61b6s006TQQPBsRgFdGIJB4yOVHQimrbra/wCX/B3E+z/q/wDl0OfvvErWOqeINZkeZtP0e1jg SEP8k0zfMTj15QZ9zRBbapqc2nXqXWpRSJIs11czO9vDs5JiW3JGfTLLkDncTWwPCemtaapaTGae DVJGkmR3GFJAGFwBjG0YzkjFSwaAiWgt7u/vNQ2KVjkuWTcgIxxsVQTjuQT70lp/X9dRvX+vuMYN cf8ACX3NtfahdxfbwH0uaKY+S0QALx7M7d/BO4jODweK6ueeO2t5J5mCxxqWYnsBWZB4ctoby2uJ Lm5uVsv+PSGZlKW/y7cqQoZjjjLFq0Lq1S7RElLbEkVyo6NjkA+2cH8Kb2sg9SDS4JFhe6uF23F0 3mSKf4B/Cn4DA+uT3rlvEpN78SvDGmXK5s0Sa7Ct915VGF/Fev4129Z2r6HZa1HCLpXWS3fzIJ4n KSQt6qw6fyPel1TDo0X2ZUUs7BVHUk4ArkNejvNR8ZaTpelzW9udNt3vW86BpIwT+7jG1WXsX79q 6Cz0l4Av2rVLzUShyhufLG09uI0UH15BqnpnhYabrtzrB1nUrqe6RUmS4MJRgudoAWMEYyehHvmj qHR/1/WhQ8HxvrDt4i1WQvq0fmWbwgbY7Xa+GVB15IBySTjFSeGG/tLxF4g1nqv2hbGFh02RDn/x 9m/KrLeFNmo317Y65qenm/cPNFbmExltoXcA8bEEgc4NV9M8Fvo+niwsPE+sxW4Zm2/6MxyxJJ3G EnJJJ600/wAv6/X7wf6/h/VjpVZWztYHBwcHoadVXTrGPTbCK0jkllEY5klbc7knJZj3JJJNWqQB RRRQBi+FP+QRP/2Er/8A9K5a2qxfCn/IIn/7CV//AOlctbVABWL4r/5BEH/YSsP/AErirarF8V/8 giD/ALCVh/6VxUAbVFFFABWLa/8AI8ap/wBg2z/9GXVbVYUcEVz4x1eCeJJYpNLs1eORQysDJdZB B6igDdorgfhxomlW194guYNOto54NXnhikWIbo0AHyqew5PArrtZ1ZNHs0nMLzPLMkEUa8bndgoy ew55NHbzt+IdWu36GhRWLpGvT3mr3mkX9klre2kaSsIZ/OjdHzghiqnPByCBR4m8RN4ctre4/s6a 7jmnSFnjdVEZZgozk5PXsD07UdgNaaaK3heaeVIoo1LO7sFVQOpJPQUsUsc8STQyLJHIoZHQ5DA9 CCOorJk1i5hDw3umCOWa48izjE6uLkFd248fKAA2QQfunGeKz9I1+20v7bo2oWiabJpVt9p8uOfz YzAc8o21TgYxggY460AdTUQurdrk2oniM6ruMQcbwPXHXFc0/jK6trewvLnQ5GtdUdEs/s9yjSlm GVDq+xVyPR2qpp0FvbfFvUnit47fzdJjllCqFJYyHJbHU+/tTtrZ+f5XE3pf0/Ox2tFcxfeMGsbK HWJLBTokrqn2sXH7xQzbQ/l7cbDkHO7OD0rptw27sjGM5pdLj8haa7pGjSSMERRlmY4AHqa5SXxw 0ekHXl0ozaL5nlrNHcL5zHfsDeWQFCk9y+faruoajNqlvPpVrpfnXDW6vdW9zcrEI1fICM6B/mIB 6ZGO4yKHewdTbtrmC8t0uLWeOeGQZSSJwysPUEcGpa49fHdvHpGm3Nno87RXF2LF41eNRayBtmw8 5PfGBjjqM1rQa/IPEcmi31mls5tjcwSLNvV0Bw275RtYEjjke9P+v1/IP6/Q07i8tbRolubmGEzv 5cQkkCmRv7q56n2FT1x+peI4YhY+JLnS1k0hG2xXZuMyRCQhRL5e3G08c7s4PSrUfiu/utT1XTbL QJJLnThGwSW5RPOVyeQRuA4GQCee+KLAdNUMl1bRTxwSXESSzHEcbOAznBPA78A/lXO6l4vns4dS vINLE9jpUnl3cj3HlyZCqx8tNpDABu7L7VQ16K1f4i+EL6KCNZbgXG6UIA7KIsqCepxk/nQldoO5 29FYd/r13H9sbS9OS/WwOLndceUc7dxVPlO5gCODtHPXrWhpOqW2taTbanZsWguYxIhIwQD2PuOl IC5RXO6n4ontLO71Kz05bzT7FnW5l+0bH+T75jXaQ2OQcsvIOM1MPEYvL2G20mGK8Z7ZLtzJP5X7 l87SnynceOhwPU0A9Dcorj9Y8Ra4ur+HYdOsbdYtSLs0dzcNG+VjJ2MVRgoHByM5Ixx1rrd+yHfN tQhcvhshfXnjijpcOth9FcrfeM57PQ5fEKaT52jom5ZRcBZpBnAYRlcbDwcls4/hq0niS5/4S2DQ 5dOjWK5tGuoblbgsSBgFSmwY5PqaLAdBUc88NtA89xKkMUalnkkYKqgdSSegrB0fWZPEZ1rS7/TY 7drKX7NIsdyZFlDLnIbapHB9M1DdQ23gvwNPGNOk1Kztkcva+YGVYiSSuZDyoHHc+1JuyuNK7sdC 97aRiEvdQqJyBETIB5hPTb659qnrgvE62t3deCdTSzhhllv4QpCjciGNm2BsdPau7kkSKNpJGCog LMx6ADqapq179/8AIlO9rdv8xlxcwWkJmuZ44Y16vI4VR+JqSvO/Ht8+s+B5b99Hj+xM0T2dxI4a ZcyKA+zb8gI6EMTg8gc1193q863v9m6bax3d6kImdZZ/KjjUnA3MFY5OGwAp6HOKVhmnLLHDE8sr rHGgLM7HAUDqSe1EU0VxCk0MiSxyKGR0YFWB6EEdRXOS+LIZtB1WeXSZZp9NLR32nlkJUYyTliAy Fec9x2zxWfqfiTU4tI8MT6NYWkMOqzQIYnnKeWCu4INqEBcDBOPw54P+B+If8H8DtqKhRro2Yd4Y ludmTGspKbsdN+0HGe+38KwtD8Sahqlrqsl5pdtYTadI0TQm8L5ZRnLHyxtUgggjPB6Ud/IDo6Ko 6NeXeoaVb3d7ZpZzTIH8lZTJtB5GSVXnHbFYmo+MpbK3vNRj0sS6ZYXBguJjPslyCAxSPbhlBPdg eDgertrYN1c6miueuvEWo23iyy0Y6VAbW+RnivGuyCQoBYbPL+9zwN3I7ipLjxFPZXmpfbLKJLCw RCLiO4LPK7Y2psKABuR/EfvL68IDdqFbq2e6ktUuImuIlDPEHBdQehI6gHB/KsaTxFdafqFpb6xp qWkF9KIbe4iufNAkIyEkBVdpOOMbhnvUNpryzeJdZs49AkjvLO3RzIGi8y6UltoBzjHHG5hjPQUA dLRXO+H/ABNeeILWzvYNGaK0neVJXe4XdCUJA+XHzAkdjwfUc1f1fV306Wztbe2+03d9I0cCM+xM hSxLNg4GB2BPtTasBp0Vyc/jO6h0HWL4aTG13oshS7tjdYUgKGyj7Dngjqo/CptR8WXFgugTDTY5 LfWJYoS32khoWcZHy7PmGM9xSWv4fjsJu34/hudNRUF5PJa2cs8Vs9y8allhjZQz+wLED8zXLDx5 K3hKDxOujH7Az4mBuB5kab9u5VCkN7jI/GgZ2FFYU3iKa01ywsLuwEVvqRZbacT7m3hd210x8uQO CGP4U2bxDeSRXF1pelLfWdpI8cr/AGnZI5ThvLXaQ2DkfMy8jigDZmure2aJZ7iKJpn2RB3Cl264 Gep4PAqauUvvFenzP4eni0s31tqk6C2u3KBYHIPY5YMBu6D2zVqPxLd3Ov6hotvo7rcWcKyo89wq pKGJAOV3FQdvoT7Cj+vuA6GiuctvGEVzoMV+LUR3Mt0bIW8kuFE4YqVL4+7kHnGcds8VrWF5c3Dy w3dn9mmhC7tsm9GyM5VsAkdskA9eKALtFYOo+IrjT/Fml6M9hG8GpiTZci4O5GRdxBTb9Od1VovF l5/amuafLopaXSY45VFvdK5nV8kH5wgUgDJGT3xnudLjsdPRXKr40l/sPS9cfSvL0++aNJGNx+8i MhAUhduGXJGTkH2NaN9rV2JbqHSbCO+eyx9oElx5QBI3bV+VstjBwcDkc0PTcS12Nmis/Q9ZtfEG jW2q2RbybhNwDDlT0IPuCCKzLbxReX2t6ro9torpc6eiMDcXKqsm7djld2AQPQnnkChqzsC1Vzo6 K5JfG1xL4VfxBDox8q1Li8ikuQrR7CQ+z5SHIweu3NXrjxJPLdG10awjvZUtUu3M85hTy3ztAIRs sdp4wB70Ab9FcpN46QaNo2qW2lXM8GqzJED5iL5LM23Byck9egxx1FaEGvzf8JFJot5YCGU2xubd o5t/moDgg5C7WBI4yRz1p2/r0A1YLq3uTILe4im8pzHJ5bhtjDqpx0PtRbXdteRtJa3EU6KxRmic MAw4IyO49K57QfE1lcabrF/Jpf8AZSWN3JHcJ8hd3AUsTs4LEnHU59abFrDaPryW17pAtBrLF4Gh uBJ5kyryrqVUI5AHQsDjr6oDqaK5rRvFN7rcZmg0N4o4b17W5825UNCF6twCGweMA/Qmm33jBrGy h1iSwU6JK6p9rFx+8UM20P5e3Gw5Bzuzg9KAOnqOe4gtYWmuJo4YkGWeRgqge5NOLKE3lgFAznti vP8Ax1qB1zwFqF7/AGPFLpvlF7W5kcNKGzgSCPb8qkdG3ZwegFA0rnoIIYBlIIPII70tYr6rcqFs dLs4ry7ht0lkWWcwooPCjcFY5ODgY7ckcVP4f1238Q6Wt9AjxEO0UsT43RSKcMpx702iU9EadFc8 niHUf+Ez/wCEfn0qCKFoGuI7v7WSZEBxwnl/eBIyM8A5yacviO6iuLxLvT4kSO6W1tDFcl2upCAc YKKFwDzycYb0pf1+n5jNiO8tZrqW1iuYXuIADLEsgLx56bh1GfepiQoJJAA5JNcpZaydN1fUNNuN FEeqSxG+Vba4WQXa/d4dgmCMAYI6Y5NSaf4rvtW0S31a18PSTWdxDI7AXKCRSpwF2tgEHnnPGO9D 2uHWx0dtc295bpcWs8c8MgykkThlYexHBqq2u6Ok00LatZLLAQJUNwgaMk4AYZ4ySMZrmp9dnuPh a+saFp1vZo1nK6QmXyxAgDcrtQgkYzjge9Zcs9vYeDtB1jW/C1rftaxwx20kc4cRhwoDPvVSCSRw A+DznvTtq16fiK+ifr+B6RRWZfapOl2bDTbWK7vViEzJLP5SIpOBlgrHJwccHoelYTfEGP7FaXEe kXDtLf8A9n3CiRMW024KQect6jAwe+KS1GdhUP2q2+1C1+0RfaCpfyt437RjJx1xyPzqLT7i9nWb 7dYraMkpWPbMJBInZ84GM+hHGK5Vbe3tvjI0kUMUTTaKXlZFCl280DLHucAcn0oW6X9bXDo3/W9j taK5i+8YNY2UOsSWCnRJXVPtYuP3ihm2h/L242HIOd2cHpXTAgjIOQaAFooooAKxfGf/ACI+vf8A YNuP/RbVtVi+M/8AkR9e/wCwbcf+i2oALr/keNL/AOwbef8Aoy1pmq+KBpet2ukDRtQu57tGeBrc w7XCjLcvIuMZHUD2zT7r/keNL/7Bt5/6MtaoWf8AxM/iPf3OSYtIs0tU548yQ73/APHQgoW/9f1u HQ07TxFbzX8enXdrdadezKWigulX94B12sjMpI64DZ9quHUrRdUXTDN/pbRGYR7TygOM5xjr71yv j9XuNT8LWdq2LxtWSVQv3hGikufpg8/Wr3h281K81HX2N/Ld2ttc/Z7VZ0jXDquX5RFyNzBec/d6 0dL+v6f5g/8AL9f8jpqbvXfs3DfjO3POPWua8JX2palarJeaiz3MTsmoWssKq1vLgYRdoHydwTuJ GOawY3vrTQPEfin/AISHUFzJKtvuW3I2xHanWM8Fg3A4w3rzQ9BpX/I9FrLl1qKWxv5tM8q5msHa OVJnaJQygFgW2nseoBrKLa+LKPULvVxbafBYO05SFPPdwoPmZKlR/Edu3jjOc4GbeXeq3PwwtYry 5M2pa0I7dWkCoR5zdDtAHyoT0Hahp6pf03sJNaN7fp1Or0DU5dZ0Ky1Oa1+yPdRCXyS+/YDyOcDP GO1aFclc3WpaJ4r0TS7a8Nza30ciPatEirAsaDDoVG4DOAdxbrUdt4lvLfQfEWs3dz59va3Esdli MDOxQuAB1Bk3Yzk+9N21a/rWwJPRM693SNC7sFVRksxwAKr3GpWdpeWtnPNsnvCywJtJ3lRk8gYH HrXKava6pqM/hnSJ9ZuormRfPvWgWIB/LUEsQUP8ZXj7vXjpVy01C8TxjqsUuqzy6bptmjzJLHEF WRsngqgPCrk5J+9Q9N/P8BbrQ6miuLm1nV77whc+KkvzpkMcL3NpbLEjiSMDK+aWBPzY6KVxnqad FrmpXniPRoobiWM3mmm6uLFljMcZO0KSdu8ck/xfwgd6LO9v66/5Dff+un+Z2VFYPhu8vry71n7T dG5t4L0w27FFUgKi7x8oGQGJAzk8da3qQBRRRQAUUUUAFFFFAGL4U/5BE/8A2Er/AP8ASuWtqsXw p/yCJ/8AsJX/AP6Vy1tUAFYviv8A5BEH/YSsP/SuKtqsXxX/AMgiD/sJWH/pXFQBtUUUUAFYUcy2 /jHV5nDlY9Ls2IjRnYgSXXRVBJPsBmt2sW1/5HjVP+wbZ/8Aoy6oA5rwbq6aY+uG+03WIBd6rLcQ 50m5bfG2MH5Yzjp0PNaOs63q17p/n6XZahBZpeRRTv8AZJEuWh6yNHGw3Y5UZxn72O1ddRR28rfg F9W+9/xOJ0Kwaz+Id/cwabdw2dzp8Ijmkjb94wY5LM3O7GOG+b2qx8RZJDo9pbwWd7dSm+gl22tr JNtRJFZiSoIHHr17V11FF9vL/O4rb+f+VjkPGuny6vp+l6paaSNVSyuPPk0+4i2maNkKkbHH3hkE AjPFR6KNOm0+9vtO8CnSdttIrJdWUVtJccfcABztOOS2B069uzqpqmnrqumT2LzSwrMu3zIiAy/m CPwIwaT2aK6o830zW7GFdOGoeH/GJtLErJClxp4NrasBjeCPnKjJxuLY7VtwSG6+J99KLS/Frc6W lqlz9jlETOGZjh9uMYPXOD2NdLbWWrHfFqOpWtzAwwBDZmJyPRmMjA8eij8K0gABgDAFU9d/P8dC f6+7U8w0HTbTTkh8P6p8OFur+AeWuoJYQvbzKOBI8rYwcckcn27V6co2xhcDgYwowPwp1R3EIuba WBmdVkQoWRsMMjGQexpNtoaWp5ZDqdsIWsrzwv4uNl9oaSSxtbFJLMsJC2Q33iucHAbafSr+rQ2s Wvv4im8JnxLpOq28TI0Vks89s6jGNj8hSMemCOa7DTtM1ixWO1bV7eayiQIgNltnwAAMuH2k/wDA BWrFGkMSxxjaiDAHtQB5/wCIUS30bR0sPDN1YodVhujaWmnlmjjQjc0giBUN7ZzjHvi3qEpvviLa lbLUhbPpcts1z9hmEavIVIBYrgcDr0B4ODXcUUf8H8Vb8g/r8bnmGhadaaekGgap8N1utQgHljUI 9Pha2mA4EjSt0yMEjk+3atvw/cN/wsDXWawv4obmO3jhmexljicxqwbDFcAemTz2zXaUU7vqK3Q8 58QW2p6zo/ie01DT766vl8wWEKQsYPKwNjIfuM/GTnLA9BUt9NN/wkvg2T+zdTMdlC/2iRbCVlj3 xBVyQpxz1HUd8V6DRSWg3r+P4nm97p8Gi+JtSbVfA76/bajcCe2vLeyjuXQkAFH3Y2gEZBJxzXea VAltpsMUVjFYIASttEqqIgTnGF4z644zmrlFC0VgerueZQ6ba6Hq15p+reAH1r7RdyTWuoW9jFPv R2LYkZ8bSM45Na+vaLYXnkw32kXlk1pboLK90iJ99u5yDGvl5OBx1G3ntXbUUdLB1ucLJba3G/g6 /wBVgnuJ7R5FvHiiLupeMqpZVz7ZI4B9q7G+t2vtLuLYExNcQsmT1UsMdvrVmiiXvJpgtGmjzLWr meH4QXuj3thd215p9pHBLvgYRttKgMkmNrA4zwc88it2+hntPGeh6w1tcTWn2CS1d7eFpTG7FSu4 KCQDg84wO9a3i3QrjxLoE+kwX0dmtxgSyPAZTtznAG5cHIHPP0rR0+G5t7CGG7njnmjXa0kcRjVs d9pZsfnVXu7vf/gWDokv62/yOZ8JxX0HinxK1zpd3BBd3SyxTyBQjAIowOck/QEcHmr/AI7Lt4K1 WCG3uLia4tniijt4HlZmYEDhQcD3PFdBRUNXjb5DTs7nnOr3Mklh4M8vTdVc2VzFLchdNnJiVUKt kbM9e3U9RxXb6zYtq2g31hHIYmu7d4lcjG0spGf1q/RTl7yafUmPutNdP0POdUbUr34ZtoI0W/8A 7UtY4IXhEDbGKMvzLJ91lOM8EkZ5A5rUi+2aP4sm124029NjqtnEkixxGaW1kTOFZI9xIIbqucEV 2VFNtt3GkkrHDX+nTQab4t1g2l0X1iIRW9tFC8kjBYtikooJBJJ69BjOKrNBdSeEPB8y2F6Tpd1b m6iNrIJYwqFWOwjcQCR0B45r0KihO34fgD1X3/iNRt6BtrLkZw3UVx+taVeJ4ygaxC/Zdbi8jUAT 90R/MGA75XKH6iuxOSCAcH1rI0XRr6xle51XWJdWuyCiSNAkKxoTnaFX6DJOScCkt7h0NevNPEVr qmt+GPENvf6df3OqJK4t4hC5hWIMChi/hY7RyRl8nFemUUDTscv4lsrq88M21/YW8h1DTHS6toym Hcr95MdfmXcMdeai1zQNQ1XwVJFEqrqckqXpjZuGkDh/LJ9AAFz7Cutop3/z/r8BJbf1/XU5LUt/ jC3061SwvbRoL2K4uTc27xeTsO4gMww5JGMoSOc5qpZXpt/iLrt7LYamLZ7SKOOUadOVkaPduCkJ z149e2a7iil/wfxVg/r8bnJfDZ5U8KR2lxZ3lpPDLKXjurWSI4aRmGNwAPB7ZxVrxRNqCX+lxIl3 /ZUsji+eyR2lHy/IPk+YKT1K88DoK6Oim3d3Duec2uhXj2njjTbfS5rX+0CTah49qPmLGQ3Q5bry Tk80urm+vdC8KG00XUppNPvYGuITbmN02IQw+fA/4FnafWvRaKE7fh+AW/X8Ste3Ag06a4eKYhYy THHGZH6dAq5JP0zXmERu0+Ch0c6Rq39oYMX2b+zpt2fM3Z+7jGO/Tt1r1iil3GnscH4h1D7XrfhW 4g07VXitp2mnYaZP+6UoVG75Mg57de/TFWfDbXXhiyutCvNPvZ2W4mktJoYGkS4R2LDLgbUbJIO4 gV2dFHddxLp/Xf8AzPM73Sp/D+meD9M+yXt09hfC5umtbSWdIlO8tyqnoWxjrjtWxZX3l/EfVrp7 DU1tpLKKNJ/7Pn2OyFywB288Hj16DNdpRTv+v46Ct/Xzuec6DEt74bvdN1Lw9f3Fvc6rM88FxZyR N5LszLIu4DJGB0OR6ZxW54Ls7uxkv4kuNQm0fchsf7RVlmQ871w4DbRxjcPX6nqqKFoN6nKeK7ae PxL4c1lba4ntrGWZZxbwtK6B0wG2qCSM9cA1ml72z8XeJr+TR9Ra0u7KJIpooN+WVSMbR8xJLDoD jnOMGu9oqWrq3r+I76/13ueXXEtx/wAKo0jTRpOrNewyW6yQDTpty+W6sxPy9MdD37dDVi/tLfTv El7qGoeCZfEFjqzRzQTx6es08DbApR0kAZRxnnGM16TRVN3bf9dP8iUrKxQ0a3ittMiSHTYtNjOW W0jRU8sE5wQvy59cd/XrXK6VfG3+IniK8m0/U0tpoIVim/s6crIYw27BCc9ePXtmu5opdbj6WPML WecfDLXdPbStWW8uJLryoDps+5/NZihHy9MdfTv1FaOmTXl9Nb2Wo2Gp/wBnrp0S2sAtZY0eUKRI JcgYwQMB8KeozXfUUf1+Adb/ANav/gHk8Ed7YeAvDOnS6PqhuLTUo5Zo47GV9iJKxYnap7EY9c8Z 5rpLm9L/ABMsbpbDUjbJp0kLT/2fNsDsysBnb6D8Dwea7Sind3v6v71YPL+t7nmemaZd634c8Xaa lld2097qEtzbC8tJIUlUlSvLqBglcEdcdRV/w82mz3KE/DhtIvbTDzXL6bEI4yOvluvzOeONorva KW34fgD13/q5xngMvNY6zaT2d/aNPqFxMn2m0lh3Ru3ykFlA/DqKwtB02005IfD+qfDhbq/gHlrq CWEL28yjgSPK2MHHJHJ9u1eoUULT8PwDv63+8q3tobvS57MMIzNC0QZRgLlcZFcHcJqLfC658MNp F9/alraC22LAxjkxgBkk+6wIAOAcjuK9Goo7+Y07W8jzXUrQ2etLreq+CJtZs760iRohax3NxaSJ kY2ZI2kEdD25rtvD9vBBpoNroyaPFI29bVYkjZeBywTI3HHr0xWpRTuTY5vxjZ3oSw1rSrU3N/pk 4ZYV6yxv8rpn6EH/AIDVHxR4cup/Ddh5FlBqdxp9yLua0mAKXRIbzBg8ZO4kZ9q7Kil0GcTodxpJ hn1Gy8CXOiGCNhJJJpSxzPkY2xrHl2574x/R3gq4ez+G8MF1Y6hBPaQMksD2MokyScbV25bqPu5r tKKHqmu4LRpnm+mvPb/BdtNk03Uxe/Y5bX7N/Z83meYwbHG3pyPm6e+abr08t38L9P0+30zVXu4z ao8P9mzhlMZQtwU6AA89D2r0qim3q36P7hW0S9fxPPvElpHF4ij8RXHhSTxDpt3ZpE8QshJcWzKS QRFIM4IbkcYxzUWuiKLSdI/s7wrd6dG2qwXTWtrppLpGh+Z5BECoPoM5x+Q9GooTt9/63H/X4WGR SLNEkqhgrqGAdCpwfUHBB9jXF3Beb4qlzZ34tm0prQ3Is5fK8wvuxv246d84967eil1/rtYLu39e p5foOm2mnJD4f1T4cLdX8A8tdQSwhe3mUcCR5Wxg45I5Pt2r05BtRVwBgY+UYFOop3vuAUUUUgCs Xxn/AMiPr3/YNuP/AEW1bVYvjP8A5EfXv+wbcf8AotqAI9SWdvGGnLbSRxTHS73Y8kZdVPmWvJUE E/TIqlpHhnxDo63nk6/p8r3ty1xNLJpblyzY6YnxgAADg1o3X/I8aX/2Dbz/ANGWtWb7xFoemXH2 fUNZ0+zmwG8u4ukjbB6HBOcUbMCOw0GG0vpNRuJ5b3UJFKfaZsZRM52IoACr9OTjkmqOm+FZtP0e Gx/tV3kiuWuTMsIXexdn+YEnOS3PPIHGK2bHUrDVITNp19b3kQOC9vKsig+mQTVqgNzGsNCmt7q/ v7q8SW/vo1jkkghMUahQduELMc/MeSx/CqY8IbvDGn6FPfCSK0khaVhDgTLGQ23G44yQCTk966Wi nf8Ar0AzPEWkPr2g3elpdG1NymwyhN+BkZGMjORx171BqWgzXn9ny296kVxp8hki82DzIixUrygZ TwCcYYY962qKQGVZ6J5N5NqN3cm51CaLyvP2bFiT+7GvO0Z55JJ4yTgVlR+DJk8L2minVATbSRt5 ot8Bwsgcgru6tjBOfw5IrqqKdwMkaLKPEf8Aa5vSy/ZFt/KMfzDDFiQ2cDPGRjsOagsfDKwf2wt3 dm6j1aaSSRfL2EKyhdpOTnAGAePpW7RS6W/ruF9b/wBdjmIfB8sml22j6lqn2rS7TYI7eODymlVf urK247xwPuhc45zWpaaOttrl9qrSiR7mOOKNdmPJjQH5Qc85JJ7fpWnRTbbAzPD+jf2FpYszcm4b zHkaQrt3MzFicZPc+tadFFIAooooAKKKKACiiigDF8Kf8gif/sJX/wD6Vy1tVi+FP+QRP/2Er/8A 9K5a2qACsXxX/wAgiD/sJWH/AKVxVtVi+K/+QRB/2ErD/wBK4qANqiiigArFtiB431Qngf2bZ/8A oy6rarnyYx4r1szAmMaTabwOpG+6zSbshrVl631/TbqQRxTuWYny90LqJcDJMZI+cY7rkVR8P+L7 LX3vBHBdQLbTOm6e1kjXamASXK7Qc5+UnIHUVhaPJqGiX+h2QvrfW9DvGKWE+MXFuBGxGSOHXbkZ 6803Q7y0sfCPiqW+hNxDHqF80tupwzrnkeo4pvS/o/zQlrb1X6/5HU2fibSL68W0guX86RS8Qkgk jEyjqYyygOPdSazLHx9pl0dSeW31CGGwmMbOdOnbhQCScIdvJPB5wM4rCu5Zk8S+CZZrq3RG81kt oMeXDGYePmOS3HG7gHHSr/h/5rTxjCCPMfUrgKmeTmJcUS0TfZP8Ghx1t52/X/I3Z/F2iW2nWOoy 3UgtNQKi3mFtKysW+7nC/LnP8WKhk8X2kfiw6Aba9MiQiRpFs5WXJYBcFVPy9csfl9+tcXf3VvH8 GPD5eeNQJLTJLAY2yLu/Lv6V0lrcwS/FGa4jnjeGXRImjkVwVceaeQehHI/OqtaVvNr8LkX92/kv zsddJIkUbSSOqIgLMzHAAHUk1xWt68LrxB4ebTdTvEimvhFLbmJoo5k2s24blBcZA5BK1ofERrhP B9xJAGKJLE1wFGf3IdS/Hptzn2zVDxpqWmx3vhO+e7tlt/7SDrMZAFCGNuc+nTmpjuvVFPZ+jOj1 LxFpekuVvbhkC48x1hd0iz0LsoIQe7EVoq6ugdWDIwyGByCPWvNre6sGvvEGj674un0iSS7lLW8h to45oXHysrSRknK8cNxjtXdaBaW9hoNlZ2ks0tvBEEikmILsg4BOAO3t0oW1/QHvYrR+MPD8yM8O pxzIlwtuzwqzqJGIABKgjqQM9OetVda1XTZNTsLebVri0ihufnaESLHJJ0WJ5VG0cnlSwJIAxzVX wnh9e8X+UV8z+0AMj/rkuP1zXLaR/Y+q+FToOv8AjG8sp0Yw3enTPaxv5gbPy7ot7ZPIIJJzQuny f9f12Dv80egxeJ9Jm159CSWc6gilmiNpKAF/vbiu3HvnBp8PiHTJpb6MTSRnTzi5aaCSJUP+8ygH seCeCPUVheJGTw/e6P4n/eCG3UWd8zDLGF8YZsDkq4U/iareJhdWPh/TtSlQpGdVhvNSwuSke7PP svyA+y00tvu/H/IP+H/r5nUWWvabqF29nBM63KDd5M8Lwuy/3lVwCy+4yKjvvEukabKY7u6MYVgs kgido4icYDyAFUPI+8R1rK8SRG98SeGJbB1aeK5eVmQ5/ceWdx47E7R9SKyvCfiHRLfRrzQ/Ed9Z wX0N5Ol1b3zqvnbpGYEBvvAgihB/X5/5HXajr+m6WwW5mkLlPM2QQSTME/vEIpIX3PFZ+t+MdP0n TrC9iWW8i1CaOOGS3heVCGIGcqD2zgdT2FUZLyK58T6hDYpHp0sOnxNdXcw+dozuKKik7Vxk5Yg+ mPTltOlDfDLwlucEx6tb7unA85gCaErteq/F2B6fc/yudyNX0e98R2MSatcR33kuU0/5496kA7pI yAQQBxux196uX/iLS9MkZLq4ceXjzWjheRYc85kZVIQY5yxFYOsSI/xQ8NbXVv8ARbvofZaf4Nuw sOu2WpuqXkGoTyXCyYH7tjlG9124APtil0+/87B1+78jbu/Eei2MtpFc6nbxve4+zrvyZQe4x29+ lSWWtWGoXc9pbzN9ot8GSKSJ42APRgGAypx1GR7155b28tj4b8Gw3LbV/tzdArnBERMhTr/skfmK 6UOo+LjIGAY6KMjPJ/fU7a29fwVxPT8PzsdRcXENpbyXFzKkMMSlnkc4VQO5Ncbfa6ZfHOiG11C/ FpKlx59m8Dxg7IyQwQoHbOTjqDgYq58QJpbbT9MuDxZQ6pbvesRwsQbqfYNtNVvEt9YweP8AwnNN cwRhhcKHZwM7kAXn3PT1NJb/AIfgN/obKeMNDk0ObWkupWsbeRo5ZBay5jZfvZXbuGO5xgVq2t1D e2kN3bvvhnQSRtgjcpGQcHnpXnVi6wfDrxlFK6o63d+CpPIJzgfjXY+Drm3u/CGlPbTxzItpGhaN wwDBQCOO4PGKa1V/T8UJ6P7/AMGTah4j0rS5GS8uWQIQJXWF3SHOMeY6gqnUfeIqe91ey0+FJZpH YSLuRYInmd145CoCSORyB3rj/DPiLR7GLWNF8R39pa3keoTmWO+kVBMjsSpG7hgVIH4VHqeoQWPj dGu9duNBsrzTYhZyqkKxkqzFkJlRgpwVPb+VLovP/K5Xfy/zsdTJ4s0CGztbuTVbdYbx9lud3MjZ wQB1yCcHjjvVDWPHel6YiiJbm5k+2JaOsdpKQjNg8/Lz8pyAM7u2a5nV7DSdP8Hn+zNUk1K2utct 5nuJZI3R3aVS+0ooXHHOB1zXReP+LPRmPCrrNqSew+amlqvVL8v8xd/Rv8/8i4NX0e98R2MSatcR 33kuU0/5496kA7pIyoIIA43Y6+9YkmvReIvFeo6I82rWcFvDEIJLeC4hZZW3ZdyFGF4GN/ynB61Z 1iRH+KHhra6t/ot30PstLobKfih4nAYEi2tMgH/Zakle3z/ML7/L9C94SurGa0u2tvEUutukgFzc O+UV9gyEA4VeM4BPJPNXrfxJpNzfx2Md0RNMCYd8Los4AyfLdgFfj+6TXDSx3VxovxDjsNzzm8bC pyWAjXcB7kAiup0vxT4X1y3sJLa8srm5wGhtwytPE2MHCfeUgE5Ppmne+vkvxQPT8fwLreKNGW8W 1a7IZ5fJWTyX8kyZxs83GzdkYxnNVpPF9pH4sOgG2vTIkIkaRbOVlyWAXBVT8vXLH5ffrXFavdrd +BrK9szFYWMmqxNb2S/M5P2j5i7MSc5+baAMeprp4ZYx8VrlzIoVtGjw2eD++ahLVX8/yuJ9fl+d jrWZUUsxCqBkkngVxHiXxAtzfaE+lardxpJqUMUkaxmOK4jY5LBmUFxwBlWK889a0/iGLs+BtT+x KzP5YLqoyTHuG/j/AHc1leNtS0w6f4YvxdW4tf7Vt5Um3gKEwctnsORmhbp+a/Mb+F+j/I6Mxawv ihZUvg+ltBh7VrcDy37MJM5JPp0AFT63d3NppkhsVV72X93bK/QyHpn2HU+wNX1ZXUMrBlYZBByC KwLo3+rayW0m+soU00mNzcWzTgysATjbImCqkDv98+lJq+gJ9R/g3W5Nf8M215c4F4mYbpcY2yod rcduRn8aqrrd5r/iO/0fSbgWltpu1Lu7CB5DIwOEjDZUY7kg+mKytCe48MeP7zSdTu7Z011Ptlu0 MRhTzh8rqFLMckYPXmm+E1Xwz4z8QaTqLCFtTuvttlI5ws6nO5VP95T1HWnu791+P9X+4Wya/q39 WOk+z63Y3tiqaib+zMjC6NxCgmA2naQUCrjOMjbnpz1rTvbyDT7Ka8un8uCBDJI20ttUDJOByfwp z3EaTLBu3StyEHUD1PoPelnnhtYHnuJUhhjUs8kjBVUDuSegpPYa3CCaO5gjnibdHIodGxjIIyKp XOu6baXLwTzsjRjMj+U5jj9mcDapORgE5ORxV6KWOeJZYpFkjcBldDkMD0IPeuC1trzSn1vWdEv7 a7s0lJ1TSbsfxBQCUccqSuMA8H9KOtg6HTXF/pT+K7SzOsSLqEcT4sI5flcEA7nUDqAOCcda2WYK pZiAAMkntXG6pKJfiX4XfBUvZXTbW6jKrWp46iu5vBOrR2IZpzbNhU6sP4gPcjIoekbvz/NhH3pW 9C3b+JNJub+OxjuiJpgTDvhdFnAGT5bsAr8f3SaLnxJpNneLa3F0Y2aQRCQxOYg56KZMbA3sTms7 TPFHhjXbewa0vbG4uyoaCDcjTxMRg/J95cAnJ9M1x2lHSNW8MyaDr/jG6sp0kaK70+RraJt4cn5d 0W9snBBBJ5607a2BO6udpP4xs4PFL6G1tfF44PNeSOymkGSwAxtU8dfm6ds9ad4e8XWfiGS8WKC7 hFvM8Yaa1lRcLgEliu0HOflznHUVnWZWD4nSB3ZR/YcQBmIDHEp6+/rWPbrcSeAfF0FoWNydQvcR py7DcCQB64/nS2WvZ/nYN381+Kudra+I9KvNQWwiuWFw6l41khdBMo6mNmADj3UmtJ3SNGd2Cooy zMcAD1rgrB/D/iK60e8Txpd6jcW0qzW1pvtlkDYwQyJEr4wTn2rd8erct4M1A2nmb0VXYRKCxQMC +AcgnaD1BoeiCOrL1t4k0q7vHtIp5PPWMyCN7eRDIg6sm5R5g91z2qpb+NtAutPvb+G6na309tly xspwY29MFMkjvgcd8Viad/wj+vatpOpReMrnVru1YyW1uHtg6hhhtyJGrAY65xUesbNL1p/FVsvm aI0ipqUaNkSMpKicD/YOAfXGcfKMu3cPQ2tQ8a2Njq2m2H2a/f7dG0oZbCZiEC5+6F3E5IyMcd8V o6j4h0zShm8nkQABnKQSSCJT0Z9qnYODy2BWHq88MnxA8L3CSo0L212VkDfKwKoeD9Kx0vrOLxD4 h07WPFk+ivNc+akbG3SOeFo1ClWljbPAI4bt0pf8H8wOzm8TaJb31tZSanbi5uk3wxBtxdcEhuOx AOD3qWy1vTr8XRguCDZti4WaNomi4zllcAgY5z0Ncb9ksdM1fwNYWN1LPaxPcrBJO6lnTyzg5AAI 9CB0xUs5sX8XeMYr9yto2mQfaNjYIXa4Y/UA02u3mC6X8vzsdTF4i0qVXY3RhCI0h+0RvD8i9XG8 DK8j5hx71BoN/pX9hPe2msSX1kkkrNd3Mu7HzEsNxA+UdB2wKxdFn1jS/EVjpOpXdrrFpcW0j2V/ GuyZFXGQ4HBBG0bh1IrnLSWeP4Y/aYctbwa2011sG4+StwSxwOo6E+2aNL/13sC2/rsei2niDTL2 9NlFO6XG0ssU8Lws6jqybwN491yKrp4w0CW3ubi31AXUdq22Y20bzbfU4QEkDPJHA71m+KkGpX/h iTTpUeddQWdHQ5/c7G8w5H8JBA9ORUHh14zqfjT5lIF783PbyV6/rUvRN9r/AIW/z/Aa3Xnb9f8A I663uIbu2jubeVZYZVDo6HIYHoRWavirRJJruCC/W5lsv9fHbI0zJ14wgJJ4OQMkd6o/Dpw/w/0Y ht3+jAZznoTVfRHQ/EfxQAykiG0yM8j5WqpK0mvUmLvG5sXV02seHXudD1MQGePMF3HB523n+4ep 6jB6VNb3Utlo1vNrMsa3AjUTFF4aQ9lAzkk9hmsL4aureERsYFVvLkDB4A85qi8fXJsLjQr6a+ns LGK8YXF1AisYS0bKrHcrLjJxkjvQ9PmP9Lm/Z+IdKvre4nhutq2pxOs0bRPF/vI4DD2yOaSPxBp8 tvLLG1wWhjMrwm1kWYL0z5ZUNz2457VyMlh4auxqeoHxZc6k11bxwXNzHPblYAHHlsfLRQCGOeew NaOjXWt22uzaNrclrqLixMtvqNumxmTIG2ROgJPIxwcGk9gX9fgavhfxNb+J9NW8gguYd2TiW3kR du4gYZgFY4HO0nFWLjxHo9rqq6VLfxC+Zdwt1yz4xnoM/h69qyfhq6HwDpKBhuETZXPI+dqr67LH F8UPDHmOqbra6Vdxxk4Xge9Nr3rIV9Lm/Z+IdJvrS5uobwLHaEi485GiaHAyd6uAV455FJYeIdM1 K8azt5pBcKm/ypoJIWZM43KHUbl9xkVxniCS1t9c8T6pNai905bC3tbiFXKrJNvOAzDptBXJ7A1a d54vidoxvL+GV20243JEoWOIZUgDJJ545J5xwBQtbf10YPS/9dv8zq49e02W6Nss7B9/lqzROqSN /dRyNrkYOdpOMHNT6jqVjpFm95qN1Fa26Y3SSttAz0rh7KW+0Q6bJY3kGr+Hb28VIoJBi4s2ZuAr D74U5yDyB9K6zxX/AMijrH/XjN/6AamTtHmLirzURsXivRJZLNVvCBfBTbSNDIschIyFDldu7/Zz n2psnjDw/Gbwf2lHJ9hKi58lWk8okkc7Qe4OfTviuU1BF1H4P6RZ2sqNdXMVpHa7Tk+aCnTHcYJP pg1r6CVPxH8TDcrOsFoCR1+61aOKUmu1/wBCE7xuXPE+qaetqLSfVbiyTzEa4ntVkzEmQcNIgIj3 cDLEcE1qXOr2Nj5CSSyOZgDGIYnmJX+8doJC/wC0ePeuAtLix+069o+veLbnR5pLyYyW8rW0aSxO flZWkjJIK4H3uMdq0jpD276fF4X1w2+o2OnhYkv1DpeW+47d2MEYIzuUcAjjmoW39dv6/HQp72/r f+vw1Otl1nT4rKO8+0ebDLnyjCjStL/uKoJboegNU5PF/h+HShqk2qQxWpcx7pMq28dU2Ebt3+zj PtXFHXTJqOg6nqN9N4dtbm0uIPOtxG0SziUZG6RGUKwXIOB0607XrTSLXwL4nvNN1yXVhemOSe4a WJ4/M3AYUxqq5xjI+lO39fOwlq0jvI9e02XUU09bg/aJULxBonCygddjEbWx3AJIqho/i601jWb7 Tora9jNpL5QaSzlVSQuSSxXC9eAxBP4is/xG6L4o8GkOoJuZQOeoMJ/+tVSxE7v47gtH23clyywj PJY267cflSeib7J/mv8AMFrbzt+v+R06eJNJfUI7AXRE0xIiLQuscpHUJIRsY+wJNaleZ6W/h/xF o+kxXHjG8kntnikj00taxzJMnRQgiD8HI69O/evRoby1uJpoIbmKWWAhZURwWjJGQGA6cetNqwk7 k1YvjP8A5EfXv+wbcf8Aotq2qxfGf/Ij69/2Dbj/ANFtSGF1/wAjxpf/AGDbz/0Za1i6xeW8nxGs mnhmli0ayeZjBbSTsskpCqNqAn7qsela2oyPD4w06SOB52XS70iKMqGc+ZbcDcQM/UiqXg+21VdV 1u/1fSJrGe/uQ6M8sTr5SqFRfkcnI5J4xz1oW/8AXoD2Io3Mfie88W3aPpmlQaeIWNwnlvcHdu3s vUADgBhnJPFXLjxVcWa2V5eaUYNNvZUhSVp/3yM5wpaLbgA8fxEjPIqbxlo91rmgG1tNrSJPFN5T NtEoRwxTPbOPzqtd6ZqHibUdOlv7NtP06wlFz9nldGlmlXO3OwsoUdepJ46U10X9W3YPq/67Ic9z /aHjb7DPpcDvplubmC6W7fKF/lAZNgAJw3dsAZqFPGVwfDmoaq2mQmSxaYNHHdkxsIyQTvKA8kEA be1P0ux1a0vfEepy2A+1XUx+zDzV/eRogEQHPGTuJzjGaqt4Yu7XwVp2h20XmvJPC+oEuMsNweUk k85Ix34NJbL5fj/l1B7/ANdP8+ha17V9b+3aPYaVa226/wAyyia5aN1RAGYcI2ByF3cnnGO4tHxF cyatf2NtpvnjT1TzsTbZGZlyNiFcMv8AtEjocA0w2Wot4wm1B7QNBDYLFayb12hixMgxnOThB0xg daqjTtXu9c0i9msvst7ZLsvr1ZEMdzGVOUUA7j8+D8yrjnFNAdVS0UUgCiiigAooooAKKKKACiii gAooooAKKKKAMXwp/wAgif8A7CV//wClctbVYvhT/kET/wDYSv8A/wBK5a2qACsXxX/yCIP+wlYf +lcVbVYviv8A5BEH/YSsP/SuKgDaooooAKxLdVfxrqqsAynTLMEEZBHmXVbdYtr/AMjxqn/YNs// AEZdUAaEOmafbXct5BY20VzMAJJkiVXfHTLAZNOTT7KKeeeOzgSW5x50ixgNLgYG44549aji1jS5 799Ph1K0kvI+Xt0nUyL9VByKxLHVNVPxEvtHubqKSyjsVuIUSHYVLPjBOSScDrwOelG7SB6K5sw6 HpFvFFFDpdlFHBJ5sSJboBG/95QBwfcVPHY2kV3Ldx2sKXMwAkmWMB3A6At1OKjk1bTYb9LCXULV LyQZS3aZRI30XOTUk17aWziOe6hidgWCvIFJAGSefQA0AQJomkxrIsel2aCWQSyBbdBvcHIY8cn3 61NJY2ctzDcy2kDzwAiKVowWjB67T1H4VF/bOl7bZv7StMXn/HsfPX99/uc/N+FXFZXUMpDKRkEH INAAQCCCMg9qpQaJpNr/AMe+l2cOJDL+7t0X5yMFuB1x3rF8Parqtz4w8QaZqF1FPDY+QYBHD5YU OGbnkknoM57dBWjoV3q9y16mrRWY8mcrBLaMxR07A7v4h0OOM/SgH2Ld3pOm6hPFPe6da3MsBzFJ NCrtGf8AZJHH4VbIBGCMj0qpBq2mXVzNbW+o2s09vzNFHMrNH/vAHI/GoIfE2gXEM08GuadLFbgN NIl3Gyxg8AsQePxoAdY+H9F0y4Nxp+j2FnMVKmS3tkjYg9sgZxUsmkaZLqCahJp1q94gwlw0KmRR 7NjIrO1Hxn4f0w2Pn6raYv2/cv567CvOX3Zxt46+vFaFzrGl2VrFdXepWlvbzY8uWWdVR88jBJwa ALU0MVxEYpo0ljbqrqCD+BpzKrqVZQykYIIyCKiku7aIRGS4iQTECPc4G8noB60y11GxvmlWzvLe 5MLbJRDKr+W3ocHg+xoAbYaVp2lq6adYWtmsh3OLeFYwx9TgDJol0rTp76O+msLWS7iGEneFTIn0 YjIpbXU7C+aRbS+trhonMbiKVXKMOqnB4PtUOlu7G736rHqGLhtojVR9nGARGdvUgHOTzzQBPNpt hcXkV5NZW8tzACIp3iUvHnrtYjI/Cmf2Rpn2F7H+zrT7JISz2/kL5bEnJJXGDzzS2+rabeXUtpa6 haz3EP8ArIoplZ0+oByKS41fTLVJnudRtYUgIErSTKojz03ZPGcd6AIpfD2iT3iXk2j2ElzHt2TP bIXXb93DEZGO3pUt1pGmX1zFc3enWtxPDzFLLCrsn0JGR+FWkdJEWSNg6MMqynII9RUE+o2Nrcw2 txe28M8+fKiklVXkx12gnJ/CgCHUND0jVnSTUtKsr14xhGuLdJCo9BuBxTU8P6JHfjUE0ewW8ByL hbZBIDjGd2M9Klj1fTJr9rCLUbR7xF3tbrOpkC4ByVznGCPzqEarYanp902mazaMY1KG4hlSVYGx wTzjjrg0bBuaDosiMjqGVhgqwyCKqWujaVZCMWmmWduIiTGIoFTZnGcYHGcDP0qqNf0jTbO0TUvE OnmWWFWWaWeOL7QMffUZxg+3FXJNW02G/isJdQtUvJhujt2mUSOOeQucnofyp2sw6CPo+mSzzXEm nWjzXCeXNI0ClpF/uscZI9jVqONIoxHGioi8BVGAPwqrb6vpl1eSWVtqNpNdRf6yCOdWdPqoORRc avplqkz3Oo2sKQECVpJlUR56bsnjOO9IBZ9K066u4ry4sLWa5h/1c0kKs6fRiMinX2n2Op2/2fUL O3u4Sc+XPEsi59cEYqhrfinR9At7aa+voIxdSKkOZAN+SBuz/dAOSemKtyazpUOnpqMupWkdk+Ct y06iNs9MNnBo6AMu9A0W/ihivNIsbmOAYhSa2RxGPRQRx0HSpn02wk08ae9jbtZhQgtmiUxhR0G3 GMVPFLFPEs0MiSRuMq6MCGHqCOtQ32oWem25nvry3tIs7fMnkCLk9BkkUAivL4e0Se8S8m0awkuY 9uyZ7ZC67fu4YjIx29KZD4Y8P210LqDQtNiuFbcJUtI1cH1yBnNZ3hDVdR1CXWotTu4bk2V8YY5I ohGmzYp4GT6nqTW1Z6rp2ovLHY6ha3TwnbIsEyuUPocHij+vvAisNB0bSpmm07SbGzlcbWe3t0jZ h6EgDipbbStOsriW4tLC2t5pzmWSKFVaT/eIGT+NVlvIrS91G4u9bt2tokRzbtsX7IoByWbOTuIP X04pugeJdK8S2pn0y8hmwTujSQF0GSAWXqucZ5oAnOh6QVuFOlWRF0wacG3T96Qcgtx8xz61PJYW ctzDcyWkDz24IhlaMFoweu09R+Fc/rOq6rZeOdBsIrqIafqHnCSEQ/PlEJ5ck8ZI4AHTqc1om71d fFC2vlWcmlvBu3IzefG47t/DtPQd+vpQugM1qpRaHpEBYw6VZRlpPNJS3QZfkbuB15PPXms7V7+a HV7aOLWrSzcEbLCV4w17/eHzfMMDpt79eKkuvF+h2evR6LcalbRXbRl2WSZV2nIAU5P3jngdeKED NogEYIyD2qlYaHpGlSPJpul2Vk8gw7W9ukZYe5UDNPfVdNibbJqFqjeYIsNMoO89F69T6daJtV06 2vYrKfULWK6m/wBXA8yq7/RScmgCvd+G9B1C6a6vdE065uGxulmtUdzjpyRmrd3YWeoWxtr20guY D1imjDqfwPFWKKPICtY6dY6ZB5FhZ29pDnPlwRLGufoBT7u2jvLWS3ljiljlXayTR70YehXuKmoo 3Ar2NlBp1lFaWsaxwxDCIqhQB7AcD6CmS6Vp09zFczafayTwkmOV4VLIT1IJGRmrdFHmBn3GgaNd 3y39zpFjNdqQVuJLZGkBHQ7iM8dq0KKKAKltpWnWVxLcWlhbW805zLJFCqtJ/vEDJ/Gkk0jTJtQT UJdOtXvIxhLhoVMij2bGRVyigCCWxtJ7qK6ltYZLiDPlSvGC8eeu09Rn2oisbSC5muYbWGOefHmy pGA0mOm4jk/jU9FAFO20nTbO6lu7XT7WC4m/1s0UKq7/AFIGT+NXKKKAKVto2l2Uk0lrptpA9x/r migVTJ/vEDn8ajHh3Q1086eNGsBZs+824tU8st67cYz71o0UAUV0XSUt4LZNMs1gtn8yCIQKFib+ 8oxgHk8in3ulabqLxPfafa3TQndG08KuUPqMjirdFAGfd6BouoXKXV7pFjczoAFlmtkd1A6AEjIx SReHtDt7x7yHRrCK5fJaZLZA7Z65YDJz3rRooApJo2lxi5CabaKLsEXAWBR52eu/j5vxosNG0rSk kTTtMs7NZceYLeBYw/1wBnrV2igCpZaTpummQ2Gn2tp5p3SeRCqbz6nA5qonhXw5GJQmgaYomXbK Fs4xvGQcHjkZAPPpWtRQBVsNM0/SoDBp1jbWcTNuMdvEsak+uABzxVUeGdAE8s40PTvNmDCWT7JH ukDfe3HHOe+etalFAFPT9I0zSUdNN060slkILi2gWMMffaBmrMsMVxE0M0aSRuMMjqCGHoQetPoo Aq2ul6dY2v2WzsLa2t87vKhhVEznOcAY60tnpthpwkFjZW9qJW3uIIlTe3qcDk+9WaKAILWxtLIS C0tYbcSuZJPKjCb2PVjjqfeuS1/Tb/UvHel3D+HpbzS7WGaCeR3gKP5gXnYz5KjHORn0BrtKKOtw 6FaLT7KCy+ww2cEdrt2+QkSiPHptxjFRw6Ppdv8AZ/I020i+y58jZAo8rPXbgfLn2q7RQBUj0rTo rz7bHp9ql0E2eesKh9v93djOPaqfipLyfwzf2tjYy3txcwPCkcbouCykZJdgMD8/ateik1dWGnZ3 Od8H6LDYaLYyXWiRWOqRWyQTSMkRlbaoGd6E5Bxxz+FaNv4e0S0vjfW2j2EF2SSZ47ZFkyep3AZ5 zWjRVN3dyUrKxTu9I0y/ninvdOtbmWE5ikmhV2jP+ySOPwp15pmn6jGY76xtrpDjKzxK4OOnBHbN WqKQyvcWNneWhtLq0gntiMGGWMMhHptPFV5tB0a5sorGfSbGW1hOY4HtkaND04UjArQooAym8LeH XMRfQdMYwKFiJs4z5YByAvHAySeKvLY2iXj3q2sK3TqEecRgOyjoC3Uj2qeigCnHpGmRag+oR6da peSDD3KwqJG+rYyaba6RaWupXOoR28EdxcgCR4oghcDpuI5Y+5/Sr1FABWL4z/5EfXv+wbcf+i2r arF8Z/8AIj69/wBg24/9FtQAXX/I8aX/ANg28/8ARlrW1WLdf8jxpf8A2Dbz/wBGWtbVABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBi+FP+QRP/ANhK/wD/AErlrarF8Kf8 gif/ALCV/wD+lctbVABWL4r/AOQRB/2ErD/0rirarF8V/wDIIg/7CVh/6VxUAbVFFFABWAZYoPFm tTTOUij0m0Z2HVQJLrJrfrEt1V/GurI6hlbTLMEHoR5l1SeqGtzi7tnj07wVNaQCHT11OFbUzNvu JEZW+dyMBSeSQM5yMkdK3FZ0+K2ptEu6QaJGVX1PmNgVrp4O0FLaC3Fk3lW0wmgBuJD5LA5Gwlsq P9kYHtUsPhbSLfWzrUUM63zLsMn2ubaV7Ls3bdo7LjA9Kp6/j+KsS/8AL8Hc5vSI7TWvhJK975bS S280ty7DBWcFiWOejBh17YqpZW7TeJvBN5qFug1CfTZjcyFAHkYRpjce+Mng9M12B8MaOb2W7Fqy vM26WNZnWKVv7zRA7GPuQTSXvhbSdQ1eHVrmO5N5AMRSJeTIIx3AVXAAPfjnvmi+t/62f+f4A9rf 10/yMLV7LUtK1O6vdAsrLUbP7MkN5pTfumVRuYGM428hjkEc10fh+7tb7w9p9zZI6W0luhiWT7yr jgH3pLzQNNvrhriaBxNIAJJIpniaRR0VipG5eT8pyOTxV6GGK3gSCCNY4o1CoiDAUDoAKS2G9zk/ Dv8AyUnxb/u2n/os1p+Nrm5tPBmq3FoxWaO2YhlzlR3Ix6DNT2PhjStN1a41W1iuFvLr/XSNdzOJ PTKsxBx2447YrUZVdSjqGVhggjIIoeyQ7+9c4yLRbrUptC1oa9pYtrF1MDWOnsnmow2+XuMzcHPp 1qrrtvFomvXN9FEToF+yx62qqNqP2f6HID+xHvjoNL8D+GdF1KTUtO0iG3unz+8Usdueu0E4X/gO KnHhTSBo9xpBiuWsrpi80bXszFiTk/MX3AE9QDg5OetO/UlLoZfinZ/b3hHy9uz+0G27emPJfGKq ibUb3x1rWnx6hptvIsMQihvLNp2khK8lcSpxuzkYPat9fC2jpptppwtpPs9lIJLbNzKXiYdNr7tw 9MZxjjpUeueDvD3iNIV1bS4rjyBiNssjKPTKkHHt0pOw/wCvxOOvfDdvo1r4UsZ54dRlttZEIuPs +wrGQ7eWMljtHHGe3tWvfpEvxEv42mNtDN4fPmyJwVAkI3fUAmtm98HaDfxWUM1m6RWGDaxwXMsK xEdCAjAZ9+tLJ4P0SXVX1SWC4e7kiMLu15MQ0ZGChXfjb7YxnnrRvv5/irB/wPwdzC0mfUdP1rTN G8R6bbTExPDY6naH5JlC5KOh5UlVB9CRWDbySaR4G8af2XCsKw6tMgWFdoiiygbAHTC56V6JbeH9 MtLjz4IHVwpSPMzssKkYIjUnEYx/dAqLSfC+kaJ9pFjBKq3ZLTrLcyzLIx6kh2Iye56mnfVvy/VM Fol6/oYvjK3jGg6Re6SkYuba8tvsTRAD5WYKVGP4SpOR0xUfhews4PFvi+OG0hiQTQgKkYUDdEC3 A9TyfWuh0/w3pOmSK9pbuojOYkeeR0h6/wCrRmKp1P3QKrweD9Ftrq8uoY7uOa/GLl11C4zJ/wCP 8EdiOg6Un187/p/kC6fL9f8AMpfDVmbwDpm4k7VdRnsA7AD8hVPX01ax1LU9R0+1tta0+WJY9Q0+ Rtk0e1f4CeCCrZ2nv0rpNE0HTvDtl9i0uGSG33FhG08kgUnrjexx9BTbvw9pd9PJPNbv5kpBlMcz x+aAMAPtI3rj+E5HtRLV3COhzFtPb3nxB8PXlqreRPocjRlxhiuUIz74NZ5tba5tfiLHPbxSospc K6BgGEAIOD3B5z613N5oOm38lpJNblZLI/6O8MjRNGMYIBQg7eOnQ+lU5vBXh2Y3jNpiI98NtxJF I8byLxldykEKcDKg4PpRLVNeT/F3COjT9PwVjAm0x734XaLe2sQe+0u2t7224ySyKCV/EZH41qR6 np2sW9z4iaUjT7exZUmT7yhlDyEe4AUfUEVuaZpdpo+nx2Fkki20YwiSTPLtHoC5Jx7dKLTSbCx0 3+zba0jjs8MvkgZUhiSevrk05vmcrdf1FHS1+hwUwlhuPArw2yWtktyI7ZHO6cxmE4LkYAJHVRnn HPatTwvYWcHi7xfHDaQxIJoQFSMKBuiBbgep5PrW2nhDQkitYhZsVspPMti9xIxiPTCktkLz937v tTbfwdolpc3lxbxXcUt8MXDrf3AL/wDj/BHQEdBwKJa387/jYF0+X6nEWjM3w38JbiTt1iBRnsBM wA/IV0F/c6hJ8RnsYdQsbQnTka1W8tWm8zLt5mzEiYPC568AVr2/g3QbXRjo8NnILLzBKsRuZW8t wcgoxbKHPPykc1JrPhTQvENnHaarp0dzFEcoWZgy+uGBDc9+ee9Df53+9JD/AK/G5B4R0STw/Z3d jJqMd5m6eYLFAYkg3/NsUbm4yc9e9VbO4a5+JepW90qn7JYQmzDdlct5jL9SFBPsK39N0yx0exjs dOto7a2iHyRxjAH+J96h1DQ9O1S4gubqBvtFvnypopXikUHqNyEHB7jODR1Do/663PObiUaZp3iS OFVjtG8Rwx3X91IG8vfn/ZPT6Gup8W27Rav4avdPRVu11BYMpgFoGVi6+64GfwrYg8L6FbPePFpd sGvgVuWKbjKD1Bz29ulSafoOnaW4a1ikyoIQyzyS+WD1Cb2OwcDhcChOyXlb8El+n4g9b+d/x/r8 DmPDltb2nj3xjFbQRwRlLZtsaBRkoxJwO5JJrQ+G3/JPtI/65H/0I1o2PhjSdO1a41W1iuFu7r/X u93M4k9MqzEHHbjjtirOmaPYaNC0OnweTGzFtm9mC5OSFBJ2jJ6DA9qS2+78Aeruc74m/wCSheEP 966/9FV2FZOoeGNK1PVbfVLuK4a7tf8AUyJdzRiP1wqsAM9+Oe9a1HSwPc8403T9S8WaHrOnSatp sLSXk6XUclg0k8RDnad3nKOFC7Tt4AFaVijJ8Q9NjkuftbLoBVp9u3zcSL82OevWtbUvA3hjV9VX VL/R4J7tcfvDkbv94A4b8Qa0LrRdOvL63vZrfNxboyRursnynqpwQGX2ORTWlv66NfqD1v8A11TO Z8IaVpy6x4ot1sbcQR6mhSLyl2KRGjAhcYHPP1rL0zT9R8X+GdSsZNZ02Fnu5lulawaSeCQSHBL+ cBkADadowAPSuy0rwvpOi3k93YR3KTXJzMZLyaUSH1IdyCeOuM1Xv/A3hjVNXXVr3Rrea8U58w5A Y+rKDhj9QaXZeQd/U19PDLp1sHuPtLCJQZtu3zDj72O2etWKqNpdk2qx6oYf9LjhMKSbjwhOSMZx 1HpRYaXZ6WJxZw+ULiZp5fmLbnbqeTx9BxTbu7iSsrFuiiikMKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKxfGf8AyI+vf9g24/8ARbVtVi+M/wDkR9e/7Btx/wCi2oArazpmn6r4x0mDUbG2vYl0 +8cR3ESyKG8y2GcMDzgnn3qz/wAIZ4V/6FrSP/AGL/4mi6/5HjS/+wbef+jLWtqgDF/4Qzwr/wBC 1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJraooAxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi /wDia2qKAMX/AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JraooAxf+EM8K/9C1pH/gDF /wDE0f8ACGeFf+ha0j/wBi/+JraooAxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8Aia2q KAMX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAAYv8A4mtqigDF/wCEM8K/9C1pH/gDF/8AE0f8 IZ4V/wCha0j/AMAYv/ia2qKAMX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/ia2qKAMX/hD PCv/AELWkf8AgDF/8TR/whnhX/oWtI/8AYv/AImtqigDF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWt I/8AAGL/AOJraooA4/w14T8Nz6XM83h7S5GGoXqBnsoyQq3MqqOR0AAAHYAVrf8ACGeFf+ha0j/w Bi/+Jo8Kf8gif/sJX/8A6Vy1tUAYv/CGeFf+ha0j/wAAYv8A4msnxL4T8NwaXC8Ph7S42OoWSFks owSrXMSsOB0IJBHcE12FYviv/kEQf9hKw/8ASuKgA/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8A AGL/AOJraooAxf8AhDPCv/QtaR/4Axf/ABNZNt4T8Nt4x1KA+HtLMSafaOsZso9qsZLgEgY4JCrk +w9K7CsW1/5HjVP+wbZ/+jLqgA/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJraooAxf+ EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi/wDia2qKAMX/AIQzwr/0LWkf+AMX/wATR/whnhX/ AKFrSP8AwBi/+JraooAxf+EM8K/9C1pH/gDF/wDE0f8ACGeFf+ha0j/wBi/+JraooAxf+EM8K/8A QtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8Aia2qKAMX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAA Yv8A4mtqigDF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/ia2qKAMX/hDPCv/QtaR/4A xf8AxNH/AAhnhX/oWtI/8AYv/ia2qKAMX/hDPCv/AELWkf8AgDF/8TR/whnhX/oWtI/8AYv/AImt qigDF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8AAGL/AOJraooAxf8AhDPCv/QtaR/4Axf/ABNH /CGeFf8AoWtI/wDAGL/4mtqigDF/4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/6FrSP/AGL/4mtqigDF/4 Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJraooAxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6F rSP/AABi/wDia2qKAMX/AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JraooAxf+EM8K/9 C1pH/gDF/wDE0f8ACGeFf+ha0j/wBi/+JraooAxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wB i/8Aia2qKAMX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAAYv8A4mtqigDF/wCEM8K/9C1pH/gD F/8AE0f8IZ4V/wCha0j/AMAYv/ia2qKAMX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/ia2 qKAMX/hDPCv/AELWkf8AgDF/8TR/whnhX/oWtI/8AYv/AImtqigDF/4Qzwr/ANC1pH/gDF/8TR/w hnhX/oWtI/8AAGL/AOJraooAxf8AhDPCv/QtaR/4Axf/ABNH/CGeFf8AoWtI/wDAGL/4mtqigDF/ 4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/6FrSP/AGL/4mtqigDF/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6 FrSP/AGL/wCJraooAxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi/wDia2qKAMX/AIQzwr/0 LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JraooAxf+EM8K/9C1pH/gDF/wDE0f8ACGeFf+ha0j/w Bi/+JraooAxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8Aia2qKAMX/hDPCv8A0LWkf+AM X/xNH/CGeFf+ha0j/wAAYv8A4mtqigDF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/ia 2qKAMX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/ia2qKAMX/hDPCv/AELWkf8AgDF/8TR/ whnhX/oWtI/8AYv/AImtqigDF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8AAGL/AOJraooAxf8A hDPCv/QtaR/4Axf/ABNH/CGeFf8AoWtI/wDAGL/4mtqigDF/4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/ 6FrSP/AGL/4mtqigDF/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJraooAxf+EM8K/wDQ taR/4Axf/E0f8IZ4V/6FrSP/AABi/wDia2qKAMX/AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8A wBi/+JraooAxf+EM8K/9C1pH/gDF/wDE0f8ACGeFf+ha0j/wBi/+JraooAxf+EM8K/8AQtaR/wCA MX/xNH/CGeFf+ha0j/wBi/8Aia2qKAMX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAAYv8A4mtq igDF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/ia2qKAMX/hDPCv/QtaR/4Axf8AxNZP izwn4btvB2tTweHtLili0+d45Eso1ZGEbEEEDgg967CsXxn/AMiPr3/YNuP/AEW1ABdf8jxpf/YN vP8A0Za1ryypDE8srhERSzMxwAB1NZF1/wAjxpf/AGDbz/0Za1Hqk+p3cytptpZ3NnbsTKbi7aEO 69MbY3yoPXpyPY0m7AT+Hdc/4SC1ubtIGihjupIIg4wzBOCT+Oa16840jWLrRvhXa31uFS91O6YR MVyqPNMcN7gA5564FdJL4d0nTRb6nMZHvbENM10SDPcYU5DNjcV5ztBA6cY4qnpv0/pgtXp/XY6O qeq299c6dLHp16bO6xmOXYrjI7EEHg9D39K5fR9Jt/FnhdNW19xNPqKGWNjgizVs7BEGBCsAfvYy T+FRi5udc8Qanpq6Y99YaWqW0cU8yrBJIVBYy5JZuCAPlI4J64oad7dQT6naxM7Qo0ibHKgsuc4P cU+uFuNBCeGBpthNbX8tlcfbZ7BRtt5kLPmEDkBRggDplRkV03h6SwudIiv9N3i2vQJkVyfkyANo HYDGMDgUd/6/r/gC2salFcqssfiXxFqdveENpOkYheBz8k8pXcxcd1UEAA8ZJPYVznk2o8BarcWc fOuX7QWcfQFWbyYxj+6FG4DsB7Ut/wCvu+8rS/8AX9aHptFclcRLP4o0HRojvt9Lhe5kfd1ZVEaD 35Yn6j2qg+j29l45k0xLq8/s7WbVvPja6kYmVOSoctuXKvk4Pan6ef4E+p3lFV7CzttPsILOzTZb wRhIl3FsKBgDJyTVikxhRRRQAUUUUAFFFFABRRRQBieFs/2NcbSAf7Sv8EjP/L3LWI3jLUdB8V/2 R4k+yNZTKgh1C2haJEkbdhZAztjO04Of/rbnhT/kET/9hK//APSuWq13pNlruqa3puoQiW3ntrdW U9R/rMEehHUGjzDyJ9eudbt7uwXS7rT44rqYQuLm1eRlO1m3ArIufu4xj8aXxTuGjW+4gt/aNhkg YBP2uKuK0q/1jQvFGleC9aEl0sd15un35/5awiN/lb3GQP8AIrtvFf8AyCIP+wlYf+lcVPpdA97E 3iCTVrfS5bnSJrOOWBGkZbuBpFcAZwNrrt+vP0rP8IeLU8TWMkc0X2PVbUBbq0fqjY4YDPKnsa19 Y/5Al9/17Sf+gmuS8S+Gr2S0sPE/hwiLXLGBPlHS7jwMxt6+3/6sSnvfbT9RtXtbfX9Dd0K51y4v 9Qj1O60+SG0m8lRbWrxsx2q24lpGA+9jGPxp1uwXxrqrHoNMsyf+/l1Wd8P9cXxHp2oaqtvJbme9 IaKTqjLHGrD8wa0YGCeNdWY9BplmT/38uqqWi+X6CWpT0jW9Z8QaYNa006cbSTf5Nm6v5j4JA3Sh sITjpsOPU1bvtR1k+FYdQ0+Gyj1B445Ghuy+wZwWUbeS3Ye9c7ceEJYgfEngXVm06S5T7Q9o/wA9 rc5GeV/hJ9R09q6jwtrMniDw1Y6rLbm3kuY9zRnsc4OPbjI9qLaB1H3cs7f2a7ajHpjtKplgcIxn yP8AVAnockcjnj3rKj1XVV+JTaPNdRPYNpxuY4kh2lTvC8sSSe/TA56cVT8c21v/AG94UuvIj+0f 2qkfm7Bv27WO3PXGecVI3/JYk/7AZ/8AR1EdWvn/AOk3B7NeS/Ox15OBk1Vs9V07UXlSxv7a6aFt sqwTK5Q+hweD9axfiBdT2fhKeaGRYl86FZndSyrEZFDkgEZGM5GRxnmqqaHeTa/puv3GvWBSKJ4V WxsWjFxGy5A3GV8gY3DA4waXmB0keqadLNNDHf2zy25xMizKWjPX5hnj8aoaJ4t0TxBPcQadqNtN JDIy7FlUu4GMuF67cnGelc1pst/ol3oun6taQahppm26Zq1s3zqWU7RIh7sCRuBxWp8P/wDjy1n/ ALDN1/6HTS1/ry/zB6f16/5HSzXdtbMiz3EURkbagdwu4+gz1NRWmqadfpK9nf21ysDFZTDMriMj qGweD9a5Xx5Z2smt+Fbh7aJpjqqRGRkBYptY7c9cZ7Uut6fFP8QrMLbRSw3OlzrfoyhlkRSuzcOh +YnGfep6X9fwVw629PxdjqotU0+eaOCG/tpJZVLRokylnUHBIGeQDwaSPVtNlv20+PULV7xBlrdZ lMij3XORXDaAjWnwai1Cxtka/t7CZoJNgLox3Z2nqOB29BVnxBBbT/Cu3u9O2Ca2ggnsZYx8yy5X G0+pJx75NU1Ztdv+CC1t5/8AAOwuNU060Mgub+2gMSb5BJMq7F/vHJ4HvU1vdW93bJc208c0DruW WNwysPUEcEVxml2cEPxZvnFrDFK+kRSybEAzIXIZuOp7ZrEv3n0q18RRQqI9HbXbdJMfcSNthm+i knB+poSvZf1vYV/6+Vz0iz1XTtReWOx1C1unhO2RYJlcofQ4PFOXUrBrx7Nb23NzGAXhEq71B6ZX ORmub8W27Rav4avdPRVu11BYMpgFoGVi6+64GfwrMM19oLwLfWsOq6DPqIlt76E4ntneXI3qfvDc duRzjrQtbfd+X+Y3p/Xr/kdP4ivxBDBZQ61a6Xd3UqKkkzx7tufm2K/3iRwODya1x8qfM2cDljXn 2m22o+JE8R6a+p6ZHJJeTQ3MFxp7SzInRDu81eNuCvy12eg2z2WhWdpJem+aCIRG5K7fN28Zxk+n qaS2/rqD3t6iR+INFmspb6LWLB7WA7ZZ1uUMcZ9GbOB1HWp01KwkggnS+t3iuCBDIsqlZc9Npzz+ Fcj4eRVn8bqUAU3z5BHHMS1gWlnay+Evh9PJbRPL9sij8xkBbYVclc9cZA4oWtv+3fxB6X+f4Hp1 rqNjfNKtneW9yYW2SiGVXKN6HB4Psakubq3srd7m6njt4Yxl5JXCqo9STwK5iMCL4sSqg2iTRVLg dyJSB+QJq94qs7y7gsjpl3BBqEFz51slwCYpmCtlGxzjBJz2xR0T/rewdWv62ubMN1b3EImgnjli I3B0cMpHXOR2qGz1XTtRWVrHULW6EJ2yGGZX2H0ODwa8/wBT1yc6FqAuNPj0W9j1S2XUw/72HaxU eZwV3IwC5GRxkGt1fDc9z4httX1LVdNuYprV7V7a308ol3GRkBi0rggYyOMdfWjz/ra4f1+JvTeI NFt0V59XsYlYMVZ7lFBCnDdT2PB9KE8QaLLp8moR6xYPZxNte5W5QxoeOC2cA8j865z4cadZSeCr MyWkLlJrjYWQHZmR1OPTjjjtVXR1Wyt77wKwG6O6KQr0zZyZcn8BvTPrj1p21sB1Md3Hd6tazWut 272sluxW0j2N5/IxIGznAHHHHNWbjVdNtLuK0udQtYLmb/VQyTKrv9FJyfwrlriztrb4uafJb20U Ty6XMZGRAC5DKBkjrgcc0nhBbDxJ4W1Cz1ZI7idrydNRiY4YMJDjODkYULg9gBjpQtk/63sHr5fl c6u+1PT9LiWXUL62s42O1WuJVjBPoCSKsqyuoZWDKRkEHIIrh4Li9v8Axnq9jbajpsP+jw/Z4ry0 adpICmSVxKnG7OeD2zW94R0htA0GPSm1AX32aR1EgiKBQTnYBuPAzjr7dqSBmhqGoWlhCPtN/a2b zHZC1y4AZz0ABI3fQGsfwZq19qWjXU+qXMcs0F7PCZEjEa7UbAOMnHTuT9ag0Gb7d4y8SreIrS2z xQwq45WApnj2LZJ9fwrk7e5bTvCASCeC2tf+EllinknQvFGnmNjeoZcru255FC/Nfm1/mD29H+jP TLHU9P1SN5NPvra8RG2s1vKsgU+hIPBqPUNb0jSXRNS1SysmkBKC5uEjLAdcbiM1i2GhXsPi2PXb vWbOV57U25gtLJolmAO4MSZXyR6++Ks+NNIfVvDsv2dFa9s2W6tCRn97GdwH44x+NDsrN/Ma1djT l1fTILqC0m1G1juLkAwwvMoeUH+6Ccn8KF1jS31BtOTUrRr1RlrYTqZB/wABzmsjSNUtPEckOuRk fZba1yrf3ZHAZx9VUAfia5HUX/4pnw3c6dCItOXWIGtpLht9xMGkOXOMBc5PqSDzinb3kn3/ADdi b6X/AK2Opj1XVV+JTaPNdRPYNpxuY4kh2lTvC8sSSe/TA56cVsaaztc32/VY74ef8kSKoNsNo+Q4 5J75PPNc+4B+MKAjIOhnj/ttXPxSSaHoHj9tHhW3a3u28pYECiMeWuSAOmASaS+Fej/9KsU171vN fkdH4r8STWjWi6Nq9kXS/gt7yBQssoDuB/e+TjPVTnPauhu9Y0ywuIre91K0tppjiKOadUZ/oCcn 8K5Hxda2Mfhbw+9tFEsUWoWfksnAClx09jVfxA0d1pPjP+zIhImxxe3F024CRIh8kagdAO5PBPAP YekX5N/kv8wj7zXnb9TqdX8WaLod/aWOoahb2810TgSyqgRQCdzE9BxgepNWIZTLrTsmrwywtbqU sVCEqc8ybgckEED0/OuT8xptQ+H0rnLPDISff7PU1tBHZ/FbV3s7aNJJNHSUhFC+ZJ5jcnHUnA5p yXK7Pz/C5Kd4pry/FnWSatpsN+lhLqFql5IMpbtMokb6LnJqWW7toZViluIo5HBKozgEgDJIH0Br itIjtNa+Ekr3vltJLbzS3LsMFZwWJY56MGHXtiqllbtP4m8E3eo2sf8AaE+mym5kZBvdgiY3HvjP 4Zotrb+uv+Q+l/66f5nfWd/Z6jB59jdwXUWSvmQSB1yOoyKllmit4mmmkSONBlndgAo9ST0rl/Dn yeOvFkS8J5ls+0dNxi5P6Cl8TXDHxb4ZsJ1BsbieV3DfdaVEzGD+OSB6gelLe3mHcNO166vfHj2U WpWt5pUmnfaYPs6AjO8Ly4J3dD0wOenFb8eq6bLfvp8eoWr3iDL26zKZFHqVzkVxmteZZ+PtUnsF C3Z8OPIm3qzhzg/XgVHZaTdeIPDuiahH4h0yO2sXiuYpbbT3EisB8yFjMeTkhuMk046pf11f+QPR v+ui/wAz0KqkWrabPfvYRahayXcYy9ukymRfquciqXi2e7tfCOqz2G4XMdpI0ZXqDtPI96r6XDoO p6Do2oIkMkNsqSWsinHluRt7d8nBB79aSBmrc6rp1ndRWt1qFrBcT8RRSzKryf7oJyfwp1xqVjaM y3N7bwFEMjCSVV2oMZY5PQZHPvXBadZaj4r0zXtMk1bTYmkvLiK5ilsGknjG4hDu81Rwu3advGO9 T6ZpdrB8Q7FHMN3I+gkT3IiC/amDqu9hznIHcniha2/ro2D0v5f52Oi/4TPw9/biaQNWs/PaMOCZ 1AJJAVQc8sc5wOcfWrFvew2f9o3N9rttNbxzZ+YpGtmuB8jMD685bnmsW0hih+KVxBFEkcSaJEqx qoCqPNbgD0qPwHbQWeqeKre1gjghj1PCRxIFVR5a9AOBR0+T/OwPR/d+VyrY+Ir7xXYSX2h+J7Gx uI5pFe0lEciRwhyokI++Gxhhk7TwMd67G1uI4tJhuLjUIriNYVZ7zKqkgx9/jgA9eOK4LQra3uvg zqKXMEcyqL11WRAwDB3IPPcHkGpbXUFtLfwBFeOqafNbYZn+6ZhEvlg/m2Penbden43/AMglo7+v 4WO7s9RsdRtvtVjeW91Bz+9hlV0468g4qO01jS7/AM77FqVpc+R/rfJnV/L/AN7B4/GsTxRa+H9O 0jWbi7SWE38Si6+yt+8m52LgHjJJ2579+lZwN6nxO0ZrmC3t/N0ydBFESxVQykBm4z24xgc8nrQt X/Xa4PRf15G/oni3RPEE9xBp2o200kMjLsWVS7gYy4XrtycZ6VrTzw2sDz3EqQxRjLySMFVR6knp XMfD/wD48tZ/7DN1/wCh0zxfeXNv4g8PwpeWtnBNLKPNu4TJH5oUbAQHTn72Oeval287fkHV+V/w Ojh1XTrix+3wahay2gz/AKQkytHx1+YHFKmp6fJe/Yo762e62eZ5CyqX2/3tuc4968/8U+GGstC8 U32o3tneyXloJxbxWRjSKRBtEo3O+GIOM8GtXXI0t7jwW0KLGRfKoKjHDQtkfjTWv4fiJ6fj+B19 2tw1pKLWVIZyh8uSSPeqn1K5GfpkVy3hrWNR1r4eLqN5q8VjeS+aPtrRJsixIwB2njAA711r/wCr b6GvKIrW3ufgDO08EUrQrPJGXQMUbzWG4Z6Hk8il0fyLSvb1PUJby2srEXN5eQxwqoLTyuqJ9cng U6G9tLi0W8huoZbZhuWZJAUI9dw4rmNWgmN34YvIP9Je1DN9g3KGmBiwWUtgbl9yBz1FZ8/hS3kt /FOt6no1rG19CXggnijkli2x8ksMgEsM4BPQHOaJaXfYmHvW8zsk1bTZJ4bdNRtWmuE8yGMTKWkX +8ozkj3FLearp2nNGt9f21q0zbYxPMqFz6DJ5NcJdxpD8OvCMsSKjrdWDBlGCCSoJ/EE1ZtU1DXN Z8T6Z/aOmRubjypLe6smnk8kxrtIIlX5eScY6k+tVJWbS6X/AAt/mJO6TfW36/5HedRkVmy38tzq z6faOsa2yrJdTEZ25+6gzxkgZJ7DHrw3w1Yvpfh6z0+S/N+1qnlfaCm3ftJHTJ6Yx17VleDGkk1H xM83+t/td1Oeu0IgX9MUratL+tl+odLstWXjjw3fy3iR6zYqLRyrM9wi7gACWGT90E4z0yK0I9f0 abT5NQi1exeziO2S4W5QxoeOC2cA8j86wvBaJJP4njkUMjaxMGVhkEbE4rO0wiye88BSAj/SM2wA 62T5dvwGGT6lfWha280n+Q3o35NnX/25pHkGf+1bLyhH5pk+0JtCf3s56e/SrMN3bXNqt1BcRS27 ruWVHDIR6gjjFcfp9jZ23xe1DyLWGLdpUch2RhcsZGBbjvjjNYF7Jc6TNq8dvLBaaQ3iGFS8yF4Y 9yAvlQy/L5m3IyBnPvSWtvP/ADsLv5f5XPS7HU9P1SN5NPvra8RG2s1vKsgU+hIPBqW5ureyt3ub qeO3hjGXklcKqj1JPArnLDQr2HxbHrt3rNnK89qbcwWlk0SzAHcGJMr5I9ffFWvFVneXcFkdMu4I NQgufOtkuATFMwVso2OcYJOe2KGNGzBcwXMQmt545Y2AYPG4YEHociobTVtNv2mWy1C1uTAcSiGZ X8s+jYPH41wWp63cnwxrXm6cuj6hDfQDUlP72IozIDICMblKDkZBxnmtdvDk+oa1p+sX+r6ZcW4h e38i204ql3E6/cYmVwQMZHGODR/X4XA6GbxBotuivPq9jErBirPcooIU4bqex4PpQniDRZdPk1CP WLB7OJtr3K3KGNDxwWzgHkfnXOfDjTrKTwVZmS0hcpNcbCyA7MyOpx6cccdqq6Oq2VvfeBWA3R3R SFembOTLk/gN6Z9cetO2tgOvn1vSLazivZ9UsorWfHlTyXCKkmem1icH8KdLq+mQXUFpNqNpHcXI BhheZQ8o/wBkE5P4VyiSX91441nTYb/TbZkghWGC7s2mZ4CvO3Eqcbs5GD2rMu9FbQbXwjpjXwv/ ALJrgQSiIoEBVzsAy3Azjr2x2oWrXnb87Ceifl/lc76LVtNnvZrKHULWS6gGZYEmUvGPVlByPxpY 9V06WaKGO/tXlm3eWizKWfacNgZ5wevpXKyW9vc/Fq7gnhjmil0JVkjdQyuPNPBB61J8NbG0/wCE NspDbRF4Z7gxsUBMf7xx8p7cccUJaX/rdr9BvRtf1tc7GiiikAVi+M/+RH17/sG3H/otq2qxfGf/ ACI+vf8AYNuP/RbUAV9YsodR8WafaXBl8qTTLwN5UzxNjzbX+JCCPzq7F4b0yDQxosSXMdiBgIt5 MGA9A+7dj2ziorr/AJHjS/8AsG3n/oy1rQN9jVFsPstyd0Rl+0CP9yOcbS397vj0o8guZ9t4R0O0 0V9Gjs2bT3x/o808kqrjkbdzHbzzxjnmr9lplrp8PkwLKy427p5nmbHpuck49s1brP1fVV0uCHbH 5txcyrBbxbsb3PqewABJPoDQAzTfDul6Sx+w27xIW3LF5ztEh9UQsVTqfugUS+HdLl1R9TNu6XUi hZXinkjEoAwA6qwV+P7wNSaY+qlrmPVEg+STEMsClRIhAP3SzEYJI684zgVfoAzbnQNMun3vbtG5 CqWgleFmVeiEoQSvJ+U8c9KvQQQ2tvHb28SxRRKFREGAoHQAVJRQBnroWmpqNxqC25We5A87Ej7J CBgEpnaWA74z71CvhfRk02105LQpb2ciywBZnDIy9DuB3frWtRQBl3PhvSLueaaezDPPbfZZMOwB i54wDgdTyOeetSz6Jptylqk1sHFm/mQku2VbBBJOcnIJznOc81aW4ieeSBXBkiALqP4Qc4/kah06 +/tC3ab7Jc2u2R49lzHsY7TjcB6HGQe4oAtdBgUtFFABRRRQAUUUUAFFFFABRRRQBi+FP+QRP/2E r/8A9K5altfDem2WqyanB9r+1S/6xnvp3VuuAVZypAycDHHbFReFP+QRP/2Er/8A9K5a2qAK1zYW t3PbTzwq8trJ5kLnqjEEHH4E1neK/wDkEQf9hKw/9K4q2qxfFf8AyCIP+wlYf+lcVAF/U9MtdXsm s7zzjC/3lineIsPQlCCR7ZxS6dp9vpdmlpa+d5KfdEs7ykD03OSce2atUUAVrSwtbFrhraFYvtMp mlC9GcgAn9BWbbqG8baqp5B0yzB/7+XVbdYtr/yO+qf9g2z/APRl1QAv/CJ6KIkhitHggT/l3t7i SKFs9d0asFbPfIOa1ooo4YkiiRY40UKqKMBQOgArEi8Q3OqPOPD9jDexW8hie5uLkwRMw+8EIRy2 D1OAPfirGma/Fe6jPpdzA1nqNugd7d2DBkPR0YfeXPHYjuBTBhq/hnStduLe41CKd5LVt0Jju5Yv Lb+8AjAZ9+tIPC+kjXRrnl3H9oBdnm/bJsbf7u3dt298YxnmoR4im1C8urTQrFL42b+XNPNP5MAf ugYKxZh3wuB604+IWtJ54dUsHsxbWjXUk4cSRMq43BG4Jx7hT045pXtqG+hrzwRXMDwTxJLFIpV0 cZVgeoI71jaN4K8N+Hria40rSoraacEO4ZmOD1A3E7R7DAqI+I9UTSm1d9B3WJiEsaxXQafaRnLI VCjjk4dj7HpR4g8Q6no+oabbWulWt1HqMwgjkkvWiKvgt8wEbcYHUE/Si1n+AX0L1t4b0mznimgt Svkf6mMyuY4jgjKRk7VOCeQAeams9G0/T7u5urWDypLqQyS4dipc9WCk4BPcgDPesy28USxeIIdC 1qwWxvLqNpLZ4p/OhmC9QGKqQw9Cv410NPzDyOH+IOLnUdAtzp1/dx2+oJcXBgspZVSPawzuRSM5 7DnvXRw+HtMjtJ4UjuMXShZZWupjMyjoDIW3gDJ4zxk1q0Uulg63M7RdB07w/ZfYtMilits5ET3E kqr9N7HA9hUdp4Z0ixn863tWQb/MWLznMKN13LETsU57gA1q0UX1uHSxwDWsOq/FK7kuLDVUt2sE t47pLe5gHmK5LASqFwMd84PvXZx6Vp8Wmtpq2kX2RwytCy5Vgeuc9c5OSetXKKOlg63M7T9B07S2 DWsMmVBCGWeSXyweoTex2DgcLgVHH4a0iKdJktCvltvWLzX8oPnO/wAvOzdnndjPvWrVPVdVs9F0 6W/v5hFBEOTjJJPAAA5JJ4AFF+oW6GbrHgjw1r+oR3+qaTDcXMeMSEsu7HQMAQGH1zW5HGkUaxxq ERAAqqMAAdhWKdW10Q/ax4fU22zf5X2wfasYzjy9uzPt5laGlarZ61p0WoWEvmwSjg4wQRwQR2IP BFHSwED+HdKk1C4vmtiJrpAk+2V1SUAYBZAdpI7EjI9az28AeGDBbQJprQR2r+ZCtvcywhX/AL/y MMt/tHn3rojnBx1rnvDOu6lrE+s299bWsE2n3X2dVgdnU/KDksQCeT6CheQepaTwtpMeujW1iuf7 QC7PNa8mPy/3dpfbt74xjPNXr7TbPUljW7hEnlNvjOSCjYI3KRyDgnkc0unfb/sEP9p/Z/tm3979 m3eXn/Z3c4+tWaH2Az4dD0yCxnsharJDc/68TsZWm4x87OSW4AHJPSqGl+B/DeiR3K6ZpotDdKVl kimkEmD2D7tyj/dIrfooAzNE8PaZ4dtmttLilhgY58t7iSVQeScB2O3JJzjGas/2dZ/2n/af2dPt nk+T538WzOdv51lx+IrjVJ7iLQNPjvUtpPKkubi4MEJcfeVGCuWI7/Lj3q3Y6rPcapNp11p0trLD EsnmFw0cmSR8jDk4xzkA89Ke/wDX9dA/r+vmMm8MaVPrqa3JHcG/jG1JReTAKv8AdChtu31GMHvV e+8D+GNS1gaveaNbzXgOTIwOGPqy52sfcg1vUUtg3MXXvCGgeJvK/tjTI7ow/cbcyMo9NykHHt0r UtLO2sLSO0tIEggiXakca4VR7Co7TULfUYJZbGVJVjkaLeDlSy8H8jx+FUL3V7nQfCk2q60sD3Fr CXmW1yEZuwXdzzwOaNkO12WLzQdNvr+O/mgYXUQ2iaKV4mK9drFCNy/7JyPaobbwpoFpa3drBpNq sN6SblSmfNySfmz16nHp2qoJ/F51K2WOHSpbCbbJJOQ6NCvdNu47mIPDcDg5HSuiotoK5jaB4R0H wwJf7G02O1M332DM7H23MSce3Stmioby7t7C0lu7uZYYIVLySOcBQKG+4JEdhptlplqbWyt0hhLs 5RemWJLH8STWaPBugC0W0Fi3kJMJ40M8mIXByDH83yDPZcD2rZhlWaFJUztdQwz6Gn0bMN0Y48K6 OutjWVhnW+CeWJFu5gAn93bu27fbGM80ul+FtI0ee6msoZw15k3Hm3cswlJ6kh2IJ9+tP1jWhpkl paxQfaL2+kMdtCX2BiFLEs3OFAHJwT6A0211W/8A7Sh0/UNK+zySxvIJoJ/Nh+Uj5dxVW3cjgqB1 5OKEBAfBfh57P7HJpwltd4dbeSV3jQ/7KFiFHsAB7VK3hTQ2kuX+wKFu4xHPErsIpABgZjB25AAG cZ962KKAMo+GdIa1srb7KQlgwa2ImcPGQNo+cHceOOTyODTYfC2kW+uNrUUM63zLtMn2ubaV7Ls3 bdo7DGBWvVXUft/2GT+zPs/2vjy/tO7y+vOdvPTNF9bhboUz4Y0c3st2LVleZt0sazOsUrf3miB2 MfcgmkvfDGk6hrEGrXMVwby2GIZEu5kCDuAqsBz34575rWGcDPXviloAyNP8MaTpeq3GqWkVwt3d f6+R7uaQSemQzEcduOO1W9T0qx1i0+y39us8W4MASQVYdGVhgqR6gg1crF8V63d+HdDm1W2sIr1L Zd0yPcGIhfVfkbJ9jigau2SReF9Fi1CHUfsKy3kCBI7id2lkUDP8TknPJ561WtfAvhiy1s6zbaNB HfE7vMG7Cn1C52g+4FVrvxZe6KLWfX9KhtrK6kWIXNrdmdYmbpvDRoQPcZrp6eu5N7gQCCCMg9Qa wtP8D+GNK1V9UsdGt4bxjnzBk7T/ALIJwv4AVvVWvNQtbDyRcyqhuJVhiUnl2Y8Afz/Cl1H0MnVP A/hjWtTTUtR0eC4uk/5aHcN3+8AQG/EGpz4U0g64uteVcC+VQqyLeTABR/DtD7dvH3cY9q2KKFps D1KNxoun3OpxalLATdxRmJZFdlyhOdrAHDDPIznB6VRs/B+jaf8AazapeRG95uGGoXBZz/eyXyG4 6jntmtyigDn7fwPoFppc+lwQXcdlcDEkA1C42kE5PG/jPfHXvmrDeE9Ek0EaFNZefp6jCwzyvJt9 NrMSwx2weO1VrzXtQtfHGnaIba2+x3sMsgm3sZMoBkYwAOSO5/Cuho3QdTFs/CHh7T9Gm0e10qCO yuBiWPkmT6sTkn3zUkfhjR47q1uxas9xaIUimknkd9p6hmZiWHHRs4rWrPtdRkOoSadeIsdwFMkT IflmjzjI7ggkAjtketHULaDrPRtP0+7ubq1g8qS6kMkuHYqXPVgpOAT3IAz3pdW0jT9csHsNTtI7 q2k6o47+oPUH3HNXaKA8zno/AfhmDRJNFh03ybGVt0scU8iGQ/7TBtzD2JIp9x4K0O6SzWeK8cWH NtnUbjMR7EHf15xnrjjpWjrFzd2Wk3N1ZQwzTwxl1SaQopA5OSAT0z2/Kq/hnVJtb8NafqlwiJLd QLI6xg7QT6Zp+foBoXFtHdWsltKZBHIu1jHIyNj2ZSCPqDWGvgXw8miNoi2twNOd95t/t0+0n0+/ 0746Z5xmuhopAcX4k8O6PP8AYNP1bRLu+0e1iYxyxNNcSpISBtO0mXbj0yOOcYFGleAfDKRyf2XY 31lY3cJS4hNxcQ+eCRgFWYMMYPp1xyCa7SigDnpfAvh+bTrbTpLe6a1tG3QRf2hcYjPYj5+2OPTt in6v4I8N69NBPqmlR3U1uAqSO77yB0DEHL/8CzW9RQBHDDFbwJBBGscUahURBgKB0AFZf2STTNcm vreFpbfUNguFQZaORRtD47gjAPcYB9cXo9RtZb+exjmVp7dFeVQfuBs4z+RpbDULbU7b7TZyiWHe yB16EqSpx+INHmG2hVbTrDSZL7V7eyleeUGWVICzGVguMqhO3eRxkYJ7mqmiltX1A6/Ppc+nk24g gju0VZ9pO5iwBOATtwCc8Hpmt6ihAzgGtYdV+KV3JcWGqpbtYJbx3SW9zAPMVyWAlULgY75wfeux Gjab/ZbaWbKFrJwQ8LLuVsnJJz1JPOTzmr1FHSwdbmNoHhHQfDAl/sbTY7UzffYMzsfbcxJx7dKv 32m2epLGt3CJPKbfGckFGwRuUjkHBPI5pZNQtYtQgsGlX7TOrOkeedq9T9OQPxqzRuBRttF061tJ rVLYPFcZ8/zmMrTcY+dnJLccck8Vmab4E8M6O1y+m6WtrJdKVkkimkDgHqFbdlB/ukV0NFAGZonh 7TPDts1tpcUsMDHPlvcSSqDyTgOx25JOcYzVn+zrP+0/7T+zp9s8nyfO/i2Zzt/OrJzjjrVbTv7Q +xJ/af2b7Vk7/s27y+pxjdz0x+NAFDXvCOgeJ/KOs6bHdND9x9zIw9tykHHt0qe48PaTc6VFpb2S LaQFTFHETH5RXoVKkFSPUHNaVFAGNN4R0K4vBey2O67EQiFz5r+aq89HzuDcn5gc+9TaJ4e0zw7b NbaXFLDAxz5b3Ekqg8k4DsduSTnGM1p1DdtcJaStaRxyThSY1lcopPbJAJA/A0XsG5NRWL4R1qfx B4atdUuYo4pZy+UjztXDkDr7Ctqm1Z2AKxfGf/Ij69/2Dbj/ANFtVmO7uLDT7q71yazhSF3cPCWC rED8u7d/FjrjjPSqfi2VZvAOtypna+lzsM+hiakA+6/5HjS/+wbef+jLWsPS5k+zeK9Vnur46dHN JFErX0x2rEvzsjbsrl9w+UjGBity7GfG+lj/AKht7/6Mtajh8IWEPh19CFxdvbSE7md1LkF95GcY wSSDxkg9aVtxroc8h1T/AIQ/w/HJfXsV9e3FuseZ38zlt8hYk5YbA3DHGMd6tahplpqfxMgkkkut umWJuZNt3Kqq7NtTADYX5VfIAGc85rX8Q/2VbahpF7qUksXlTtHCylRGrMh++T04GBg5JOOc1JoV gy3GpapcIRLqU+4K64KxKoVAR9AWx23Yqr63Xn/l/wAEnZWfl+f9IxLK8fxF4bu/Emo31zZ2WJJL OK2uHg8qNMgOxUgsxxnByvTiqNvqOqagvgzzprldUuYWnuESaREeNU4MiKQuCWQnI7YHWuii8F6d HbfYXuLubTFfemnSOvkoc5xwoZlzztZiPatJdItl1w6vlzP9mFsqkjYibtxwMcEnGeewoVr/ANdn +fUb/r+vI5PWbC+0/UdLtF1zULu91DVPOTNw0SpEqBnTahClMqOo/iPfkz2N9MfEniWV7+5bT7CK JJS0p2h1Qu+zPCHBAOMYx68100uk282twau7SGe3geGNcjYoYgk4x1+UDr0qk/hWxfQ9Q0kzXIi1 KSSSeUOPMJc5POMYxwOOgpdLf12/IfX+vUwtM1LVotC8P6L9plOq6pG00k8x8x7eAfMSSerAMqgn PPJzirljAYvG89vDqV7JZ2NjvnilupJF82RupyT0VMgdBngDNalx4btZtQsb+K4uLa5sUaNJISvz o2MqwZSMcDpgjsRSQ+GLGCbVJUluAdUGJv3n3fk2/LxnOOec8k0292vP+v66iXZ+X9f10ORsrS10 3wFq3iPffedfmWeIDUJwWBbEPO/OSAnPUg46cVsPd6jZNoHhWC7lN7c25ku72VvMkSNANxBbOWZj gE5xWpP4Ws7jQ7XSXubryrV4XWQModjGQVB+Xbj5RwAKl1Dw9b31xbXcdzc2d5aqyRXMDKXCtjcp 3qykHA6g0aX8v0S0/wCCLV+v+f8AWhgPP/Z3jC70qK8vZdOGlPc3olu5HMLbsKVcnchIDcKQOMjF UIZNTk+HumO17fQ3d/PCttm5cygySbsliSzAJnAJxgc9eOqfwrpraXf2AMynUgftVxvzNLnjliD2 4xjAHQCrN9olrfz6fLK0i/2fIZIlQgAkoU549CemKFpb5fm3/wAAb/r7v6uY3iK5ktta0+8ubq4G jDMEj2s5TyLgsArSbSNy9VwcgHqK6S0he3tIopZ2nkRQGlcAFz3JxxzWVP4WtLhWgkurs2cspmmt C6mOZy27JJXcBnsrAe1bVJbW/r+v0sHUWiiigAooooAKKKKAMXwp/wAgif8A7CV//wClctbVYvhT /kET/wDYSv8A/wBK5a2qACsXxX/yCIP+wlYf+lcVbVYviv8A5BEH/YSsP/SuKgDaooooAK5y5SeT xHr6Wp2zto1qIj6NvusfrXR1i2v/ACPGqf8AYNs//Rl1SaurDTs7mX8LGj/4V5pkaDDxB0lU9VcO 24H3zVDxDHc3HxW0cae2JoNNuHnIPRDkJn/gVdJL4bhW6mudNvrvSpblt85tPLKyt6lZFZQfUgAn HWrWnaPaabJNNEHkuLggzXEzl5JMdMnsB2AwB6VUnzO/9aqxKVlb+tzlvhCceA4onP8ApMVzMtwp +8sm85B98YrrNTjsJbKdNQWMwPC6Sb/7hHze+OlUJ/C9sdQm1DT7280q6uCDO9mybZiO7I6spPvj PvVuXRoLnTp7K7lnuRcxGKaWRgHdSMH7oAX/AICBRJ8241ozirmx8S/Dy1kuNPuRrfhyBS0ljdHE 9vH32P8AxADsewxjvV7xfeSXv/CI3umRxytPqKSQpO5jVgYmIyQCRx7GtybwxHcQ/ZJdU1F9P2bG smlUo6+jOV8wj6vzTNa8KR6zd2U51W/sxYOJLeK18kIjgEbvmjYng4wTj2ovt6oX+TKi+HtT1bxT Y65rf2OBdNRxa2trI0vzMAC7Oyr26AL+NVfilAr+ExPvlV4rqELslZQQ0ig5AOG49c12MalI1Rna QqAC7Yy3ucAD8hXE/Fm+soPCH2a5u4oZZ7mEojSbXYLIpYjvwOpHSl1S81+Y9035foS67YxaL4p8 P6hpMAgnvbw2155Yx9ojKMcv/eI25BPNM0Gxs/GGg3Wpanbh717m4SOUn97a7XKqEbrGQFXpjJ5P Wt7TdJtZJ4NVOpz6phD9llldGSNGx9zYoByP4jk4780z/hFrWO9ubizvbyyjvGL3VvbuojmYjBY5 UlSe5Qrmh7W/pAu/9df6+RxFpLJqcvgHWL+FDqUk8kMtwUAeRVRwCT3Bxn8TWtBpln/wsjxFbpD5 MdzpcTy+QxiLMWbLZUggnHUGul1Hw1Y39nZW8bS2J091e0ktSqtCQMcBgQRgkYINVpvB1pJq0+rJ qGow308AhaaOcDgZ52kFSeT1BA7AUS1v8/xQf8D8GZnw60u0m8J6Lqs0Zkvo4ZFWdmO4BmOR7jgd frWp4pv7iBtO0+MPFDqNyIJ7sdIVxnb7M/3Qe2fXFWfDnh+Pw1pSabb313dW8X+qFyUJjHXAKquR k981fvLSG/tJLW4TdHIMEdCPcHsR1Bpyd3cS0RhaNdy6j4o1OK4iNtHpO2C1tj1KsM+d6YONo9AD 6kVl/E8SLbaDcMcWUGsQPdc4AXOAT7ZrrvsEP2yK8y3nxxmIvxmRfRuOeef/ANZqS7tLa/tJbS7h SeCZSskbjIYe9F7Wfa34f5j7+ZL2zXjNvZs/hzUb8STpbv4oH2TZO6qUaZVY7QcEcd898V6WPDAE P2X+2dU+w7Nn2TzkwFxjHmbfN/8AH6brPhGy1fS7TTEurrTrS0dXjisvLUZUgrncjdCM8Y980LR3 /rdP9A3Vv62f+ZnTW0OmfEvTBZRrAL6xn+07OPOKFNrN/eYZPJ55qr4ft47u48awSmQI+oNkxyNG 3+qXoykEfga2ZvCn2jXbPWZNc1M3NnH5cYHkBCpA3ZHl87sZP6Yplh4PXTv7TaHXdUZ9TYvO7+QS HOBuX91wcDHp7VLXu28mvxuNb381+Vji1h8/4S+G7l5ZxKt3ANyzuobdOA24A4b8c4rp7i3h0v4k 6b9iiEP26xuPtITjzihTazf3mGTyeeaf/wAK9tf+EftdCGuastnaSiWIBoNwIOVBPlcgHn8ec8Yv S+FBPr1lrMut6k1xZR+XGv7kIynG7IEfO7HP6Yq29dO7/FW/MhL3beS/M5G307XPFvhyLVLSx0qL VJHMkOqPfSCeFg5+XAhOAMFdm7Fd/e/apdBn8llN09q2xozkFyvBB9M1if8ACv8ASk1iTULW91Sz jmk8yeytbxo7eZz1LKOee4ziuoACqFUAADAA7VDV42LvaVzjvhMY/wDhXenInDxmRZR3V97ZB962 /FF++leHNR1C2VDd29pI8RIBIwM/lnBqKTwrbR3097pl9eaTNctvn+xshSVv7xSRWXPuACa0o9Ph WCSKYtcmVdkrzYJkHoQAAByeAAOelVJ812KNos4uLQdZlutJ1iws9H09o3SS6vI9Qkkku4SuGV/3 K7iQQQSTgijw/wCHdL1PUPE1hqNu17aw6mhjjuZXkwRGjdWJJ59T046Vr6R4C03RbzzrS/1U2yHd FYSXjNbRH1VO+Dz82eat6J4YXRNQvL1NX1C6a+fzJ0uPKKs+AN3yxqRwMYBx7UaX/ruv8ha2/rzO c8EaFpZ8Jak6WMUEslzdxNNbjypNglbC70wwAwOM9qxrm0trz4AQ3N1bxTzw2xeOWVAzIxk5IJ5B PrXfWvhmCxtL61s7+9t4ryR5AFZD5Bc5bZlT1OfvbsZOMVmt8P7VvCq+Gf7b1UaevG0GDcVyDt3e V0zz689ccUun3fgUtJJ+bMrxZpNhptl4Yawtls1/ta2UxW5McbbjkkouFJyo5IzxWpCLTxJ4s13S 9XtormGwWFYLedQy7WUsZNp4znjPbFWdR8GjVLWwt7rXtVb7BMJ4nXyAxdfuk/usHH0+uadrXgnT 9avoNQa81Cyv4UEZu7G48mSVP7rEDBH0Ap3/ADf6f5ErZen6sp6rp+n2Fvo+kS3d1fxpNIE0+TEz 3vysdjliBtXIPzccDPauVuYUbwh460+eyhjgsJi1tbAh0t8xqRsyPl5546EnFd7ceFbKX7BJDc3d tcaezGG5SUPKdwwwYyBt27vmox4N0zbq6PJdSRax/wAfMby5Gdu0kHGc49SQO2KT6/12Gt1/Xcxb +NdObw/omlaVp4ttQSSSa3d/s0U7LGvDFUbOck4xzjmtDwrouqaNqmoCeOws9NuQsltYWlw0ggcc OVyiAKeDgDGat6h4P0/VtDh0u/nup/s5VoboyBZ42AwGVlAAOPQY9RVnQtAh0K3aNb6/v5G+9cX9 yZpCPTJ4A9gBVX1bElokVfFPh+z8RpbWsl5NZX8LNPZ3MDYkiYYBI9R8wyKx9I1rxDo3iGz8P+Ko 4Lz7WH+w6nbrt8wqMlXX+Fsdxx9etdRqGj22o3VtdSyTxzWu7yXhlKFS2M5x16dDke1Q2mgpBfR3 13f3epXMKssMl0UHlBsZ2rGqrk464z71KG9UcTHYaz4v0Se9g0/TBqBuJhb6jLfSLPasshAAUQna AABtDYPfrVy10mK+8f3VnqZ+1Jc6JG1zH5zvE7s5ViuTwOBgDHrjNa83gDS31mTU7a91SwM7+ZcW 9leNDDO3cso5z9CKtQ+FI4PEp12PVb8SmIQeR+68nygchMeXnAPfOfehdP66WCXW39apmIdF0nwp 8QLLUIbG3gt9Tt2tvM2f6qZRuBz2LLuBPfbWZ4u0Swt/h1qurW9qLS4vZluiYCYsqzgKGC43fIeQ cjLE9a7vXNDsfENgLLUEZohKko2nBBU5HPv0PsTUPiTw7B4m0k6Xc3l1a27sC4tigLgHIBLK3GQD xjpQn/Xle41a9/67fkZVzNFqfjWLQdQiSWyXTPtCwSjKTuX2nKnhtoHQ565qDXIP+EX0q007SWLR X2ppGYp7kokSPk+WrBSUQlcAAHqQPbS1jwZY65a2a3d5fLeWQxDqMEqxXC+vzKoHP0qZ/CWlXGgy aNeC4vYJsGSS6naSVmHRt5OcjtjpR/Xrrclf15aW/wCCZeh6Dqul+KGvEtNL0rTLiAxy2Vncu4eU HIkCmJADjIOOtWfiN/yT7Wf+vY/zFWvD/haDw/uK6nqmouRhX1C7M3lr6KOAPyzU/iLQY/Emlvps 99d2tvKMSi28sGQehLK2PwxQ9rFRdpXZhajoOueLNNstO1aPT7LTlaOWf7PcPPJMFwQo3IgQH15q roWhafeeKPFNldxyXFvFdWzRpNM77G2B8hicj5vfiuy0+zewso7Z7ye8MYwJZwm8jsDsVR+lZmk+ F10nWb3VE1fULiS/YNPHP5WxiBhT8sYIwOOD9c076v8Art/kRbQydDs7Hxhaand6tapNOl/PBEX+ /ahDtXYeqHAByMHJzXOyp/bmg+EZdbtoby4XWTaPLPEGM0amRec9QdoJ9SK7t/DNuupT31ne3lg1 2c3UVsyBJzjGSGUlTjupU+9Pv/DOn3unWVknmWiWEqS2r25AaJl6Y3Ag8Eg5BzmktLfL8Nyn1+f4 mNZW9hrPinWNFvdPgew0qG3itrN4wYgGUsWCYx6AHHG3isSXV73RrTVNJ8+YWVvrdvaJcNId0UEu 1mXf14BwD2DDnpXZ3vhu3ub+PUbe8u7G+SPyjc27IWkTOdrB1ZW555GR2xT5/DelXWjXOk3Nv51t dEtPvYlpGJyWJ65zjntgY6U0+v8AW6/P9Q/r8LFWTRNN0Ga51rToDbSrbSBra3wkdw2N25lA+Z+O vXk9a53+z7fUfhsviRQF1r7AbtdQQ/vlkAL439ducjb0xxiuk0Hwla6CSy6hqd+eRGL+7aVYl9FX gDjjOM+9Ng8H2NtHLaw3N2umysWbTdy+RknJx8u8An+ENt9qT2t/S3Gn3X/BMI3U19428GXdxH5c 0+mzySJjG1iiEiu2u7eO7tJbeXISRSpIOCPcHsRWRe+Fo73xFaa4dUvoZrJSkMMXleUqnG4YKE84 55z6YrXurdbu1kt3Z1SVSrFDg4PXB7U3qtPP8yYqz18vyOIj8R6kfD9lrf2d5ruC9+xBU4GpRl9u 9B2zjcM9Np7GtbxTNJba94XniDb3v2hYD+40TZB/IH8K3Bptqs9tKsYAtEKQRjhI8jGQPXHH0z6m s5rca14gtb3aTaaZvMTkYEszDblfUKuRnuW46UX1/r+tf1Do/wCv6t+huVznioWktzpdtdu84kmc jTEjD/bcIflYEgbVzuO7jp7Vf0vTbiy1HULiS+vJ4bpw6Q3MocRHnOzA+VcY4yelGq6FBql3Z3n2 i4tbuyZjDPbldwDDDKQykEH3FLsPucr4aaSGz8Y6f5K20FpO4hto33JCrQg7V4GB3wOAScVX0q+d PC3gbSjuW31Has7Biu5VjLBMj1IHHcAiumHg+1j/ALV+z6hf27aqQ07JIrEHbtJXcp6j1zjtiiDw Zp8Xhy30Oa4urqC0ZXtpZWVZYCv3SrIq8j1IJ55zTT7/AN38Nw/4P47GXc6fFonjXTLDSoPs2nat b3Ed1bWxMcalACJFC42NzjIweRVTwfo1rd+F5bh3K3dne3n2W6lkYmA7nQHJPIx1zmuqt9DEJaaT Ubu5vTEYUvJhH5kSnn5QECDnH8POBnOKq6P4St9H0u701dSv7q2u95Zbho8qXzvIKopyc98+1Lpb y/Uf+f6GH4auorHW7TSdU0WTRtUKuRJF81vqDbfmfcOr4G75huGT61seN9Sl03R7YpIYo7m+gt5p VYqY42cBjntxxntmrtv4fhhvYLqa8u7v7KD9ljuHVlgyNpIIUMxxxlix5NWtV0qy1vTZtO1CATW0 67XQ8fQg9iDzmm3sxIzJNC07Q5rnWNMh+yzC2kBt4MJFO2NwZlHV+PvdeTmuUtdJ1zWtG0rW7G00 i2v8RXDaqb+Qyyr1dXAhGVPI27iB26V1mg+ErXQSSuoanfnBEYv7tpliXphV4A44zjPvVSy+H2la dqJubO81OG1LF/7NS8YWu4nJPljr9Cce1C0YnqjN0vQdGuviH4l+0aRYzbIrZ1326NhmVtxGR1Pc 96x9F8nQvheNR02ytYLu4u/s8s6gRMUa5KfNIBkAA4B5x2HFegJoNtHr82sxTTxzXEaRzxKw8uTb naTxnIyRwQD3Bqta+EtMttJutIfzrnT7lnJtpmBWMOdxC4AOM8jJJHY0lov6/rUrr/XYyLDw/q9l 4ptNTt7HSNJsmV472G1u3f7ST91sGJBuB7nk5NaPjbULnT9Fh+y7d1xeQ27FpTGArOAcuASuemQC Rml0HwdaeH5/Mi1LVbwLxDFe3jSxwD0ReAOOMnJx3rV1XSrLWtNm07UIFntp12uh4/EHsQe9D6f1 1EjlrHwzqEPiMXEmmaNp+k3UDw3tjb3LSrcseQ2wxIu7qCepBrItNC0nTNak8I3dnA2h3l39ptpW j4aZQCbct3I6g9xlfWuq0jwdBo0cqxaxrFw7IUie7u/N+zAjH7tWG0EepBpL/wAGwaj4dt9EuNW1 Hy7eVZVuFaITFlORltnUHuAD6k85ezX9db/gHf8AroZWraJpNz8TtJS40uzlRtOmJWS3RgSrIF6j sOnpVOS01HxautL/AGVplxLBeS21vcXF88ctoV4UoqxNtPRshsnNdZL4chnvNPvpL68N3YxtEJwy BpkbG4Phcc4ByoByODVHUvAmm3+stq0N9qem3MuPtH9n3bQi4x0346/hg0uy9fzvcPP0/K1jFtdO uE8caFFqtwbm7fSphdlLh3ikdCi5CnAHfIAGec07TrW5WHxfo2kSRWiwXaCzjJ2RoXRGKDH3QxyO P71b0nhGFtftdYi1TUIJLSLyYoEMRjCHG5TuQsc45JOfcVFa+CbaC41CWXVtTuf7SdJLhZJI1BdS CrKURSpG0Dg/4073/H87i2/D8rGb4en0+9urrRptGufD94toRLp6MY4mUnmSJ4yB1OCy4J4z0rF0 PU57T4baBAJJAuo6r9mnm3kMEaZy3zdcnGM9ea7pPDyrNNcvqV7LeSRGGO6fy98CE52oAm3qByQS cDJNU9P8EabY+Gn8PSz3V9YsxZVuWTdGc7sqyKpB3c55INCf6fmPp/Xb/Mz9Y0+DQPEehyaPbi1j 1G5e1vILb92sqsjNvIXHzDbnd1rF0/SrSbwH4o85Gma0vLw27zO0jxFPuMrMSQwwPm68da7e00FY HSW41G8vp4VZYJrkxloQRg7QqAE+7An3rNt/AsNtpGo6Ymu6sYNSd5JyxgLZf7+D5XG7v+mKl7NL t/kNPVN91+v+f4Gv4fuJbvw5ptzM26WW1id2PclQSa5/Q47bxRda1e6lAJZbS/ktbYPybZUAAKf3 WJJO4c8jnAFdHo+mLo2lW+nJdT3MdugRJLjaX2joDtUDgcdKqnw3bJq0+o2t3d2bXX/H1FA6iO4O MAsCpIbHdSpqp2cm11uTFWikziPDl68fhXwfpJLC31C7mSdt23cFMjBSR6kDjuARW5PYR6F420ux 0mD7Np+q286XVtb5jjUoARIoXGxucZGOorQtvAujWuhLo6fanhSYTxyPcMZIpAchkPRDnngAcnjm tC10RbdzPLfXV3eeUYku5/L8yNTzhQqhRzj+HnAznFDet/62H/X4nncdpBJ8KPFUc0YnFve3flGc mRlKnCnLZOQB1611urafZad8MdWisbOC1jbSZnZIIwgLGE5JAHX3qbTvBNlYaRqOlSX19e2mpF2m S4aPIZ/vMCiKQT+I44xS+IrL+z/h1rVt9pmufL0udfMnILNiJgM4AHbsBQtvu/BCtr83+JZuv+R4 0v8A7Bt5/wCjLWtqsW6/5HfS/wDsG3v/AKMtaztL1fxBqbazGsmnqtjctDDdtauEfaAWBTzMnBJG dw6dD0E3KsdXSVxtp4z1DUND8P30FnBHLqtysLRuS2Rlt5XkYAVS2T7DFbC668nia+sF8n7Hp9os txJzuWRiSF64ACrk/UU2rb/1YX9foTaLr8esz30C2N1aS2EohlW42csVDcFGYHgj86fqmsppVxZR SWdxMLycQLJEY8Ix6ZDMD6n5QeAa4211XWPD/gV/E4jtttxO17cW86sZJUkcbQrAgIQpUAEN07V0 F239qeNtLtwP3en2r3rg9Q7/ALuP9PMp21S+/wC67Do3/Xl+hvi6tzdG0E8RuAm8w7xvC5xnHXGe 9VrvVEtL+zshbzzy3ZbHlKCI1Ucu5JGByB3OSOKwNJ1vD69rGq/YGh02U2yXdvamOR1QZZTl2Jwx wAD1B45p41vV21uwiWKwLXLYuLJFZ57aHDEO8gbA7Dbt65AJ60l0B9TqqK5PUPFVzLZ3N1pU1nDF DI0Vu1zG0r3si5BSONWU43DG7J6HjHNWL7XNTg1DRbFo7axe/jLSy3CtIgkAB8lcMvzHJwSf4Twa FqD0OkoqG0a4e1RruNIpiMsiNuC+2e/1rndN1bXtR1PWrNJLERWMwihujauF3bdxBXzPnxkDIK9/ pQB1FFcjpPjWXUdA0+f7Ij6nfzSQRQRuQjFGIaTJ5CADPryByauWWpa2/iWfSLl7F0gsxO08UDr8 zsQi4LnptbPPPGMU7B/X6HRUyRikTOsbSFQSEXGW9hkgfma5PSNf8SatpcM1pbWFzJ9tMc02GijE Ak27lUsxLFRuxnjI69DueI9ROk+Hb++UZkihYxj1c8KPzIpPa41vYfo2rxa1povorea3Qu6bJtu4 FWKn7rMCMg9DU+n6jaarZpeWMwmgckK4BHIJBGDz1Bqro+lf2b4ctNLWR42ht1jMikbg2OSMjGc5 PSppJLHQdKeWWRYLS2Qs7yP07kknqSe56k05WTZK1J5bqCGaGGSQLJOxWNe7EAk/oKLq7t7K3e4u 544IUGWkkYKo/E1w9hqFprnxKsLm2v7e9MOnzyOLeZZUt9zIqrlSRnGc+pPpirGmv/wk/wAQ9Tmu jvtPD5SC1gPK+cwy8hH94dB6UW2/rrYbe50A8T6QNxlnlt0VgokubaWFHJ6BGdQHJ7bSc1rVXvLO G/gENwu5BIkmPdWDD9QKsUgMXwp/yCJ/+wlf/wDpXLW1WL4U/wCQRP8A9hK//wDSuWtqgArF8V/8 giD/ALCVh/6VxVtVi+K/+QRB/wBhKw/9K4qANqiiigArFtf+R41T/sG2f/oy6rarCSZLfxhrE8hw kelWjN9BJdGk3ZXDctvrcKawunNb3GH+UXW0eT5mM+XnOd2OemO2c8Vo7l3bcjdjOM84rzuXxVqM +m2Wr6fFqd000kckmlro0pgMbNklZPKzvAOd28gkcCrul22ozfEHxCI9bvF8mG3Mcckcbx/MrkKy 7QdoJ6KVJ7k1VmB3FFcToes6zceHZdd1HVVCadcXX2iKO2ULcRxlgBzyhyARgnpznNQHxPqwm0y+ s/7Vvhcyxrd2J0eVIYo26ukhiB+XjqxB56UJXdv61B6fj+B3tFU9Wa7TSrl7GaOG4SMsjyxGRRjn 7uRn865aw13VIfBVr4sv7/zkGn+ZLZrCoWSQ42sGAyPTHI59uV3/AK/rYDtaK4ddf1ePWtPW0k1S /gvG8q5S40WWGO1JHyyKxjU7c9QzE47iorTVvEN34S1zUJNXVLvS7m4WNobZFSQRdmDBvlOOxzz9 6jbUFq0l1/r9DvaK43UvFnkw6JcXt5LpNhqFsJXvY41ZVlIUrGxZWCggtyR26ip7/wARy2cOm2kt 0zzagZW+1WFq1wfKXkMiIH5IK8kEDnOabVhJ3Oolk8qF5NjPsUttQZY47AetRWN19usYLr7PPbec gfybhNsiZ7MOxrkdP1vX5YNctVe6K2cQmstS1DTHi81cZZGQiMFhjGQB1zjjlU8TamvgLQtTdwbj UXgjuLoxjbAHOC5HA9h2yRmi36fiP/g/gdrRXIR3fiGPxVPoFvq8E8MdkLn7Vd2QkkVmYqFby2jU dMj5eRn61mR+INfb4cP4mfUx9qtJJHaNIEEcyrKVKsCCRwOMEH1JpeYeX9dzvbieO1tpbiU4jiQu x9ABk1Fp16dR0+G8NrPa+coYRXAAkUHpkAkA/jXOat4jE+rSaOs1/apHaxzSTWWntdPucnavCOqj CnO5ec8YxVK08ZajFo0Cana3cF5NqDWccx0+UPLGAWEqw7dxJUYwBgHtgYo/r9A/r8LndUVyfh3W dTl8R3OmTDUrzT/s4mhv73TntmV84aNsxop4wQQB361pa/q8ljcadptq6x3epzmKORl3CNQpZmx3 OBge5FFtgJR4hsz4k/sDy7kXfkmbc0LLGVGOjHAb7w6Z71q1wz2d7F8SrS2m1OaZjo84jumSMSrm ROoChDjt8v1HrUi13XpvhZqGrnWJV1GxkuNtwsEXziNyAGUptxgdgD70fZv/AFu0O2tv62ueiUgZ WJAIJU4IB6VWsJJLnSbaWSQ+ZLArM4AzkqOfSuM8H2Gq3mna20fiXUI5/wC0biJHeOBwGVgA5zHk nAxjOMdAOKGrNrsSndJ9zvaK4rS9S1a+8FeW2q3A1wXX2SSXyod0cwfBAXZtK4y3TOO9P0641+48 WatoNzrhMVrawyRTw2saSAsW5OQyk8DPGPQCnb+vxH/X42Oyorg7fxreW1tJpuoM0moQ6o2nm4t7 ZpC6hS/mCNASW2jGAMA89K0PDus6nL4judMmGpXmn/ZxNDf3unPbMr5w0bZjRTxgggDv1oSv/XzB 6f152OsrKHiGzPiT+wPLuRd+SZtzQssZUY6McBvvDpnvUWv6vJY3Gnabausd3qc5ijkZdwjUKWZs dzgYHuRWF5dxYfEyzF5fPeJHo87CaVUWTHmJkNsVV+mAP6lLfXbX8FcdtP672O3orzubxhqlxplt reljVrmWRkc6YmjymF4i3OJfKzuCnO4PtJHSvQJJHFs0kcZZ9hZUPBJxwKHorsXWxJRXH+GPEbaw 8ONYEl0pLahp1xEkclqQpyqDAbaGxyd2fWsy68Yand6UutaO2qTT790emx6RK8E0e7GPN8r723nc HxnsaOtgWp6HRXHjUNevvGF5o6aktpbvpi3MDLajzIGZtoyGzuIx7DnGO9LpEmtaf41m0rV9euL6 3kshPab7eGMOQcSZKoDkHaQM9G5zQv6+V/8AIP6++3+Z0uo339nWn2j7Jc3Xzqvl20e9/mIGcZ6D OT6AGrVcDrep+ItI8KvrFvrZmWW9URie2jYiFpAi7SoUDIO7JDduldDe6lPeeIh4ftLp7R1tPtU0 8aKzgFtqhdwK9QSSQelH9fhcH/X32N2iuXvtW1Tw5pMceqXKXdxcXot7aeG3Z3KEZ3NGg5cANwow eOlQ6FrOpv4nfTn/ALTvtNlt/NS8vdNe2aGQHmMny0UgjkcZ+tC1/r5g9P6+R11Fcv451PVtIsbG 50y7hgWS9hglV4N7MHcDgk4HfsevUUzUb/V9F8TafaHUftVrrHmRJ58C/wCizKu5SNm0shwcgnP+ 1QtQOroritC1jWLnw9Jrmp6sqx6dc3X2mOO2ULPHGWAHqp4BGCenOc06+1TXLTwoniyO/wDM2263 MunmJPJMZwxCtjeGCnqWIyOlH9feHl/Wh2dFcbHq+r3/AI5XS49TWLTrrSvtkPk26iSPLAD5m3Ak cnOMc9D1qBfF97o8Wu2Goypd3mmTwxW87IF84TYEZcLgZBPOMZx0FOz/AK9bfmH9fhc7miuV1a/1 Twxd6fd3GovqFjeXSW1xFLDGphL8KyFQDjPBDbjg9arWviSa61660+TVhZanFc+WmmXMaKkkIfh4 yQGZmQE8MQD/AA0JX/r+u4PT+v67HT6rqUek6fJeSwzThSqrFAoZ3ZiAAoJHJJHerSMWRWKFCRkq 2Mj2OK4nUfEk+oT6klnc6javp87RW/2XSZLpJZFXnewjYYySMKVIx15rpvD2oXWq6BZ3t9ZyWV1L GDNBKhRkboeDyBkce1Jaq4PR2NKkLKpAJALHAyeprh9S8UXd6upPpl1qUE1jNJFbw22kyXEU7p1D uI2GC2R8rKQOpqvdTanrHijwpNJe6jpL3lnPJJaqkYMEiqM/LIh5+Yj5geOmKFr/AF5XB6HoNZeu +ILPw9bwzXqXDLNKsSmGEuAxIA3HovJHUip9W1KLRdGutSuNzR2kLSN6tgZ/M1xXi6PVJfB9vqF3 qPmi5urR3thGojizKpAQgbvTO4nPtQtWl5r8Qei+/wDA9CorkdV8QtPq99pcF7qNkbIIPNsdNe6L Oy7sMRG6gAEccE+orU8J6nqGr+HoLrVbKSzvMsksckLRZIONwVuQCMH8aFqrg9CSLxJZTeJpPD6x 3Iu44DOzPCVjKggcMcbuT1GRwea1q49v+SxJ/wBgM/8Ao6qOreItX0hILy61ILdm/SGbS0SOSKOF 5CqlmVSysVwclsE8Y7U1ql5/5tBLRvy/yud9RUVys7W0i20qRTFTsd03qp7ErkZ+mRXn8Ov+Ibn4 a3HiM6qqXlnJM+1LdBHKqSEbGBBOMDsQfc0h2PRao6rqiaVBFI1vPcvNMsMcUCguzN9SBgDJJz0B rA1PVtT0zVPD9yb0yW+q3C281oYkCJuQsGU43ZBAzkkH0FZl94qvtQsrvUNLl1JLi1llW0tYdHkm hn2ErhpBG33iDyrLjPPSjYS1O+LqMbiAW6A9TWbo3iCz117xLSO4Q2U3kyieExHdgH7rc9COoFct M2oar440GX+0NR00XWlyTtbBIwYWymV2uh55wc88cYp+kQ3supeMfsmoPZOt8GWSONGbcIUIzuBG PXjPuKNrt9n+DsC128vyud1RXH2Hiy51PS/DUSskF9rcZd3C5EaouXKg8ZJwBnpnvipl1q70DxGN I1W9a9tZ7OS6gupI0WVTH99W2AKeCCCAPfPWm1Z2f9WEtVf+tTX1/XrTw5pcmo30dw8MfXyIWkI+ uOAPc4HvWjG4kjWRc4YAjPvXnniafU9X+GN9rjX5WK8tPMFl5aiNI2II+bG8uBjJzg+g61r6h4h2 6guix3N/aGKzjmeexsGupMsSFGBG4UfKc5HOeOlFrb7j7Nf1sddVLU9TTSoI55beeWJ5VjdolB8o McbmyR8oPUjOKzfB+q6lqulTHVbWeGe3uHhWSa2aD7Qg+7IEYAjIPPvmo9elvzqP2eTURpemtB8k 0YieWeYk/uwjq2QFGcBcnPXrSegLU6OisDwTrc/iDwta6hdbfPZnRyqFASrlc7T0zjpWbqXiSSHx Jd6ZPqw0m4VR/Z0U8a+ReZUcliMkhiRtVl/Gm1rYEdjUVzP9mtZZ/Kkl8tC3lxLudsDOAO5rmIb/ AFSP4ktpMmoySWUul/aRC0cY8qTeF4YLkj6k9azrDWdfGgeK3OqrPc6RdypBPcWyH92iBsFU2DJ5 5/TtUva/lf7nYaV3b0/FXO3tZ/tVpFceTLD5qB/LlXa6ZHRh2NTVwWp6lrw8H6D4gi1qe3jZLdtS EUELbo3xukG5Dggn6YzxW7qS6rca1t0zWWtooLQvLG0EckZcn5CeA3QMSAw6L75qSs38/wACY6pH QUVxOja9qreCrfxbqWob44bSaWe0SFAsxBO0hsZUjGPTn8ajHiPVo9T0ya2OrahFdzLHeWz6NLFF bqw/1iOY1OAcZ3M3HpRbWwX0ud1RWV4nub6y8N395p08UNxbwtKrSxeYPlGSMZHXGM9vQ1zF3ret 6b4L0zxW+pG4Aht3vLRoYwkivtDMpA3B/mz1xx0pLX8PxHY7yiubt7678SX2pw2GpyafDp04gVoY o3aSTaGbdvU/L8wGBg8HmuevfFesz6DbXsV6bO9s9YXTr2KKJDHP+8Ck/MCy5GCMEdT14ppXaXp+ P/DoHtf+v60PRaK5TUL7Vrf4g2Wm2+pkWt7YzSCCWFGSORMAEEAMRzkjd+VN8I3eu63YRX15qyA2 99PFNHHbKFnRWZQPVcEA8E9Oc5pLX+vOwPT+vK51tFFFABRRRQAVi+M/+RH17/sG3H/otq2qxfGf /Ij69/2Dbj/0W1AFfWryPT/E1peykCO30i/kYn0D2xrL8PaR4guPCUOm3a2ljFeI0txcQzO07eaS 7jYVAQ/MRnc2PSr3iLRbHX/FGmWGpRyS2zadeFo0neLd+8tuCUIJHPQ8dPSt+3gt9MsVhWR1ghGA 08zSED3dySfxNHe4drGNN4dnj17SbixFtHYadaSQRxMSDEzbQGUAYb5QRyR171W/4RfUZNP8RWrX VvG+rSt5coBYiMoqANwMHAPTPLZ9q6uij+vxuC02OdOh3uqx2dtq0Vpa2Nm6utnaytKJimNm52VM KCM7QOSBzjip7DSL621/V9SlkhIvDGINpJIREwFYEcfMWPB71t0UPUFocZ/whV3deAH8P3txbi6k bznkQF43l8zzCWyASCeox0rb0vT7yK0igmt7HTY0Uq1vp53I/GByUXA9gPTn1v32o2OmW/2jULy3 tIchfMnlWNcnoMk4zVhWV1DKwZWGQQcgije4HJeFvC1/4csH0yKHTIY1JCajAp+0SKT/ABoUxuxx ncRwOO1T6zoWr6tY3WmSS2slvdTGRbl3YS2gBBXYu0hmGM5yuCe/fp6Kd9bgQzTJZ2ck0r/JDGWZ m9AMk1xvhqx8RXnhcROLSxj1MvcyXSyu04ErbiBGVAVsNgHccYHFdVq+j2WuWLWWoJK9u/30jnki 3jGMEowJHseKlsLCDTbOO0tvN8qMYUSzPKwHpuck/rS73DtYwR4Xm07xDpl9pK2/2OzsWsvs8zlf KUkEOuFOTxgg4z60620PWLaXxDc/areS51E/6K7FhtAjCoG4+UBtxwM9fWulooeqs/6vqC0Zn6Fp MOhaHZ6XABstolTI/iPc/icmq/iTSrrWLW0t7dogkd5FNOsrFd6I27AIB5yB+VbFFNu7uJKysNQF UAZixA5Y96x4odduNfMl/b6eumRAmARXDtLv7MwKAdO2eOevGNqil1H0OVttK8Qjx3Nrlxb6b9kk thaqqXchkjQMW3YMQBJz0yPrUraBqGleIL3WNCa1kGo7TdWd07RqzrwHV1DFTjqNpz7V0tFG1g3K lql7IVmvfKiYD/UwOXUHvliAW9uB/hboooAxfCn/ACCJ/wDsJX//AKVy1tVi+FP+QRP/ANhK/wD/ AErlraoAKxfFf/IIg/7CVh/6VxVtVi+K/wDkEQf9hKw/9K4qANqiiigArDhjWXxnq0bjKvpdmpHq DJdVuVi2v/I76p/2DbP/ANGXVDAx9H0DxforppNvqumyaHFlYpJYXN3HHnhBgheBwGOfp2rQj0bU 7DxRqerWf2WaK/t4l2TSsjK8YIA4U8EHr1Hoa3YLq3ulZreeOZUYqxjcMAw7HHepaLsDlfC/h7U7 LQb7R9bisjFdSTPutZ3fIlZiykMi4xnrk59qj0PR/GWmPHpdzq2m3GjwDZHP5Ti7ZB0U4IQHHG7k 111FMCnqyXkul3EVhHBJcSIUQTyFE54ySFY/p+VYWkeGbtvAQ8Ma0LdNtt9m820mZ9y44b5lXBz2 56da6mmSyxwxPLK6xxoCzOxwFA6kntS6MfVHM6NY+NrZxbatqWlXNpAB5csMciXE+Om852pnjOAe 9Z9l4d8T23hrXdMkh0kzanNPLG63cm1PNzkH91n5e3r7V20U0VxCk0MiSxyKGR0YFWB6EEdRT6Hr e4k7WscvY6V4gtdGs7WaLS7kQWa201m8zmKUjgNvKfLwORsOc4zxmqLeBr2y0WxXRtQhtNT064mn tyUJgAkJLREddmCBnrxmuxuLmC0hM1zPHDGvV5HCqPxNSU229RJJaf12OdS08VXGg3a6lJpUuozR NFHFbmSK3QHgksQzE/gPTvmsj+zfEGm+DdJ8PQy6WmqROsaRu7ywXMaDLb/lVgPUYPQDPNd1VPUd KsdVjRL2ASeWS0bhijxnGMq6kMpx3BFL/gfgM5TRrfxhoTrby6N4WS1nJVY9L8232ybSQzZUjHHO Bn61Wj8KeJ1+HVz4YaPSTcTM4Ewu5NgV3Lk48rOQTjH457V2tjptvp6bITO/X57i4knf6bnYnHtm rdMFocdfeH/Esd3b63otzp9rqptlt7u2uGeS2mVTlSGADAjJ7d8Va1Pw7rGr6NbtcapDBrVtOtzB PbxHyY3AI2hWJJUgkHJyc/hXT0UgWhi6DD4mwZPElxppdRhItOSQKfdi5yT7AAdevGG+JNCn1VrG 9sZo4dQ02fzrdpQSjZGGRscgEHqOlblVbnU9Ps7iG3ur62gmnOIo5ZVVpD/sgnJ/CgDCOi65c+Lb DXpZbC2WC1e3mgTfNkMwJ2sQvoOSPwNUD4Q1dPCus+HIZbIW928z21wzvuxIxYq67cDBPUE59BXb UUdLf13DzKWkW11Z6VbW17NDNPDGEZ4YyinHAwCSemO/5VneG9FvdEm1KGV4JLW5vZLqJ1Lb/nOS rDGBg9wTn2reqvf2NtqdhPY3kXm29whSRMkblPUZHNDbu2CSskc/ZaLEPH1/qMMxMAijaSAY2rck Fd/+95eAf94VnRNqSfE/XG02G1nf7DbBo7iVogeW5DKrflt59RXWaZpWnaFpyWWnW0dpaxDhF6D1 JJ5J9zWfpOg6B/aDeIdMkknnuh81ymoSypKOeMFypA7DGB2xT6ryDo/MzrvwXcTaUXt9QW31n7cd QW7WPKCbGNu3uu35f1rU0GHxNgyeJLjTS6jCRackgU+7Fzkn2AA69eMbVFIDD8SaFPqrWN7YzRw6 hps/nW7SglGyMMjY5AIPUdKpvoWt3niqx1ueSwt0itHt57dN825WIJCsdvoOSPwNdRRR/X6AzjNI 8P8Ai/Q5F0qz1XTZNDjJEUk8Lm6iQn7i4IU47Mc/TtXXTxu1pJFE5VyhVGJPBxwc1LRQ9VYOtzlz 4cvr7W9M1DUksFm005+2W+7zbnKFSrKR8i5Ocbm6dqqab4f8XaFdHT9L1PTH0MyM6faoXa4t1Ykl E2kKwBPBJ/Cuzop3A5a30fXYfHcmstFYNYvaLZ83TmbarFt5Hl4JOemfxq34o8PTa39hms7kWt1Z z7hNjnymG2RfxU8e4Fb1FLsHVv8Arscz400HUda8PR6TpCWaASxsTcTMgRUYMAAqNnOMdse9Q654 f1241Gy8QaJcWVnrEMHkTwzlpLeZCc7SwAbg8g4H4V081zBbsizTxxGRgqB3A3H0GepqWgDmdR8O 6trWgrHfanDBq0UyXEE9pCRFBIvTCsSSOSDk856VZ0GHxTkv4kudMJTiNNOSQBuOrlz+gArdooA4 /wCJgc+HrMRlQ/8AadrtLDIB8wYyK0H0zVb/AFKDUr+CxWTT1kNnbxTsyvIwxvdygK8ZGApxnOTU 3iPRdC1WGKXXWZYYHUoWvZIED5+U/KygtnoTz6VrxRrDCkSFiqKFBdyxwPUnJJ9zQtvn+iB7nMeF /Duo2eg32j67DZNDdSTPutp3fcJWJZSGRcYz1yc+1Nt/Dus/8I+fDF5PaS6cI/IF4Hbz2h6bTHt2 htvG7d74rrKKAOEvFu7f4rQppcNu7x6HtWKeRo1KiXGNwDY/75P9a0rjwaNU0vVE1CZUv9UlSZpo BxAyY8sKTgnbjqcZyelaI8LaSuvf24Irn+0MbfNN5MRt67du/btz/DjHtWxR0Xf/AINwe+n9aWOd /snVtXWzh14WSxWc6Tk20jObl0+6SGUbBnBwC3TGaq6t4Z1LWoI7K/FhNHHc+fHfEsJ4AJNwVVxy cfLu3D6Gusop3A5C50DxPpet3V54Yv8ATvsmoSiW4ttRR2Eb4wzoUwTkAcHFdTaRTQ2yJcTedNjL uBgEnk4HOB6D0qail0sHW5x8mgeKtJ1q6n8N6hppsL+Yzz2+oRuTC5xuaPYRnPXBIq9qGg6hLrei 6rbzwzS2AlScTkrvEgGWXAPII4XpjjIroqKFpYGU9U02HWNJudNusmK6iaJyvBwRjIrl9Q8N+JdS 8Kx6FNc6cr20kJivMuTKsbAgtHgbTwOjEH2rtKKP6+4DkNQ0DxTaau2seHtQ037TdxIl9b3kTiCR lGBIu0lge2M/jXTWEV1FaqL6dJrluZGjUqmfRQSSB+JqRLm3kuHt0njaaMAvGHBZQehI6jofyqWg Dln0XWm+IQ10R2IsRZfY8faX83Bbdv2+XjOeMZ/HtWZJ4M1tvCY0IS2BaC9W5S4Z3LXOJd5L/L8r e/zZ9q7ieeK2geeeVIoo1LPJIwVVA6kk9BVbT9Y0vVg503UrS9EeA5tp1k256Z2k4oWm3T/O/wCY PXfr/lb8iaU3S2bmJIpLnYdqs5RC3YE4JA98H6Vwtt4T8UQfD288MtHpLTXLSATi7lChZGLE48rO QTgDv7YwfQaKO47nF6vonifUl0ApbaSj6VOtxKDeyYkKgrtU+TwCDnJ+mO5dD4f8WaJqMyaBqGln S7qdp3hv45He2ZjlhHtI3AnJwSOtdlRTvrcmxz15oV+fEel6vazwym1t5becXDFSwfad4wDk5X7v A56iqGlaR4msLjX55LbSnbVJfOhVbyTCNtCYb910wM5HfjHOR2FFLpb+tdRnDad4O1i20DRUeWyh 1fQmIt5I5HeKZCMMr5UFcj0zjAPPSttdDm1PUP7R1uK3SVbWS1S3t5GkVFc/Od5VSSQAPujHPXNb 1FNu+4LTY4qXwrrreDbnwmLixa2EPk212zOJNmeA6BcZA4yGOcdBUt/4c8TQ3VrrGi6lp41VLZba 6juIXW2uFBJBwCWUjJ78+1dhRSu9wKWlRajHaBtVuIJrt+X+zoyRL7KCSfxJ59ulZcujanH4yfWb d7Wa3ntFtys7sHtiCTlAAQwOeRlenWtbUNV07SYll1LULWyjc7Va4mWMMfQFiOamtrm3vLdLm1nj nhkGUkicMrD1BHBo31DpYxfBmh3vh3Qv7OvZIJGSaV1aEkghnLAnIGDz05+pqDXtB1LWbS/0+aPT ryzvGPlm5LBrQbQMqADvIIJHK49a6aih67hfqcy/hy+s/Eenavp7wXHkWP2GdbmRkYpkEOCFbLZH QgZz1FZ6eFdftrDxLBDcadOdalkeNX3x+WXXaWLAN0Azt29f4q7aih67+f4u4LTby/AwtH0WdfBs OhaxFbkrai1kEEhkR1C7c5KqefTHHrTNF0bU9F8MtatNDf6mVwZJXMaPgBVyQpIwoHbk59a6CiiT 5r36gtLeRyvhzw1e2/gc+GdcW12+S8HmWkzPvVs8/Mi7SM+9JoemeM7KWOx1LVdMuNMgAVJ44XF1 Ko6Budq+hIz+fNdXRTvrcVtLGT4r/wCRR1j/AK8Zv/QDXO6HpWp654L0XTr1bNNM+zW8jyI7NJMq hWCbCuF5AydxyM8DPHWarpVnrVg9jfLK9vJw6RzPFuHoShBI9ulGl6XaaNYR2NisiW8QwiSTPJtH oC5Jx7ZwKS0v8vwv/mN7L5/jb/Ix4tE1PRtdvr7R/sk1rqTrJPbXMjReVIBgujKrZyAMqQOR1qvq Hgx5vDUlja3EX25r4agZZFKpJMH3kEDkL/D3IGOtdZRQByd/oniG68Sabr0L6bFLaW0kT2ztI6sW IyA4APb723j+6aseC9J1jRNOns9VjsvmuJJ0e1nd873LEEMi4xnrk59q6SimtP6+YBRRRSAKKKKA CsXxn/yI+vf9g24/9FtW1WL4z/5EfXv+wbcf+i2oALr/AJHjS/8AsG3n/oy1qzcf6fqaWo5htcSz ehf+Bfw+9+C+tUdTmNv4u0+ZYnlZNLvSI0GWY+Za8CtTTbV7S0AmYNPITJMw6Fz1x7DoPYCgC3XI eItSurjXtBs7aXZZzajtkK4zMY1ZyP8AdBUfU59OdPUNY8zVo9EitdRUzcS3iWcvlRjGcCQLjJ6Z BwOecjFcxcWdppnxA0VbSy12S0skmEsrx3lzEjsoVApfcAME8rx6miO6B7M7Ftctl1+LRfLmM8sL yq+0bMIVBGc5z8w7Y681WuPE8Eem6tew2lxOulSNHKAUTeVUMxUswGBnnPocA1n24vG8Y63fyWdx vhhitrRjEdhjALsyt0YljjA5+UZxWXFY3Y+HNlYNY3qyajdIb1WhdpEWSTfKSuNw6lcke/Tmi11/ XV6fgPZ/121Leoalfap4NtIdQtJLG51a4jgaOVk4jY73wVY8CMMOcHjkCugtNdtbnVZ9MWGeJ7e3 SfzJFAR42JAI5yPunqBWdqmmy6x4o0hJoZo7KwikunxkI0hwiISODwWJH9DWTq2l6tqmmeLpLS3l S8vCLeAOuwvFGAMLnruzJg9ORTv28/8AISWyfl/n+RtzeMdPhhS8+z3T6YzhDqKovkKS20Hlt5XP G4KV96mn8T21rq9zp1xZ3cZgtxcecFR1lUnaAoVi5YnIA2gnFYup2snijSLHQNP0+6tdODR/bJbm BoNkcZB8tVYAsSQBkDbjPNXtE06ebxXrWsXcMkaiRLW0R12jy415ceuWdgD6UW/X+vvFfT+v62Ir nxDb6ymjW6W+s2iaq6y288DRxkbcuVcb9wXC8/KRggZ5p8viq7TxLd2X9jXxstPhDTzQqkpZm5X5 VYtjAPABPIyAOS4w3F18RftEtpOLewsQkEhQiNnkbLkN0yAijHXmpPCUc5/tS8urWaCe8vpXcSoU wqnYgGeo2KDkcc0f8H/Ib/y/zJ7fxXYXfhxNetobqa1Z9hVISZF+fYSV7AHk+gFbdcf4Jtbj7DfW s0Lx28Oq3LKWH+t/eEjHsD+o+tdhQHVoKKKKQBRRRQAUUUUAFFFFAGL4U/5BE/8A2Er/AP8ASuWt qsXwp/yCJ/8AsJX/AP6Vy1tUAFYviv8A5BEH/YSsP/SuKtqsXxX/AMgiD/sJWH/pXFQBtUUUUAFY cMaTeM9WilRXjfS7NWVhkMDJdZBFblYcMgi8Z6tIwYhNLsyQqljxJddAOT9BQBifD2yt38N6zYiB Bbtql3F5S/IoXdjaMdBjjjpWvElr4I8LxwokssUUojhhVy+DI+FQM2TtBYDJ7Cs74ctKljqkU9ne 2rvqU86i5tJIdyO2VILKAfp1HetXxbPqlvovmaUkrP50YnMCb5Vh3DeUXu2KOi9EC3fqyG38RahJ qF9pFxptvDqdvai5iVbsvDIpJAy+wMDkc/LXODxZ4n/4VjL4gNrYCVoy6S/aXLAM5BOzy8AjIAG4 /XsbWnac0HxCe8tNNvUs7nSBEtxNG+XfzMnez/MGwf48Nx0qpDpmozfByfRF066W/t4WjaF4ipZl kzhc/eyOhGQfWn0v/W7/AOANfF/XZf8ABOtGrX0MNrbTWdsdUuVZo7eO6Zo9qgZZnKAgcgHCnkjr Wc/i9ZNK1lbvR2lu9J+W9sUlR1KFd24M20MpXPUZ4IxWb4qs2u5tI8Qjw4+tWltE8VxYTWwMu1wp DrG4zuBXGMA809xZf8IZrFzpnhC40cXVq8KQLpwS4mcqQMxxZIGT39T0HWZbMIbxRfPi4Wem+HpI dEk8nVxEkYikQJAWXITsTwD2A46ir9r4hY67d6RqNqlpLBbi6SRJvMR4skEklVwQRyOR71x9xcTL 4d8FRDS9WaSwuIHuUXTZyYlRCrEjZ6n8e2at6vDLrHjm+to7XUIobvRHsVu2sZREsrMTjcVxjB69 O2c1ct3bu/yuvxJjsr9l+dn+BF49vn1nwPLfvo8f2JmiezuJHDTLmRQH2bfkBHQhicHkDmujn8TX UfiN9Bt9GkknFm1zDJJOqJNggYGNxUZJGSB06HrXN6o2pXvwzbQRot//AGpaxwQvCIG2MUZfmWT7 rKcZ4JIzyBzV6K/lm+JNpdyaTqkER0s27u9lIUSVnVgpdQV6dSCVHrRZXstrv8tA6Xf9ao2pNe1G SKQWOkxz3Nqim7hkuwnlMV3GNWCsGYAj0HI5q9oes2viDRrbVbIt5Nwm4Bhyp6EH3BBFcTq2nw6N 4r1G61PwU3iGz1ORJYbi3s47mWFggUowbkL8uc5xzXTpqNt4f0yxQaFPZwXMu0QWdqCtqG5zIE4X 3IyMnv1pLVXG9Dcmmjt4JJ5nCRxqWdj0AHJNYkev6hI9lcLokkmnXrKqTRy7pYw3R3j24VfcMSM8 itDWtP8A7W0O+07fs+1W7xbvTcpGa5rwvr+tJbW2g33hjUYb60jWGS62L9kIUYDhywzkDOACaS3/ AK+YPb+vkbM+t3k091HpGnR3ospPLnaS58rLYBKp8rbmAI67Rz161n3HjqBdM0vULPTbm5g1C5W2 J3ohgkLbSrAnO4HPQY46jOah0X7R4W1XVrK8s7ye3vr1ru1ube3eYNvxlG2g7CCOrYGO9Ymp6Zda LoGl27WF9PcS64NRmjtbaScQIZCxBKAgYBHHc5xmmul/L9L/AKg+vz/W36HXxa9c/wDCQS6LcWEc Nw1qbm1YXBZZVBwQx2/KQSOm7g1zPhz7Vrlz4pg8QWFjJYG/ZLkm7djHsRcKo8sZUYzuypBzxV27 v/8Ai5VleCw1NrWPTZInnXTpygdmVgM7PQfgeOtUfDsL6nF4s0yW01KyOr3U728s9jNEpRkChtzK APoSD7Ule1+tn+f+Q9L79V+RuzeK5rLTItYk0rGiMqnz1nzNGhOA7R7cbcEHhicdqdJ4qun1670a y0Z5riG0+1QtJcIiXCk4GCN20E55PPtjmslRfah4FfwpPpl1Dqn2T7G26BvIwAF8wS42EY+bGd3b FO00mz+JBQWeom2TSo7JLlrKXy2kVycb9uMY/izj3qmlzWXn+T/4BOvLf+t1+l/uNS08U3t5rl3o y6HJBd21ss3+kXKBG3EgcpuwMg84J9qgh8ZXdz4dudWg0YbrCSRL2CS627DGTvCHad54yMhQfWqd reNB8T9Vu5NP1MWr2McKTjT5ijOhYsAQvPB4PQ9s8Vm6bdSp4M8U2z6VqyT3VzdvBE2mzhpFlzsI +Xv+nfFQ37t12/UpL3rPuvy/zOpuNaXWbMWek26Xkl3ZrcMsk/kqkT8DLBWIJ+bGFPQ8isv/AITq 1sfDsFzaaLNshuv7Pmt0kRVtZAwTaeeRyMEA8dcVzVrp/wDZ8WnatqHg+fXLN9NgtJ4H0/fc2ssY xlY5ACVOeo44zWl4niQeDoI9L8K3Vh9ovoZ1s7XT/wB4FR1LNIIgVU4HAJz0+gtpKXlf9f8AIi7a 87fp/mdRL4jurbxJBo1zpe03kLSWkqThtxXG5XGBsIzngtTbPxYhOqw6nbLaXOklPOjil81XDjKF G2qTnpggc1k6tqIm8e+H7yLT9Ue2ggmEso02fbGZFXbn5Pbn074rGvNOutf1rxhbQWF4hvktmtHu rKWOGZoRkqWZQMEjHPXPep6ff+f+Rf8AwDr28S3VnrVtpuqaWtub9XNm8NwJPMZRkowKqFbHTkj3 qnD40u7nQL/V4dCZV06aSO4hmuVD4j+/t2hgWHPGQP8Aaqj4cbTLm7Rk+HT6NeWvzS3MmnRIiEdf Ldfmc+m0f/Xo6ZczJ4L8U276XqyT3NzdvBE2mzhpBLnYQNv5+nfFD0T9P1QKzav3/wA/+AbWs+I9 X/tjw7Ho9vaS2uqbpB51w0ZfEZbacI20cg5GckY4611m8pD5koCkLlgpyBxzjjn8q4OGO6aHwRf/ ANn3wjsA0N0htZBJExh2DKEbsbh1xjv0ruLlp/sUr20YNx5ZMaOeN2OAce9Ofup28yY62v2Odg8Y zO+lXE2mCPTtYlEVpOLjdKGIJXfHtAUEA9GbtU+neJL+/wBX1vSjpcEVzpYQxn7WSk+8Erk7MrwB ng9e9cndWl9qNl4b1CfTtUn1K31SGTUJJrd8xEAhgin+DOOUG3jJOa37CK50zx9rVzPZXbRarBA1 u8cJdNyKQyswyqnp94gH1oa3+f6f8Ef/AAPzNbwpr7eJtBi1N7QWjPJIjQiXzNpViv3sDPT0p95q 9ybyex0mzivLq2RXmE05hRN2cLuCsdxAzjGPUisj4bwXtn4Y+x32nXNnJHcSsPPAG8M7MCBnPQjq BVS7n1Pwl4x1HUF0S+1XTdYETbrCMSSQyou3BXI+UjBznih7h3IvE06ag/hPVpNJltrw6qieXNGo mQYfKZ9CRnrg8GuitPEEj69d6Pf2i208FuLmNo5TIskRJGfujDAjkc9eprB8WXt3PJ4cnfSNRBi1 JLmSKK0eZoYgrDLmMMN3PQE0s93cn4lTXNpp98w/sg28U0llKsJm3lgpcrgDHfp2zml0+b/L/MH+ i/N/oX4PGMzvpVxNpgj07WJRFaTrcbpQxBK749oCggHozdqfbeKb/UNW1bS7PQ9tzpvl8XV0qLJu yRygfHABHXrziuXurS+1Gy8N6hPp2qT6lb6pDJqEk1u+YiAQwRT/AAZxyg28ZJzWjpeqR6f8RfFM k1reOsiWn+ot2mKnyzwQgJH16cdaq2/z/QPP0/Ms6l42s5fC66lLoUl2i3Ytrm2laPFtMrhfmznO GwQVB9eKs6rrOuw+N9P0mytbKS2ltZJsS3Lxl9pUHJEbYxu4HOfUYrnNe0i7svBN4g0+9lvdW1YX xt4Ld5miXzVbDbAQCFUfjkDNdFfec3jbRNYjs7uS0eymhLLbvuR2KsodSMpnB5bAB64pLp/X2f8A MT6/11/yJrXxVf399qdlaaBIbjTZo45I5rlELK3O4EZH3ecZ59qdqXiyWysJtWg04XOlWrss84n2 yAKdrMibcMAc9WB4OAao+Frln8Z+JHex1CCO8liaCWeyljSQJGFb5mUAc+vXtWHp+mWui3suj6v8 PW1aVriRrfUYLGGZJUZiwMjvjaRnHJ7Uuw+56VDNHcQRzxMHjkUMjDoQRkGuH+JN1cXPh6YW8jR2 tvdQJIyn/XOZVBX/AHR39+OxrtYIPLsY4AiQbYwgWEALHxjCj0HauF8aeFtSj8I/ZbLV9Xvwk8G2 28mBsjzFy3yQhjjrnP1zT+0vVfmL7L9P0PQB0rjPFHgvTL2yvda1Ge6/tOGN5ILqK5kX7OcfKsag 49B0yT9a6MXMmmtY2Mov9Qe4ZlN15SEJgZzIUChR2GBXL6n4zP8AbEkE3hPxLdWlrIPLa30xmSZx /EdxGQD0468+mJZSOq0IXy6DYDVG3Xwt0+0H1faM/rWVrvg3SvEM0l1rjTSiLm3CXDxrbgD7wAIG 7OTk59O1X49bdtPsLuTSdQQ3sip5IhzJADnDSjPygAc9cZrC8SeK2t9UbS38NeIL6zQAzSWWns6T H+5kkAr64znp0zly1Yo6I0/A6agnhKyXUp5J5gG2SS/faPcdhb324qD4iQrJ4F1aUtIrw2zuhSRl wcexGfxq3a+I3n0FtWbQtVhUOESze3xckZC58vPAzk9egzVXx+zv4J1K2htrq4nu4Giijt7d5WLE cZCg4HucClU1THDdGzpH/IFsf+veP/0EVDqerNZ3FvY2sAur+6DGKFpNihV+8zNg4UZA4BOSOKXQ JxcaHZsIp4isKoyTwPE4IAB+VwD+lY2uW91p/jLT/ESW091ZpayWlwlvGZHi3MGDhBywyMHAJ9qu XxkQ+Ay9DubfSvGvii8urOLTlis7eW5SIZUt85ZgQBuz64BPfmt5vEtxZ6vY2eq6atpDqTFLWZLj zDvxnZIu0bSR0wWHvXN6ppWo65rfiWGDTLpINT06FLe5mQJHvTcQGBIbkkDGD7gVP4bXT7q9hgb4 b/2VqFuVMt1Jp8KQxsOpSQcseONo9KS1sVLq1/WiOi8af8iTrf8A14zf+gGqsthZ6j8PIob21huY 105XCyoGAYR8EZ6EetWvGn/Ik63/ANeM3/oBqu1ytr8P4CYbiZpNPWNEt7d5nZjHx8qAn8elRL4Z fL9Sl8Ufn+hwcMfhiX4dWKaLHZv4nNnH5H9mBftazYHLFPmAz94tx1zXT+PNNW6+GFxNrNtbz6ja 2QYymMExyYXcVPbn0qpp2j3WpeCNGudPgubHX9DgRYhdWzw7iFAeI7gNyMOMjjOKf4m8RSa94Bv7 RNC1uHUbmDZ9lbTJyQ2Rn5wm0j3zWlTeXr/Viae8X/Xz/ruWNNsfh7qkdpY2Vtoc17JGGBskhMsZ UZLEryuCPzpdJuF8a+KNaW9zJpWkyi0isyT5cr4O95F/i9ADkV0ukSQX+mWc/kTo0KgAXEDwujBc H5XAPc+1c5ZWF34N8T6rdpZT3mj6tILgtaxmSS2l/iBQfMynOcqDj070P4vv/r7iY/D939febf8A wjNjbXtjc6ZGLBLSRmNvbny4ZAVIOYx8uecg4z155rivFEelXfiKW48deFr0aesohs9QFyxhjj9X WNvly2Tk5PIzjFeg2mo/2gEe1t7hIj957m3eEj2CuA2fwxWbdagniDTL/S10u+SaRHgaO8tGROcr u3n5GXv8pJ9qnW5asP1bwrp3iCGK01BWk0uKMCO0ileNGPq20jIAAwM46+1ZPhjTdSsdI1/T9PvJ Ht4p5ItKkuHLmPCAEZPVVfIH0NT69rs3hu2stJttJ1vUR5SpJcWFk0pRAMdeBuOPXjr6Zk07VbvX PD9/b6Ro2o6JJDAY7U6lb+Sd5U4IXJyBxzQ9pWFH7NzC0OTTdVms7bSrRdN8RWU6f2mXAEwVf9Zv brKG6A89QeMVqWnk+KfGet22owJc2GlCKCG3mUMnmMCzPtPBPQA9scdTVP8As9dTsNHhg0y+s9e0 5os3D27oIuR5uZSNsisN3AZsk1pRWz+GvFmrai1tdT2WriJw1vC0xjmUFSpVASARg7sY65I4qnv9 /wCm3l+pOtvu/r+ugnhXUZ7nTdb024kaVtKu5rZJGYlmjxlMk9SAcfhU/wAO/wDkn+jf9ew/maTw 5o82maRql1dxmK61O4mu5Iy2TGG+6pI4yFAzjvmq3gy//s74a6LP9kurrMUaeXax73+ZsZx6DOSe wpLr/wBu/fr+pT308/0OvooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVi+M/8A kR9e/wCwbcf+i2rarF8Z/wDIj69/2Dbj/wBFtQAXX/I8aX/2Dbz/ANGWtbVYt1/yPGl/9g28/wDR lrWXr82qv4y07TdP1+4sYJYJLi7RYoGEcaYAKl0JBLHuSOOlHWwHXUVnw65o8mmtfx6xZS2kZ2vd C4Qxg+7A4B/xrM8WeLrDw9YBft9ol9clVto5ZVH3jgORn7g5JPTigFqdHRWHFHbaA8uo32vn7JNG gJvbgbPMycuGY4XcCBtUAce9X7jWdKtIYJrnU7OCK4OIXknVVlP+ySefwoAu0VSu9a0qwMgvNTs7 bygpk86dU2bs7c5PGcHHripBqFk1zHareQGeVPMjiEq73T+8BnJHvQBZoqG2vLW8EhtbmGcROY38 pw2xh1U46H2qBda0p7k2q6nZtOsgiMQnUuHIJC4znOATj2oAu1Uure7nuIGhvfIgXcJoxECZMjjD Z+XFZ0vjHQotcbSH1SzWeKNpJt9wqiPHY5PXGSR2Ayas6PqEmpC6uVvNPu7Iy4tJbKTflABkOc43 Zz07Yo3DY0URY0CIoVVGAB2p1VLfVdNvLqW1tdQtZ7iH/WxRTKzx/UA5H40yHXNIuLae5g1Wylgt jieVLhGWI/7RBwPxoAvUUyKaK4hSaGRJY5FDI6MCrA9CCOop9ABRRRQAUUUUAFFFFAGL4U/5BE// AGEr/wD9K5a2qxfCn/IIn/7CV/8A+lctbVABWL4r/wCQRB/2ErD/ANK4q2qxfFf/ACCIP+wlYf8A pXFQBtUUUUAFYtr/AMjxqn/YNs//AEZdVtVi2v8AyPGqf9g2z/8ARl1QBtUUUUAFFFFABRRRQAUU UUAFFFFABUckMcpUyLu2HIBJxn6d6kooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAK5zRvDeo6b4m1LWbnVba5GpBBJClmY9uwYXa3mHsecg59q6OijzDpYK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCjrWnf2xol7pvm+T9rgeHzNu7buBGcZGevr UWh2Oo6bYx2l9e210sMaRxGC1aEgKMfNmR8np0xWnRQG4UUUUAFFFFABRRRQAUUUUAFFFFAFLVLf ULm28rT7u2tmbIdri2aYFSOwDpg++T9Kh8O6P/YHh+y0nz/tH2SIR+bs27vfGTj8606KACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsXxn/yI+vf9g24/wDRbVtVi+M/+RH17/sG 3H/otqAC6/5HfS/+wbe/+jLWsnQruK+8TeI/ELSq1rabbKFweAsa75D/AN9N+laOp21veeL9Otrq COeCTTL0PFKgZWHm2vBB4NXbXw5oViJRZ6Lp9sJ0McohtUTzFPVWwOR7GkBxQguF+HRlvRi916Yp GDz5QuH5P1CHJ9hjtW7fxLeeMdB0yFc2+mwPeuOw48uP+bH8K19ZhlXTUNjptveyW8sbRwOq8AMM lMkAMFzjkc0abp7x313qlygS6u9i7Qc+XGoO1c9zksT7nHOKu6v/AF20Frb+vmc7oOoW7XXiDxHr cqxyWl3JaxiU/wDHvCmMKo7Fjzxycj2rHtLTUF8PaJpEkJhn1fVnvfs8nH2eBXMuCPbC8epxXoT6 TpsmoDUH0+1a8UbRcmFTIB6bsZqZraB7hLhoY2mjUqkhUFlBxkA9QDgflSWlvl+H+bG9b/P+vkch 4u0mxsNHmgsLVRf69PDZSy/xzAt8xY98Lv5/woFmlz8QIoFA+zaNpxM0hwC0kpHH/fKfka6+W2gn kiklhjkeFt8TOoJRsEZB7HBI49aFtbdJJpEgjV58eawQAyYGBuPfjjmlt/XlYP6/E85t7t5dLg+z ymF/Fert5kyZUxwYO0A9maNAB/vZrckTTp/Hek6dawxxx6RaSTDaAFBbCKo9eA/5fWujfR9LlsEs JNNtHs48FLdoFMa46YXGBipVsrVLn7SltCs/liPzRGA2wdFz1x7U7/18rIH/AF9+pyllqsNraeJv FErgjzHEWevlwgoB+Lh8fWs6aC4sfDHhnQmnMY1K7WPUp0bBJYNI67uxZuPzFdwNK04Wk1oLC1Fv OS0sPkrskJ6llxg575p89jZ3NmbOe0gltiu0wyRhkI9Np4xS/wCB+H+YP/P8dvuOVvkivvHOi2el oiQ6Iskl3JEMLErJtWLI4yc5x6AGs+CeWLwjrfiOZQ0uo3ErWK9c7yIom+pAXHoPqa7u3s7W0tha 21tDBAowIo0CqB6YHFNOnWLWSWRs7c2se3ZAYl2LtOVwuMDBAx6Yo6W/rfUadmR6PZRadotlYwEG O3gSNSOhAAGau0lLTbu7kpWVgooopDCiiigAooooAxfCn/IIn/7CV/8A+lctbVYvhT/kET/9hK// APSuWtqgArF8V/8AIIg/7CVh/wClcVbVYviv/kEQf9hKw/8ASuKgDaooooAKxbX/AJHjVP8AsG2f /oy6rarEt13eNdVXJGdMsxkf9dLqgCR/FGjRzSI122yIkSXAhkMEZHUNNt2AjuC3FWbjVoorG3vY ILi9iuHjVPsse84cjDnp8ozkn0rhrTVNY+Hdt/Zeu6ZJqGgxlhFqdqu9o0JJxKntk5P861PEOrXG l+HNFu/Dl/AthJcW8A/c7zJGzKBtYnC8Z/hP4YprW3qgel/mdnRTJZVhheV+FRSx+grmbCbXdd0m y13T9TWA3O2QWUsSmExE9Cdu/ft7hsZ7UgOppGZVGWIGTjk965PVfELT6vfaXBe6jZGyCDzbHTXu izsu7DERuoABHHBPqKwrm+1vW18JTX1xqGkXU188M8KQrGCVRyJAkiE8gDAbIGemeaFqD0PSdyhg uRuIyBnk/wCc0tcPHa33/Cz5YW17UPLh0uOXBEOG/eYZSPLwAduTjB9+gFS68Yand6UutaO2qTT7 90emx6RK8E0e7GPN8r723ncHxnsaF0/rrYOrX9bXPQ6KhFwv2QXLq0a+XvKsMFRjOCPWuBm8Yapc aZba3pY1a5lkZHOmJo8pheItziXys7gpzuD7SR0otrYOlz0SkZlRSzEKoGSSeBXGatqWreHvEsF1 e6rdTaJfq0UUQghBguG+4pbYDtPQEng/eJFVvGVprFl8PSLzXrqa78+LzpUSJAwaRVKcIPlGfqe/ HFCA72iuU1PWJNKvbXQn1HUpJJYHnkvIrIXE4UMAoCRRFRyepTHy46nNYl54n8TQeEtZuEeaGXTJ h5N5eaa8Ru4WwAQrBQGBPJ2kcdOaN/687B5Ho1Fcxe6jqWmeJtDie9M9tqhkhlgMahY2VC4ZCBu7 YIJP4VU0vxJLf6vNZPqotdTjutj6VcRoo8oP96M4DMSnOdzD2FOwr6XOoivvN1Oey+yXKeSiv57x 4ifdnhWzyRjn0yKtVydjreow+MNestSu4pLKxtI7iIRwbNituJyckk4HXOPYVBNqmtyeER4ttb/k W32sac0KeS0f3tucb9+3+LdjP8NLpf8Ar+tCrO9js6K4+PXdUv8AxZpUFtfRJpmp6c10iC3HmJjZ 1Yk5PzHsAPQ1e8L6je3F7rOmX1ybptNuxHHcMiqzoyBhuCgDIyRwBTs/69bE3X9elzoqQnAya5nX tR1e08XaHZWt5DHZ37SpJGbfL5VC2dxPTpwAOnU9Kk0PUb7/AISjWNEvLprtLRIZoJnRVcLIGyp2 gA4K8cfXNLcb0NPR9d0zX7aS40u7W5jikMTlQQVYdQQQDWhWLrV7D4Y0W91QIZJWZSSQSXdiEXIU ZOOBgDoPWsW113VI/E1jBC2ralY3m5bk3OkSW62jAZVlYxr8pPGGLHpzRuD7naUgZSxUEbhyRnkV x2h+I5dU1FrZtX8rUkuCt1pNxGiGFAT/AKvgM3GDuJYEZxjs3whb3jeJ/Eck2s3s6QX4TypBEVce UpGfkyMZ4CkDjoeaFr/Xp/mD0O0orl/HOp6tpFjY3OmXcMCyXsMEqvBvZg7gcEnA79j16ikvNR1P Q/FemWs9619Y6s0kQSSNFa3lVdw2lQMqQCMNkj1oWoPQ6miuBvfEWraVNplxd6mDdXN/HbXemJHH JFbo7ED51XcrYwfmYg88el3UvEkkPiS70yfVhpNwqj+zop418i8yo5LEZJDEjarL+NC1A7Gio2Er W5CMqylOGZdwDY6kAjP5iuK0O98Sa54d1K5OtiG9sr2eKIx2sYjk8s4CsrAnacdiCM9TRfcFrbzO 5qK4njtbaW4lOI4kLsfQAZNcPp/inWNa1Pw20NzDb2esWcskkSw5eN0UZwxJzyeOB05zVq81m4hv m8PXWpX7y21qklxe2elGd5HYnaNqo6IMLzlec8YxQ01oCaep1OnXp1HT4bw2s9r5yhhFcACRQemQ CQD+NWq4JfFurxeGPtWqQXtksN81tc3/ANiZHWDBKziN1OM/KDlSBzx2rRn8Tmx0Br+LUYtUhuLq O3s7iCPzCQ2ASyx/eYHccKBnAGBTf9fMXqdZRXF2Os6y/iE6fazald2d1buyXl/pEkItJh0B+SMM pHQdcjrVGPxBr7fDh/Ez6mPtVpJI7RpAgjmVZSpVgQSOBxgg+pNIZ6CWUEAkAtwAT1pa4nVIry8+ I2kLFrF9axTafNKI4hEVQgp0DIeueScn0Iqvf+K769s7680mfU1uLSaWO2tYNJknhuCh24eQRn7x B+6y4zz0o6f13sC1/r5nfUVV026kvtMtbuW3ktpJold4ZVKtGSMlSDzkUzWJb+HSLqTS4Y5r1Yz5 KSMApbtkkjj8aGraAtS2zBFLHOAM8DJ/IVmaD4isvEUN1LZR3CLazm3kFxEY23gAn5TyOuOQDWHp uvXEfjS30caw2q213aSSmR4kAjkRgCqOiqGHJyDkjHJrM0PWU8P6L4w1N1DmHWp9inoznYFH5kU1 +n6pB0+f6XPRKK5PWb/VvDEdpqtxqTX1pLcRQ3cEkKKIw527oyoBGCRwxbjuKjtbrxDqPiXX9I/t mO3W0WB7aWG0X5N+44KsTu4ABOR7YoSv/X9dwOwqOeZbe3kndXZY1LERoXY49FGST7CuQtfEk11r tzp0urCy1SK58tdMuI0VJIQ/DxkgMzMgJ4Ygf3a7Kk9rh1sY+neKdM1HQJtcRpYLKAyCRpoyrKEJ DHbye3Tr7Vf07UbPV9Phv7CdZ7add0ci5wR+PI+hrmvhsC3hOUBipN9dDcOo/et61e1zVIfDVnY2 lusiNe3JiVo4Gndchndtigljwe3U5PFN/wCQd/mdDRXF6XqWtX+rXujJd6t9le2EttqtzpnkPFJn BjIeJUbsR8vTP1qDQ73xBqTHQbvW7iDWNOuS1/OsEOJITnZsBTGG45xkYOT0BErgzutyhguRuIyB nk/5zS1xX2e9l+Ks8Y1m+jhj01JhEoiK4MhBTBQ4U7Rkj5vfpVO98XajeabPqmkSambiGVxBYxaR LLBcKrFcNIIzycE5VwBnHOKXRP8ArewdWv62ueg0VyEOra1d+NINPa6FtZ3Wlm7WH7KFlhO5Rgli csMnsBzyDVZPE2q2uh6z58kt1JpWoi1e6jhUyCA7SZNijBZVY9BjjpR/X42/MP6/C52ssnlQvJsZ 9iltqDLHHYD1qKxuvt1jBdfZ57bzkD+TcJtkTPZh2Nc9barc3ugX17o+v21/FFAGt7p4ldgwBLh1 QqM4x2XGeh71tP8AE97P4c8MLJOp1HWwoMxjGFAQu7bRgZwMDtkjrTtuvT8bh5+v4HZUVyrahqmj +JbXQ7jUDexanBK1pc3EKb4pUGSGCBFZcHPAB461kw634hm8Bahrj6qq3enTXBAjt0CTCJyNrAgn BA7EEeppeYeR6BRVe1na7sIbhcI00SuMjIBIzXIaBd+I9dsdaSTXBDdWGoSwQyQWkYRtijAZW3Ha Tzwc/wC1Q9G12BapM7emySLFG0jnCoCxPoBXBW3i3WdUg8K3sE0FvFqkzW91AIckOofcQxJ4yvAx +NXb3V7m01A+HbzU76ZxA08t5aaWZpNruQibUR1GADklecUNNaAjptK1AarpsN8trcWyzLuWO4UK +OxIBOM9fWrlcPp/i3VU01ba+t50vJdTWxtLq5s3gE6NyJSjBedoOQMDI7VsTSap4dS/1G+1L+0N LgtWmxLGizo687QUVVKkeoznuabtv0/4FwV726/8GxpXGqJBq1rpotriWW4RpC8ajZEq45ckjGSc DGTVi6uEtLWW4kSR1iUsVijaRjj0VQST7CuHPiTVUudNv7RdUvWupI0vLI6LLHFHG3VkkMQPyk/x MQeelbNpf3viG61KWx1A2ltp9y1siJGrec6gbi5YE7cnAC4PGc84Cd0vv/r8UCsa2iaxa6/pMOp2 YkEE27Z5i7W4Yjp26Vfrzjwvrx0nwJ4etQZUlv5Zk3wW7zvGqs7MVRVJJ6DpgZyemKuQ69r4j1q2 hlvJIrW1+02mpajpTxbsZ3xsu2ME+hAHXocU5WTfkC1O7pNy7tuRuxnGecVxD63rNr4d8N65JqBl N5JbRXNv5KBJBLgFum4MCc8ED2pdLjul+IfiGSXWb0wWkVu/lERFWUq52n5MgDnGCD6k0NWbv0v+ H/DgtVdeR29FedzeMNUuNMttb0satcyyMjnTE0eUwvEW5xL5WdwU53B9pI6V309zHbWcl1LlY44z I2RyABk0norsOtkUtf1608OaXJqN9HcPDH18iFpCPrjgD3OB71oxuJI1kXOGAIz71554mn1PV/hj fa41+VivLTzBZeWojSNiCPmxvLgYyc4PoOtdBHqFxqmsSaHZ30liLKzilmmhRGkLPnaBvDKAApzk HOR0xTs9U9w7P+un+Z0FzP8AZrWWfypJfLQt5cS7nbAzgDuabbXIuLSG4aOSDzVVvLmG11J/hI7H tiuRbxFrK6X4ksjcwLqehDeLlrfKzRlN6koGGGIBB7Z5x2qhqE2parb+Brl9Yu7eS+dDMYFiALmF m34KEZz2PHtnmhK/4fiD0/H8D0JmCKWOcAZ4GT+QrI0nxVpur2F9fQi4hgsJWinNxCY2BVQzfKfm 4z3APHStaJGjiRGlaVlUAyOBlj6nAAz9AK5HwAMv4mAJGdbuOR24Wkt2vL9V/mPon5/ozpdL1ew1 nTYtS065Se0lBKyjIHHXIPI/GodM1qLVJp4ltrm2eLDKLhAvmoejrgnKnHfB9QKp69fQeGNAaSKL eZp1iAMZkLPI+CxVRluSTgDnoKx7PVdSl8Sx2Mcmr3dldwSA3lxpLW72UnUAM0SqVOOAQeQMk0en 9dRbLU7UMrZ2kHBwcHvS15Zp95r2lfC2fXLPXJXnSWUlLqGOQf65lJUgAhiTnLFh7V1mrapfaBCt xc373A1GeKC3iW03m3YglyoQbn4BIGCc+1Nqwf8AB/A6eiuR0LWdTfxO+nP/AGnfabLb+al5e6a9 s0MgPMZPlopBHI4z9a66kAVi+M/+RH17/sG3H/otq2qxfGf/ACI+vf8AYNuP/RbUAF1/yPGl/wDY NvP/AEZa1ryypDE8srhERSzMxwAB1NZF1/yPGl/9g28/9GWtR6pPqd3MrabaWdzZ27Eym4u2hDuv TG2N8qD16cj2NJuwE/h3XP8AhILW5u0gaKGO6kgiDjDME4JP45rXrzjSNYutG+FdrfW4VL3U7phE xXKo80xw3uADnnrgV0kvh3SdNFvqcxke9sQ0zXRIM9xhTkM2NxXnO0EDpxjiqem/T+mC1en9djo6 K4vR9Jt/FnhdNW19xNPqKGWNjgizVs7BEGBCsAfvYyT+FRi6utd1/U9NXS3vbDSwttHFcTKsEkm0 FjLklm4Ix8pGMnriizTt1C+lzuKK4WfQVTwuum6fNb38llcfbZ7FeLeZCz5hA5AUYYAHIyozVq5t 7TxD4S8nQptjXyJex28xO10BXMTeiHbtIHAz0xS/r+vx+4P6/r8PvOworE8Ky6fd6Qt9p9u1qk3y Nbfw27JlTGoHAAIPTjv3rbptWYBRRRSAKKKKACiiigAooooAKKKKACiiigDF8Kf8gif/ALCV/wD+ lctbVYvhT/kET/8AYSv/AP0rlraoAKxfFf8AyCIP+wlYf+lcVbVYviv/AJBEH/YSsP8A0rioA2qK KKACsOFS/jPV1HVtLsx/5Euq3KxbX/keNU/7Btn/AOjLqk1dWAggtPEtrpMOmt/Zl8RF5T3UrvEQ MY/1YVt//fS59qydU8GahF4T0nw/of2R47GeOaSW7meMsUbdgBUbqc/T3rt6Kq+t/wCtAIlVprYL cxoGdMSIrblBI5AJAyPwFchovhzxZoDDSbPVdOfQkJ8p5oXa6iQnOwYIXjPBOfp2rtKKXW4dDk9W 0HxHa69LrPha+sVe7REu7XUVcxuVGFcFOQ2OMdDU+p6Dqt7/AGPefabae+0+7+0Sq26OJwVKsF+8 VwDx1zjnrXS0ULQDn20W/TxkutxSWzxS2ItbhXLKykNuDKMHOckYJGPeszTfD/i7Qro6fpep6Y+h mRnT7VC7XFurEkom0hWAJ4JP4V2dFCDf+vkMES+T5TEuu3aSxySPeuP0jw/4v0ORdKs9V02TQ4yR FJPC5uokJ+4uCFOOzHP07V2dFHW4dLHPXmj3urNqMGq2VlcWbQmOzT7S5bpyX+T5STj5gWIxx3zm Hw54l1LwJJoesXNi19GYzBcxyu4k2MGHmZQEH5QCRn1xXaUUAcvrmha7eXFjrWk3lpZ6xaxtG0co Z7eVGwSjHAbggEEAfSq2u6J4q1vwfc6dcTaU+oXm1X2NJFBCoOfl4ZmOfXH6c9jRQC7nJarpPiXU NV0G9S20tBpjmSZTeSfOzKUIX910AOcn6Y7lb/w1qWriyg1EWEn2S4SdNQUt56bX3BFUj0GC27n+ 7XWUU763FbS3yOUtdB1c+MtV1K9t7BtO1G3W2KJcu0gVd2CVMYBznkZ49TTbPw5rNroEnhhri1k0 0xtBHeF289IjxsMe3aSFOA2704rraKXSw763OUl0HV4fGGm6hY2+njTdPtGtFR7l1kKttyQBGRxt 4GefUVL4b0nW9P17Wb3UYrBYNSlWZBb3Du0ZVQuCGjUHIGc5/Cumop3/AK/H8xWX9fccxr+k65fe J9G1GwisGttNZ3cT3Do8hddpAAjIGBz159qXS9J1y38balq91FYLZ3sUcSiK5dpFEe7BIMYBzu5G ePeumopLQb1M/XtIi17RLrTJpGiW4TAkTqjA5DD6EA1laFZ+Mo5hDr2o6XNaw42SWkUizT46FyTt X3ABrpaKAOTuPDOo6nPpf9pixd9OlSZdRjLfaGKnOwKV4B4BO45/ujte0jRr3S9f1e53wPZ6jOtw DlvMVggUrjGMcA5z7Y71vUU72/r+uyB6/wBf13OP+Jgc+HrMRlQ/9p2u0sMgHzBjIrROkahqmqW9 9qwtrcWKyC2jtZGkO9ht8wsyrggZwoB69TVrWvDWl+IRCNTinlWBt8apdSxKGHRsIwBI7E8itKKN YYUiUsVRQoLuWOB6k5JPuaS2a/rZIHucP/whutt4Z07SC+nh9Nvo7gSiR/8ASgr7izfL8jHJz97J 7itTW9B1TWLK9065TTb21vD8jXG9WtflA3KMHcdwJAyuPWunooeu/wDW3+QbbENnb/ZLKC23tJ5M apvbq2BjJrgvBqa1NpWtW+niyEU2q3ameZ2DwktjIQKQ/wD30v41388K3EDwuXCyKVJR2RgD6MpB B9wc1n6J4b0vw8syaXFNEs7b5Fe5llBbu2HY4J7kde9G7bf9bBskl0MFvC+q2Ou6DLpUFgdO0a3e BRNdOssgdQCcCMgEYz159qta9oOuDWxrvhi9tIb14RBcW98rGGZQcqTt5BGT09a6iihtsDEWz8Q/ ZbaWa9s5LxZC9xGqOkDrtI2LySOSDuOee3asf/hBGn03VFEkGl3V9cx3US2WXjtZY8YYZC7iSMng Zz0712dFHmBzmlQeM1jkbWrjSJniU+RHaCSMTNjAMjnOB7Kp/pWFH4U8Tr8Ornww0ekm4mZwJhdy bAruXJx5WcgnGPxz2r0CigFocy2iau+taNrGLJJ7W1ktrmLzXZQG2/Mh2gtgr0IHXrVRNA8V6Lqt wPD+o6YdLvJ2neK/ikZ7dmOW2bCNwJycEjFdjRTv/X4itpYx3l1e21qxtYjaXFg0RFy7s32gPgkO ABt28Y+p46U7xRpE+u+HbvTbe4EEs6gKxztOCDtbHO04wfY1rUUhrR3OVbQtZl8SaVrTLp8P2O0l t3to5HIUtjBVtoyOOmFx71R03wZqM+k6/peurZpDq9090klpcPI0TMQQMMi/dKg57+gruKKP6/G/ 5gtP6+RzX9jaxqtnbafrxsmgtpY5Hlt3ZmuihyMqVAj5AJwW7jim6RpOu2vjLVdVuodPFnqCxoBF cu0kYjBAODGAc555GPeunop3C2ljk9W8M6lrUEdlfiwmjjufPjviWE8AEm4Kq45OPl3bh9DXUTmZ YHNuiSShTsWRyqsewJAOB74P0qSil0sHW5zfgjRtV0HSJbHVFs9xuJJke2mZwd7FiCGRcYz759qt eKNCn1yxg+xXn2K/s5xcWs5XcFcAjDDuCCQfrW1RQ9QOd0+LxkLGeXVJtHkvlQi3htfNSEt/ekZs k/QKO/4UNS8O64X0jU9Jj0+HV7Zj9slluZNkyt95CRHlgTzkgbcDArsaKOtwOf8A7G1FfGEeuxm2 2TWItbiNnYmMhtwKfL8w5I52+vtWbaeH/Fmh6hLbaJqWmNo887zBL2F2lttxLMqbSAwySeT3rsqK P6/UP6/Q5U6NryeOYdYRLGWyhsvsf7y6cTMCwYuR5ZGcjGM/j2qDR9D8UWV1qc8j6Zbm9vxeKYp5 JQBgKY2BRcggfezweccV2NFC0/rzv+YPX+vKxyMfhrUIG1rULa0062vdUt1h+yxTuIcjcDIz+Xks Q39wdMZ71DaeENUXwxotrLLaW2q6G6tbTRO0scgAwQ2VUgMCQQOnBya7Sij/AIH4AYK6ZqN5qMGr 6jBZrd2UMiW1tFOzx73xljIUB5AA4XjJ61g2/hjxPH4I1TQXi0kz30kxSUXcm1VlLFsjys5GePX2 xz3lFHkO5S0aK8t9HtYL9IUuIogjiCQunAxkEqDzj0/OuL8I/wBsmbxNHpqWRSTWbhTJcSMrRHC/ MFCkP9Mr0688d9JGJYmjYsA4IJVip59COR9RWbo3hrSvD7zvpsU8RuWLyh7qWUOx6th2IyfXrTvd tvqv1X+QlpFJf1uYF54V1W0bw9b6LDYSWuiyeaTc3LxvMxVlPCxsB94nPqelXfEGg61JqsGu+HLy 2ttSSHyJobsM0E8ecgHbyCCTgj1rp6KVwOW1Pw1q2v8Ah9ItT1G3h1eKVLiCe0jYRQSJ02hiSRyc k9c1NYaZ4i1HT7i08V3OmvHNE0Ri06ORdwYYJZmPp2AHNdHRR3DscjoukeM9Okj0271bTbjSIBsS 48qT7YyDoDyFBxxu5NWbHQtT0TVdQ/s1rSXTtRma4dZ3ZXt5WHzFQAQ6kjOCVx610tFD1A4O08Da 1beF7CzTV7aLU9LuGnspo4SUG7O5HyfmB3EZAHbitQ2Pi+88P3sOpS6RJfTwtDFFbGWOBQ3BZmIZ mOOgAHcd811FFD1umO+tzhbvw34nn8JaLo6Q6SJtOlgeSRruTa4iIK4/dZ+bHPp79tm00S/t/FN/ qjfZjbalbwrMm9i0boCCF+UBgQepII9DXQ0U273v1JWhxmkeH/F+hyLpVnqumyaHGSIpJ4XN1EhP 3FwQpx2Y5+nauunto7m0ktZQWilQxsCeoIwalopPVWY9nc4qXwrrreDbnwmLixa2EPk212zOJNme A6BcZA4yGOcdBVuPw/rOnapFrNlPZXF7Larb30Em6CKfafldSA5UgEjkHPtXVUU7u9w8jmL3w7fN pGuG2FrJqmsqVkMjskUa7NigEKSdo56cknp2qx+GdYGj+G0b7ELzQ5UJQTuY5kCFCd2wEHBzjafT PeuxopLT8PwB6/j+Iz94IudrSBf90E/rgfnXN+DtF1jRpdWOpx2IW/vXu0NtcPIVLY+UhkXpjr39 BXT0ULR3DpYy/Eeirr+iy2HntbSkrJDOoyYpFIZWx3wQOKpaFbeLhLjxFe6W8UX+r+wxyB5ewLlj geuAOuOa6GigDgrnwh4hXwNdeGLQ6a4kmfZPLNIv7tpN4JAQ/N2x0757Vu6zod9r3h6CCWaPTtTt 5EnhmgYzJFKh4OWVdwI68DrXQUUB/X3mFoUPirl/EVzpZZBiJNPSQBjjq5Y/oAK09N/tH7BH/av2 b7Zz5n2Xd5fXjG7npirVFABWL4z/AORH17/sG3H/AKLatqsXxn/yI+vf9g24/wDRbUAV9YsodR8W afaXBl8qTTLwN5UzxNjzbX+JCCPzq7F4b0yDQxosSXMdiBgIt5MGA9A+7dj2ziqOs6Zp+q+MdJg1 Gxtr2JdPvHEdxEsihvMthnDA84J596s/8IZ4V/6FrSP/AABi/wDiaAC28I6HaaK+jR2bNp74/wBH mnklVccjbuY7eeeMc81fstMtdPh8mBZWXG3dPM8zY9NzknHtmqH/AAhnhX/oWtI/8AYv/iaP+EM8 K/8AQtaR/wCAMX/xNAE+m+HdL0lj9ht3iQtuWLznaJD6ohYqnU/dAol8O6XLqj6mbd0upFCyvFPJ GJQBgB1Vgr8f3gag/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/iaALFzoGmXT73t2jch VLQSvCzKvRCUIJXk/KeOelE3h/S5o0T7MYfKjEUbW0rwOiD+FWQggewPPeq//CGeFf8AoWtI/wDA GL/4mj/hDPCv/QtaR/4Axf8AxNAGpa2lvY2yW1rEsUKD5UUYAqasX/hDPCv/AELWkf8AgDF/8TR/ whnhX/oWtI/8AYv/AImgDaorF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8AAGL/AOJoA2qKxf8A hDPCv/QtaR/4Axf/ABNH/CGeFf8AoWtI/wDAGL/4mgDaorF/4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/ 6FrSP/AGL/4mgDaorF/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJoA2qKxf+EM8K/wDQ taR/4Axf/E0f8IZ4V/6FrSP/AABi/wDiaANqisX/AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8A wBi/+JoAPCn/ACCJ/wDsJX//AKVy1tVx/hrwn4bn0uZ5vD2lyMNQvUDPZRkhVuZVUcjoAAAOwArW /wCEM8K/9C1pH/gDF/8AE0AbVYviv/kEQf8AYSsP/SuKj/hDPCv/AELWkf8AgDF/8TWT4l8J+G4N LheHw9pcbHULJCyWUYJVrmJWHA6EEgjuCaAOworF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/ AMAYv/iaANqsW1/5HjVP+wbZ/wDoy6o/4Qzwr/0LWkf+AMX/AMTWTbeE/DbeMdSgPh7SzEmn2jrG bKParGS4BIGOCQq5PsPSgDsKKxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi/wDiaANqisX/ AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JoA2qKxf+EM8K/9C1pH/gDF/wDE0f8ACGeF f+ha0j/wBi/+JoA2qKxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8AiaANqisX/hDPCv8A 0LWkf+AMX/xNH/CGeFf+ha0j/wAAYv8A4mgDaorF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/ AMAYv/iaANqisX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/iaANqisX/hDPCv/AELWkf8A gDF/8TR/whnhX/oWtI/8AYv/AImgDaorF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8AAGL/AOJo A2qKxf8AhDPCv/QtaR/4Axf/ABNH/CGeFf8AoWtI/wDAGL/4mgDaorF/4Qzwr/0LWkf+AMX/AMTR /wAIZ4V/6FrSP/AGL/4mgDaorF/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJoA2qKxf+ EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi/wDiaANqisX/AIQzwr/0LWkf+AMX/wATR/whnhX/ AKFrSP8AwBi/+JoA2qKxf+EM8K/9C1pH/gDF/wDE0f8ACGeFf+ha0j/wBi/+JoA2qKxf+EM8K/8A QtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8AiaANqisX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAA Yv8A4mgDaorF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/iaANqisX/hDPCv/QtaR/4A xf8AxNH/AAhnhX/oWtI/8AYv/iaANqisX/hDPCv/AELWkf8AgDF/8TR/whnhX/oWtI/8AYv/AImg DaorF/4Qzwr/ANC1pH/gDF/8TR/whnhX/oWtI/8AAGL/AOJoA2qKxf8AhDPCv/QtaR/4Axf/ABNH /CGeFf8AoWtI/wDAGL/4mgDaorF/4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/6FrSP/AGL/4mgDaorF/4 Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6FrSP/AGL/wCJoA2qKxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6F rSP/AABi/wDiaANqisX/AIQzwr/0LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JoA2qKxf+EM8K/9 C1pH/gDF/wDE0f8ACGeFf+ha0j/wBi/+JoA2qKxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wB i/8AiaANqisX/hDPCv8A0LWkf+AMX/xNH/CGeFf+ha0j/wAAYv8A4mgDaorF/wCEM8K/9C1pH/gD F/8AE0f8IZ4V/wCha0j/AMAYv/iaANqisX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/iaA NqisX/hDPCv/AELWkf8AgDF/8TR/whnhX/oWtI/8AYv/AImgDaorF/4Qzwr/ANC1pH/gDF/8TR/w hnhX/oWtI/8AAGL/AOJoA2qKxf8AhDPCv/QtaR/4Axf/ABNH/CGeFf8AoWtI/wDAGL/4mgDaorF/ 4Qzwr/0LWkf+AMX/AMTR/wAIZ4V/6FrSP/AGL/4mgDaorF/4Qzwr/wBC1pH/AIAxf/E0f8IZ4V/6 FrSP/AGL/wCJoA2qKxf+EM8K/wDQtaR/4Axf/E0f8IZ4V/6FrSP/AABi/wDiaANqisX/AIQzwr/0 LWkf+AMX/wATR/whnhX/AKFrSP8AwBi/+JoA2qKxf+EM8K/9C1pH/gDF/wDE0f8ACGeFf+ha0j/w Bi/+JoA2qKxf+EM8K/8AQtaR/wCAMX/xNH/CGeFf+ha0j/wBi/8AiaANqisX/hDPCv8A0LWkf+AM X/xNH/CGeFf+ha0j/wAAYv8A4mgDaorF/wCEM8K/9C1pH/gDF/8AE0f8IZ4V/wCha0j/AMAYv/ia ANqisX/hDPCv/QtaR/4Axf8AxNH/AAhnhX/oWtI/8AYv/iaANqsXxn/yI+vf9g24/wDRbUf8IZ4V /wCha0j/AMAYv/iayfFnhPw3beDtang8PaXFLFp87xyJZRqyMI2IIIHBB70Af//Z ------=_NextPart_000_00A9_01CDEE88.FAC3C7B0-- From piyush@ditenity.com Wed Jan 9 07:18: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 4CC0221F86F7 for ; Wed, 9 Jan 2013 07:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 86a64MeQmBje for ; Wed, 9 Jan 2013 07:18:34 -0800 (PST) Received: from mail-ye0-f170.google.com (mail-ye0-f170.google.com [209.85.213.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F321F84CA for ; Wed, 9 Jan 2013 07:18:34 -0800 (PST) Received: by mail-ye0-f170.google.com with SMTP id m12so345911yen.29 for ; Wed, 09 Jan 2013 07:18:33 -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=VTud9Zeq5GXVPqVYX9uwgGuBhy6Rw9kftdsxCukEQ04=; b=IP6XcEynk0ZrWaNE/EVKkHaGcUeEMwKJmCZyOXP+ZUNB3Ayvrtkqu7WfwTRm8THN1D RciIrMt6VD6XwgV0wrEi2JEMz1TzuFyHKbfSjq0eliXyRmEehmvjH6lKGa99XMd7ClQq 7vU9mCafi/FQwC4SePDlmFjqyaVO6i16kQAltudg2+f2xl7MYdZIXrYfT9Mbo2B1qyyl Xl3fOkb46RDzHpQX6G5d7s12jMXSY6D8Rh0lgmpZFeO4HWFSb2UYAKiNvjlcBBPWMTu4 6yU8g+oG/o5y6TIFSH8biU0ZdTG5GfExVeX43Iuw5/j8Zkp2JuyhtsVQBr+oJZlRlk64 RERg== X-Received: by 10.236.81.198 with SMTP id m46mr18037854yhe.129.1357744713559; Wed, 09 Jan 2013 07:18:33 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s8sm3018831yhn.7.2013.01.09.07.18.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Jan 2013 07:18:32 -0800 (PST) From: "Piyush Jain" To: "'Liaquat Khan'" , "'Ferda Topcan'" , "'Miller, Timothy J.'" , References: In-Reply-To: Date: Wed, 9 Jan 2013 07:18:28 -0800 Message-ID: <054a01cdee7c$94fbae90$bef30bb0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFkiqstgWPMnRRmry5eJY4DzKRqMJkT4jfQ Content-Language: en-us X-Gm-Message-State: ALoCoQl2HQaj6xqblGLtEW9OT8ChSGFVCc6FO4Zvd1cUCA9TQrzF77B7rSS+NqhAeanjNyoTGmAE Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 09 Jan 2013 15:18:35 -0000 That is an interesting observation. Sounds like giving an opportunity to CA vendors to include a fine print = - "I will provide both OCSP and CRL but if you use CRLs I'm not liable". = :) But your point is well taken. There may be a reason for CA to recommend = one approach over other for operational reasons. However, I do not see = any value in it from security or legal perspective. Given that information in the certificate is more or less static, it is = better if the recommendation is communicated out of band and implemented = vial a local policy at the RP. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Liaquat Khan > Sent: Wednesday, January 09, 2013 3:35 AM > To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org > Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >=20 > I think it's also worth looking at it from a legal point of view. If = the CA is > wanting you to use a particular approach (OCSP or CRL) as defined in = its CP > then if you as a Relying Party want to show that you have fulfilled = your > obligations it's better to use the approach recommended by the CA. >=20 > Of course in normal case this is not easy as end-users do not = generally read > the CP document, or have the expertise to configure their settings in = the RP > application - so generally it will be what's contained in the cert and = local > default settings in the RP application. >=20 > Regards > LK >=20 >=20 > On 09/01/2013 08:58, "Ferda Topcan" = wrote: >=20 > >Hello Timothy, > > > >I would like to explain my opinion about this topic: A CA can produce > >different types of certificates from the same Issuer. And the method = of > >obtaining revocation information for each type of certificate may be > >different. For example a subCA can produce QES and OCSP Certificates. > >The subCA may choose to publish revocation info from OCSP for QES but > >CRL for OCSP Certificate for some reason. In this case how the = verifier > >knows how to check the revocation info unless its is specified in = related > cerficate? > > > >If you would answer this question I'd appreciate it. > > > >Thanks in advance, > >Best Regards. > > > >Ferda TOPCAN > >Chief Researcher > >................................................................ > > > > > > > >Disclaimer > >-----Original Message----- > >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > >Miller, Timothy J. > >Sent: Tuesday, January 08, 2013 8:41 PM > >To: Ahmet YETG=C4=B0N ( B=C4=B0LGEM-UEKAE); pkix@ietf.org > >Subject: Re: [pkix] Lack of AIA and/or CDP Extensions > > > >On 1/8/13 2:46 AM, "Ahmet YETG=C4=B0N (B=C4=B0LGEM-UEKAE)" > > wrote: > > > >>We have an disagreement between our testing group about meaning of > >>missing extensions. > >> > >>For example when validation a QES, if a certificate has an AIA > >>extension, but not CDP extension, and CA is publishing both CRL and > >>COSP responses, > >> > >>1. Can I use CRL for revocation checking as a first choice? > >>2. If I cant, can I use CRL if I cant reach OCSP for any technical > >>error/reason. > >> > >>(Problem here is I need to know that CRL publishing address, and in > >>our example I have it from elsewhere, from another certificates = OCSPs > >>extensions in the same path. Weird example, yes.) > > > >I guess my counter-question is "Why wouldn't you?" If OCSP is not > >reachable, and you know from another context that a CRL is available, > >is there harm in getting it? > > > > > > > >However, if the issuer is issuing CRLs but isn't populating CDP, this > >sounds more like a misconfiguration or a contrived thought experiment > >than a real use case. I can't think of a reason why you'd produce = CRLs > >but not publish their locations for relying parties (but I'm sure > >someone on the list will educate me :). > > > >>So rephrasing the question, do nonexistence of CDP, means dont use > >>CRLs; and same question goes for AIA. > > > >I don't think anything stops you from trying. Absence of AIA doesn't > >mean OCSP isn't allowed; it simply means an out-of-band method is > >needed to communicate the location. > > > >-- T > > > >_______________________________________________ > >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 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Wed Jan 9 08:49: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 1558F21F8703 for ; Wed, 9 Jan 2013 08:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 jnL-TFUDozeG for ; Wed, 9 Jan 2013 08:49:33 -0800 (PST) Received: from mail-gg0-f175.google.com (mail-gg0-f175.google.com [209.85.161.175]) by ietfa.amsl.com (Postfix) with ESMTP id C51A321F84CA for ; Wed, 9 Jan 2013 08:49:32 -0800 (PST) Received: by mail-gg0-f175.google.com with SMTP id y1so367361ggc.20 for ; Wed, 09 Jan 2013 08:49:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=iLs1hrITJKqsYW6brwXmXD5l7PIsLNNqEzV4oKTJKLU=; b=bPt8Vdy+72C5QlvZk25+5KV2Btg/VPG8eGGqeYgaV+7W+D0+KKdqj07Bz6fonmH3C/ aAF3CVJt4omvDjbdSxN70AiDHmITfUvGtzk1+Rwb+1/RIGpYA2qQwT1DbEontEcC8WGL skNaDBUvpc0tsFGJJ5ZZilvTsUPorGXxBeCVTAW2ObwN+nmCKzS28G/agdP1ncKOhABC llPNKXiV3UgQrE0FFsq4GP5zQup2KTJgisBnitNdg2exL2RDmVQXTxyOLLQL6aO8ZL2W 2BUwwBXnLSiWRBBWYawE44OAaF7z7y2dFViAN3rKWgvUHJR9mwtpsehJ3WNlpDlwdjJE eqSg== X-Received: by 10.236.151.168 with SMTP id b28mr76669367yhk.11.1357750172110; Wed, 09 Jan 2013 08:49:32 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id h62sm71674097yhe.3.2013.01.09.08.49.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Jan 2013 08:49:31 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , Date: Wed, 9 Jan 2013 08:49:27 -0800 Message-ID: <057501cdee89$4a987c90$dfc975b0$@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: Ac3uhiMTl2sKLLD8Tz2ObQSOiuGZhA== Content-Language: en-us X-Gm-Message-State: ALoCoQnOzGl/ine0ciGNh9NHt+u3i9fI/LL0XZSomhee4isG8pBga6i7tOch1QZ4wDwYwOOQUVvI Subject: [pkix] Review of 2560-bis draft 8 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, 09 Jan 2013 16:49:34 -0000 Hi list, I just finished reviewing the latest draft. Here is the summary. 1) Text from Section 1 "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." However, section 2.2 does not have a corresponding definition for "non-issued certificates" 2a) Text from Section 2.2 "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." Switching the subject (state) in the second sentence makes the text confusing. Also "never been issued" is ambiguous. Please see the comments in Authorized responder section Here is an alternative proposal. "The "revoked" state indicates that either the certificate has been revoked (either permanently or temporarily (on hold)) or the associated CA has no record of issuance of the requested certificate." An even better alternative would be to allow for revoked to be extended for any bad certificate and have the extended revoked extension specify the actual meaning by including a OID. This document can define a OID for one of the meanings (fraudulently issued as revoked). This leave room for extensibility without the need to change the main document should someone come up with another requirement to return revoked as a negative proof. 2b) Text from section 2.2 "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. " - IMO the above text belongs in the extension specification for extended revoked. - I repeat that use of non-issued is ambiguous. It will help to define what non-issued is and to explicitly mention that a certificate signed using the CA key can be non-issued as per this specification. - Why force the responder to include optional revocation reason field. Change MUST to MAY and change the text to say that if revocation reason is included it must be set to 6. -Reference to "revocation date" in above text is dangling. It should be changed to "revocationTime in RevokedInfo" 3) Text from section 2.5 "nextUpdate: The time at or before which newer information will be available about the status of the certificate" 4.2.2.1 states - " The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs" SO guidance needs to be provided for setting nextUpdate in case where extended revoked for "non-issued" is used because the response does not correspond to a CRL. 4) Texts from Section 4.2.2.2 "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 above text introduces a paradox if a response contains revoked for non-issued certificates. Any response that implies that certificate was not issued by the CA makes that response non authoritative because the response is not issued by a responder that is issued by the same CA as the one who issued the paylod certificate. One way to address this could be change all references to "issued" to "signed". We should also explicitly call out that "signed" and "issued" are not synonymous as per this draft. Please note that "issued" is used extensively in section 4.2.2.2 5) Section 4.4.2 - CRL references This section needs to be updated with a note that this extension is incompatible with extended revoked and should not be included if extended revoked is included in the response. 6) Section 4.4.5 - CRL Entry extensions This section needs to include a note that "invalidityDate" extension should not be included as single response extension if extended revoked is being returned. 7) 4.4.8 - Extended revoked definition If this extension is used to indicate responder capability, it should be included with all responses, not just revoked. If it is used to indicate changed meaning of revoked, it should be a single response extension. Also, IMO it is a misnomer to call it extended revoked. It might be more meaningful to call it "Fraudulently Issued as revoked". Other option is to keep the name extended revoked but allow for adding a list of OIDs that represent the changed meaning of revoked. In current case it would be a new id - "id-pkix-ocsp-fraudulently-issued-as-revoked". In future someone could add id-pkix-ocsp-revoked-expired-as-revoked or id-pkix-ocsp-ugly-moustache-as-revoked through an add-on RFC. 8) Section 2.5 - Response pre-production. I think it will be useful to indicate that if responder choses to issue revoked for fraudulently issued response pre-production becomes computationally infeasible. The note could be added here or in the section defining extended revoked. Thoughts/comments are welcome. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Friday, January 04, 2013 1:58 AM > To: pkix@ietf.org > Subject: [pkix] 2560bis WGLC > > Forwarding Steve's WGLC on RFC 2560bis. > (It was misaddressed) > > > On 1/2/13 4:43 PM, "Stephen Kent" wrote: > > >Folks, > > > >Stefan has just published the long-awaited 2560bis update, and has > >requested WGLC. > > > >Let's begin a slightly longer WGLC, to accommodate those who may be on > >a post-New year vacation. > > > >the WGLC will end on 1/20/13. > > > >Steve > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Wed Jan 9 09:17: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 A80A821F8599 for ; Wed, 9 Jan 2013 09:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 zTjPt5qXWiuK for ; Wed, 9 Jan 2013 09:17:27 -0800 (PST) Received: from mail-gg0-f181.google.com (mail-gg0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68321F858E for ; Wed, 9 Jan 2013 09:17:22 -0800 (PST) Received: by mail-gg0-f181.google.com with SMTP id s6so375279ggc.40 for ; Wed, 09 Jan 2013 09:17:22 -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=2y8a9zYPt/sCi/rFiCjt+QoViiz3dw0m4UrbhXAig3w=; b=C3RaLLFIKhcvYc2RAFq/yEeptQ0MUCFtRlPBHhyUbJhr1g1sYx2nEwOhqMYnB5IeKO xXt0jJScHb8SvjHWIo+f2l41vJYRvgAvEOn/8q8ZW/Xjx0iu60leHfjlJYcM2fYhaOHn PCdfflSP0Rkh3WagbsdiXJ4gy35aeLfhAdksE/12k01lTdtyaWl5tRa4B+Ca0MaHxUdP OVydKESBwQRJ/irxIVeGUh8l5V9Fw5Kqzb1yFjaaxeBmpFeKRg4G4AdbohodP+x7hT8h Sdmog6Ph3z9x3CTMWTmc1azqgLlzww4lkjL3Domi/5z3Acqr3XuikCWGnyDVO6+bYQBB cScg== X-Received: by 10.101.132.37 with SMTP id j37mr21925589ann.55.1357751841921; Wed, 09 Jan 2013 09:17:21 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id q4sm66740116anp.18.2013.01.09.09.17.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Jan 2013 09:17:21 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Rybar'" , "'pkix'" References: <201301081618.r08GI1x4054036@mail.nbusr.sk> In-Reply-To: Date: Wed, 9 Jan 2013 09:17:17 -0800 Message-ID: <058601cdee8d$2e18d070$8a4a7150$@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: AQJTurzfUuo/qkb+vJxdixlo2qoa3Jc1nVmQ Content-Language: en-us X-Gm-Message-State: ALoCoQmAW8SzWiuXjgD3vggq/L+sgrmljOfNak91yJPB0qcC6XT81RXglpEQNAn6b+ZMADkbStfF Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 09 Jan 2013 17:17:27 -0000 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > Importance: High > > Peter; > > On 1/8/13 5:18 PM, "Peter Rybar" wrote: > > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. > > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are signed fraudulently. RPs won't make queries for certificate for which they cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently issued certificates unless you are saying that this specification will allow for RPs to skip signature checking. > > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. > > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? > > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. > > No that is a task for another possible effort. > It's not part of this update. [Piyush] Can you clarify what is the goal for this update? I think it is one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. But based on different threads on this topic I get confused about what it is. Having the goal clear would help us keep the review of draft focused. > > But this update paves the way for such extension. Which I'm not against. > It's just not part of this update effort. > > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records in > >OCSP database will be use: > > -- unknown > > > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect (to > indicate that a certificate with this serial number should not be trusted). > > It's important that this works with legacy clients. They will be around for a > while. > [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". > /Stefan > > > > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > From stefan@aaa-sec.com Thu Jan 10 00:24:17 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 6967221F8996 for ; Thu, 10 Jan 2013 00:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.349, 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 EwT77Tu90c69 for ; Thu, 10 Jan 2013 00:24:16 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC6021F89BF for ; Thu, 10 Jan 2013 00:24:15 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 002D71E28563 for ; Thu, 10 Jan 2013 09:22:20 +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 ubKgmThtifSM for ; Thu, 10 Jan 2013 09:22:17 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1A4511E29147 for ; Thu, 10 Jan 2013 09:12:47 +0100 (CET) Received: (qmail 67766 invoked from network); 10 Jan 2013 08:12:47 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jan 2013 08:12:47 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 10 Jan 2013 09:12:46 +0100 From: Stefan Santesson To: Piyush Jain , 'Peter Rybar' , 'pkix' Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <058601cdee8d$2e18d070$8a4a7150$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 10 Jan 2013 08:24:17 -0000 On 1/9/13 6:17 PM, "Piyush Jain" wrote: >[Piyush] Can you clarify what is the goal for this update? I think it is >one >of the following >- Allow for extending definition of revoked so other specifications can >extend the protocol >- Address handling of fraudulently issued certificate. >- Address handling of any certificate not issued by the CA. > >But based on different threads on this topic I get confused about what it >is. Having the goal clear would help us keep the review of draft focused. The purpose of this update is to correct errors, fix problems, merge previous updates into one document and clarify ambiguities. It is not to add new features to OCSP. The reason why the non-issed thing is handled is because it was not perfectly clear how an OCSP responder could respond to a certificate with a serial number that was known to never have been issued during the lifetime of the CA. So the answer is your first bullet. The update is limited to allowing the revoked response for non-issued certs, which required an extension. The playing field is then open for user community profiles or other extensions to the OCSP protocol to address the area of fraudulent issued certs or positive confirmations. /Stefan From stefan@aaa-sec.com Thu Jan 10 00:42: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 6D06521F84F9 for ; Thu, 10 Jan 2013 00:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.233, 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 YRICjhHgqNmY for ; Thu, 10 Jan 2013 00:42:18 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08721F84F8 for ; Thu, 10 Jan 2013 00:42:15 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 308A21DF5BD1 for ; Thu, 10 Jan 2013 09:42:14 +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 bETWWUkLmPCL for ; Thu, 10 Jan 2013 09:42:13 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D51721E0A65B for ; Thu, 10 Jan 2013 09:42:13 +0100 (CET) Received: (qmail 29368 invoked from network); 10 Jan 2013 08:42:13 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jan 2013 08:42:13 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 10 Jan 2013 09:42:13 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: Review of 2560-bis draft 8 In-Reply-To: <057501cdee89$4a987c90$dfc975b0$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Review of 2560-bis draft 8 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, 10 Jan 2013 08:42:18 -0000 Thanks for the review. I will get back with comments on them. One questions though. Taking any random certificate serial number in the context of a CA. How can that serial number have any status other than. 1) issued and not revoked. 2) issued and revoked (or currently on hold). 3) never issued by this CA. This seem to be a fundamental unambiguous factual basic division of the possible state of a serial number that is beyond question. Then of course you can sub-divide each category into further divisions, but every possible serial number will always fall into exactly one of these categories. The Responder may not know which category a serial number belongs to (may just know whether it belongs to 2) or not), and in such case, the discussed update is of no relevance to them. To introduce "Bad" as a reason for responding revoked, or to be more granular than this basic division, scares me, because there is no end to its potential complexity and ambiguity. I'm not against the community going further in giving more granular information, but I'm reluctant to do it within this update. I further can't see why a CA would treat a certificate as "bad" without having it revoked or on hold. What I feel less sure about is wether the extension should go into responseExtensions or into singleExtensions. There are pros and cons with both. /Stefan From stefan@aaa-sec.com Thu Jan 10 00:46: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 59B0721F84F9 for ; Thu, 10 Jan 2013 00:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.655 X-Spam-Level: X-Spam-Status: No, score=-100.655 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, 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 GhsqbTUo2OWb for ; Thu, 10 Jan 2013 00:46:50 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 320C121F84FC for ; Thu, 10 Jan 2013 00:46:49 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 769631E1434F for ; Thu, 10 Jan 2013 09:46:42 +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 s5o0Ja1OvXiu for ; Thu, 10 Jan 2013 09:46:41 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 234761E0C1E1 for ; Thu, 10 Jan 2013 09:46:41 +0100 (CET) Received: (qmail 56656 invoked from network); 10 Jan 2013 08:46:38 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jan 2013 08:46:38 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 10 Jan 2013 09:46:38 +0100 From: Stefan Santesson To: Denis Pinkas , Ferda Topcan Message-ID: Thread-Topic: [pkix] Lack of AIA and/or CDP Extensions In-Reply-To: <50ED7EFA.9040607@bull.net> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3440656001_28865896" Cc: pkix@ietf.org Subject: Re: [pkix] Lack of AIA and/or CDP Extensions 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, 10 Jan 2013 08:46:52 -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_3440656001_28865896 Content-type: multipart/alternative; boundary="B_3440656001_28807677" --B_3440656001_28807677 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable No, I can't read french. If you at least had provided text and not an image= , I could have pasted it into google translate. /Stefan From: Denis Pinkas Date: Wednesday, January 9, 2013 3:30 PM To: Ferda Topcan Cc: Subject: Re: [pkix] Lack of AIA and/or CDP Extensions > =20 > =20 > Ferda, > =20 > RFC 5280 is a base standard. There are other standards built upon them. > =20 > In France, thiis is the case for PKIs used by the Administration. > =20 > Here is an example extracted from such a document (if you can read Frenc= h) : > =20 > =20 > =20 > Denis > =20 > =20 > =20 > =20 >> =20 >> =20 >>=20 >> Hi Denis, >> =20 >> =20 >> =20 >> Nice to see an answer from you. >> =20 >> =20 >> =20 >> Yes, we can solve this issue with a validation/signature policy. But no = one >> composes and applies these policies in practice as Liaquat said. So, I t= hink >> it would be better if standards put rules about how to reach revocation = info. >> Verifier has only signer's certificate in hand to validate the signature= . I >> think signer's certificate SHOULD contain CDP or AIA extension or both. >> =20 >> =20 >> =20 >> E-signature standards are more applicable than the policies in terms of >> interoperability. >> =20 >> =20 >> =20 >> Thanks for your response. >> =20 >> =20 >> =20 >> Ferda Topcan >> =20 >> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Denis >> Pinkas >> Sent: Wednesday, January 09, 2013 3:20 PM >> To: pkix@ietf.org >> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> Hi Liaquat, >> =20 >> It has been a long time since we exchanged emails. :-) >> =20 >> You said: "it's better to use the approach recommended by the CA". I do >> think this is the right answer. >> =20 >> A Relying Party will apply a validation policy or a signature policy ( = if >> the goal is to verifying an electronic signature). >> =20 >> The RP will select the validation or signature policy which is adequate= for >> the context. >> The rules that are applied are defined in that policy. >> =20 >> Theses rules may say at the first level : use CRLs, or use OCSP respons= es or >> use any of them. >> =20 >> At the second level, they may enforce freshness conditions such as : >> if you retrieve a CRL from the local cache, it MUST not be older than t= wo >> hours. >> =20 >> In this way, the nextUpdate date that is included in CRLs is not releva= nt: >> the CA does not dictate the validation rules. >> =20 >> Denis >> =20 >> =20 >>> =20 >>> Thanks for your response to my question. As I understand from the >>> =20 >>> discussions this issue is not considered in standards. And I think it i= s a >>> =20 >>> missing part of revocation issue. >>> =20 >>> =20 >>> =20 >>> Best Regards. >>> =20 >>> Ferda TOPCAN >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> -----Original Message----- >>> =20 >>> From: Liaquat Khan [mailto:liaquat.khan@ascertia.com] >>> =20 >>> Sent: Wednesday, January 09, 2013 1:35 PM >>> =20 >>> To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org >>> =20 >>> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >>> =20 >>> =20 >>> =20 >>> I think it's also worth looking at it from a legal point of view. If th= e >>> =20 >>> CA is wanting you to use a particular approach (OCSP or CRL) as defined= in >>> =20 >>> its CP then if you as a Relying Party want to show that you have fulfil= led >>> =20 >>> your obligations it's better to use the approach recommended by the CA. >>> =20 >>> =20 >>> =20 >>> Of course in normal case this is not easy as end-users do not generally >>> =20 >>> read the CP document, or have the expertise to configure their settings= in >>> =20 >>> the RP application - so generally it will be what's contained in the ce= rt >>> =20 >>> and local default settings in the RP application. >>> =20 >>> =20 >>> =20 >>> Regards >>> =20 >>> LK >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> On 09/01/2013 08:58, "Ferda Topcan" >>> wrote: >>> =20 >>> =20 >>> =20 >>>> =20 >>>> Hello Timothy, >>>> =20 >>>> =20 >>>> =20 >>>> I would like to explain my opinion about this topic: A CA can produce >>>> =20 >>>> different types of certificates from the same Issuer. And the method o= f >>>> =20 >>>> obtaining revocation information for each type of certificate may be >>>> =20 >>>> different. For example a subCA can produce QES and OCSP Certificates. = The >>>> =20 >>>> subCA may choose to publish revocation info from OCSP for QES but CRL = for >>>> =20 >>>> OCSP Certificate for some reason. In this case how the verifier knows = how >>>> =20 >>>> to check the revocation info unless its is specified in related >>>> =20 >>> =20 >>> cerficate? >>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> If you would answer this question I'd appreciate it. >>>> =20 >>>> =20 >>>> =20 >>>> Thanks in advance, >>>> =20 >>>> Best Regards. >>>> =20 >>>> =20 >>>> =20 >>>> Ferda TOPCAN >>>> =20 >>>> Chief Researcher >>>> =20 >>>> ................................................................ >>>> =20 >>>> =20 >>>> =20 >>>> >>>> =20 >>>> =20 >>>> =20 >>>> Disclaimer >>>> =20 >>>> -----Original Message----- >>>> =20 >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> =20 >>>> Miller, Timothy J. >>>> =20 >>>> Sent: Tuesday, January 08, 2013 8:41 PM >>>> =20 >>>> To: Ahmet YETG=C4=B0N ( B=C4=B0LGEM-UEKAE); pkix@ietf.org >>>> =20 >>>> Subject: Re: [pkix] Lack of AIA and/or CDP Extensions >>>> =20 >>>> =20 >>>> =20 >>>> On 1/8/13 2:46 AM, "Ahmet YETG=C4=B0N (B=C4=B0LGEM-UEKAE)" >>>> =20 >>>> wr= ote: >>>> =20 >>>> =20 >>>> =20 >>>>> =20 >>>>> We have an disagreement between our testing group about meaning of >>>>> =20 >>>>> missing extensions. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> For example when validation a QES, if a certificate has an AIA >>>>> =20 >>>> =20 >>> =20 >>> extension, >>> =20 >>>> =20 >>>>> =20 >>>>> but not CDP extension, and CA is >>>>> =20 >>>>> publishing both CRL and COSP responses, >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 1. Can I use CRL for revocation checking as a first choice? >>>>> =20 >>>>> 2. If I cant, can I use CRL if I cant reach OCSP for any technical >>>>> =20 >>>>> error/reason. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> (Problem here is I need to know that CRL publishing address, and in o= ur >>>>> =20 >>>>> example I have it from elsewhere, >>>>> =20 >>>> =20 >>>>> >from another certificates OCSPs extensions in the same path. Weird >>>> =20 >>>>> =20 >>>>> example, yes.) >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> I guess my counter-question is "Why wouldn't you?" If OCSP is not >>>> =20 >>>> reachable, and you know from another context that a CRL is available, = is >>>> =20 >>>> there harm in getting it? >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> However, if the issuer is issuing CRLs but isn't populating CDP, this >>>> =20 >>>> sounds more like a misconfiguration or a contrived thought experiment >>>> =20 >>> =20 >>> than >>> =20 >>>> =20 >>>> a real use case. I can't think of a reason why you'd produce CRLs but >>>> =20 >>> =20 >>> not >>> =20 >>>> =20 >>>> publish their locations for relying parties (but I'm sure someone on t= he >>>> =20 >>>> list will educate me :). >>>> =20 >>>> =20 >>>> =20 >>>>> =20 >>>>> So rephrasing the question, do nonexistence of CDP, means dont use CR= Ls; >>>>> =20 >>>>> and same question goes for AIA. >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> I don't think anything stops you from trying. Absence of AIA doesn't >>>> =20 >>> =20 >>> mean >>> =20 >>>> =20 >>>> OCSP isn't allowed; it simply means an out-of-band method is needed to >>>> =20 >>>> communicate the location. >>>> =20 >>>> =20 >>>> =20 >>>> -- T >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> =20 >>>> pkix mailing list >>>> =20 >>>> pkix@ietf.org >>>> =20 >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>>> _______________________________________________ >>>> =20 >>>> pkix mailing list >>>> =20 >>>> pkix@ietf.org >>>> =20 >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> =20 >>> pkix mailing list >>> =20 >>> pkix@ietf.org >>> =20 >>> https://www.ietf.org/mailman/listinfo/pkix >>> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3440656001_28807677 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
No, I can't read french. If = you at least had provided text and not an image, I could have pasted it into= google translate.

/Stefan

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Wednesday, January 9, 2013 3:30 PM
To: Ferda Topcan <ferda.topcan@tubitak.gov.tr>
Cc: <pkix@ietf.org>Subject: Re: [pkix] Lack of AIA and/= or CDP Extensions

Ferda,

RFC 5280 is a base standard. There are other standards built upon them.

In France, thiis is the case for PKIs used by the Administration.
=
Here is an example extracted from such a document (if you can read French) :

3D""

Denis


=

Hi Denis,

 

Nice to see an answer from you.

 

Yes, we can solve this issue with a validation/signature policy. But no one composes and applies these policies in practice as Liaquat said. So, I think it would be better if standards put rules about how to reach revocation info.  Verifier has only= signer's certificate in hand to validate the signature. I think signer's certificate SHOULD contain CDP or AIA extension or both.

 

E-signature standards are more applicable than the policies in terms of interoperability.<= /span>

 

Thanks for your response.

 

Ferda Topcan

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas
Sent: Wednesday, January 09, 2013 3:20 PM
To: pkix@ietf.org
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions

 

Hi Lia= quat,

It has been a long time since we exchanged emails. :-)
You said: "it's better to use the approach recommended by the CA". I do think this is the right answer.

A Relying Party will apply a validation policy or a signature policy ( if the goal is to verifying an electronic signature).

The RP will select the validation or signature policy which is adequate for the context.
The rules that are applied are defined in that policy.
Theses rules may say at the first level : use CRLs, or use OCSP responses or use any of them.

At the second level, they may enforce freshness conditions such as :
if you retrieve a CRL from the local cache, it MUST not be older than two hours.

In this way, the nextUpdate date that is included in CRLs is not relevant: the CA does not dictate the validation rules.
 
Denis

Thanks for your response to my question. As I u=
nderstand from the
discussions this issue is not considered in standards. =
And I think it is a
missing part of revocation issue.
 
Best Regards.
Ferda TOPCAN
 
 
-----Original Message-----
            
From: Liaquat Khan [mailto:liaquat.khan@ascertia.com]

            
Sent: Wednesday, January 09, 2013 1:35 PM

            
To: Ferda Topcan; 'Miller, Timothy J.'; pkix@ietf.org

            
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions

            
 

            
I think it's also worth looking at it from a legal poin=
t of view. If the

            
CA is wanting you to use a particular approach (OCSP or=
 CRL) as defined in

            
its CP then if you as a Relying Party want to show that=
 you have fulfilled

            
your obligations it's better to use the approach recomm=
ended by the CA.

            
 

            
Of course in normal case this is not easy as end-users =
do not generally

            
read the CP document, or have the expertise to configur=
e their settings in

            
the RP application - so generally it will be what's con=
tained in the cert

            
and local default settings in the RP application.<=
/o:p>

            
 

            
Regards

            
LK

            
 

            
 

            
On 09/01/2013 08:58, "Ferda T=
opcan" <ferda.topcan@tubitak.gov.tr> wrote:

            
 

            

              
=
Hello Timothy,
=

              
 

              
I would like to explain my opinion about this topic: =
A CA can produce

              
different types of certificates from the same Issuer.=
 And the method of

              
obtaining revocation information for each type of cer=
tificate may be

              
different. For example a subCA can produce QES and OC=
SP Certificates. The

              
subCA may choose to publish revocation info from OCSP=
 for QES but CRL for

              
OCSP Certificate for some reason. In this case how th=
e verifier knows how

              
to check the revocation info unless its is specified =
in related

            

            
cerficate?

            

              
=
 

              
If you would answer this question I'd appreciate it.<=
o:p>

              
 

              
Thanks in advance,

              
Best Regards.

              
 

              
Ferda TOPCAN

              
Chief Researcher

              
.....................................................=
...........

              
 

              
<http://www.tubitak.gov.tr/>
=

              
 

              
Disclaimer <http://www.tubitak.gov.tr/disclaimer>=


              
-----Original Message-----
              
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of

              
Miller, Timothy J.

              
Sent: Tuesday, January 08, 2013 8:41 PM

              
To: Ahmet YETG=C4=B0N ( B=C4=B0LGEM-UEKAE); pkix@ietf.org

              
Subject: Re: [pkix] Lack of AIA and/or CDP Extensions=


              
 

              
On 1/8/13 2:46 AM, "Ahmet YETG=C4=B0N (B=C4=B0LGEM-UEKAE)"

              
<ahmet.yetgin@tubitak.gov.tr> wrote:

              
 

              

                
We have an disagreement between our testing=
 group about meaning of

                
missing extensions.

                
 

                
For example when validation a QES, if a certificate=
 has an AIA

              

            

            
extension,

            

              

                
but not CDP extension, and CA is=


                
publishing both CRL and COSP responses,<=
/span>

                
 

                
1. Can I use CRL for revocation checking as a first=
 choice?

                
2. If I cant, can I use CRL if I cant reach OCSP fo=
r any technical

                
error/reason.

                
 

                
(Problem here is I need to know that CRL publishing=
 address, and in our

                
example I have it from elsewhere,=


              

              
=
>from another certificates OCSPs extension=
s in the same path. Weird

              

                
example, yes.)
              

              
=
 

              
I guess my counter-question is "Why wouldn't you?"&nb=
sp; If OCSP is not

              
reachable, and you know from another context that a C=
RL is available, is

              
there harm in getting it?
              
 

              
 

              
 

              
However, if the issuer is issuing CRLs but isn't popu=
lating CDP, this

              
sounds more like a misconfiguration or a contrived th=
ought experiment

            

            
than

            

              
=
a real use case.  I can't think of a rea=
son why you'd produce CRLs but

            

            
not

            

              
=
publish their locations for relying parties (=
but I'm sure someone on the

              
list will educate me :).
              
 

              

                
So rephrasing the question, do nonexistence=
 of CDP, means dont use CRLs;

                
and same question goes for AIA.

              

              
=
 

              
I don't think anything stops you from trying.  A=
bsence of AIA doesn't

            

            
mean

            

              
=
OCSP isn't allowed; it simply means an out-of=
-band method is needed to

              
communicate the location.
              
 

              
-- T

              
 

              
_______________________________________________<=
/o:p>

              
pkix mailing list

              
pkix@ietf.org

              
https://www.ietf.org/mailman/listinfo/pkix

              
_______________________________________________<=
/o:p>

              
pkix mailing list

              
pkix@ietf.org

              
https://www.ietf.org/mailman/listinfo/pkix

              
 

            

            
 

            
 

            
 

            
_______________________________________________

            
pkix mailing list

            
p=
kix@ietf.org

            
https://www.ietf.org/mailman/listinfo/pkix

 


_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3440656001_28807677-- --B_3440656001_28865896 Content-type: image/png; name="efhcaagh.png" Content-ID: Content-disposition: inline; filename="efhcaagh.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA7AAAAF6CAIAAACvMyNuAAAgAElEQVR4nOy9v4vcSPcvrH9D 8WQvk03mSJGSCd4nmeA60IUOrgMHBsMVdGBwsOCgocFgWO5AQTMvBsMgaDDmmgbRYBaWBmEW zCIEy/drTCNYhucZhFiGxhR6g6qS6rek/jXdM+cT2T3dpdKpU6c+deqcU07FwXGcCvDosSM1 OK5mAQAAAAAAPBI4EpkAbgGojo25gtICAAAAAADYBBpCDAAAAAAAAAAAPC5IhHi/jBxwiNiR GhxXswAAAAAAAB4JgBADNDgu5gpKCwAAAAAAYBMAIQZocFzMFZQWAAAAAADAJgBCDNDguJgr KC0AAAAAAIBNAIQYoMFxMVdQWgAAAAAAAJsACDFAg+NirqC0AAAAAAAANgEQYoAGx8VcQWkB AAAAAABsAiDEAA2Oi7mC0gIAAAAAANgEQIgBGhwXcwWlBQAAAAAAsAmAEAM0OC7mCkoLAAAA AABgEwAhBmhwXMwVlBYAAAAAAMAmAEIM0OC4mCsoLQAAAAAAgE0AhBigwXExV1BaAAAAAAAA mwAIMUCD42KuoLQAAAAAAAA2ARBigAbHxVxBaQEAAAAAAGwCIMQADY6LuYLSAgAAAAAA2AQP kBDjDPkOgeujFN93f44Rx8Vct9csLpOx57jeaFHST4osnl6PAtcdxgWo0loo4tB1HHeA0uK+ u7JT3Cajc8c5HyW3+3hamcXR+1FwBibuAICLeOg6jhtM0tI+GmYlwXkSjQLXcRzHDcaz5P+O PNfxxklLg/36WWbz6HoUuGdhfLO9Zg8czIb7KNvVVLmJwzPHOQ3Qt7L9y/eF/Rooij0If5to JcR3GbpwdHCDUZTkh/qOpNsXKLu7754cJRQ1oBafjb2O3BDe00Bjc5VmiR2pNUpdTsTnOo6j I6Zqb8ssRiHbFnkhmiY5vonHH7g5WaRooKxhhBDXdo1TfiDEa4KMoD+Mlw9dfLfJ6HxPvB+n yHe3tOfHZTaPUOhxhv16muR4tYzGk+yO8y9oloDrOOMZgPbLbhg/7J0QtWPe6zhftX3ToCTl NxR4g+g7rnCZTgK3lnArw+4BbnQeDyHmbPjuOFkRh67rDWcHy4eqqtqrgaLYi/C3Csfp4CHG y2jgOgK/LLPZKHCd00H0vcdrlt9QcNrNcGyImzg8O5YxOEBo1aCqVnkSjYJTx3FMg4iX0cA1 aoW+2cY1YrIpq2X03HWfR0u92ojNrvL4teecBuPfSFNN84I+kO1yB0pBHZw7IsQ38+j3B00X 7jI0OGzHyZGC7DQ2I8RlGoW+45wGoyipp3OZxZQf1wafbBT5GbTKk6vQc3Vzln3Z8cMofRTj jlN0/mwDnkGGspb2Ko9fe2ZztxmID2JHhBgX84/zXnay+D2a9+3JGk+JQ3eHnAxn6HyrW5ft YB3Z7qIbuxX+dtGJEOtfiXgpehGFNQkx9VX0+AVOke8+As/ErmAgxJXgstWOI06R/9TkmDc3 W7uK9ZwYZ8g3zyih2XIx8tShXy2j57pTm7sMPb0/QrzK49f+w9ZSnEWT5FGwon1jY0JMrLHe eU/8lBxt0i0BzFGisKvd7iEPDjj7ONnoGJpYv/2cZ+6QEON8NvRf9Rh0vIyHT/v2pPdTql1z srssut5qZMs2sJZsd4KHR4hxhnzV8tJju11PY1ymk+C8nzRxhvxHdCq0fdgJ8Unw8qXn6k/0 1ifEfhA+9xxHG4nVnRCTY0HNXgin6NlEbqH8hsJfW2zZrlb3Vb54F7iP4UAZsAtsSIjJCQkf Li9htYyGQyshriM3ZB1+ZIR4U+xpJSXYFSHG+W/j4LTHoON8MQ7cnj3p/RSCo+JkW8Bast0V jkr4XQgxCQS5FzcAIQ19jb50AgXojRZCHM6WLNBN5sTrE+LzMP6LxPWqnLgvIXbcYLyQHM13 2fSz4N/Kv0zQNOGd3DRR6VRY4LvpOZcS47jBeJZxDIEeTDuOF06S5e3847z4D3vTGjp15fpz my8mNCraDyfs3XCeTK9R6HNf4OJVyiy+bvokhPy3tsxeq8zmpjaqCpdZRM/Nw6skXwrhH6JE RrNMS7w0cY1NMDqb+NxrFk2zTVSMHhqx19/mgn+c02D0OaM6vMqTTxEKPXcY3y6TSeg5jsu2 fyyuk2qC2PO/DelKfDi764Uo5hWjm4iE709Cumkcf0lnCiHu3CDrvNVIFvPxhDVuI8SKfV5n aeDzvZYsHoOMnTTIRRZ/4MauDvZQI/75DAT6pjhPptFl6D1pnqIEJ0iR0MwaaDIKTLPe8JQ7 WUmaWHDpcYZcXtP42u2AAC0hNk0HLYosGnq1ubj9PZr/zcc9yzO37jA/WPR0goP3NGCzjAmc yzDxUYax8Ska1CE9jhu8W6SfFO3t/Mo22WobkdKuNGPNXtBuXauq4uOXHMcLER+y3122RHpG A2XqA2cMi7v6Td3g3aLlhN8k/E4z9H7hOK2EWB8aQXKSpFknmapayXgVIa+tRlvXQmRZkPK4 WuVV640bjBd/zNQAYpwn00tqZFuX0kcPjRpQEEIcFzRU15GDHDYixDcVXsZDSs74k9weIRP4 ezToaNmlN1MNVlVVnVZ3nM+G/mC8yHHNEetVFn+PBhc0mJJs3EVGZfQQ8/0JXl1Ofs9xxeRD HHvNguG+RLN5VuSzoXdCfX7lYuSdMT2naxjdvbS3THtQJmOv3lrU8aZsr4KX0cAfRllRMc9N 8y7lNxR49Onsh8Z8g3Ix8lxhkaaDSBY87jWDXy7RdZKvDPaHl55R7DRShZp1JplBtMScdXZf oNlvWfEjHvqON06K5WKshqET3TgfJbeGdKVVHr/2PCYiEmDQKMYyHl50FRGTCdt/Fln0y8vg XwIh7tEgM7/dOauGENexwopl7k+IOQGeBsN3ZF+G89mQXxGqiji22ZJcz7U6T4h1iXu0kADT 7LXOXqJP8+wmj197urx76omUKRcu4qFLKz/gMp0EJ4Fm1hue8gb9os9pkz3Ehlxe4/ha7YAM lRCbpoN2oFbL6IUfRlmJmbtKJHzCoN8mo3MWWUfXC65l1dFG8zo4k7haRs+FedcpUJPknBCt wGUWDV8OnrpiBHzXV7bItkjR4ETfCD39U6bGTRw+YePSYl0rqv/nzIgRk1jP6H6yNRgoSx94 Yxi8uURXSV5nfJrVo1X4bTP0vuE4rYRYNoX1lkKglXRFpLtkneDIiPImFafIP/FRiqsinYzf LvKfcmzGXYYu2rSfGKMzyn6EpVT6AtlCQQGKdnQgxFVdqEHgxBsS4orfCDWcuAchbhYzAj9E cWdazMon9SLE+Hs08DjmITSCM+Tzyoa/R89+6USITf0Rl09q6eTyTLfJ6Fw0W2RpqedFe8uE UguMik4ubk/LDQpeRs+GjS+tjwzVRZpM0mYWU1lxb2SXnk3sy2hwwjsFxadTISgkSRtEK6il /BZ4GQ1cvh2yapJerZbR8xN+gFpEdJehC3GUyeNqEfVpsN4RdT/HlF5fcEAovoU1Dw81zkuq 3vxqKjp06Wpad0x9tJ5uWmJF6M90ESlcygFOkf+E5xbihDI9Reeg1YZMyC/SMr4GO6BCp6WW 6SBLpV6yK9YrFlejUtUiDvmQMPkLKiHWGCVRAToRYpwhX5i/jNuxRvq9skG2OEO+0A2pEV1c OL84tlhX8t8zwT2RRaHHhN9btrrXbO8DaZaTVZv8W4XfYYbeJ1oJMbULXvhrU8fK8UMU8Wd/ dCuvsdfNS6qByCzSd7mc/jpJC+6T2lHUmhtHmDdvd5S90TIauPzGqwvJfuzoRogrzqHLJLw5 IW48Q019t16EmDTBDpfpHrf9PJq9XV9CLHOv2oC6w7jARO05J3qTIr0mIRbJor6RIg7VQCPh RVpb1sYd8b8iX+Yd+axihvp0avJMS05nQqyOi0ErzGKXeXztkKONGy0++Rpv6+8y9Izrs/QW VjsjE4s2EWkGVGRsvRpcmxDzsNTd3B4hFhdLbe0g8VddCXGH8EryQ35Rwyk6f8VNH+OsNz9l XULcNr4djIm2A23TQS8TLp26LmWgTpxyMfK4Pu+JEOuURLAVPV9ZL1v1KXIj1ARxOyKcoXMW LNFmXdvyoHrLtlKGvr0POmnbE0BbhX/0hLhDAizdVUg+Fd3EE9ohC0YYza4Q/aG8hLTnxpHD VoGIi40QSt1srMnhwmOoiroRuhLiinfongboW7kNQlzxxTjdAUqL3oSYtMIHWRlruslv15MQ K5WSG1yg7K4J4XCD0fU8k3wM6xBi1W5qv2DPgm1tWT/x+fWJHXXJ9WjNlWtNMX/bJ8RmsQul rwWQpswrrtyHhh7p3sK+cqv80iYi7YCKH/ZqcEMPMZ3y5gCPLRJi/kP9iIuqskVCrDt3ZoTG WJ5fjAncHiFuG991CXHbdJDBYhic02D0QQyItyj8Kk8+MoeaZSC2QYi1SiJ82PeVdbLVBX/L jWhI6jNR7Bbr2l1LO8q26uTDlgTelxC3C//YCXGHDEH1NLOqlJc0SfaJH4zrLZS0vWjNjVN9 NuxB7IitiIc015JlEemyNAAyZDVooBBi3qHr+MPZ58stEOKqamKUHcd7PYvfrUGIWffqpLHW stlrEOIOETh1dpfj8MVZd0aIZTbJwBvEtpZNRkp0M7OkOjJMJFiWm3RdsQNCXBnELtgHHWwr 7k0cnnEu9le+cCDegxDr6/YYoR1QgRD3bJBxgnVDJlg8tKHI/24IscyNKERN3iYhlg6mb+Iw YGsNrwlabJkQt47vmoS4dTpoUCfVOY7jejSe2KTwRRaj0DvxQhSnv7cNxBYIsV5JeO3t/8om 49MmbdESFnHoM89du3X9p4OW9pJtZYgNs1r4noS4XfjVkRPiDtNMv/rKolEVSJWLfCzYdrmG Ls9DOUasV+sQRdEUqHA39CLEgkNX2Kd2b1YlxBUXo2zbvldylYkPY40RYddwtNjBtT3Eresr X22g+ymnhbZaPEN2QtzqIXZ9lGK7uRTESOwy8RU3USJ9KsPshhBXlU7sbVTGtuLykr+Jw2dK xkyH9YbrfOeKe+2EuGeD9bFG50VIljbzFGqDVrdPiC9QfWeenhDvwkMsPL0q4rCp/tm6Dd6J h9gyvht5iNcIIOSqHxiP10lAXb1rah+IvRDi/q9s9BC3surmubiIX51LEQ4262qy4XUH+sq2 6keI1/IQP3hC3MV2aK0Y4R+1Q05DGpRVU/EHa+MgOWjUtEwuA0/Yk61jlwF9CXElOHS3Rogr Lka5OyGujzXFlvSrqfytdWOINYm3OPs8ze5Egs7SgY3O3Q79EWeKthHDy/I7zNaWDRa5mZV3 2eRSXvz4o231qi2cTada8e8ihtgkdtKyelbAqvLZV1wSo+Wj9Ec0kIuja4PE1PG9/Rr/UajZ KjYRte+LNOkvtgbrRciaW4Z/xNM/6F810jZXMm7NoRQuUec+NxFifnnWRz2yD7dMiElSvOuj P35EL87l1co463cTQ2wb341iiC3TQZZHOhnPG7ZKzgb13kQlzmcvhFive2oMcfdX1suWiLG1 ETJHLlCaRoOBHC9qs65SSHrTl/Lrl6T42V+2lWHobX1YM2TCJvyjJsSdSpyooleLgDR7Mpz/ 9Vddq08VtDuMiyLPS8HM4b+zvzQMR548+Pt0/PYy9B13GN+W5T9ah391QDe4HDD6E+KKc+hu jxBXXIxy9zrEupNcnCF/JyETzUGEUH64/IaG7zNc4QydC7VWmjzRdatMfI8Gp/Xk0jdCI2hF g1jEoSvtUa0t02Nx/sVxEQ/ZHdp3GRrw8uQi/pk/XiicWaTojeG+SVMBpo2S6uxiF6vy4TK9 Gk5Ma4Da1RPPU9VVyd+3PagufMane5pFRIi4wIe0ZQ06N1iPrymhAi/nk49NiXGttGm9POUm HduUwWXydtA1lFy6Cp66pVVq0qw1+tSutQlx3eATzxNvR6PNirWl2azfPiFuG991CXHbdFCl cf6CU0JuHW/N6+pA2pS3UO4Mb+ckkjNOI8x+r6yXLXc/eVPFSNMI/a3neZLPosW62peVdWRr KIPToQ89kurahd9hht4nLISY8Zu2Si5ErFyBzKHHhxZVnDEt/owmX3K211fPINzwU5rETXE0 dxgX//4afdLfEk6aJd0r0yn6mBZ/It91/Hez2eevJW4MKCsljfPFZDjU1AkCiDAzV1L+0KAS 1E3YnxCXi5GxcCbzQ/S6mEOwU7TEtbV6IgHz6inlvTS+Ga6DSsV4pw5tp7nGdeVOvu5po8B3 +TyKNe3XR9u+WFK37oxSp1MSmlBj8lyoutDSctXsbIWyr+eMP9EqE+znS1qyl8hcLQ5vc0bS 1YWVSc4Xk8txHf7rDuPiTjmgr+tZ6sfFJnYpFIeAtdxaFFO3ipA/kDWJXwxsD1pPRHWgdpl+ eDP4l9uICPdssKqaEPDTYPSeCycrsvjDeIS48vu1tKWtZq35PC801yemWa7WFPXmHVkpT2Fj QyzMqVBgW7hDni7JhKPj/PcJGof8jQ+aupx2aFl4ZZ/1uuqf5Eeqkuh3JhqzYxtfox2Q0VdL tT9vBogveEyG73yU3OL8y1X84yfhgmRSl9ls/NJ/QnhPnkw+ZpgVsBotSrycX82XuN74ETVb 5YsPaPzSo33iQp64p2h6SQkWM03lt8mb509dvpE+r2yUbbdGtL6JqmqzrlWHZaWnbDVD39IH pplcmhbbA7cVlbcIv22GapvdFxxHQ4jVxHm7+cBl9pm7j+O9HKpLtZzb2hoKM3GXoNCyqQKx lsGO6ZsCQDdxeCbcpMKX31LS/AEmOBrmqiRWa41v+Q0Fgx6EWE7X1WfZ26/vdtQY4jqHktqp ELXGj8s9uUDZrfjK1gCeJnVPKEiFsw/j+K86yla+CogoMFtg1FapF/Al+jymNwM2zKNNdEKR DemWI3vLDfirmKQv3GWTy3iZslBC/s6wqqrEO5YsJboo6kwd4rb5J0MXjhei6FOSL8Ws8LMw /lP5RPb2WcVe8XcpcT3vpuHVTRw+0adMaH7IB1gr9keyTi0i4sysG4xm6TIeulREBnPX0iD7 yZSbKU6HmiHCZqAuO9AZRtJGPVgv0TWrI64rIi6ote4LdTIlWXFwivwTL7yMpskyld6lm1Oq iEM9iecj1Bt5KxITS4bzcvipFitwffQ1NZkd7fh2MqG6oeQvqtBMB20T6WQcL+u3FnWMZVfX ecPSpL6T1/T6MqBmlW/ydIlnFGfId/wQXdf2W3mKDmU2ozpyGow+Z8tZ6AqNdH3lFtlys9vY CC7ioWso2WG2rhWTRq1gUlmPfrK1Dr22DzIJdMPZD/kTA3ltFb55ht67q9Jx2q9uBjw6bKIG LCpmu82u8uy7yfw9XKXVBo8eeMsAwHpouR8BAAAAdgogxAANdqQGx9XsAQAIMeDxAAgxAAC4 TwAhBmhwXMz14SotEGLA4wEQYgAAcJ8AQgzQ4LiY68NVWlquoUM64OG0DACshdZ8HQAAANgl gBADNDgu5vogldaUmnPILQMAa6FjOiMAAADsEECIARocF3MFpQUAAAAAALAJgBADNDgu5gpK CwAAAAAAYBMAIQZocFzMFZQWAAAAAADAJgBCDNDguJgrKC0AAAAAAIBNAIQYoMFxMVdQWgAA AAAAAJtg94S4iEN235+p6GmT9i5cCvpAwd8GeajJ1MfFXO+DEJOyZdwl7zW4q2XdYDxL/u/I czV33O8N9BbrM+vt64Btg9g9d4DSLoWecZl9Hg3f1xc+p2jgWq8Krx+TxdPrUeA+QMtpnmI7 BC6zeXQ9CvR3NR8DSPU6ncHhLNNpMPqUxCPPcb3RwngB8hEDl8n44b7dNmDWky2BlBU/DdA3 +xDg7P1w9Fm+gP2esB8PMbkFwG7fb5PR+eO5JgBnyO+04N0Pjou53hshVulO+Q0F3iD6jitc ppOg3goGk/ReJnyz++KVjfCt1l7dZeii05Qsszi6DL3mbUfXn5J8hZfTV5MD1fAdg1g8fxh3 qfK8yuPXfvBuka+4Bpbx0G/bMHPVygRC3HF8DxyGKbZLcBUJj5sQK0OPy3QSnDyPlqtaPRzC jNv4ynGCEOKH+nbbgF5PtociDl3XG87y9uaLLBp63uuYN4D3hP0QYmK4rSamiEOXX7MJn+go 0LWxn6donlvEQ/eAbe5xMdd9EOLi92jeeoGWNKyrPH7tuWQR2iJu5tHvfTiCuh2lt3I49i0Z Pduxa2mRRUPPcdxgFCX1HCqyGIWe29L+Q8ZdhgbdFmPChnXLUvkNBYN2E0Fd0Twh7ja+h4ZO U2wPIJ6twzXOInAx/zhvPxy4icOzZn+Fl/HQ3/alPB17AuiCoxcmztB5D7a9yuPXh8CJ90OI xdmogUoQd0RVV8toPNn5U1pxl6GLQ44POS7munNCjJfx8GmHG2X3sJSu8vi13+8gxXQ+c5eh p2bCtFpGz90WUkVP9vXTp/yGgtPHc+YjAGfRJOnimsLLaHBi3DLhPH4btQVVaQgxgX18Dwxd p9gecEyEGOezof+qfR0hSrLLCL2uPQF0wPEL8y6LrnsGY6yW0fOT+745dS+EuIhD1xhAXFXV vggiLtNJcH4AYbs4Rb57yFzhuJjrbgkxzhfjwHXO2ldrGp+wu6V0lS/eBS1TSdMtPSEuv6Hw V6PNwik6H0azkec4hjgzcihp+mtVVRVeRs+Gh6vk9w/8PRpsHNttIsT28T0odJ9i+8DREGKc /zYOTrusmzQUZGeEuHtPAK14vMIsFyPvyf0agT0QYrIeW43dPggiIROHcYYox4ccHI6LuSrN 4jKLUUiiAV0vRHHGa9YqT6JRcEpD6Jpw/lWefIpQ6LnD+HaZTELPcVz/+cv/cerw8FGG68wb ptV8oiSDG8aFMefJ0kO+e3woAh/51xbmiHPSf8c5DcZf0plMiHH+ZYKmifF8Chfxq3OUYvpe uslL/2RX45t4/MFyLmQdJlxm82uaAySFZHAjVdzV4nKlMNyqqsosRkQOjuOFKM54ry2XY+S4 wXjGno7zZBpdht6TMF7myVXouY77PPrx38n0GoW+G8ZF88vTYPyb4B0XGx3NMoufGGfI1wwi Lxb5zTXQEWLD+Go1n9jnGmdhfGMIPV9PnvxkYfJ0HMcLJ+S1ym8o6DDFGuFsrBXqQOSLCRG4 G4wXf8xkQmyyGKQ/EYkO8sKrJF+2hTPV0USO4/ghioVcIoPy6BTyf6HPvwaCOSAjJRsc5Z52 NsQ011Y5w7EMMd895zQYRUm+qsRkCUFnyjQiUvXCSbK8NcUA4LyeWbd0IE4H0XcsPVAzEcwG RHk7ToY3TbNuMF5Ypm9jE6rur6OKqu45t0ywjpHdF6f2JmGSlzKovhk0pM1x/HCyyG/rqCTT wmRR9Y7za5PJcpehi/utNOA4JkIsDR6nRF4YcRziKpRzFaUACeb9vV1y2feCEHGGfEfHLRTR 4DyZctN1IqgENz2817P4XZO1JtvcC5R+NT9Fsrn1rOBSWOhP2Ou3p0LXdrAmKPJCKLwaP1Gb eTiMstsyuY5277pwjpgQk2ikYZQVFTmSdh2nCeTlE5hY/OsgWmKOFrgv0Oy3rPgRD33HGyfl Pxm64Ekht8aIq7XsITblPFl6SNyuNBkL57MhYWPsSJ08umXriL9Hg1OWLVFk0S8vg391K1nA tfAsjJar+hXUJzIhrO3Vsw8TLpOxV88COgVIigw/UsGbS3SV5HUKIx8WifPZ0DsPo7RkMqkX WvpXfzBe5Lg20+TpTVWcs5fo0zy7yePXHr9ABb9couskr5OTmjZJSiWlyKzPzV9l6I/F8DIa uCw7nqTW2YVsDJnQCFyn+bWshO0NzpAvJgWuJ09uspwGw3eTRd4odmM277pNsS1ohQq8jAYu y74q02j4Inh66oiZAEa5LaOBz3Q4/21sjxHCy3h4zlZPGpLU9A0v4+GFRnn0Cnk+Sm6pwWmG 3mRwFA+xhpm1DvFtMjp3aJTnikwKrvNST8jPL1hT+WJsKoTSMEL3JZrNsyKfDb0Tb7Qoy8XI O6HhWHQi8LPJbEDUt2tkeBq8+RVdLXLMWAFvXU02ocfrVFVFPJ2mntP4fk7sLDhNGh2p/XIx 8s7Y9rvO3LAH6a6W0Quf6Vu+eMe2l9aFyfHpawqs6f95+j//1WF+FSkanKw/We4/t8pxrB5i SlWj2WT06ywrmmkcxkW1yufv0exLFJ4JYpUCJMjoei9GdBWhc4mjoRopkFVBXMKJfOtdtUS7 iywaenRXjcv06qX/RGxTs/xonkJ1ne3OlTlT4RT5J2Qvnk7Gbxf5z9Z6EWUahT4j1or2853n 95H0CzdxeMbMEPnaPk5SjpcQ42U0cPn9CVEbqglKyCYxx9JmTNreyKu15of02bqQCYWvWHt4 EwuzSU8U2qOP1A1qH0KMM3ReP4L2X4pzrU3qmsbLPkzE+gtUki7P7At0zZAmJreK4O/R4Iwr ukRWuBMqBPw9Gnhc+5ROMcGSt5NrNlHh85xbGA6lKIedqgrTvEb/Ee9GiFs0v/bzUc0pUvTi mSz/teWpmSwiRes2xTbXCo1cUuSfCAMt5pJa5SY7tKwxQqtl9NzlJyZhvcy3IgdQCsOqV0j9 22lPDDQhE9IYtQ2xdllvppvcE/n0A3+Pnv1iGgXaPcFqyQfL0kRoMSDq21EZ8pRa1DqrDvd5 HXvP1Y4ZtitKmqy4ryNEwmrVG65S/2Q4rGeTqieKRSK1sBqVaJtfOEO+0O3ek+Xeq2/ZCTHV GD9832xEajn+Z/n1a471QlS0gR9LmTeoKXdqVQqyr+I8FkUcurVyE+Xgpoe62GiiMpSn0M0c P83k+Ev2dsvl9NdJWqjvK4NQam6qKyvcahk9d/nqQnxXpRfB6WQ830NQ5tESYnswunoiI3pA 9cvndgmxvYe3yehcPl3pTY8kg9Kl6KHUh5B7BS2f3pAQ24Wg9ROIC4lmpITQT/usVGMV6Jok 8A/55xrh87lKquQtASfGocRFPHR7nQl0IhwxBjUAACAASURBVMRtml9V9RLrjX7Pk7eBZjOw tjxbJ0uXKbYFrVA7rmuT/4ldbuTfvB/dXAHGHhYocxdJefQKuV1C3LaQLUYe18NOhJhPt7WV TdApOTkra4ZG3Xxadd5EiIUDB94w2nW4z+vYe74WIdbGWLZOfOqL5Eo38IVcVE+NqiRSLmbL /DIRuT6TpT3fbLewEmJ1Q6BITWH0pHhkLTKdxZF4g2khkV3IxiLbwiEj14KiczqL3DylXg/4 p+hcR24Yza4Qf9hn5zeix1G3YeC2rYSUN0qsqtE+cKyEuMUhxAVsSSBqsAdC3OqyqhtrQmik /ZjFXmi5b09CXMTDZ7wrgiXP6SzdmoS40zApMUW85WkxzQYCwVoSo2Z52H5uJ8S6YE16xKiV fDvT5as7W+LqOhHiNs2nfSIOVzXGYEN56iaL6j1qmWKba4VJLBZC3CI3elLvOG4wuo5b48XN w81dX6VTnj0QYvsQ81jlyUcWuSv55qWQiVMmmrn92oUW4eA8mYoTod2K9iXEbTrc53VsPV+H EBsMeHsOd10p6DQYfRAzNMweYuW0vysh1iXS9J4suy+HYofjWAgxKa3cShD5zRB55+Z9dAXX xJFQqao8PezaTzRVYxRU1dfs/5SnaI+Ga128icMz54kfjGuZ2CrKyScOGonVR+Q/WRIJiTfn S/STqbhXTuw8SEKsP6RWvnDPhJiFwnshiv9IBPVrZVGSutIG+xBiLrxMhjqhnJ0QYpOh5yW5 ESFuLYu+BiHukDosvqS6LjYos9kocN1gdD1Pk8uW+gBdCHGr5tdfpF4xrRlcW57bIMRb0Ar1 bbVtKmu8tWAoyxNyHIekeRhInXXmtp0UHwghJpkwJ16I4vR3QXT6sFeW/eI4Th2Z2ks4NMPP D1EsTITtE+IOVyV0fh1bz9chxFqrXgkTRNlQsfbrpDpHzP7S6olUhZbkSCgH76b51e7c7TBZ umZE7AoWQtx6nKTa2SKbjYVKDhoZScuz6mFtCR6SoD1tUXqu0lb9U2Tbp3FmO8oWymTIdLZY 3ABxXiXXCy+j6JM+8V8NZd4xjpsQ2x1CrWdMeyDExh6SCPv6giXZFO6cEJeL0WCiLP+61Dpq gteK97ILwU59eniITX1rJa9re4j7BWprQybomsSWrvaCWd09xK3LDP4ePXuJrn/xZCfxhvK0 EOLOIRNb0Aq1422EuKPc+NoRhi+3jGMLmdgbITYrMDm6rEP7JNEZGSpfCMIeciO/Psm8rPPG NEcBNv66noe4dUPb7XUsPd8+IW7IqI4QV1UlVA5pPtfbjVUe//omfEoak0tZdPEQt++6rZPl gD3Euiw00eUprgGrZfw5SS75QBxdoILo0NUIUZtXZDIWOktBLumWQ2EkfZKeonXY0MPiJk1S XvOsSZHa0PjLZ15j+KxeouomHr4RM7H2F1tzrITYqC23X+M/WBiTmvh/l00/7ylkwt5D2Rz0 JcR6Ne5MiFm1NfUvGuvJfMnmOsTEJnzV/LXLMGlj5tiHnWKIVYOLy69fEhoRqCk+gLPP03VD JgzZh1WFs+lUY971Q6mPxdycELdpflVVVZGi1+PktrlvhTva2kyeZkLcI6luC1qhoCNTN8nt LptccifO1pIgpoDy8luc/NtwPlkrz95iiE1D/FO2IW2EGGcfxk1vWVWKHl4teeB0WZgmA6J5 u24xxEYd7vM69p6vE0NsMAJt952JGUesZhFrVushVpIHpAbbY4g3nCyHG0OsJgGQq6eaSh/8 KQMu00/R15xx6J//lP9gDaVWst9qc1b+MY1/4IqXyCrPvpcG1ojzL5Poz1K1aHg5R8OnpIV/ yrJRQbKJ+Tv7q6g0T9HMSaXolfo6Nasu8lzRIlnhVsvpu/Fl6DlnYZyXZbNsa3bG/qv4P38i /ymX8Nf10HMrOFpCXDvd+QqIuEyvhpPG6pn+uhdCbOvDT1kf+hJithsUVlb7vkv8rfF6JJpa J0bqk2Ae00WPq3z+IUr1z2wZJlpESTk4aqogtVEfFtAmFBMtv6Hhe87DZPjreoS4vjBZqN5a pOjNxLJhtoaTNYLalBC3aX61yuPRsMlkICOrnJauKU9dlYllNGiyojtNsS1ohSIVyeWhPtcq t7sMDfjl35qXxjaQQnXqWj26/HW3hNg6iEoH2gkxOlcy6XsQ4jZS2KbPvQmxXYd7vE63nnO/ VZI0jAHZogIIdQW0Yk3R+QtuIRAJjD6G+MTmN2mZX+xFhALb/SbL4VaZoMNG6S8us8+j4FSs H1zTwbt88WEyX9YVJ9If8yvuv3SYWWAcVwq7PqdY5l+/5Q15dX30Z5F+nMyXuGJrfBO1U2Tx exT9WTYt0HUa58k0IlF3ro9+S6JPaYk5Pfj3V/qJ7inUdU2OhFiwCx/mos4B+smnNIl1oQ5E V8iiUmTTqyj9m2whLmefp19vq/qhTXn/VZ5cDcNfF/mKBnDTk1NykGrV/q3ieAmx7gIL3otp +yuL+tdmsrveaFHi5fxqvmwYgDAi7Odi9VZNUKa5D9TiECUsstm70CcVHv4sSP1pYsW8cVLe 5fMo1oTQ1BfIEdXFZfrhzaAuIWkJF1myusvaLzC2JwXPsbg6NxhdT+vTNVxm8+vx6O3CUjne PkzMB0MNDpmP57Vgmag5xkatRD0iaol7/vvWvzKiL9pllqHSdJKJuh5c9Y4JcyqwIR+X97Lg Mvs8Dv/1hCyWxZ/T+L9MnuYO8VQWgeMynQQnmk1Uc0S+iTzr1DRPrELaMIyOU2xzrVBBFLu2 tEU6+WXwlF2LE8aFTW4045mVp7XPoDb1sPxVr5AVv8Tg/MtV/APr9aFWXa7gQO1k5UbBMogC Hyiz2fil/4QQ4jyZfMyw3BNSjbQuutzUTtZAW4qU+uZJkWlxIiSTKMMtBkR5u3r33sxHVhKY fqf19Tu+TlvPqc+CzKxVvviAxi89+jhCEHXDSt1zfBHuc4MngoFWmagnHSvwTP6o6okps1Mq 9mybXxtOFunIndU54EOfdwzH0RNiSlU974S9VYim0s0orCZxvaOiy3lNeXGZzSPusgklPZOs KHwaGduyC5fESBfSXAodob73xjEj6m6lE6v2KYyy152V3tdQDcNyExKrP99c6lPEQ3FLwF2S 5AjZlzj7OEn+TfYh/NvtB84RE+JKjFJStW7VXJfVDI2STCZk3xMdoyok1xPwUfZTTbB1ffQ1 FdrklcfUwybtgCgntUHNxoyV8Tan79TbV9r4LF3GQ9cLkSlCvXG3qP0knVUMpXjskyef6ots DDLXonWY6huP+Guo5HxwN5z9kD+hIUmc3dDkWUtTjxYBl4tFaKsNnIXxn8onN1UlXvTVdpuU WumpYmTRcdiUl90BPCSlbfWsaDWff2Xq6dHcXbeuPKuqqn2uL9E1fTXNJW1tUwxvSytUkNQX 0u3xLPsrDp944WXU2H+93KrqLptcxsuUjTj/JwP4aE411765YLKRoEEh61+QJYaoh0YffmqK n4j3UgltWoa4Ts8iTtk7aVUVe0JCJv6qJ7hxKsilCfiL2VgSG/Gas+RybiIYDIjc5gVafBQs mDuMf8zkT0iKv0GHu75Op54rRj5DvuOHqGEckjBr7Whuv+vCB3A6GcfLekCbTpvsxkq6hIj7 yv++vv7f3eYXfxdj38kiVTmsvTD7u9TdcfSEuGMyAeBhwjluQgwAHAPkqxAeKrShugAA4KCw yuNLpLi9cf7bOPD3MXlxivwnyoNwEb8Z3jMhtlcRBzx0HBdzBUIMOFIoF6E9SAAhBgAOHLhM xr6pdAGfD7crKJc1EpTfJuNPe6s4qyfELZfWAB46jou5AiEGHC1Wefzas1XqeAAAQgwAHDYs GXX4Rzz9Y8enWLhMJ4HPx7hXVVVk8TSSI3V3Cx0hli6IBzw+HBdzBUIMOGYQTmwJCj9ytGe2 AQCA+wUJ2PVD9JEL7cVlNt89JS2y2Vhhw/cDDSEWcH8VkgH3iONirkCIAUcOXGafR7RI2UOC NVcVAAAcEPhLuR1NAYPdAGfvh03tvHuGKakO8KhxXMwVlBYAAAAAAMAmAEIM0OC4mCsoLQAA AAAAgE0AhBigwXExV1BaAAAAAAAAmwAIMUCD42KuoLQAAAAAAAA2ARBigAbHxVxBaQEAAAAA AGyCNkLc3IJ48FUk+QsbIZd5MxwXc+3RbJnF0ftRcAqXzhwPSD2g85FyhdIugctsHl2PArdP 9UlSX2zNosKsIMPR1CSmtyW7wSQ9jg4/DJCizqcB+vbQLzi0otNcuxfTsX8cnek4XHTxEOMy GXtHco0zzpDP34cOWAv3z1x30Sy3ZQJCfDy4TUbnjjtA6f5GDGeIFR/qTYjXJIhFHPqvZ8nH oXd2JPV6b+LwzPEOonroI0IRh67rDWfrVsMis4lcjrhaRs/dI+WLneba/k3HfYj3+EzH4aIL Ib6JwzPR51qkaOA6/jDe2416HUGcFnClyKZ4mIS4qhq31nER4uL3aH7T8sm+cTOPfj8mGfYG ccVtbky6COo2Gb8hFzjjfDb0Xwneh/sfax1wis6f7XOXcqBy2C9whs43cclTpwA57yUa/oD8 R/euIVsWLy7mH+ctjkir6Xj4VnrL6ECIizh0pUHtS4hXy2g82QdJvcvQhXMkzuxDxgEw1x01 e4SEGC/j4VMhYEn9ZN9Y5fFrw8X3DwZbIcSdBIWXX6ZfGzcSzuO3EfM/3P9Y64Gzj5N9ehYP VQ77xV0WXW92LM5rNTlqP/hgyI44CA3Zpnh1BFf5jsV0PAorvWW0E2KcIX+jOYPLdBKc7yWo F6fId4+J6xwqDoC57qjZYyPEOF+MA5efgOon+8YqX7wL3OOR4ZrYnBBvLKj7H+vDAMhha+B9 Rg/oQPVQNGRr4sX5b+PgdAPv3iOx0ltGKyHe0OdKRmVfhzIaZzZgHRwAc12/WZwn0ShgwcLB KOJvnzQQ4jKLr9lvpJ/gPJleo9B3w/g2X0xC33FOB9F3XOEyi0LPdRzXC6+SfNlyOFVmMQo9 0isvRHHG58TwfXaD8Swrqqqqym8oOBVuvnX/FfwP8ZM6lklsYjTL7Dk3+icWcehyTwvjgr99 10cZJqdDPGqLv8qTaEQ7fBo0t3Gu8uRThELPHcbFXf0dN3i3aMJPTcKsk9ukpQ6X2dwwYl0e Z5IJGV/HcYPx4o+ZSogtelIVWTy9HgUutZYWQakoshiFHvm6H04WOdaNvo+ynyZttMhfAZda elu/cv1cSYa3y2QSeo7jDiJyIKjXHNpyGpHWvHCSLG/FA1/DD9vGSyuHtXSeH+lkGl2PAtdH GW6Ezx66ypMr9onwgmbbYpOY8DMvnCRpGr0aoBRrshrINkx8zfbB7Tz0xACylnGG/Hpx5wxd 0XT4NBj/JsYrW6Yeketl6D0J45umDTcYL+wxz7jMYnZpsOuFKCYyN9peca7pNcRkOvjRcL3w Ksn+iMKXKLvjMgfYTxp7KPAK8xQwi1cP7cDhMp0Egu2wsBqd6dAbn2LNSf2Y4DgdqkzU7IHT GH6E+MUsysp/J5OPmcag8+uBcGs2t1YVWTT0yNBGaVkmk8juWa614TQYf0lnmg0ZzpNpTUTa Zyagqo6aEJeLkXdCk07wMh7yjKHSE+JyMfLOmN2nGsjSNZr1yX2JZvOsyGdD78QbLYplNPCH UVZUbDdv2YvjfDb0zsMoLauqwt+jwSnfK5zPhv5gvMgbkk3TMirduZvuJA4v4+EFfQVKSk4t CRa2J1Kh8bQjRf4Jn8dD7ID4vqs8fu3TicxkOIiWmAqczL43l+gqyTGz+I05NghTs0RVFUvz ZXOZvW+AvpVVp8fpZbKMBi5L3i/TaPgieHoqWC2bnnDbBm4J1AlKRZGiZ34YZSVmji7XGy1K zVgbtbE0yl99T46EBa8uJ79zM4U8l5fhCzT7LSt+xEPf8cZJ+bNMJ8FJYNCc79Hggil5vhjX ewOLyt11G68t6DwHjnR6L8foAxEa4RDuS/R5InSjmQhG22KRGKVrbI2ruU69gJJKCLySkGQs nhAXKRqcGAe389ATsWWTZ/XajdPJeC4RcTf45RJdJ41MBPtpnno8fTwN3vyKrrh9XWPQVKzy +LXnsem/jAau47jPo+XSoO3zRDPXZA0xmo50Erg1y6+JI5vmpHiFcCJHzHVDeKzm2iRe44sb B47M0xY+bTEdkvGxqaj9jR4V2gixxudKpiu3TvB5r2UakS0m/ZvOwUy+w3aWXF0IMmYkNJkM zBPbCQhth+xmVCNSUSVrnpQi34WKbF1wtISYqJBsFjmFVAnxbTI6F9cPokucBSS2VShqc5eh C16X8DJ6NjTwHvw9GpzVdoptIE9o+/h7NPDMlL0LIV4to+cn/CuQlclkTFueWG9lSX40LtPJ 4Jmwvqo8Dy+jwQlvQ8n6yjpJjTv3BcHc24UpNlVRYipQH7poMaPU8jgdCOlvxqhe3WtD164n qtg7EGKlhg8lrMYwRJ02tslfeahmWyg8t/6vmCOPU+TzNlloB2fI59cF/D169gvzPlpVrn28 NtZ5VQREjPxyQFtQxUheqs22aCVG+K5qOhq10YyF1DfF0SgMbs+hb5cJr+TyO7ZOPfp2PIdu CaXFy2jg8kIj1JA2qNX2qlKHW/sUrekQp7mk9hrpiePVajw7o5vNtOiz3XTojI9+Um/tjR4A 7IRYFwSj0Eqp0hnOPoyb3ZUS1Iu/R4NTvloKF6NMNI+bWpNLozaQNZubJ8rwr5bRc5cvuQIR xp1xvIS4TMYep7HthFgbZiNaWx2tIbrK55Ua83ntUfgyjajXAJ4s2gkxTpF/IryCkOzc94lV VftpvHGS/z4K3kqrkSIQmdHWHlOR8aiLOk/7TMKUlihtZJ6WYJkepxGJrk3xJx30ZC1CfBOH Z+IX+OR0IyHWaKNF/vr31ap0vfCrMtRIidccshBwJwlNjnyLyrWP16Y6rxGBSoiN3SBtttkW HYPRlQHtS4jVKk/84PYd+naZCD8kKk3b7zD1NBpLvmA69G+JyTTOoHUIsUQwyAP6EeIuxrMb 1rCZEuymw0yINSq6lTd6CLATYnUq6mY4kbKuIKVCBYj2c+cL5BCE2VDFpJqgKbgtPQtnyOf3 qeSEC6pmdsPREmIOOE+mlzS4qtFhyXwbjHXrVrumjI7jBqPr2BK8aHeQcCdZMkw+QuUTMfCX g3YRan0iATty0Z2dKQLhzqAlEMm3MR6rMKUlSk9tBQ7RmxBr/6p6B1v0ZB1CzF8nJA1eE8Dd Sojb5K88VUeIWzcVXFiIVnOos5CM4pwLY21TuTUIcT+d1wm+NyHmf6yzLcYthPTznoTYrCGO jzLcd+jbZWImxB2mXl9C3Eb7tkqIb+LwTH5WP0Lc0Xh2wRo2Uyc67Rzg4s3aCPEW3+ghwHEs hFjjUtWv7syfJNFNZUNZxCFNe2RB8UImR1WfQto5MeXN/MGHvPmrVf8ni6wnyTrAhjvBOWpC TNPX/BDFaXIpLntaf4ZqrMVDSb1RrkPnHcdxHBYDp8BOiHVOi5afa6PluueStj6RgRpcTVym 3jdmWYDbGY9FmLqTRLX//ALZlxDr21R92C16sg4hbkyiFt0Ice9gsPUIsY5PSKiT6hyH5oE0 b2FWuf6EePMLmNYkxBbbYtxCbEaI7Rqy1TjAFkLcZeodMiHWPqsfIe5sPFuxjs0U0WI6OhLi 7b3Rg4CNEOuOek02UZu2IjmYeQeDH6LraJroWK8ayC9Bt7YJG1kh+c8LL6PoE1DhXjheQozz 2ZC7wUhZ9noRYpuHmIFL8tUbL9Mj+P5Yznm7eog7n5C2PpFgtYzCZ+jqjS7BQu8hbnVmtDNU rTD7EOL1PMSbEuKNPcTGdbGPh7jHEaeFEFtCJjqunXzFABps0KJy63qIN4l/W4MQt9iWHRHi Fg3pO/TtMlmTEG/iITYr1YER4o7GswvWsJm6L5gpdR8P8b2XqzsUWAixzvxJZqiIh03uC3Hu SjaLnwaWYH9cxG+GUl6nMSVIHdTb5PKZ13TsUUeFbwVHS4hl3tNGiHXrYt2OuL+Sj0r4AHea cm6J2VXpMi6/fklo5KUmKxxnn6cdQybUnCTWxHSqsZZtT6yqCpfpVThelHVSvJTCpY0h1mxi 77Lp5w4M1S5MbSCgNpzXQua6hExoV1MxuceqJ2vHEDuaS45IFHWfGGKL/GVYCLGUmKg5XTVp jpA9QkoHSKe3JpVbM4a4h85rRNCbELfZFqPEthFDbBzcvkPfLhNzyESHqbdeDLFmjtx+jf/Q n/vzHVsjZGILMcR249kRa9hMCXbT0SuGeCtv9BBgIcS1rb/9Ov2yxJWwmcB/Z38VOEO+MbuO M6/47+yvwqCy5DKVjwv0lJswVleEPBNWy+m78WXoOWdhnJelOeizw70vAIJjJcTKhG8lxCzw UVTLIg5driyanoIMeFtmy5xjwV5CfcfyGxq+52ME9X/tVGWCnb0IpViLFL3RXw/Z8sQK57NX w2ld1IlGMXERSpoqE/RMhq+Bisv0ajjpwlDtwpSXKFaYSWEeTf2v3kl1ZTL25FVBci+168n6 VSbIoRlfBjgej5o841ZC3CZ/5aG6KhPfo8FpS9UnWpSKqxRbNZqDM3TOC5CPuOsyBXoR4r46 r4qgLyFutS1aiRGVsFWZ0CT+UpVgqWyNhqBYHdyeQ98uEzMh7jD1ehPilv5vlRDTnlirTKjt kIQlcbNtNp7d0d9myg1YTUdXQrzFN3oAMBNi5gy+zb99pfEGtZH6O40+zHNSQrIOFCtSNJAn hjuMi39/jT7RMyY6nVgVQ5wnk9fh+LecZAbUgYOkcKOxkiLpBsmoK7LpVZT+TQj05ewzvcaQ lXpl5QZXeXI1DH9trcwPIDhWQsy23aQkbZl9Hof/ekKWloLUtGYOCb60UD4beq4jFNc856LY tRX9aGEEVnV12ZQd1UAttO5wKaEtf22MOF7Or+assi//ie7yAjnIvnN/ym8o8AS/BU1gYtVG K36Zv8vnUbxsyrgKYAJhOXNcFiylVoRNWoWpCWVm3se6tmsWhd557Slpe5wWdNnzSFHPqkgn vwyeUpFSN2eLntRHAZzbUiMo06PFwaP6qY61Vhsru/xVBWCZNL5YNphLd6YylEsKWDSHpnZQ AZIx6qTkHcarp85T+1+vTSo0OaPdtNRoW37qJUYfVNfaZ5e/cASRPIUWRFrliw9o/NKjb0SY mX1wew29BUwmzW8Z5Wqk1DL16qq9nPFhhZaNC7ql/yZtV+eaTkNU06EjBqHHE2K2NyaBMThf TC7HdVg8yUqymetesA9cw3Nw/uUq/qETnsV0aIzPGpP6scFxTISYzFIvnDSBvkT69YaG3Kt+ m83GpNK44DaoHUvUPtIP6xuAHOc0GH1gF9Jk0SQpy2xG70rht8Ia0JXJOQ1GUZKv2CZVuHSj uXTKaa0DAJDhHCsh5tJ6iOuIXxrltFzu9JO/gIq/Rk7+CXcyOLmMlym7fK5WRRP4wEpO8+s/ i+oqXq7HLk2op5L6CXmHSXMBjdiErkPaJzbvy95Uc3ddVa+LYvabNLu5uclLMJz9kD/5uDAI k0sGcByHXxf5G554y9PlcSZ/bcFMGXGW/BWHT7zwkk91MOqJXIGh1hOtoGyPlq0fP9bFnwZt tMhfP/jUQ/wSfR7XV3bVMlSqSQh0hNdkQdFw9mEc/8Xd+ibroE7lOo9XL52nRNYU1i8l+Ls+ ms+klH//cjETs+99lBUm2/I1sUmM16tRlPxXKgceNBmlxEuHM+Q7foiuOdXjLyRTB7f70Jsg yeQsjP9UPrlhz9JOPaX0hzuMf8zkT/T+Tj55gJUosdhe7VwTNcRoOhqacRqMomT5hxLEXN8O RqjOPxm6cLwQcZlINnPdD7aBYzzHsq+rbKZDMD5/Wyf1Ft/ouOE4LVc3Ax4jdqQGx9UsAPBA 8UiyLG7i4ZvDi5GzZ9kC9ou2rD7AowIQYoAGx8VcQWkBgD54DIQYl+mH8bTLTc57BhDiQwIQ YgAHIMQADY6LuYLSAgB98NAJcZnFkaGq5/0DCPEhAQgxgAMQYoAGx8VcQWkBgD5ozXMC7A4g /ENCe7ot4BEBCDFAg+NirqC0AEBHyMlG4BvbJ+Qbp0H49wjl1uItXfgHOF4AIQZocFzMFZQW AAAAAADAJgBCDNDguJgrKC0AAAAAAIBNAIQYoMFxMVdQWgAAAAAAAJsACDFAg+NirqC0AAAA AAAANgEQYoAGx8VcQWkBAAAAAABsgiMhxPV1iy03oAK2g+NirveltNxFvvV95oCtgJSmOh8l t/fdk10Dl9k8uh4F7k4KDuA8mUaXofeE3bu7CzyewdoeyiyO3o+CszWrEZtvoQdsHyDtR4Mj IMQ4nw298zBKy+omDs8ebDH5Q8JxMdf7UFpcppPg5Hm0XFVVkaKBC4VFt4nbZHTuuAOUPvC5 zhVB28Eq2xT5Ots5Id7nYMnFy7q/HS6Tsdfl+zhPplGEQq99XDq32fyiJljrXs9BWnCHzcXU MmnTgXy/yzeFS1uKLEahRzvshZfTJMfFfDxJsem5veuXFVkcobCuB3gajN5Pkxzj79Gr9xkm V5nYcRbGN7ZXc4PR9Vz0WXRp1hGEXN3E4RkQ4gcMxzkcQlx+Q8Gp472O8xX34WLknbGi2Tdx SCfcMAbusUPsSA2Oq1krbuLwrLH7eBkPfSDEgLWw01WWrPo7JcRa4GL+cV7sYj4oPKY7/aK3 MLRJA6doMLykhz9t49KxTeUZRTx0t0iIWzqDyywK/VeMEBMHEwFRP+4nOF+MgxNCiPEyHvqO G4wX5Nq/VZ5Eo+BUpvJk7XYcN5ik/Q7KcJlFoec6bjCK6qsFcZnFlB83g8suNFE9YmUahU+b /lMhNAOH88WEtCawi7sMPfXCiLFk9frGVb54F5wAIX5EuE9CjJfTVxNlUgkqu1pGz11h2hNv 3JYJsdyTR4/jYq73QIiJjwoKuQO21BujXQAAIABJREFUgAdIiHE+GxL6tXUUceiPk3XCk26T UeB5J12l0elS355tcq3vhBCr7LbBXTa5JIR4Mp4X9p9Q16zB+Y2/RwMp2GO9+6hxmU4C15G9 YBRFigbc6m+7bxxnH8ZNJ3UTCn+PBqcin2YCYd/Qtb9aRuNJ0w4Q4geO+yPE5TcUDLpsvnce I9GlJ48Mx8Vc90+I6Uk3EGLAFvDQCDHOfxsHpzq6tjnuMjRY65ZdXCZvg9E0MvJF9RethLh/ m9xv906I69/+nf1VtP1klWffS7Py4GzybHNCTF255uhz/D169ksXQixCO6HYwUIjNPKOzcO0 7eP8r79K8BA/FtwPIaYW084nyGHNjk15p548PhwXc1Wa5U7cHNcLUSwkYuIym1/T81DxpE5M Qmpy5poTQ/XmW0dQ0TKLDU1zLS/z5Cr0XMd9Hv3472QaXY8C10cZbmL13ODdIl9V1Yp+03Hc YDwT3qI+u3Q6pPTxX+b6xYXcsWWAWPz6JJr7L1tLuoa9cimHjhuMZlkptW9ssM4zUxbpllc2 fWGVJ58iFHruMC7u6u8wIXMosxiFHumLF6I449ZL6YXE4SjTiJ7JhpNkedsWLdCc4brBePHH jK6yt00wAF22+dtlrdI29rzhNFp9VuQmqi3N/Tp1w/i27rPjh5MFd7rNDxbz+XFj7KP0p1b5 l6tuw8qBRg+7XngZTZO8s9HG+WwYvE3Kv9v5YvObFkLcu02cJxMyRqfB+Es6kwmxTcG0fVuP EMuwOpXRhX6m4Gw6zTYjxIyh2hZfXMSXzEG7JUJsfFyX9oEQP3A4TgdCjPNkylnbiWiIhL9S U9sse1S9cL4YB65zgbK/SQYSZy6/pk1MGFE1cdV0HDeM/9OsmuqsW+XJR44AXSXC7K15husN p/HlBXtKofQkxRW/tg2j7LZMrqPHp/1aNTiSZld5/Npj1UjwMhq4Drf64jIZezUhoGN9GqBv ZcUn65wGb35FV4scs0iepoWqMnmIy8XIOwvGv+W4qqoii4ZeHVTHpTe9RJ/m2U0ev/Z4Ffde jtGHRc6l6L1EnyfoKslxTTKax63y+LVPVyn2IGMEMzn3pFFGOJ8NBTqiRuatltFzt3m7Fetq vQzcZejCcMpZP3MZDy+oKJiQmWOvpUGOH/OLNPmVT2MfWcwi9zWTTDhO6QZvLgWR8kLjknfr A9a6zyQGYDBe5LiJemQyxN+jwQX7Yb4YB67VOYqX0cBlKlem0fBF8PS02QwkY88RUnmoDtuZ mbHnhAeo+tycRBvVg98vBa8uJ7/nuPZTuN5oUZoGS6JreuUnfsFemqxED3csOoS/R4Ono+S2 H1+0E+K+beLv0eCUhdgWWfTLy+BfPCG2KZipb90JscxfO/yE/I7qHr+n1aI/IWba1fkE2ERY 77LpZ/HddLSVeqMtPQRCDGgnxMRI+SGKsxLLuUTkr7VLgag4+yvOkE9zP4kNbWx686caxI7z DENsraoqtlRLip5God84RYo4dDmlL9Mo9Nluu0jRS9874dtUenITh2dsbSZvt4uDv0PH8RJi vIwGLn8GRxSY6YyQo0l+QAiESM44JqQ9dNYR4ttkdC6u5URda22kawZhEramCIEQlkPBEONl NDhR/2pakm/i8IxbO6XX0SwDSpcIR2c9L7+hQWhcqtmLn/CioG9U96G1QTXRR7YGOEM+J8wW mVACwX1BohT4ezQ444aGkJITOnb4ezTwOJUQhIYz5PNGSTjnVYBT5J8IOkD5ImtBllUXZmbu ebs+91YPpT+GwRIsp0H5+2ly/YLEJ01IcWu5t9UyCp81adlbIcR92yRbPj70mfzK7aJgxr51 JcSrPP5lYCSC9v6v8sW7xuWvHJsIL9iHELOtVPefmEIaZsPBxEqIa4/YKfNW9GhfBBDiBw47 ISbeIy6DrYhDt/H0LKPnLl9tB6fIr0N+iXoRl/CrV/GP23jI1si7DF1Ik5ksb8L5kfKJhiKT bV/jrMJFPHQFz80pb4aUNpWeSI+Q8w8eC46WEGtUi0Otk3fKh7UdVOmvJtrPwGIV4y6QG31A nqYpzWrHL1p3GboQuTg72dSb8ttkdM59fw1CXG8bzkfJfyWjFy0UBKfIP9HMXIEz2RuUF2nj toF+0iYTo0jNW3T+hSTKW/enCflwveGsjiIwF1jQaqC4yvYkxPaed9Dn3uqhsJ/uhFjqZ19N lt6c+VmsAW94GT17Vu/NtkOIe7epMQ7CKNgVzNg3IyFWYeGd7f1vInyos1gN59gfIdZAVgBV CKfBKEosJ1pc+0CIHzMshJjOWGlPXwNnyOcdD8Q8NdyU+JIvk8XVWKoIIfBmAjKdeD0jT1fd cvz8Idpp8hAQ/5zwV3nxMPbksZd1O1ZCbFwnCPTmTCRb6xFiQ4qMsKZuixCb1rz2JD8uuqnu ajdC3ByenranNMllYvWrsrXBDhxLIMRtMmkhxPbMM/NKTH7OEth1tU6177VFQtyaM9dJn+kf uqmH8uHahHh9TWYPko53dF94Fvb0QNe/NYi9d5tagfMftimYqW/78BBzjXCB5soSebAe4u5F 4oEQAyyEuAu3cIdx8ZMdYInBu4RrBuEblMh8Wt0um5Yrq0klM8qkvmS51dhxeU1VSQwxso+a EzsPkhCbVrgWP24XQmxaDxTP7uaEWBNK1AqWZeiFKP4jEbralRA33ru2pUVztqOHpUF1kSZR v7UjlqxzbLvbKpONCLG6XVdQJx44jlMHOpu6cXCEuJ96bI0Qr6PJMqwOcj6wgWBzQrxGm1rj wI9CBwXT9m33McQKmjRfMaarfwwxy4/ckBC3xxCzqHoatd+7fXPLgAcHIyFuoZtcipsXXkbR J+k8gn7BUwtG6g4Nizh0dWFqgq20x7pJMDskZK+eTrl1eVSPCsdNiO1uFRMh3shDbCfEO/AQ 9whtJ+lo9XogdbWHh/jZs1+v35y3O4nV6ayDtUGTo+vXN+FTXQ2PNpl0IsSmtVlzWqV9Blfb xPDlXRFiC6to1efe6qG0sJmHeMMkjSIO5WokdTftV7K1UTGt2Ndps5UQd1QwpW97qDIhVOpl 0CSorVFlgp0PdN0RrV9lgh1G2cPNgRADjITYHsvVqjoWtiqx0kq73micTNIqq0YlCh1U7QVJ plYiLpqe3MTDN1Jm96O9JvpYCbFRb2+/xn8UJqstHBSsGUNs8KryOrbVGGINiVQ9JfXbWbh7 N0JcfkPhr0mJWXkH69KiZrCxdhs3VUuDOg9x8jYwhG+1y6RTDLEasonLr18SVhhO9WTj7PM0 uxMvBaA1NAymQ0s+No8hNva8XZ/7q4fiStgshri7JuuAM+Rr3C4mbK/KRI822zcVdgUz9q03 IV4tpx+U6HZ72bVn5nJsGxLi2q1mMyZ4+WX6lfy1hXXg5efJnMsTFSMwafEWm6oAIQYYCbEp XufLJPqzrrajieahtxOZt/4N+ajLYjdfZkWwrSHFtK64wYc0/xClhbqo4PwLCi9c5yyM//6n /AerPcEp8p9yqeJbOM47XhwtIa6NLF/QFJfp1XCS4tpVIO6UhETMtZPq6MGcqJBCEuq2CHHL O0pQpqq8dClfYIsHfzH1q19qdktlaFta6hr4fKmmIkVvaEnR9ga1HOvEsty2yKSNEDdFoPiE ofIbGr5v+LThrzhD5zyV0WQmNN0kshWpj7YgBtdV5SpasUlrz9v0uU09tFUmvkeDU+4V1ibE /TRZh9v2FE8B90KI2QgKW0RRsC2DaOhbT0KMl9GzoaqWLXWIdbcxk9zlzUImqqqp8Gio4Vjz DfI/G2EVSrtoaSurL2m8XBoIMcASQ0ytcB0PV2Txe1RrZx2XQ+uYrPLkahj+Sst3m89MWcjX 3+XXjxEpT1G7KIo/o8mXHFc6L3KtiH+n0Yd5vuL2fKwUZZnFkwltU8i3W+XJp4jGxl2g5Peo 4fRcT4o4dF12szkJWOyQP/RAcbyEWCkv7TiCY4A58GjpU1Kj6ryJF6eKzeeSMkvaMAC9HWc1 XPkix+dN8QHWsrhmsKa41UVzwEcnY62Q9ncUQddOUg2myGbvQp/Ue/qzIDW26WpNvrDKFx/Q +KVHGz0L479SNDjREDjL0iLVCaanyUykRXuDlB9wE9CUqNdUorXJpINI1Rsl+O/b/kqrTFDT seKK7GpB1Kn+fpFOfhk8ZZdihHFBv0BjGHD++wSNadSmfrW29rxVn1vU4x+W7+WLhZaVAnaC o7cxvzj/chX/wHrlbxk1GdREs0yVMpuNhkMxXJue7Bk1U0P+jD9pvUfN3KYCabXCZfrhzeBf bFCHcfHTqn5qewZCTOed2hkS+/tE00kW/6DLnmc7W77aGr1eRFwc2Xy32QQ9aPFpxw1G11zg ZZnF1+9Gb/kqaSw9TpkCpAhG8zmb2nLQcG2U9MXj6LywbvX1wRj93xpwoHAcc5UJ8bqvy6l8 H0dTisUNRtechlkSHZg3iCuoTtdjzpmkyXVji4Rwj1Fzs5fj+CH6mKjspLmojJaPqPNdpJ7g 7OMk+XeZfR7Z5sxjgXPEhLgSFEOT+M+nS4v32Emsyx3GP2bSJ7PF/1FuquPsI3fXFK9Cyv12 2gtoXB/NZ1LevX+5mIkZ6PV9GXV2S0tRIVbnn/mflDmofCFDvuOH6Hqa/FdzaY62noMtbLe+ l4sP+OXuVjA0KEtYvh9EAX8Xq0Ymcgq/G85+yJ/QSpGcxTsNRh/ECw5li1dHMOPswzj+i7tl ULj7UIcim40Dqp7jWfZXHD4Rrl6rU/SIVSSli213sxl63kGf4+KnVT2Y2+wl+sy6zE8ZWbHr IvTU/PphlBZ65a/RWZPp7U70SZLBp1/ZDiFWyl/YAp07ep1xs7i4wWiWLuOh64WIS78xKZiu MYUQtwQ3695C8xNp2SUxxD/Fws8iGdA+t+fJKs6TadO+o8w+5UIWDbiEY/Xz+kH1PSOOo9Se 7/IKQIgfOBznPq5utkMtygjYM3akBsfVLOCQsMrjS6Q4zHD+2zjw+6QQAXqheyYTYI9oqQEF 2BEgZOKB4wAJ8V2GnpqKHwP2g+NirgegtICdApfJ2NdzMkMiPGA7AEJ8kABCfD8AQvzAcRiE GH+PBmf0sKZcjPwXj7be2YHguJgrEOIHDktGHf4RT/+AzfPOAIT4IAGE+H4AhPiB4zAIMasl ifPFJHz2mG/EOBAcF3MFQvzQQe+QF8NGcZnNzWG1gK1AzSgFHACAEN8PgBA/cBwGIa4TSDWX pAPuAcfFXIEQPwKs8uQjam6D06T5ArYLQyYo4AAgZ48d1NB0zoE7Fhy0tAHbxIEQYsBh4biY KygtAAAAAACATQCEGKDBcTFXUFoAAAAAAACbAAgxQIPjYq6gtAAAAAAAADYBEGKABsfFXEFp AQAAAAAAbAIgxAANjou5gtICAAAAAADYBFsixDQN0z/Yimk0Y9p7HRtvuO2Im3g4fPBlko+L uQIhBgAAAAAAsAm2Q4hxhnzndBB9P0w2TAvBuM83JrK4TN4G7bforfLkU4RCj1ZpYTez4+/T yW8Fq3Uvww1G1/NMuBJd982e18Svh+NirkCIAQAAAAAAbIKtEOK7DA0C9O1w74vCKTp/htKN Kxzj79GzX6y10HGZfR4Fp44Xoqhmt+xDx61v28L5bOi5TUVDnCeT0NMWwMffo8Gp47jecLa3 sqvHxVyBEAMAAAAAANgE2yDEOIvexodcIh9n07dbiOXARfzqXHt/LAW5XsT1wkh09FZVVeFl NHC5gt4kyERw95JLoZSK5fdxKdFxMVcgxAAAAAAAADYBJNV1Bk7R4G2iMF2G1TJ67lruOMUp On/VkNoiDl3HDWPOa00u+Gm8yOZv7hzHxVxBaQEAAAAAAGwCIMQdsVpG4TNjkDQuk7HnOLYw ZZxOxvOa1OIM+bIzmBBi6UMSRrzviy6Pi7mC0gIAAAAAANgEFkJ8E4dnNN2LuCdxvhgHrnCR d5HFH0bBKfkWDXItsziKrkfBSePUJN7TUzHOmP/taTD6rIQZrPIkIqG33nCW38ahW3tPV3ly FXqu4405l+1NHJ7JOWdlFl+PApqYxhfBKLJo6DmO4/hhlJZlMomsuWrlYhSY3cMszFd27hpB uK9wJTpeRgNXzZnTfHMPOC7mCoQYAAAAAADAJmjxEDeOTLyMh77jOA05K7+h4NQNxrOsYJT3 LLz+/8K6LEIT9rrK49ceVyEB57+Nm9/iMp0ErhhsQMm3H0ZpWVU4/4LCC+YoXeXz92j2JQrP hMhaObSANMuoNuGs9PvE7Ur4MS6zKPSeWF2wq2U0HJq/QGu6dQ/zlQKIcZ5Eo8DVVYXThBrv A8fFXIEQAwAAAAAA2AR2QkyI4wXK/k7Rq1fxj9t4eEJoa/kNBWdc3QNCiClXps5O4aB/tYxe kIw0WmBBde42flCSXsbXcbuJa/qL869fc6wwRTEIgbBhziVMCDH9vuR2vcsmlzYuW8ThuYWS ktZ6FESjBFoquRbNNal4GfJ7OJ63huNirkCIAQAAAAAAbAI7ISZBCJfJ4mosVGm4TUbnHKNl vtgmIoIQXJ7J4WL+YbpcseiC81FyKz+I0lkajyukkenpL9/+bTI6b3y05WLknXhNweAiRQPX HdSV18jPuxUyu01GL8TeSqCxJZ3z3oSwYEKODb/VRhXvA8fFXIEQAwAAAAAA2ARWQoxT5Ltu EL5BCV9jGC+jAQnnxXkyvUah77jBaJZx3yGcjyOs5R/T+Aeu+Z9UioFedHeBsjtWZUzITlPo rxxZKwbgNu5qnCfT6DL0XBaeUYN8p50T42X07JmhcITQ+e6EmPN21z/Xh1uI39wjjou5AiEG AAAAAACwCWyEmF13PBaTyViEADvpj+JMvZJDdHzefp1+WTaxCnIMAH2QjzKs9ZiSCApLEd8i m42DOuWOMVTWwWmcaZkqKRtsv2Cv1T1c9fYQF3EoJM+x8GvVDSx/c384LuYKhBgAAAAAAMAm sBBi03k9H97A464sf9b/4Xjtahl//koptfa3fMSwhjFT7y/nKBUdxqtl/DlJLv2aMRMeqTpW /ylLjIv4TZMeJ2TaaYAzdN5Oc9kFy/LOgfvG8vNkfqPrfFV3WOHTiped+1OZXEe7rDtxXMz1 vgkxzQpdZ+tSZnH0fhSc7qvONJmAp+veK0lV3Q0mqbEgdyuKLJ5ejwL3Po4+7hUkGMxtQrnW GX0mvV7KVi5GctrGkYIsFudtToojhaIhgDWg13Z6bda+EnJwmc2j61Hg7qVCFOU8g7breG0K Vuf2O85pMPqUxKMdqOKhG/+2smuafmuJcpGiZ+cKyXP8yyT9PWkqJ6i/pQUoWBCFQojLPyM0 Dj2XWzP4eAlcpp+ir3mGLhx3GBc//yn/wdoghPIbCgYou83QU0vohYibOHzWSZtpYLSeZ+A8 HjcxJ9onElFLNYylREMO5WI0mOzUbXxczLVuVs1W7BPKsgmIGve0ffxRxn4IcRGH7iZ3gN/E 4ZmmFkoP8OdLB2oTt4DyGwpUg0BWI/bhOqPPSa8/Id5sG3MgILkirQv/kULUEMB6MGk7qZS1 lxNXbiXaAyHmq2a1fNOgYLhMJ8EJYSBk50CwXVU8AuNvJsTmC9Koy9YbRiQUocxmo+EwSgXB EUJcf0f8LVNWUgyYv+uYZdQNoiWucP77ZPJlmUp3WNRM/S5ffJjMl3XFifTH/Gq+xHV8MG0W l9nnUfhLlBVsRa97/g0Fp4a75XCZvA06b49IITnHcb0QNREaZRZfvxu9/Y3xD+ZKlCdJ7Xh7 t6BUgxWqk76J82R6GXonu97mHikhrqqquSSF1ezbF5Q9YSewod8LIcYZOt+EFeEUnT/bAhcx neHsA7iYf5zv+rnER9W+HK41+luLpLqZR78/SF4JAOhB/WL7KepvdmltGXcZGmzGXMU7HPAy HvrGO3c3xH0a/3YYCbHuKrUa7F4MQjvQx0T1GBnXTlxmn7n7ON5PE9FdRSsQO44Xojgrm9Jv tVaxS5LrPDnqEg7Gi5p55skk9MhexAtR/QycRZOkLLMZPRrwQxSrxc6qqqrw9+hZaLx2Tg/+ qhHl7YgemDyXyl9tsNyHtyUcMyG+vymHl/HbaU+ask9CfJdF15scmuPs42QrR9X3ZxNxPhv6 r/b0XJwi/+mhEuJVHr/293shPABw78B5/NZ+CdfWsC9CTFjNJi3sM1vpSAnxwUB3/xxgxwBC vC/s1UN8KLinAaLHOHt6Li7Tq3BsP2K6L0K8yhfvAsMBIAAA2Ab25iHeFHxVg53jsFfngyfE 5sgNwO7wOAhxfTe44ziOG4yixBhby+r3PQnjJT0eafz0uMxiFJKYMdcLr8QDE/4p6hXlekrE 5Tc4SsVA+4vYb0GXvrDKk08RCj0SgMS+w4Xu2PvD/fx2Sc5k2EGbVbb6AWp9C3lEjCIq04gM hxdOkuXt/OO8+MmilZpzFkvcEde464VXSfZHFL5E2R0XGshOz5qzHb7BVT5/jyR90qTQdSTE zYmcG7xbpJ8UQozLbH7dSEPSZCmRhY8RJFDWbC6+2XG4kWpe1nB4yI+KcxqMIjIXpOB+9r66 mMIyi41vUicq1U+3aKAqQ51CaiK5adUgx0IRcJ5MI5baWGQxakYnX4njJU1e60gpGsKZnZtG tPxZKBnfaOg5juP44WSR3/4ezdWhUUXNcsE5Bej2uO7WaZUnn1hi2T+NkWQN4nwxYZ/wZVsF JRJk1MVemdK2mmGigsK1iK9R6LthfEv70xSe6mmHhTcaL/6YyYS4m4kzzD6N8RH718jQ9FKq gmmybs7C+MaU79t/IVCgM/595bw7OM5BE2ISD3oPN1M8cuxIDfbUbCdCTFSLJiLQ2xNNsSgc D3iJPs2zmzx+7dFUd1ymk8AnUenU8cYlOJNYcBbNTHOteKOmoUQ4nw39wXiRs3vFzR3r9Igi RYMTumbQtdMdREvMrYhu8OYSXSU51tyjTvItAqU/d9zPX6DZb1nxIx76jjdOyp8tstUM0CqP X/uaThoGzyIi/D0aXFBpkPirTjW/OcUg1wyNSeh/TR/rK+tJfDBnlGhOrTWBXZ9C14UQr5bR c3apEC6zaPhy8FQgxLhMxl7NWuhmoM6G0SeyWO8DIt9YxkPfUb9TxKFrKvJALmwiOZdStnST ZSFKCRfx0K3nS7kYeWe15KkasKh3hRBgswZK42Cf7KRyBf+mNCrPQIg5xuy9HKMPRGmJnrgv 0eeJMJW6jpSqIY3ZOQ3e/IquFjlmE7zp/GoZvfBptgyxP6blkiVX8GpA75S9QNldt8d1t048 4fbD8eVkwcnEfYE+vxceIcyvE5r4S5WQMNQu9sqUtlWk6BmVEo3JJPUTmqF0X6LZPCvy2ZBd 6dXTDhNhstEs02j4InjKvVcvE1cHjkoayM++8hsKPDpZmC4Nou/Y9FJvfh0ZsnhlD7Eh39cg EMtCoHs3xfj3lfNOcdCEmNnQIzh0eGB4BIRYKqLSeikgrX8il6EpFyPvXxw/EMukGG5Y5BpR KBH+Hg08rjZ2G2dqewTOkC+IQix9qN6DI7FGnCL/CScWsT/UdOounrTIVrWJy2hwwhtBU23H dhHhDPlCzfLv0bNfehBi+ZLLSrg2SN83fXl1td/KULYTYpwhXxAvowX1iJeLkXcmFFOnBJ0T girwVkJcv7iwsOEiHp6YfiWd5snS1taRvOPK/twmo3ORItD0aO4nivD1GijBrpC6TWnbIbLm C1TIqhrzVM8+UmpPSFf5Yvli53GKfD7HerWMhkOTEVMNo6zbrY9byzoJKzit/Kg0QkZZuMa1 UhW11V5pXhOXydjj1Vjslf6+hXXeVLQbdIPBntLLxNU/FzUQZ8inn9xl6EKThiS5k2VWajiQ 1Gh7z4Wp0zTU9LO3nHeMQyXEcpLZ3soHAqrqURDi22R0zpmAjoRY+gIu4qF4NifwFeOqyTmN pPkv87naWhlep+0Ragg+daIIhkzDmGlZQyWlVeyPnmK2yVYeoLsMXdg6qXllY5eUW9m5shLt hFhXFfE+CbEug0IYX80AaZpdjxBr7gy6icNz4xwpFyO+AI4qbZVh4xSdsxzHIg5dRYZyzw2E eKPJviVCbJxKvD/bPlImQnym7EjFLTdfCbHQhkxohWkixMbH9bVOOkJsegR5a+LG5u6g1RNi k73SvuZNHJ6Jqk5+wr+UliN2f1Pt4PId62fiuC+ci96WZ1ykljhZqKipYA0TfH1C3CKQTtOw Yj2XiHsfjdoxDpUQA+4Vj4AQN8B5MkWkJomF02gJMXdCJ8FkJloIMX/OKMFwTmJ/hBSOxoP/ gnGBMb+gcNG6+WobrWz1LMfcSbHJFhFRr5vjuMHoei5E6bVbbV3x9XskxNr8OXXDo+iGvMKt SYiVDhRxeN4l82aVJx9ZVL2NDHE3HxnuIWoVfveVmHxdo5D7IcRdRqo/Ia6jO5zTYPTBcCcr w6aEeF3r1IMQ878lNUZdwQ6sQYjNNpA7U5Ke3vdNtYPLf9jLxLFOqJsBtnvUVtx3OK3eNiFu tbrrEeL+GrVjOA4QYoCCHanBnprtSohZMpwXoviPpIXTaAmx6fIa7hHpJGjuwiCBhpoTcDHN qJctsD6iNSe1ZYFpe0GjHbTKVrtidc1x7iCiOqnOcYRy1K1WW/uF+yPEelqm2fAo0pAkvDYh Fm6Gw0X8qq3SNkldOvFCFKe/a/omKORNHAZsLphkKEl7bUJsUci9EOJOI7UGIa64pDrHEYr6 K9iUEPe3TusR4jKLUeg5fojiNLnUhLf2IsRtNlA3F3q+qX5wuY71M3FiC41uvPJpSIYcWNLt pSqTwelAiNsEsiYhXmO92y2AEAM0eASEmCT9SLlH63mI7fN5lce/vgmfkn2wUgFAuxHvm0Vq fkSrIe7kIe5rB9tkq/UQd3XydRQRX/pDCph+NIR4cw8x/83WssokBaq+Rq6VJQj+Zjsh3tBD bFfIAyDE63uIGSiJdJzWA4dGqtuTAAAgAElEQVRNPcR9rFN/QkxSHuVMys09xN0dsU2XOr9p q6r3M3FSN4jwhXtzSWCYrU7OTjzEZoFs5CE+oKoJQIgBGjxoQnwTjz9k/5EOo9cjxNRgKRe+ 13GrrfcdakO1NNnHOPs81XMR+yPUFBb2OtPPHUImWPdM/dHaQfmgv5UQq6k8YielF7aKCGcf xurN8MaAaa24DiaGWKvJgngNj5ZCDDcgxLVMLqO3vs3FpRA1PUsgQaKuj/74Eb3g/c0GDipF Ua9FiFsUcj8hE11Gap0Y4sl4LtQB8MzS2E4McR/r1JsQyxNwC4SYfkHN96I3NZpjiLu/qTZD TvUsdDVxDUhNGx+lP6IBH62kyeCk/ZtOsx2ETLQJZKMY4l7r3W5xzISYS7yDQsXbxcMlxLhM 3g5Q+lO2F+sR4loJhfLDOJ+9Gs0ZA7Pfs60m89KIN6EcY/kNDd8bSqLaH8FdZN1cyojL9Go4 4ZJyLAsMrTIm3UnO+qOzg4otbiXEdUgcX5uT66TmlY0iwhk6580rTpHvdibEuh1OO2kgcQW7 SKojLYvrqLSikMpZamantc5dH0Jcq5DdkaOIxeQTpaPwxPPEKwNp8Lf4lCIOXf711yHErQqp fIG98jYJcZeRWiup7vwFx4ruMnTRkuLG/5XO7q6EeC3r1IcQKz3cBiGuA1W58sPVKo/HI0v+ Wb83pQojEjtx9HuZuAZEXCeeJyWz0lqB7EJf+uYpejPhSmdskRC3CGRdQtxbo3aMVkJsCgZ3 vfAykq9d3j8M50eAzXDMhLhev9WVmJT/5pMAyPFukc3ehT7JO/6zSK4jdW9qrDVLfZDi5GAr nOlGbo/ULa6aXGOp7q/8K3M5m/ZHqBcxNOV4WCFSrn26RtYsxNYfoY5pI6sW2bI8Yt69Yeuk AmuXSJWJujJrUzG64n1FOP9yFf/QLW1koOs6xPUlC01tLLr4kVNdnC8ml+M6ZLm9hAU/1uon CuhwNHWmJ2+e0+AYutYyLzgtcUpqeZ6Tmrv0nVSBE7Xxxkl5l8+j2F71s9tqR9dgIpYym41f +k+I3PJk8pFb3mgemErHmYOTr9R7zhUMqZdP7uoErQbq+2+e7ETI9AurfPEBjV96Di9kCSyV jS/Q2z6VWkdK0QdmdrgdGquaTL5Dq0zQyY65Mro60P0VCR3B+e8TNGZ3VRA+2va4ntaJyYTb 0rQ8gnpSA/StrHCZfR6H/3riOI6PsiKZRNnPdiHrtJ0V1eZRXyFkqDnd0w6zXTGzPEU6+WXw lF0EE8ZFPxOnyFCdfULJefocJlXTS2kNDvsyX6uk58LUaRqSVuTR6Svn3cJxOniINRuI+j6h Zt2t//QNBaeicLcETcu7Ccre3SscCbRqcPjNmnNvObBwPVoDnO1N6ZRW9VnTrHIKnH1m9w9J N9Xp6DK1XcP4P3+K6c/cQWF945HTcoVeyyOoDeVvaarvD5MzfN1w9kP+hAaQcfG4dX+UAhT8 BQRG2f4t/kq83Y3d78VfcmaCSUQ4+zCO/+IuDxOkRykXn2mnosxm9Nqk02AUJcs/FC9XncZE /D3/ZOjC8UIUfTL2WU51v0DpV9PoW/vzOVvOQtcP0TXnjuBvwBJ9+fIwNdUJqNroFF7tva38 cANJLHekirAmzauIQ1f/vsItZYL3S5mG/tvo/5g0UG61bbIrX8iQ70hCriE5iVwfzWeS28i/ XMzE9HnaN/NIqRqy+Cjsdd1h/GMmf/KfPyfjeMldAmc3Fk2+KbnYjFTPJb6t/8TtjyOHEp2s k1JAQJWJ+o7OBUq+ij0kBNoPoz+X7fbq48JoXopsNmaKxVzFssxlf0cfOyw8wg3Gs+yvOHwi +g37mThO357oXX5c4HjTP9NLqQomXL3JfW42TTqBWBYCCSZb1FfOO4TjdCbEmg09NSviLqc3 m1wto/GkC6PVtKyr09kfeDl9xZ9cACE+TkJ8eFjl8SVSNrs4/20c+FvKJNjDIx43TEf/jwh8 OQgAAAB4mOhCiC2ZgIbru3oAl+kk6FTbUofWqlJdUH5DweARr3YaHBdzPVRCjMtk7OuV8y6b XG6j8PgeHvHoAYS4a/lhAAAAOGJ0IcT6iuIEm10rQu5eXzsCeAs1O+jt0Bv7mB8Yjou5High tqS74R/x9I9195D7fQTgkRNivIyH55CkAQAAHjw6EGLtbUkMLAblAmW3XICINt7OD6O0LJNJ lOFKDQn/f9+MnrPwfkKva7r8NdW3zDJqb5d13BnLV6iqJjBFvQeBNCIFuVseVFUVFzbtsPCm ug9C6EwdJ3RvgeGb47iY64ESYppm4YfoIxcrhstsvr1s1D084tFDydp5DGBZMsTa0aKwAAAA 8IDRTojtJaA5QnxXVSyHVL6Z1h/GS0wTF57I9TuVsohuGBdNqlAdEi61XCfYvhih6yRfNWki PspwhfMvE/R5EYWiC1muj40z5Es+ZvVBlJrXBVMIk+YzZ2tHXZFOxm8X+c+2utkHjuNirodK iCvxDluH1GbZNlPdwyMeLdTEoMdylMSyD/kqUQAAAPCQ0UqIDeVXGaSQCYU9S1UgxLhGvkQo Aa1S/meRXoWvZvltHJ7Q8hwqL9eUdG4ON4v867ccKzUo5CdqqjYqDyI8W4yTFr3mjFUvl9Nf J2lRaXn2UeG4mOsBE2IAAAAAAABHgDZC3FKBknlQhGuThGADWhaUryUp/Ekt0H2Bki9oHIvf V1vmgx/E3jbuaunORlJAVC7qbr/EXF9JQ72P2w2j2RVL9rdWRz8GHBdzBUIMAAAAAABgE7QR 4pYyDuLFsHr2vKLVKGVOrDJawiOfhm+u5GrVpvtppBNMza2A/FWipKKhdKWNGNggP0h/46JY mPkmDs+cJ34wrl3I2ykGd484LuYKhBgAAAAAAMAmsBPilnvgKC+svadG9qwE3VaVhjVS/64u F01tWfMsqbeSr5fdniDHN4s+ZqlZfYK5ePOnelGwyrOPDcfFXIEQAwAAAAAA2AT/P3tv7yI3 0/UN6t9QPNnLZBOtI0VKOtgrmWAn0AMdrAMHBsMt6MDgwOCgocG8hot7QNA7YPAy6KXBmNc0 j+hd48U0CGMYLoQW82CM0HIx3PcghBkaU2iDqpLqW1J/zEzPnF82Pd2lqqNTp35VdT7MhNiU cI2miaj5q5AEDRXRq1HjnPAjHB6aWaOu/IcyvZo2GE6okV27+WafZvFnPkeVfI4rPUgmuxWN Ord1zs0qnr1v2C/mCoQYAAAAAADAJjASYn3CNZK+lxR/x2gSOKD8+/fyVxqc6KPrGNaI/k6/ F8akwkLLSOWkix0zmtNljqeWf4Xht6Lm0L/KErGMfJWnP0rlg2RXDVIVvT7tlntSN1Lk+b7m gd0v5rr3hLhMo/Dt2Dva4a0C2dqxE/auAbv4b1LlZz0UaTQ7H3v2Xfdx0suHqXdse5N5+iMe D2417eO+iLQXbks/HwiubltpAd2wB0vJ+tATYpQvJ54tHNmWaRSG52PPtmzHP+Mqcdfsufgr nH7K0WXkHzXF4suLwDtkMkLUPPJfX8MPSYnkhGj6lqVouTKdjz3b9ibLnD+mPfKjS5R/mU4/ NRknkjQ6+5Sj+oz57/Lr+xC/WvlBhGcfesFFWdWF4F0/TIhNlMPyyCcfkjjqVqn8LmK/mOt+ E+KmxPzu3GzY7Id3Fphw0Ll2Q5DziN9ZaORTXgSeMwx/IFz107Ys2/VO/pfbW7GUIiVJ39tS Gl+nwXG3yqNFGoVMtsFDb/x2FucI/Qifv93Ne7wV/Xw4uIrHgztBs8jVN7xoJfZiKVkfSkLM WDQZjh+EsyiVtJY4EtCKFSgNp3GJqaplWZbrBxGTz5JG2vkh+VCR8EHTclWR0gOB75DUq974 fCEkyyTZIcQKGofe5HOOmC/UlF39oKqqinQ+aepxnH+QtgGKsDy2Psg+Yr+Ya59mLxfhlz4W FxWL94ve2UL6P8XorL8xrtNgePfs+3qy3QGMtYduD13kIzhorfLohUO9ubaHvvosixSf/7Xt +vCvWvzNcD5727K9cVgn3EZlGhF+fOfeY3fIcu4v+S3j1jtw4yCFeFr1sDvukwxvfCkpvoSL m0tf25qHGPAQcQeY6y6aXeXRC7fT+RMByucj93nP9Hm9n7JzQox3p7toeQOsJdvd4E4S4m7y MYZ5bAdr6LNOpNe8H534oCzExUoNE4GegjsvIsWJQ5EEQ3tf813Kcl5L8rvt0oMBSgL3ZBvT 6n7J8IaXEpRFo5ObrOcAhBigwG0z1100i8sNGnIIiqCO8r3W195PwY/a8QnxncNast0Z7h4h 7iofdRqcLWI9fdaItLwI/D/FlJo1UBIMRuF87FhS3vemBXx6p/c0RT/Cxy/vhFL1gyzndSW/ wy49HKAyOfMnmzuLP2QZbgzitXujBc6AEAMU2GdCTG9UiZt7tgi/FNSFkUFdvaUJSLKsQ28c xvmqOYhqYDveCXHRqacoueGtz7T0T5GB8niKfX4OvcmnZC4RYrZjohuP2NIsPPWdR36U5fGZ z6RAUTfSeC3jz9m83fwAqyKN3o29Q1443MObq2rLdvyAdabiRNtccCtk6wYJIpGFh+LiUabR OTOEkClLjfJ4dh74ru1HRfOwxi1KjxURlGXZ3ptl8oGwt9+NZGg38BGs1X4XX6ZR7cTl+EHE vS/+PUzmVEqqd/e/Bx//bJeP8BKbPqMyXYTnY88WFhLDm1rlcUjfMivjPvqsE2kd1ZF/mgYz fVgFKqLngyBBZFzKVZD68pleBCqi06m6k12i4pTWo6qqOvJV0k9FC9oZoZnUspz/24n3h0by 7MvqUFhb/URGqy1iAZjpfxykf+tfva4Dqzz+EAa+Y4+i4rr+jug9SOJwLMvxp3F2RZyCDEq7 MM1+Mncum1FyoUQCuvWwWuWLtwH7pObnOskXaThyLMuyXH+6zK/wLX+36cPo1VW+nBLNcf0p OwzdDDU8XQYNdbVH0VVGVx82GIyRD/1CE/dlWo8MHVhXW4gnN4N61ndeGdeAZQEhBkjYkRrc QLMoC4cu8QvHx2z1AqbK63cVjwf0+hXX6GZNgJRjhBxQscUOcbWXhsvqswcyQD/C4SENMCrS 8OUz7w+OEKMsGh0TYkeWELE6DEFDyo+eBR8W6WUevXDwEVp5EXiOuhEaMqsqbVMfv13F4wG1 ULXjJhv1ssqjFw71wqde+5SLl8uxc0DK8Yi5WSTZIpmJ1gI/ogSXmF0qt2ZRt72Xp8F5nK80 Kc8FrLLwiU0Ggso0HD0bnjTsjXi7smd15Cpfz8NQPh85AxJrS1Si6QPK5yN3OFnmqBHjkzBb md5dR/lIJ8SqXY35TWGaSKJkUD4fsRuqjvrcItIOQD/Cx36YrWrWq3giFcK65214J2YixFrr oZO/COOMME5qWc4qya/y6IVLpiSdDk2oumI8+icSc8coz3UaHLO+KH06QGvWWpZle69Og7M4 r6M8GYv6Ixwe02mSLyeeLXJxrnJtGU+cmuDS/hMH1mbuHHqv/gzOljmiLErtQ9+th8Y3q5H8 KgufuiQaCh8JN6NomT6sXnnPT6dfGGtZK6p5hpqezoAJDLNPRqfvlsySZzmTuPzNyOdpMP+c Fj+jkUvuagxLiakDm2kL6bOQXbfzyrgWgBADFNhbQnydBsfcuVQWPh7pCbGyDovAQuScetwU 5au0dCIQeOFhL4Vxs3Ujqyx8csDaaGU+bKFB8ehLCtgXGlFdaqM0cMkneDXilhaywDe5vcOh zV5eY5OH11cxi6IoFoVsiZVk+nwVjwf8WkWCcUVpM99plT9KA5e7cxfqz8vdECpTyi3+CIdH jPAx66Upz9GPcOgwJltoX/nuOspH5zIhaqnxTQnpfcRFqAshbhNpO1AaDOpHEEUVaQ2lTTuN PdVaD7X8hVGY5NwyqbsQYpSFwwNWLLI5YtFqRvDukepeeREMfW6+9+0AUVrmC7waozRwWV3l /FuksZTLsXPEcR2x1qxcR1ZFoVi09VAH08BRwtc3WGXhaNRj+rTOa+MMNT5dhGId4dcvdXE0 41Ki78CG2qJ6m31Xxt4AQgxQYL8JMZcUponwVdimcjl2mMl8M4RYUciQ9yEWTUxtp3SGXrUM 6MqSN1/Dv2Jt33UaPKb/VZYfZ4cvZ+BmgU81xJPLfoRYWfGxjUa0OQTrS76vS4gVRYLE/3KE lbRGhqBZwrdJiM1v6ioeD5ihrUGIW0Xaiqt47DNDEPaHdKw3Q4g11qMDITbKuW1SdyDEIl83 naZ3eGJV1RRzMI7/Kx4/FTyze3dAazCJfuLiAOTWCIu0yaMiKK2yvpVyM8kdKrcEY7T1UAPj wHGbbJQnkxhhTULMLSvGGWp8uggVfeSMm3J7YF5KtB3YVFsU77f3ytgbQIgBCuwtIaanmDhF nuDHabJNqzx+Tz3/avfiXRBipcnmP2xuAwXoDL2CVDG3kNpGFCR18NxwfswNttvJSlVVFcrj 2Sn2LmX8wFoJn2Zt4ylgb0Ks/O9GhNh8KMVcDorAQ9g9Ie78plAez4gbdN8NnlmkbSii0WP2 HgDvplTXF7slxCbr0U6IzXJum9QdCDHv+MtCKeduZoQOWXHv3LsDrRSH8G9LlSlVMK1qnsrP xBsjxOaB19lRDr3xOyEj7bqEWK1sqhlqeroI5XmqeNwr6nDbUqLrwMbaIr/f3itjb1gWEGKA hB2pwY00W4fFWJbF5ZnW2KYijQLfOXD8IEq+cPRiJ4RY/D7+EWvHpWLgrdAtDK37ZvYyDhXR c5de3GsoIGOmu9AsEmfm+kGUxKdcg+2ETymoSngFfQmxelw7JMRChc7OP79RQkzjwBw/iL7F PW88OojUDEPae/nSY5uLnwpa67EhIW6d1O2EWChH1TqSrmaEnttJfrS9O9CFbtZBdZbFlbhS Kq08cThKd1OEuF3ydVSZZbHVFbZGiE0z1PB0qZtrEOIuS4mqA1vQFuVt1W5zMQEhBiiwz4QY A9NcfNqjv17H4Qt1oJhghW+JEIueze3QnRC32g72uZeR/1iMzVITYuaEWL+Q4OCPujKZ2OCm hHjNE+KdEWKdqFuXk5sixNo3hQNr6rpcvV2ANiXE5XI8nEpfUzoD0DOnnSfIU1iProRYJ+e2 Sd31hLi7u2Q3M4Ky8PHjP89fDeRD4t4d6Eo32UQcwpFwN0J8KyfErZJn8swYI7nFPukJMTmC Nc9Qw9NFGAix3mWiKw0VO7C5tqhPiHeaww4IMUCBvSXE1+n0tJlgJFxXd5ooWc+bIMSt5q9+ rhQrjdLZTMkEdD7EVnsjOG+GGyQ/w+GA4RnqBYl17NP5L159jb4V0jLTnxDraCjnsbqmy4Rh SVjTh1gO7EDl108xjaBXHb99nN2My4T5TYniWs8n3ixSA2i2tW7N0ttbfR7iqkLZp9lX7X+N MFmPdkJslnPbpO7qQ6zwbbhOZx8Vcu5iRurM0CTLFSfY3h1o9yF+NxEynzTtK5VWGUJQf3iz PsS6gf9OppNF89ZIFgj9KYzUJ/2KcByk19JUEsPgDE8XoZ2qwtKjPELWKJK2A7821BaND3Gv lbE3gBADFNhjQhwM2RnIBjxp7Ls030yEWDbBOEtXHwJBKoSzs1p5OGrxSRaLJHilSbCqJFW0 WC6XE1duBP/2wHEG/M+JZ5h8RFdzO8pO2OySqEzORlOFh/EahJh6HMpE35Ssqo2KYbHwZrol UE/t0tqgTgfGJBiuyotg9Lax+7r/3gQhNr2p3+pJ0StrSrtItSiXY201PhJax+ffoA6L6kp1 Fco/TcO/1s1LarIeHQixcUa0TepOWSZM7SuHYzQjKIuev2zy62FnYib7Te8OdAiqG7A7Q5QE rq0hxHXSOmkKNJbzxghxm60bPGWMORdbuW6WiR/h8BBbWs2yxVBY/dNFKGYlTphYZwZUuv0Y lxJ9BzbUFtX77bsy9kYrIdY6eEnZoQH3B/tMiI8b1zR8xlObeGwOnElcXueLMMpWxNbga/0y nU+euY8wvcjj6fsU4fk5GMdXKP90Fv1ElBuRn6B8OT2d1C5xeG5LT5H6SwkW8VBEZfLu1ZDm 4ceNyGnJDQUFpFzIBN0aUS085B84eTCXBpgjInLm+XpBJWcqXnBRVqhMP078Px5hTlnE0zBF lSxbhS8jPW9gc5EOmCj1mh7VqziVrToXKRYLTiZNlaS8mL56ckKGceRHl3THgh1pVvnyXTB5 5ljMF+QXKpYasZjDNuN/de+uo3xIRBSbGKFmySxD1b8psizhwRbp/I3v4gwPfxXxeVgfUJn0 uYNIlRCmpwi6DHOeplXjsGh74/MPTaWPMo3O34xfG2qy0CNJ6sYjwWg99L62DAwzom0+ynJW SN7YvgzTE4skGHIZrKhHSiOfnh2g2sgcMxPFIKpIskzUOWvrrNuVUmnr98WmQh80qk7nDmPT aBJxzTtq7aEebTOoTj6dz0fOgem1Sp2icbcun6FZIKmaGZp8NT1dHATxwne4tMHM+QKRj7Q9 MCiSafgbaUu9vXHGyxJli7NFhswqTZJymryo22BZHU6IFWIq0/nYa0uALwEPRrO5B9wdKNVg H5q9TqenUZZQZyahuFqdh7yOlamjAfAu9lqYUYSQcUuy8JNfaXBsOX4Qfmjq/YhPkYHK9COp 32N743mSRSOba6RiStmZdp9SCDBvy9jyadpGLiP/kfpMhas15/pBJBka1tuSjxyvo2fwbp6s Xo0kOdmKddcYXwu2C9wRhRDFfORHf0mfaKgYMV/0JWZz33b94HxGxNNEVuFjXZQGrsV+QSEp xi1SFWze1KBq3oP53bXIBy+E/MLgBuTEt0Fzqq17U9JgyUlhrb1d9LlVpJK8uH5qkutxg+N9 J/J4Vlcw08hcQh0Or8/WorMeev2UoJ8RlXlSy3JWSr6pCKgpHslD/UTmnItoiKJ2XZ8OiNlU bH/+U/wk+nf6bhJ9r+WjnQiN0rJ1zviyf4KG2KPo51z8hHdh6tJDowJpJI+S6STK6unf/lrF N0ROiJ8FH3GxJLHAoXGGtjydBzkhfhp8fE3mTmNRpaNPse66ZilpHf662lJU9aEMz3G1k6je Qq+fhc2yurhMKG8hu+ddqrEmIV5l4WRbR+KALlCrwQNrFgAA3D/wnqwAwO2i3RVna9h2GYs7 CVREr7SlSdrQiRCrwwzbwsy3BFQmU2+w67BiAIf9Yq5AiAEAQDdcfQ0/aFwmAICbBxDiraK8 mE4+tBXi1qILIdaEfdyEcLGPy24zzwFk7BdzBUIMAADasMrjD2G4WNu/EADYAYAQbwtFGs1C vVtbF3QgxGrXCOwuLfgQF2n0jnr8sKGFrHsKl7OJcVWpfU2ok7XoPY1/WPvTYLeSf8XT93B4 vHXsF3MFQgwAAACAPURLIOD20CHg+MGjAyEWHYhRmS7Ox57dhJ9XVVWh/PPEO6SphUhgNfeO cVSNK+Q6xZWpi2Q6eb3Mf4u+GVIOkSLybVoMvUxC372JfdXDw34xVyDEAAAAANgvtIREb/NJ QlQo3Lqr0UqIaeYL/8+ArbgYhGxILwmI5vK/KDPz81XUSZbHLJv9OU0K5hMuL6yUB5HNkQnh ETvBfjFXIMQAAAAAAAA2QSsh7lLpGydUEqoHKQvPsO3g018/nJ8F5IfiebDIj6s66R0kbtst 9ou5AiEGAAAAAACwCdoIcYcKnOrapB2r4D5yvcmSSyzK+GYwdWKZhkkSPuDEO8R+MVcgxAAA AAAAADZBCyHuUHhQXXNcrNRaRL6tqrAq+Qcz7Qj8uGlb4aAM2Cr2i7kCIQYAAAAAALAJzIRY k3CNg1iCvKoqqbo9PuvlviO5FEvnwQI/LqLRqObTuObQ+vVIAGbsF3Pt0WyZRuHbsXd4s7GY RRrNzseefc/y3eBKm4bKsbeOu9/DdqAyXYTnY8/uE3CzzsB7aykNCRKc5QAAAGAvYSTEnWrR yaSZliBvTnAvI/8It4Py799LpEgf0XynyPOS48fo7/R7gdLAZU6L1bVCAFvC7TPXXTTLRNre ICFmMgxyCk/qvNvedF/LBJTLsWPf6f7f/R62gYlD702I+wx8DS29jPyT0fzLfOTCZR0AALgH MBBiYgpbjxmwUy+1mEUajhyh9nTtiFz8FU4/5UiRPoJ+8iGJozhfMYz5X1/DD0n5u4hGtuX6 YVLWfYN0ejvD/STEVXWjWdBZKDKi14XXt72vK76EC7g5uUWgYvF+sc2rgA6Rzd3aWYRfTGrf Q0tRGf85wheAKItGJ/xl3dYlAAAAADuHkhAT0tA5ax0q049MPY63Yq0QfH9ne+N5SuLnRHdh Soi9N0sSKoedImpifZ2G53F5lc4nnm1Zlu34AZv3DbBd3AHmuqNm7w4hxrhOg5NtEmIFOwHc KFA+H7nPt+obsxVCvMqjF65Z7btrKfoZzb6VzZ9Z9HrWXN9tXwIAAACwc3QozAF4eLgDzHVH zd4xQlxeBP6fW/NwRfly4oFv/S0C1yfadnHUzQnxKl++8ew2td+Glu5GAgAAALBzACEGKHAH mOv6zaI8DscedRb2xiF7YaEhxGUandPfCD9BeTw7D3zX9qOrfDn1XRotylYRP4vzzHQfraIa KP80DWaxmD1wlcehVP9cuLQ58qNLxiXadoMEiaXOmRwvrETYixpmaEXzHa4CJXWCsizL9afL /Kr2x9DFYAn128NmgJ0ep5Cd3AHGs5ayfyxh7jqL76FQq4l2W2qKlT+vCy39J9lvlBdr/BvA 5TxNQETTLMv2Jstvc5EQ1+VCVTouvhrq/NZAw617aCkq04iWasL6v9JJ4Hcez8JT33nkR1ke n/mOzRSPVWo7AAAA3AKAEAMU2GNCXC7HzgEp7o2yaOQy2U4qNSEul2PniNIaQr+oTzw+nLMs y7KfBfNFWuTzkXPgjJdFFg7dUZgWVV233HD8pr2MFrDKoxcucRyiPaERS6QeJFepMXAtdxTV EU2qtDAoi0bHZHRlEgHB05IAACAASURBVDaEnhma9/I0OI/zFSVPtcRWWfjUJW5L+JQRN66L wbqKxwPq+EQ3DPYwSIqq0+MUAtF0gDpicYUtcYUgLB9VD8kJupRYvYh8G6dKQGU8cahIicAJ e+vWf1UgMsrnI3c4WebNJsoY/4CycGgfesFFWVVVmYSjp97JIcNiURlPHNubLHNUNe+UfF/z ajok0OyupahMph5RfnL23ISaCBJoNipHz4IPi/Qyj144JDGFSdsBAADghgGEGKDA3hJiMcGf xANkQnwVjwf8Mkz813neKUSXXqfBMcurUBY+Hm1KiFEWDg9YqiTkNKQncKQnRRI8fcxRSUXK lyx8csCOju+JXFWHkxhKAveAcR5dZeFoVDcuDgoTNY7qkTI6VFAtj1NIxNABOeGjlBNdnexc JMRMBpsmH45Snu39lwkx+hEOnZYtmTRkZ7xsPHQJp6SEuFyOnSNuC0F2AkLOyp0R4nI5dh5p xa7YEpAvcINq13YAAAC4UQAhBiiwv4S4jCcOwwzaCbEc31lpWCNHJvAaz57OGkP4O1ENkWTX p33Mo2mw6fhLHr/2eIahIMQioaxzz5HvKIbGUka5UjqbwkIclLKSDsdyWh4nw9SBtQgx+Q6b Ovc6DR7TRq7i8YDpjIYQG/ov0UGUBi7vokD2V2plUJbnZH2IlV9QavWOCDEqohHvJ0P9eVid UchcYLpdtB0AAABuDkCIAQrsLSFmgPJ4duo7tsVdkQvUAf8pEWK+8LiSTJCzT8uyvfF5lPLE VEInqtFcyotgeQM5DlReLkvMo7mwFkCG3MbwMP/G/p3vxLwuwqDU1JYjqb0JsakD6xFi1Znu QJESAeXxLPAdRlaK38r9F+mgnLGnhtKRVxk/x36oDrBTVgbdDSFmXDJEnWJ8tdsJcTdtBwAA gJsCEGKAAvtNiMs0CnzHcv0gSuJTjiiIhFhdeLz9XLOqGh9ZDIf4E6vRhWpgJtGBDdAjRtkP VXmiacqZ2IGh1jFtlqXMLy5Ep4n95wTenxAbOrAmIeb9IlARPXe5g3YaLub4QfQt5hvsT4hx lzoniOB3YlyHSZUi5Rc0m5OdEGLBq0QzhFZC3FnbAQAA4GYAhBigwP4SYhwIVRfWklhaL0Js OiGmKNIoILTYwBK2QjXICH6Ej58F5y8dxSGx+oTYQIO6MlSyx7As/b28kRCvfUJs6MDahJjt 0mXkP2bIJa6yKQSobX5C3NkvdkNCfHMnxHqK3+uEGLKzAQCAOwMgxAAF9pYQixfKbYRYR+M4 d1i1D/H0lAmcwuks9LynB9WQUy5cp7OP9XltEryYxFc0v4EQqKT0IVblNEDpbJa2M1SUTCeL +l8064LmGFLN1Tif1zV8iPUdWJsQ0wwVbpD8DIcD5tFiZzYnxIo4PPr5x5nWZULpXYBlqNnC Ca7wu/YhtmySyIX9HFen6+VD3KLtAAAAcHMAQgxQYF8JsYaOGAgxdcnlV+si8u1mqdYE1Q3Z tRylgbspIa5z4rIJWVGZnI2mmOis8mg8ajJ84Z4L8WHHKo5ocemHqyIJXk27MFSUBIOnDJmu C6or7+WJvy8vqMvIP2oyx60RVKftgDxYXGe4AyEmvz1wnAH7yqTubYEQ1/mPufTD5UUweqsa Mo4KFQg078CDndflsDZ227PzLBN1+m3yRJTPn48XNDNJF0Lcqu0AAABwowBCDFBgXwkxPXby gouyQmX6ceL/8QgT4iKehmmdnpbLnEXOHdnErgPmAIzGdSki4l0/TMqKnhBzedk46L1+Bcg1 FOoka6hMph6XpooGbJFEv1VzejdelihbnC0yVFVywY7mXJkOrek5IWSkqyTJQ51umeRgLnWD oomfuaTOTY6ItscpBGfoAOWO2D0G5cvp6cSnRTbsUVQgg9hVtLImc1ieRTp/47tHlmW7wV9F fB6mRYf+Y/I6GMdXKP90Fv1EinIVFr+NEUBoPfWWLpLpy+EJLRTiRwXx67D4fM8DJuGJ6tVg sutM4vI6X4SRStqdtZSOmtMpvQS4/NAsDNpO93uNbpNXVntDAQAAwHYBhBigwN4S4rpOAT0T JYux64dJKdQqYz0r2OJ2jh/UWSPEn9SL+nU6PY2yhDq28iXZOAhR+aYQt6qqqmpFqnnxzTIF 1dj0WzXo8RuhpHz0G8rjKXHAZcqaCWH+R370l/jJ/P+aTqKsrknW/FY/KE6Urh9EfAyc8XHy +TpKNB3AqOPt8CnjrzQ4thw/CD/EedEm9svIfyR92ARK4gNdwpudUZh+79h/Wj+FbpaIVGjl OXkQChTpHFcQwd34HvmPHP80nNU/Ywu82Y4fMPk3dK+G0GhN9GdfLUVl+lHTAU4CRaO3GIJH jVrbqwoIMQAAuGlYFhBigIQdqcF+NQsAAAAAAOCBAAgxQIH9Yq6gtAAAAAAAADYBEGKAAvvF XEFpAQAAAAAAbAIgxAAF9ou5gtICAAAAAADYBECIAQrsF3MFpQUAAAAAALAJgBADFNgv5gpK CwAAAAAAYBMoCDEAAAAAAAAAAPCwIBDim2XkgLuIHanBfjULAAAAAADggQAIMUCB/WKuoLQA AAAAAAA2ARBigAL7xVxBaQEAAAAAAGwCIMQABfaLuYLSAgAAAAAA2ARAiAEK7BdzBaUFAAAA AACwCYAQAxTYL+YKSgsAAAAAAGATACEGKLBfzBWUFgAAAAAAwCYAQgxQYL+YKygtAAAAAACA TQCEGKDAfjFXUFoAAAAAAACbAAgxQIH9Yq6gtAAAAAAAADYBEGKAAvvFXEFpAQAAAAAAbAIg xAAF9ou5gtICAAAAAADYBECIAQrsF3MFpQUAAAAAALAJgBADFNgv5gpKCwAAAAAAYBMAIQYo sF/MFZQWAAAAAADAJgBCDFBgv5grKC0AAAAAAIBNAIQYoMB+MVdQWgAAAAAAAJvg7hDiIgmG tmXZflTcUg8ANfaLuW6vWVTGE8eynfGyJJ8UaTQ7H3u2PYoKtKWnPDAUkW9blj0Mkvs9s6/i 8cCyBuP46iaeVqZR+HbsHblBcht6qZwXrRJAZboIz8eefRyk12s9V56hNwM6XjdI764Z0Msf 5XE49mzLsizbm8zj/zl2bMuZxOXdHYwR66nfzaJM5+OX0zX1HHA7WJcQlxfB6O22TcNVPB5Y wDzuACQ1QEU0si0KJbnBvKfBkR9dtjV7GflHTaveNBENNP9cy1Kqh9zbMo0C3yU/cfxgFufo Mpq8YzSWbsC4h+Ll9tALLsqqqqrrNDg2PBfQAfgNuqMou+/iw+brRng/SgIXTwv7Ngixbl60 SAClAZ2TGxLieobeDJjx3n1CLMu/vAg8Zxj+QBUqk6lH7anK3u4F1lS/mwTK5yN3OFnm+yjf h4z1CPFVPB7s5CgXZdHoRCZSgBuGRg1WeRyOvUPLsiznRZSv5G+gLBzah8Pwh9IQqJttTi9s ZzRXmZBVFj6x7Sdhpnii1Owqj1441qE3+YybaprnFjN8nNCBUpADzh0R4stF+OX27fcOcZ0G w5ulLw8EeKdxK4S4qqq15wXeA3cnxKhYvF/chb0oHu/dIsRdrAfWk1rgqzx64eht6S57slXs 1ixvBJTPR+5jnpffGTUGGLEGIV5l4ZMd+jaUF9Pg872mCHsAvRowR7ZKToySwD3RrXb6Zuuj YjUnRmng6pcirtlyOXZsSTlXWfhEdd15nQYnt0eIV3n0wr3fPkIoDacxsOEd4EEQYpTPR+7z O0F67hwh7mg9+u5AdteTreLOEmL0Ixw6wpHQHVJjgBF9CTEqkzN/eOLcoiEG7B5mQnzgPXvm 2OpLt/UJsev5TxzLslT3od0JMb6WVezWUBI8nootlBeB/2eLI92uLO8qX77xbHCaB6yH+0+I Uf554h3eFdJztwhxZ+tBvGt2R4hvyY7dUUKsOHm5W2oMMKInIS6XY28yD31b5SEKuDdoIcT+ PKO+aCInXp8QD/zoO/brlTlxX0Js2Z7kv3Wdzj7ydurTNJjF7CE3CVQ65Ix7N8vLRK1YtjeZ p8zqUCYhdmh2/GmcXS3eL4p/05HWUK1YTH+u8uWUeEW7/pSODeXx7DzwXeYLjL9KmUbnTZ/G YdxIpLVlOqwyXejaqCpUpqHv2JZlO/5ZnGfctSkvkfE8VZ4TM36l1KQ0zuiU7THDLJpmG68Y NRRir7/NOP9Yh974Y0p0eJXHH8LAd+xRdJXFU9+xLJtu/wS3Rb7nf9NwMcEwsu7stuMHEasY 3UTEfX/qk03j5FMylwhxpwYZF0xW7I1fMiU3bGvWoTcOuckizgukkUCFagWzvcny25wnxNxD Gg3jvF0bZVDO0Mqo6uspT1VV1SqPz3yy83+zTD6IhLjv6yvTKMCvz7IcP4i472sMiEohh//8 +E/ZevwS5c+80EaIflRoA4WLNAp8ouquH0RpqZwvrICLTnbMKC6Ux7Pw1Hce+dEl4z0nG3Ae XdVPN9N52RbX9dds782Su/k0tCCPMQncA2ZKqtT4n//nP12FPWHs3pH/Pz51ss+9NNBkD/uo Xyd7eKntnmxn2FAiMr+Uah/eQBiKZXUnxCiLnr8MsyINjpUhU1W1yuP3jPU/i0XF6vhfVinZ RTdMy3/F0/fGPTqzAjkv5tEbl11Wp74YoVxEvk2/UKZReB74g+YLWIe273F116FXA0yIo4K4 6lqik8NGhPiyQlk0IpOfDcPq4TKBfoTDbsZLHJk8Uauq6kSImRAKqq61zqAf4fDYD5OyqiqU LyfNOqQ9zJb74z0/nX7JUUXlg3W4sSP2s2C+SIt8PnIOiPaWy7FzRFf9Ig1HTr17aW+Z9KCM J069MhF72uxVUBYO3VGYYu70ecLSlPIi8BzydPpDnWc59nLhTAp5iXhiMsP0Xp4G53G+oiux vk292MkNL7EwVDLDMEOMO5D9NJh/Touf0ci1nElcZMuJ7IaOdWMwjq8UiwF9kONQEWXh0LYY xcii0XFXEVGZ0P1nkYYvn3l/cIS4R4PkVE+iL5eR/4gqwFU8HlC3KDLZuTWJnxcaCZCgAqIz ZRKOnnonh81zy+XYOSAGhGgg02esqPWL081Qg6qvpzxVReMWcIQWKtNw9Gx4whLinq8P5fOR M6AKidW7+b7GgFxrFbJEgvXQyV86IdZEpKEsGg0cP0xL1HhFkteNAxmJQUb5fMTat1Y71rSv ElfDAg+9V38GZ8scYetx2LLsdlI/rLcuETtuluC/nfzHH7URfHUanMV5HXTI6LnOVmhGmQau TI0ENa5qVZeEhu3J8v/pZJ97aaDJHvZXvzZ72NY9EsDDDJ+onOUGqcEO7z4GtDshXmXhy+dR hsiMkjaCeMz1xpclmt3+W+87URYO6/8WkW9TyoW/Zpp4RRqOHLIXQWVy9sx9ROIJULaYns2X 5z53uYNFf+RHl/x++jhIr5n5s1MHrLuIDoS4Yo4HGE68ISGuWLPVcOIehLi+oiIQjjrMIFOx HyEWnca4RlAauKz+oB/h45edCLGuP/wKR1YC0VhcxeMBb7ixxaknXXvLmGdwFpYs5PgL12lw zBpElIWPR7i16zQ47iNDzFrYhQQbmcZEEFkxIzJLzyT2LBwesGst/3QiBCl5k+rGnFdLcRQo C4c22w5eUHGvVln45EDPLyVcp8Ex/5bx42oR9W1Q5brATt4i4kylvKgr2pfeI0oC90A6gKgt KmN+a3laxocq9LZV1XsrD/0C++7oIk1PsPpJG/0Ih0fcVjMNfYceJRoNiE4hVUOQ55FMiJW9 XWXhE5vVLrxek8FeRv4R8+Vr4USsgx0ziws3yJI58REKdFU/m7NRaeBynBIrGGMNeJVrsRUi NNRIocb0Q25Gs2trq33up4EGe7ie+rXZQ3P3FKMjC1mz4dQ8d8foSIhRGb/2iBqpLCk+42mi rFARjZq0AOb/cicfVcVvs7AGM6bt3UQ7SbAdZCTIzAeUX3zNV0JrRIMVWzfbDT4vJ88fbNqU boS4Yg506SHQ5oS4PoSwrDqHTi9CjJugl8tko91+oUlH15cQi7amntv2KCoQMcHNIXoTbrwm IebJoroRYcOpGEhry0Jwutwf/GX2IJ9GmstPJ9ZNt5B0JsTye9FohV7sIo+vz8y4BUDxuvHX WAN9nQaPmT4Lo5BsC9c/4Wq1TUSKF8r7EPdtUCYHVYXSYNCc8S/HDtPgOoRYqULs8oGPHhn3 iTUIcbuq91Ye0knF6Rf9SU9pqw8Ouf9qDYhOIbdJiFESuHIgco2reDxgpNGfELeIS6a/Hfzj OxBikWNV0ntXyJbVzzZboRimynSoP8d05Yg3IAN+7ujt8zoaaFiGeqtfiz1s6V5nQnzjjtfd CHG5nIxmWYsO6bi8+b942WDuX/L5yLGb3TzZSKmTfLHA58rcaYQ4z6UNnDIjAT4acYbj+585 VYuuhLhiD3QPveCi3AYhrljXK3sYJEVvQoxbYd0TtTndxNH1JMRSpuQG+GqCunDY3vh8wZ5V r0uI5RNo5Rek5YRbGltbVgc/sWaL+ADgkTEOkcz1pQDdCrd9QqwXO5f6mkPDddSGWEHXBs+1 67HZoItJu80iUr5Q/sN+DdL+cz0U+H0N1pmN0Yd2RqJUIU1QHcrj2SlxYDUtioLedlH1/sqj /C/7YT9pm887Ww3IzglxJ58H3Fgez4gbtHFuCmgR164IsXYX15UQt9kKUTq9CLHUmSLyB3Wz bfa573zX2sM11a8y28OW7u01IW6cMtUK0eHuUj9bmos56ukveY6TddfMiXEnBfEVkW8bLlDE mzUK4YboIUKhBgQSIWYPdC13NP94ugVCXFWNjzL1Be9PiGn36qAEs9dgtRYh1lyTsaijGSzL qh3adkiIRTZJwS4YbS3rgtP5Y2bq349fE3aWFe/BO2AHhLjSiF26RRVhMsSsZUBF9Nzl6qX1 IMTSVZUZyhfKkYaeDbItMLGMruB4g6OsDhw/iJIvoj60MhK1CkmEmISauX4QJfFp26Io6G0X VV/vesFEiNd6fT3v2Zve3AVCTCNzHD+IvsWtc1P4cYu4dkaIycFKfRSCffykO2QdIW61Fe1d 0j0Fgy2th4ro+YCJxjPb53+vMd/Vy9Ca6ldVlcEetr3xPSbERRK8mLCHu6Ip6TLbu2yOXT84 D2ex6gxPdnWXvqE9JxPu41jH5XQ+9qQbvYqq6YNOo9GLEFdiLK12dvUhxJUYwtw1y4TSqYaW 4WixbmufELdqC5ttQL9Od+mPggn1IsStJ8T1lZyeEHNiZILTGS+RPsZ6N4S4qlRib9vumgwx K/nLyH+sonpmOsh1vnOmqnZC3LNBrhs0kIVdjyviDVXX/ZKHsw1CTO4Dqb9ch0WxFyFe84S4 lRBv4/U1T2sxIDdFiPVTiZY64up39j4h1n9hd4QYd/7PV/4JuW4U8uR0OSHuzsn6nhCzohNv Vtvs83rzXWEP11Q/sT+CPWzp3r4SYlTGf/pyAizZzUsn0N6+gwyKaDQSghD70G7suCwSd2oX 0M9o9iUWPYTwkN8G83cKv7SHhJ6EuOIOdLdGiCvGR7k7IWb8INmWWow++da6PsSK3RpKP87S a56g02h97eFuh/7wOz1lI5rBsp6RrS1rVvHGZfM6nZ5KzvdHfnRJJSYFiaN0NlOKfxc+xDqx yxE89Ik4K5/ZEFOrkvwMhwOVeAUfYsX7vfoafSvkaB6TiNr3RYrwIFODTWfi8cCyjoMkCYdD aT1mU1j0J8Rq8y5fSYs+xH0IcRdVX9dlQnHfKPjVdJU255TJfFx+/RQXyGxAbsyHWLEQlxdR /C/NEVgfQtwirl2eEDexT4aOGX2IDbaivTXj58zjTsPX/BVom33urYFty1BP9SPQ2cOW7u0l IUZlcuY/F9wuZU3VbMsW78KkaPuvUuFW+fLNcBT9m3cbNR47yc5D2SIYneA9yq+yrE0YabBI wvdfi7+oh/F1Wf4mPyzjIIhL9svo7/R7z23Y/qM/Ia6YA93tEeKK8VHunodYVc4epYG7E5eJ ejnh0w+XF8HoLb5dHbC2hvFrXzfLxI9weFjbL3UjxM2Jn3dF5DdVtTu0TNKESXSEmLnrNBiy 8mQih+h5PJdstUiCV1O1YsgrIm5ho6A6s9j5rHyoTM5GU5ZZmj1kDhxHVldNTI/6QTT7FRfu qRcRXni4BUZ5Vtq5QUZQrmXZjuMoLhkkf7N+hBjHzAlrLfMdSdRrEOIOqr7G9QJWP95cKBIj dJa20UR0+u9OCbFxONKD+hPiFnHt1If4wNRICyFusxXqYXbLMkH/h+eIxJFa7XM/DTTYw/XU jx+ybA9buifpDJXDHSXEJEhfzqhH8+c1wqUjoek2qzKNptOQMBLzf+tFl+Y6RXk8feFPPuck F13t6VIkwdDWJiYk8wdH1KE8noWLJD51LdsNPsfhh6REzRk+ypfTt4sm48S3n1H4n//53137 SfjzvxbT90mJGs1OvtNPHhb0zBVnJ9VkBCTq0Z8Q43Skmq088VHuVZiDy7ZGEux3yOxNT/Wk DE3GpJhy9nWrjiIl4b00wWcevXBqJzZs051JXF7nizBStF/7FLl8Csm6M2z6RpXQuCzCAy7K uKXlqjlIIGk4scfwgKaVIFkm6M8zLlUkl/ITw9a934Y5kTTJ+XJ6Oqnd3exRVFyTYTaKRw2L 5r2YxK6oJtC0TCMFtTqs2ifgf+B1hWVRpgetJ6LaUbtM3r0a1olUR1GBejZYN6wilPWKhd9I mc4nz9xHmFflOBO8Yl4oJEA2NvRFFMn05fCE1nfw3y+DY5qgBpXpx4n/xyOszEU8DVOagnow jq9Q/uks+omUM7RF1Vd9laeq6tzYTQrb6asn5N4dy6rv69ObiBYDolNI2Xoo5F//XErrLgzf MBxCTfApQ5HO3/guzvf3VxGfh+l1Bztmbp8kHWekR/PUtjlJtqifLrRLSA3OehWT9143YpzC 6l7J99iyGrO/UTK/Dva5jwYa7eFa6le3rLOH5u6RHT5WqlW+fBdMnjnka0d+dNn63B3BsiRC zAeJ17s0ob4R+y+hws17vuKG+b9NNSDLOvTG72glp+s0PI/Lq3SOE0BLRZ4E1Hfr9FCK14B6 1jVbPWrx3yzzFclQUX+5quRPHhQsBXOVFEDJUMuLwBv2IMR0eyopFfelMpl64g21ullyN0Qr WlET5gdq93RDT46D9IofsunEggnd4zzVUPpuEn2vpwDvxEb9TOrtotQqOSd4FnyckMqAzURo Ex2XZEOsjGVsuQFbpUn4wnU6PY2yhBbfkiqZsXW5pBp3EkjSezpDf6XBseX4QfghzjM+1vvI j/6SPhHvFoxirySzg3veTcOry8h/JIpaSKzR/JB1sBbTjHDJAdtFhMr0I3kXtjeeJ1k0somI Vms1SH5TRCNbMVLhjeA9CTaJv+R58dsggTnVMG8yT79H/iPHPyXhInWgDz5JIlaaCTwlAbuu HyalYoaqyt1xqn65hvIQkCATKoFs7tuuH5w3hqT366vdN9mVrn51sgExKyRnPRQa+FsQF35T XxOdTWMmLJ83pomdxYeINMy9tlqtdkwvLoGz2qPo51z8RJ3wixuCRv1YRz5BEv84P/8H9xx/ /pPPt0DPL5W2QjdG9Zk0p8bSb5RhOZ3sc2cNbLOHa6hfDYU97NA9SanSwLXw/PqvpNNzdwLL 6lW6GfAwsIkaoPz7d80uYoNmV3n6Q3fWdX+VVulJdsdbBgAAgLuAVR6dBlK+V5R/nnjuboLm pRIn7biMfE9KSgv2+XYAhBigwI7UYL+avQMAQgwAAABrAJXxxFXbNz4geMuPFQq/tYFLP9y0 Avb5VgCEGKDAfjHX+6u0QIgBAACgPwwRdehnNPvWoXDpuk/O5yPnj041h1EWjQb6Wjxgn28a QIgBCuwXc72/StseXHL3WgYAAIBbBzZxQtgSKtOFptzBNoHy+cgZqDyGq6qJVMO+tVNV1D7Y 59sBEGKAAvvFXO+l0koFkLcWb7u7lgEAAODOgK06juPSTndPhinKdD5+qU6CRmLs2GxuzH/B Pt8egBADFNgv5gpKCwAAAAAAYBMAIQYosF/MFZQWAAAAAADAJgBCDFBgv5grKC0AAAAAAIBN AIQYoMB+MVdQWgAAAAAAAJtg14S4rq70cKu+7SP2i7kCIb6PQGW6CM/Hns3WEsNFdztUJN4z 6MfFFGGzvck8/p9jxzYUj31AwNVfQRQdQYt3rpvJ6zqdvhzP0x3MO+VMB9xt3M7sK9Jodj72 VJU1dei3ZOyUEK/y6IWDyzkWkQ/qvj/YL+aqaXaVxx/Ox02Rdtsbn5tjjMs0Ck9plU78gw9x vkLZ7Pm0ThXJlmCti0JfRpN3KaqYGvQSupSPvhdAeTwT5f7BVO9U2UgTai0T4kMvuNg9IUZl ugjr6tON/qyycKIMHt/oWcpxlReBh5P8ozKZei2pmm4JbI1ukuXquohOty0i+bnLsWPvRhRC wecaN5umYItgql6vn9q2TEJ/4Izm2x2/ZqYD7jZ2OPt0YEpJ9ybEXZeMDoS4vAi8Q8t5EfVb 0lAZTxz7SZitqgqXLL/j2UOKJBjaljuKIPHf/hPiMgl9l6+fXpBK7niHJqJIw5EjVlynP7Fs mjt9lUcvHOvQm3zGX2rO77gpirNI1r9iKsX3nkf7BSzGQ28cUgZc7x9cXVZOPTAvuY1lEusP NxCW+W1syoov4aJ1UHhzVT9rlUcvGou6LXTqiRY4gZTtvVliKTXz4Y5b+w7AZ2Cs/OMzbA22 RAovF+GXGyy7sI1aDyiLRtvnxLc509cHKhbvF1y5O/mTG8dm03kPUES+3YsQ69pRC2pnhBj9 CIdr387cCNCP8PlbRqxAiBvsNyHGK5mSOpB/DYOEVUz86jXrXHkR1PeMeFssavUqC5/wlzh4 7bG5EkToRzg83OiE5q4DbwMOVWVLyb96nuze0jKJLZ7aFOCT2s26hLJodNKhBTz8XTLLrj3R 4SoeDyx7JFTByUmemQAAIABJREFURVk4vOvHH12gkD8tqbC5Tq7y6IWmsPCOsKXiZ31LE3fC /hFilM9H7nNW8+VPbrxPG07nfcBWCLFeUDtymcDH1HdZv4skeDxQ1nUE7DUhJrxTScsqqpkW 4/wkfyL9Jgsfj6KC3u4pVhSUBI+nLYS48aa4B1xBxioLn9iG0krkvG3QqaIpwa0sk+R0X+9z tsrC0WjtLqF8OfHsLoMi19w705buPdG2kASuLRPiqrpOg+f7r+TKDQn1pthoSV7lyzeefcN7 421VA8Z3v/JL3wR7RohR/nniHbKaL39y833adDrvBTYnxEZB7YQQk0Ist6gcZhCJ3Etesh3s LyEmHmkG3SM8gzJm8qetrnpPQFyEaePeZCkcJV+ns49thLj2llNNRSbk5ar2r7Bcfyo8CZXp onbQZR08FK542HZYVjM6lMez88B3mafodg4Yqzwaj5ovoDJ+PVQKiojRYI6JBxhmzCiPZ+Gp 7zzyo8vmml0UrLRMSoFB3drhQtMs2zPEBlExGo1DsZg0PuVC25M5dchh+pbR23YJ2LIL42I8 Phv3VT8q6pgSUb1r3x7Lslw/iJjw5VUeh2Pv0BIUhpyCSz3pI6t6KtUeRIwYP844AbLdYAp0 qRTS+8cTRxx4xXkQ2qOo+Hd/UfQZWlVpCDHthj2KrjLTbCrTSDlRyX0Ui/oRRRq9Y6QUSp73 bACD7fhBxHl/aY0D/m8bIb5OA5/Zr66y8NVEuX1FSeAeGA2mDI0eEigJsWk4islFrgSJ8xsx nldmFwKzPJVKy3nzk+Gc/Mf/xn3COsupjUMHKTVP5ONSjvzokjERthskqP907mY5dcI0GCKN AjMzvWiepzAdKpkQ42l7b5bJB4kQG9VeMK0GQVVVZSTEjAEiM1Z2aq77Sg9+mjWYeXnqftfK 0UQw0PWAEtble9oa7kCRzieebTW34eSb8nEOo+jOi3n0xiU6KmmzGyRJzSRkViS8YGLHGfJB bBl1EuV7QjwRLcsZhelVGZ+He0LBrX0lxFRFTTtI7ozHRFJlULcHXdXN+ntGQiyRLTbkxXt+ Ov2SI3ytI2gUPpuhNqv2c639EMgpLDMW0mHcE2aiPQvmi7TI5yPnwBB+i7Jw6DYH54Y7wQ48 kjkgb+b1offqz+BsmSNqqjhHF36ZlAODGmtjbAdl0eiYWF4qNM02gKE73TbzKJ+P3OFkmaMK lWnYLMxN346eBR8W6WUevXCswTj+/9LgmH9HmoAn8YRYYIT1JiWLRgOaw0c4p8e3H8T3g55T 1JK5FnvST1ZV/TirZbFf5dELl/gZU2f9YZghrUIW+LxNecfiTOLyV39R9B1a1UKI3df/xz/0 s6lcjp0jutjX8QlNBJLqrukqHg+oN3atS6xzFxOkXjtvNG+zzTh0OSEuIt9lfCPL5dh9qvJZ v4z8o/6BTTo9rFSE2Dgc7eT6OwufulQB8uUbo3eTWZ46pcW9k+5GVLclWuOg74/uibTaM0O1 08Dl3Lr6TOdOlnOlEabGEJkUmJnp3svT4DzOV3Rn2HIik4VPbNIIKtNw9Gx4whFio56oTatK UBSWZT4hxgsqq/rN7rBIppPXy/x3Gri85ULSJ4S51hsUadFCaeCSrQ/mAfXiehn5R5Y9ioqr JDybpX83gyn/Cqef8t+yIhZpOHLIs1CZnD1zH3HnwSgJXMETFFtP3l0s/zzxDqmhJ0yauRG+ ToNjyw1ShMrk3fj1Z9KTRlaXkX9Efa9xl+7qkbmEfSXEdAIYrwVZ0lOvrF2vC8jVGIF0BEW/ pSLE+C5e51SgWq4ESlQux84RZz4I3607L68reLCCGTX5hzQQHldeBN6R5lioE4/k9x74J6w1 lO2UYpmUpNTazioLnxywMseLgbKrtQHtuNiL/pRC94jw+S2H0hx3ePvqzq+y8InNvk28JJD+ 18YTqR4t96SPrEgn8ZEEWXSkM7aqwlTjQMt+NAqpnEHXaXDSfNJPFP2HpiTEZM9J9E3T+at4 POCnOV5fxGnIvG4+Br2WG7P2oywc2qzHEeZM3Y1DF5eJ6zQ4Znq+ysInB4pMAlhzul+xmvWw Ut0FtQ5HNbnEo2uTd5NZnmal7USIW4yDqj+GJ9ZneUTZiiR4+pijkn2nc5vlNAtTnD4dFBjr PNMfrQtixX6BfUf0VKW2z+uo/QaEWKa2lLlm2ezPaVIwnwhrMEtAMceVB1a3XMdT/50Ez59H P6+iEXmRhLx+SBZhlK2YxvOvs0/1F5gFDJse5lniF+QOq76DN2ScpePtI2XVV9mHybTZjjRy F9pEyXSy2JdoKiDEJqA8njbZuFR3r3QS1pO/TOfkTkp3QqA0lyydFXIOKH/VlRB38CO8iscD Zkaow6f4p6xBiGWyy1qb7oRY3458vWvw7uhJiFEauMIumvPYUVrerRJixd6ehfAS2whxL1k1 WPEOIcLlSX1wIEiADNbkl+/yFhglwYC5oOglinWGhtWvZgx1Tn3m3E7Z+SLybemyke+t9EPl mSur/9dpcKyfX12MQzcf4iLybYZllsux4hIJN9XdXdWsh5VM/joMR3kginWGOeTWZl0wy7NF absQ4jbj0POJVVVvq5zxlzx+7Ykvpe907mI59cIUCXGrAqsmS4tDsKpN7ifrqf36hFjeCGI1 8sP5WUAYp6xYwnawfovs+1Mt5O5pvDyb8JHdKA1c69B7NZ7MGI9P9818/vFr473ArPdZOLTl XaMtikO42hB4P9lkCAFA8ts98sP3QRCXTSMyF9nLtBVAiFvBumZZYoYKZTZinKJVd1+mXK7Y D9U5B4iRZU8Et0CI8ZzlDlllDxAGd5gQi05czT5GMZx+hFifc5rzMdshIe68valQHs9Izrh6 4FJPeslKfgAzH5h1VJfTl/NZUg1B7B5Kg4G8mnYUxTpDU/WczyaueqjaXUp4m+IP1cyAmbza +EW2q2bj0DGoTjg4xHNfuNfWjLEDVHpYSTO9y3CU86j24Tn0xu/kywqmrS7y1CptB0Lcahx6 PpE8haYqUlwz9p3OrRbYKEyBELcq8BqEWPlf7sP11H5tQqxQmsvIP7Ieud6kZpwSiy8in42f JY0IB2P8Oo05q+e/ouSy7kERjWz7j+H4A3n9uPHGX42n7FhdBC0Xa4LI2w6F5XVlneMsGtki O96bOlmBYrNC1Hf/OLG1p4S4jw+x7UfFxpkfmgTD3JqxxoLRRoh1OQc4w7QlQqw0dkYR9fAh 1p6e7oQQK9y3TOiVQ6D14vguEGIaTeH4QfQt5pRBaffWYTnM05rLE5u54jPI0zQEbim5jHyP O6HoI4q1htae9k71UHHG8a2pT8v4JbxpXpz+OgLXyTh0zTIhHGSqzjXXSFhh0ENRON2Go6M1 dRyYZRnq43aRp8EItBPinl4lrU+sv0heh3zT2Hc6d7HAemGqZp9JgfsTYnWb7E/WVPu1CbFA bSUp0E9MDsTqUam2yyq/RsEkSTfRPLvV79cZkSnus5QeTpqIKO1RnCbOQBEqtAfYW0LcPcuE kIqh02KJ0ncTxSwizsGsp/9WCTFzRKSb/Ds5IRZOiYzD6Z5lQnvjucMT4s4rd68NUuvF8Q0R Yv06SuvIkMgqQRnUR0o9WI7aDYzmMRSDQNRdNCokY/+LyB+olsaOoug7NOHpGvQnxOoTYiOf ME5/8sUuxuEWT4jNelj1I8SmE2IKpnqierwtOQ1blLbzCXF3r5K2J5Kn/AgfPwvOXzqKQ+K+ 07mLBa6qSiPMHoR4zRPiTQnxtk+IFW9U2nPIx6LCxki9zGOLSd+ovn+ivPC0YTwZOHaragfH QIhMRbHGiO5cYn/4ogPyfo7ryWU0etX4EmXh8KZTTm6K/SXEfF4FBaTdFz1UNsWZrbLo49cS iZe2Qpu7IsTs/bvSN5FRvO36EDcyMfsQV839mo6REONVT96b9CFWBXejdDZT9ZSm4TMk36jQ z2j2rdRdJVV10rEb8iFWGM/yIor/JdnPNkK8hqxYp151z+XYHdqZ2Uejy0RFVwrbDb79DJ+K aeN7iaLv0KpqXUKsIwfGsxv10i5Pf1lQV1+jb0Un43B7PsQtelhJM73LcNQ+xOwOzZj+tYs8 tUrb2YfYYByU/dE/saqqqkiCF5P4qqkkZY7WbdH5dstpEqZ69hkUeF2XCcWFv7Ap6qv2axLi ZsuC8u/fS3pJoXYXLvK8bOQiRrBxUpCyrmj3RpJrr9B4PS3/Lr9/z5G0fKJsEYxOMBn9VZb1 ERr2XSODYuY2+jv9XiijNfPoBbsnk9yFmZ7kf5coCdwTIanFFooN3iD2mBA3CiaUo6uqSnNg Tzm0piTpKl+8C+v4UVWz2NN9+y4TuNxjrXUkMZB0d2lKpCUVke7sdVqVF4HndMsygZvGsbPK cnRyhp2bIsSNfzMb+1gkwauphujQamQaTyeULabvSdx97bPOJh0rL4LRW/0h1nazTJhGJ73r NkLcV1YoCdwjxevGLnB85BkfbIfK5Gw01ZwbSU1Z9iPHkZh3H1GsoQZrE2JqT/hXXES+3ei/ 9EOaJI5r6jLyj7qKsd04dM4y0aSV2E6WiTY9rOSZvpatwzs0Nk+cKXKui1rq/tsty4TZOPTr j5gSXhHm1Hc6dzhKMAhTmeOlgwL3CapTlT4VTqbXUfv1CHHd1+KvcPopp7si2WTb/ockjki0 kOyQQPx6m0xyvmNbNPlf/SB9UEUz66TzacKk58nyfZzTMHyybUJ5PAsXSXzqWrYbfI7DD0mJ miGU38Lwr7JuBCe4CN8t8lUtZWoXsBsN60AjTzPyCekJ3mST7+NsKeZke3cOe02Iq6quG8Tl wycZ+1ndq0EzRtve+LwJmkFlujifjF/TXOXUZrHZ1kiIPX8SQHLva8u2KVBf1rt+mJRVRTMV stydbsy4XI8DhrfRuxesuihfTk8nfp1lexQV1y3nuEKfOuchpj/ASbjYlOx1RnA6LvJNuglp DjmktHRCCZWqas51mu90aEdOxm4+AK7NlHXojd8yMVRFGr2bjINlExmpyNLfrFLqywrGTKFs cbZgbsn4nEQqXq7wIDSMjizS2PYW6fyN7x5Zlu0GfxXxeZj+UvSkl6zq03Qm2xrxquf0Vi5F UV/ItF0sqBfa/qJo/a8M8v0OaZilztM9OZsedcDtt/Hy6kzi8jrHCZTq/SSbvZiN8TeJsepg HBQ6JmK9PMQ0VIab4Jw4zHp4rZrpbcNRTi6SGIGmFm7Js26Wp/m/zWU1yj+dRT+R4hOjcejX H1QmU49LylaHZNQHNCrDYjIObZbTKEzF7GtRYDpZ5BqxBodSkuWQqlZ5MX315ITICDPaNdRe aYEJLEtHiHFX2L2FguziYLg3dIVQZsFgck6JhKOWrJKtC165cuOYEDO1Veocxo4fRCm902S4 rGLqkl0InyqoybAjLYpyx6jQaU9Q+n4a/6tpgXZmj2DtOSGuqqqqijQKg5oOWrbjn4amF7HK 4w/nTKC8ZXvj8wUbk0F8iGnxG2qz2MBzRXBxN28ZupF9FnwkiV2VWV3ZUkbKL9RhEFilf6XB seX4Qfghzr7x9c+6HGB3rlTHDKRMF2HApKVz/CDkxCiGP9uj6Odc+GS+/KfLfGC5QfpbqN/G FvjQtkNv9JhMeVKZLM048njGvGWsDir9YQIrm7aZ2j20t2IaSmqXxLp0x0HyVapUZ7vB14Rk RJFeH+vkx3WyZvbkmIqQ7HpPKPSkHnhHWZFLVVq2ir4qVTYVNjUb3S+JA9coZBH5tqY6Rg9R 9BqaHPIvrVBtneeybiiWALKQc/tz7jfKHOdMHT7JOpmMg6xj6lv7tSrVEdYi3W4zPzDooThT mAyquuFoJxdKppMoq2tytc/0VnlKSlsPiVTKaLiE/EmlMQ56qJ8oFQITVpna97rzdO5ggaN/ /6URpn72aRVYmFBHfvSX9InG/aZhj4fe+GOazX3b9QOWRfZXe6WgqqradulmOZceYC+xmRrc k2ZvFmsEbgMAAMBNA6WBq+C+XOQMALCP2CohRkng/qG/EQDsDfaLuQIhBgAAgJuAWICNfFom 70itAABgb7EpIUZZOCT3WaiMJ24Pp0nA3cV+MVcgxAAAALB7FEnw2BWCj8s0CsNZBy8kAOCO Y0NCjAP6RlFxncdnvvcy0hbiAuwT9ou53gtCLIWCAQAAwN1Bmc7HQ5ENAwD3CBu7TNBQXD4o DbDf2C/muu+E2BSABQAAALeP63T6ksneBQDcQ2w3qA5wT7BfzBWUFgAAAAAAwCYAQgxQYL+Y KygtAAAAAACATQCEGKDAfjFXUFoAAAAAAACbAAgxQIH9Yq6gtAAAAAAAADYBEGKAAvvFXEFp AQAAAAAAbILdE2KmSKAux2oTZa+t/SgAFw+0nX1PAdOUFtSXLrwN7BdzVTZLlcpQO/4eAydx 293YadZkb5psJ7cMKtNFeD72xCK9+469Gxcq44lj2c54CfkENMB1aA+94OLmRETKxR91KLeu BC2v3XWF3TraLQbK41l46juPtroUbmUCojKZera18yq8uAi2M4khYdct4WZOiPFk0JSqJ7iK x4OuVQlQErj2fcnYisp44sh2qlyOnYN2xl9eBKO3+lm6yuMPYUBLmVuH3vhdlBYV+jGbfjaI ev8J8WXkn4zmX+Yj977oSS9cxeOBZQ+DZEdVPi4j/8hyXmwr7ziTeG5fiGMn7OG4MCG+Wba3 Xygi377Zs5jm3MS8huqAz496HTltHW0Wozk42+bZ0PYm4CqPXji7nsXlcuzY2ztlAPTGzRBi PCGNylREvs3OdrwnU9sdlAaD+6M0l5F/pNh64gTPLfbLsItAZfpx7B1ajh+EC5oimn7YZlj3 nBCjMv5zhIuLoiwanfAWFhWL94vbWRXuC1ASDB5vm23jg7cNl5zLRfjljpX628q4AHcFW1p9 +ipql0MlIzDjvC1CrLMYxZdwURtnzBO2flm6rQlYJMHjwdryB+wDboYQazhfAzzbWZU1EOLr NJzen5J44k6gAUqDgenIfJWFTzTFfoskGNqW7fihXC2FqbatxX4TYvQzmn1rzrdQFr2e1bqH 8vnIfX5LxyT3BCh9P92+M8bm69Yqj164d672NRDi+4TrNDzf+EZ7DUXdb0KsthjiacUdJ8Ti UgK4f7gRQlxEvq11IK6qisyEW7vNuU2gNHAVJmCVx2e++zTMdLwflcmZPzxxFCaSEmWdqwBK gkELI9xvQqwHyj9P2s/dAbeCDdetVb5847XYmVsBEGIAi/UUdb8JsQIoX048m1v77jwhBtx3 3AAhxjPZqOXYJ/jOrWQ3APVOAKXToX8WG07By+XYm8xDXxIsdgG0LPuJlkyjZDpZmEV968x1 s2ZRmUaBj53HbIdIkgZGNLDdIPndRHJkeXzmO3YjOpTH4Zj8xPYMZUuRoZFqlcfh2DukPty0 wjnK49l54Lu2HxXNgw69yWfmSgSVaeg7Nh1Fxl2zartXx5EIuqHpCfnXhzDwHXsUFdf112zv zZJXQv6Zk3ladP+vSm7LKX5NtjdZfpvTdYvx/KNDaFwMlZwAX4mwOP5n+JotiE3NCwnusSzL sv/xP5b/SQVFX5xlWY4/jbl7qW2Na60G19IBRruu6s5woIJt/FMt248KErx1KFnjIo0CIh/L 9YOIu3rqOlNYzVQL3DiVijR6xyhwyFhIJmjsKounOGqinvsMyjQ6Z7oa8m+6TEIsK8efxtkV 51tlmD7KsSplolBULVFDOR3IoTf5lMwlQtzZQFWVkhCzI1IIg8Eqjz/Q0LRfjXW1vckyR7zC C91Qqzp2CGThBilqCHHzK/oIdiR6NagfusUJWFVlGnFxOIonMl+WVeiX5MPNWKGmY3zgIzMx mR9WnG2cf5Om+eEQ+wr2GGPHuYPKdKGcOl3MtXFe3yFYlo4QC4aS0VDmIn5FxsbFRQoOEpTz XWX1+xEWWu6UlNUD0cuCeyWyhz7K41mtuNxEKtJw5FiWZbl+mJRlPA3lew8h8qChBZYzCkVl qpcH2xnNotPaQxpvRqnQqnofrLF66+0EUBY9fxlmhWI/jX6Ew3YX4VZYe0yIUZlMPRe/MnIY 0+gn1q56VWAiOZ4FHxbpZR69cHByBpRFo2NCT4mNa2wNB0Mj+G6UaDtRQnsYZojRE+/laXAe 5yu6WDIWLQuHZCDkbLtRFX33FOapqmhQiOuHSVkJC9J/O/mPP+hU916dBmdxjuj+gblnQGUy 9Q7wtKIsjTFqKJ+P3KHuvzJQFg5tGrxVJuHoqXdy2CwPOOCaHUKbbuOBs7MJ5fOR0EhVkdXI mSzjf1JBHXqjN1OytOOfNAk6tjyung2upQOMdj0L5ou0yOcj58AZ/98png6iObqM/EfOeFkK Np/pRDQaULMvXUB1nimMZmoEbppKV/F4QBeOWm44bJQ13Sej03fLfEUV3uLWpnI5do7onpPO x9ohGP0Ih8dkgmC73dDHIgmGB4qJrFUCg0xkRVW18CMcHtK+FWn48pn3B0eIuxsoDJEQ46MT dxRlzVtQ6yHL3lx/cjpdNvbBsp8GH98GZ8sc1Val1i6zxZDPg/Enh96rP7kGORJvUINa9tuc gMTsEC0iSqV9d1oVqg+qmrGgLBw2k1EV+EjIg0SEisi3B+P4/9VM82XZY4wd5w4O/aeciupb E3prNtemeX23YFnGE2JCVcP5dPznPC14v9VVvngbzD+F/hGnsoKDBDayztMxWfWprJt3LDsQ Y10RVr4iCYY23YBiZWL0skjDkVNvW/BDySNw+3jmY+XQJ3YhDPX8y3QyYR7EDbBMQt+lW64i CZ65zgGrsg2/R1k0wkuAhhDrHYj1WGXhy+dRhlShimTJ2fhebI8Jcbkcc++XZOgjQhYIMfMF Ps/UKgufHLALXsuFo7KRCmXh8IA1Q5ipEKtB1kXmKfxKeZ0Gx5xeZeHjEf5Xa/e4B1WVMCPq ZzEdJpJheivICiWBywqW5lEiG78f4dBh1mP+vzJQErgHnLiI0az1WRqC8CrlJlU8QxwmaXlA m5WfQicRltXWx9WvwfV1gIxCTOGkuj5GSeCe1CRG6s8qC5/YHK1MQt+lveo7U9oErp5KeD3m VnRimWvhKJ4rKMxVPB7wLBYvZ/QQKw1cVjLoR/j4ZSNMrmXFKBh0ejXtPoTyMVMzlr5i15iI 5s82dwWyWWI1h6Sfk5SZNbZ6i6EnxEyDwnc6qMGWJ6D0shQriPBltQopXpAsUvk7+BOeEKM0 cOkn6mne12q1zp1yOXaOuO0W4bvdzbV6ibxrMBNioo6u/7YJqq1l9+/s69ccqRfaRi7yqi/p gRxyJ1O9IgmGNnMkzDPmVRY+sdltInfyKrR2nU5PdVYDL5+PXH/a7Dj5N83tF5ufsPkxKL// OwmeP49+XkWjA/VZgmIn0AZUxq89olLy2kZ3exunS9xbQoyKaMTn2qTHG4Tf6AixcNCeBO4B fzuJlVa3YCiXE5HN1C8Ia6ZiXeTMH/4yOcKpqqqJTG/vnmieeM4hP0spGVbBVLtWZvclrgQt ezOl5gv6vB1CTCassMYc6HcOFWegtj6ung2urwM61iXvEPjgXWntNN9i9Z4pLQLXTCVlWDbf lIoRcmqvPH1gfkUk04Rx1+lodCuUhmGs+2r4XgldlblmL7HL8rmKxwPxIrcfIZZ/wipPi8XQ E2K5wVoUrWqw9QmI5cZw9HZCrFShdQkxkQl7mHqdBo9FfqU4Beg7RsPcUUpVMBQdCfHdqrcg w0iI5UMjaWWV6CBOgNrcyyhEKeiBPPlFko2vGxidKC8Cr75Own1gVTaLRi7rUCGpqQ7yDlXo LT5R4I76pag4PGlP4+XZJDInwG1NviGhXE5GM3pTqWMwW4gr2ltCzFwACWAds1oJMVNNRmhF w8b0q7gSbpCiVkJc36lZtjc+j1LpzMPQPc0JseHsoYUQ6wVrHQfpL+ZSVf6vvN9ThrnshhCL ayoqoudM7iTlUV/94d/bHhfq2eD6OqBlXeKL5tZXmRC3sLfeM8Us8EvTfBRNJa8PyiPS5sPf 6qA01ryTQy8s60XjIix4c7JQWu+1Xw33CoyEuLfYTUfIjKuh/ue9CbHZYih3Pm2EuF0Ntj8B WQmmUUhDU3Q+kBoVUsq/EyFWHVEzMfEqXeo/xpa587cyKpGngg+BEOMM5PzVlerWg/HOEe4v lJxPcX+kuEFjNOBHODy03CBFdZkJNqahvvr5TSM2ZH9wcjXWxolx8nD+9oE9QhD9NKhAJC23 Pf9VELdcDfR1IK4nm84iU8P9gAmxcA8ooRshlrZ5rdAdM9uGDU8rIa6agCrLshpf9g7dk82T kMcQ+yszW7sWQmwWbIdE49zI5cW12hkhFuo/XUb+Y+naV8fPfm57XD0FVVVr64CedfFRzkXk u6zF60eI+8+UdQix4n5D7mrLov5Lozx8f+qIKMuyaof79ixJ/WTSRoiVes5Rw/5iV8qHBh87 fhB9i42Tqz8hbjPF/QlxuxrsZAJWVVWk84lnH3rjd1HyRfUIBkoVqtYnxLztRUX03OWvdyRd 6j9G89z591/qIXO/uv+EuMO1prjkY71hJpXClAjbXznNgpiVggvFGL8NQ27jxfzXdvzTMPyg iQAVI5ZUXzFfVHW6y9O47imgSbim7VwSvJiwTuiK7TKcELfZgj4nxH3EqNcN/ZLQgRCTT5sA f9xae/eUtGOVR3++8k8wtxKDyjudEOsE2yGTDPf1myXEzNth3e80T2F78mvb4+opqAa9dcDE uho1E87LKx0h1u7res8Us8DVLhNGJtThhLjJYKAjxHwK/CZHDQ4FadnZ9pXJ5oS4v9hl+eBg njouqmVyrXtCbKBl2yXEthskaBcTEAf21YH16keIwhJVqNqEELNCEPbzhhPiPmM0z53fmiFz q9X9J8SKjGCC/xm/T11l0cc4PmWdVxScT3DpU9gagUbo/MHRr/IXavEWR0X0aiSEPbYQFNUh H2a3CsZJ7/0lAAAgAElEQVSAfTlYI9L9rffaxqEy/tPni6ma7kr0dBxlH6eLdo3cW0JMbId0 FUB9uXr4EKvCclE6U+dl1/sQK/Zg1+nsYweXCd7ZnQRoMiu0qXuqE+LG+1yFTj7Eish6lH6c 0URpuv9KD2tlRcrvrE2Ia8G+Dk9P+J/re8K6tWxvXD0bXF8HjKzrKh4PLOs4SJJwODS6BtbL tmTTyoso/lf/mdIicNN8VHsxsq53ykXdTKfYd/1uImZlYQ479RNZxEavplK8guZDITi4u9gl +Yh7760T4haLsY7LRLsa7GACCl0yEmK9Cm1CiOkdlxskP8PhQAqwU/sQdx9j69zR6AZ3gHjv CbF8oc977vKUDpXJh/BrTjn071/lL6Sg1JIPbi3T8tss+snvfVd5+qPUML8ymXoDjSNmVVcj +5UGJxJb1XFQubc4rwWN1ZOUBuWfAv/Yto786O9f5a9GLToleagN8dXX2SejrzEqkzP/ucTw 1C5x2K2CyYfCiSWatDpyVFW1x4S4zv/Cuc2gfP58vKChSB0Ice0Ax6XVLJLg1dSgPNJsp9cX rIcPKpOz0VTjSigG1Q3ZNZjZsLV2T+lDfKBd7dSS4RlqI9ggqrMQlhfB6G0TrWjxCS/r/0oP w0mIeJMt9FkWKaZxaxFi8lvNdaRwHpmFwzqMZuvj6tfg+jrQwdXBsh3HUbtcsz80P6jvTGkT uHoqKatyXkb+USNqVZ7dLHxiN2nFsW2U74KafIUDKfgbczuSM4tLwNxMZAkbvZqqonON47tK Z8XuYm/NdLF1QtxmMdYJqmtVg61PQE0whpYQ61RIZWCJfDoQYiKZA8cZKJcYKZK41xjb544i 1xZxFjUk0RPM9Z4TYiJoQn9RmX4ce4d8/uCa/F3ny3fTRVZnnEh+Ls6YP8k7KNP52LO59MD1 2X6Wf73IUcVMgL+K5P10gZUcG7LaHadI56/9Ec2FXFNAkl1ylcdnI//PZb6iPsH0sgMTekP9 NpfJaKjoLZ4bNL9s/CEkflfHQfwlDP+i3mbdXLso77/KL74asnyT3OySGtGEbopdIC7GJpqh NDp/M379uS2skGCPCXGzejFo5m3zElH+6Sz6iXTZbeXU8YaUMdoUuXIe/vr8nhh3Mddj01uS YYBmtcShovTL5u4Rg8icaemicGqfVBK8xYauYntdNyJXNmG/b/6vDGIuaXbbIpm+HJ7QGgEM CyEmCOXL6emkds5T7jnxGJ1JXF7nizDiD880LIQGPjp8rl8h+/J2x9WjwbV1gGqX7qJfyQ6b J/KGxaxsvWZKq8B1U4lYvEMuizCbip5oeC15nIOcO9al2XbZdKqD+jaJ3H/WP+dSpRomsgpm mRgVFfeUmAIiJVQm714N62Tho6hAPcVe5xmotwfselek8ze+i9O6/VXE56HE9qh9YIPXyZti Hkq2nQ09NVoMcps3XpYoW5wtst+tDXZQgy1PQP6cu0znk2fuI8xi/05mi+/iEaxBhXDHyFkV yr9Mg0kdG8DmHVImDFZR0ko/zXtarfa5Q0+7uQzQAyb7TZu5/vd/baVCwq5hWWpCTKiq4xzQ ye8HM6GODd2u1bsQMsdqEonKdBEylTLEuEvqcsAc5tVi5QqrNIVnLNvxT2diHammFBMXi43S cBqXmNpalqLAEosi8m37kfOIapHrB+9jsfAHziFfc01+ueLOb9pAAn3Emljc4xr3aEvaaXF2 UOZhTC0fC/tei2/PCGuPCXFV79+owjAbg+Ylun6YFJyELSk/a10pyjLUcULmRuriNeRF4CpH QgKKIz/6S/rkZzo9jbKEFkmSKiRpuif2h+aLJfm/Zdj/OD//B2s8bX/+k49Trsu8Mb5xCpEI M1Ff+AoDhxzgL0/m6ffIf+T4p2GjqXU9HXzE/isNji3HD7RxAnU+ebmSTsWnH2Y/PLKso2fB +YQojMJKbHtc3Ru8XkcHxKwIykUIFdHIFtZR8YeMJjPFusR8F7puqGESeMtUYktvya+JnHI9 DT6+Jt9x/CASi7dxbfBfQOm7SfS99tWWxsHW6msrV9YiE7Oikt83Rsz2xvMki0a2oPxdxS4s GVgfmmBNvNoSyqXokpS1wD1dzoU8BsfB8j2/5aZXxwaLQdit7fhhms25n9uj6Kf0CS1XYVID /Ka2NgGrpjoGeda/eMLNf9esQnW8HT7XxymTSceU74jFZeQ/UiXa0/6kxxg7zR22rqG4qhKx a8z18j//u3GJvEOwLDUh7n71fz+wdrDL/YS134QYIGOVR6eBdEKA8s8Tz30Qai+mU8AwV1gA bB07E3hrZQoAAKAEzB0KDSFer6TwHkMRQfiQsV/MFQhxG1AZT1xdLTR9nZp7BDmdAgYQ4hsG EGIA4I4B5g6FmhD3zAi2/3hwG4AW7BdzBULcAkNEHfoZzb7d5VqaWwHK5yPnRHVPB4T4hgGE GAC4Y4C5Q6EixGKV6nsPrqI9oNo35gqEuA04nkNwi0dlugh7uZbvGWjECXZrU+VdkQIHATvG rgQuBKQCAICOgLnTQEGIOfQqLLyHaIuIeqDYL+YKhLgDVnn8PmhKKCmCU+8daOgSl5qqhhSc et9t3W1jZwLvFEQIAAAkwNzhoQuqAzxo7BdzBaUFAAAAAACwCYAQAxTYL+YKSgsAAAAAAGAT ACEGKLBfzBWUFgAAAAAAwCYAQgxQYL+YKygtAAAAAACATQCEGKDAfjFXUFoAAAAAAACboBch RkX08vEN5ydqoiAhV+jNYb+YK9dsmUbh27F3eCeySpMC3XKBtO4o0mh2PvbEKrv7C6byqlCh /SY7gavR2t40Wf/V3DugPJ6dB767y7mDczzZznh577Nf7wyoTBfh+diz18yJpKnuDmitnwy4 5+hDiMvl2HvdY2kvL4LR223MNFTGEweyRt8g9pUQM0lkuEW9vAi8Q20y2t2hXI4dewPWxRjo +7FolReB5wzDH6hCZTL17NtKfnkZ+UeW8yLKH3reTQa4ZIY0d7YMTIhvfCZWdDK2DA2VaUSz E3ZMTbjGT6qqWuXxhzA89R1NxRzD8xo6uxEh5kQhpt9iaaE3Pl+krAXDdRxMkKlkkUYhk/bx 0Bu/ncU5Qj/C5wJJaPRQZcnTKPAd/A/HDxSyXuVxOPYOrfo7kZxycZXHZ75j4y9MFe8Lb5iB ED84dCfEqywcjXqc0V7F48GWDOtl5B/tjBAUSTC0LXcUZaD6NfaVEFdVc/jHmVFcDqDvEnK5 CL/wCoyKxfvFDW/M8PJzHwgxfjX1K1jl0QvnVggxSoLB4yC5/SuE29EoPRRU6WZQfAkXO70A xLVpWoaGsnAoUr2WpWGNn1TVdRo8809febaSO3YBZo3bI8QYxE42zaJ8OcUsVto9onw+cmzF zW2ZhP6AGRQq09B3bMv2xmHNPZldBG/ZTJUBSMkwji07oznDZ7FJ8SZL/NkqX77xbKEKTJEE Q9seBklRkW25/L6AED9QdCbEReQPui/JpEbUmoZV2DUaCs9uAUpCvMrCyfQBV+i4b4SY/CcJ XGX9XiVWefTC5RtB+XzkPr/pm4r7Q4g3WsW3CJS+n8ZXt9sHjNvRKD1uhxCjLBqd7NIjDpXx 6xPnUduSdBn5rjf+iE9DGy5oupxc4yc18P3PXSLEymYpDZW+r6/CXSwmUzwoehGkvo3B3JSV 1WXke2P13ERFNDqonaxQHk/xUTHTAQVVuE6DY+Z1kAsKhiLjLwjbciDEDxQdCfF1GvgaNZWB yuTMH544a+pTkQSPB8wPURq4N+pAjMpk6vVg//cQ95EQozI58ycdPRfx0QLXCMo/T7zDWyj4 fm8IMbmWvX1CfEdwaxqlxy0QYpQvJ569UwtfLsfeZB76ZkKM0ulQ8Gxu09g1fsJgTwhx7bgl KqqeENcgR84DLXlAP8LHL+tmURoMhqH6dB0lwVDw2BQFiNLAFeUpEGLFAPGveKd2IMQPFJ0I McrCx481aiqjsT79bRwxjqy+oiIa2Te3ZmAm9NBnwr0jxKt88TYIRWcxJr7LYm708KUBi/91 fP7G4z5irDDTCB8lRuPhau1lg5aanx16k898xxoXN9t7s0w+MIR4lccfwsB37FF0leEzEpsu IfqedESRRgFxrbNcP4g4x8GqSKN31Dnv0BuHcXPkw/SquK59+GzvzRJ/R+WhyLwgfcuMxK7I 8dvhMPzxO49n4duxd+QGCWrcCqkkm9Ojw/r0Tn7jrIjQug0KLTY1olveNT05U2mUAI2WMv7l RMGI5luW1UaVtC+6oUp6/dT0p+IUniqnZdmOf9a8UCHmlTj3M3CD9Lf6pZNL8MZDVHoXSqAs Gj0Zx//SXhzR76l8V8y8c42fsOhHiJnjZ2+y/DYXn9JDMmsSYnFP3kqIdT/k+lJEp/QylnoP O34QfoiFE2WFU41EW7GdYY970Y9weNSQXXy4INAJxYdAiB8oLKudEF/F46ddj4dRFj1/GWZF GhwLU4XOZ3azyPoUSisEmUWsA3FNFKQdZ5lG5/KyxKwQRN0bvvu78VWiei9a5+Mg/haF54E/ YLePKA1cw5b3XkClBvvSrN5lQkC5HDsHxAUNZdGIXXf1cSe8MUX5fOQOJ8scNa5y2BzLfIUJ WvJengbncb6i5Ju9wltl4ZPGxS0NR8+GJ4QQs/r8NJh/Touf0cjFWSz0PekGlEWjgeOHaYka l6fmtOYqHg8owa3bJ51keuW9Og3O4ryOmbPZ8x714ZmhZUZiz4L5Ii3y+cg5cJ49+w/6PMef BNMvOaon79GzIJxysq1XNVQmU+/AU4ioCRLq1SAW2jHhi2USNtSt27tWaVQfLcX3v9xaTl1a 9YTM+KKJ2ot9Ziy5tj+swp+MTt8t8xXx6bQskmhFHfN6zS8Wmpc+XpbYi4moSpGGI8fiFUyB VRY+dcfLsrtZ4HAZ+Udtj1j7Jz0IMcrCoU0jEcskHD31Tg4t3h2/u2T6EWJyyiv3U0WIUTqb pZx6d5a55D3s+mFivNDDh2WslaP6RtyIiyR47BJVrxpLJRB0hV0CQvxA0U6IURY+HnU0Iqss fPk8yqhxZH3zP02Dj0vx2Pgy8o+49QAlgWtLLAR7BRXJdPJ6mf8Wr0WI4zzdE6tXHduPinq2 ND/H6wE7E5gbFvZYi11ybivu5AbxAAgx/lqjjcJr7USI0Y9w6DBcVnq0dPZAmmXWKtVz5U0j Y8SJWvJbstaetGCVhU9sNj0cpnfkoTjNC0evCfESesWdzcjiUiw8rS2TZVJMXSeTCTpklgew 3iYoCdxHjPERRNS/wWqVhU8O5P/SIbe+6w6EuEVLFYdbLVf25hfd2uf+/REFK2vmteL0RPXS URYOD1hVab+yZ+421yLEReTbPc8+evykMyFGSeAecHf6ZAtH3nJfyXQmxPVNgnyLpXwK5+5I CW5PWknvEMgG1ZSe7zLyH0lfqFf5w5Phi8mcTTFB9mziwMmUOZKMAxDiB4dWQnwZ+Y+7OSqh Mn7tEe0U5tUq/3qRI5Ely/RXdhemn2TZ7M9pUkjfwdpvK4xFvVQXkW/bbvBXkZz5z+f5VeTX tgPPBHa/KDNyKfC2qiqUTh/f66nyEAhxGU8cds/WnxCjNHAV7mgMIdARYrZZTl1VCVUEfVYe VLf2xAxZ7Tko07zwy6GiV9Jpk4KrtbesWbwVZEIrW3sUFb/5BBeyiPo2iBQRPPzK2vauOxFi s5b2JsQtL7q1z/37U8uZttCdEPP9vE6DY15VNPymaeVH+NinNHENQnydBic98yX3+klHQoxk 1eUnV2/JtBFiFoJzlPnLHP1dkxAT1LzW4MAduOoU7+z9DPXa+v/bO3vXuJW2/+vfUJ3WnbtU qtS4uZs0LrbYJkWKAykEWwRSBPzAwkIgcHgMgsVwwGAECyFgFsQ+hANhQRwC5iAE4SYEIQjm /IwQN2a5GfQrZkaaV2m0Wtur7PWpkl1Jnp3Xr2aul7IEQQy00iyIWY3bRrGeTRZpw0Qvqk88 t7K9ULB/L+mZiBcsP0zI7hd3DdlMEkYFNynT2ST67M9C0YRUssFXOfDJ8/V9Mj/fHz+Yh+AA BDF7RxYtzolJpbBV1iSIWZNNATqJdxXESv+5dhVlUJLmCmg+9FB79fHL+XaC2ODJOxLE/+FD 7stV1F0Qa6Ox6kveWRAzqHppV0HcerrVXuau5RE/3FoQK+WXxf11jk0aeC+3PzMpURqM3W4p dTreYiiIlXa97Idda8Zwh5i4UuhNL+QdYlRE78e7EcQlPb/V3I6+B+NT1U58Hvsv3em6ICZM luVMAuIqAIIYaMGyGgQx94bdiCJAoDK+IGt+h29p3i4iQ50Zk+w1uH8LUQaFDQksoE+9swtp npInYuW7uHgZSj+9Xzxuur5HxzoQQUzcp1zPD+PonOk2JoJYOvGQ6SiI+a6ruEBVDLOSNNKs k9SlEup5K0Fs8uQdCeKfonWWSGdBrHJpV9TbDgSxvpc+jSDuVB7xw20FsXya14jkCN5REBc3 /ths7dv+FjNBrG5QZnB1rJnS3GSCrNG6LCptNsTkjbGHrNQeaOSx/5sqaW4e++PaIoj46Fdb ZhobYt7+BP9hEMSHSYMgNt8ezmP/7Yx9V1NsKghrNiqS6+noiLuG2DZIR5CsiSF7jXqmUG1c qX3gJAtm9QEuPzbQ98X7T798Do9DEMQ4sHyVRk4QZ8Y7xI2hVB5JEBuUpLkq1MK0+VthXOxc ED/EDnHDO8OWO8S9xKWBIG7updsJ4gbx1FrmzuURn9Bvh9g03NC9/kCgaeuU/vk0fPOmW96W LW7ZlSDuVjNlaS6IqzPYhgW0adqhW9fbh4y8Db1jqZybLJx6So2uGJKcV6jRBFuWIIgPFr0g RrF/YhIxHhXR70LvbH2/R+nnRfQnb4Gn2J2V9mD4a5STLzb5pRq6aUdEHjyyIq//KP58ky78 xRNkmn1sDkAQS1N/Z0Gs8ECin18v+phMNOkJtYpqL0kzikPDsizLsrgJo380SzI/GLczmTB4 8k5tiBuqaDsbYlUoD7pJtgtB3NJLt7Mh1jZ0e5m7l6cU5tV+NsTSeWBZ3ieLawO9ZbxDTMK0 dXGk2+KWsuxoMiE0mWRD3KVmukSZoJFMFNa6Bk6NxGqiycsQpZ8Xf+miFMe++y/+3k0WvtPs 02mamNtE+x6MxcjfqqMeEMQHik4Qozx8c9LeG1CBPdUato7wR2yfK/4Ogq95Za37n6Koplq8 T5Z9+1YdcMhHw66foPxb8hMp3NjFsET6nTPmK/Qz+VZFj8KHUPgTtvCW7S3T+ON89cvvDpfl IQhijbrtJIjruEJs0N/ixp/8odMHbYIDJ5jl1zbhIQ0G+g0laaGKvc9E0i3z2D+bJ/eaxJN8 eKktneran7wjQYyq6FGO54eKKur+wJZK24UgbuuliieonICletu2zK3lUQhiHEbwld65zVAQ V+qKDbKLivhiMjdRLYbTQhpOXoqJfIs4mC2042iLWwimTnVYkvLvcgrHU/Oa6RiHmGa9pscC yjJoIANck6muRNnnefC35hRaPqPeZOG70UTQG3kSnAfsBoRiA5g5moZMdYAejSAu1tPR+xbn ABKsXhoPRJWyA7hWnyj7Mp9/riNOxEl48TmjU63thXnxNSAjRDJgINd8iqMwyjZ0sDHRGT2X D17YcJZUjfyfcXC5ymjgWHsS5v/8FXxiRz6Nzemd+VEXj+MBM2RBTD0nWkKBkm2VkX9TlKhI rmfev57jpT2P5kGC8NzqzKLiPlsFYbqhfeZkGt2h7PNF+AMp0itw2yE0jkE121bLQ7XdUoWS pdcQQUO7cXEzP3t1Sv7EsRfeagLNNpeEuKc4dUhOCTlFAhu8hb5q0uhLeRJMHGaRUxytkh/C hHYm1/Bp0lueTGtMDB1K08nWrdxat41VtM0DmyvN4HZFj+rYS+kbFJ4DUfZl7s9oxg2N+OtV ZrNRU/c0EhNT1B+K1cF2pusCpauLVYo0ja7ImKPcuVSiEsRkv3BMTB3oyiXBRE5Ig7HNSMMt bqnBbdccWYy/ktRqHs/fjU+PmFbuVjNaQUzHrGg0XPUZx/ND8h6FjWf0FsYVJC6yZY+mV5+4 FC1XH6bvq2hut6F3bDnenKR5yZPle2/CzldV3AmJup9QSVAn0/5zNjrma/gump5QTzv8TFd8 n1EIYl5sAL8olqUQxIJ/rgI+hnbVb2TLLWoIiNfCeluCTqxVdEOyIDFyVhPViA+kkifLWZ2P 44pPb9MUY4guJPUrtV40YOOKbuHZh401UEEsZkRr9DOr3JBxtxR7YJVToHJSrtYALmJ8nUHK YvN2CWPBdv3/W3LO4Mde+HcofnJblmVZJEuSZOZoNL1O0qVnu55/tYj+HQvjS/BbVZekrPZ4 2vKsVhnaLHs0vQoTburnEpSx6c3EGBe2t/whfPL6f87ETHWsf63myWJr0lvE8A4v/PVH/hPb 9Vd8beN7cRI6qYq2f2DJJLFjn3grtay6rZU9qksvlS+IffeZ450HCzEvY1tDm5W5uTxkh/g3 //o9aVBGQmmHJ5GVtuMFSf63utEJdRLHxohgMq2CuBojMqJNLVW3W9zCFUbuD3rqlc4ezZbJ t9B7zrdyh5rRHn/pi0TfZnW0bKaiLFpUmbNICS9DLpUmfnciT3O8c77/0hez9j/NZuzju5+2 MmWBAIL4QLEsg9TNh04eeh3j7wydB+oGw3rsLwfKw7PJto53ANCO0oYY2DMOIbdUP8Bk4kAB QdxKTm0qDohhKVfotEYUN/PZrx8gBXhKQBAPARDEbYAgPlBAEDezofajh8WwlCt02jbyJFw0 naEDwE4AQTwEQBC3AYL4QAFBrAJ9D8bHrv81XV0G3UJL/iIMS7lCpwWAPUD2GgT2ERDEbYAg PlBAEKso1lPH1pjbHwTDUq7QaQHgidF5QAL7B+8T3ydxxi+G7AkNffiwAEEMKBiWcoVOCwAA AABAH0AQAwqGpVyh0wIAAAAA0AcQxICCYSlX6LQAAAAAAPQBBDGgYFjKFTotAAAAAAB9AEEM KBiWcoVOCwAAAABAHx5BEKMiuZ6OjixlVmRgLxmWcgVBDAAAAABAH1oFsZDg3jLIus6yycK3 jjMJkrzMQ8/udC/wZAxLuYIgBgAAAACgD2Y7xMV66tiWdTTyb4oOD0dFNHOqIO156Nkv/OS+ T3EfmDz2x7blTsJDT3A7LOUKghgAAAAAgD6YCWKckLNr+G70PRgf7Xc6nE0azOa1RgdBTBiW cgVBDAAAAABAH4wEMUp8t3PWFpzGc59tJFARz0cnkKRHwbCUKwhiAAAAAAD6YCKIcT7DbtYO KFtOHNuyJ2G+n3pzk60/jGzIzahmWMoVBDEAAAAAAH0wEMQ4ST2Rtkyyb2JBscmiC8+xLetk Gt2VJbWvUDvhoSJZXU1H+Ht7NFsm2J6idt0jJhYoW89GtvXCT37Qr7B4rWJWHI2D76gsqbS1 LGcWcSEsUJGEvudalmU5b5fhh3qTu7jxR0dMCV/8b/Ce5naXJXKehJdTcv3RaHpNAmXgamFv QVk09xxLLsnwGJZyBUEMAAAAAEAfDARxHnq2xZkCo9h3n7l+jMo8ns/er7P/SjYVCisLrHHt 0XSZFCVVpZXLHbnl2AtvS5SGEyxQ8bY0ysOJbR174c8i/ugv4jzxXSKd8zi4XGV54r/glXee BBOH/C1UxBev3ec2t8l9n/gv+A3sTRq84q8pUfbnbHREhTsq4vnItuxxUJkYo8R38S3FzXzq r0lJ9tx3sJ1hKVcQxAAAAAAA9KFVEGMxKovdYy9M08Xv8zgvWS1LkKwsiMalu8iKJ+P/vvCT n7H/5k344y6cPCPSk4jXZby6CH+gWm3/nf91HaYb6c9hacv8LbybyzoFoth3bUnlc9cQqw9u uxfvZFd/iKrqu38vZpdxgVQ6e5AMS7mCIAYAAAAAoA+GcYjlvVUvWF74RHHKKvA29I6ZT7BC tZ3pmonahhVwtfd8G3rHlnserS9mQpAHLF5Hb6ezT7U+tl6cL68Xf91VF1RaFqXB2Ob/liR/ JQUvbWmj78H4iFfwVW3QG8ljL5f+HxFjR7HfgTWMGJZyBUEMAAAAAEAf2gSxIuDabegdW8/d 0axSnFjLMtcIVhbECrm2jijLkuraygAXq17vzI/EUMd56NlHp+PpgtyO1TY1vRC0LBaywh6t mBOk2o3mVT4jkRG2ymCsI+ofUt2Yh55tP3fGs0o056H3SzjqDUu5giAGAAAAAKAPLYIY1da6 FCyRWcUpqUBhtxU/RAxjzItLco3CHU2y2SAFqOQ1p24VBVbIX0nBi1vavFjna4PeKOxwK//Q UBmWcgVBDAAAAABAH5oFsbhvWiq85XS7rdUnsnAsaZTiagtW8Ycogs0G0ceMRQSrblXPwWn2 xA1sXuyKjoO8aQThLpqeMNEt5Gh0ss4eKsNSrls9FremYBID7Aqo3kFAJ+fRPB54YByJPAkX V9OR/ageHahIVsHVdGTvcwD+LRjOcCb7ZWM/7m632H4v7VT7u8pXPbDLxhzWSN2iY3UeX2Q/ cb97UaMgxtXE/eAGc+E8y4qyVHmnSbu2NEpxtcsrbNAyiE+TZGilZYvvSZaKQhalK39yii/4 T1HUO7sv/OS+RD+TbzkTxeKWfiIL600WvnVYIwrZXLguyc9s4KvLPinXLR7LRNyzLMvx/EWU odtwdsnMYnfR9GTLeRNoZ2+ql8RY7Jp2/kC4Db1jy3kbZpv2a4cEEx70EQUxXfKlYKPxfLS1 StsL9mY4t4CX8u1yzbbeK8ec3TuYHthZEHd5K9aMr6bJ9jb0TifLL8uJK1qi7hN6QUwiAVsm wRls71MchRGeVeX9V2LXi4cTKpLAc2zLmQQJfYwc2a26VfR1E/Qx1bLLr9HHKEPc/jHKokWw iqNz17Jd/88o+MQHgvjnL/JJtQn9Mw4uV9mmJJ551cZJngQTx7IdL0hoj9G45VUl2ao19oYh CwSi2IYAABGvSURBVGL86nI0mv2JWwFlUTCVevIjkH8JVsIu0e0q+PKkS8qTF+DRwW/1XVeI BhTNOlhQ7J+8fFSV85i1J1v3PQby6SI5Dn0AIXV4w7mF+8Qfb/vqa3avwquqJyhffVztsovK gRC2onWoyuNLO9miIvp9go/WURpOTvnzk53XwPYoBXGdJqOCqFWF2MXOcB/WmcKit6ZIlnU+ junVgpOMsrisvhGfJhYAX1CrnzqGseP5YVJQSc1oWRryov6E2ELUSTfKsqwzgFiWdTSa/iEU Wf6ZKPFdtiRDZsCCGL/sii9XmzR49ajnXIphv8nCt+5TRiB58gI8HSj23dMdCGJFsw4YlHyc P+bx5SPX3r4IYgJKfHeXU9ABD2cdKAnmklP+bu/dtSBG2XLivtlpF92FIDYZqrrxJU+26Ee4 +MpE/UrD9wsuvu2Oa2B7DBJzdOM+8V/s7YECYMhwBbHKqxJ/Efsv54/ULcnpCm9ys/4w0hyD PApPXoAnBBXxhTdb9zWZUDQrYMzj195+CeI89t/Odvb6ccjD+UnZqSDGmb923UV7C2LDoaoe X90m24epge3ZtSBGse/+a5+NpgEThi6ILXs0Wws79ffJ4rqytDH1fSmS0PecyhY5TLhxXltj WJaQgpHFPbv63zGXzryarZRP0MNfTjOf88nSbS/MRXO3PPY1BSg3WRQoMpOXmyz6FPieY0/C /L66hjkLKmvzJ8t2vIsoS+kBrq56hczt04A5dUFZtAjOPee5F97WP1PRjhUmJSzLcpOt/vAD yYqpqeaxiZRlWa43X2d3X4LVrapZ5UWR/eEpzWlvWY43Z/8++6eto9E0iNgCF3FAEs578yi9 0x0mFkkY/DEdHdleeJet58Ri3vXmtL5QFi2ufM9lLqgcgjUdqb0A2/YWfe01laQdtjxij9Is 2HkSXjI/ga185lfcpdHccyqnEcNGKUu1IEbpaj5v64MHPpwZJy1a+bQkG+mZdHBVbkgtE2me hD4ZjJbr+WHCGsu23LupBrI9+rCOP0mCeLs6p5blTFPXgbk6DgpUzQD2aLb+uhQFcVNLie5x RhMdvk8eX5rJlvPqqdpUWQNfU90YbG+pHWBZvQUxSoMxcWlERTRz99hiGjBki26wL48lGVUs yQaGuUTt+yJdli0nzokXxEX92FpSlCgNJy+IhQxZL4UIJLKJuZACveEJmvK449k6Q9XSVa8H 1FKomrxQ7LvPnMmymptUe+ebLHzrkgmaqEB7HKTEFp/MO2fn/kWUISl1OUqDsUs8AUiScy/M G1yLoplTrYj09xKjvVoEHI3Ofvcv1hlSZHdnK8OkhFqaan6TBr+5xJ4K78NVv6IhGE5dw+RX TD5gaUociGvf6rtoekL92GRX3e/B+AXtcjjXvd7VmPz6N+fzLxmq+gD2oKjN3uzX/nKV5Nly 4jxzpusC19KzkaYjNRSgV29RD4qGLt0Ots0lXlCSo7Zywb6Lpie1IiF/kTi3ML/iN3/5Z5L/ CCeu5cyi/N9GjULQmkyIpYfhXMM6aZ1Ozi/XzOgg0Q/qZx6/9j+tktssfOvgYVXc+CNHO5Gi NJycUAtJbDDJdMvme/H1jPvT5PX4lBPE/QYFSdHAdaeugwKlwdimNV/EweS30ekRG5irqaXU 7nEtEx3B9AQGFfF8RLoWOdmoI1pwNaAfgwXqulxuR39BjPJwYpN3oAtv9O6Xc1g+RAYsiKtT GPp6K+4HENrWLfQ9GB8z0f3w3PSMvsRv0uDVM1Z4cbODiSBufoKyPA4z/qVohuTNHgsvVMTz 8UtOFyqCvaTB +Bk71SoSMXJzMTd5icZRKA1eTvSBC4v11Dnm5i/yjsEnQufmuLZ5uaWEOhpr HsW++4zxUtikwWRiJojVP7zk45erkxaRAqPEd7mM99+Dl+80v0UVztIkuDuKffe5lKXIYtSP ugD9eouq9lq7dAvK4PHM88UBhZUBpy2w8zSvO20hMlSXRpGqRQcMZxnFBCgkBCD/5VPe3if+ C32qhE0avLLZIYC1FBOntSHNAkp8l+sMVLGxaXH7DAp5vuo6KPCbElsh5M2BNkR7S8k1v1NB XKynDjvhKDKy8TWgGIOdl8tt2cEOcR1rQ7MhBwyOQQvisixLlNFDN93xSsu6pXf0xF8Lsqka xvgWA0Hc8gRleWQnTm5GIKu7M4uyL9PReyGopLSCyub+ZLeAXKMQl6x1Gr6YjVLE+rwL1av0 tRXmernSpKQ8YqU0l1BDc83jf7ORyGpv6y0FMadTi/XUeSaGzeEWYJvZCGzwv1aulNxiY5al iOtI+gL07C2K2jPp0o3cRdMTKSJngyBWxolXKhh+x65Do0gP1ADDWYFK4vDJsFQDUOPozw5n rZpsvlfZYTgb4t6DQrqg46BQNgT7J0xa6kEFcbVhirhPqjbVCWLhsR2Xy63ZhSAGfjkGL4jL six5W01uSSvb1i2zzQwFeHo1EMQtTxB/Sn2WJMJOduRAUHnEJq2gimAydFddM1XxszlZsHHc mLD5fUOtU9tWu4cRxC01T+vQOhpNL0POem9bQaz+cJNFH6ldXbVAUoMfezS9WjXuL6gTHknb vUrFrO9I2gL07S1S7Rl2aSNQFi2Irb+c05QWSe0O1bZf1a1RSjNBDMNZhVJgmZ28qbBdP/6v zsfa4F6k7DDch70HhXhB10GhbAj2Q5OWelBBrJ9w6hM5A0HcbbncHssCQQxIPFA3eJLH1g4H 3PldL0Es5Wtsv11YwNqeoHyggVAg780K4yrVFrWtdZgoTSRO5YVjWZbFRRZXbrzJ5W9Z7R5E EBvUfOVUZ1lcfMZdCWLs4vPM8fww/iLWTOW/ZVmW5RLTVdXv2EoQ61MgVSgLsIPeItSecZdu gjrrOJ4ffo2443Xl8bcsiPlq1JncmDZKaSaIYTir2EYQM0m1lD+6SRAb3dskiPvXudqsyHhQ qBuC+RNGLfWggrhtwjETxB2Xy+0BQQwoGK4gRsnlTDGMcahpdnYzEcQtc7fe2NF0h9jYXLJl 7qZs0sB76V+cqfww1FtKnaYqtdxkPLiF42nDFfQpdojba54JMKI/BZZpEMR4iUrDiVsn/VLX DOuUrftzDYK4wWTCcMWVC9C/tyh3iPuceNIUPJx70HaCuHGHWFsnSsx3iGE4l4rblYJYbzLR LJU0jd7jXnmHuE+dq3eIjQdFT0H8eDvE+gmnyw7xIwQZBEEMKBiyIPZPtCkPzQWxznILFX99 juqDHukoEyWLRWJkMtHyBHV55PgJKLleVBs8JAAkDWfDe1OpjQ4Vm080Pl2r0eH8nJnFsF+8 cKgqbAdKaw9nw/eYNsT6mkfxfLaSksxrT2wl9ILY9RMk/SLRDY59naMxKJr2t5pMhPU2xNqO pC9Az95SamyIm7t0I+KJdosg1r17cEaW6t0p80YpzQQxDGcVWkHc8MzqLu1wVluaFjdh9E/L vaYCvcegUNsQmw+Kttdvo5Z6eBti0V6xLCtD/A42xB2Wy60BQQwoGLQgdqvtNwacR9DYZKJa PvkwkMWNP/mDmQoFd7089s/m9TTUHGWi+Qldy1OibPlmsqDTKE3HyHgfK9zSiQkd6w6Livhi MtftlglT7ZhdCXg3RLF6iYWi7F1Rz3GPJYibax7F/slvzLRbZXrfXhDjuEjj4LviTUmKC3HC roVNLkHKKBPfg/FRHUhLeV5M0qvajueHUkdqKEC/3lIqaq+tSzejGVANyzwNuSXZkLSEwerQ KKWhIIbhrEAV1zYNXjU+s6xP/7g48cJUrJtmm+8lKWw5vas8dth6UGhjLBgOCpIVnBfQXGMZ tNQjRJnAEw4bUnr5ZrpSGympT2k6Lpfbsq0gNp62gCEybEGM7fzqaGsksrotrWqNgQzlsOEW FwtGDmBer1j0tXi6LlC6uliliE4fziwq7rNVEKabxid0LE9x448cxcRdHyirClDKEf7rjSjq ZMP+ZDy1sdqusjFN64CR6uqlW2tcFNiT2quduC6xNUCWK11c4bYS6mmoeRJlogrIWoXv1TSr CPWzcfiQroJIHc3jApVFspy9dp9jQZxF849xzOaZ39SRVlW/nvrfuHyI3Gqdoy5ZkpFAQ0fi E90LBejTW5S119ilSX/QG+yShRO//ebJ8oPnHluW7fp/59FVkNzTQx426BXe+Dwi0UyxsTgT UYT+CtnN37BRTCaW9lY4zOFMfyNT1esPI5uNKEyeKUrq5om017e4imi1FDfzs1enpIqxXuw5 KPB0cTKN7lD2+SL8gVrXHRFcq1Wl5fH83fiUpqrxwry1papFsx4pJhOdfJcOotr5Oq7uEmvg v6ox2NpSuKrJvNoDy9pGEN9F0xNIGvkLY9YN9vGx5HyT5vGiM5TnLyIhpn2N1iuCtRqUYw6U XHA3MVMTzZJQu2RVceYZb5WGJygLVDsIMpfTTYV6qVAku9IUgMnDxCTuEp2dbW/5Q/zk43p+ HqYxNbStk37pq5dN6cTvUApOxPYk/LEUP+FtVwxK2DhB6WoexfNZmFbt3t6sAmR75rV/RYNh C5GwK489vKt0Tzb/vCApEEouZ+G3yoizsUfQHeLX/vUML6BMldZdwuI6Br2X6dj8r28pwNa9 BbusKWpP3aXLSjo0bEHVTmB4O43GKZsEyU/et521UWFDz7BNI7nDV7FmjRvFeGKh18NwZiE7 jr/51+9JAzEbt1JECF4wsSlF5RZi/QHkGBpt9y5JfzkaTa+TdOnZrudfMetJr0FBE/dwL37a QaEmT5Z0ChjNlsm30HvueOdBXUR9S4ndvjKmb57oNHdpQUVyrSkAWwN/RZoxWF2qWy6fUBAr D56AXwqDbvDrPxYAumOaqKw3XdNYDJTbcHK229j7wJ7yMKkWAMCcroIYFfGFNz51HiUEBvBU DEu5giAG9gYQxDsEFfHlbLHj7KzAngKCGHhqOgriYj0dzZaB1y9cDrDvDEu5giAG9gYQxDui SMKAOfUFfnlAEANPTRdBjNLwzbsgzfUeiGzuJc6psOO3lQF4yRiKYXOWf6L5R2pWUlnjuV4Q F0U0D8DNbzcMS7mCIAb2BUOvvh3Q5qIEAEOCul61O2kBwENhLog3afDuTZhSd1TZBzAOSMag pCilQHcG31ZG0ly47Dz0bBrEDl9GdkTwBgnOvY5F83PYtN4Vw1KuIIiBPUDrlbVzWhyMAGBY tPiAAsAjYSiIURG9H5EIF6pIn3hfpI5fwwe6a/4Wx85k3APZCIhCLhkmRrqgy/m44kA/hqVc QRADAAAAANAHM0FcrGdVkHBtrGldqLzmb3Hc+/qUhAT+rPKakLCgdajIChIeUsyAAuyAYSlX EMQAAAAAAPTBQBCTaNg8zGmgOh9SafQtk6I6T8LF1XRkW643X7Mal0aXlDUxzd8DmnjXDEu5 giAGAAAAAKAPrYI4j/23M3ZzV51BXudVbfItkdief6VxKia5W1TuIzhPzCO4sBwWw1KuIIgB AAAAAOhDsyBGRfS7V+WKxB8JO77EHF4jeZu/bQ5RlIeTSbWvjDeD8ZUoD88m1S14AxtiteyU YSlXEMQAAAAAAPShQRCjIr7w3gjWCCTJNeMEqhS1m2x1GcR527fK/eNNFr51vfD/Jb4rGmbg v3uf+KdMATRRL4AeDEu5giAGAAAAAKAPGkFMckZLe7ckwzVrvUDDB1YZ1YsknM+DODf4ltoH 26MZNhtGWTR/683+zBCJqkYTfOexP6aBKW5D75h54I0/OoJgnLtlWMoVBDEAAAAAAH1QCGI+ yGW1GSxF2ay/ypPQ9xybmgJ/5DNuNH+7yaIL+u3RaHoZYplb3ifBVVTcJcvZyLYsy3Y8n3yF kmAeFUWynI5s8swwKUAO75JhKVcQxAAAAAAA9MEwDjFwWAxLuUKnBQAAAACgDyCIAQXDUq7Q aQEAAAAA6AMIYkDBsJQrdFoAAAAAAPoAghhQMCzlCp0WAAAAAIA+gCAGFAxLuUKnBQAAAACg DyCIAQXDUq7QaQEAAAAA6INCEAMAAAAAAADAYSEI4sdV5MA+8kDdYFiPBQAAAADgQLAs6/8D UEup1kb5NEQAAAAASUVORK5CYII= --B_3440656001_28865896-- From prvs=072273e934=rybar@nbusr.sk Thu Jan 10 03:13: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 C958C21F88F7 for ; Thu, 10 Jan 2013 03:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 vXLJfptVdbHL for ; Thu, 10 Jan 2013 03:13:07 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63821F8910 for ; Thu, 10 Jan 2013 03:13:05 -0800 (PST) Message-Id: <201301101113.r0ABD19C061661@mail.nbusr.sk> From: "Peter Rybar" To: "'Piyush Jain'" , "'Stefan Santesson'" , "'pkix'" Date: Thu, 10 Jan 2013 12:13:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CDEF2B.DAC9E8B0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <058601cdee8d$2e18d070$8a4a7150$@ditenity.com> Thread-Index: AQJTurzfUuo/qkb+vJxdixlo2qoa3Jc1nVmQgAEy4XA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.6 X-NAI-Spam-Version: 2.2.0.9309 : core <4456> : streams <888242> : uri <1315486> Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 10 Jan 2013 11:13:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CDEF2B.DAC9E8B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stefan, For me is unclear how this extension of revoked with reason code = certificateHold is useful. It define that now is possible to revoke what does not exist and it open = never ending cycle of trying to fixing or correcting the first incorrect = status that "fake" cert serial number is revoked but cert serial number = is not revoked because "fake" cert does not exist. =20 I agree that extension of revoked can be helpful like: The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. =20 =20 When the certificate serial number is not in the OCSP database/CRL then = according to rfc2560bis there are defined following possible responses: 1. signed - good (e.g. certificate serial number is not listed in CRL) 2. signed - unknown (e.g. certificate serial number is not listed in = CRL) 3. unsigned =E2=80=93 unauthorized as an error message 4. signed - revoked where according to rfc2560bis are defined values = for: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC =20 What is missing? The rfc2560bis must also specify values for: This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC =20 X.509 defines the reason code certificateHold as 1) it may remain on the = CRL; 2) it may be replaced by a (final) revocation; 3) it may be = explicitly released; and=20 4) as a consequence of rfc2560bis the status of certificate serial = number indicated as revoked with reason code certificateHold can be = replaced with real status of a new real certificate which was issued = with the same certificate serial number as was asked in the incorrect = OCSP request created by insufficiently implemented applications where = the signature of the certificate was not checked with CA public key. =20 It is based on the following definitions: =20 According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/=20 =20 - good =E2=80=A6 is not revoked, (does not necessarily mean that the = certificate was ever issued)=E2=80=A6 - revoked =E2=80=A6 has been revoked (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.) - unknown =E2=80=A6 =20 When a responder responds revoked to a status request for a non- issued certificate, the responder MUST also; =20 - 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.=20 =20 =20 According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code = extension: http://www.itu.int/rec/T-REC-X.509=20 A certificate may be placed on hold by issuing a CRL entry with a reason = code of certificateHold. The certificate hold notice may include an = optional hold instruction code to convey additional information to = certificate users (see 8.5.2.3).=20 Once a hold has been issued, it may be handled in one of three ways:=20 a) it may remain on the CRL with no further action, causing users to = reject transactions issued during the hold period; or,=20 b) it may be replaced by a (final) revocation for the same certificate, = in which case the reason shall be one of the standard reasons for = revocation, the revocation date shall be the date the certificate was = placed on hold, and the optional instruction code extension field shall = not appear; or,=20 c) it may be explicitly released and the entry removed from the CRL. =20 =20 =20 -----Original Message----- From: Piyush Jain [mailto:piyush@ditenity.com]=20 Sent: Wednesday, January 09, 2013 6:17 PM To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' Subject: RE: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined = in > section 4.4.8 of ocsp draft 8 > Importance: High >=20 > Peter; >=20 > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >=20 > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. >=20 > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The = certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are = signed fraudulently. RPs won't make queries for certificate for which they = cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently = issued certificates unless you are saying that this specification will allow = for RPs to skip signature checking. >=20 > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. >=20 > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? >=20 > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already = used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. >=20 > No that is a task for another possible effort. > It's not part of this update. =20 [Piyush] Can you clarify what is the goal for this update? I think it is = one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. =20 But based on different threads on this topic I get confused about what = it is. Having the goal clear would help us keep the review of draft = focused.=20 =20 >=20 > But this update paves the way for such extension. Which I'm not = against. > It's just not part of this update effort. =20 >=20 > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status = the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records = in > >OCSP database will be use: > > -- unknown >=20 >=20 > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect = (to > indicate that a certificate with this serial number should not be trusted). >=20 > It's important that this works with legacy clients. They will be = around for a > while. >=20 [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting = "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". =20 > /Stefan >=20 > > > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > >=20 =20 ------=_NextPart_000_0006_01CDEF2B.DAC9E8B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Stefan,

For me is unclear how this extension of = revoked with reason code = certificateHold is useful.

It define that now is possible to revoke what = does not exist and it open never ending cycle of trying to fixing or correcting = the first incorrect status that "fake" cert serial number is revoked but = cert serial number is not revoked because "fake" cert does not = exist.

=C2=A0

I agree that extension of revoked can be helpful = like:

=C2=A0=C2=A0 The "revoked" state =
indicates that the certificate has been =
revoked
=C2=A0=C2=A0 (either permanently or =
temporarily (on hold)). Response =
extensions
=C2=A0=C2=A0 may be used to convey additional =
information on assertions made =
by
=C2=A0=C2=A0 the responder regarding the =
status of the certificate such =
as
=C2=A0=C2=A0 positive statement about =
issuance, validity, etc.

 

 

When the certificate serial number is not in = the OCSP database/CRL then according to rfc2560bis there are defined following possible = responses:

1. signed - =C2=A0good (e.g. certificate serial number is not listed in CRL)

2. signed - =C2=A0unknown (e.g. certificate serial number is not listed in CRL)

3. unsigned =E2=80=93 unauthorized as an = error message

4. signed - =C2=A0revoked where according to rfc2560bis are defined values for:

Extensions: = id-pkix-ocsp-extended-revoke

Revocation Reasons: = certificateHold

Revocation Time: = 1.1.1970 00:00:00 UTC

 

What is missing? The rfc2560bis must also = specify values for:

This = Update:=C2=A0 ?? ?? ??=C2=A0=C2=A0=C2=A0=C2=A0 10.1.2013 9:51:15 = UTC

Next = Update: =C2=A0?? ?? ??=C2=A0=C2=A0=C2=A0=C2=A0 10.1.2013 9:51:15 = UTC

 

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) it = may be replaced by a (final) revocation; 3) it may be explicitly = released;

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as = revoked with reason code certificateHold can be replaced with real status of a new = real certificate which was issued with the same certificate serial number as was asked in = the incorrect OCSP request created by insufficiently implemented applications where = the signature of the certificate was not checked with CA public = key.

 

It is based on the following = definitions:

 
According to rfc2560bis the certificate =
status value is:
http:/=
/tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ =

 
=C2=A0=C2=A0 - =C2=A0good =E2=80=A6 is not =
revoked, (does not necessarily mean that the =
certificate was ever =
issued)=E2=80=A6
=C2=A0=C2=A0 - =C2=A0revoked =E2=80=A6 has =
been revoked (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.)
=C2=A0=C2=A0 - =C2=A0unknown =
=E2=80=A6

 

=C2=A0=C2=A0 When a responder responds =
revoked to a status request for a =
non-
=C2=A0=C2=A0 issued certificate, the =
responder MUST also;
 
=C2=A0=C2=A0=C2=A0 - include the extended =
revoked definition response =
extension
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (section 4.8), =
indicating that the OCSP responder supports =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extended =
definition of revoked state to also cover =
non-issued
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
certificates,
=C2=A0=C2=A0=C2=A0 - provide the revocation =
reason certificateHold (6), =
and;
=C2=A0=C2=A0=C2=A0 - specify the revocation =
date January 1, 1970.

 

 

According to ITU-T Rec. X.509 (11/2008), = clause 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-= X.509

A certificate may be placed on hold by = issuing a CRL entry with a reason code of certificateHold. The certificate hold notice = may include an optional hold instruction code to convey additional = information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be = handled in one of three ways:

a) it may remain on the CRL with no further = action, causing users to reject transactions issued during the hold period; or, =

b) it may be replaced by a (final) revocation = for the same certificate, in which case the reason shall be one of the standard = reasons for revocation, the revocation date shall be the date the certificate = was placed on hold, and the optional instruction code extension field shall = not appear; or,

c) it may be explicitly released and the = entry removed from the CRL.

 

 

 

-----Original Message-----
From: Piyush Jain [mailto:piyush@ditenity.com]
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

> -----Original Message-----

> From: Stefan Santesson = [mailto:stefan@aaa-sec.com]

> Sent: Tuesday, January 08, 2013 8:40 = PM

> To: Peter Rybar; 'Piyush Jain'; 'pkix'

> Subject: Re: [pkix] Question about extended Revoked = Extension defined in

> section 4.4.8 of ocsp draft 8

> Importance: High

>

> Peter;

>

> On 1/8/13 5:18 PM, "Peter Rybar" <rybar@nbusr.sk> = wrote:

>

> >Stefan,

> >The terminology is not clear for someone who will = see:

> >The revocation is of "non-issued = certificate".

> >Because by reading the text it is expected that the certificate was

> >issued, but fraudulently.

>

> What part of the text supports = that?

[Piyush] None explicitly, but many would infer it that way. The certificate

space that is covered by your interpretation of = "non-issued" includes

certificates which are not signed using the CA key and those = that are signed

fraudulently. RPs won't make queries for certificate for which = they cannot

verify the signature. So the only genuine requests for = "non-issued

certificates" coming to a responder would be those for fraudulently issued

certificates unless you are saying that this specification will = allow for

RPs to skip signature checking.

>

> >

> >The revocation with a new extension is only about = fraudulently issued

> >certificate. It means this new extension and revocation = is not used

> >when the certificate is not issued and only fake random certificate

> >serial number was created in OCSP = request.

>

> What?

> How in this physical universe would the OCSP responder tell = the

> difference???

> Crystal ball?

>

> >

> >While it is intended only for fraudulently issued = certificate where

> >fraudulently issued certificate can potentially reuse = any already used

> >certificate-serial-number the extension must contain = e.g. a positive

> >confirmation of existence in the form of hash value of fraudulently

> >issued certificate.

>

> No that is a task for another possible = effort.

> It's not part of this update.

 

[Piyush] Can you clarify what is the goal for this update? I = think it is one

of the following

- Allow for extending definition of revoked so other = specifications can

extend the protocol

- Address handling of fraudulently issued = certificate.

- Address handling of any certificate not issued by the = CA.

 

But based on different threads on this topic I get confused = about what it

is. Having the goal clear would help us keep the review of draft focused.

 

>

> But this update paves the way for such extension. Which I'm = not against.

> It's just not part of this update = effort.

 

>

> >

> >Only according to the hash value of fraudulently issued certificate

> >relaying party and OCSP responder is able to identify fraudulently

> >issued certificate because CA was compromised and = serial numbers of

> >certificates are not any longer unique for compromised = CA.

> >

> >Conclusion:

> >Positive statement extension as a hash value of the certificate whose

> >status OCSP response is providing can be used in this = case:

> >=C2=A0 when the certificate is = revoked,

> >=C2=A0 when the certificate is good and = also

> >=C2=A0 when the certificate is fraudulently = issued.

> >

> >For that reason it can be more helpful to define in RFC = one positive

> >statement extension as a hash value of the certificate = whose status the

> >OCSP response is providing and define in RFC that it = will support

> >situations when status is:

> >=C2=A0=C2=A0 -- good

> >=C2=A0=C2=A0 -- revoked

> >And for randomly created certificate serial numbers = without records in

> >OCSP database will be use:

> >=C2=A0=C2=A0 -- unknown

>

>

> No, we have been through this and determined WG = consensus.

> Unknown is not the choice, since it may not have the = desired effect (to

> indicate that a certificate with this serial number should = not be

trusted).

>

> It's important that this works with legacy clients. They = will be around

for a

> while.

>

[Piyush] That's an interesting usage of the word = "legacy". I don't think

that any of the previous versions of OCSP recommended = interpreting "unknown"

or UNAUTHORIZED(unsigned) responses to imply that certificate = can be

trusted. The right word would be to "incorrectly = implemented clients".

 

> /Stefan

>

> >

> >

> = >_______________________________________________

> >pkix mailing list

> >pkix@ietf.org

> = >https://www.ietf.org/mailman/listinfo/pkix

> >

>

 

------=_NextPart_000_0006_01CDEF2B.DAC9E8B0-- From piyush@ditenity.com Thu Jan 10 05:18: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 D23E721F884F for ; Thu, 10 Jan 2013 05:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 zM57LSyEmWkI for ; Thu, 10 Jan 2013 05:18:25 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5321F84C2 for ; Thu, 10 Jan 2013 05:18:24 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so507158obc.41 for ; Thu, 10 Jan 2013 05:18:24 -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=rcqZzZbkbPuRvagLfB0sHwmuQSJN+ki4yG/3B6LBOn8=; b=dHezACdHkyhPYifsbtNzJu+QZWcVbgs4GKx9QlKwbwaEe41wIOyTbnZOZXWGqAXV72 FQDK44WdWjZY9iyt9FCOofq72HRa2y4GGNs2JvGmxNadUNh5EMDSGouW0B1JTgYE4uLn GuZi8opPTBgWYyksTqV3W2vHJQeXJ7LM+/HzVqLFapzaxBkrv0tk4eKMKCNh+nPiyuJf V8F2MET4X9l+g11rCP1E2AJF2q3el4MMPqZAA8fZkSqjECjsEaphzZl59fnMoDizT53r J67o6TOfTAoi7G2xWOk16rR5E3Ay60SY3TZ9TXV1RbqS1dHNbN/EK68MAo2pitjRCb1V RWDg== X-Received: by 10.60.169.203 with SMTP id ag11mr41007653oec.124.1357823903834; Thu, 10 Jan 2013 05:18: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 4sm1082972oba.18.2013.01.10.05.18.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 05:18:22 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <057501cdee89$4a987c90$dfc975b0$@ditenity.com> In-Reply-To: Date: Thu, 10 Jan 2013 05:18:19 -0800 Message-ID: <068f01cdef34$f67f2d00$e37d8700$@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: AQGlatBqPcKiXZbZzJj9cu8RNyQgiZiTga2A Content-Language: en-us X-Gm-Message-State: ALoCoQkqHEJ4jNFhjQ3NKBzuvor6IMh7IAVDIr69usP7C9fcUw9BXXYutyyAJN254ZtI9DvYvHes Subject: Re: [pkix] Review of 2560-bis draft 8 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, 10 Jan 2013 13:18:25 -0000 Stefan, Thanks for getting back. Please see inline. > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Thursday, January 10, 2013 12:42 AM > To: Piyush Jain; pkix@ietf.org > Subject: Re: Review of 2560-bis draft 8 > > Thanks for the review. > > I will get back with comments on them. > > One questions though. > > Taking any random certificate serial number in the context of a CA. How can > that serial number have any status other than. > > 1) issued and not revoked. > 2) issued and revoked (or currently on hold). > 3) never issued by this CA. > [Piyush] Relying parties trust certificates. They do not trust certificate serial numbers. The question to ask is - what is the status of the certificate, not what is the status of a certificate serial number. "Never issued" is not a status of the certificate and RPs do not need responders to determine issuance. (at least in OCSP context). I have not seen an OCSP client which determines the trustworthiness of a certificate by sending an OCSP request without verifying that the certificate is issued by the CA. According to the spec, you cannot trust the responder if it is not issued by the same CA as the responder. The notion of extending revoked to imply a negative proof beyond revoked status (through use of extensions) is fine but to allow it for only one other kind of negative proof is limiting IMO. > This seem to be a fundamental unambiguous factual basic division of the > possible state of a serial number that is beyond question. > [Piyush] Think of a RP which sends a status request a certificate and includes a request extension to check if the bank account associated with the cert has at least 100 dollars. Failing this check the responder could return revoked (which implies bad according to this new update) My personal preference is to limit OCSP for just revocation status checks and communicate additional state information through extensions, as originally envisioned. However, if you are extending the meaning of revoked, allow it for any negative proof and require that meaning of revoked (if overridden) is communicated through a new OID in the extended revoked extension. This spec does not need to go into the details of what those overridden negative proofs could be. > Then of course you can sub-divide each category into further divisions, but > every possible serial number will always fall into exactly one of these > categories. > The Responder may not know which category a serial number belongs to > (may just know whether it belongs to 2) or not), and in such case, the > discussed update is of no relevance to them. > > To introduce "Bad" as a reason for responding revoked, or to be more > granular than this basic division, scares me, because there is no end to its > potential complexity and ambiguity. > I'm not against the community going further in giving more granular > information, but I'm reluctant to do it within this update. [Piyush] That is why this update should just allow for changing the meaning of revoked through single response extensions and let other communities define and use those extensions. The topic of "not issued" should not even feature in the main OCSP specification. > I further can't see why a CA would treat a certificate as "bad" without having > it revoked or on hold. > [Piyush] On hold is just a reason code associated with revoked. A responder can determine if the certificate is 'bad' or untrustworthy if it is asked to perform validation under some context specified in the request extension. Responders are not needed to determine issuance and people have repeatedly asserted that fraudulently issued certs cannot be addressed by OCSP in a secure way. > > What I feel less sure about is wether the extension should go into > responseExtensions or into singleExtensions. There are pros and cons with > both. > [Piyush] Depends on what it indicates. If it is responder capability it should be a response extension that should be sent with every response. If it is about overloading the meaning of revoked it should be a single response extension sent only with revoked status where the meaning has been changed. > /Stefan > From stefan@aaa-sec.com Thu Jan 10 05:18:47 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 53FEA21F88A1 for ; Thu, 10 Jan 2013 05:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.127 X-Spam-Level: X-Spam-Status: No, score=-101.127 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 Yxpr8e7r3KWn for ; Thu, 10 Jan 2013 05:18:42 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6956521F84D8 for ; Thu, 10 Jan 2013 05:18:41 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2A7951DA1962 for ; Thu, 10 Jan 2013 14:18:38 +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 EvBtjtD8GGo0 for ; Thu, 10 Jan 2013 14:18:33 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DFE991DA17B7 for ; Thu, 10 Jan 2013 14:18:33 +0100 (CET) Received: (qmail 44936 invoked from network); 10 Jan 2013 13:18:33 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jan 2013 13:18:33 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 10 Jan 2013 14:18:40 +0100 From: Stefan Santesson To: Peter Rybar , 'Piyush Jain' , 'pkix' Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <201301101113.r0ABD19C061661@mail.nbusr.sk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3440672323_29782104" Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 10 Jan 2013 13:18:47 -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_3440672323_29782104 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Peter, i think the reason for this has been thoroughly debated. It is correct that a cert serial number that was on hold, may be released. The requested cert serial number may actually be used in a future representing a real certificate. So this is intentional and the whole purpose behind using the on hold reason. /Stefan From: Peter Rybar Date: Thursday, January 10, 2013 12:13 PM To: 'Piyush Jain' , Stefan Santesson , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > Stefan, > For me is unclear how this extension of revoked with reason code > certificateHold is useful. > It define that now is possible to revoke what does not exist and it open = never > ending cycle of trying to fixing or correcting the first incorrect status= that > "fake" cert serial number is revoked but cert serial number is not revoke= d > because "fake" cert does not exist. > =20 > I agree that extension of revoked can be helpful like: > The "revoked" state indicates that the certificate has been revoked > (either permanently or temporarily (on hold)). Response extensions > may be used to convey additional information on assertions made by > the responder regarding the status of the certificate such as > positive statement about issuance, validity, etc. > =20 > =20 > When the certificate serial number is not in the OCSP database/CRL then > according to rfc2560bis there are defined following possible responses: > 1. signed - good (e.g. certificate serial number is not listed in CRL) > 2. signed - unknown (e.g. certificate serial number is not listed in CRL= ) > 3. unsigned =AD unauthorized as an error message > 4. signed - revoked where according to rfc2560bis are defined values for= : > Extensions: id-pkix-ocsp-extended-revoke > Revocation Reasons: certificateHold > Revocation Time: 1.1.1970 00:00:00 UTC > =20 > What is missing? The rfc2560bis must also specify values for: > This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC > Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC > =20 > X.509 defines the reason code certificateHold as 1) it may remain on the = CRL; > 2) it may be replaced by a (final) revocation; 3) it may be explicitly > released; > and=20 > 4) as a consequence of rfc2560bis the status of certificate serial number > indicated as revoked with reason code certificateHold can be replaced wit= h > real status of a new real certificate which was issued with the same > certificate serial number as was asked in the incorrect OCSP request crea= ted > by insufficiently implemented applications where the signature of the > certificate was not checked with CA public key. > =20 > It is based on the following definitions: > =20 > According to rfc2560bis the certificate status value is: > http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ > =20 > - good =8A is not revoked, (does not necessarily mean that the certific= ate > was ever issued)=8A > - revoked =8A has been revoked (This state MAY also be returned if the > responder knows that the requested certificate has never been issued duri= ng > the history of the associated CA using any current or previous issuing ke= y.) > - unknown =8A > =20 > When a responder responds revoked to a status request for a non- > issued certificate, the responder MUST also; > =20 > - 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. > =20 > =20 > According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code exten= sion: > http://www.itu.int/rec/T-REC-X.509 > A certificate may be placed on hold by issuing a CRL entry with a reason = code > of certificateHold. The certificate hold notice may include an optional h= old > instruction code to convey additional information to certificate users (s= ee > 8.5.2.3).=20 > Once a hold has been issued, it may be handled in one of three ways: > a) it may remain on the CRL with no further action, causing users to reje= ct > transactions issued during the hold period; or, > b) it may be replaced by a (final) revocation for the same certificate, i= n > which case the reason shall be one of the standard reasons for revocation= , the > revocation date shall be the date the certificate was placed on hold, and= the > optional instruction code extension field shall not appear; or, > c) it may be explicitly released and the entry removed from the CRL. > =20 > =20 > =20 > -----Original Message----- > From: Piyush Jain [mailto:piyush@ditenity.com] > Sent: Wednesday, January 09, 2013 6:17 PM > To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' > Subject: RE: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > =20 > =20 > =20 >> > -----Original Message----- >> > From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> > Sent: Tuesday, January 08, 2013 8:40 PM >> > To: Peter Rybar; 'Piyush Jain'; 'pkix' >> > Subject: Re: [pkix] Question about extended Revoked Extension defined = in >> > section 4.4.8 of ocsp draft 8 >> > Importance: High >> >=20 >> > Peter; >> >=20 >> > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >> >=20 >>> > >Stefan, >>> > >The terminology is not clear for someone who will see: >>> > >The revocation is of "non-issued certificate". >>> > >Because by reading the text it is expected that the certificate was >>> > >issued, but fraudulently. >> >=20 >> > What part of the text supports that? > [Piyush] None explicitly, but many would infer it that way. The certifica= te > space that is covered by your interpretation of "non-issued" includes > certificates which are not signed using the CA key and those that are sig= ned > fraudulently. RPs won't make queries for certificate for which they canno= t > verify the signature. So the only genuine requests for "non-issued > certificates" coming to a responder would be those for fraudulently issue= d > certificates unless you are saying that this specification will allow for > RPs to skip signature checking. >> >=20 >>> > > >>> > >The revocation with a new extension is only about fraudulently issue= d >>> > >certificate. It means this new extension and revocation is not used >>> > >when the certificate is not issued and only fake random certificate >>> > >serial number was created in OCSP request. >> >=20 >> > What? >> > How in this physical universe would the OCSP responder tell the >> > difference??? >> > Crystal ball? >> >=20 >>> > > >>> > >While it is intended only for fraudulently issued certificate where >>> > >fraudulently issued certificate can potentially reuse any already us= ed >>> > >certificate-serial-number the extension must contain e.g. a positive >>> > >confirmation of existence in the form of hash value of fraudulently >>> > >issued certificate. >> >=20 >> > No that is a task for another possible effort. >> > It's not part of this update. > =20 > [Piyush] Can you clarify what is the goal for this update? I think it is = one > of the following > - Allow for extending definition of revoked so other specifications can > extend the protocol > - Address handling of fraudulently issued certificate. > - Address handling of any certificate not issued by the CA. > =20 > But based on different threads on this topic I get confused about what it > is. Having the goal clear would help us keep the review of draft focused. > =20 >> >=20 >> > But this update paves the way for such extension. Which I'm not agains= t. >> > It's just not part of this update effort. > =20 >> >=20 >>> > > >>> > >Only according to the hash value of fraudulently issued certificate >>> > >relaying party and OCSP responder is able to identify fraudulently >>> > >issued certificate because CA was compromised and serial numbers of >>> > >certificates are not any longer unique for compromised CA. >>> > > >>> > >Conclusion: >>> > >Positive statement extension as a hash value of the certificate whos= e >>> > >status OCSP response is providing can be used in this case: >>> > > when the certificate is revoked, >>> > > when the certificate is good and also >>> > > when the certificate is fraudulently issued. >>> > > >>> > >For that reason it can be more helpful to define in RFC one positive >>> > >statement extension as a hash value of the certificate whose status = the >>> > >OCSP response is providing and define in RFC that it will support >>> > >situations when status is: >>> > > -- good >>> > > -- revoked >>> > >And for randomly created certificate serial numbers without records = in >>> > >OCSP database will be use: >>> > > -- unknown >> >=20 >> >=20 >> > No, we have been through this and determined WG consensus. >> > Unknown is not the choice, since it may not have the desired effect (t= o >> > indicate that a certificate with this serial number should not be > trusted). >> >=20 >> > It's important that this works with legacy clients. They will be aroun= d > for a >> > while. >> >=20 > [Piyush] That's an interesting usage of the word "legacy". I don't think > that any of the previous versions of OCSP recommended interpreting "unkno= wn" > or UNAUTHORIZED(unsigned) responses to imply that certificate can be > trusted. The right word would be to "incorrectly implemented clients". > =20 >> > /Stefan >> >=20 >>> > > >>> > > >>> > >_______________________________________________ >>> > >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 --B_3440672323_29782104 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Peter, i think the reason fo= r this has been thoroughly debated.

It is correct t= hat a cert serial number that was on hold, may be released.
The re= quested cert serial number may actually be used in a future representing a r= eal certificate.
So this is intentional and the whole purpose behi= nd using the on hold reason.

/Stefan

=
From: Peter Rybar <rybar@nbusr.sk>
Date: Thursday, January 10, 2013 12:13 PM
To: 'Piyush Jain' <= piyush@ditenity.com>, Stefan Santesson <stefan@aaa-sec.com>, 'pkix' <pkix@ietf.org>
Subject: = Re: [pkix] Question about extended Revoked Extension defined in section 4.4= .8 of ocsp draft 8

Stefan,

For me is unclear how this extension of revoked with reason code certificateHold is useful.

It define th= at now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the = first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist.=

 

I agree that extension of revoked can be helpful like:

<= pre> &= nbsp; The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on ho=
ld)). Response extensions
   may be used t=
o convey additional information on assertions made by
   the responder regarding the status of the certificate such as=

   positive statement about issuance, val=
idity, etc.

&n= bsp;

 

When the certificate serial number = is not in the OCSP database/CRL then according to rfc2560bis there are defined following possible responses= :

1. signed -  <= b>good (e.g. certificate serial number is not listed in CRL)

2. signed -  unknown (e.g. certificate serial number is not listed in CRL)

3. unsigned – unauthorized as an error message

4. signed -  revoked where according to rfc2560bis are defined values for:

Extensions: id-pk= ix-ocsp-extended-revoke

Revocation Reasons: cer= tificateHold

Revocation Time: 1.1.19= 70 00:00:00 UTC

 

What i= s missing? The rfc2560bis must also specify values for:

This Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

> -----Original Message-----

> From: Stefan Santesson [ma= ilto:stefan@aaa-sec.com]

> Sent: Tuesday, January 08, 2013 8:40 PM

> To: Peter Ry= bar; 'Piyush Jain'; 'pkix'

<= font size=3D"2" face=3D"Courier New">> Subject: Re: [pkix] Question about extended Revoked Extension defined in

> section 4.4.8 of ocsp draft 8

> Importance: High

>

> Peter;

>

> On 1/8/13 5:18 PM, "Peter Rybar" <ry= bar@nbusr.sk> wrote:

>

> >Stefan,

> >The terminology is not clear for someone who will see:

> >The revocation is of "non-issued certificate".<= /span>

<= span style=3D"font-size: 10.0pt">> >Because by reading the text it is expected that the certificate was

> >issued, but fraudulently.

>

> What part of the text supports that?<= /p>

[Piyush] None explicitly, but many would infer it that way. The certificate

space that is covered by your interpretation of "non-issued" includes

certificates which are not signed using the CA key and those that a= re signed

fraudulently. RPs won't make queries for certificate for which they= cannot

verify the signature. So the only genuine requests for "non-issued<= o:p>

certificates" coming to a responder would be those for fraudulently issued

certificates unless you are saying that this specification will all= ow for

RPs to skip signature checking.

>

> >

> >The revocation with a new extension is only about fraudule= ntly issued

> >certificate. It means this new extension and revocation is= not used

> >when the certificate is not issued and only fake random certificate

> >serial number was created in OCSP request.

>

> What?

> How in this physical universe would the OCSP responder tell th= e

> difference???

> Crystal ball?

>

> >

> >While it is intended only for fraudulently issued certific= ate where

> >fraudulently issued certificate can potentially reuse any already used

> >certificate-serial-number the extension must contain e.g. = a positive

> >confirmation of existence in the form of hash value of fraudulently

> >issued certificate.

>

> No that is a task for another possible effort.

> It's not part of this update.

 

[Piyush] Can you clarify what is the goal for this update? I think = it is one

of the following

- Allow for extending definition of revoked so other specifications= can

extend the protocol

- Address handling of fraudulently issued certificate.

- Address handling of any certificate not issued by the CA.

 

But based on different threads on this topic I get confused about w= hat it

is. Having the goal clear would help us keep the review of draft focused.

 

>

> But this update paves the way for such extension. Which I'm no= t against.

> It's just not part of this update effort.

 

>

> >

> >Only according to the hash value of fraudulently issued certificate

> >relaying party and OCSP responder is able to identify fraudulently

> >issued certificate because CA was compromised and serial numbers of

> >certificates are not any longer unique for compromised CA.=

> >

> >Conclusion:

> >Positive statement extension as a hash value of the certificate whose

> >status OCSP response is providing can be used in this case= :

> >  when the certificate is revoked,<= /font>

> >  when the certificate is good and also

> >  when the certificate is fraudulently issued.

> >

> >For that reason it can be more helpful to define in RFC on= e positive

> >statement extension as a hash value of the certificate who= se status the

> >OCSP response is providing and define in RFC that it will support

> >situations when status is:

> >   -- good

> >   -- revoked

> >And for randomly created certificate serial numbers withou= t records in

> >OCSP database will be use:

> >   -- unknown

>

>

> No, we have been through this and determined WG consensus.

> Unknown is not the choice, since it may not have the desired effect (to

> indicate that a certificate with this serial number should not= be

trusted).

>

> It's important that this works with legacy clients. They will = be around

for a

> while.

>

[Piyush] That's an interesting usage of the word "legacy". I don't think

that any of the previous versions of OCSP recommended interpreting "unknown"

or UNAUTHORIZED(unsigned) responses to imply that certificate can b= e

trusted. The right word would be to "incorrectly implemented clients".

 

> /Stefan

>

> >

> >

> >_______________________________________________=

= > >pkix mailing list

> >pkix@ietf.org

> >https= ://www.ietf.org/mailman/listinfo/pkix

> >

>

 

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3440672323_29782104-- From mrex@sap.com Thu Jan 10 10:32: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 BAA9F21F8935 for ; Thu, 10 Jan 2013 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 d-Oc2Y+K9asP for ; Thu, 10 Jan 2013 10:32:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5321F883A for ; Thu, 10 Jan 2013 10:32:26 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0AIWHxl014249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 19:32:17 +0100 (MET) In-Reply-To: To: Stefan Santesson Date: Thu, 10 Jan 2013 19:32:17 +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: <20130110183217.437831A44A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:32:27 -0000 Stefan Santesson wrote: > > Peter, i think the reason for this has been thoroughly debated. +1 More importantly: it is entirely irrelevant for the operation of the OCSP responder what motivates the RP doing what it does, and what weird things the RP might infer that are *NOT* specified. For completeness, the behaviour of the OCSP responder should be well-defined even for requests that some think would be spec-incompliant for an RP to send, because there are going to be RPs that will do spec-incompliant things. > Peter Rybar wrote: > > > > X.509 defines the reason code certificateHold as > > 1) it may remain on the CRL; > > 2) it may be replaced by a (final) revocation; > > 3) it may be explicitly released; > > It is correct that a cert serial number that was on hold, may be released. Peter's list is misleading to the point that I would call it incorrect. While there exists a ReasonCode "removeFromCRL(8)", this reason code is strictly limited to "delta CRLs", and therefore MUST NOT appear on base CRLs and consequently MUST NOT appear in OCSP responses. An (issued!) certificate that was listed onHold on a base CRL or on a delta CRL will simple be missing on the next base CRL if the CA clears the onHold status. > > The requested cert serial number may actually be used in a future > representing a real certificate. > So this is intentional and the whole purpose behind using the on hold > reason. Correct. -Martin From mrex@sap.com Thu Jan 10 11:18: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 186CC21F8930 for ; Thu, 10 Jan 2013 11:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.18 X-Spam-Level: X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 BWa2f6FZEhYX for ; Thu, 10 Jan 2013 11:18:16 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE921F8864 for ; Thu, 10 Jan 2013 11:18:15 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0AJI6is026545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 20:18:06 +0100 (MET) In-Reply-To: <068f01cdef34$f67f2d00$e37d8700$@ditenity.com> To: Piyush Jain Date: Thu, 10 Jan 2013 20:18:06 +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: <20130110191806.0BB171A44B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:18:20 -0000 Piyush Jain wrote: > > Stefan Santesson wrote: > > > > Taking any random certificate serial number in the context of a CA. > > How can that serial number have any status other than: > > > > 1) issued and not revoked. > > 2) issued and revoked (or currently on hold). > > 3) never issued by this CA. Exactly. > > [Piyush] Relying parties trust certificates. > They do not trust certificate serial numbers. That is actually entirely irrelevant. We're discussing the OCSP protocol here (and to some extent CRLs), and these protocols are factually about status of certificate serial numbers, NOT certificates. (which is exactly one of the security problems of CRLs and OCSP, for which this change is a partial remedy...). > > The question to ask is - what is the status of the certificate, That is a question/decision inside the RP. Irrelevant to OCSP. > > not what is the status of a certificate serial number. CRLs and OCSP (the latter in its basic form), are not about certs, they're only about certificate serial numbers. PKIX unfortunately has the bad habit of drawing bold conclusions from the status of certificate serial numbers. > > "Never issued" is not a status of the certificate It is the status of a certificate serial number. OCSP is about the status of certificate serial numbers. > > and RPs do not need responders to determine issuance. The OCSP responder, as well as the OCSP protocol, do not care at all, about motivations of RPs. > > I have not seen an OCSP client which determines the trustworthiness of a > certificate by sending an OCSP request without verifying that the > certificate is issued by the CA. According to the spec, you cannot trust the > responder if it is not issued by the same CA as the responder. You might want to update your Web Browser if yours really so old that it does not allow you to configure a local trusted OCSP responder ... ;-) > > > This seem to be a fundamental unambiguous factual basic division of the > > possible state of a serial number that is beyond question. +1 > > [Piyush] Think of a RP which sends a status request a certificate and > includes a request extension to check if the bank account associated with > the cert has at least 100 dollars. > Failing this check the responder could return revoked (which implies bad > according to this new update) That OCSP responder can do that today. And even if we add a MUST NOT for this particular example into the spec, that OCSP responder can continue operating in this fashion, and there will be nothing that we can do about it. There is not IETF protocol SWAT team that will take down a service for an IETF protocol violation (if it existed, it would probably have to take down 99% of the internet...). > > My personal preference is to limit OCSP for just revocation status checks > and communicate additional state information through extensions, as > originally envisioned. You can continue doing that in _your_ RPs and _your_ OCSP responders. This update is not going to interfere with what you're doing in any way. > > However, if you are extending the meaning of revoked, allow it for any > negative proof and require that meaning of revoked (if overridden) is > communicated through a new OID in the extended revoked extension. > This spec does not need to go into the details of what those overridden > negative proofs could be. It's my impression that you're misunderstanding the OCSP protocol. Although the expanded name is "Online Certificate Status Protocol", it really is, and always was, about the status of certificate serial numbers, not about the status of certs. Any other "negatives" would have to be new ReasonCode-s to be added to X.509. > > > Then of course you can sub-divide each category into further divisions, > > but every possible serial number will always fall into exactly one of > > these categories. > > The Responder may not know which category a serial number belongs to > > (may just know whether it belongs to 2) or not), and in such case, the > > discussed update is of no relevance to them. +1 > > > > To introduce "Bad" as a reason for responding revoked, or to be more > > granular than this basic division, scares me, because there is no end to > > its potential complexity and ambiguity. +1 > > I'm not against the community going further in giving more granular > > information, but I'm reluctant to do it within this update. +1 > > [Piyush] That is why this update should just allow for changing the meaning > of revoked through single response extensions and let other communities > define and use those extensions. > The topic of "not issued" should not even feature in the main OCSP > specification. You're ~13 years late. "not issued" is *already* part of rfc2560: quoting from rfc2560: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued This update is about fixing an inconsistency in rfc2560. > > [Piyush] On hold is just a reason code associated with revoked. > A responder can determine if the certificate is 'bad' or untrustworthy if it > is asked to perform validation under some context specified in the request > extension. > Responders are not needed to determine issuance (OCSP) Responders are need to convey certificate serial number status. Conveying "good" for a certificate serial number that is positively known to have never been issued would be stupid and wrong. > > and people have repeatedly asserted that fraudulently issued certs > cannot be addressed by OCSP in a secure way. This is the first step in standardizing how to report "non-issued" for a certificate serial number. You're misinterpreting the situation. For OCSP, this approach *IS* completely secure. There is the problem that some of the bold/flawed assumptions of PKI(X) evaporate for certain kind of CA security breaches. But that could be addressed by updating OCSP even further, eliminating the single point of failure CA cert that is implied by OCSP AIA in the leaf cert. > > What I feel less sure about is wether the extension should go into > > responseExtensions or into singleExtensions. There are pros and cons with > > both. > > [Piyush] Depends on what it indicates. If it is responder capability it > should be a response extension that should be sent with every response. If > it is about overloading the meaning of revoked it should be a single > response extension sent only with revoked status where the meaning has been > changed. I agree with that determination. -Martin From piyush@ditenity.com Thu Jan 10 12:35: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 B71C821F8848 for ; Thu, 10 Jan 2013 12:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 fZz3fqqOiUGi for ; Thu, 10 Jan 2013 12:35:58 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id D16EF21F8846 for ; Thu, 10 Jan 2013 12:35:57 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n9so1065449oag.27 for ; Thu, 10 Jan 2013 12:35:57 -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=qrJ3Cu8+Zj9j8njY/6NI89WkAK0S5/wDCs9MEjwZnEw=; b=fmTPyp8x0W1oxbzB3i2gFW3/dbOAKaAV3Kkzlb3yvB6K1hddEZJozGBQP5KMloPl2R opeWDiaujSvR2mK4Ea2EeuE1RWzKmHY+qBL89q9uip2iCG4fj00vvY5M18qWaZNtA0FK G+6RkbnNan9kp+QqVh3c3psGl9jDXS2sJKKPGes5oXPMu/c14jiwfdPnMxIMOIBOyQxo eVNKwylN3nHZtYRK7plZKEi1TWc8BWBF6yPinkPNTqIZTNybYfCMJiTJ1+lNT05pbMaX kjrwJt66MRt4WqsCyhpC0B+VPhgLRB1q6iYEW3ZfKFdC7DufTMFKUqvIs2zEZZag8oJW jaeg== X-Received: by 10.60.31.206 with SMTP id c14mr41808585oei.88.1357850157112; Thu, 10 Jan 2013 12:35:57 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id aw4sm1952716oec.9.2013.01.10.12.35.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 12:35:56 -0800 (PST) From: "Piyush Jain" To: , "'Stefan Santesson'" References: <20130110183217.437831A44A@ld9781.wdf.sap.corp> In-Reply-To: <20130110183217.437831A44A@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 12:35:52 -0800 Message-ID: <008a01cdef72$166e4cd0$434ae670$@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: AQHbKeRIMHF2tpbSqTXwCS4h0MxU4JgoiWPg Content-Language: en-us X-Gm-Message-State: ALoCoQlMXVAYHps5ve0hYJnHyjfx6SwNMw2JNSZzlleROIKqoyHN6iizvhZLo5gkztVMvXmDPVxm Cc: 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 10 Jan 2013 20:35:58 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, January 10, 2013 10:32 AM > To: Stefan Santesson > Cc: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Stefan Santesson wrote: > > > > Peter, i think the reason for this has been thoroughly debated. > > +1 [Piyush] Debated but there was no consensus. > > More importantly: it is entirely irrelevant for the operation of the OCSP > responder what motivates the RP doing what it does, and what weird things > the RP might infer that are *NOT* specified. [Piyush] I think we are in agreement. If RPs decides to treat signed unknown or UNAUTHORIZED as good, the standards body should not change the spec to accommodate such behavior. > > For completeness, the behaviour of the OCSP responder should be well- > defined even for requests that some think would be spec-incompliant for an > RP to send, because there are going to be RPs that will do spec-incompliant > things. [Piyush] I agree again. The question is what is that well-defined behavior? Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective. > > > > Peter Rybar wrote: > > > > > > X.509 defines the reason code certificateHold as > > > 1) it may remain on the CRL; > > > 2) it may be replaced by a (final) revocation; > > > 3) it may be explicitly released; > > > > It is correct that a cert serial number that was on hold, may be released. > > > Peter's list is misleading to the point that I would call it incorrect. > > While there exists a ReasonCode "removeFromCRL(8)", this reason code is > strictly limited to "delta CRLs", and therefore MUST NOT appear on base CRLs > and consequently MUST NOT appear in OCSP responses. [Piyush] While I see no value of including removefromcrl in OCSP responses I'm surprised at how you arrive to that conclusion in the above sentence. How is content of OCSP response related to that of CRL or delta CRL? > > An (issued!) certificate that was listed onHold on a base CRL or on a delta CRL > will simple be missing on the next base CRL if the CA clears the onHold status. > > > > > > The requested cert serial number may actually be used in a future > > representing a real certificate. [Piyush] It is as likely as I growing wings and start flying in future. > > So this is intentional and the whole purpose behind using the on hold > > reason. > [Piyush] The purpose is to support the hack of unissued certificates. Genuine RPs won't send request for such certificates. And it does not matter what you return to malicious clients. > Correct. > > -Martin From mrex@sap.com Thu Jan 10 13:21: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 D2B7921F8842 for ; Thu, 10 Jan 2013 13:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPTNXLZUiUso for ; Thu, 10 Jan 2013 13:21:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 809E021F8838 for ; Thu, 10 Jan 2013 13:21:29 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0ALLPvh029253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 22:21:25 +0100 (MET) In-Reply-To: <008a01cdef72$166e4cd0$434ae670$@ditenity.com> To: Piyush Jain Date: Thu, 10 Jan 2013 22:21:25 +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: <20130110212125.84F071A44C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:21:31 -0000 Piyush Jain wrote: > > > > For completeness, the behaviour of the OCSP responder should be well- > > defined even for requests that some think would be spec-incompliant for an > > RP to send, because there are going to be RPs that will do > > spec-incompliant things. > > [Piyush] I agree again. The question is what is that well-defined behavior? > Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective. At the pure fomal level, you're correct that just having defined _any_ behaviour would suffice to describe it as "well defined". But when just slightly beyond, OCSP does not exist for its own merit, it has a specific purpose, and we *know* that RPs are going to infer (and then act on) the OCSP response. We know that RPs / OCSP clients will either skip revocation checking or fallback to using CRLs when they receive MALFORMED_REQUEST or UNAUTHORIZED as the response, and in both cases, will end up considering the certificate status for the certificate serial in question as "good". Which means that both of these answers are useless for the intended purpose, discouraging the RP from considering a certificiate status of a certificate with the serial in question as "good". > > > > Peter Rybar wrote: > > > > > > > > X.509 defines the reason code certificateHold as > > > > 1) it may remain on the CRL; > > > > 2) it may be replaced by a (final) revocation; > > > > 3) it may be explicitly released; > > > > > > It is correct that a cert serial number that was on hold, may be > released. > > > > > > Peter's list is misleading to the point that I would call it incorrect. > > > > While there exists a ReasonCode "removeFromCRL(8)", this reason code is > > strictly limited to "delta CRLs", and therefore MUST NOT appear on base > > CRLs and consequently MUST NOT appear in OCSP responses. > > [Piyush] While I see no value of including removefromcrl in OCSP responses > I'm surprised at how you arrive to that conclusion in the above sentence. > How is content of OCSP response related to that of CRL or delta CRL? It was and still is perfectly OK for OCSP responders to draw their knowledge about certificate (serial) status from CRLs. http://tools.ietf.org/html/rfc2560#section-4.4.2 The rfc2560 update is not going to change that. However, an OCSP responder which would copy a status "removeFromCRL(8)" from a delta CRL into an OCSP response would be defective. > > > > > > The requested cert serial number may actually be used in a future > > > representing a real certificate. > > [Piyush] It is as likely as I growing wings and start flying in future. This is about avoiding the abusive potential. "certificateOnHold(8)" is an un-ambiguously temporary status assertion, whereas a generic "revoked" is a final status assertion. > > > > So this is intentional and the whole purpose behind using the on hold > > > reason. > > > [Piyush] The purpose is to support the hack of unissued certificates. > Genuine RPs won't send request for such certificates. > And it does not matter what you return to malicious clients. You're not looking at the complete picture. If you set up a local OCSP responder, it will be perfectly OK for such a responder not only to source from CRLs, but alternatively to essentially forward/proxy the OCSP request, and either cache and forward the response cache and recreate an OCSP response with the local signature. In the latter case, when the original OCSP client only sent the issuer&serial in the OCSP request, the local OCSP responder is a perfectly correct an honest client, still it might be forwarding a request for a certificate serial without having seen (let alone verified) the certificate carrying that serial. -Martin From piyush@ditenity.com Thu Jan 10 13:38: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 9783C21F88D6 for ; Thu, 10 Jan 2013 13:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 jR4cxOQSjOBJ for ; Thu, 10 Jan 2013 13:38:04 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6CC21F886B for ; Thu, 10 Jan 2013 13:38:04 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i18so1145062oag.32 for ; Thu, 10 Jan 2013 13:38:03 -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=aKVynikEeIYYxEu6GWMsvKjDcxs7Y4m/Im5IBwNi3CA=; b=dRS2OFlKypuYZ/J/s/O49wwz1rZOrSv57EVA7q9L3CSLTTX1sOBhyxvi3AXxJ++dLq dwMdN7bx1qMgbE/EeW33gZdhdbCmeyrivzm6H2uKRlYK8GcoZeZL20oF8FD9ovuvuqKV 6+rfeyrbC5tu1jquBKRsaEenjxyixebaRp3sElEMSVanV7TNxJAvkRyr9X7/DnD2gCZH 4VtSU22F/TmQzd2a8OsjnzJYE5r54TxwLPohrcrgYCyhi9L1XRpPIcnM0GeC7fYUIIn1 dkSXo21Lg6LShHa+HefeQIwDyFeje3eZDZPopXA+i94mItBaoGpAdJHOmiDzQ23kNb97 pFSg== X-Received: by 10.182.144.7 with SMTP id si7mr44107051obb.94.1357853883744; Thu, 10 Jan 2013 13:38:03 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id b6sm2091914oee.3.2013.01.10.13.38.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 13:38:03 -0800 (PST) From: "Piyush Jain" To: References: <068f01cdef34$f67f2d00$e37d8700$@ditenity.com> <20130110191806.0BB171A44B@ld9781.wdf.sap.corp> In-Reply-To: <20130110191806.0BB171A44B@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 13:37:59 -0800 Message-ID: <009501cdef7a$c3b96c50$4b2c44f0$@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: AQElWy3JZO1/EZVMPi6o83SBxCXKAJmULgkQ Content-Language: en-us X-Gm-Message-State: ALoCoQnYEk0OgQMlmo28IRe0KMV0lJF+o6A+59+iMvaOBnoVK9YDWdcqlwVauqHCESJx30NkIS9p Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 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, 10 Jan 2013 21:38:05 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, January 10, 2013 11:18 AM > To: Piyush Jain > Cc: 'Stefan Santesson'; pkix@ietf.org > Subject: Re: [pkix] Review of 2560-bis draft 8 > > Piyush Jain wrote: > > > > Stefan Santesson wrote: > > > > > > Taking any random certificate serial number in the context of a CA. > > > How can that serial number have any status other than: > > > > > > 1) issued and not revoked. > > > 2) issued and revoked (or currently on hold). > > > 3) never issued by this CA. > > Exactly. > > > > > > [Piyush] Relying parties trust certificates. > > They do not trust certificate serial numbers. > > That is actually entirely irrelevant. We're discussing the OCSP protocol here > (and to some extent CRLs), and these protocols are factually about status of > certificate serial numbers, NOT certificates. > [Piyush] I'm surprised by your interpretation of these specs. My simple advice - don't trust the certificate if OCSP responder says it is good. Make sure it chains to a trust anchor. CA hash and serial combined is representation of the certificate. > (which is exactly one of the security problems of CRLs and OCSP, for which > this change is a partial remedy...). > > [Piyush] You allude to this problem again and again. Please lay out a use case that captures the problem and tell us how this update addresses the problem. > > > > The question to ask is - what is the status of the certificate, > > That is a question/decision inside the RP. Irrelevant to OCSP. > > [Piyush] I don't get it. RP uses OCSP to determine the status of a certificate and it is irrelevant to OCSP? > > > > not what is the status of a certificate serial number. > > CRLs and OCSP (the latter in its basic form), are not about certs, they're only > about certificate serial numbers. > > PKIX unfortunately has the bad habit of drawing bold conclusions from the > status of certificate serial numbers. > > > > > > "Never issued" is not a status of the certificate > > It is the status of a certificate serial number. > OCSP is about the status of certificate serial numbers. > > > > > > and RPs do not need responders to determine issuance. > > The OCSP responder, as well as the OCSP protocol, do not care at all, about > motivations of RPs. > [Piyush] Really. I thought that the protocol and responders exist primarily to address one motivation of RPs - to get correct revocation status of a certificate. > > > > > I have not seen an OCSP client which determines the trustworthiness of > > a certificate by sending an OCSP request without verifying that the > > certificate is issued by the CA. According to the spec, you cannot > > trust the responder if it is not issued by the same CA as the responder. > > You might want to update your Web Browser if yours really so old that it does > not allow you to configure a local trusted OCSP responder ... ;-) > > [Piyush] Silly me - So I can assume that you support addition of text that says that CA delegated responders should not issue extended revoked responses.;) > > > > > This seem to be a fundamental unambiguous factual basic division of > > > the possible state of a serial number that is beyond question. > > +1 > > > > > > [Piyush] Think of a RP which sends a status request a certificate and > > includes a request extension to check if the bank account associated > > with the cert has at least 100 dollars. > > Failing this check the responder could return revoked (which implies > > bad according to this new update) > > That OCSP responder can do that today. And even if we add a MUST NOT for > this particular example into the spec, that OCSP responder can continue > operating in this fashion, and there will be nothing that we can do about it. > There is not IETF protocol SWAT team that will take down a service for an IETF > protocol violation (if it existed, it would probably have to take down 99% of > the internet...). [Piyush] We are agreeing on quite a few things here. So what is the need for this update. OCSP responders can respond with revoked for non-issued or fraudulently issued certificates today. There is not IETF protocol SWAT team that will take down a service for an IETF protocol violation (if it existed, it would probably have to take down 99% of the internet...). > > > > > > My personal preference is to limit OCSP for just revocation status > > checks and communicate additional state information through > > extensions, as originally envisioned. > > You can continue doing that in _your_ RPs and _your_ OCSP responders. > This update is not going to interfere with what you're doing in any way. > [Piyush] Or we can get rid of this update. Lack of this update won't interfere with responders who return revoked for non-issued. > > > > > However, if you are extending the meaning of revoked, allow it for any > > negative proof and require that meaning of revoked (if overridden) is > > communicated through a new OID in the extended revoked extension. > > This spec does not need to go into the details of what those > > overridden negative proofs could be. > > > It's my impression that you're misunderstanding the OCSP protocol. > Although the expanded name is "Online Certificate Status Protocol", [Piyush] What can I say - I'm speechless. I think the misnomer got me. >it really > is, and always was, about the status of certificate serial numbers, not about > the status of certs. > [Piyush] I think you sincerely believe this. You should petition to change the text in all those published specs that call for checking certificate status using CRLs and OCSP. Here are some examples: 5280 Section 3: " CAs are responsible for indicating the revocation status of the certificates that they issue. Revocation status information may be provided using the Online Certificate Status Protocol (OCSP)" 5280 Section 5: " A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL." 5280 Section 6.3 : " The algorithm output is the revocation status of the certificate" 5280 Section 6.3.1 : " certificate: The algorithm requires the certificate serial number and issuer name to determine whether a certificate is on a particular CRL." And so on. I guess we globally replace "certificate status" with "certificate serial status". > Any other "negatives" would have to be new ReasonCode-s to be added to > X.509. [Piyush] > > > > > > > > > Then of course you can sub-divide each category into further > > > divisions, but every possible serial number will always fall into > > > exactly one of these categories. > > > The Responder may not know which category a serial number belongs to > > > (may just know whether it belongs to 2) or not), and in such case, > > > the discussed update is of no relevance to them. > > +1 > > > > > > > To introduce "Bad" as a reason for responding revoked, or to be more > > > granular than this basic division, scares me, because there is no > > > end to its potential complexity and ambiguity. > > +1 > > > > I'm not against the community going further in giving more granular > > > information, but I'm reluctant to do it within this update. > > +1 > > > > > [Piyush] That is why this update should just allow for changing the > > meaning of revoked through single response extensions and let other > > communities define and use those extensions. > > The topic of "not issued" should not even feature in the main OCSP > > specification. > > You're ~13 years late. "not issued" is *already* part of rfc2560: > > > quoting from rfc2560: > > The "good" state indicates a positive response to the status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued > > This update is about fixing an inconsistency in rfc2560. > > > > > > [Piyush] On hold is just a reason code associated with revoked. > > A responder can determine if the certificate is 'bad' or untrustworthy > > if it is asked to perform validation under some context specified in > > the request extension. > > Responders are not needed to determine issuance > > (OCSP) Responders are need to convey certificate serial number status. > Conveying "good" for a certificate serial number that is positively known to > have never been issued would be stupid and wrong. [Piyush] Sure. How about UNAUTHORIZED or MALFORMED_REQUEST > > > > > > and people have repeatedly asserted that fraudulently issued certs > > cannot be addressed by OCSP in a secure way. > > This is the first step in standardizing how to report "non-issued" > for a certificate serial number. > [Piyush] A step that does not address any practical use cases. > You're misinterpreting the situation. For OCSP, this approach *IS* > completely secure. [Piyush] That's another bold claim without any associated facts. Just lay out one use case and we can analyze it to see if the claim holds up > [Piyush] > There is the problem that some of the bold/flawed assumptions of PKI(X) > evaporate for certain kind of CA security breaches. [Piyush] What flawed assumptions. There are security breaches and there are procedures to address them. And some of the procedures require that CA be revoked. What's wrong with that. But that could be > addressed by updating OCSP even further, eliminating the single point of > failure CA cert that is implied by OCSP AIA in the leaf cert. > [Piyush] May be. But the trust models are what they are today. > > > > What I feel less sure about is wether the extension should go into > > > responseExtensions or into singleExtensions. There are pros and cons > > > with both. > > > > [Piyush] Depends on what it indicates. If it is responder capability > > it should be a response extension that should be sent with every > > response. If it is about overloading the meaning of revoked it should > > be a single response extension sent only with revoked status where the > > meaning has been changed. > > I agree with that determination. > > -Martin From piyush@ditenity.com Thu Jan 10 14:51: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 BCC9921F86CE for ; Thu, 10 Jan 2013 14:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQdzCZBw7SNn for ; Thu, 10 Jan 2013 14:51:06 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 649E821F8589 for ; Thu, 10 Jan 2013 14:51:06 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id un3so1132978obb.7 for ; Thu, 10 Jan 2013 14:51:05 -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=zVNqTo/z/Wd9WsdTerglqt8jUU4vp0gW8duC1SHsl5A=; b=NLNEoTbgTyLuEICffjpG20nDeWlI2TSUFmGXKWBOZCBOJ3tJj05faRhpzzK3Gw6HDt xacINt6b12ErNr9dkd1B+49ARozVFHvFMl76enC3nwd5kGz+Lw2z64Vql0BWMvXrAatm GjHFboTNl3jo/gqAa+W4w6uuM/eYLMUCpzM0SXFAwQQy0a4wiHi3nRu5DoORMGJnHU2X 8CaCEYwpS4IejTiiOBQ9BmjaFUlgcVfOXmN0b9hvG6UNceDQevctBCj8CFz0fDuPNq+3 k9AhP3V8/l0nkqjvbSpamXZr3JIE0CkUOON0NECvsyr27UaZFQ/MICZUVu/sEBZZIs2Y xrCA== X-Received: by 10.60.23.200 with SMTP id o8mr42087945oef.48.1357858265615; Thu, 10 Jan 2013 14:51:05 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id c4sm2251515oee.0.2013.01.10.14.51.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 14:51:05 -0800 (PST) From: "Piyush Jain" To: References: <008a01cdef72$166e4cd0$434ae670$@ditenity.com> <20130110212125.84F071A44C@ld9781.wdf.sap.corp> In-Reply-To: <20130110212125.84F071A44C@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 14:51:01 -0800 Message-ID: <00a501cdef84$f7c72f00$e7558d00$@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: AQEUxl0+aS/g71kCLxLQIutrfQCZEJm1dyVw Content-Language: en-us X-Gm-Message-State: ALoCoQmGMwZ5WYYw7PrR769HiD278VL5tw1tiUBhUQ4paWAwy9Uu7F/+QUJYs85hhX9qhtyQT59g Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 10 Jan 2013 22:51:08 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, January 10, 2013 1:21 PM > To: Piyush Jain > Cc: mrex@sap.com; 'Stefan Santesson'; 'Peter Rybar'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Piyush Jain wrote: > > > > > > For completeness, the behaviour of the OCSP responder should be > > > well- defined even for requests that some think would be > > > spec-incompliant for an RP to send, because there are going to be > > > RPs that will do spec-incompliant things. > > > > [Piyush] I agree again. The question is what is that well-defined behavior? > > Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective. > > At the pure fomal level, you're correct that just having defined _any_ > behaviour would suffice to describe it as "well defined". > > But when just slightly beyond, OCSP does not exist for its own merit, it has a > specific purpose, and we *know* that RPs are going to infer (and then act > on) the OCSP response. [Piyush] You said before - "it is entirely irrelevant for the operation of the OCSP responder what motivates the RP doing what it does". So what is it - Is it relevant or not? > > We know that RPs / OCSP clients will either skip revocation checking or > fallback to using CRLs when they receive MALFORMED_REQUEST or > UNAUTHORIZED as the response, and in both cases, will end up considering > the certificate status for the certificate serial in question as "good". Which > means that both of these answers are useless for the intended purpose, > discouraging the RP from considering a certificiate status of a certificate with > the serial in question as "good". [Piyush] We also know that OCSP clients will check certificate issuance by verifying the signature. So they will never send a request for a certificate that was not issued. And making the universal claim that RPs treat all non-revoked responses as good is incorrect. There are RPs who implement 5280 correctly and reject the certificates whose status cannot be determined. > > > > > > > > Peter Rybar wrote: > > > > > > > > > > X.509 defines the reason code certificateHold as > > > > > 1) it may remain on the CRL; > > > > > 2) it may be replaced by a (final) revocation; > > > > > 3) it may be explicitly released; > > > > > > > > It is correct that a cert serial number that was on hold, may be > > released. > > > > > > > > > Peter's list is misleading to the point that I would call it incorrect. > > > > > > While there exists a ReasonCode "removeFromCRL(8)", this reason code > > > is strictly limited to "delta CRLs", and therefore MUST NOT appear > > > on base CRLs and consequently MUST NOT appear in OCSP responses. > > > > [Piyush] While I see no value of including removefromcrl in OCSP > > responses I'm surprised at how you arrive to that conclusion in the above > sentence. > > How is content of OCSP response related to that of CRL or delta CRL? > > It was and still is perfectly OK for OCSP responders to draw their knowledge > about certificate (serial) status from CRLs. > > http://tools.ietf.org/html/rfc2560#section-4.4.2 > > The rfc2560 update is not going to change that. > > However, an OCSP responder which would copy a status > "removeFromCRL(8)" > from a delta CRL into an OCSP response would be defective. > > > > > > > > > > > The requested cert serial number may actually be used in a future > > > > representing a real certificate. > > > > [Piyush] It is as likely as I growing wings and start flying in future. > > This is about avoiding the abusive potential. > > "certificateOnHold(8)" is an un-ambiguously temporary status assertion, > whereas a generic "revoked" is a final status assertion. > > > > > > > > So this is intentional and the whole purpose behind using the on > > > > hold reason. > > > > > [Piyush] The purpose is to support the hack of unissued certificates. > > Genuine RPs won't send request for such certificates. > > And it does not matter what you return to malicious clients. > > You're not looking at the complete picture. > > If you set up a local OCSP responder, it will be perfectly OK for such a > responder not only to source from CRLs, but alternatively to essentially > forward/proxy the OCSP request, and either cache and forward the > response cache and recreate an OCSP response with the local signature. [Piyush] It could but it would be incorrect. And none of the OCSP responder products that exist today work in the way you describe. You are talking about proxy responder re-signing response from another responder without establishing trust. Do we even need to discuss the security implications of this approach? > > In the latter case, when the original OCSP client only sent the issuer&serial in > the OCSP request, the local OCSP responder is a perfectly correct an honest > client, still it might be forwarding a request for a certificate serial without > having seen (let alone > verified) the certificate carrying that serial. [Piyush] I think it will suffice to say that you should not circumvent the trust model by putting a proxy in the middle. > > > -Martin From mrex@sap.com Thu Jan 10 15:53: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 E816D21F84D8 for ; Thu, 10 Jan 2013 15:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 dNHvNHcqsRpX for ; Thu, 10 Jan 2013 15:53:00 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1F21F847F for ; Thu, 10 Jan 2013 15:52:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0ANqtcF008312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 00:52:55 +0100 (MET) In-Reply-To: <009501cdef7a$c3b96c50$4b2c44f0$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 00:52:55 +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: <20130110235255.9A23D1A44B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 23:53:01 -0000 Piyush Jain wrote: > > > > > > > > > [Piyush] Relying parties trust certificates. > > > They do not trust certificate serial numbers. > > > > That is actually entirely irrelevant. We're discussing the OCSP protocol > > here (and to some extent CRLs), and these protocols are factually > > about status of certificate serial numbers, NOT certificates. > > [Piyush] I'm surprised by your interpretation of these specs. My simple > advice - don't trust the certificate if OCSP responder says it is good. > Make sure it chains to a trust anchor. Huh? You're just saying that certificate revocation checking is not worth bothering. I believe there are some folks on this list that do not agree and would like to improve certificate revocation checking so that less certs that are not supposed to be considered good will be reported as good to RPs that perform certificate revocation checking through OCSP. > > CA hash and serial combined is representation of the certificate. That is actually wrong. The octet string that _is_ the certificate is the only valid representation of the certificate. X.509/PKIX uses a (cryptgraphic) hash (plus a digital signature transform) (which isn't quite perfect, as we all know) to perform data integrity protection and data integrity authentication. When deciding whether to trust a certificate, that was received from a communication peer, we're already using a certificate (or ToBeSigned) hash to check data integrity and data origin, so it is OK when we use a certificate hash of at least the same strength for protocols like OCSP to identify the certificate, rather then conveying the certificate itself in full. Keeping in mind that OCSP itself also uses a cryptographic hash for data integrity protection and data origin authentication... > > > (which is exactly one of the security problems of CRLs and OCSP, for > > which this change is a partial remedy...). > > [Piyush] You allude to this problem again and again. Please lay out a use > case that captures the problem and tell us how this update addresses the > problem. CRLs are based on the absence of a negative status, so are pretty much a lost cause. OCSP, on the other hand, is at least about positive assertions. However, it currently fails to securely identify the certificate in the positive assertions, because the "good" response does not include a certificate hash from the CAs database of issued certs. > > > > The question to ask is - what is the status of the certificate, > > > > That is a question/decision inside the RP. Irrelevant to OCSP. > > [Piyush] I don't get it. RP uses OCSP to determine the status of a > certificate and it is irrelevant to OCSP? That is incorrect. The RP uses OCSP to determine the status of a certificate serial number, and infers from the absence of a negative status of the certificate serial number the status of the certificate. When the OCSP responder returns bad (certificateOnHold) for a "not issued" certificate, then it will not matter if the RP does not understand the subtle difference here. > > > > > I have not seen an OCSP client which determines the trustworthiness of > > > a certificate by sending an OCSP request without verifying that the > > > certificate is issued by the CA. According to the spec, you cannot > > > trust the responder if it is not issued by the same CA as the responder. > > > > You might want to update your Web Browser if yours really so old that it > > does not allow you to configure a local trusted OCSP responder ... ;-) > > [Piyush] Silly me - So I can assume that you support addition of text that > says that CA delegated responders should not issue extended revoked > responses.;) Huh? Definite NO. Currently, the CA key(!!) is the single point of failure, so the fix to the single-point-of-failure problem will consequently have to look like a delegated responder for backwards compatibility with the installed base of OCSP clients, but the OCSP signer cert will additionaly need a property that can not be faked by compromising the CA key (something that only updated OCSP clients will understand and check, of course -- that is regularly inevitable when fixing protocol shortcomings). > > > That OCSP responder can do that today. And even if we add a MUST NOT for > > this particular example into the spec, that OCSP responder can continue > > operating in this fashion, and there will be nothing that we can do about > > it. There is not IETF protocol SWAT team that will take down a service > > for an IETF protocol violation (if it existed, it would probably have > > to take down 99% of the internet...). > > [Piyush] We are agreeing on quite a few things here. So what is the need > for this update. OCSP responders can respond with revoked for non-issued or > fraudulently issued certificates today. There is not IETF protocol SWAT team > that will take down a service for an IETF protocol violation (if it existed, > it would probably have to take down 99% of the internet...). The IETF is a so-called "Standardization Organization", and rather that leaving it undefined and up to implementors how to convey the "not issued" status which some OCSP responders may be positively aware of, it is expected from the IETF, the maintainer of the OCSP protocol (rfc2560), to standardize how to convey this information. You do not have to donate your time to the effort, but I would like to ask you not to stop others from doing that work. > > > it really is, and always was, about the status of certificate > > serial numbers, not about the status of certs. > > [Piyush] I think you sincerely believe this. That is formally provable for the protocol specified in rfc2560. > > I guess we globally replace "certificate status" with "certificate serial > status". OR we could just improve OCSP to better live up to the expectations. Like adding the certificate hash from the CA cert issue log into the OCSP "good" responses. > > > > > [Piyush] On hold is just a reason code associated with revoked. > > > A responder can determine if the certificate is 'bad' or untrustworthy > > > if it is asked to perform validation under some context specified in > > > the request extension. > > > Responders are not needed to determine issuance > > > > (OCSP) Responders are need to convey certificate serial number status. > > Conveying "good" for a certificate serial number that is positively known > > to have never been issued would be stupid and wrong. > > [Piyush] Sure. How about UNAUTHORIZED or MALFORMED_REQUEST As explained in a previous reply, it would be entirely useless to standardize either of these for "not issued", because for most RPs in the installed base, it would have just the same bottom line effect as returning "good". > > > > > > > > > > and people have repeatedly asserted that fraudulently issued certs > > > cannot be addressed by OCSP in a secure way. > > > > This is the first step in standardizing how to report "non-issued" > > for a certificate serial number. > > [Piyush] A step that does not address any practical use cases. > > > You're misinterpreting the situation. For OCSP, this approach *IS* > > completely secure. > [Piyush] That's another bold claim without any associated facts. Just lay > out one use case and we can analyze it to see if the claim holds up > > > [Piyush] > > There is the problem that some of the bold/flawed assumptions of PKI(X) > > evaporate for certain kind of CA security breaches. > [Piyush] What flawed assumptions. There are security breaches and there are > procedures to address them. And some of the procedures require that CA be > revoked. What's wrong with that. X.509/PKIX does *NOT* have a procedure for dealing with a CA key compromise. The PKIX assumption is that it can not possibly happen. And if it happens anyway, the reaction is to "Nuke the PKI", a stereotype of the US military in hollywood movies (we don't know how to deal with it, so nuke it). What I'm calling for is reasonable plans for disaster recovery that will work in the real work. We reliably know that immediately nuking a large PKI did not work a single time in the real world, besides being a stupid idea in the first place. It is the same underlying idea as for the "Certificate Transparency" project. Accept as valid only certs that can be positively proven to exist (=have been issued), based on information that can be audited to be correct. Infering from the absence of a negative assertion (i.e. the concept of black-listing) has always been a pretty dumb idea security-wise. If online shops would be verifying credit cards by looking at paper-based CC-Number blacklist only, fraud would be skyrocketing. -Martin From piyush@ditenity.com Thu Jan 10 17:50:17 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 B942021F88EE for ; Thu, 10 Jan 2013 17:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 f6JTCVoTK0Bk for ; Thu, 10 Jan 2013 17:50:17 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4621F88E1 for ; Thu, 10 Jan 2013 17:50:16 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so1272048obb.26 for ; Thu, 10 Jan 2013 17:50:16 -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=gELq2FTWu/qr6U32GULhsT8kv66j96zBDFU+EOqCWpQ=; b=k6TY9xkZmZ7esd82XzIm1vYagM9wmmuUes3Qtwnrzekkx1Q7Yghh1Aswxiii2KjnaB 7UYVQzrzmmxuWYcl/hcUaDMcY3L87339z6w05m+OVQ8OPs3IpqS/DIgR/XqmqsLsNkZU 6r14n+KHzVROZkdOPmm8QcvXn66JwCQdqYjb3iisUzC0ikj+e6AeQ8NoSDjM9zoaekzA 2KuDUsymyoRw4j5Cra6jE28OSfEqIVg1u+9DESf/qmoJ3qa5g/5iudK/wDBmPrIpklG6 sjYk9QoAmLWVWxUHSWUFGpXUjlNZ+jCidPtP9ylZfTqE+DzctDevzokF1cSAnyohizUd sxFQ== X-Received: by 10.60.169.171 with SMTP id af11mr42911518oec.92.1357869016406; Thu, 10 Jan 2013 17:50:16 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ee14sm2549671obb.2.2013.01.10.17.50.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 17:50:15 -0800 (PST) From: "Piyush Jain" To: References: <009501cdef7a$c3b96c50$4b2c44f0$@ditenity.com> <20130110235255.9A23D1A44B@ld9781.wdf.sap.corp> In-Reply-To: <20130110235255.9A23D1A44B@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 17:50:12 -0800 Message-ID: <00bf01cdef9d$ffe9f8c0$ffbdea40$@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: AQJKI6QOd+Dd+iP/l44EbQTlETWwVZdK4tuQ Content-Language: en-us X-Gm-Message-State: ALoCoQkJg98a+Wy0mN5BraBuu7DVmhfL1YxjBmbhGwrJcfeTW2Kl5P7Si29jBrPLXlUNAyYyuOed Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 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, 11 Jan 2013 01:50:17 -0000 > Huh? You're just saying that certificate revocation checking is not worth > bothering. Nop. I'm saying is that revocation checking is not worth bothering if you have not done signature verification. > CRLs are based on the absence of a negative status, so are pretty much a lost > cause. > > OCSP, on the other hand, is at least about positive assertions. OCSP, at least as envisioned by original authors is functionally equivalent to CRLs. It was an oversight to have a 'good' status in the specification. It should've been 'not revoked'. From mrex@sap.com Thu Jan 10 18:23: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 BDB3921F8930 for ; Thu, 10 Jan 2013 18:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.147 X-Spam-Level: X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 wETIKeCYQQ5Q for ; Thu, 10 Jan 2013 18:23:10 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0A21F884F for ; Thu, 10 Jan 2013 18:23:09 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0B2N7v9025040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 03:23:07 +0100 (MET) In-Reply-To: <00a501cdef84$f7c72f00$e7558d00$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 03:23:06 +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: <20130111022306.F34BB1A44B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 02:23:11 -0000 Piyush Jain wrote: > > > > At the pure fomal level, you're correct that just having defined _any_ > > behaviour would suffice to describe it as "well defined". > > > > But when just slightly beyond, OCSP does not exist for its own merit, > > it has a specific purpose, and we *know* that RPs are going to infer > > (and then act on) the OCSP response. > > [Piyush] You said before - "it is entirely irrelevant for the operation of > the OCSP responder what motivates the RP doing what it does". > So what is it - Is it relevant or not? This is getting boring. At the protocol level, it is important that the protocol is well-defined for every possible situation, not just the situations that the inventors had in mind. In that respect, rfc2560 is defective. When fixing a protocol that can be formally proven to be defective, fixing it in a fashion that results in *DESIRED* behaviour is even more important than just making the spec formally provable correct. Formal logic is indifferent to whether the formally provable correct behaviour (with respect the a given specification) is sensible and desirable or stupid and not desirable. Consumers of a protocol and implementations thereof, on the other hand, typically do care about this difference. > > > > We know that RPs / OCSP clients will either skip revocation checking or > > fallback to using CRLs when they receive MALFORMED_REQUEST or > > UNAUTHORIZED as the response, and in both cases, will end up considering > > the certificate status for the certificate serial in question as "good". > > Which means that both of these answers are useless for the intended > > purpose, discouraging the RP from considering a certificiate status of a > > certificate with the serial in question as "good". > > [Piyush] We also know that OCSP clients will check certificate issuance by > verifying the signature. That statment is a proven logical fallacy. (colloquial "nonsense"). We all know that were some 200 certs created by hackers that would verify under the public DigiNotar CA which were never issued. And there was a CA certificate created by some researchers as a proof-of-concept which also was never issued, but the signature on that cert would verify under a public CA: http://www.win.tue.nl/hashclash/rogue-ca/ Btw. *NONE* of the RP software I know (MS-CryptoAPI, Firefox, OpenSSL, and ours) checks certificate issuance, for the simple reason that none of the existing protocols actually supports conveying proof-of-issuance. Chrome might be one of the first to check certificate issuance through the "Certificate Transparency" protocol, but that is currently outside of X.509/PKIX. So with respect to a PKIX concept of an RP, we would need to augment OCSP to convey the certificate hash from the CA issue log in an OCSP "good" SingleResponseExtension in order to enable updated PKIX-RPs to check certificate issuance. > > So they will never send a request for a certificate that was not issued. You seem to know very little about what RPs in the installed base are doing. What I know from discussions on IETF Mailing lists, there are RPs, which - given an untrusted leaf cert with an incomplete path, will silently perform forward AIA-caIssuers chasing during certificate path validation - will attempt to parallelile AIA-based OCSP lookups with certificate path validation And I'm pretty sure there is more dangerous behaviour out there in the installed base that I wouldn't think of in my wildest dreams. > > And making the universal claim that RPs treat all non-revoked responses as > good is incorrect. There are RPs who implement 5280 correctly and reject > the certificates whose status cannot be determined. "Implements 5280 correctly"? While I can see "must reject the certificate" in a few places in the certificate path validation algorithm in Section 6.1 of rfc5280, I am still searching for where in Section 6.3 of rfc5280 it says "an RP MUST reject the certificate when the revocation check returns with the cert_status UNDETERMINED". Btw. I'm also still searching for a requirement in rfc5280 that says "a compliant RP MUST perform certificate revocation checking". I was under the impression that both, whether to perform revocation checking at all, and what to do when the check returns cert_status UNDETERMINED is subject to local policy of the RP, and that soft-failing on OCSP lookup failures is actually the norm common RPs such as Web-Browsers, rather than the exception. > > > [Piyush] The purpose is to support the hack of unissued certificates. > > > Genuine RPs won't send request for such certificates. > > > And it does not matter what you return to malicious clients. > > > > You're not looking at the complete picture. > > > > If you set up a local OCSP responder, it will be perfectly OK for such a > > responder not only to source from CRLs, but alternatively to essentially > > forward/proxy the OCSP request, and either cache and forward the > > response cache and recreate an OCSP response with the local signature. > > > [Piyush] It could but it would be incorrect. Huh?? Could you please enlighten me which part of rfc2560 you believe would prohibit this? > > And none of the OCSP responder > products that exist today work in the way you describe. While I do not have any experience with OCSP responders myself, the Microsoft Online Responder Web proxy described here: http://technet.microsoft.com/en-us/library/cc731001.aspx appears to do just that. It is to be configured as local OCSP responder, will forward the RPs request to the real responder (local or public, I assume, depending on the request), and cache the response. While this particular implementation from Microsoft is conceptionally split into two components, the OCSP proxy itself does not need to (re-)sign the OCSP responses. But rfc2560 Section 4.2.2.2 (1) clearly makes it a valid implementation option that the OCSP proxy could re-sign instead of forwarding the OCSP response, e.g. to achive a coherent maximum caching of forwarded OCSP responses by local RPs, configurable centrally on the OCSP proxy. > > You are talking about proxy responder re-signing response from > another responder without establishing trust. Huh?? public CA responder (identified through AIA) ^ | v trusted local/organizational OCSP responder ^ | v local RP What do you mean by "without establishing trust", -- that does not exist in this picture, the basic usage scenario that involves a local OCSP responder. Besides "official" OCSP responders, there are _existing_ protocol extensions for OCSP request proxying. -Martin From mrex@sap.com Thu Jan 10 18:40:02 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 9BA8F21F8863 for ; Thu, 10 Jan 2013 18:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRPUzKmeAeyn for ; Thu, 10 Jan 2013 18:40:02 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C534321F884A for ; Thu, 10 Jan 2013 18:40:01 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0B2dqlm021261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 03:39:52 +0100 (MET) In-Reply-To: <00bf01cdef9d$ffe9f8c0$ffbdea40$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 03:39:52 +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: <20130111023952.94E131A44C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 02:40:02 -0000 Piyush Jain wrote: > > > > CRLs are based on the absence of a negative status, so are pretty > > much a lost cause. > > > > OCSP, on the other hand, is at least about positive assertions. > > OCSP, at least as envisioned by original authors is functionally > equivalent to CRLs. It was an oversight to have a 'good' status > in the specification. It should've been 'not revoked'. What may have been envisioned by the original authors is entirely irrelevant today. What has been standardized by thet IETF ~13 years ago, evidently as you can see from the published specification, and from a lack of an update or errata of the kind you seem to desire, is a positive assertion "good", decorated with the caveat that when lacking information about issuance (such as when feeding the OCSP responder on CRLs only), a "good" response might be erroneously returned for a certificate that, in fact, was never issued. The update currently under disussion is about enabling OCSP to actually and sensibly convey within the OCSP protocol, whether a certificate serial number refers to a certificate that is present on the CA cert issue log. And the choice is to convey the information in such a fashion, that it will cause the desired behaviour with very close to all of the installed base of RPs (rfc2560 OCSP clients). -Martin From piyush@ditenity.com Thu Jan 10 20:09: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 E500021F8A08 for ; Thu, 10 Jan 2013 20:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 acLk0M6iBi7m for ; Thu, 10 Jan 2013 20:09:24 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE73C21F88C7 for ; Thu, 10 Jan 2013 20:09:24 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id xn12so1330139obc.4 for ; Thu, 10 Jan 2013 20:09:24 -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=VT4u6SVd+RhssGJhD26J2qEBpdA5+1mv2w+eSPrxb7g=; b=ana1+u7E2ttzg0g64DW5BOwkEOcZa7dY2hXvdOOdlDWkWkGdpcGRf1c64SW2bJSLU8 qv8hCiOhXS/W4w0owV53drmotbmNdbd7zH96wBrMXBhdVDI7qwtPeYaBCUx/I7G66OYZ 7aIQh/2eFBlcaIPmFti/B8aPB+PHPSh1p/jFbsNjXJOwPj+zWIhU5XuOh1+kBMDv+r5e wEP/A8o1Y1MKfQCWNPk/O5QDGElzRPTOC9zI3OfBl90hL1O6F/Phrrm4yR3GIGkjldjd QGzPpMikqIIJCAkY5NNdqJS3mUvtrlRRAE1VqJ37gYru0mUwsXIA/WZDxxpq4SKFtFvb IxfA== X-Received: by 10.60.8.131 with SMTP id r3mr42873381oea.14.1357877363950; Thu, 10 Jan 2013 20:09: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 el2sm2802321obc.9.2013.01.10.20.09.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 20:09:23 -0800 (PST) From: "Piyush Jain" To: References: <00a501cdef84$f7c72f00$e7558d00$@ditenity.com> <20130111022306.F34BB1A44B@ld9781.wdf.sap.corp> In-Reply-To: <20130111022306.F34BB1A44B@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 20:09:18 -0800 Message-ID: <000001cdefb1$6e9ec080$4bdc4180$@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: AQEC9c/vg8o4o77aBDE2h+NgPFEWGpnZZgbw Content-Language: en-us X-Gm-Message-State: ALoCoQlVExaOtDpqDmRTgFBGI+kG5z9FV44iojSoDHvMyaumSCYTxA+XPLQbUZkygZxmHADgCZl8 Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 04:09:26 -0000 > That statment is a proven logical fallacy. (colloquial "nonsense"). Proven how? > We all know that were some 200 certs created by hackers that would verify > under the public DigiNotar CA which were never issued. There is a difference between fraudulently issued and non-issued. This is what 5280 says about such a scenario "On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If such a compromise is detected, all certificates issued to the compromised CA MUST be revoked, preventing services between its users and users of other CAs." > And there was a CA certificate created by some researchers as a proof-of- > concept which also was never issued, but the signature on that cert would > verify under a public CA: > > http://www.win.tue.nl/hashclash/rogue-ca/ It is addressed by adopting strong hash algorithms. But at least you have presented two cases where you think it is useful. So how does the 2560 update help address these issues? The fallacy in your approach is that one hand you are unwilling to put your trust in the signature created by a CA and on the other hand you are willing to put your trust in a responder that is signed by the same CA. > Btw. *NONE* of the RP software I know (MS-CryptoAPI, Firefox, OpenSSL, > and ours) checks certificate issuance, for the simple reason that none of the > existing protocols actually supports conveying proof-of-issuance." [Piyush] Once again, issuance is checked by verifying the signature on the certificate. If you disagree then let us know how you would verify that the cert that signed the response was "issued" by the CA > You seem to know very little about what RPs in the installed base are doing. > > What I know from discussions on IETF Mailing lists, there are RPs, which > - given an untrusted leaf cert with an incomplete path, > will silently perform forward AIA-caIssuers chasing during > certificate path validation [Piyush] And you have a proposal which would make these RPs secure? > - will attempt to parallelile AIA-based OCSP lookups with > certificate path validation > > And I'm pretty sure there is more dangerous behaviour out there in the > installed base that I wouldn't think of in my wildest dreams. > [Piyush] Sure. So you have a magic bullet to make these RPs secure? > "Implements 5280 correctly"? > > While I can see "must reject the certificate" in a few places in the certificate > path validation algorithm in Section 6.1 of rfc5280, I am still searching for > where in Section 6.3 of rfc5280 it says "an RP MUST reject the certificate > when the revocation check returns with the cert_status UNDETERMINED". > > Btw. I'm also still searching for a requirement in rfc5280 that says "a compliant > RP MUST perform certificate revocation checking". > [Piyush] 5280 section 6.1: This text describes an algorithm for X.509 path processing. A conforming implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm." 5280 section 6.1.3 The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (1) .... (2) ... (3) At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), by status information, or by out-of-band mechanisms. I think it is easy to deduce from above that if you cannot determine that certificate is "not revoked" you should reject the certificate. > I was under the impression that both, whether to perform revocation > checking at all, and what to do when the check returns cert_status > UNDETERMINED is subject to local policy of the RP, and that soft-failing on > OCSP lookup failures is actually the norm common RPs such as Web- > Browsers, rather than the exception. > [Piyush] Unfortunately, that's a myopic view. Browser's soft fail because they don't want to offend the user and unsuspecting users just hit continue on warning displayed on their browser window because they do not understand the warning. Browser vendors can afford to do so because of complete lack of accountability. PKI has presence outside the CAB community. In enterprise deployments, depending on the application, such behavior would be completely unacceptable. > > > [Piyush] It could but it would be incorrect. > > Huh?? > > Could you please enlighten me which part of rfc2560 you believe would > prohibit this? > [Piyush] Common sense I would guess. If the proxy is re-signing the response it should ensure that it can trust the response first. Otherwise I can route you AIA to my rogue responder and have your proxy responder attest my rogue response. > > > > > And none of the OCSP responder > > products that exist today work in the way you describe. > > While I do not have any experience with OCSP responders myself, the > Microsoft Online Responder Web proxy described here: > > http://technet.microsoft.com/en-us/library/cc731001.aspx > > appears to do just that. It is to be configured as local OCSP responder, will > forward the RPs request to the real responder (local or public, I assume, > depending on the request), and cache the response. > > While this particular implementation from Microsoft is conceptionally split > into two components, the OCSP proxy itself does not need to (re-)sign the > OCSP responses. [Piyush] Sane behavior. Microsoft got this right :) But rfc2560 Section 4.2.2.2 (1) clearly makes it a valid > implementation option that the OCSP proxy could re-sign instead of > forwarding the OCSP response, e.g. to achive a coherent maximum caching > of forwarded OCSP responses by local RPs, configurable centrally on the > OCSP proxy. > [Piyush] Sure it could sign. After making sure that the response is signed by a responder that is authorized to provide response for the payload certificate. > > > > You are talking about proxy responder re-signing response from another > > responder without establishing trust. > > Huh?? > > public CA responder (identified through AIA) > ^ > | > v > trusted local/organizational OCSP responder > ^ > | > v > local RP > [Piyush] Identified through AIA is fine but it does not obviate the need to ensure that it is authorized to provide response for the certificate in question > What do you mean by "without establishing trust", > -- that does not exist in this picture, the basic usage scenario that involves a > local OCSP responder. [Piyush] Simple local ocsp responder needs to make sure that public CA responder is authorized to issue response for the payload certificate. The fact that it was reached through the AIA does not make it trustworthy. -Piyush From mrex@sap.com Thu Jan 10 22:36: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 E1CF121F89E9 for ; Thu, 10 Jan 2013 22:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxjaPyWawgTa for ; Thu, 10 Jan 2013 22:36:24 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F386E21F87AB for ; Thu, 10 Jan 2013 22:36:23 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0B6aKf9007928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 07:36:20 +0100 (MET) In-Reply-To: <000001cdefb1$6e9ec080$4bdc4180$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 07:36:20 +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: <20130111063620.62DDA1A449@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 06:36:25 -0000 I don't really see any convergence of this discussion, and I'm lacking time and endurance to continue. Piyush Jain wrote: > > > "Implements 5280 correctly"? > > > > While I can see "must reject the certificate" in a few places in the > > certificate path validation algorithm in Section 6.1 of rfc5280, > > I am still searching for where in Section 6.3 of rfc5280 it says > > "an RP MUST reject the certificate when the revocation check returns > > with the cert_status UNDETERMINED". > > > > Btw. I'm also still searching for a requirement in rfc5280 that says > > "a compliant RP MUST perform certificate revocation checking". > > [Piyush] > 5280 section 6.1: > This text describes an algorithm for X.509 path processing. A conforming > implementation MUST include an X.509 path processing procedure that is > functionally equivalent to the external behavior of this algorithm." > 5280 section 6.1.3 > The basic path processing actions to be performed for certificate i (for > all i in [1..n]) are listed below. > (a) Verify the basic certificate information. The certificate MUST > satisfy each of the following: > (1) .... > (2) ... > (3) At the current time, the certificate is not revoked. This may > be determined by obtaining the appropriate CRL (Section 6.3), by status > information, or by out-of-band mechanisms. > > I think it is easy to deduce from above that if you cannot determine that > certificate is "not revoked" you should reject the certificate. You seem to have missed the important parts in the text you quoted. All that "the certificate is not revoked" means, is that your RP does not have positive proof of the revocation. The "This may be determined ... or by out-of-band mechanisms.", means, that an RP, who does neither support CRLs nor OCSP (or has them disabled), and only an implementation-defined "out-of-band mechanism", that consists of "Revocation by manual out-of-band means on the granularity of trust anchors" will actually be _compliant_ with RFC5280. While this might not be what *YOU* want, but it definitely is what rfc5280 explicitly permits. > > But rfc2560 Section 4.2.2.2 (1) clearly makes it a valid > > implementation option that the OCSP proxy could re-sign instead of > > forwarding the OCSP response, e.g. to achive a coherent maximum caching > > of forwarded OCSP responses by local RPs, configurable centrally on the > > OCSP proxy. > > [Piyush] Sure it could sign. After making sure that the response is signed > by a responder that is authorized to provide response for the payload > certificate. This is bordering on silliness. Honestly, why wouldn't it? Who would be so stupid to write **TWO** seperate OCSP clients, one that implements rfc2560 correctly (including section 4.2.2.2 1/2/3) and a goofed one that lacks section 4.2.2.2 1/2/3, and then use the goofed one in the proxy, rather than using the same rfc2560-client everywhere? An other than CRLs, where it is undefined (explicitly declared out-of-scope by rfc5280) how to obtain the CRL signer cert if the CRL is not signed with the same CA key than the cert under investigation, OCSP has a standardized carry-on for the OCSP signer cert (chain), in case that the OCSP response is not signed by the cert signer key itself. -Martin From mrex@sap.com Thu Jan 10 23:00: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 A140221F884F for ; Thu, 10 Jan 2013 23:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.155 X-Spam-Level: X-Spam-Status: No, score=-10.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 2aW+Lo2eXG6i for ; Thu, 10 Jan 2013 23:00:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE73821F87A3 for ; Thu, 10 Jan 2013 23:00:47 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0B70iCA022878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 08:00:44 +0100 (MET) In-Reply-To: <008a01cdef72$166e4cd0$434ae670$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 08:00:44 +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: <20130111070044.5385A1A449@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:00:49 -0000 Piyush Jain wrote: > > Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective. Are you aware of rfc-2560 Section 2.7? 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. As you can see, even rfc2560 has been suggesting all the time, that when the OCSP responder is aware of a CA key compromise, it MAY return a revoked response as a safety precaution for cert serials that are suspect to (or even positively known to) not be validly issued certs. This MAY implies "at the discretion of the responder", and includes selectively returning "revoked", e.g. if it wasn't a complete CA compromise, but only a fraudulent cert creation for which CA issue records may have been destroyed -- so the existence of fraudulent certs could be invisible to any audits. Du to the lack of issue records, it is also not possible to revoke such certs in the X.509 sense, since it is unknown how many there are, what serials they carry, and whether they share the serials of "innocent" certs that exist on the CA cert issue record. -Martin From piyush@ditenity.com Thu Jan 10 23:04: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 019D221F8A89 for ; Thu, 10 Jan 2013 23:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IptcMUrxYb7O for ; Thu, 10 Jan 2013 23:04:33 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id D83B521F8A3E for ; Thu, 10 Jan 2013 23:04:32 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id k14so1506743oag.14 for ; Thu, 10 Jan 2013 23:04:32 -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=0eV2wv7MtuuyLVHhSTmtRouJKec2Pgo8etuSrfL3rkk=; b=DVsgfcgLlLXJz766d1Wqs48mJMcR8KzeSfExSNMRORsNV4vZKOnjHviFhDegRM4YXJ g/cgR3cnzj+DeJL/EZxHP+CiOm9tYJImMN//mKTfWtEjQL+2L+B11VQudaqHlYNGLxOg IvMwcTqR7ouW0cRmJNF+sR1euoJRPREzYUMJgepuVMzZwIqCfADfsl+FwC5bXhLtratP W7LElOLqS1r3sqBDhJM2mlGF36i0S6z/SF4DbcGFsq5HJKpQUpNxotYC9oFkjYK3WO4U /leosszEhsxKcwIoLAUQqXlg+BJb1oV3RP+USDs0MqKBKiM0/iUMNm+Eb1u/i2nU6QPA cYVg== X-Received: by 10.60.171.146 with SMTP id au18mr42748142oec.108.1357887871981; Thu, 10 Jan 2013 23:04:31 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vk8sm3049913obb.19.2013.01.10.23.04.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jan 2013 23:04:31 -0800 (PST) From: "Piyush Jain" To: References: <000001cdefb1$6e9ec080$4bdc4180$@ditenity.com> <20130111063620.62DDA1A449@ld9781.wdf.sap.corp> In-Reply-To: <20130111063620.62DDA1A449@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 23:04:27 -0800 Message-ID: <002001cdefc9$e6075e80$b2161b80$@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: AQJtj0Cgx0IRheEneMxKz5HBqn7ua5cEcIOQ Content-Language: en-us X-Gm-Message-State: ALoCoQnoH+0BXEUxT5ixdznVI931F4dIUyqNhc+r19RENveysBx6Rqa3dv8fHPb33jVdbq+9875p Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 07:04:34 -0000 >Honestly, why wouldn't it? >Who would be so stupid to write **TWO** seperate OCSP clients, one that implements rfc2560 correctly (including section 4.2.2.2 1/2/3) and a goofed one that lacks section 4.2.2.2 1/2/3, and then use the goofed >one in the proxy, rather than using the same rfc2560-client everywhere? [Piyush] Glad we are on same page now. This what you quoted before: " You're not looking at the complete picture. If you set up a local OCSP responder, it will be perfectly OK for such a responder not only to source from CRLs, but alternatively to essentially forward/proxy the OCSP request, and either cache and forward the response cache and recreate an OCSP response with the local signature. In the latter case, when the original OCSP client only sent the issuer&serial in the OCSP request, the local OCSP responder is a perfectly correct an honest client, still it might be forwarding a request for a certificate serial without having seen (let alone verified) the certificate carrying that serial." Which seemed to indicate that local OCSP responder re-signs the response without having all the information (since it does not have access to the cert) to verify the response from the public CA responder. You came up with the scenario to refute my assertion that genuine OCSP clients need to verify signature (issuance) before sending an OCSP response. > I don't really see any convergence of this discussion, and I'm lacking time and > endurance to continue. [Piyush] I agree - too much flip flop. I'll let others chime in. From mrex@sap.com Fri Jan 11 00:03: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 6668221F8949 for ; Fri, 11 Jan 2013 00:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ8Ul4D1wAUX for ; Fri, 11 Jan 2013 00:03:26 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 389A721F88BD for ; Fri, 11 Jan 2013 00:03:25 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0B83Cdh002748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 09:03:12 +0100 (MET) In-Reply-To: <002001cdefc9$e6075e80$b2161b80$@ditenity.com> To: Piyush Jain Date: Fri, 11 Jan 2013 09:03:12 +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: <20130111080312.0ED361A450@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:03:27 -0000 Piyush Jain wrote: > > > >Honestly, why wouldn't it? > >Who would be so stupid to write **TWO** seperate OCSP clients, one that > > implements rfc2560 correctly (including section 4.2.2.2 1/2/3) and a goofed > one that lacks section 4.2.2.2 1/2/3, and then use the goofed >one in the > proxy, rather than using the same rfc2560-client everywhere? > [Piyush] Glad we are on same page now. > > This what you quoted before: > " You're not looking at the complete picture. > If you set up a local OCSP responder, it will be perfectly OK for such a > responder not only to source from CRLs, but alternatively to essentially > forward/proxy the OCSP request, and either cache and forward the response > cache and recreate an OCSP response with the local signature. In the latter > case, when the original OCSP client only sent the issuer&serial in the OCSP > request, the local OCSP responder is a perfectly correct an honest client, > still it might be forwarding a request for a certificate serial without > having seen (let alone verified) the certificate carrying that serial." > > Which seemed to indicate that local OCSP responder re-signs the response > without having all the information (since it does not have access to the > cert) to verify the response from the public CA responder. The cert for which the status is requested would actually be pretty useless for verifying the signature on the OCSP response. It will require the _CA_cert_ that signed the cert for which the status is requested in order to verify the OCSP response. While both, proxying and re-signing OCSP responses aren't possible in a "fully dynamic" fashion, both should be possible for explicitly configured issuers, where the proxy already knows the URL to the CA's OCSP responder and has the necessary CA cert, and therefore can recognize the issuerNameHash and issuerKeyHash in the CertID of the OCSP request, as well as verify the OCSP response. Under these conditions, the actual cert for whose serial the status is requested, seems entirely unnecessary. Are any common OCSP clients actually including the cert for which they're requesting the status? My Firefox doesn't seem to send it (says wireshark), although I don't have a local OCSP responder to see whether this makes a difference. For reference, the relevant OCSP request contents from rfc2560: Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } -Martin From stefan@aaa-sec.com Fri Jan 11 02:24: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 C5B7321F87FE for ; Fri, 11 Jan 2013 02:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.78 X-Spam-Level: X-Spam-Status: No, score=-101.78 tagged_above=-999 required=5 tests=[AWL=0.469, 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 FWa0UyQ-zz3H for ; Fri, 11 Jan 2013 02:24:27 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3321F883A for ; Fri, 11 Jan 2013 02:24:26 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CA6341E2CC41 for ; Fri, 11 Jan 2013 11:24:24 +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 W1b15TlJV4pf for ; Fri, 11 Jan 2013 11:24:22 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 152501E2CC36 for ; Fri, 11 Jan 2013 11:24:21 +0100 (CET) Received: (qmail 74704 invoked from network); 11 Jan 2013 10:24:18 -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 ; 11 Jan 2013 10:24:18 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 11:24:19 +0100 From: Stefan Santesson To: , Piyush Jain Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <20130110212125.84F071A44C@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 10:24:28 -0000 On 1/10/13 10:21 PM, "Martin Rex" wrote: >> >> > The requested cert serial number may actually be used in a future >> > representing a real certificate. >[Piyush] It is as likely as I growing wings and start flying in future. It feels like you are not reading the posts here. As said numerous times before, If the CA is using sequential serial number assignments, I can make it 100% sure that this WILL happen. If I just got a cert with serial number 1000 from that CA, and immediately sends an OCSP request for cert 1001, then I would get a revoked response if the proposed update was implemented. Next time that CA issues a cert, it will have serial number 1001. Random serial number assignment with high entropy avoids this, but that is not mandated. /Stefan From stefan@aaa-sec.com Fri Jan 11 02:35: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 E7E7B21F8717 for ; Fri, 11 Jan 2013 02:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=0.402, 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 O6urhN9EFdtX for ; Fri, 11 Jan 2013 02:35:48 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 44E1521F8576 for ; Fri, 11 Jan 2013 02:35:48 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0E2B41E2CA54 for ; Fri, 11 Jan 2013 11:35: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 cvkTHDWdgk9R for ; Fri, 11 Jan 2013 11:35:45 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C04C91E2C8A4 for ; Fri, 11 Jan 2013 11:35:45 +0100 (CET) Received: (qmail 36475 invoked from network); 11 Jan 2013 10:35:45 -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 ; 11 Jan 2013 10:35:45 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 11:35:46 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <00a501cdef84$f7c72f00$e7558d00$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 10:35:49 -0000 On 1/10/13 11:51 PM, "Piyush Jain" wrote: >[Piyush] We also know that OCSP clients will check certificate issuance by >verifying the signature. So they will never send a request for a >certificate >that was not issued. No, the OCSP responder has no way to know this. Attackers can do this at will at any time if they find any reason to do so. The client may even have a bug, using a flawed mechanism to extract the serial number form cert after signature validation, causing it to ask status for the wrong cert serial number. Yes, that is hypothetical and our task is not to fix that, but the point is, there might be any reason unknown to the OCSP responder that could cause an OCSP request for a non-existing cert serial number. We are simply dealing with this on a protocol level, allowing the OCSP responder to respond to such request in a reasonable way, without even wandering about the reason that caused the client to do such request. /Stefan From stefan@aaa-sec.com Fri Jan 11 02:59:51 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 AEDA721F8843 for ; Fri, 11 Jan 2013 02:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=0.352, 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 o9V6SxKkK4sm for ; Fri, 11 Jan 2013 02:59:50 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 72A1B21F8795 for ; Fri, 11 Jan 2013 02:59:49 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2E9941E27336 for ; Fri, 11 Jan 2013 11:59: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 eO7AP9Vml-mW for ; Fri, 11 Jan 2013 11:59:48 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 599CA1E27F7F for ; Fri, 11 Jan 2013 11:59:48 +0100 (CET) Received: (qmail 54741 invoked from network); 11 Jan 2013 10:59:48 -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 ; 11 Jan 2013 10:59:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 11:59:50 +0100 From: Stefan Santesson To: , Piyush Jain Message-ID: Thread-Topic: [pkix] Review of 2560-bis draft 8 In-Reply-To: <20130110191806.0BB171A44B@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Review of 2560-bis draft 8 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, 11 Jan 2013 10:59:51 -0000 +1 To Martin's post here. Well put. Piyush. This discussion seems to go nowhere. It seems to have gotten to the point where you can't even acknowledge facts, because they don't support your view of the world. /Stefan On 1/10/13 8:18 PM, "Martin Rex" wrote: >Piyush Jain wrote: >> >> Stefan Santesson wrote: >> > >> > Taking any random certificate serial number in the context of a CA. >> > How can that serial number have any status other than: >> > >> > 1) issued and not revoked. >> > 2) issued and revoked (or currently on hold). >> > 3) never issued by this CA. > >Exactly. > > >> >> [Piyush] Relying parties trust certificates. >> They do not trust certificate serial numbers. > >That is actually entirely irrelevant. We're discussing the >OCSP protocol here (and to some extent CRLs), and these protocols are >factually about status of certificate serial numbers, NOT certificates. > >(which is exactly one of the security problems of CRLs and OCSP, > for which this change is a partial remedy...). > > >> >> The question to ask is - what is the status of the certificate, > >That is a question/decision inside the RP. Irrelevant to OCSP. > > >> >> not what is the status of a certificate serial number. > >CRLs and OCSP (the latter in its basic form), are not about certs, >they're only about certificate serial numbers. > >PKIX unfortunately has the bad habit of drawing bold conclusions >from the status of certificate serial numbers. > > >> >> "Never issued" is not a status of the certificate > >It is the status of a certificate serial number. >OCSP is about the status of certificate serial numbers. > > >> >> and RPs do not need responders to determine issuance. > >The OCSP responder, as well as the OCSP protocol, do not care at all, >about motivations of RPs. > > >> >> I have not seen an OCSP client which determines the trustworthiness of a >> certificate by sending an OCSP request without verifying that the >> certificate is issued by the CA. According to the spec, you cannot >>trust the >> responder if it is not issued by the same CA as the responder. > >You might want to update your Web Browser if yours really so old that >it does not allow you to configure a local trusted OCSP responder ... ;-) > > >> >> > This seem to be a fundamental unambiguous factual basic division of >>the >> > possible state of a serial number that is beyond question. > >+1 > > >> >> [Piyush] Think of a RP which sends a status request a certificate and >> includes a request extension to check if the bank account associated >>with >> the cert has at least 100 dollars. >> Failing this check the responder could return revoked (which implies bad >> according to this new update) > >That OCSP responder can do that today. And even if we add a >MUST NOT for this particular example into the spec, that OCSP responder >can continue operating in this fashion, and there will be nothing >that we can do about it. There is not IETF protocol SWAT team that >will take down a service for an IETF protocol violation (if it existed, >it would probably have to take down 99% of the internet...). > > >> >> My personal preference is to limit OCSP for just revocation status >>checks >> and communicate additional state information through extensions, as >> originally envisioned. > >You can continue doing that in _your_ RPs and _your_ OCSP responders. >This update is not going to interfere with what you're doing in any way. > > >> >> However, if you are extending the meaning of revoked, allow it for any >> negative proof and require that meaning of revoked (if overridden) is >> communicated through a new OID in the extended revoked extension. >> This spec does not need to go into the details of what those overridden >> negative proofs could be. > > >It's my impression that you're misunderstanding the OCSP protocol. >Although the expanded name is "Online Certificate Status Protocol", >it really is, and always was, about the status of certificate serial >numbers, not about the status of certs. > >Any other "negatives" would have to be new ReasonCode-s to be added >to X.509. > > > > >> >> > Then of course you can sub-divide each category into further >>divisions, >> > but every possible serial number will always fall into exactly one of >> > these categories. >> > The Responder may not know which category a serial number belongs to >> > (may just know whether it belongs to 2) or not), and in such case, the >> > discussed update is of no relevance to them. > >+1 > >> > >> > To introduce "Bad" as a reason for responding revoked, or to be more >> > granular than this basic division, scares me, because there is no end >>to >> > its potential complexity and ambiguity. > >+1 > >> > I'm not against the community going further in giving more granular >> > information, but I'm reluctant to do it within this update. > >+1 > >> >> [Piyush] That is why this update should just allow for changing the >>meaning >> of revoked through single response extensions and let other communities >> define and use those extensions. >> The topic of "not issued" should not even feature in the main OCSP >> specification. > >You're ~13 years late. "not issued" is *already* part of rfc2560: > > >quoting from rfc2560: > > The "good" state indicates a positive response to the status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued > >This update is about fixing an inconsistency in rfc2560. > > >> >> [Piyush] On hold is just a reason code associated with revoked. >> A responder can determine if the certificate is 'bad' or untrustworthy >>if it >> is asked to perform validation under some context specified in the >>request >> extension. >> Responders are not needed to determine issuance > >(OCSP) Responders are need to convey certificate serial number status. >Conveying "good" for a certificate serial number that is positively >known to have never been issued would be stupid and wrong. > > >> >> and people have repeatedly asserted that fraudulently issued certs >> cannot be addressed by OCSP in a secure way. > >This is the first step in standardizing how to report "non-issued" >for a certificate serial number. > >You're misinterpreting the situation. For OCSP, this approach *IS* >completely secure. > >There is the problem that some of the bold/flawed assumptions of PKI(X) >evaporate for certain kind of CA security breaches. But that could >be addressed by updating OCSP even further, eliminating the single >point of failure CA cert that is implied by OCSP AIA in the leaf cert. > > >> > What I feel less sure about is wether the extension should go into >> > responseExtensions or into singleExtensions. There are pros and cons >>with >> > both. >> >> [Piyush] Depends on what it indicates. If it is responder capability it >> should be a response extension that should be sent with every response. >>If >> it is about overloading the meaning of revoked it should be a single >> response extension sent only with revoked status where the meaning has >>been >> changed. > >I agree with that determination. > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Jan 11 04:55: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 3DC4C21F884F for ; Fri, 11 Jan 2013 04:55:59 -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 M1q1raF5uppM for ; Fri, 11 Jan 2013 04:55:56 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B021F8825 for ; Fri, 11 Jan 2013 04:55:55 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 0DF971D01B for ; Fri, 11 Jan 2013 13:55:54 +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 2013011113555253-10845 ; Fri, 11 Jan 2013 13:55:52 +0100 Message-ID: <50F00BD4.2060302@bull.net> Date: Fri, 11 Jan 2013 13:55:48 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/01/2013 13:55:52, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/01/2013 13:55:53, Serialize complete at 11/01/2013 13:55:53 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------050507050807010708020307" Subject: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 12:55:59 -0000 This is a multi-part message in MIME format. --------------050507050807010708020307 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed To the list The purpose of this email is to provide replacement text and its rational related to the topic currently called "non-issued certificates". First of all, speaking of non-issued certificate is misleading. The certificate may also have been issued by the CA, but irregularly because the RA was attacked and thus the certificate was indeed issued by the CA. So either the certificate has not been issued or has been irregularly issued (either by the CA or someone else). Secondly, RFC 5280 states: CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries. The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment on that reason code. Depending of the content of the signature policy, these applications may "wait and come back later" to see if there is a change in the revocation status. That change will never happen if the certificate has not been regularly issued. It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. :-) The current definition of CRLReason within RFC 5280 is: CRLReason ::= ENUMERATED { unspecified(0), keyCompromise(1), cACompromise(2), affiliationChanged(3), superseded(4), cessationOfOperation(5), certificateHold(6), -- value 7 is not used removeFromCRL(8), privilegeWithdrawn(9), aACompromise(10) } Rather than importing CRLReason from RFC 5280, we can define RevocationReason locally, consistent with CRLReason with one more bit which will be specific to OCSP. Anyway, we need to redefine the ASN.1 module, since the syntax of nonce had been omitted and must be added. This changes the meaning of the revoked reason in the following way: temporary revocation will apply for two reason code rather than one: certificateHold(6), notIssuedOrIrregularlyIssued(7), Note that the proposed new "extended revoked definition response extension" is not necessary anymore. Why do not make things simpler, when they can be simpler ? :-) This leads to the following replacement: OLD: 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. NEW: The "revoked" state indicates that the certificate has been revoked, either permanently or temporarily (i.e. certificateHold or notIssuedOrIrregularlyIssued). In particular, this state MAY be returned if the responder knows that currently the serial number from the requested certificate has not been used by the CA to issue a certificate or has been used irregularly to issue a certificate. 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. The Note above will allow people that do not have followed the discussion on the PKIX mailing list to understand why we have chosen "revoked" rather than "unknown", which would have been more natural. This leads to another change, since the following sentence is not English, it uses the word "never" which is inappropriate and omits to take into consideration certificates that have been irregularly issued: OLD: o Section 2.2 extends the use of the "revoked" response to allow this response status certificates that has never been issued. NEW: o Section 2.2 extends the use of the "revoked" response to also allow this response status either for certificates that have notbeen issued or that have been irregularly issued. The above arguments lead to other changes. The text copied below, does not follow the order of the ASN.1 syntax and should be aligned with the above proposed text. OLD: 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. NEW: When a responder responds revoked to a status request for a serial number which has not been used by the CA or used irregularly to issue a certificate, the responder MUST also: - specify the revocation date January 1, 1970, - provide the RevocationReason : notIssuedOrIrregularlyIssued (7). and also: OLD: 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. NEW: This section should be deleted. Denis --------------050507050807010708020307 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1 To the list

The purpose of this email is to provide replacement text and its rational related to the topic currently
called “non-issued certificates”.


First of all, speaking of non-issued certificate is misleading. The certificate may also have been issued 
by the CA, but irregularly because the RA was attacked and thus the certificate was indeed issued by the CA. 
So either the certificate has not been issued or has been irregularly issued (either by the CA or someone else).
 
Secondly, RFC 5280 states:
 

   CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries.

 
The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold 
as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment 
on that reason code. Depending of the content of the signature policy, these applications may “wait and 
come back later” to see if there is a change in the revocation status. That change will never happen 
if the certificate has not been regularly issued.
 
It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.
 
The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. 
 
:-)
 
The current definition of CRLReason within RFC 5280 is:
 

   CRLReason ::= ENUMERATED {

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

             -- value 7 is not used

        removeFromCRL           (8),

        privilegeWithdrawn      (9),

        aACompromise           (10) }

 
Rather than importing CRLReason from RFC 5280, we can define RevocationReason locally, consistent with CRLReason with one more bit 
which will be specific to OCSP. Anyway, we need to redefine the ASN.1 module, since the syntax of nonce had been omitted and must be added.
 
This changes the meaning of the revoked reason in the following way: 
temporary revocation will apply for two reason code rather than one:
 

        certificateHold               (6),

        notIssuedOrIrregularlyIssued  (7),

 

Note that the proposed new "extended revoked definition response extension" is not necessary anymore.

Why do not make things simpler, when they can be simpler ?  :-)
 
This leads to the following replacement:
 

OLD:

   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. 
 

NEW:

 

   The "revoked" state indicates that the certificate has been revoked,
   either permanently or temporarily (i.e. certificateHold or 
   notIssuedOrIrregularlyIssued).  In particular, this state MAY be 
   returned if the responder knows that currently the serial number 
   from the requested certificate has not been used by the CA to issue 
   a certificate or has been used irregularly to issue a certificate.
 
 
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. 
 
 
The Note above will allow people that do not have followed the discussion on the PKIX mailing list 
to understand why we have chosen “revoked” rather than “unknown”, which would have been more natural.
 
This leads to another change, since the following sentence is not English, it uses the word "never"
which is inappropriate and omits to take into consideration certificates that have been irregularly issued:
 

OLD: 

      o Section 2.2 extends the use of the "revoked" response to allow
         this response status certificates that has never been issued.
 
NEW:
 
      o Section 2.2 extends the use of the "revoked" response to also 
        allow this response status either for certificates that have 
        not been issued or that have been irregularly issued.
 
The above arguments lead to other changes. The text copied below, does not follow the order of the ASN.1 syntax 
and should be aligned with the above proposed text.


OLD:


   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.

NEW:


   When a responder responds revoked to a status request for a serial 
   number which has not been used by the CA or used irregularly to issue 
   a certificate, the responder MUST also:
 
    - specify the revocation date January 1, 1970,
 
    - provide the RevocationReason : notIssuedOrIrregularlyIssued (7).
 
and also:


OLD:

      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.

NEW:


This section should be deleted.

 

Denis
--------------050507050807010708020307-- From eabalea@gmail.com Fri Jan 11 06:00: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 9351D21F8919 for ; Fri, 11 Jan 2013 06:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UWtGTTzvf9U for ; Fri, 11 Jan 2013 06:00:21 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id C542D21F890D for ; Fri, 11 Jan 2013 06:00:20 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id d16so1424431vcd.19 for ; Fri, 11 Jan 2013 06:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N2f1XNeTwfU/A4jM7c+jBypbf7qAVvw1gTUz/u6Wj+Q=; b=xmQ1s/zU6xCZt9MJS5/jNDskRC/fh5NPt4e0hlsFJwCqF1GUXJYS17Kro6ECyPArlR cU9pg7BSHmAubvQnHuKZ0xXMj+OdGkrcN810mVvSvJZQuo3XcGN3vTA8+9crptOK+QMI PU26KPM5T7BVvpwck+V21bXyeEt1YJdMSIwaN8iockwT4CJydY8CirYjTsQcViI0jIAC YusJ3o8VTPy5tIygSJkvuWpqOtu3pArlMxTZA1DgGpA0ARJ2EfzCtGG3bF1qEXmj5rLp fwIvXzI18i3i5P8K9/E9jskYBAeEnEgUVBG8Gb2Y2Li+L5yPMFSIDdbVZW5TPxjCUA0R Xnbg== MIME-Version: 1.0 Received: by 10.59.11.67 with SMTP id eg3mr97211814ved.31.1357912819894; Fri, 11 Jan 2013 06:00:19 -0800 (PST) Received: by 10.52.69.44 with HTTP; Fri, 11 Jan 2013 06:00:19 -0800 (PST) In-Reply-To: <50F00BD4.2060302@bull.net> References: <50F00BD4.2060302@bull.net> Date: Fri, 11 Jan 2013 15:00:19 +0100 Message-ID: From: Erwann Abalea To: Denis Pinkas Content-Type: multipart/alternative; boundary=047d7bf0ec724407f204d303b768 Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 14:00:21 -0000 --047d7bf0ec724407f204d303b768 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/1/11 Denis Pinkas > > The re-use of onhold reason code is not meaningful, because it does not c= orrespond to the meaning of onhold **** > > as it is used today. Some applications dealing with electronic signatures= are already applying a specific treatment **** > > on that reason code. Depending of the content of the signature policy, th= ese applications may =E2=80=9Cwait and **** > > come back later=E2=80=9D to see if there is a change in the revocation st= atus. That change will never happen **** > > if the certificate has not been regularly issued.******** > > ** ****** > > It would be more appropriate to use a specific reason code that will only= appear in OCSP Responses, and never in CRLs.******** > > ** ****** > > The authors of RFC 5280 were very wise, because that have reserved bit 7 = for a purpose that is not supported in CRLs. > > If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;) --=20 Erwann. --047d7bf0ec724407f204d303b768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2013/1/11 Denis Pinkas <= ;denis.pinkas@bu= ll.net>
=20 =20 =20 

The re-use of onhold reason code is not meani=
ngful, because it does not correspond to the meaning of onhold 
as it is used today. Some applications dealin=
g with electronic signatures are already applying a specific treatment <=
/u>
on that reason code. Depending of the content=
 of the signature policy, these applications may =E2=80=9Cwait and <=
u>
come back later=E2=80=9D to see if there is a=
 change in the revocation status. That change will never happen <=
/u>
if the certificate has not been regularly iss=
ued.
=C2=A0
    
It would be more appropriate to use a specifi=
c reason code that will only appear in OCSP Responses, and never in CRLs.

    
=C2=A0
    
The authors of RFC 5280 were very wise, becau=
se that have reserved bit 7 for a purpose that is not supported in CRLs. =C2=A0

If you're talking about bit instead of enumerated value,= then you're talking about the "ReasonFlags" definition that = is used in cRLDistributionPoints extension instead of the "CRLReason&q= uot; definition used to indicate the revocation reason. And this "Reas= onFlags" bit string already uses bit 7 ;)

--
Erwann. --047d7bf0ec724407f204d303b768-- From prvs=0723c6ed50=rybar@nbusr.sk Fri Jan 11 06:38: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 68D1621F87F5 for ; Fri, 11 Jan 2013 06:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 a8OeB03XMavE for ; Fri, 11 Jan 2013 06:38:38 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19C21F87D6 for ; Fri, 11 Jan 2013 06:38:36 -0800 (PST) Message-Id: <201301111438.r0BEcXsu066830@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , "'Piyush Jain'" , "'pkix'" Date: Fri, 11 Jan 2013 15:38:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01CDF011.BBA05690" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac3vNQM50Waj0ViAQaW/SM0OxRj7QgA00pMw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4458> : streams <888749> : uri <1316431> Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 14:38:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01CDF011.BBA05690 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stefan, As you can see in my previous mail, when OCSP request contains incorrect = (malformed) serial number, because the certificate does not exist, the = OCSP Responder may return an error message malformedRequest or all other = types of responses except for revoked!!! According to rfc2560bis is situation worse because the status revoked = which was about the real certificate status (in CRL or in previous OCSP = RFC) is now with extension of revoked with reason code certificateHold = defined as equivocal result when is not correctly implemented.=20 It means according to rfc2560bis all serial numbers are initially = revoked with reason code certificateHold=E2=80=A6 Is it useful? (The revoked with reason code certificateHold is based on CA database = and in some next steps database can also include the hash values of = certificates for positive statement!) =20 For that reason some systems and legislations where non-repudiation = services are required (e.g. QES) dictate that status value good or = revoked in OCSP response MUST contain a positive statement a hash value = of certificate in singleExtensions. =20 When hash of the certificate as a positive statement MUST be used, the = situations with OCSP responses for RP are clear and unique because: 1) good or revoked is only about know and issued certificates, 2) any other situations are moved into one group which is unclear and = not analyzed =E2=80=93 no evidence, no responsibility. =20 It is a radical simplification! =20 Instead of trying to solve presently not practical and theoretical = situations from the responsibility/liability point of view (like = preparing us for situations: what we will offer for intergalactic green = man, are vegetarian? ;) we can define steps which can be implemented by = CAs and OCSP systems like usage of positive statement cert hash. =20 E.g. define new or reuse already defined in private OID space. PositiveStatement ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, certHash OCTET STRING, -- Hash of Subjects certificate } =20 And according it we cam move. =20 Peter Rybar =20 =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, January 10, 2013 2:19 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Peter, i think the reason for this has been thoroughly debated. =20 It is correct that a cert serial number that was on hold, may be = released. The requested cert serial number may actually be used in a future = representing a real certificate. So this is intentional and the whole purpose behind using the on hold = reason. =20 /Stefan =20 From: Peter Rybar Date: Thursday, January 10, 2013 12:13 PM To: 'Piyush Jain' , Stefan Santesson = , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Stefan, For me is unclear how this extension of revoked with reason code = certificateHold is useful. It define that now is possible to revoke what does not exist and it open = never ending cycle of trying to fixing or correcting the first incorrect = status that "fake" cert serial number is revoked but cert serial number = is not revoked because "fake" cert does not exist. =20 I agree that extension of revoked can be helpful like: The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. =20 =20 When the certificate serial number is not in the OCSP database/CRL then = according to rfc2560bis there are defined following possible responses: 1. signed - good (e.g. certificate serial number is not listed in CRL) 2. signed - unknown (e.g. certificate serial number is not listed in = CRL) 3. unsigned =E2=80=93 unauthorized as an error message 4. signed - revoked where according to rfc2560bis are defined values = for: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC =20 What is missing? The rfc2560bis must also specify values for: This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC =20 X.509 defines the reason code certificateHold as 1) it may remain on the = CRL; 2) it may be replaced by a (final) revocation; 3) it may be = explicitly released; and=20 4) as a consequence of rfc2560bis the status of certificate serial = number indicated as revoked with reason code certificateHold can be = replaced with real status of a new real certificate which was issued = with the same certificate serial number as was asked in the incorrect = OCSP request created by insufficiently implemented applications where = the signature of the certificate was not checked with CA public key. =20 It is based on the following definitions: =20 According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/=20 =20 - good =E2=80=A6 is not revoked, (does not necessarily mean that the = certificate was ever issued)=E2=80=A6 - revoked =E2=80=A6 has been revoked (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.) - unknown =E2=80=A6 =20 When a responder responds revoked to a status request for a non- issued certificate, the responder MUST also; =20 - 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.=20 =20 =20 According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code = extension: http://www.itu.int/rec/T-REC-X.509 A certificate may be placed on hold by issuing a CRL entry with a reason = code of certificateHold. The certificate hold notice may include an = optional hold instruction code to convey additional information to = certificate users (see 8.5.2.3).=20 Once a hold has been issued, it may be handled in one of three ways:=20 a) it may remain on the CRL with no further action, causing users to = reject transactions issued during the hold period; or,=20 b) it may be replaced by a (final) revocation for the same certificate, = in which case the reason shall be one of the standard reasons for = revocation, the revocation date shall be the date the certificate was = placed on hold, and the optional instruction code extension field shall = not appear; or,=20 c) it may be explicitly released and the entry removed from the CRL. =20 =20 =20 -----Original Message----- From: Piyush Jain [mailto:piyush@ditenity.com]=20 Sent: Wednesday, January 09, 2013 6:17 PM To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' Subject: RE: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined = in > section 4.4.8 of ocsp draft 8 > Importance: High >=20 > Peter; >=20 > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >=20 > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. >=20 > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The = certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are = signed fraudulently. RPs won't make queries for certificate for which they = cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently = issued certificates unless you are saying that this specification will allow = for RPs to skip signature checking. >=20 > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. >=20 > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? >=20 > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already = used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. >=20 > No that is a task for another possible effort. > It's not part of this update. =20 [Piyush] Can you clarify what is the goal for this update? I think it is = one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. =20 But based on different threads on this topic I get confused about what = it is. Having the goal clear would help us keep the review of draft = focused.=20 =20 >=20 > But this update paves the way for such extension. Which I'm not = against. > It's just not part of this update effort. =20 >=20 > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status = the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records = in > >OCSP database will be use: > > -- unknown >=20 >=20 > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect = (to > indicate that a certificate with this serial number should not be trusted). >=20 > It's important that this works with legacy clients. They will be = around for a > while. >=20 [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting = "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". =20 > /Stefan >=20 > > > > > >_______________________________________________ > >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 ------=_NextPart_000_0015_01CDF011.BBA05690 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 
Stefan,
As you can see in my previous mail, when OCSP =
request contains incorrect (malformed) serial number, because the =
certificate does not exist, the OCSP Responder may return an error =
message malformedRequest or all other types of responses =
except for =
revoked!!!
According to rfc2560bis is situation worse =
because the status revoked which was about the real certificate status =
(in CRL or in previous OCSP RFC) is now with extension of revoked with reason code =
certificateHold defined as equivocal result when is not correctly =
implemented. 
It means according to rfc2560bis all serial =
numbers are initially revoked with reason code =
certificateHold=E2=80=A6 Is it =
useful?
(The revoked with reason code =
certificateHold is based on CA database and in some next steps database =
can also include the hash values of certificates for positive =
statement!)
 
For that reason some systems and legislations =
where non-repudiation services are required (e.g. QES) dictate that =
status value good or revoked in OCSP response MUST =
contain a positive statement a hash value of certificate in =
singleExtensions.
 
When hash of the certificate as a positive =
statement MUST be used, the situations with OCSP responses for RP are =
clear and unique because:
1) good or revoked is only about know and =
issued certificates,
2) any other situations are moved =
into one group which is unclear and not analyzed =E2=80=93 no evidence, =
no responsibility.
 
It is a radical =
simplification!
 
Instead of trying to solve presently not =
practical and theoretical situations from the responsibility/liability =
point of view (like preparing us for situations: what we will offer for =
intergalactic green man, are vegetarian? ;) we can define steps which =
can be implemented by CAs and OCSP systems like usage of positive =
statement cert hash.
 
E.g. define new or reuse already defined in =
private OID space.
PositiveStatement ::=3D SEQUENCE =
{
=C2=A0=C2=A0 hashAlgorithm=C2=A0=C2=A0=C2=A0 =
AlgorithmIdentifier,
=C2=A0=C2=A0 =
certHash=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OCTET STRING, =
-- Hash of Subjects certificate
}
 
And according it we cam =
move.
 
Peter =
Rybar

 

 

From: = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Thursday, January = 10, 2013 2:19 PM
To: Peter Rybar; = 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Peter, i = think the reason for this has been thoroughly = debated.

 

It is correct = that a cert serial number that was on hold, may be = released.

The requested = cert serial number may actually be used in a future representing a real = certificate.

So this is = intentional and the whole purpose behind using the on hold = reason.

 

/Stefan

 

From: Peter = Rybar <rybar@nbusr.sk>
Date: Thursday, January = 10, 2013 12:13 PM
To: 'Piyush Jain' <piyush@ditenity.com>, Stefan = Santesson <stefan@aaa-sec.com>, = 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Stefan,

For me is unclear = how this extension of revoked with = reason code certificateHold is = useful.

It define that now = is possible to revoke what does not exist and it open never ending cycle of trying = to fixing or correcting the first incorrect status that "fake" = cert serial number is revoked but cert serial number is not revoked because "fake" cert does not = exist.

 

I agree that = extension of revoked can be helpful = like:

   The "revoked" state indicates that =
the certificate has been =
revoked
   (either permanently =
or temporarily (on hold)). Response =
extensions
   may be used to =
convey additional information on assertions made =
by
   the responder =
regarding the status of the certificate such =
as
   positive statement =
about issuance, validity, =
etc.

 

 

When the certificate = serial number is not in the OCSP database/CRL then according to rfc2560bis = there are defined following possible = responses:

1. signed - =  good (e.g. certificate serial = number is not listed in CRL)

2. signed - =  unknown (e.g. certificate serial = number is not listed in CRL)

3. unsigned = =E2=80=93 unauthorized as an error message

4. signed - =  revoked where according to = rfc2560bis are defined values for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

 

What is missing? The = rfc2560bis must also specify values for:

This Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC

 

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; = 2) it may be replaced by a (final) revocation; 3) it may be explicitly = released;

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced = with real status of a new real certificate which was issued with the same = certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the = certificate was not checked with CA public = key.

 

It is based on the = following definitions:

 
According to rfc2560bis the certificate status value =
is:
http:/=
/tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ =

 
   -  good =E2=80=A6 is not revoked, =
(does not necessarily mean that the =
certificate was ever =
issued)=E2=80=A6
   -  revoked =E2=80=A6 has been revoked = (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.)
   -  unknown =
=E2=80=A6

 

   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.

 

 

According to ITU-T = Rec. X.509 (11/2008), clause 8.5.2.2 Reason code = extension:

http://www.itu.int/rec/T-REC-= X.509

A certificate may be = placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to = convey additional information to certificate users (see 8.5.2.3). =

Once a hold has been = issued, it may be handled in one of three ways: =

a) it may remain on = the CRL with no further action, causing users to reject transactions issued = during the hold period; or,

b) it may be = replaced by a (final) revocation for the same certificate, in which case the reason = shall be one of the standard reasons for revocation, the revocation date shall be = the date the certificate was placed on hold, and the optional instruction = code extension field shall not appear; or, =

c) it may be = explicitly released and the entry removed from the = CRL.

 

 

 

-----Original Message-----
From: Piyush Jain [mailto:piyush@ditenity.com]
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

> -----Original = Message-----

> From: Stefan Santesson [mailto:stefan@aaa-sec.com]

> Sent: Tuesday, January 08, = 2013 8:40 PM

> To: Peter = Rybar; 'Piyush Jain'; 'pkix'

> Subject: Re: [pkix] Question = about extended Revoked Extension defined = in

> section 4.4.8 of ocsp draft = 8

> Importance: = High

> =

> = Peter;

> =

> On 1/8/13 5:18 PM, = "Peter = Rybar" <rybar@nbusr.sk> = wrote:

> =

> = >Stefan,

> >The terminology is not = clear for someone who will see:

> >The revocation is of "non-issued = certificate".

> >Because by reading the = text it is expected that the certificate = was

> >issued, but = fraudulently.

> =

> What part of the text = supports that?

[Piyush] None explicitly, but = many would infer it that way. The = certificate

space that is covered by your interpretation of "non-issued" = includes

certificates which are not signed = using the CA key and those that are = signed

fraudulently. RPs won't make = queries for certificate for which they = cannot

verify the signature. So the only = genuine requests for "non-issued

certificates" coming to a = responder would be those for fraudulently = issued

certificates unless you are = saying that this specification will allow = for

RPs to skip signature = checking.

> =

> = >

> >The revocation with a = new extension is only about fraudulently = issued

> >certificate. It means = this new extension and revocation is not = used

> >when the certificate is = not issued and only fake random = certificate

> >serial number was = created in OCSP request.

> =

> = What?

> How in this physical = universe would the OCSP responder tell the

> = difference???

> Crystal = ball?

> =

> = >

> >While it is intended = only for fraudulently issued certificate = where

> >fraudulently issued = certificate can potentially reuse any already = used

> = >certificate-serial-number the extension must contain e.g. a = positive

> >confirmation of = existence in the form of hash value of = fraudulently

> >issued = certificate.

> =

> No that is a task for = another possible effort.

> It's not part of this = update.

 

[Piyush] Can you clarify what is = the goal for this update? I think it is = one

of the = following

- Allow for extending definition = of revoked so other specifications = can

extend the = protocol

- Address handling of = fraudulently issued certificate.

- Address handling of any = certificate not issued by the CA.

 

But based on different threads on = this topic I get confused about what = it

is. Having the goal clear would = help us keep the review of draft focused. =

 

> =

> But this update paves the = way for such extension. Which I'm not = against.

> It's just not part of this = update effort.

 

> =

> = >

> >Only according to the = hash value of fraudulently issued = certificate

> >relaying party and OCSP = responder is able to identify = fraudulently

> >issued certificate = because CA was compromised and serial numbers = of

> >certificates are not any = longer unique for compromised CA.

> = >

> = >Conclusion:

> >Positive statement = extension as a hash value of the certificate = whose

> >status OCSP response is = providing can be used in this case:

> >  when the = certificate is revoked,

> >  when the = certificate is good and also

> >  when the = certificate is fraudulently issued.

> = >

> >For that reason it can = be more helpful to define in RFC one = positive

> >statement extension as a = hash value of the certificate whose status = the

> >OCSP response is = providing and define in RFC that it will = support

> >situations when status = is:

> >   -- = good

> >   -- = revoked

> >And for randomly created certificate serial numbers without records = in

> >OCSP database will be = use:

> >   -- = unknown

> =

> =

> No, we have been through = this and determined WG consensus.

> Unknown is not the choice, = since it may not have the desired effect = (to

> indicate that a certificate = with this serial number should not be

trusted).<= /span>

> =

> It's important that this = works with legacy clients. They will be = around

for = a

> = while.

> =

[Piyush] That's an interesting = usage of the word "legacy". I don't = think

that any of the previous versions = of OCSP recommended interpreting = "unknown"

or UNAUTHORIZED(unsigned) = responses to imply that certificate can be

trusted. The right word would be = to "incorrectly implemented = clients".

 

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

------=_NextPart_000_0015_01CDF011.BBA05690-- From denis.pinkas@bull.net Fri Jan 11 06:59: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 2494821F88E2 for ; Fri, 11 Jan 2013 06:59:41 -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 3-xDX8Txp54Z for ; Fri, 11 Jan 2013 06:59:40 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3004621F8880 for ; Fri, 11 Jan 2013 06:59:40 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 9DD961D018; Fri, 11 Jan 2013 15:59:38 +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 2013011115593733-11167 ; Fri, 11 Jan 2013 15:59:37 +0100 Message-ID: <50F028D6.1020502@bull.net> Date: Fri, 11 Jan 2013 15:59:34 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Erwann Abalea References: <50F00BD4.2060302@bull.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/01/2013 15:59:37, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/01/2013 15:59:38, Serialize complete at 11/01/2013 15:59:38 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------080502000801020001020406" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 14:59:41 -0000 This is a multi-part message in MIME format. --------------080502000801020001020406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Erwann, Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED Case 7 is unused. Denis > > 2013/1/11 Denis Pinkas > > > > The re-use of onhold reason code is not meaningful, because it does= not correspond to the meaning of onhold > > as it is used today. Some applications dealing with electronic sign= atures are already applying a specific treatment > > on that reason code. Depending of the content of the signature poli= cy, these applications may =E2=80=9Cwait and > > come back later=E2=80=9D to see if there is a change in the revocat= ion status. That change will never happen > > if the certificate has not been regularly issued. > > =20 > > It would be more appropriate to use a specific reason code that wil= l only appear in OCSP Responses, and never in CRLs. > > =20 > > The authors of RFC 5280 were very wise, because that have reserved = bit 7 for a purpose that is not supported in CRLs. =20 > > > If you're talking about bit instead of enumerated value, then you're=20 > talking about the "ReasonFlags" definition that is used in=20 > cRLDistributionPoints extension instead of the "CRLReason" definition=20 > used to indicate the revocation reason. And this "ReasonFlags" bit=20 > string already uses bit 7 ;) > > --=20 > Erwann.=20 --------------080502000801020001020406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Erwann,

Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

The re-use of onhold reason code is=
 not meaningful, because it does not correspond to the meaning of onhold =

as it is used today. Some applicati=
ons dealing with electronic signatures are already applying a specific tr=
eatment 
on that reason code. Depending of t=
he content of the signature policy, these applications may =E2=80=9Cwait =
and 
come back later=E2=80=9D to see if =
there is a change in the revocation status. That change will never happen=
 
if the certificate has not been reg=
ularly issued.
=C2=A0
It would be more appropriate to use=
 a specific reason code that will only appear in OCSP Responses, and neve=
r in CRLs.
=C2=A0
The authors of RFC 5280 were very w=
ise, because that have reserved bit 7 for a purpose that is not supported=
 in CRLs. =C2=A0

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

--------------080502000801020001020406-- From stefan@aaa-sec.com Fri Jan 11 07:04: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 4D60521F88E2 for ; Fri, 11 Jan 2013 07:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=-0.386, 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 fJ3cumtRV0Wh for ; Fri, 11 Jan 2013 07:04:40 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 732AC21F86CD for ; Fri, 11 Jan 2013 07:04:39 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 89D961E1A939 for ; Fri, 11 Jan 2013 16:04: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 il5PrEOC8ZW3 for ; Fri, 11 Jan 2013 16:04:30 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 253751E2AF58 for ; Fri, 11 Jan 2013 16:04:30 +0100 (CET) Received: (qmail 95379 invoked from network); 11 Jan 2013 15:04:29 -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 ; 11 Jan 2013 15:04:29 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 16:04:35 +0100 From: Stefan Santesson To: Peter Rybar , 'Piyush Jain' , 'pkix' Message-ID: Thread-Topic: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <201301111438.r0BEcXsu066830@mail.nbusr.sk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3440765080_32444697" Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 15:04:48 -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_3440765080_32444697 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: Peter Rybar Date: Friday, January 11, 2013 3:38 PM To: Stefan Santesson , 'Piyush Jain' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > Stefan, > As you can see in my previous mail, when OCSP request contains incorrect > (malformed) serial number, because the certificate does not exist, the OC= SP > Responder may return an error message malformedRequest or all other types= of > responses except for revoked!!! How does a serial number become malformed just because it doesn't exists. Its just an integer. Its syntactically a well formed integer. > According to rfc2560bis is situation worse because the status revoked whi= ch > was about the real certificate status (in CRL or in previous OCSP RFC) is= now > with extension of revoked with reason code certificateHold defined as > equivocal result when is not correctly implemented. > It means according to rfc2560bis all serial numbers are initially revoked= with > reason code certificateHold=8A Is it useful? Yes. > (The revoked with reason code certificateHold is based on CA database and= in > some next steps database can also include the hash values of certificates= for > positive statement!) > =20 > For that reason some systems and legislations where non-repudiation servi= ces > are required (e.g. QES) dictate that status value good or revoked in OCSP > response MUST contain a positive statement a hash value of certificate in > singleExtensions. > =20 Then that can be achieved by defining a new single response extension that does not interfere with what is being done in 2560bis. > When hash of the certificate as a positive statement MUST be used, the > situations with OCSP responses for RP are clear and unique because: > 1) good or revoked is only about know and issued certificates, Great, so how then do you respond to a request for a serial number that has never been issued? > 2) any other situations are moved into one group which is unclear and not > analyzed =AD no evidence, no responsibility. But the responder still need to respond. > =20 > It is a radical simplification! Of what? > =20 > Instead of trying to solve presently not practical and theoretical situat= ions > from the responsibility/liability point of view (like preparing us for > situations: what we will offer for intergalactic green man, are vegetaria= n? ;) > we can define steps which can be implemented by CAs and OCSP systems like > usage of positive statement cert hash. > =20 Asking for status of a never issued serial number is not impossible. It is not even hard. A good protocol should provide a reasonable response to every possible request. > E.g. define new or reuse already defined in private OID space. > PositiveStatement ::=3D SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > certHash OCTET STRING, -- Hash of Subjects certificate > } > =20 > And according it we cam move. I have nothing against such extension being defined. But it still does not remove the need for the current discussed mechanism. The current discussed mechanism address how to respond to legacy clients to requests for non-issued serial numbers. Your extension does not help, because it is not understood by legacy clients. So its not either or. /Stefan > =20 > Peter Rybar > =20 > =20 >=20 >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Thursday, January 10, 2013 2:19 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > =20 >=20 > Peter, i think the reason for this has been thoroughly debated. >=20 > =20 >=20 > It is correct that a cert serial number that was on hold, may be released= . >=20 > The requested cert serial number may actually be used in a future represe= nting > a real certificate. >=20 > So this is intentional and the whole purpose behind using the on hold rea= son. >=20 > =20 >=20 > /Stefan >=20 > =20 >=20 > From: Peter Rybar > Date: Thursday, January 10, 2013 12:13 PM > To: 'Piyush Jain' , Stefan Santesson > , 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 >=20 > =20 >>=20 >> Stefan, >> For me is unclear how this extension of revoked with reason code >> certificateHold is useful. >> It define that now is possible to revoke what does not exist and it open >> never ending cycle of trying to fixing or correcting the first incorrect >> status that "fake" cert serial number is revoked but cert serial number = is >> not revoked because "fake" cert does not exist. >> =20 >> I agree that extension of revoked can be helpful like: >> The "revoked" state indicates that the certificate has been revoked >> (either permanently or temporarily (on hold)). Response extensions >> may be used to convey additional information on assertions made by >> the responder regarding the status of the certificate such as >> positive statement about issuance, validity, etc. >> =20 >> =20 >> When the certificate serial number is not in the OCSP database/CRL then >> according to rfc2560bis there are defined following possible responses: >> 1. signed - good (e.g. certificate serial number is not listed in CRL) >> 2. signed - unknown (e.g. certificate serial number is not listed in CR= L) >> 3. unsigned =AD unauthorized as an error message >> 4. signed - revoked where according to rfc2560bis are defined values fo= r: >> Extensions: id-pkix-ocsp-extended-revoke >> Revocation Reasons: certificateHold >> Revocation Time: 1.1.1970 00:00:00 UTC >> =20 >> What is missing? The rfc2560bis must also specify values for: >> This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC >> Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC >> =20 >> X.509 defines the reason code certificateHold as 1) it may remain on the= CRL; >> 2) it may be replaced by a (final) revocation; 3) it may be explicitly >> released; >> and=20 >> 4) as a consequence of rfc2560bis the status of certificate serial numbe= r >> indicated as revoked with reason code certificateHold can be replaced wi= th >> real status of a new real certificate which was issued with the same >> certificate serial number as was asked in the incorrect OCSP request cre= ated >> by insufficiently implemented applications where the signature of the >> certificate was not checked with CA public key. >> =20 >> It is based on the following definitions: >> =20 >> According to rfc2560bis the certificate status value is: >> http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ >> =20 >> - good =8A is not revoked, (does not necessarily mean that the certifi= cate >> was ever issued)=8A >> - revoked =8A has been revoked (This state MAY also be returned if the >> responder knows that the requested certificate has never been issued dur= ing >> the history of the associated CA using any current or previous issuing k= ey.) >> - unknown =8A >> =20 >> When a responder responds revoked to a status request for a non- >> issued certificate, the responder MUST also; >> =20 >> - 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. >> =20 >> =20 >> According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code >> extension: >> http://www.itu.int/rec/T-REC-X.509 >> A certificate may be placed on hold by issuing a CRL entry with a reason= code >> of certificateHold. The certificate hold notice may include an optional = hold >> instruction code to convey additional information to certificate users (= see >> 8.5.2.3).=20 >> Once a hold has been issued, it may be handled in one of three ways: >> a) it may remain on the CRL with no further action, causing users to rej= ect >> transactions issued during the hold period; or, >> b) it may be replaced by a (final) revocation for the same certificate, = in >> which case the reason shall be one of the standard reasons for revocatio= n, >> the revocation date shall be the date the certificate was placed on hold= , and >> the optional instruction code extension field shall not appear; or, >> c) it may be explicitly released and the entry removed from the CRL. >> =20 >> =20 >> =20 >> -----Original Message----- >> From: Piyush Jain [mailto:piyush@ditenity.com] >> Sent: Wednesday, January 09, 2013 6:17 PM >> To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' >> Subject: RE: [pkix] Question about extended Revoked Extension defined in >> section 4.4.8 of ocsp draft 8 >> =20 >> =20 >> =20 >>> > -----Original Message----- >>> > From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>> > Sent: Tuesday, January 08, 2013 8:40 PM >>> > To: Peter Rybar; 'Piyush Jain'; 'pkix' >>> > Subject: Re: [pkix] Question about extended Revoked Extension defined= in >>> > section 4.4.8 of ocsp draft 8 >>> > Importance: High >>> >=20 >>> > Peter; >>> >=20 >>> > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >>> >=20 >>>> > >Stefan, >>>> > >The terminology is not clear for someone who will see: >>>> > >The revocation is of "non-issued certificate". >>>> > >Because by reading the text it is expected that the certificate was >>>> > >issued, but fraudulently. >>> >=20 >>> > What part of the text supports that? >> [Piyush] None explicitly, but many would infer it that way. The certific= ate >> space that is covered by your interpretation of "non-issued" includes >> certificates which are not signed using the CA key and those that are si= gned >> fraudulently. RPs won't make queries for certificate for which they cann= ot >> verify the signature. So the only genuine requests for "non-issued >> certificates" coming to a responder would be those for fraudulently issu= ed >> certificates unless you are saying that this specification will allow fo= r >> RPs to skip signature checking. >>> >=20 >>>> > > >>>> > >The revocation with a new extension is only about fraudulently issu= ed >>>> > >certificate. It means this new extension and revocation is not used >>>> > >when the certificate is not issued and only fake random certificate >>>> > >serial number was created in OCSP request. >>> >=20 >>> > What? >>> > How in this physical universe would the OCSP responder tell the >>> > difference??? >>> > Crystal ball? >>> >=20 >>>> > > >>>> > >While it is intended only for fraudulently issued certificate where >>>> > >fraudulently issued certificate can potentially reuse any already u= sed >>>> > >certificate-serial-number the extension must contain e.g. a positiv= e >>>> > >confirmation of existence in the form of hash value of fraudulently >>>> > >issued certificate. >>> >=20 >>> > No that is a task for another possible effort. >>> > It's not part of this update. >> =20 >> [Piyush] Can you clarify what is the goal for this update? I think it is= one >> of the following >> - Allow for extending definition of revoked so other specifications can >> extend the protocol >> - Address handling of fraudulently issued certificate. >> - Address handling of any certificate not issued by the CA. >> =20 >> But based on different threads on this topic I get confused about what i= t >> is. Having the goal clear would help us keep the review of draft focused= . >> =20 >>> >=20 >>> > But this update paves the way for such extension. Which I'm not again= st. >>> > It's just not part of this update effort. >> =20 >>> >=20 >>>> > > >>>> > >Only according to the hash value of fraudulently issued certificate >>>> > >relaying party and OCSP responder is able to identify fraudulently >>>> > >issued certificate because CA was compromised and serial numbers of >>>> > >certificates are not any longer unique for compromised CA. >>>> > > >>>> > >Conclusion: >>>> > >Positive statement extension as a hash value of the certificate who= se >>>> > >status OCSP response is providing can be used in this case: >>>> > > when the certificate is revoked, >>>> > > when the certificate is good and also >>>> > > when the certificate is fraudulently issued. >>>> > > >>>> > >For that reason it can be more helpful to define in RFC one positiv= e >>>> > >statement extension as a hash value of the certificate whose status= the >>>> > >OCSP response is providing and define in RFC that it will support >>>> > >situations when status is: >>>> > > -- good >>>> > > -- revoked >>>> > >And for randomly created certificate serial numbers without records= in >>>> > >OCSP database will be use: >>>> > > -- unknown >>> >=20 >>> >=20 >>> > No, we have been through this and determined WG consensus. >>> > Unknown is not the choice, since it may not have the desired effect (= to >>> > indicate that a certificate with this serial number should not be >> trusted). >>> >=20 >>> > It's important that this works with legacy clients. They will be arou= nd >> for a >>> > while. >>> >=20 >> [Piyush] That's an interesting usage of the word "legacy". I don't think >> that any of the previous versions of OCSP recommended interpreting "unkn= own" >> or UNAUTHORIZED(unsigned) responses to imply that certificate can be >> trusted. The right word would be to "incorrectly implemented clients". >> =20 >>> > /Stefan >>> >=20 >>>> > > >>>> > > >>>> > >_______________________________________________ >>>> > >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 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3440765080_32444697 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, January 11, 2013 3:38 PM
To:= Stefan Santesson <stefan@aaa= -sec.com>, 'Piyush Jain' <piy= ush@ditenity.com>, 'pkix' <pkix@iet= f.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp d= raft 8

Stefan,=

As you can see in my previous mail, wh=
en OCSP request contains incorrect (malformed) serial number, because the ce=
rtificate does not exist, the OCSP Responder may return an error message mal=
formedRequest or all other type=
s of responses except for revoked!!!

How does a serial number become malformed just becau= se it doesn't exists. Its just an integer.
Its syntactically a wel= l formed integer.

According to rfc2560bis is situation worse be=
cause the status revoked which was about the real certificate status (in CRL=
 or in previous OCSP RFC) is now with extension of revoked with reason code certificateHold defined as equi=
vocal result when is not correctly implemented. 
It means according to rfc2560bis all serial numbers are initially =
revoked with reason code certif=
icateHold… Is it useful?

Yes.

(The revoke=
d with reason code certificateHold is based on CA database and in=
 some next steps database can also include the hash values of certificates f=
or positive statement!)
 
For that reason some systems and legislations w=
here non-repudiation services are required (e.g. QES) dictate that status va=
lue good or revoked in OCSP response MUST contain a positive s=
tatement a hash value of certificate in singleExtensions.<=
/font>
 

Then that can be achi= eved by defining a new single response extension that does not interfere wit= h what is being done in 2560bis.

When ha=
sh of the certificate as a positive statement MUST be used, the situations w=
ith OCSP responses for RP are clear and unique because:
1) good or =
revoked is only about know and iss=
ued certificates,

Great, so how then do you respond to a r= equest for a serial number that has never been issued?

<= span id=3D"OLK_SRC_BODY_SECTION">
2) any other situations are moved into one group which is unclear and not an=
alyzed – no evidence, no responsibility.

= But the responder still need to respond.

&n=
bsp;
It is a radical simplification!

Of what?

&n=
bsp;
Instead of trying to solve presently no=
t practical and theoretical situations from the responsibility/liability poi=
nt of view (like preparing us for situations: what we will offer for interga=
lactic green man, are vegetarian? ;) we can define steps which can be implem=
ented by CAs and OCSP systems like usage of positive statement cert hash.
 

Askin= g for status of a never issued serial number is not impossible. It is not ev= en hard.
A good protocol should provide a reasonable response to e= very possible request.

<= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
E.g. de=
fine new or reuse already defined in private OID space.
PositiveStatement ::=3D SEQUENCE {
   hashAlgorithm    AlgorithmIdentifier,=

   certHash   =
;      OCTET STRING, -- Hash of Subjects certificat=
e
}
=
 
And according it we cam move.<=
o:p>

I have nothing against such extension being def= ined.
But it still does not remove the need for the current discus= sed mechanism.

The current discussed mechanism addr= ess how to respond to legacy clients to requests for non-issued serial numbe= rs.
Your extension does not help, because it is not understood by = legacy clients.

So its not either or.
/Stefan

&n=
bsp;
Peter Rybar

 

 

From: Stefan Sant= esson [mailto:stefan@aaa-sec.com]
= Sent: Thursday, January 10, 2013 2:19 PM
To: Peter Rybar; 'Piyush Jai= n'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8<= /font>

 

Peter, i think the reason for this has been thoroughly debated.

 

It is correct that a cert serial number that was on hold, may be released.

The re= quested cert serial number may actually be used in a future representing a real certific= ate.

So this is intentional and the whole purpose behind using the on hold reason.

=  

/Stefan

 

<= /div>

From: P= eter Rybar <rybar@nbusr.sk>Date: Thursday, January 10, 20= 13 12:13 PM
To: 'Piyush Jain' = <piyush@ditenity.com>, Stefan= Santesson <stefan@aaa-sec.com>, 'pkix' = <pkix@ietf.org>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

St= efan,

For me is unclear how this extension of revoked with reas= on code certificateHold is useful.

It define that now is pos= sible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist.

 

I ag= ree that extension of revoked c= an be helpful like:

   The "revoked" state indicates that the certificat=
e has been revoked
   (either permanently or temporarily (on hold)). Response e=
xtensions
&nb=
sp;  may be used to convey additional information on assertions made by=

  =
 the responder regarding the status of the certificate such as<=
o:p>
   positive stat=
ement about issuance, validity, etc.
 =

 
<=
font size=3D"3" color=3D"black" face=3D"Times New Roman">When the certificate serial
number is not in the OCSP database/CRL then according to rfc2560bis there a=
re
defined following possible responses:=

1. signed -  <=
b>good (e.g. certificate serial nu=
mber is not
listed in CRL)
2. signed -  unknown (e.g. =
certificate serial number is
not listed in CRL)
3. unsigned – unauthorized as
an error message
4. signed -  revoked where according to rfc2560bis are
defined values for:
Extensions:=

id=
-pkix-ocsp-extended-revoke
Revoc=
ation
Reasons: certificateHold
Revocatio=
n
Time: 1.1.1970 00:00:00 UTC<=
span style=3D"color:black">
<=
font size=3D"1" color=3D"black" face=3D"Courier New"> =

What is mi=
ssing? The rfc2560bis
must also specify values for:
This Update:  ?? ?? ??   &nbs=
p; 10.1.2013
9:51:15 UTC
Next Upd=
ate:  ?? ?? ??     10.1.2013
9:51:15 UTC
&n=
bsp;=

X.509
defines the reason code certificateHold as 1) it may remain on the CRL; 2) =
it
may be replaced by a (final) revocation; 3) it may be explicitly released;<=
u1:p>
and

4)
as a consequence of rfc2560bis the status of certificate serial number
indicated as revoked with reason code certificateHold can be replaced with =
real
status of a new real certificate which was issued with the same certificate=

serial number as was asked in the incorrect OCSP request created by
insufficiently implemented applications where the signature of the certific=
ate
was not checked with CA public key.
 
=
It is based on the following
definitions:
 
According to rfc2560bis the certificate status value is:=

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 
 
   -  good … is not revoked, (does not necessarily mean that the certifi=
cate was ever issued)…
   -  revoked … has been revoked (This st=
ate MAY also be returned if the responder knows that the requested certifica=
te has never been issued during=
 the history of the associated CA using any current or previous issuing key.=
)
   -  unknown …<=
/o:p>
 
=
   When a responder responds revoked to a status request for a non=
-
   issued certificate, the responder MUST also;
 
    - include the extended revoked definition r=
esponse extension
      (section 4.8), indicating that =
the OCSP responder supports the
<=
pre>      extended definition of revoked =
state to also cover non-issued
      certificates,
    - provide the revocation reason certificate=
Hold (6), and;
    - specify the revocation date January 1, 19=
70.

 

 =

A= ccording to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-X.509<= u1:p>

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to co= nvey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways: =

a) it may remain on= the CRL with no further action, causing users to reject transactions issued during = the hold period; or,

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall= be one of the standard reasons for revocation, the revocation date shall be th= e date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or,

c) it may be expli= citly released and the entry removed from the CRL.=

 =

<= u1:p> 

 

-----Original Message-----
From: Piyush Jain [mailto:piyush@diten= ity.com]
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

> -----Original Me= ssage-----

= > From: Stefan Santesson [mailto:stefan@aaa-sec.com]

=

> Sent: Tuesday, January 08, 2013 = 8:40 PM

> To: Peter Rybar; 'Piyush Jain'; 'pkix'

> Subject: Re: [pkix] Question about extended Revoked Extension defined in=

= > section 4.4.8 of ocsp draft = 8

> Importance: High

> <= /p>

<= span style=3D"font-size:10.0pt;color:black">> Peter;

> =

> On = 1/8/13 5:18 PM, "Peter Rybar" <rybar@nbusr.sk> wrote:

> =

> >Stefan,

> >The terminology is not clear for someone who will see:

> >The revocation is of "non-issued certificate".

> >Because by reading the text it is expected that the certificate was

=

> >issued, but fraudulently.

>

> What part of the text supports that?

[Piyush] None expl= icitly, but many would infer it that way. The certificate

space that is covered by your interpretation of "non-issued" includes

certificates which are not sign= ed using the CA key and those that are signed<= /p>

<= span style=3D"font-size:10.0pt;color:black">fraudulently. RPs won't make queri= es for certificate for which they cannot

=

verify the signature. So the only gen= uine requests for "non-issued

certificates" coming to a responder would be those for fraudulently issued

certificates unless you are sayi= ng that this specification will allow for

=

RPs to skip signature checking.=

&= gt;

> >

> >The revocation with a new extension is only about fraudulently issued<= /font>

> >certificate. It me= ans this new extension and revocation is not used<= /p>

<= span style=3D"font-size:10.0pt;color:black">> >when the certificate is n= ot issued and only fake random certificate

> >serial number was crea= ted in OCSP request.

<= font size=3D"2" color=3D"black" face=3D"Courier New">>

> What?

=

> How in this physical universe wo= uld the OCSP responder tell the

> difference???<= /span>

> Crystal ball?

>

> >

> >While it is intended only for fraudulently issued certificate where=

= > >fraudulently issued cert= ificate can potentially reuse any already used

> >certificate-serial-numb= er the extension must contain e.g. a positive

> >confirmation of existen= ce in the form of hash value of fraudulently

> >issued certificate.

>= ;

> No that is a task for another possible effort.

> It's not part of this update.

 

[Piy= ush] Can you clarify what is the goal for this update? I think it is one

of the following

- Allow for ext= ending definition of revoked so other specifications can

extend the protocol

- Address h= andling of fraudulently issued certificate.

- Address handling of any certificate not issued by the CA.

 

But based on different threads on this topic I get confused about what it

is. Having the goal clear would help= us keep the review of draft focused.

 

>

> But this u= pdate paves the way for such extension. Which I'm not against.

> It's just not part of this = update effort.

 

>

> >

> >Only according to t= he hash value of fraudulently issued certificate

> >relaying party and OCSP res= ponder is able to identify fraudulently

<= p class=3D"MsoPlainText">> >issued certificate because CA= was compromised and serial numbers of

=

> >certificates are not any lon= ger unique for compromised CA.

> >

> >Conclusion:

> = >Positive statement extension as a hash value of the certificate whose

> >status OCSP response is pr= oviding can be used in this case:

> >  when the certificate is revoked,

<= font size=3D"2" color=3D"black" face=3D"Courier New">> >  when the certificate is good and also

> >  when the certificate is fraudulently issued.

> >

> >For that reason it can be m= ore helpful to define in RFC one positive=

= > >statement extension as a= hash value of the certificate whose status the

> >OCSP response is pro= viding and define in RFC that it will support

> >situations when status is:<= u1:p>

> >   -- good

<= p class=3D"MsoPlainText">> >   -- revoked=

&= gt; >And for randomly created certificate serial numbers without records in

> >OCSP database wi= ll be use:

= > >   -- unknown

> <= /o:p>

>

>= No, we have been through this and determined WG consensus.

> Unknown is not the choice, since it may not have the desired effect (to

> indicate that a certificate wi= th this serial number should not be

trusted).

> =

> It's important= that this works with legacy clients. They will be around

for a

> while.<= o:p>

>

[Piyush] That's an interesting usage of the word "legacy". I don't think

<= p class=3D"MsoPlainText">that any of the previous versions of O= CSP recommended interpreting "unknown"

or UNAUTHORIZED(unsigned) responses = to imply that certificate can be

trusted. The right word would be to "incorrectly implemented clients".

 

> /Stefan=

>

> >

> >

> >_______________________________________________=

> >pkix maili= ng list

> >pkix@ietf.org<= /u1:p>

&g= t; >https://www.ietf= .org/mailman/listinfo/pkix

> ><= /font>

>

 

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/li= stinfo/pkix

<= /div>
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3440765080_32444697-- From stefan@aaa-sec.com Fri Jan 11 07:32: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 74D7421F879E for ; Fri, 11 Jan 2013 07:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.199 X-Spam-Level: X-Spam-Status: No, score=-101.199 tagged_above=-999 required=5 tests=[AWL=-0.347, 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 iL1mpYloSjKv for ; Fri, 11 Jan 2013 07:32:19 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 57DD121F8738 for ; Fri, 11 Jan 2013 07:32:17 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D759B1E2867E for ; Fri, 11 Jan 2013 16:31: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 bddofqaUJP9T for ; Fri, 11 Jan 2013 16:31:55 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8FCF71E2D396 for ; Fri, 11 Jan 2013 16:31:55 +0100 (CET) Received: (qmail 21803 invoked from network); 11 Jan 2013 15:31:55 -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 ; 11 Jan 2013 15:31:55 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 16:32:03 +0100 From: Stefan Santesson To: Denis Pinkas , Erwann Abalea Message-ID: Thread-Topic: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <50F028D6.1020502@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3440766726_32539090" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 15:32:24 -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_3440766726_32539090 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number. Thus the certificateHold is a good match. /Stefan From: Denis Pinkas Date: Friday, January 11, 2013 3:59 PM To: Erwann Abalea Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > =20 > =20 > Erwann, > =20 > Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED > =20 > Case 7 is unused. > =20 > Denis > =20 > =20 > =20 > =20 >>=20 >> =20 >> 2013/1/11 Denis Pinkas >> =20 >>> =20 >>>=20 >>> =20 >>> The re-use of onhold reason code is not meaningful, because it does not >>> correspond to the meaning of onhold >>> =20 >>> as it is used today. Some applications dealing with electronic signatur= es >>> are already applying a specific treatment >>> =20 >>> on that reason code. Depending of the content of the signature policy, = these >>> applications may =B3wait and >>> =20 >>> come back later=B2 to see if there is a change in the revocation status. = That >>> change will never happen >>> =20 >>> if the certificate has not been regularly issued. >>> =20 >>> =20 >>> =20 >>> It would be more appropriate to use a specific reason code that will on= ly >>> appear in OCSP Responses, and never in CRLs. >>> =20 >>> =20 >>> =20 >>> The authors of RFC 5280 were very wise, because that have reserved bit = 7 for >>> a purpose that is not supported in CRLs. >>> =20 >>> =20 >> =20 >> =20 >> =20 >> =20 >> If you're talking about bit instead of enumerated value, then you're tal= king >> about the "ReasonFlags" definition that is used in cRLDistributionPoints >> extension instead of the "CRLReason" definition used to indicate the >> revocation reason. And this "ReasonFlags" bit string already uses bit 7 = ;) >> =20 >> =20 >>=20 >> =20 >> --=20 >> Erwann.=20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3440766726_32539090 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
The purpose is to signal tha= t the serial number is CURRENTLY regarded as revoked, but this may change in= the future, i.e. a legitimate certificate may be issued with this serial nu= mber.
Thus the certificateHold is a good match.

/Stefan


From: Denis Pinkas <deni= s.pinkas@bull.net>
Date: Fr= iday, January 11, 2013 3:59 PM
To: = Erwann Abalea <eabalea@gmail.com&= gt;
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 o= f ocsp draft 8

Erwann,

Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <<= a moz-do-not-send=3D"true" href=3D"mailto:denis.pinkas@bull.net" target=3D"_blank"= >denis.pinkas@bull.net>

The re-use of onhold reason code is not=
 meaningful, because it does not correspond to the meaning of onhold =

as it is used today. Some applications =
dealing with electronic signatures are already applying a specific treatment=
 
on that reason code. Depending of the c=
ontent of the signature policy, these applications may “wait and 
come back later” to see if there =
is a change in the revocation status. That change will never happen <=
/pre>
            
if the certificate has not been regular=
ly issued.

            
 

            
It would be more appropriate to use a s=
pecific reason code that will only appear in OCSP Responses, and never in CR=
Ls.

            
 

            
The authors of RFC 5280 were very wise,=
 because that have reserved bit 7 for a purpose that is not supported in CRL=
s.  

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3440766726_32539090-- From piyush@ditenity.com Fri Jan 11 07:55: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 A536421F88BD for ; Fri, 11 Jan 2013 07:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 9+5EM8PsH+8g for ; Fri, 11 Jan 2013 07:55:49 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24821F85E0 for ; Fri, 11 Jan 2013 07:55:49 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id uo13so1889828obb.36 for ; Fri, 11 Jan 2013 07:55: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:x-mailer:thread-index:content-language :x-gm-message-state; bh=pPSGYPtqB2gELb+7VlGEnqlmS3JaS8eFUfUOLclHzAE=; b=XtvY9E+3WpxApMQ91+Mr4BCgd+FVU1oei01qGSGR8+y6fR0nO5pCwjDCSe4k5eMALd Q5ts4TrYi8SjlBXesA5IUQiNqy+peF1CMrnkbIVeRS4Df+vJUGpAVZLV7yfOROApYHTH vGSyTIjoGMJW3mjpxD7F2TkR/D3cZhTzPAQr6xSB6P72kQCS8nZoHodVaYZ2S5mGjeoL JPjUq5N9FkVWyBRdV6e3Sspi/4K7vp0/G6n9Bcqwl93YJbDfyOickpwz5DEdPPuv5kzK ew7reYiDsQP+I6xy/8cS/0Mie3sjvB36k48QmNyEF+A/9v/kCu5F4Vz4mqD6BAKjJLHb bVmg== X-Received: by 10.60.3.193 with SMTP id e1mr46280830oee.39.1357919748497; Fri, 11 Jan 2013 07:55: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 w10sm3898362oeg.2.2013.01.11.07.55.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 11 Jan 2013 07:55:48 -0800 (PST) From: "Piyush Jain" To: "'Denis Pinkas'" , References: <50F00BD4.2060302@bull.net> In-Reply-To: <50F00BD4.2060302@bull.net> Date: Fri, 11 Jan 2013 07:55:44 -0800 Message-ID: <00fa01cdf014$1e5dfa60$5b19ef20$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FB_01CDEFD1.103F9C60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+LHORN7STCGlJk5aGhrXJuvAraQHSAQlZl9U5lDA= Content-Language: en-us X-Gm-Message-State: ALoCoQmUvUNkuOuXkwifQGRScu/gJQjAyciWU2ypgp+Q2x/6Ah6ZmsoIcve3ktnaP37JlBnDMom5 Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 15:55:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FB_01CDEFD1.103F9C60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Friday, January 11, 2013 4:56 AM To: pkix@ietf.org Subject: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 To the list The purpose of this email is to provide replacement text and its rational related to the topic currently called "non-issued certificates". First of all, speaking of non-issued certificate is misleading. The certificate may also have been issued by the CA, but irregularly because the RA was attacked and thus the certificate was indeed issued by the CA. So either the certificate has not been issued or has been irregularly issued (either by the CA or someone else). [Piyush] +1. I think it is important to distinguish between these two situations conceptually even though a compromised CA may have no means to do so. Secondly, RFC 5280 states: CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries. The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment on that reason code. Depending of the content of the signature policy, these applications may "wait and come back later" to see if there is a change in the revocation status. That change will never happen if the certificate has not been regularly issued. [Piyush] +1. The reason cited for onHold code is that the certificate with that serial may be issued in future. However, this is not true if the certificate was irregularly issued. It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. :-) [Piyush] J Lucky us. I hope in future we do not encounter a bunch of incorrectly implemented RPs who want the responder to return revoked for some other reason. The current definition of CRLReason within RFC 5280 is: CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), -- value 7 is not used removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } Rather than importing CRLReason from RFC 5280, we can define RevocationReason locally, consistent with CRLReason with one more bit which will be specific to OCSP. Anyway, we need to redefine the ASN.1 module, since the syntax of nonce had been omitted and must be added. This changes the meaning of the revoked reason in the following way: temporary revocation will apply for two reason code rather than one: certificateHold (6), notIssuedOrIrregularlyIssued (7), Note that the proposed new "extended revoked definition response extension" is not necessary anymore. Why do not make things simpler, when they can be simpler ? :-) This leads to the following replacement: OLD: 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. NEW: The "revoked" state indicates that the certificate has been revoked, either permanently or temporarily (i.e. certificateHold or notIssuedOrIrregularlyIssued). In particular, this state MAY be returned if the responder knows that currently the serial number from the requested certificate has not been used by the CA to issue a certificate or has been used irregularly to issue a certificate. [Piyush] +1 again. I think it is important to capture the fact that this response may imply that CA may have been compromised. Use of "non-issued" hides that implication. 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. [Piyush] The note is a good idea. Do you think it makes sense to clarify why CRLs cannot be used in such cases? Folks not privy to the discussions on this list may get confused because 5280 implies that CRLs and OCSP are interchangeable. The Note above will allow people that do not have followed the discussion on the PKIX mailing list to understand why we have chosen "revoked" rather than "unknown", which would have been more natural. This leads to another change, since the following sentence is not English, it uses the word "never" which is inappropriate and omits to take into consideration certificates that have been irregularly issued: OLD: o Section 2.2 extends the use of the "revoked" response to allow this response status certificates that has never been issued. NEW: o Section 2.2 extends the use of the "revoked" response to also allow this response status either for certificates that have not been issued or that have been irregularly issued. [Piyush] +1 . Distinction between not-issued and irregularly issued is important to have any meaningful discussion. The above arguments lead to other changes. The text copied below, does not follow the order of the ASN.1 syntax and should be aligned with the above proposed text. OLD: 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. NEW: When a responder responds revoked to a status request for a serial number which has not been used by the CA or used irregularly to issue a certificate, the responder MUST also: - specify the revocation date January 1, 1970, - provide the RevocationReason : notIssuedOrIrregularlyIssued (7). and also: OLD: 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. NEW: This section should be deleted. +1 Denis ------=_NextPart_000_00FB_01CDEFD1.103F9C60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Denis Pinkas
Sent: Friday, January 11, 2013 4:56 = AM
To: pkix@ietf.org
Subject: [pkix] About extended = Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

To the list

The purpose of this email is to = provide replacement text and its rational related to the topic currently =
called “non-issued = certificates”.



First of all, speaking of non-issued =
certificate is misleading. The certificate may also have been issued =

by the CA, but =
irregularly because the RA was attacked and thus the certificate was =
indeed issued by the CA. 
So either the certificate has not been issued or has been =
irregularly issued (either by the CA or someone =
else).
 
[Piyush] +1. 
I think it is important to distinguish between these two situations =
conceptually even though a compromised CA may have no means to do =
so.
Secondly, RFC 5280 =
states:
 

   CRL issuers are strongly = encouraged to include meaningful reason codes in CRL = entries.

 
The =
re-use of onhold reason code is not meaningful, because it does not =
correspond to the meaning of onhold 
as it is used today. Some applications dealing with =
electronic signatures are already applying a specific treatment =

on that reason code. =
Depending of the content of the signature policy, these applications may =
“wait and 
come =
back later” to see if there is a change in the revocation status. =
That change will never happen 
if the certificate has not been regularly =
issued.
 
[Piyush] +1.
The reason cited for onHold code is that the certificate with that =
serial may be issued in future. However, this is not true if the =
certificate was irregularly =
issued.
 
It would be =
more appropriate to use a specific reason code that will only appear in =
OCSP Responses, and never in CRLs.
 
The =
authors of RFC 5280 were very wise, because that have reserved bit 7 for =
a purpose that is not supported in CRLs. =

 
:-)
 
[Piyush] J Lucky us. I hope in future we do not encounter a bunch of =
incorrectly implemented RPs who want the responder to return revoked for =
some other reason.
 
The =
current definition of CRLReason within RFC 5280 =
is:
 

   CRLReason ::=3D ENUMERATED = {

        = unspecified          &n= bsp;  (0),

        = keyCompromise          = (1),

        = cACompromise          &= nbsp; (2),

        = affiliationChanged      = (3),

        = superseded  =             (= 4),

        = cessationOfOperation    (5),

        = certificateHold         = (6),

       &nbs= p;     -- value 7 is not = used

        = removeFromCRL          = (8),

        = privilegeWithdrawn      = (9),

        = aACompromise           = (10) }

 
Rather than importing CRLReason from RFC 5280, we can =
define RevocationReason locally, consistent with CRLReason with one more =
bit 
which will be =
specific to OCSP. Anyway, we need to redefine the ASN.1 module, since =
the syntax of nonce had been omitted and must be =
added.
 
This =
changes the meaning of the revoked reason in the following way: =

temporary revocation =
will apply for two reason code rather than =
one:
 

        = certificateHold         &nbs= p;     (6),

        = notIssuedOrIrregularlyIssued  (7),

 

Note that the proposed new "extended revoked =
definition response extension" is not necessary =
anymore.
 
Why =
do not make things simpler, when they can be simpler ?  =
:-)
 
This =
leads to the following replacement:
 

OLD:

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

 

NEW:

 

   =
The "revoked" state indicates that the certificate has been =
revoked,
   =
either permanently or temporarily (i.e. certificateHold or =

   notIssuedOrIrregularlyIssued).  In =
particular, this state MAY be 
   returned if the responder knows that =
currently the serial number 
   from the requested certificate has not =
been used by the CA to issue 
   a certificate or has been used =
irregularly to issue a certificate.
 [Piyush] +1 again. 
I think it is important to capture =
the fact that this response may imply that CA may have been compromised. =
Use of “non-issued” hides that implication.
 
 
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. 
 
[Piyush] The note is a good idea. Do you think it makes sense to =
clarify why CRLs cannot be used in such cases? Folks not privy to the =
discussions on this list may get confused because 5280 implies that CRLs =
and OCSP are interchangeable.
 
 
The Note above =
will allow people that do not have followed the discussion on the PKIX =
mailing list 
to =
understand why we have chosen “revoked” rather than =
“unknown”, which would have been more =
natural.
 
This =
leads to another change, since the following sentence is not English, it =
uses the word "never"
which is inappropriate and omits to take into consideration =
certificates that have been irregularly =
issued:
 

OLD: = 

      o Section 2.2 extends =
the use of the "revoked" response to =
allow
         this =
response status certificates that has never been =
issued.
 
NEW:
 
      o Section 2.2 extends the =
use of the "revoked" response to also =

        allow this =
response status either for certificates that have =

        not been =
issued or that have been irregularly =
issued.
 
[Piyush] +1 . Distinction between not-issued and irregularly issued =
is important to have any meaningful discussion.
The above arguments =
lead to other changes. The text copied below, does not follow the order =
of the ASN.1 syntax 
and =
should be aligned with the above proposed =
text.


OLD:



   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.

NEW:

 
   When a responder responds revoked to a status =
request for a serial 
   number which has not been used by the CA =
or used irregularly to issue 
   a certificate, the responder MUST =
also:
 
    - specify the revocation date January 1, =
1970,
 
    - provide the RevocationReason : =
notIssuedOrIrregularlyIssued (7).
 
and =
also:


OLD:

      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.

NEW:


This section should be = deleted.

+1

 

Denis

------=_NextPart_000_00FB_01CDEFD1.103F9C60-- From mrex@sap.com Fri Jan 11 08:20:09 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 78E3521F8928 for ; Fri, 11 Jan 2013 08:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.159 X-Spam-Level: X-Spam-Status: No, score=-10.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 i7mc0UrM9o7H for ; Fri, 11 Jan 2013 08:20:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A023221F8929 for ; Fri, 11 Jan 2013 08:20:03 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0BGK19c000891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 17:20:01 +0100 (MET) In-Reply-To: <50F00BD4.2060302@bull.net> To: Denis Pinkas Date: Fri, 11 Jan 2013 17:20:01 +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: <20130111162001.ADEDF1A453@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:20:09 -0000 Denis, It's fascinating to see the whole scope of conceivable positions in this discussion. Piyush argues that the situation this change/update addresses is so rare that it is not worth bothering, and in particular that no reasonable RP would ever be sending OCSP requests for "non-issued" certs anyway. You seem to argue that there is an installed base which has covertly made the bold move to abuse the certificateHold ReasonCode in a fashion that it is *not* guaranteed to be used, and seem to lack back-off and reasonable recursion limits on the one hand, and that those OCSP clients could be coerced into making requests for non-issued certs that you have serious concerns about creating operational problem with the proposed update using certificateHold ReasonCode. I'm not in favour of breaking an installed base lightheartedly, although it sounds to me that like a somewhat unreasonable abuse if it really is so brittle that it makes you worry that much. When creatatively going beyond the official scope of a spec, one MUST ensure that the behaviour remains _safe_and_robust_ so that there can not occur any disastrous interference if someone else "bends" an interpretation into the opposite direction. Looping on certificateHold status to the level of operational risk status to me looks dangerously unsafe and significantly overstepping the boundaries of robustness for creatively re-interpreting protocol features. How real is the problem you outlined? Is there an official specification what exactly should be done (including limits that have to be observed) for certificateHold by the OCSP clients you have in mind? Should the suggestion to use/assign a new ReasonCode be adopted, then it would be important to describe it as being a TEMPORARY status, much like certificateHold and unlike all the other ReasonCodes. (I didn't see anything to that effect in your proposed text). Further, I stronlgy dislike the term "irregularly issued". This status is about certificate serials(!!) that are not found on the CA cert issue record. There is exactly ZERO point in trying to speculate why this is the case. It could have been something as beningn as a desaster recovery after some physical damage (fire, storm, flooding, earthquake), which resulted in recovery from backup and loss of records of issuance on that day. It could have been the result of a non-yet public progress on hash collisions. It could have been a simple software bug. For me, the a certificate earns the status "issued" only when it is created following the issuance procedures, gets recorded on the CAs cert issue log, becomes visible to auditing and can therefore be revoked upon request (not just through OCSP, but also through CRLs), and the CA can produce a proof-of-issuance on request. Calling a certificate "issued", for which there is no issue record visible to audits, no proof-of-issuance can be created and no revocation can be posted on a CRL, is a logical fallacy based on a design flaw in X.509. A humans existence is not proof of his birth. While most, if not all currently living humans might have been "born" (given birth by a human mother), alternative means are already technically conceivable, if not feasible today. I'm afraid they might become "commercially available" within my remaining lifetime (which to me is a pretty uncomfortable thought). -Martin From denis.pinkas@bull.net Fri Jan 11 08:24: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 A811821F842B for ; Fri, 11 Jan 2013 08:24:46 -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 1xeLHELbBah9 for ; Fri, 11 Jan 2013 08:24:41 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5921F8319 for ; Fri, 11 Jan 2013 08:24:37 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 7E9481CFDE; Fri, 11 Jan 2013 17:24:36 +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 2013011117243549-11363 ; Fri, 11 Jan 2013 17:24:35 +0100 Message-ID: <50F03CBF.6020007@bull.net> Date: Fri, 11 Jan 2013 17:24:31 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 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/01/2013 17:24:35, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/01/2013 17:24:36, Serialize complete at 11/01/2013 17:24:36 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------020704010506070407070703" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 16:24:47 -0000 This is a multi-part message in MIME format. --------------020704010506070407070703 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number". However, the use of certificateHold is not a good match, as it is explained below. The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal. You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons. Denis > The purpose is to signal that the serial number is CURRENTLY regarded > as revoked, but this may change in the future, i.e. a legitimate > certificate may be issued with this serial number. > Thus the certificateHold is a good match. > > /Stefan > > > From: Denis Pinkas > > Date: Friday, January 11, 2013 3:59 PM > To: Erwann Abalea > > Cc: > > Subject: Re: [pkix] About extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Erwann, > > Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED > > Case 7 is unused. > > Denis > > >> >> 2013/1/11 Denis Pinkas > > >> >> >> The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold >> >> as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment >> >> on that reason code. Depending of the content of the signature policy, these applications may "wait and >> >> come back later" to see if there is a change in the revocation status. That change will never happen >> >> if the certificate has not been regularly issued. >> >> >> >> It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. >> >> >> >> The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. >> >> >> If you're talking about bit instead of enumerated value, then >> you're talking about the "ReasonFlags" definition that is used in >> cRLDistributionPoints extension instead of the "CRLReason" >> definition used to indicate the revocation reason. And this >> "ReasonFlags" bit string already uses bit 7 ;) >> >> -- >> Erwann. > > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------020704010506070407070703 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it is explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons.

Denis


The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number.
Thus the certificateHold is a good match.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea <eabalea@gmail.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Erwann,

Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold 
as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment 
on that reason code. Depending of the content of the signature policy, these applications may “wait and 
come back later” to see if there is a change in the revocation status. That change will never happen 
if the certificate has not been regularly issued.
 
It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.
 
The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs.  

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

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

--------------020704010506070407070703-- From stefan@aaa-sec.com Fri Jan 11 08:49:42 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 9587721F89AA for ; Fri, 11 Jan 2013 08:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.167 X-Spam-Level: X-Spam-Status: No, score=-101.167 tagged_above=-999 required=5 tests=[AWL=-0.315, 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 uXnrtpMeif4s for ; Fri, 11 Jan 2013 08:49:39 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 369E621F8809 for ; Fri, 11 Jan 2013 08:49:37 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 87CA61E13AA0 for ; Fri, 11 Jan 2013 17:49:36 +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 1WTQk3n1NW1J for ; Fri, 11 Jan 2013 17:49:34 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 52BA21DD82EC for ; Fri, 11 Jan 2013 17:49:34 +0100 (CET) Received: (qmail 21319 invoked from network); 11 Jan 2013 16:49:34 -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 ; 11 Jan 2013 16:49:34 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 11 Jan 2013 17:49:44 +0100 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <50F03CBF.6020007@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3440771387_32813758" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 16:49:42 -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_3440771387_32813758 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Two things, 1) The purpose of this exercise is to provide a solution that works with legacy clients. That is, the output provided by the responder have to work and provide the desired effect when sent to a client using a current implementation of OCSP. 2) The extension was evidently required after discussions at the last IETF meeting to reach WG rough consensus on this mechanism. The reason being mainly to support audit when going back and examining what happened, it mus= t be evident that the responder operated using this extended definition of revoked. Therefore, the on hold bit is the only one that is known to represent a temporary revocation in current clients. And therefore the extension is needed. The rationale you give for not using certificateHold, is provide no problems. I see no obligation to help your client understand that this serial number will never be released from certificateHold. Because your client must always consider that as a possibility when seeing certificateHold, so it should not fail badly in any case. /Stefan From: Denis Pinkas Date: Friday, January 11, 2013 5:24 PM To: Stefan Santesson Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > =20 > =20 > Stefan, > =20 > We both agree that the serial number is CURRENTLY regarded as revoked, b= ut > this may change in the future, > i.e. a legitimate certificate may be issued with this serial number". > =20 > However, the use of certificateHold is not a good match, as it is expla= ined > below. > The use of the extended Revoked Extension defined in section 4.4.8 is a= n > overcomplication that is not necessary in my proposal. > =20 > You have provided no argument about the proposal for using case 7 in the > enumeration of CRL revocation reasons. > =20 > Denis > =20 > =20 > =20 > =20 >> =20 >> The purpose is to signal that the serial number is CURRENTLY regarded as >> revoked, but this may change in the future, i.e. a legitimate certificat= e may >> be issued with this serial number. >> =20 >> Thus the certificateHold is a good match. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas >> Date: Friday, January 11, 2013 3:59 PM >> To: Erwann Abalea >> Cc: >> Subject: Re: [pkix] About extended Revoked Extension defined in sectio= n >> 4.4.8 of ocsp draft 8 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> Erwann, >>> =20 >>> Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED >>> =20 >>> Case 7 is unused. >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>> =20 >>>>=20 >>>> =20 >>>> 2013/1/11 Denis Pinkas >>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> The re-use of onhold reason code is not meaningful, because it does n= ot >>>>> correspond to the meaning of onhold >>>>> =20 >>>>> as it is used today. Some applications dealing with electronic signat= ures >>>>> are already applying a specific treatment >>>>> =20 >>>>> on that reason code. Depending of the content of the signature policy= , >>>>> these applications may =B3wait and >>>>> =20 >>>>> come back later=B2 to see if there is a change in the revocation status= . >>>>> That change will never happen >>>>> =20 >>>>> if the certificate has not been regularly issued. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> It would be more appropriate to use a specific reason code that will = only >>>>> appear in OCSP Responses, and never in CRLs. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> The authors of RFC 5280 were very wise, because that have reserved bi= t 7 >>>>> for a purpose that is not supported in CRLs. >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> If you're talking about bit instead of enumerated value, then you're >>>> talking about the "ReasonFlags" definition that is used in >>>> cRLDistributionPoints extension instead of the "CRLReason" definition = used >>>> to indicate the revocation reason. And this "ReasonFlags" bit string >>>> already uses bit 7 ;) >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> --=20 >>>> Erwann.=20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ pkix mailing list >>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3440771387_32813758 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Two things,

1) The purpose of this exercise is to provide a solution that works= with legacy clients. That is, the output provided by the responder have to = work and provide the desired effect when sent to a client using a current im= plementation of OCSP.
2) The extension was evidently required afte= r discussions at the last IETF meeting to reach WG rough consensus on this m= echanism. The reason being mainly to support audit when going back and exami= ning what happened, it must be evident that the responder operated using thi= s extended definition of revoked.

Therefore, the on= hold bit is the only one that is known to represent a temporary revocation = in current clients.
And therefore the extension is needed.

The rationale you give for not using certificateHold, is p= rovide no problems.
I see no obligation to help your client unders= tand that this serial number will never be released from certificateHold.
Because your client must always consider that as a possibility when = seeing certificateHold, so it should not fail badly in any case.
<= br>
/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 5:24 PM
To: = Stefan Santesson <stefan@aaa-= sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in sec= tion 4.4.8 of ocsp draft 8

Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it = is explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons.

Denis


=
The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number.
=
Thus the certificateHold is a good match.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea <eabalea@gmail.com&= gt;
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Erwann,

Yes indeed, it is not a bit, since CRL= Reason ::=3D ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

The re-use of onhold reason c=
ode is not meaningful, because it does not correspond to the meaning of onho=
ld 
as it is used today. Some app=
lications dealing with electronic signatures are already applying a specific=
 treatment 
on that reason code. Dependin=
g of the content of the signature policy, these applications may “wait=
 and 
come back later” to see=
 if there is a change in the revocation status. That change will never happe=
n 
if the certificate has not be=
en regularly issued.
 
It would be more appropriate =
to use a specific reason code that will only appear in OCSP Responses, and n=
ever in CRLs.
 
The authors of RFC 5280 were =
very wise, because that have reserved bit 7 for a purpose that is not suppor=
ted in CRLs.  

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

_______________________________________________ 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_3440771387_32813758-- From piyush@ditenity.com Fri Jan 11 09:49: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 552AA21F894C for ; Fri, 11 Jan 2013 09:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GZdo0PBh3LmK for ; Fri, 11 Jan 2013 09:49:09 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id E223D21F88EA for ; Fri, 11 Jan 2013 09:49:08 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so2004262obb.12 for ; Fri, 11 Jan 2013 09:49:08 -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=ctHsxj1N1Jku6/gxZxy+uDx0M5DotSXfmdUTFLMkTq4=; b=lzxM9wnytF+m61tIZ111PN0e2cJIXnpNurhD4lx9Nq4y+U3xvXoi5Z6OHCNwHthW+F nTdjb/Qk88upILJrB80IqkdBCBGXJl2e5jiByz26/xuXrwIYn/nretHZfIdYQAQDzui9 QBgTn0X/ZqS9IooIvHPoGyW6Wch7u4fmRfoEB+TDPlBA0eaoyfXgubzWIP6WltAUv/Ug p2Wg/rpsK+Q7QbQ49dKBS2A00V8/u1v98p1yao5e39q6gWIol2FI+zUM54k3ao8+LPlf p729zJ/9Ic7IJx+MqCunQwwexytWQaYP17bOTyMPxZAMuokP6ssTQv+wTbxEKcQTrobh 9r9w== X-Received: by 10.60.171.11 with SMTP id aq11mr45128316oec.104.1357926548277; Fri, 11 Jan 2013 09:49:08 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id o3sm3997255obk.13.2013.01.11.09.49.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 11 Jan 2013 09:49:07 -0800 (PST) From: "Piyush Jain" To: , "'Denis Pinkas'" References: <50F00BD4.2060302@bull.net> <20130111162001.ADEDF1A453@ld9781.wdf.sap.corp> In-Reply-To: <20130111162001.ADEDF1A453@ld9781.wdf.sap.corp> Date: Fri, 11 Jan 2013 09:49:04 -0800 Message-ID: <002401cdf023$f38eb530$daac1f90$@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: AQIg/4/X3GPChSKVO2Xpt0Qu1PLx2peeQNWQ Content-Language: en-us X-Gm-Message-State: ALoCoQnTrR0ZfxnwBucpi2DX1Zo7pe9bzm9z1WfqKjSPmd1DVvmAPGP9sD/nxeCFTYyd3onAu+BF Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 11 Jan 2013 17:49:10 -0000 > Piyush argues that the situation this change/update addresses is so rare that it is not worth bothering, and in particular that no reasonable RP would ever be sending OCSP requests for "non-issued" certs anyway. [Piyush] I would love for someone to clear my misconception. And I think it is because my interpretation of "non-issued" is that the certificate does not exist and your definition includes both certificates that exist and certificates that do not exist. And yes, compliant RPs gain no knowledge by sending requests for certificates that do not exist to CA responders because they have no means to verify such a response in absence of payload certificate. > Further, I stronlgy dislike the term "irregularly issued". > This status is about certificate serials(!!) that are not found on the CA cert > issue record. There is exactly ZERO point in trying to speculate why this is the > case. It could have been something as beningn as a desaster recovery after > some physical damage (fire, storm, flooding, earthquake), which resulted in > recovery from backup and loss of records of issuance on that day. > It could have been the result of a non-yet public progress on hash collisions. > It could have been a simple software bug. [Piyush] Do you think it is important for relying party to know what the reason was? A distinction between revoked because of RA/CA compromise and revoked because of Disaster recovery is pretty important, at least from relying party's perspective. It does not matter if you call it irregularlyIssued or notYetIssued or certificateOnHold as long as the relying party clearly understands that such a response may imply that RA/CA was compromised. In case of former, depending on its risk tolerance, an RP might decide to consider all certificates issued by the CA as revoked, at least temporarily. BTW, the only practical use case that prompted this update was to provide CAB community to deal with DigiNotor like scenarios. From dharkins@lounge.org Fri Jan 11 10:00: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 1F31D21F8953 for ; Fri, 11 Jan 2013 10:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 LcEl4MtWQ0pw for ; Fri, 11 Jan 2013 10:00:46 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D80A521F894E for ; Fri, 11 Jan 2013 10:00:44 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6B2271022405A; Fri, 11 Jan 2013 10:00:44 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 11 Jan 2013 10:00:44 -0800 (PST) Message-ID: <0443f8e7501cc114087a0b9a0631e49b.squirrel@www.trepanning.net> In-Reply-To: <50C73BDF.4030508@gmail.com> References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> <50C73BDF.4030508@gmail.com> Date: Fri, 11 Jan 2013 10:00:44 -0800 (PST) From: "Dan Harkins" To: "M Jenkins" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "pkix@ietf.org" Subject: Re: [pkix] EST trust anchor definition 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, 11 Jan 2013 18:00:54 -0000 Hi Mike, Sorry for the delay in responding. On Tue, December 11, 2012 5:57 am, M Jenkins wrote: > Sorry, hadn't noticed that I didn't send this to the list. > > Hi Dan. I'm concerned that the client can trust the contents of the cert > (know that it has validated the correct cert) before it starts using the > contents to check the server name. Likewise for the server, if the > client has been initialized with an "enrollment certificate" (say by the > vendor; the trust anchor would be provided by the vendor separately to > the EST server operator). That is a valid concern but I'm not sure why the text and tables do not assuage it. In trying to better understand your concern I noticed in your mail below you say: "The draft does say that the client needs to be configured with the correct trust anchor (through out-of-band means), but after that all references to TAs are "TA Database". If I can't guarantee that I'm using the TA that I configured, there was no point in configuring one.' The point in configuring it is to enable its use. You can always guarantee that you're using the one you configured if that is the only one available. That is, you are not required to populate a 3rd party TA database in your client if you have no need for it and no intention to use it. If you have more than one TA database then you'll have to, as you say, 'dig through lots of cert guts' to determine what TA is used. The EST client (server) uses the TA databases. If it doesn't want to use one then it shouldn't use it and if it does use one (possibly by 'digging through lots of cert guts') then it should know how it came to treat the EST server's (client's) certificate as trustworthy. If I am misunderstanding your concern or do not understand the scenario that you're envisioning, please restate it. regards, Dan. > On 12/06/2012 01:01 PM, Dan Harkins wrote: >> Hello, >> >> Perhaps I'm missing something but the "selected TA database" is >> allowing >> the client to verify the trustworthiness of the EST server's >> certificate. The >> client is still supposed to decide whether this is the _correct_ EST >> server by >> checking the contents of the certificate against whatever policy might >> be configured as well as performing the TLS handshake and ensuring >> that the EST server holds the private analog to the authenticated public >> key it now holds. >> >> To stretch your analogy, the "selected TA database" is allowing you >> to >> determine whether this is a bonafide Schlage deadbolt lock that you're >> looking at. Whether it's _your_ bonafide Schlage deadbolt lock is the >> next step you have to do by putting your key into the lock and seeing >> whether it opens the door. If your neighbor's rabid dog bites you then >> it's a sign that 2 keys open the same door which is a failure of a >> different >> kind. >> >> Dan. >> >> On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote: >>> I suppose that helps - but it's more wordy and less clear, and >>> therefore >>> more prone to error. It's not that the system supporting the EST client >>> can't have a TA database - I'm assuming it will. It's that the database >>> is >>> irrelevant to the protocol. I don't unlock the lock on my front door >>> with >>> a >>> keyring, I do it with a key. Whether I only have one key, or whether I >>> have >>> 100, and whether I keep my 100 on a ring or in a box, is irrelevant. >>> >>> Crucially, I have to make sure the wrong thing doesn't happen. Say that >>> I >>> have a key to my neighbor's house. I want to enter my house. If my >>> neighbor's house and mine look alike, and I walk up to his house by >>> mistake, and I "use my keyring" to unlock the lock on the door - it >>> works! >>> Which is unfortunate for me, because his rabid dog just bit my leg. >>> >>> The problem I'm having with "TA Database" is that such databases are >>> generally designed to make things work, not to make things work only in >>> certain circumstances, as defined by the operator or local admin. It's >>> no >>> accident that most consumer systems come with a laundry-list of trust >>> anchors, and there generally isn't any notification to the operator >>> that >>> any particular one was used during any particular transaction. >>> >>> Saying "use the TA Database" requires me to think up all of the ways >>> that >>> applying the entire database to my protocol might fail, and say how to >>> prevent them. Saying "use only the XYZ trust anchor" is much more clear >>> and >>> precise. How to ensure that that particular trust anchor gets used is >>> up >>> to >>> the system designer - which is a good thing, because I don't think it's >>> desired that EST be limited to any one particular type of client >>> system. >>> >>> >>> On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin) >>> wrote: >>> >>>> (I corrected Peter Yee's email address) >>>> >>>> On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: >>>> >>>>> On Dec 4, 2012, at 9:55 PM, Michael Jenkins >>>>> wrote: >>>>> >>>>>> I think that the tables, broken out according to TAs and Certs, are >>>>>> a >>>> big improvement. However, the TA table has really taken a hard turn >>>> /away/ >>>> from the ability to specify a single TA as the one to use for EST. >>>>> What prevents the client from having a "Third-Party TA Database" that >>>> contains only TA's (or a single TA) to be used for EST? >>>>>> Without digging through a lot of cert guts over and over, I'll never >>>> know if any particular validation is terminating in the selected TA, >>>> be >>>> it >>>> a provided vendor-supplied initialization root, or a "public" CA, or a >>>> locally supplied root. I'm not prejudiced toward one or the other of >>>> those >>>> options, as long as it's the one I've initially configured - that is, >>>> as >>>> long as I have a way of expressing which TA must terminate my EST >>>> transactions. >>>>>> Ideally that would happen through some kind of labeling, but I don't >>>> think that there's anything that does that now, natively, in a system >>>> trust >>>> anchor store. Other solutions would be to remove all trust anchors >>>> /except/ >>>> the selected one (drastic, but might work for some specific-use >>>> devices), >>>> or to configure the EST client app with a keyID for the selected trust >>>> anchor (and then check that it's the one used). >>>>>> The draft does say that the client needs to be configured with the >>>> correct trust anchor (through out-of-band means), but after that all >>>> references to TAs are "TA Database". If I can't guarantee that I'm >>>> using >>>> the TA that I configured, there was no point in configuring one. >>>>> We can make this the "selected TA Database" and we can indicate that: >>>>> >>>>> "The Client MUST support a configurable option to enable checking all >>>> or >>>>> a subset of either the EST client Third-Party TA database or the EST >>>>> client TA database." >>>>> >>>>> Would that address your concerns? >>>>> >>>>> - max >>>>> >>>>> >>>>>> Hope that makes sense. If I'm interpreting the table incorrectly, >>>>>> let >>>> me know where I went wrong. >>>>>> Mike >>>>>> >>>>>> >>>>>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin)< >>>> pritikin@cisco.com> wrote: >>>>>> Thanks for all the feedback. We've already updated the table similar >>>> to >>>> what you recommend below so its good to see we're on the same page. >>>>>> Below is the current table in our working copy. I'll read through >>>> your >>>> suggestions carefully to see if additional clarity can be gained. >>>>>> Similarly I'll go through you other email of specific feedback and >>>> merge them to the revisions we've made since the ietf85 meeting. >>>>>> - max >>>>>> >>>>>> Current table in our working revision (best viewed in monospaced >>>> font): >>>>>> Certificates and their corresponding uses: >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> | Certificate | Issuer | Use and section references >>>> | >>>>>> +==============+====================+===============================+ >>>>>> | EST server | The CA served by | Presented by the EST server >>>> | >>>>>> | certificate | the EST server | during the TLS handshake >>>> | >>>>>> | | | >>>> | >>>>>> | | | Section 3.3.1.1 >>>> | >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> | EST server | A CA | Presented by the EST server >>>> | >>>>>> | certificate | authenticatable by | during the TLS handshake >>>> | >>>>>> | | a third-party TA | >>>> | >>>>>> | | | Section 3.3.1.1, and >>>> | >>>>>> | | | Security Considerations >>>> | >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> | EST client | A CA | Presented by the EST client >>>> | >>>>>> | certificate | authenticatable by | to the EST server by >>>>>> clients >>>> | >>>>>> | | a third-party TA | that have not yet enrolled >>>> | >>>>>> | | e.g., a device | >>>> | >>>>>> | | manufacturer | Section 3.3.1.2 >>>> | >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> | EST client | The CA served by | Presented by the EST client >>>> | >>>>>> | certificate | the EST server | to PKI End Entities. >>>> | >>>>>> | | | Including to the EST server >>>> | >>>>>> | | | during future EST >>>>>> operations >>>> | >>>>>> | | | >>>> | >>>>>> | | | Section 3.3.1.2 >>>> | >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> | EST client | The CA served by | Presented by the EST client >>>> | >>>>>> | certificate | the EST server | to PKI End Entities. >>>> | >>>>>> | | | Clients can obtain certs >>>> | >>>>>> | | | that can not be used for >>>>>> EST >>>> | >>>>>> | | | client authentication >>>> | >>>>>> | | | >>>> | >>>>>> | | | Section 4.4.1 >>>> | >>>>>> +--------------+--------------------+-------------------------------+ >>>>>> >>>>>> >>>>>> Figure 3 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Pritikin, et al. Expires May 21, 2013 [Page >>>> 12] >>>>>> Internet-Draft EST November >>>> 2012 >>>>>> >>>>>> Trust Anchor databases and their corresponding uses: >>>>>> +--------------+----------------------------------------------------+ >>>>>> | TA database | Use and section references >>>> | >>>>>> +==============+====================================================+ >>>>>> | EST server | EST servers use this TA database to authenticate >>>> | >>>>>> | TA database | certificates issued by the CA, including EST >>>> | >>>>>> | | client certificates during enroll/re-enroll >>>> | >>>>>> | | operations >>>> | >>>>>> | | >>>> | >>>>>> | | Section 3.3.1.2 >>>> | >>>>>> +--------------+----------------------------------------------------+ >>>>>> | EST server | EST servers use this TA database to authenticate >>>> | >>>>>> | Third-Party | certificates issued by third-party TAs. >>>> | >>>>>> | TA database | e.g., EST client certificates issued by a device >>>> | >>>>>> | | manufacturer >>>> | >>>>>> | | >>>> | >>>>>> | | Section 3.3.1.2 >>>> | >>>>>> +--------------+----------------------------------------------------+ >>>>>> | EST client | EST clients use this TA database to authenticate >>>> | >>>>>> | EST CA | certificates issued by the EST CA, including EST >>>> | >>>>>> | TA database | server certificates. >>>> | >>>>>> | | >>>> | >>>>>> | | Section 3.3.1.1 and >>>> | >>>>>> | | Section 4.3 >>>> | >>>>>> +--------------+----------------------------------------------------+ >>>>>> | EST client | EST clients use this trust anchor database to >>>> | >>>>>> | Third-Party | authenticate an EST server that uses an >>>>>> externally >>>> | >>>>>> | TA database | issued certificate. >>>> | >>>>>> | | >>>> | >>>>>> | | >>>> | >>>>>> | | Section 3.3.1.1 and >>>> | >>>>>> | | Security Considerations >>>> | >>>>>> +--------------+----------------------------------------------------+ >>>>>> >>>>>> >>>>>> Figure 4 >>>>>> >>>>>> On Nov 19, 2012, at 1:24 PM, M Jenkins >>>>>> wrote: >>>>>> >>>>>>> I think that the current EST draft is weak when it comes to talking >>>> about trust anchors. Many of the right ideas are there, but a bit >>>> scattered >>>> about. Figure (Table) 3 has a lot of this information, but there's >>>> some >>>> fuzz in it, and it's not very explicit about how crucial TA >>>> initialization >>>> is to the security of the protocol. >>>>>>> A specific concern is a perception that *any* trust anchor that >>>> happens to be in a trust anchor store might be used to terminate a >>>> certificate validation chain. The use of the phrase "third party Trust >>>> Anchor Database" is worrisome. Who cares if the TA comes from any >>>> (acceptable) third party - if you can't ensure that your validation >>>> chain >>>> is going to terminate in that TA in the first place? The present state >>>> of >>>> TA store management doesn't inherently provide this selectability. I >>>> think >>>> that explicit text is needed here. >>>>>>> I would suggest that table in Figure 3 be replaced with something >>>> like >>>> the following: >>>>>>> Trust Anchors >>>>>>> +--------------------------------------------------------------+ >>>>>>> | NOTE: EST Servers and Clients must be initialized to know | >>>>>>> | which specific public keys in their trust anchor | >>>>>>> | stores correspond to which function from this table. | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | CA Root | * End of validation path of all CA certs | >>>>>>> | public key | * End of validation path of Device Cert | >>>>>>> | | * May be identical to EST Server TA | >>>>>>> | | * May be identical to EST Client TA >>>>>>> | | * Obtainable by /CACerts command | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | EST Server TA | * End of validation path of EST Server cert | >>>>>>> | | * Must be securely installed to EST Client | >>>>>>> | | * Must be obtained securely, out-of-band | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | EST Client TA | * End of valid. path of EST Client init cert | >>>>>>> | | * Must be securely installed to EST Server | >>>>>>> | | * Must be obtained securely, out-of-band | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> >>>>>>> Certificates >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | CA Signing | * Crsp. private key signs Device Cert | >>>>>>> | Certificate | * Intermediate CA certs may exist in path | >>>>>>> | | * Obtainable by /CACerts command | >>>>>>> | | * Must be validated against CA Root >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | EST Server | * Used by EST Client during TLS handshake | >>>>>>> | Certificate | * Must be validated against EST Server TA | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | EST Client | * Used by EST Server during initial enroll | >>>>>>> | Init Cert | (if certificate TLS auth used) | >>>>>>> | | * Must be validated against EST Client TA >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | Device Cert | * Any certificate returned as a result of | >>>>>>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | >>>>>>> | | or /serverKeyGen | >>>>>>> | | * May be used for subsequent EST sessions | >>>>>>> +---------------+----------------------------------------------+ >>>>>>> | NOTE: The CA, EST Server, EST Client, and other servers may | >>>>>>> | have other certificates for other purposes, including | >>>>>>> | inter-server communication during EST sessions. | >>>>>>> +--------------------------------------------------------------+ >>>>>>> >>>>>>> Mike >>>>>> >>>> >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From piyush@ditenity.com Sat Jan 12 07:49: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 1AC1621F86BA for ; Sat, 12 Jan 2013 07:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 iALNgY0iFxVs for ; Sat, 12 Jan 2013 07:49:43 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E07521F86B7 for ; Sat, 12 Jan 2013 07:49:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2775983oag.3 for ; Sat, 12 Jan 2013 07:49:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=0HNRLC1WXZ+O7NCu2DG9ePHwlyjUn6jjUSI5VnfIVho=; b=SxjinTE7zZqxB9pwVvgiQtHolZCS6JgAv4aEQo+m7qdiNgQkbo37rLl7z/WtxGw6oe Sl8YJ3N22f5UjZf7fhmAHaIINMN/85rQmapmXR6j1IQSTe7IIbd9WM0vmCe2JuJXx6L6 BnZr5UDh57uSjDMAbYFHzcjeXe4hQ9iOxGNAvzXwGCtq4Ky/H0+MJmX7buEWi8oQvo1u LXiL23WCHSOxob1xw+5A1J1svChee34JMmyDSNFpm5TrcHCWAnYdUAPlRIJBrjrcLe0M kE5gnO0SgM8wQSpK5FTABzP4uubkQi69aW0QAelw6l580mpF1CXQUhVxKsmsJECuxY/B 9Y2Q== X-Received: by 10.60.23.200 with SMTP id o8mr46492573oef.48.1358005782316; Sat, 12 Jan 2013 07:49:42 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id d17sm6162390obu.0.2013.01.12.07.49.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 12 Jan 2013 07:49:41 -0800 (PST) From: "Piyush Jain" To: Date: Sat, 12 Jan 2013 07:49:34 -0800 Message-ID: <004b01cdf0dc$6c392c50$44ab84f0$@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: Ac3w2yCjmmR4xS5kS16Enxt73OldlQ== Content-Language: en-us X-Gm-Message-State: ALoCoQnwIqb295aFlWW+nwVpyP9ly1fRpweYGNEFNyDpWLjGa5QXV8BaCkFhlCYHNF7XnZKyYp8W Subject: [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 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, 12 Jan 2013 15:49:44 -0000 Hi list, Here is the proposal to address the issue in section 4.2.2.2 that I brought up in bullet point 4 of my original review post . You don't need to refer to that post. Context is provided below. CURRENT TEXT Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. 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: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that issued the certificate in question; or 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." ISSUES - Creates a paradox If (2) or (3) are used to establish trust in the response and if the response is marked as revoked because certificate was "not-issued". If the RP trusts response, it implies that the certificate was not issued by the CA which implies that the RP should not trust the response. This can be addressed by changing all references to "issued" to "signed" in the above text. Please not that this is a problem only for certificates that exist, not for non-existent certificate. RPs who send queries for non-existent certificates have no way to establish trust in the response if the response is signed by a delegated responder. - If the RP determines that certificate was signed by the CA and if the response is marked as revoked with extended revoked definition, it implies that RP has encountered a certificate signed by the CA for which CA has no record of issuance. Most likely cause for this is RA/CA compromise. Others have pointed out there may be some 'not so severe' reasons such as loss of issuance record etc. Unfortunately, there is no way for the responder to communicate the exact reason to the RP and RPs should assume the worst case scenario. PROPOSED TEXT Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. 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: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that signed the certificate in question; or 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is signed by the CA that signed the certificate in question as stated above." If the response trust is established by using either (1) or (2) and if the response status is revoked with reason code notIssuedOrIrregularlyIssued (7), it implies that the CA has no record of issuance of some of the certificates that were signed using its private key. In this case, it is recommended that the relying application considers the CA that issued the certificate in question as compromised for any current or future use. COMMENTS: I'm using Denis's proposal to represent "non-issued" by reason code notIssuedOrIrregularlyIssued(7). If the consensus is that we extended revoked extension is a better choice, then we can change the text accordingly. From prvs=0726ef6323=rybar@nbusr.sk Mon Jan 14 07:21:03 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 3CD3821F888A for ; Mon, 14 Jan 2013 07:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 xb-43lJtOGSS for ; Mon, 14 Jan 2013 07:21:00 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id CAD6221F89CE for ; Mon, 14 Jan 2013 07:20:58 -0800 (PST) Message-Id: <201301141520.r0EFKnM5078758@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , "'Piyush Jain'" , "'pkix'" Date: Mon, 14 Jan 2013 16:20:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CDF273.22F6E8A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Ac3wDPq0vETN7z2vRqaGAUWWYhBGmQCXFhJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4461> : streams <889593> : uri <1318742> Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 14 Jan 2013 15:21:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CDF273.22F6E8A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stefan, > A good protocol should provide a reasonable response to every = possible request. =20 I agree with such general sentence but rfc2560bis-08 is not able to fix = discussed situations.=20 Good view was dome by Piyush Jain [piyush@ditenity.com] in [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 =20 Let me propose another solution. We are trying to fix the situation, where the CA key was used for = signing certificate but CA is not able to provide evidence about it for = OCSP service. 1. It could be after disaster recovery procedure where the record was = lost because it was not archived. 2. Or when the CA key was compromised and was used for signing a fake = certificate. =20 I do not think that proposed solution =E2=80=9Cto provide revoked status = with a reason code certificateHold and extensions = id-pkix-ocsp-extended-revoke=E2=80=9D by OCSP to RP is helpful, because: 1. CA will not be informed about the potential inconsistency in the CA = database or about potential critical attack (DigiNotar); and=20 2. OCSP service will not be able to decide if it is a potential CA = compromise or only bad OCSP client is creating fake request because only = according to analyzing the certificate content true result can be = produces. Because according to rfc2560bis-08 the certificate is only on = the client side. 3. Solution is expensive and not useful because the signing of such = revocation response will only consume system key resources for creating = unclear response.=20 =20 At first, I propose to define a new type of the OCSP Responder error = message: OCSPResponseStatus ::=3D ENUMERATED { =E2=80=A6 probablyCADatabaseOrCAKeyCompromise (7) } =20 Or when solution is important to be understood by legacy clients then = what is defined for probablyCADatabaseOrCAKeyCompromise will be = applicable also for malformedRequest OCSP Responder error message:=20 In RFC must be defined rules for RP OCSP client applications where = client will be able to repeat the OCSP request but together with the = certificate for which OCSP Responder error message is = probablyCADatabaseOrCAKeyCompromise or malformedRequest. =20 This certificate will be included in singleRequestExtensions where the = extension will be identified with OBJECT IDENTIFIER id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise. =20 OCSP responder will analyze received certificate and in situations where = CA key was used the certificate will be provided to the CA for analysis = and making decisions. =20 The OCSP analysis will be the bases for the second OCSP response status = like: 1. Signed good, revoked if the certificate was missed only according to = recovery procedure; 2. Unsigned with OCSP Responder error message malformedRequest when the = CertID (issuerNameHash, issuerKeyHash, serialNumber) is not = corresponding to the form for which OCSP responder is able to provide = the status.=20 For example incorrect hash length in issuerNameHash or issuerKeyHash;=20 Incorrect serial number like when CA is using sequential number and in = request is present the serial number which is out of the maximum range = or is used unsigned/signed integer as a hash value stored in certificate = serial number=E2=80=A6 e.g. MD5 causes permanently problems with = negative serial numbers where some CA and client try to change the = negative integer of certificate serial number internally and are using = such positive integer in OCSP request what causes problems. 3. Unsigned with OCSP Responder error message unauthorized when OCSP = responder is not authorized for providing status for requested = issuerNameHash, issuerKeyHash; 4. Unsigned with OCSP Responder error message tryLater when certificate = was signed with CA key and CA must define decision what to do with it. =E2=80=A6 =20 I hope this proposal can be helpful as a starting point. =20 Peter Rybar National Security Authority Information Security and Electronic Signature Department =20 =20 =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Friday, January 11, 2013 4:05 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 From: Peter Rybar Date: Friday, January 11, 2013 3:38 PM To: Stefan Santesson , 'Piyush Jain' = , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Stefan, As you can see in my previous mail, when OCSP request contains incorrect = (malformed) serial number, because the certificate does not exist, the = OCSP Responder may return an error message malformedRequest or all other = types of responses except for revoked!!! =20 How does a serial number become malformed just because it doesn't = exists. Its just an integer. Its syntactically a well formed integer. =20 According to rfc2560bis is situation worse because the status revoked = which was about the real certificate status (in CRL or in previous OCSP = RFC) is now with extension of revoked with reason code certificateHold = defined as equivocal result when is not correctly implemented.=20 It means according to rfc2560bis all serial numbers are initially = revoked with reason code certificateHold=E2=80=A6 Is it useful? =20 Yes. =20 (The revoked with reason code certificateHold is based on CA database = and in some next steps database can also include the hash values of = certificates for positive statement!) =20 For that reason some systems and legislations where non-repudiation = services are required (e.g. QES) dictate that status value good or = revoked in OCSP response MUST contain a positive statement a hash value = of certificate in singleExtensions. =20 =20 Then that can be achieved by defining a new single response extension = that does not interfere with what is being done in 2560bis. =20 When hash of the certificate as a positive statement MUST be used, the = situations with OCSP responses for RP are clear and unique because: 1) good or revoked is only about know and issued certificates, =20 Great, so how then do you respond to a request for a serial number that = has never been issued? =20 2) any other situations are moved into one group which is unclear and = not analyzed =E2=80=93 no evidence, no responsibility. =20 But the responder still need to respond. =20 =20 It is a radical simplification! =20 Of what? =20 =20 Instead of trying to solve presently not practical and theoretical = situations from the responsibility/liability point of view (like = preparing us for situations: what we will offer for intergalactic green = man, are vegetarian? ;) we can define steps which can be implemented by = CAs and OCSP systems like usage of positive statement cert hash. =20 =20 Asking for status of a never issued serial number is not impossible. It = is not even hard. A good protocol should provide a reasonable response to every possible = request. =20 E.g. define new or reuse already defined in private OID space. PositiveStatement ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, certHash OCTET STRING, -- Hash of Subjects certificate } =20 And according it we cam move. =20 I have nothing against such extension being defined. But it still does not remove the need for the current discussed = mechanism. =20 The current discussed mechanism address how to respond to legacy clients = to requests for non-issued serial numbers. Your extension does not help, because it is not understood by legacy = clients. =20 So its not either or. =20 /Stefan =20 =20 Peter Rybar =20 =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, January 10, 2013 2:19 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Peter, i think the reason for this has been thoroughly debated. =20 It is correct that a cert serial number that was on hold, may be = released. The requested cert serial number may actually be used in a future = representing a real certificate. So this is intentional and the whole purpose behind using the on hold = reason. =20 /Stefan =20 From: Peter Rybar Date: Thursday, January 10, 2013 12:13 PM To: 'Piyush Jain' , Stefan Santesson = , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Stefan, For me is unclear how this extension of revoked with reason code = certificateHold is useful. It define that now is possible to revoke what does not exist and it open = never ending cycle of trying to fixing or correcting the first incorrect = status that "fake" cert serial number is revoked but cert serial number = is not revoked because "fake" cert does not exist. =20 I agree that extension of revoked can be helpful like: The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. =20 =20 When the certificate serial number is not in the OCSP database/CRL then = according to rfc2560bis there are defined following possible responses: 1. signed - good (e.g. certificate serial number is not listed in CRL) 2. signed - unknown (e.g. certificate serial number is not listed in = CRL) 3. unsigned =E2=80=93 unauthorized as an error message 4. signed - revoked where according to rfc2560bis are defined values = for: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC =20 What is missing? The rfc2560bis must also specify values for: This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC =20 X.509 defines the reason code certificateHold as 1) it may remain on the = CRL; 2) it may be replaced by a (final) revocation; 3) it may be = explicitly released; and=20 4) as a consequence of rfc2560bis the status of certificate serial = number indicated as revoked with reason code certificateHold can be = replaced with real status of a new real certificate which was issued = with the same certificate serial number as was asked in the incorrect = OCSP request created by insufficiently implemented applications where = the signature of the certificate was not checked with CA public key. =20 It is based on the following definitions: =20 According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/=20 =20 - good =E2=80=A6 is not revoked, (does not necessarily mean that the = certificate was ever issued)=E2=80=A6 - revoked =E2=80=A6 has been revoked (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.) - unknown =E2=80=A6 =20 When a responder responds revoked to a status request for a non- issued certificate, the responder MUST also; =20 - 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.=20 =20 =20 According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code = extension: http://www.itu.int/rec/T-REC-X.509 A certificate may be placed on hold by issuing a CRL entry with a reason = code of certificateHold. The certificate hold notice may include an = optional hold instruction code to convey additional information to = certificate users (see 8.5.2.3).=20 Once a hold has been issued, it may be handled in one of three ways:=20 a) it may remain on the CRL with no further action, causing users to = reject transactions issued during the hold period; or,=20 b) it may be replaced by a (final) revocation for the same certificate, = in which case the reason shall be one of the standard reasons for = revocation, the revocation date shall be the date the certificate was = placed on hold, and the optional instruction code extension field shall = not appear; or,=20 c) it may be explicitly released and the entry removed from the CRL. =20 =20 =20 -----Original Message----- From: Piyush Jain [mailto:piyush@ditenity.com]=20 Sent: Wednesday, January 09, 2013 6:17 PM To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' Subject: RE: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined = in > section 4.4.8 of ocsp draft 8 > Importance: High >=20 > Peter; >=20 > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >=20 > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. >=20 > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The = certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are = signed fraudulently. RPs won't make queries for certificate for which they = cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently = issued certificates unless you are saying that this specification will allow = for RPs to skip signature checking. >=20 > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. >=20 > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? >=20 > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already = used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. >=20 > No that is a task for another possible effort. > It's not part of this update. =20 [Piyush] Can you clarify what is the goal for this update? I think it is = one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. =20 But based on different threads on this topic I get confused about what = it is. Having the goal clear would help us keep the review of draft = focused.=20 =20 >=20 > But this update paves the way for such extension. Which I'm not = against. > It's just not part of this update effort. =20 >=20 > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status = the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records = in > >OCSP database will be use: > > -- unknown >=20 >=20 > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect = (to > indicate that a certificate with this serial number should not be trusted). >=20 > It's important that this works with legacy clients. They will be = around for a > while. >=20 [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting = "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". =20 > /Stefan >=20 > > > > > >_______________________________________________ > >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 _______________________________________________ pkix mailing list = pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 ------=_NextPart_000_0007_01CDF273.22F6E8A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Stefan,

=C2=A0> = A good protocol should provide a = reasonable response to every possible request.

 =

I agree with = such general sentence but rfc2560bis-08 is not able to fix discussed situations. =

Good view was = dome by Piyush Jain [piyush@ditenity.com] in

[pkix] = Addressing issues in 4.2.2.2 of rfc2560bis-08

 =

Let me propose = another solution.

We are trying to = fix the situation, where the CA key was used for signing certificate but CA is = not able to provide evidence about it for OCSP = service.

1. It could be = after disaster recovery procedure where the record was lost because it was not archived.

2. Or when the = CA key was compromised and was used for signing a fake = certificate.

 =

I do not think = that proposed solution =E2=80=9Cto provide revoked status with a reason code certificateHold and extensions id-pkix-ocsp-extended-revoke=E2=80=9D by OCSP to RP is helpful, because:

1. CA will not = be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and

2. OCSP service = will not be able to decide if it is a potential CA compromise or only bad OCSP = client is creating fake request because only according to analyzing the = certificate content true result can be produces. Because according to rfc2560bis-08 = the certificate is only on the client side.

3. Solution is = expensive and not useful because the signing of such revocation response will only = consume system key resources for creating unclear response. =

 =

At first, I = propose to define a new type of the OCSP Responder error = message:

OCSPResponseStatu= s ::=3D ENUMERATED { =E2=80=A6

=C2=A0=C2=A0=C2=A0= probablyCADatabaseOrCAKeyCompromise = (7)

}

 =

Or when solution = is important to be understood by legacy clients = then what is defined for probablyCADatabaseOrCAKeyCompromise= will be applicable also for malformedRequest OCSP Responder error message: =

In RFC must be = defined rules for RP OCSP client applications where client will be able to = repeat the OCSP request but together with the certificate for which OCSP Responder error message is = probablyCADatabaseOrCAKeyCompromise= or malformedRequest.=

 =

This certificate = will be included in singleRequestExtensions where the extension will be = identified with OBJECT IDENTIFIER

id-pkix-ocsp-<= span style=3D'font-weight:bold'>CertOfProbablyCADatabaseOrCAKeyCompromise.

 =

OCSP responder = will analyze received certificate and in situations where CA key was used the = certificate will be provided to the CA for analysis and making = decisions.

 =

The OCSP = analysis will be the bases for the second OCSP response status = like:

=C2=A01. Signed = good, revoked if the certificate was missed only according to recovery = procedure;

=C2=A02. = Unsigned with OCSP Responder error message malformedRequest when the CertID = (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to the form for which OCSP responder = is able to provide the status.

=C2=A0 For = example incorrect hash length in issuerNameHash or issuerKeyHash; =

=C2=A0 Incorrect = serial number like when CA is using sequential number and in request is present the = serial number which is out of the maximum range or is used unsigned/signed integer as a hash value = stored in certificate serial number=E2=80=A6 e.g. MD5 causes permanently problems = with negative serial numbers where some CA and client try to change the negative = integer of certificate serial number internally and are using such positive integer = in OCSP request what causes problems.

3. Unsigned with = OCSP Responder error message unauthorized when OCSP responder is not = authorized for providing status for requested issuerNameHash, = issuerKeyHash;

4. Unsigned with = OCSP Responder error message tryLater when certificate was signed with CA key and = CA must define decision what to do with it.

=E2=80=A6

 =

I hope this = proposal can be helpful as a starting point.

 =

Peter = Rybar
National Security Authority
Information Security and Electronic Signature = Department

 =

 

 

From: = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, January 11, = 2013 4:05 PM
To: Peter Rybar; = 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

 

 

From: Peter = Rybar <rybar@nbusr.sk>
Date: Friday, January 11, = 2013 3:38 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, 'Piyush = Jain' <piyush@ditenity.com>, 'pkix' = <pkix@ietf.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Stefan,
As you can see in my previous mail, when OCSP request =
contains incorrect (malformed) serial number, because the certificate =
does not exist, the OCSP Responder may return an error message =
malformedRequest or all other types of responses =
except for =
revoked!!!

 

How does a = serial number become malformed just because it doesn't exists. Its just an = integer.

Its = syntactically a well formed integer.

 

According to rfc2560bis is =
situation worse because the status revoked which was about the real =
certificate status (in CRL or in previous OCSP RFC) is now with =
extension of revoked with reason code =
certificateHold defined as equivocal result when is not correctly =
implemented. 
It means according to rfc2560bis all serial numbers are =
initially revoked with reason code =
certificateHold=E2=80=A6 Is it =
useful?

 

Yes.

 

(The revoked with reason code =
certificateHold is based on CA database and in some next steps database =
can also include the hash values of certificates for positive =
statement!)
 
For that reason some systems and legislations where =
non-repudiation services are required (e.g. QES) dictate that status =
value good or revoked in OCSP response MUST =
contain a positive statement a hash value of certificate in =
singleExtensions.
 

 

Then that can = be achieved by defining a new single response extension that does not = interfere with what is being done in 2560bis.

 

When hash of the certificate as a =
positive statement MUST be used, the situations with OCSP responses for =
RP are clear and unique =
because:
1) good or =
revoked is only about know and =
issued certificates,

 

Great, so how = then do you respond to a request for a serial number that has never been = issued?

 

2) any other situations are moved =
into one group which is unclear and not analyzed =E2=80=93 no evidence, =
no responsibility.

 

But the = responder still need to respond.

 

 
It is a radical =
simplification!

 

Of = what?

 

 
Instead of trying to solve presently not practical and =
theoretical situations from the responsibility/liability point of view =
(like preparing us for situations: what we will offer for intergalactic =
green man, are vegetarian? ;) we can define steps which can be =
implemented by CAs and OCSP systems like usage of positive statement =
cert hash.
 

 

Asking for = status of a never issued serial number is not impossible. It is not even = hard.

A good = protocol should provide a reasonable response to every possible = request.

 

E.g. define new or reuse already =
defined in private OID =
space.
PositiveStatement ::=3D SEQUENCE =
{
   hashAlgorithm    =
AlgorithmIdentifier,
   =
certHash         OCTET STRING, =
-- Hash of Subjects =
certificate
}
 
And according it we cam =
move.

 

I have = nothing against such extension being defined.

But it still = does not remove the need for the current discussed = mechanism.

 

The current = discussed mechanism address how to respond to legacy clients to requests for = non-issued serial numbers.

Your = extension does not help, because it is not understood by legacy = clients.

 

So its not = either or.

 

/Stefan

 

 
Peter =
Rybar

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Thursday, January = 10, 2013 2:19 PM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Peter, i = think the reason for this has been thoroughly = debated.

 

It is correct = that a cert serial number that was on hold, may be = released.

The requested = cert serial number may actually be used in a future representing a real = certificate.

So this is = intentional and the whole purpose behind using the on hold = reason.

 

/Stefan<= /u1:p>

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: Thursday, January = 10, 2013 12:13 PM
To: 'Piyush Jain' <piyush@ditenity.com>, Stefan = Santesson <stefan@aaa-sec.com>, = 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Stefan,<= /u1:p>

For me is unclear = how this extension of revoked with = reason code certificateHold is = useful.

It define that now = is possible to revoke what does not exist and it open never ending cycle of trying = to fixing or correcting the first incorrect status that "fake" = cert serial number is revoked but cert serial number is not revoked because = "fake" cert does not = exist.

 

I agree that = extension of revoked can be helpful = like:

   The "revoked" state indicates that =
the certificate has been =
revoked
   (either permanently =
or temporarily (on hold)). Response =
extensions
<=
font
size=3D2 color=3Dblack face=3D"Courier New">   may be used to =
convey additional information on assertions made =
by
   the responder =
regarding the status of the certificate such =
as
   positive statement =
about issuance, validity, =
etc.

 

 

When the certificate = serial number is not in the OCSP database/CRL then according to rfc2560bis = there are defined following possible = responses:

1. signed - =  good (e.g. certificate serial = number is not listed in CRL)<= o:p>

2. signed - =  unknown (e.g. certificate serial = number is not listed in CRL)<= o:p>

3. unsigned = =E2=80=93 unauthorized as an error message

4. signed - =  revoked where according to = rfc2560bis are defined values for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

 

What is missing? The = rfc2560bis must also specify values = for:

This Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC

 

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; = 2) it may be replaced by a (final) revocation; 3) it may be explicitly = released;

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced = with real status of a new real certificate which was issued with the same = certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the = certificate was not checked with CA public = key.

 

It is based on the = following definitions:

 
According to rfc2560bis the certificate status value =
is:
http:/=
/tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ =

 
   -  good =E2=80=A6 is not revoked, =
(does not necessarily mean that the =
certificate was ever =
issued)=E2=80=A6
   -  revoked =E2=80=A6 has been revoked =
(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.)
   -  unknown =
=E2=80=A6



 



   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
<=
font
size=3D2 color=3Dblack face=3D"Courier New">      =
certificates,
    - provide the revocation reason =
certificateHold (6), =
and;
    - specify the revocation date January 1, =
1970. 



 



 



According to ITU-T =
Rec. X.509
(11/2008), clause 8.5.2.2 Reason code =
extension:



http://www.itu.int/rec/T-REC-=
X.509



A certificate may be =
placed on
hold by issuing a CRL entry with a reason code of certificateHold. The
certificate hold notice may include an optional hold instruction code to =
convey
additional information to certificate users (see 8.5.2.3). =




Once a hold has been =
issued, it
may be handled in one of three ways: =




a) it may remain on =
the CRL
with no further action, causing users to reject transactions issued =
during the
hold period; or, 



b) it may be =
replaced by a
(final) revocation for the same certificate, in which case the reason =
shall be
one of the standard reasons for revocation, the revocation date shall be =
the
date the certificate was placed on hold, and the optional instruction =
code
extension field shall not appear; or, =




c) it may be =
explicitly
released and the entry removed from the =
CRL.



 



 



 



-----Original Message-----

From: Piyush Jain [mailto:piyush@ditenity.com]


Sent: Wednesday, January 09, 2013 6:17 PM

To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'

Subject: RE: [pkix] Question about extended Revoked Extension defined in
section 4.4.8 of ocsp draft 8



 



 



 



> -----Original =
Message-----



> From: Stefan Santesson [mailto:stefan@aaa-sec.com]



> Sent: Tuesday, January 08, =
2013 8:40
PM



> To: Peter =
Rybar;
'Piyush Jain'; =
'pkix'



> Subject: Re: [pkix] Question =
about
extended Revoked Extension defined =
in



> section 4.4.8 of ocsp draft =
8



> Importance: =
High



> =




> =
Peter;



> =




> On 1/8/13 5:18 PM, =
"Peter =
Rybar"
<rybar@nbusr.sk> =
wrote:



> =




> =
>Stefan,



> >The terminology is not =
clear for
someone who will =
see:



> >The revocation is of
"non-issued =
certificate".
=



> >Because by reading the =
text it is
expected that the certificate =
was



> >issued, but =
fraudulently.



> =




> What part of the text =
supports that?



[Piyush] None explicitly, but =
many would
infer it that way. The =
certificate



space that is covered by your =
interpretation
of "non-issued" =
includes



certificates which are not signed =
using
the CA key and those that are =
signed



fraudulently. RPs won't make =
queries for
certificate for which they =
cannot



verify the signature. So the only =
genuine
requests for =
"non-issued



certificates" coming to a =
responder
would be those for fraudulently =
issued



certificates unless you are =
saying that
this specification will allow =
for



RPs to skip signature =
checking.



> =




> =
>



> >The revocation with a =
new
extension is only about fraudulently =
issued



> >certificate. It means =
this new
extension and revocation is not =
used



> >when the certificate is =
not
issued and only fake random =
certificate



> >serial number was =
created in OCSP
request.



> =




> =
What?



> How in this physical =
universe would
the OCSP responder tell =
the



> =
difference???



> Crystal =
ball?



> =




> =
>



> >While it is intended =
only for
fraudulently issued certificate =
where



> >fraudulently issued =
certificate
can potentially reuse any already =
used



> =
>certificate-serial-number the extension
must contain e.g. a =
positive



> >confirmation of =
existence in the
form of hash value of =
fraudulently



> >issued =
certificate.



> =




> No that is a task for =
another
possible effort.



> It's not part of this =
update.



 



[Piyush] Can you clarify what is =
the goal
for this update? I think it is =
one



of the =
following



- Allow for extending definition =
of
revoked so other specifications =
can



extend the =
protocol



- Address handling of =
fraudulently issued
certificate.



- Address handling of any =
certificate not
issued by the CA.



 



But based on different threads on =
this
topic I get confused about what =
it



is. Having the goal clear would =
help us
keep the review of draft focused. =




 



> =




> But this update paves the =
way for
such extension. Which I'm not =
against.



> It's just not part of this =
update
effort.



 



> =




> =
>



> >Only according to the =
hash value
of fraudulently issued =
certificate



> >relaying party and OCSP =
responder
is able to identify =
fraudulently



> >issued certificate =
because CA was
compromised and serial numbers =
of



> >certificates are not any =
longer
unique for compromised =
CA.



> =
>



> =
>Conclusion:



> >Positive statement =
extension as a
hash value of the certificate =
whose



> >status OCSP response is =
providing
can be used in this =
case:



> >  when the =
certificate is
revoked,



> >  when the =
certificate is
good and also



> >  when the =
certificate is
fraudulently =
issued.



> =
>



> >For that reason it can =
be more
helpful to define in RFC one =
positive



> >statement extension as a =
hash
value of the certificate whose status =
the



> >OCSP response is =
providing and
define in RFC that it will =
support



> >situations when status =
is:



> >   -- =
good



> >   -- =
revoked



> >And for randomly created
certificate serial numbers without records =
in



> >OCSP database will be =
use:



> >   -- =
unknown



> =




> =




> No, we have been through =
this and
determined WG =
consensus.



> Unknown is not the choice, =
since it
may not have the desired effect =
(to



> indicate that a certificate =
with this
serial number should not =
be



trusted).



> =




> It's important that this =
works with
legacy clients. They will be =
around



for =
a



> =
while.



> =




[Piyush] That's an interesting =
usage of
the word "legacy". I don't =
think



that any of the previous versions =
of OCSP
recommended interpreting =
"unknown"


or UNAUTHORIZED(unsigned) =
responses to
imply that certificate can =
be



trusted. The right word would be =
to
"incorrectly implemented =
clients".



 



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

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

------=_NextPart_000_0007_01CDF273.22F6E8A0-- From piyush@ditenity.com Mon Jan 14 08:20:03 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 081D821F86C0 for ; Mon, 14 Jan 2013 08:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 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 mNdVc8vcNr9M for ; Mon, 14 Jan 2013 08:20:02 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5486A21F86C1 for ; Mon, 14 Jan 2013 08:20:02 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id vb8so3981258obc.6 for ; Mon, 14 Jan 2013 08:20:01 -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=m3SKf1KqzzrYE/488tziRMYF+AJ+TlONu84Ji5VcK/I=; b=gBZxKZS045IeZFpjm2ankKX3MWsxAm8t73DFYu4+BjZcQkp84uWtjgG/uE3A40Xo87 Cqk8wIN1y8bYnJ5ZC7tNPfZoPaLJyNV9kbQ8aq7FzmnlcEa8POkUbuBj9Ne2J5+NaEa5 Ww3JEE8HLvEkSGvoY//Nnn4fb5vSuyflsZTXJihqHzjGxVGerbWfDsfxY2xOSwWC+i0h wDwW5cLAPbZ+MZeT82YrjFJ/nCkakXGt/igYa5rrenAbk99L/AAH3VqIVqHT1nEBpBSJ wcp3Mq0uCPOfQtqU0C5kOZdsFXLDLbizVAeirxfT/Wpkxc4EW/yeoisar/LQsONSIn+z hwoQ== X-Received: by 10.182.182.68 with SMTP id ec4mr23080216obc.26.1358180401807; Mon, 14 Jan 2013 08:20:01 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id m3sm10789926obm.21.2013.01.14.08.19.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:20:01 -0800 (PST) From: "Piyush Jain" To: References: <002001cdefc9$e6075e80$b2161b80$@ditenity.com> <20130111080312.0ED361A450@ld9781.wdf.sap.corp> In-Reply-To: <20130111080312.0ED361A450@ld9781.wdf.sap.corp> Date: Mon, 14 Jan 2013 08:19:57 -0800 Message-ID: <01e201cdf273$007a0550$016e0ff0$@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: AQJ7LiirJOLwiFZboraSzoL1NhMSvpbuf+VA Content-Language: en-us X-Gm-Message-State: ALoCoQneFiQT6xG51sli7zgDkljnsYtGLp4r9VCH1g2KBWiC1BjOk+uZF7MGu5qZZpnKJVMZQBLi Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 14 Jan 2013 16:20:03 -0000 > The cert for which the status is requested would actually be pretty useless > for verifying the signature on the OCSP response. It will require the > _CA_cert_ that signed the cert for which the status is requested in order to > verify the OCSP response. [Piyush] True. It is not required for verifying signature on the resppnse. But it is required to ensure that the responder is authorized to sign responses for the certificate for which status is requested. > > While both, proxying and re-signing OCSP responses aren't possible in a "fully > dynamic" fashion, both should be possible for explicitly configured issuers, > where the proxy already knows the URL to the CA's OCSP responder and has > the necessary CA cert, and therefore can recognize the issuerNameHash and > issuerKeyHash in the CertID of the OCSP request, as well as verify the OCSP > response. [Piyush] "Verifying" in this context means more that signature checking. Yes, the proxy can establish that the signature on the response is correct, but it cannot establish that the response is applicable to the cert in question. > > Under these conditions, the actual cert for whose serial the status is > requested, seems entirely unnecessary. Are any common OCSP clients > actually including the cert for which they're requesting the status? My > Firefox doesn't seem to send it (says wireshark), although I don't have a local > OCSP responder to see whether this makes a difference. > [Piyush] You are correct. Clients do not send the certificates. But they establish trust in the responder by ensuring that the responder certificate is issued by the same entity as the one who issued the payload certificate. The more interesting fact is that directly trusted responders do not re-sign the response that they proxy to the CA responder. They only sign the response that they create locally. What's important is to understand the subtle difference between trusting that the response is signed by a particular entity, and that such a response is applicable to the cert being verified. The proxy should re-sign the response only if it knows that the response is applicable to the cert that its client is trying to validate, otherwise is should pass on the response without re-signing. BTW, Many folks fail to understand this subtle difference. But it becomes clear if just think of proxy as an OCSP client. Which model in section 4.2.2.2 can it use to establish trust in the CA responder? You'll see that the answer is none. So in such case, it ''ll be irresponsible for it to re-sign the response using it own key. -Piyush From mrex@sap.com Mon Jan 14 14:17: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 4D45921F84BC for ; Mon, 14 Jan 2013 14:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-XPETPYWRLO for ; Mon, 14 Jan 2013 14:17:43 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0221F84B2 for ; Mon, 14 Jan 2013 14:17:43 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0EMHYDS001884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jan 2013 23:17:35 +0100 (MET) In-Reply-To: <01e201cdf273$007a0550$016e0ff0$@ditenity.com> To: Piyush Jain Date: Mon, 14 Jan 2013 23:17:34 +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: <20130114221734.BF77E1A454@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 22:17:44 -0000 Piyush Jain wrote: > > > The cert for which the status is requested would actually be pretty > > useless for verifying the signature on the OCSP response. > > It will require the_CA_cert_ that signed the cert for which the > > status is requested in order to verify the OCSP response. > > [Piyush] True. It is not required for verifying signature on the resppnse. > But it is required to ensure that the responder is authorized to sign > responses for the certificate for which status is requested. Plain wrong conclusion. You failed to account for "public CA OCSP responder needs to be preconfigured on local OCSP responder". The local responder doesn't need and doesn't care about the certificate for which the status is requested. Verification of the OCSP response is possible with the admin-preconfigured information -- and both, proxying and re-signing OCSP responses is impossible without the preconfigured info. > > > > While both, proxying and re-signing OCSP responses aren't possible in a > > "fully dynamic" fashion, both should be possible for explicitly > > configured issuers, where the proxy already knows the URL to the > > CA's OCSP responder and has the necessary CA cert, and therefore > > can recognize the issuerNameHash and issuerKeyHash in the CertID > > of the OCSP request, as well as verify the OCSP response. > > [Piyush] "Verifying" in this context means more that signature checking. With respect to the OCSP protocol (rfc2560), it clearly does not! > > Yes, the proxy can establish that the signature on the response is correct, > but it cannot establish that the response is applicable to the cert in > question. An perfectly valid and reasonable rfc2560 will not and need not care. Which does not preclude that you build an implementation that does it anyway, but that is not a prerequsite from a spec, and your proxy would probably return errors to all common OCSP clients because of their lack to include the certificate in their request to the local responder. Arguably, your implementation of an rfc2560 local OCSP responder could be described as not being a correct implementation of rfc2560. > > > > Under these conditions, the actual cert for whose serial the status is > > requested, seems entirely unnecessary. Are any common OCSP clients > > actually including the cert for which they're requesting the status? My > > Firefox doesn't seem to send it (says wireshark), although I don't have a > > local OCSP responder to see whether this makes a difference. > > [Piyush] You are correct. Clients do not send the certificates. But they > establish trust in the responder by ensuring that the responder certificate > is issued by the same entity as the one who issued the payload certificate. Funny. Now you're agreeing that an OCSP proxy doesn't need to care, and that it is the expected duty of (only) the RP doing the revocation check to ensure that the OCSP response properly matches the certificate under investigation. > > The more interesting fact is that directly trusted responders do not re-sign > the response that they proxy to the CA responder. They only sign the > response that they create locally. But a local OCSP responder could perfectly well proxy OCSP requests and re-sign responses rather than just operating exclusively on CRLs. > > What's important is to understand the subtle difference between trusting > that the response is signed by a particular entity, and that such a response > is applicable to the cert being verified. That subtle difference is only relevant to the RP. It is irrelevant to a local OCSP responder who decides to proxy OCSP requests and re-sign the responses rather than feeding exclusively only on CRLs. > > The proxy should re-sign the response only if it knows that the response is > applicable to the cert that its client is trying to validate, otherwise is > should pass on the response without re-signing. This is definitely no something suggested or implied by the OCSP protocol specified in rfc2560. It might be something that you may want from your own implementation, but it is extremely important for discussions about standardization that you realize the difference here. -Martin From piyush@ditenity.com Mon Jan 14 16: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 5BAC921F8B75 for ; Mon, 14 Jan 2013 16:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 2JvDTQA9HaJr for ; Mon, 14 Jan 2013 16:06:45 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id B6C8921F8B70 for ; Mon, 14 Jan 2013 16:06:45 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i18so4684126oag.18 for ; Mon, 14 Jan 2013 16:06:45 -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=HYm2qwmYb8vDXN1GNCALRrOleSe6cisJXKfMk4HXMAU=; b=NQuFN+Wc8CJFLvQD7XoMqrQN8ijPupacBTq01K5mPjTNWhrX7xrAo+GOmrV5q6PDZJ a6vjHZCbTw6TrlN7mfL7OHCyjHW0HeIX/eM57QEhoT6Zbdx103yeJCjJhBTTvwTQv09x L3xQgk/m/tH3Eu8p4eSvbinRZYYUu9o1ojc0p4qLypHsFK8f/tTDtBp9qppgWFgXKO31 1WVMC67JiWA9V0c6mwA0aMmZPJ1tZOYfXxedrqNrYcwVoM4VlbVC42JKuDjjFgVt3xSH pOIsvj62E/UAgW2aVxHNndzbH1x3cBagi6nt4sHRlODX5y9aEZ5pOebtgEzgP8o6dqVT 0M4g== X-Received: by 10.182.159.102 with SMTP id xb6mr9313639obb.36.1358208405103; Mon, 14 Jan 2013 16:06:45 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id aw4sm12118666oec.9.2013.01.14.16.06.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 16:06:44 -0800 (PST) From: "Piyush Jain" To: References: <01e201cdf273$007a0550$016e0ff0$@ditenity.com> <20130114221734.BF77E1A454@ld9781.wdf.sap.corp> In-Reply-To: <20130114221734.BF77E1A454@ld9781.wdf.sap.corp> Date: Mon, 14 Jan 2013 16:06:40 -0800 Message-ID: <02c901cdf2b4$3328f650$997ae2f0$@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: AQIU4N8GdM4/XyodV+qy16b22J2BUZe7kE9A Content-Language: en-us X-Gm-Message-State: ALoCoQmTFQeksZ5evSkUkX7CXb2wAdOS4NgJ9hY7WQl9jKHQfhWbMLvgFyn4yZoNf/XStpWMYmK7 Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 00:06:46 -0000 > Plain wrong conclusion. You failed to account for "public CA OCSP responder > needs to be preconfigured on local OCSP responder". The local responder > doesn't need and doesn't care about the certificate for which the status is > requested. Verification of the OCSP response is possible with the admin- > preconfigured information -- and both, proxying and re-signing OCSP > responses is impossible without the preconfigured info. [Piyush] Fair enough. What you are saying that client directly trusts the local responder and local responder trusts the CA responders based on local configuration. I agree that certificate is not required to accept a response if you trust the responder directly. However, This whole discussion was about CA delegated responder/CA responder and whether the payload certificate is required to verify a response from such responders. You provide an example in which you use direct trust model in both the client and the proxy. And on the basis of that you claim that payload certificate is not required to establish trust in a response issued by CA/CA delegated responders. From piyush@ditenity.com Mon Jan 14 16:17: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 E5DEC21F8B4C for ; Mon, 14 Jan 2013 16:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 EzOCJ1VpGpwj for ; Mon, 14 Jan 2013 16:17:04 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1498C21F8994 for ; Mon, 14 Jan 2013 16:17:03 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so4681901oag.9 for ; Mon, 14 Jan 2013 16:17:03 -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=kS09d24rrRgJmROJNeIVrmRPAG+wog3mAssH9+tOvvM=; b=izZYUaY68X2cOtj75Cje1rqfP9gweANgsMrcBGpCNPYA5qCUJWgyesHQfjZjUwj2Dg LCc+KGq/DBxlWBaUPNAfC0sGiLxhEloU6L46LoM6/iLy4qzOpxwhqaaYXNyk6JaMNKoI vc0L7EI1NVvvJNjRZwf6u2lhgq7Mgcs+szbuJy2fn+lJq2kZvKkWk80joAtZG+pKH8r6 ynp+bDtSPQuc/DBPlo9ylEuXj+XtjtWU4Ve+3uP6/2rM/dLHdIeNbFr3t6BOjnWq6i3E xpxoZm0jcRvdtf0QTq/NQwNGn75hF6lf1sMkEjOvNHFGofTZtXYYUaPJ7S6/7oNlIsD9 bYdg== X-Received: by 10.182.73.4 with SMTP id h4mr62398686obv.18.1358209023464; Mon, 14 Jan 2013 16:17:03 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id aw4sm12140654oec.9.2013.01.14.16.17.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 16:17:03 -0800 (PST) From: "Piyush Jain" To: References: <004b01cdf0dc$6c392c50$44ab84f0$@ditenity.com> In-Reply-To: <004b01cdf0dc$6c392c50$44ab84f0$@ditenity.com> Date: Mon, 14 Jan 2013 16:16:59 -0800 Message-ID: <02cb01cdf2b5$a3eca610$ebc5f230$@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: AQMMLUzWuxF9OdE2vr4K4/K7XRtq1pXNDn5w Content-Language: en-us X-Gm-Message-State: ALoCoQlEd1Sfb1UXe7KnS/S2G+MLO32EzQ6FOb/iVny+vDSGxRGSYEWSRHwOqxON0kTZlNNkaSR/ Subject: Re: [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 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, 15 Jan 2013 00:17:05 -0000 I just realized that even my new proposal does not fix the paradox if the RP decides to consider the CA as compromised in context of current transaction. Unfortunately, I don't see any way to resolve this paradox under existing OCSP trust models. Here is the revised text where I changed the recommendation to consider CA compromised for future use instead of current and future uses. It is akin to saying - Trust me for once when I say "I always lie" :). NEW PROPOSED TEXT Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. 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: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that signed the certificate in question; or 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is signed by the CA that signed the certificate in question as stated above." If the response trust is established by using either (1) or (2) and if the response status is revoked with reason code notIssuedOrIrregularlyIssued (7), it implies that the CA has no record of issuance of some of the certificates that were signed using its private key. In this case, it is recommended that the relying application considers the CA that issued the certificate in question as compromised for any future use. > -----Original Message----- > From: Piyush Jain [mailto:piyush@ditenity.com] > Sent: Saturday, January 12, 2013 7:50 AM > To: pkix@ietf.org > Subject: Addressing issues in 4.2.2.2 of rfc2560bis-08 > > Hi list, > > Here is the proposal to address the issue in section 4.2.2.2 that I brought up > in bullet point 4 of my original review post . You don't need to refer to that > post. Context is provided below. > > CURRENT TEXT > > Systems or applications that rely on OCSP responses MUST be capable of > detecting and enforcing use of the id-kp-OCSPSigning value as described > above. They MAY provide a means of locally configuring one or more OCSP > signing authorities, and specifying the set of CAs for which each signing > authority is trusted. 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: > 1. Matches a local configuration of OCSP signing authority for the certificate > in question; or > 2. Is the certificate of the CA that issued the certificate in question; or > 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." > > ISSUES > - Creates a paradox If (2) or (3) are used to establish trust in the response > and if the response is marked as revoked because certificate was "not- > issued". If the RP trusts response, it implies that the certificate was not > issued by the CA which implies that the RP should not trust the response. > This can be addressed by changing all references to "issued" to "signed" in > the above text. Please not that this is a problem only for certificates that > exist, not for non-existent certificate. RPs who send queries for non-existent > certificates have no way to establish trust in the response if the response is > signed by a delegated responder. > - If the RP determines that certificate was signed by the CA and if the > response is marked as revoked with extended revoked definition, it implies > that RP has encountered a certificate signed by the CA for which CA has no > record of issuance. Most likely cause for this is RA/CA compromise. Others > have pointed out there may be some 'not so severe' reasons such as loss of > issuance record etc. Unfortunately, there is no way for the responder to > communicate the exact reason to the RP and RPs should assume the worst > case scenario. > > PROPOSED TEXT > > Systems or applications that rely on OCSP responses MUST be capable of > detecting and enforcing use of the id-kp-OCSPSigning value as described > above. They MAY provide a means of locally configuring one or more OCSP > signing authorities, and specifying the set of CAs for which each signing > authority is trusted. 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: > 1. Matches a local configuration of OCSP signing authority for the certificate > in question; or > 2. Is the certificate of the CA that signed the certificate in question; or > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension > and is signed by the CA that signed the certificate in question as stated > above." > > If the response trust is established by using either (1) or (2) and if the > response status is revoked with reason code notIssuedOrIrregularlyIssued > (7), it implies that the CA has no record of issuance of some of the certificates > that were signed using its private key. In this case, it is recommended that > the relying application considers the CA that issued the certificate in question > as compromised for any current or future use. > > COMMENTS: > I'm using Denis's proposal to represent "non-issued" by reason code > notIssuedOrIrregularlyIssued(7). If the consensus is that we extended > revoked extension is a better choice, then we can change the text > accordingly. From piyush@ditenity.com Mon Jan 14 16:38:47 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 AFDDA21F8B61 for ; Mon, 14 Jan 2013 16:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 717oLNAsOJDu for ; Mon, 14 Jan 2013 16:38:47 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id F32F121F8B60 for ; Mon, 14 Jan 2013 16:38:46 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id dn14so4505343obc.16 for ; Mon, 14 Jan 2013 16:38:46 -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=WIQOsfdfCSLTyCS82np7UWetM1omCS+wFrn6Qllvakg=; b=j2IWT83jCc4TaCfN0qKU+BqhBZ4mO6XCErenv3q8lM9Y05FuYFMiz5Db6wAMbJcNMd FSkt/CqmKaqvQvfN1u891UYDm7WajSM5jDJiEXh6DFHHgKbCPeRU0SbQTpg1OdKi+JKM TgJXV1o+AgvYDJAbEXHi1SVgaRjyBV9pfVNADd6D0hpZr+zLR5aXjmbzh5vwjbj0IC+i auMRFohqmxskh9FtZaC/pPQ1FJAGLD2dAOw6YWg95C3h8B+FvwiyALkywj2p1nNVgOgb migfX1+3Cffmb4QmWQgIHuELLfWGqCAWIT3F/WeXnZeDfNaD7vv9ezZ6gCCtOVpCcOR1 N20g== X-Received: by 10.60.172.178 with SMTP id bd18mr54879034oec.133.1358210326385; Mon, 14 Jan 2013 16:38:46 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id rn9sm7140301obb.11.2013.01.14.16.38.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 16:38:45 -0800 (PST) From: "Piyush Jain" To: References: <008a01cdef72$166e4cd0$434ae670$@ditenity.com> <20130111070044.5385A1A449@ld9781.wdf.sap.corp> In-Reply-To: <20130111070044.5385A1A449@ld9781.wdf.sap.corp> Date: Mon, 14 Jan 2013 16:38:42 -0800 Message-ID: <02cd01cdf2b8$ac32b140$049813c0$@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: AQKBDWNBJRWpVQcM9grkpQCp/AztvJbjVAaQ Content-Language: en-us X-Gm-Message-State: ALoCoQnaqC1YB//FbnvCbh8jYZiQWWTiGpHpq4vfWlnqOSu637MlY5zu9VfpCaQww0fVNVRr4jfE Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 00:38:47 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, January 10, 2013 11:01 PM > To: Piyush Jain > Cc: mrex@sap.com; 'Stefan Santesson'; 'Peter Rybar'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Piyush Jain wrote: > > > > Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective. > > Are you aware of rfc-2560 Section 2.7? > [Piyush] Yup. A responder product that I worked on long time ago has support for it since last 10 years. > 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. > > As you can see, even rfc2560 has been suggesting all the time, that when the > OCSP responder is aware of a CA key compromise, it MAY return a revoked > response as a safety precaution for cert serials that are suspect to (or even > positively known to) not be validly issued certs. > > This MAY implies "at the discretion of the responder", and includes > selectively returning "revoked", e.g. if it wasn't a complete CA compromise, > but only a fraudulent cert creation for which CA issue records may have been > destroyed -- so the existence of fraudulent certs could be invisible to any > audits. Du to the lack of issue records, it is also not possible to revoke such > certs in the X.509 sense, since it is unknown how many there are, what > serials they carry, and whether they share the serials of "innocent" certs that > exist on the CA cert issue record. > [Piyush] Not sure if I agree that "MAY return the revoked state for all certificates issued by that CA" implies "MAY return the revoked state for some certificates issued by that CA" but I'll bite. So what's the need for the update? 2560 already allows what you want to do. Return revoked with CA compromised as the reason code for such certificate. > > -Martin -Piyush From mrex@sap.com Mon Jan 14 17:18: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 7967A21F87D2 for ; Mon, 14 Jan 2013 17:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 7vyI57FsWvVs for ; Mon, 14 Jan 2013 17:18:06 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A85C021F86CE for ; Mon, 14 Jan 2013 17:18:05 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0F1I2CC026645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2013 02:18:02 +0100 (MET) In-Reply-To: <02cd01cdf2b8$ac32b140$049813c0$@ditenity.com> To: Piyush Jain Date: Tue, 15 Jan 2013 02:18:02 +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: <20130115011802.298481A454@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 01:18:06 -0000 Piyush Jain wrote: > > > 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. > > [Piyush] Not sure if I agree that "MAY return the revoked state for all > certificates issued by that CA" implies "MAY return the revoked state for > some certificates issued by that CA" but I'll bite. > So what's the need for the update? 2560 already allows what you want to do. > Return revoked with CA compromised as the reason code for such certificate. I'm perfectly OK for an OCSP responder to return the reason code cACompromise(2) for those cert serials which do appear on a current CRL with that very ReasonCode or are scheduled to appear with that very ReasonCode on the next base CRL. But for certs where the CA can not make any assessment about its status, and where in particular, it is possible that a valid cert with that serial might still get created in the future, the OCSP responder ought to abstain from asserting any ReasonCode with the semantics of a permanent/final revocation and probably also abstain from currently unknown reason codes, if the desire of this update is to make it comprehensible to the installed base of rfc2560. CertificateHold asserts that the status for this cert serial is currently undecided. the certificatHold status _might_ simply disappear at some indeterminate point the future, or _might_ be replaced with a permanent/final revocation. Since neither X.509 nor PKIX specify any time limit specified for how long a certificateHold status may last, RPs MUST assume that it may last essentially forever (=beyond the lifetime of the CA cert). If CAs or RPs would want to establish special semantics for batched processing of signed request and queuing&re-processing of requests for which the OCSP-based revocation check returned the status certificateHold, then these CAs and RPs ought to use OCSP extensions to convey either a GeneralizedTime at which point in the future retrying the OCSP status request should be attempted (=polling), or whether and at which time the OCSP responder (or CA) will have determined a final/permant status for this cert serial. Trying to infer anything beyond "do not trust this cert NOW" from a plain certificateHold status would be silly, and can be characterized as an implementation bug. -Martin From wwwrun@rfc-editor.org Mon Jan 14 17:33: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 C6FAC21F8473; Mon, 14 Jan 2013 17:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sh5vxK84dpN; Mon, 14 Jan 2013 17:33:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 639B621F8415; Mon, 14 Jan 2013 17:33:26 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EAEDA622E9; Mon, 14 Jan 2013 17:22:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130115012241.EAEDA622E9@rfc-editor.org> Date: Mon, 14 Jan 2013 17:22:37 -0800 (PST) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] RFC 6818 on Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 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, 15 Jan 2013 01:33:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6818 Title: Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author: P. Yee Status: Standards Track Stream: IETF Date: January 2013 Mailbox: peter@akayla.com Pages: 8 Characters: 17439 Updates: RFC5280 I-D Tag: draft-ietf-pkix-rfc5280-clarifications-11.txt URL: http://www.rfc-editor.org/rfc/rfc6818.txt This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mrex@sap.com Mon Jan 14 17:51:37 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 C10B821F8AC0 for ; Mon, 14 Jan 2013 17:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 VzVUCJzxLCf1 for ; Mon, 14 Jan 2013 17:51:37 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D2FF321F8AF2 for ; Mon, 14 Jan 2013 17:51:36 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0F1pX0x023663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2013 02:51:33 +0100 (MET) In-Reply-To: <02c901cdf2b4$3328f650$997ae2f0$@ditenity.com> To: Piyush Jain Date: Tue, 15 Jan 2013 02:51:33 +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: <20130115015133.C5C9C1A454@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 01:51:37 -0000 Piyush Jain wrote: > > > Plain wrong conclusion. You failed to account for "public CA OCSP > > responder needs to be preconfigured on local OCSP responder". > > The local responder doesn't need and doesn't care about the > > certificate for which the status is requested. Verification > > of the OCSP response is possible with the admin-preconfigured > > information -- and both, proxying and re-signing OCSP > > responses is impossible without the preconfigured info. > > [Piyush] Fair enough. What you are saying that client directly trusts the > local responder and local responder trusts the CA responders based on local > configuration. > I agree that certificate is not required to accept a response if you trust > the responder directly. The concept of a local OCSP responder is undoubtedly based on the notion that the local OCSP responder puts a local signature on an assertion (=OCSP response) about certificate serial status which itself has determined based on revocation status information from a pre-configured issuing CA. Whether an OCSP responder obtains the revocation status information from a pre-configured issuing CA by CRLs, delta-CRLs, OCSP or direct access to the CA cert database is irrelevant for the OCSP protocol between this OCSP responder and an RP that trusts this OCSP responder (independent of whether that trust is due to rfc2560 4.2.2.2 (1), (2) or (3)). > > However, This whole discussion was about CA delegated responder/CA responder > and whether the payload certificate is required to verify a response from > such responders. > You provide an example in which you use direct trust model in both the > client and the proxy. And on the basis of that you claim that payload > certificate is not required to establish trust in a response issued by CA/CA > delegated responders. This really isn't about some specific example. This applies to the whole concept of local OCSP responders and applies _each_and_every_time_ when an OCSP client determines rfc2560 section 4.2.2.2 (1) to apply. 4.2.2.2 Authorized Responders 1. Matches a local configuration of OCSP signing authority for the certificate in question A local OCSP responder that itself obtained the certificate serial status in form of a CRL or delta CRL is effectively re-signing that certificate serial status information when creating an OCSP response from CRLs. Probably most, if not all existing OCSP responders, i.e. including regular OCSP responders (direct and designated), are operating in such a fashion that they obtain cert serial status in some local trusted fashion, and then create from that trusted information an OCSP response and (re-)sign this response with their OCSP responder key. -Martin From mrex@sap.com Mon Jan 14 20: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 42A1111E80A3 for ; Mon, 14 Jan 2013 20:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 tcjUM47KqPXX for ; Mon, 14 Jan 2013 20:15:23 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10C11E809C for ; Mon, 14 Jan 2013 20:15:23 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0F4FJkc011442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2013 05:15:20 +0100 (MET) In-Reply-To: <201301141520.r0EFKnM5078758@mail.nbusr.sk> To: Peter Rybar Date: Tue, 15 Jan 2013 05:15:19 +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: <20130115041519.D34291A455@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 04:15:24 -0000 Peter Rybar wrote: > > Let me propose another solution. > > We are trying to fix the situation, where the CA key was used for > signing certificate but CA is not able to provide evidence about > it for OCSP service. Actually, this is _NOT_ what were trying to accomplish. The OCSP update is about discontinuing to return "good" when the OCSP responder has access to the CA's cert issue records and can not find any proof-of-existence that the cert serial in the OCSP request refers to a properly issued certificate. At the abstract level, we do _not_ care how this happened, This change will also standardize the behaviour used by DigiNotar to mitigate the problem of misissued certs for which they did not have any records of issuance because these had been purposely destroyed. > > I do not think that proposed solution ?to provide revoked status > with a reason code certificateHold and extensions > id-pkix-ocsp-extended-revoke? by OCSP to RP is helpful, because: > > 1. CA will not be informed about the potential inconsistency in the > CA database or about potential critical attack (DigiNotar); and a) That is an entirely seperate issue. b) It is up to CAs to decide what to do about OCSP requests for "not issued" cert serials that are received by OCSP responders to which CAs have granted access to the cert issue records. c) As you can see in X.509 08/2005 (the one referenced by PKIX/rfc5280) section 8.5.2.1 "Hold instruction code extension", it has always been the intention that any instructions about actions that a CA expects RPs to perform (beyond "do not trust this cert NOW") ought to be conveyed through extensions with clearly defined semantics, rather than wild guessing on the part of the RP. d) the installed base of rfc2560 is quite unlikely to notice, and unlikely to react to any extensions that we might include in the OCSP response, therefore is conside (1) as a bogus requirement. > > 2. OCSP service will not be able to decide if it is a potential > CA compromise or only bad OCSP client is creating fake request > because only according to analyzing the certificate content true > result can be produces. Because according to rfc2560bis-08 the > certificate is only on the client side. The update under discussion does not try to change anything about this from rfc2560. The installed base of rfc2560 clients is huge, and you probably will have to live with such clients (and the resulting impossibility of the OCSP responder to determine the OCSP clients motivation for inquring the status of potentially fake serials for many years to come). What all protocol updates have in common, is, that it will not change what the installed base is sending out and will not change how the installed interprets what it receives. What is possible, however, when one of the communication peer is updated, that interop is improved, and the desirable behaviour will happen more often than before the update. > > 3. Solution is expensive and not useful because the signing of such > revocation response will only consume system key resources for > creating unclear response. a) The solution is extremely useful, because it can be used to stop RPs accepting certs when the cert serial can not be found on the cert issue record log. Further improvements, such as conveying the cert hash of all certs, for which cert issue records exists, can be independently added to OCSP. b) The solution is not expensive at all. Nobody is required to implement it. In order to make a trustworthy assertion about the certificate status that a responsible client will find acceptable during certificate revocation checking, a valid digital signature on the OCSP response is a requirement. If you are worried about being unable to pre-sign an OCSP response for not-issued certs, that problem was newly created by the dirty hack to randomize the cert serial after the X.509 design weakness was discovered that the specific design of X.509 cert issuance would enable a mere hash collision attack to achieve what would normally require a second preimage attack. Since the attack needs the wiggle room of the subjectPublicKey info bits, I'm wondering whether it would not be much more appropriate for the CA to clean up the subject name from the certificate request and inserted a randomized RDName component into the subject name, instead of messing up the certificate serial number space. (Will there ever be NSEC3 records for the .com zone?) c) The response is *VERY* clear (i.e. has well-defined semantics) Quoting from section 8.5.2.2 of X.509 08/2005: A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). Once a hold has been issued, it may be handled in one of three ways: a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period > > At first, I propose to define a new type of the OCSP Responder error message: > > OCSPResponseStatus ::= ENUMERATED { ? > probablyCADatabaseOrCAKeyCompromise (7) > } The symbolic name suggested above for a new ReasonCode is a terribly bad idea, indicating a lack of understanding of protocol design. If anything, a sensible name for the desired function would be: noIssueRecordFound(7) and if *your* implementation of an OCSP responder would want to convey any more specific reason what may have caused this situation, you could include an explicit extension, similar to how X.509 08/2005 suggests this for conveying additional info or requesting specific RP actions in 8.5.2.3 Hold instruction code extension. But the problem with a newly defined ReasonCode is that we do not really know how the installed base will process this, and whether it may treat such a new revocation code as a final/permanent status and cache it _much_ longer than what is appropriate for a temporary status such as certificateHold. -Martin From stefan@aaa-sec.com Mon Jan 14 20:29: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 06E3521F87E5 for ; Mon, 14 Jan 2013 20:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.699, 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 2S17SZBC2Dyr for ; Mon, 14 Jan 2013 20:29:17 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A40D621F8763 for ; Mon, 14 Jan 2013 20:29:16 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 21DBC1E35203 for ; Tue, 15 Jan 2013 05:29:14 +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 DJ6DgS01nbiQ for ; Tue, 15 Jan 2013 05:29:01 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 31D521E35208 for ; Tue, 15 Jan 2013 05:29:01 +0100 (CET) Received: (qmail 51874 invoked from network); 15 Jan 2013 04:29:00 -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 ; 15 Jan 2013 04:29:00 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Tue, 15 Jan 2013 05:28:58 +0100 From: Stefan Santesson To: Peter Rybar , 'Piyush Jain' , 'pkix' Message-ID: Thread-Topic: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients In-Reply-To: <201301141520.r0EFKnM5078758@mail.nbusr.sk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441072541_40613054" Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 04:29:27 -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_3441072541_40613054 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Peter, In general. For several reasons I'm not supportive of your proposals. The basic problem is that you don't listen to the problem statement being repeated here time after time after time. We are NOT trying to solve CA compromise. We are giving the protocol the capability to reasonably respond to requests for serial numbers that don't match any issued cert. That may or may not be caused by CA compromise. If you want to craft a perfect solution for handling CA compromise, fine. But that is not part of this update effort. /Stefan From: Peter Rybar Date: Monday, January 14, 2013 4:20 PM To: Stefan Santesson , 'Piyush Jain' , 'pkix' Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > Stefan, >> > A good protocol should provide a reasonable response to every possibl= e >> request. > =20 > I agree with such general sentence but rfc2560bis-08 is not able to fix > discussed situations. > Good view was dome by Piyush Jain [piyush@ditenity.com] in > [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 > =20 > Let me propose another solution. > We are trying to fix the situation, where the CA key was used for signing > certificate but CA is not able to provide evidence about it for OCSP serv= ice. > 1. It could be after disaster recovery procedure where the record was los= t > because it was not archived. > 2. Or when the CA key was compromised and was used for signing a fake > certificate. > =20 > I do not think that proposed solution =B3to provide revoked status with a r= eason > code certificateHold and extensions id-pkix-ocsp-extended-revoke=B2 by OCSP= to > RP is helpful, because: > 1. CA will not be informed about the potential inconsistency in the CA > database or about potential critical attack (DigiNotar); and > 2. OCSP service will not be able to decide if it is a potential CA compro= mise > or only bad OCSP client is creating fake request because only according t= o > analyzing the certificate content true result can be produces. Because > according to rfc2560bis-08 the certificate is only on the client side. > 3. Solution is expensive and not useful because the signing of such revoc= ation > response will only consume system key resources for creating unclear resp= onse. > =20 > At first, I propose to define a new type of the OCSP Responder error mess= age: > OCSPResponseStatus ::=3D ENUMERATED { =8A > probablyCADatabaseOrCAKeyCompromise (7) > } > =20 > Or when solution is important to be understood by legacy clients then wha= t is > defined for probablyCADatabaseOrCAKeyCompromise will be applicable also f= or > malformedRequest OCSP Responder error message: > In RFC must be defined rules for RP OCSP client applications where client= will > be able to repeat the OCSP request but together with the certificate for = which > OCSP Responder error message is probablyCADatabaseOrCAKeyCompromise or > malformedRequest. > =20 > This certificate will be included in singleRequestExtensions where the > extension will be identified with OBJECT IDENTIFIER > id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise. > =20 > OCSP responder will analyze received certificate and in situations where = CA > key was used the certificate will be provided to the CA for analysis and > making decisions. > =20 > The OCSP analysis will be the bases for the second OCSP response status l= ike: > 1. Signed good, revoked if the certificate was missed only according to > recovery procedure; > 2. Unsigned with OCSP Responder error message malformedRequest when the > CertID (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding= to > the form for which OCSP responder is able to provide the status. > For example incorrect hash length in issuerNameHash or issuerKeyHash; > Incorrect serial number like when CA is using sequential number and in > request is present the serial number which is out of the maximum range or= is > used unsigned/signed integer as a hash value stored in certificate serial > number=8A e.g. MD5 causes permanently problems with negative serial numbers > where some CA and client try to change the negative integer of certificat= e > serial number internally and are using such positive integer in OCSP requ= est > what causes problems. > 3. Unsigned with OCSP Responder error message unauthorized when OCSP resp= onder > is not authorized for providing status for requested issuerNameHash, > issuerKeyHash; > 4. Unsigned with OCSP Responder error message tryLater when certificate w= as > signed with CA key and CA must define decision what to do with it. > =8A > =20 > I hope this proposal can be helpful as a starting point. > =20 > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > =20 > =20 > =20 >=20 >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Friday, January 11, 2013 4:05 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > =20 >=20 > =20 >=20 > =20 >=20 > From: Peter Rybar > Date: Friday, January 11, 2013 3:38 PM > To: Stefan Santesson , 'Piyush Jain' > , 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 >=20 > =20 >>=20 >> Stefan, >> As you can see in my previous mail, when OCSP request contains incorrect >> (malformed) serial number, because the certificate does not exist, the O= CSP >> Responder may return an error message malformedRequest or all other type= s of >> responses except for revoked!!! > =20 >=20 > How does a serial number become malformed just because it doesn't exists.= Its > just an integer. >=20 > Its syntactically a well formed integer. >=20 > =20 >>=20 >> According to rfc2560bis is situation worse because the status revoked wh= ich >> was about the real certificate status (in CRL or in previous OCSP RFC) i= s now >> with extension of revoked with reason code certificateHold defined as >> equivocal result when is not correctly implemented. >> It means according to rfc2560bis all serial numbers are initially revoke= d >> with reason code certificateHold=8A Is it useful? > =20 >=20 > Yes. >=20 > =20 >>=20 >> (The revoked with reason code certificateHold is based on CA database an= d in >> some next steps database can also include the hash values of certificate= s for >> positive statement!) >> =20 >> For that reason some systems and legislations where non-repudiation serv= ices >> are required (e.g. QES) dictate that status value good or revoked in OCS= P >> response MUST contain a positive statement a hash value of certificate i= n >> singleExtensions. >> =20 > =20 >=20 > Then that can be achieved by defining a new single response extension tha= t > does not interfere with what is being done in 2560bis. >=20 > =20 >>=20 >> When hash of the certificate as a positive statement MUST be used, the >> situations with OCSP responses for RP are clear and unique because: >> 1) good or revoked is only about know and issued certificates, > =20 >=20 > Great, so how then do you respond to a request for a serial number that h= as > never been issued? >=20 > =20 >>=20 >> 2) any other situations are moved into one group which is unclear and no= t >> analyzed =AD no evidence, no responsibility. > =20 >=20 > But the responder still need to respond. >=20 > =20 >>=20 >> =20 >> It is a radical simplification! > =20 >=20 > Of what? >=20 > =20 >>=20 >> =20 >> Instead of trying to solve presently not practical and theoretical situa= tions >> from the responsibility/liability point of view (like preparing us for >> situations: what we will offer for intergalactic green man, are vegetari= an? >> ;) we can define steps which can be implemented by CAs and OCSP systems = like >> usage of positive statement cert hash. >> =20 > =20 >=20 > Asking for status of a never issued serial number is not impossible. It i= s not > even hard. >=20 > A good protocol should provide a reasonable response to every possible > request. >=20 > =20 >>=20 >> E.g. define new or reuse already defined in private OID space. >> PositiveStatement ::=3D SEQUENCE { >> hashAlgorithm AlgorithmIdentifier, >> certHash OCTET STRING, -- Hash of Subjects certificate >> } >> =20 >> And according it we cam move. > =20 >=20 > I have nothing against such extension being defined. >=20 > But it still does not remove the need for the current discussed mechanism= . >=20 > =20 >=20 > The current discussed mechanism address how to respond to legacy clients = to > requests for non-issued serial numbers. >=20 > Your extension does not help, because it is not understood by legacy clie= nts. >=20 > =20 >=20 > So its not either or. >=20 > =20 >=20 > /Stefan >=20 > =20 >>=20 >> =20 >> Peter Rybar >> =20 >> =20 >>=20 >>=20 >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Thursday, January 10, 2013 2:19 PM >> To: Peter Rybar; 'Piyush Jain'; 'pkix' >> Subject: Re: [pkix] Question about extended Revoked Extension defined in >> section 4.4.8 of ocsp draft 8 >> =20 >>=20 >> Peter, i think the reason for this has been thoroughly debated. >>=20 >> =20 >>=20 >> It is correct that a cert serial number that was on hold, may be release= d. >>=20 >> The requested cert serial number may actually be used in a future >> representing a real certificate. >>=20 >> So this is intentional and the whole purpose behind using the on hold re= ason. >>=20 >> =20 >>=20 >> /Stefan >>=20 >> =20 >>=20 >> From: Peter Rybar >> Date: Thursday, January 10, 2013 12:13 PM >> To: 'Piyush Jain' , Stefan Santesson >> , 'pkix' >> Subject: Re: [pkix] Question about extended Revoked Extension defined in >> section 4.4.8 of ocsp draft 8 >>=20 >> =20 >>>=20 >>> Stefan, >>> For me is unclear how this extension of revoked with reason code >>> certificateHold is useful. >>> It define that now is possible to revoke what does not exist and it ope= n >>> never ending cycle of trying to fixing or correcting the first incorrec= t >>> status that "fake" cert serial number is revoked but cert serial number= is >>> not revoked because "fake" cert does not exist. >>> =20 >>> I agree that extension of revoked can be helpful like: >>> The "revoked" state indicates that the certificate has been revoked >>> (either permanently or temporarily (on hold)). Response extensions >>> may be used to convey additional information on assertions made by >>> the responder regarding the status of the certificate such as >>> positive statement about issuance, validity, etc. >>> =20 >>> =20 >>> When the certificate serial number is not in the OCSP database/CRL then >>> according to rfc2560bis there are defined following possible responses: >>> 1. signed - good (e.g. certificate serial number is not listed in CRL) >>> 2. signed - unknown (e.g. certificate serial number is not listed in C= RL) >>> 3. unsigned =AD unauthorized as an error message >>> 4. signed - revoked where according to rfc2560bis are defined values f= or: >>> Extensions: id-pkix-ocsp-extended-revoke >>> Revocation Reasons: certificateHold >>> Revocation Time: 1.1.1970 00:00:00 UTC >>> =20 >>> What is missing? The rfc2560bis must also specify values for: >>> This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC >>> Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC >>> =20 >>> X.509 defines the reason code certificateHold as 1) it may remain on th= e >>> CRL; 2) it may be replaced by a (final) revocation; 3) it may be explic= itly >>> released; >>> and=20 >>> 4) as a consequence of rfc2560bis the status of certificate serial numb= er >>> indicated as revoked with reason code certificateHold can be replaced w= ith >>> real status of a new real certificate which was issued with the same >>> certificate serial number as was asked in the incorrect OCSP request cr= eated >>> by insufficiently implemented applications where the signature of the >>> certificate was not checked with CA public key. >>> =20 >>> It is based on the following definitions: >>> =20 >>> According to rfc2560bis the certificate status value is: >>> http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ >>> =20 >>> - good =8A is not revoked, (does not necessarily mean that the certif= icate >>> was ever issued)=8A >>> - revoked =8A has been revoked (This state MAY also be returned if th= e >>> responder knows that the requested certificate has never been issued du= ring >>> the history of the associated CA using any current or previous issuing = key.) >>> - unknown =8A >>> =20 >>> When a responder responds revoked to a status request for a non- >>> issued certificate, the responder MUST also; >>> =20 >>> - 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. >>> =20 >>> =20 >>> According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code >>> extension: >>> http://www.itu.int/rec/T-REC-X.509 >>> A certificate may be placed on hold by issuing a CRL entry with a reaso= n >>> code of certificateHold. The certificate hold notice may include an opt= ional >>> hold instruction code to convey additional information to certificate u= sers >>> (see 8.5.2.3).=20 >>> Once a hold has been issued, it may be handled in one of three ways: >>> a) it may remain on the CRL with no further action, causing users to re= ject >>> transactions issued during the hold period; or, >>> b) it may be replaced by a (final) revocation for the same certificate,= in >>> which case the reason shall be one of the standard reasons for revocati= on, >>> the revocation date shall be the date the certificate was placed on hol= d, >>> and the optional instruction code extension field shall not appear; or, >>> c) it may be explicitly released and the entry removed from the CRL. >>> =20 >>> =20 >>> =20 >>> -----Original Message----- >>> From: Piyush Jain [mailto:piyush@ditenity.com] >>> Sent: Wednesday, January 09, 2013 6:17 PM >>> To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' >>> Subject: RE: [pkix] Question about extended Revoked Extension defined i= n >>> section 4.4.8 of ocsp draft 8 >>> =20 >>> =20 >>> =20 >>>> > -----Original Message----- >>>> > From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>>> > Sent: Tuesday, January 08, 2013 8:40 PM >>>> > To: Peter Rybar; 'Piyush Jain'; 'pkix' >>>> > Subject: Re: [pkix] Question about extended Revoked Extension define= d in >>>> > section 4.4.8 of ocsp draft 8 >>>> > Importance: High >>>> >=20 >>>> > Peter; >>>> >=20 >>>> > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >>>> >=20 >>>>> > >Stefan, >>>>> > >The terminology is not clear for someone who will see: >>>>> > >The revocation is of "non-issued certificate". >>>>> > >Because by reading the text it is expected that the certificate wa= s >>>>> > >issued, but fraudulently. >>>> >=20 >>>> > What part of the text supports that? >>> [Piyush] None explicitly, but many would infer it that way. The certifi= cate >>> space that is covered by your interpretation of "non-issued" includes >>> certificates which are not signed using the CA key and those that are s= igned >>> fraudulently. RPs won't make queries for certificate for which they can= not >>> verify the signature. So the only genuine requests for "non-issued >>> certificates" coming to a responder would be those for fraudulently iss= ued >>> certificates unless you are saying that this specification will allow f= or >>> RPs to skip signature checking. >>>> >=20 >>>>> > > >>>>> > >The revocation with a new extension is only about fraudulently iss= ued >>>>> > >certificate. It means this new extension and revocation is not use= d >>>>> > >when the certificate is not issued and only fake random certificat= e >>>>> > >serial number was created in OCSP request. >>>> >=20 >>>> > What? >>>> > How in this physical universe would the OCSP responder tell the >>>> > difference??? >>>> > Crystal ball? >>>> >=20 >>>>> > > >>>>> > >While it is intended only for fraudulently issued certificate wher= e >>>>> > >fraudulently issued certificate can potentially reuse any already = used >>>>> > >certificate-serial-number the extension must contain e.g. a positi= ve >>>>> > >confirmation of existence in the form of hash value of fraudulentl= y >>>>> > >issued certificate. >>>> >=20 >>>> > No that is a task for another possible effort. >>>> > It's not part of this update. >>> =20 >>> [Piyush] Can you clarify what is the goal for this update? I think it i= s one >>> of the following >>> - Allow for extending definition of revoked so other specifications can >>> extend the protocol >>> - Address handling of fraudulently issued certificate. >>> - Address handling of any certificate not issued by the CA. >>> =20 >>> But based on different threads on this topic I get confused about what = it >>> is. Having the goal clear would help us keep the review of draft focuse= d. >>> =20 >>>> >=20 >>>> > But this update paves the way for such extension. Which I'm not agai= nst. >>>> > It's just not part of this update effort. >>> =20 >>>> >=20 >>>>> > > >>>>> > >Only according to the hash value of fraudulently issued certificat= e >>>>> > >relaying party and OCSP responder is able to identify fraudulently >>>>> > >issued certificate because CA was compromised and serial numbers o= f >>>>> > >certificates are not any longer unique for compromised CA. >>>>> > > >>>>> > >Conclusion: >>>>> > >Positive statement extension as a hash value of the certificate wh= ose >>>>> > >status OCSP response is providing can be used in this case: >>>>> > > when the certificate is revoked, >>>>> > > when the certificate is good and also >>>>> > > when the certificate is fraudulently issued. >>>>> > > >>>>> > >For that reason it can be more helpful to define in RFC one positi= ve >>>>> > >statement extension as a hash value of the certificate whose statu= s the >>>>> > >OCSP response is providing and define in RFC that it will support >>>>> > >situations when status is: >>>>> > > -- good >>>>> > > -- revoked >>>>> > >And for randomly created certificate serial numbers without record= s in >>>>> > >OCSP database will be use: >>>>> > > -- unknown >>>> >=20 >>>> >=20 >>>> > No, we have been through this and determined WG consensus. >>>> > Unknown is not the choice, since it may not have the desired effect = (to >>>> > indicate that a certificate with this serial number should not be >>> trusted). >>>> >=20 >>>> > It's important that this works with legacy clients. They will be aro= und >>> for a >>>> > while. >>>> >=20 >>> [Piyush] That's an interesting usage of the word "legacy". I don't thin= k >>> that any of the previous versions of OCSP recommended interpreting "unk= nown" >>> or UNAUTHORIZED(unsigned) responses to imply that certificate can be >>> trusted. The right word would be to "incorrectly implemented clients". >>> =20 >>>> > /Stefan >>>> >=20 >>>>> > > >>>>> > > >>>>> > >_______________________________________________ >>>>> > >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 >> _______________________________________________ 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 --B_3441072541_40613054 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Peter,

<= div>In general.
For several reasons I'm not supportive of your pro= posals.

The basic problem is that you don't listen = to the problem statement being repeated here time after time after time.
We are NOT trying to solve CA compromise. We are giving the protocol = the capability to reasonably respond to requests for serial numbers that don= 't match any issued cert.

That may or may not be ca= used by CA compromise.

If you want to craft a perfe= ct solution for handling CA compromise, fine. But that is not part of this u= pdate effort.
/Stefan



Stefan,

 &g= t; A good protocol should provide a reasonabl= e response to every possible request.

 

I agree wi= th such general sentence but rfc2560bis-08 is not able to fix discussed situations.

Good view was dome by Piyush Jain [piyush@ditenity.com] in=

[pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08

 

<= p class=3D"MsoNormal">Let me propose ano= ther solution.

We are trying to fix the situation, where the CA key was used for signing certificate but CA is not = able to provide evidence about it for OCSP service.

=

1. It could be af= ter disaster recovery procedure where the record was lost because it was not archived.

2. Or when the CA key was compromised and was used for signing a fake certificate.<= /font>

&n= bsp;

I do not think that proposed solution “to provide revoked= status with a reason code certificateHold= and extensions id-pkix-ocsp-extended-revo= ke” by OCSP to RP is helpful, because:

1. CA will not be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and

2. OCSP service will= not be able to decide if it is a potential CA compromise or only bad OCSP clien= t is creating fake request because only according to analyzing the certificate content true result can be produces. Because according to rfc2560bis-08 the= certificate is only on the client side.

3. Solution is expensive and not useful because the signing of such revocation response will only co= nsume system key resources for creating unclear response.

 =

At first, I propose to define a new type of the OCSP Responder error message:

OCSPRespo= nseStatus ::=3D ENUMERATED { …

   probablyCADatabaseOrCAKeyCompromise (7)

}

 

Or when solution is important to be <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri;color:black">u= nderstood by legacy clients then = what is defined for probablyCADatabaseOrCAKeyComp= romise will be applicable also for malformedRequ= est OCSP Responder error message: =

In RFC must be defined rules for RP OCSP client applications where client will be able to repeat t= he OCSP request but together with the certificate for which OCSP Responder error message is probablyCADatabaseOrCAKeyCompromise or malformedRequest.

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"> 

This certificate will be included in singleRequestExtensions where the extension will be identified = with OBJECT IDENTIFIER

id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise.

 = ;

OCSP responder will analyze received certificate and in situations where CA key was used the certificat= e will be provided to the CA for analysis and making decisions.

 

The OCSP analysis will be the bases for the second OCSP response status like:

 1. Sig= ned good, revoked if the certificate was missed only according to recovery procedure;=

 2. Unsigned with OCSP Responder error message malformedRequest when the CertID (issuerNameHash, i= ssuerKeyHash, serialNumber) is not corresponding to the form for which OCSP responder is = able to provide the status.

  For example incorrect hash length in issuerNameHash or issuerKeyHash;

  Incorrec= t serial number like when CA is using sequential number and in request is present the seria= l number which is out of the maximum range or is used unsigned/signed integer as a hash value stored in certificate serial number… e.g. MD5 causes permanently problems with = negative serial numbers where some CA and client try to change the negative integer = of certificate serial number internally and are using such positive integer in= OCSP request what causes problems.

3. Unsigned with OCSP Responder error message unauthorized when OCSP responder is not authorized = for providing status for requested issuerNameHash, issuerKeyHash;

4.= Unsigned with OCSP Responder error message tryLater when certificate was signed with CA key and CA m= ust define decision what to do with it.

…

 

I hope this proposal can be helpful as a starting point.

 <= /p>

P= eter Rybar
National Security Authority
Information Security and Electronic Signature Department=

&n= bsp;

 

 

From: Stefan Sant= esson [mailto:stefan@aaa-sec.com]
= Sent: Friday, January 11, 2013 4:05 PM
To: Peter Rybar; 'Piyush Jai= n'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8<= /font>

 

 

 

From: Peter Rybar <rybar@nbusr.sk>Date: Friday, January 11, 2013= 3:38 PM
To: Stefan Santesso= n <stefan@aaa-sec.com>, 'Piyus= h Jain' <piyush@ditenity.com>= , 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Ste=
fan,
As you can see in my previous mail, when OCSP request contains=
 incorrect (malformed) serial number, because the certificate does not exist=
, the OCSP Responder may return an error message malformedRequest or all other types of responses except for revoked!!!<=
/font>

 

How does a serial number become malformed just because it doesn't exists. Its just an integer= .

Its syntactically a well formed integer.

 

Acc=
ording to rfc2560bis is situation worse because the status revoked which was=
 about the real certificate status (in CRL or in previous OCSP RFC) is now w=
ith extension of revoked with r=
eason code certificateHold defined as equivocal result when is not correctly=
 implemented. 
It means according to rfc2560bis all serial numbers are initia=
lly revoked with reason code ce=
rtificateHold… Is it useful?

 

Yes.

<= /div>

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black"> 

(Th=
e revoked with reason code cert=
ificateHold is based on CA database and in some next steps database can also=
 include the hash values of certificates for positive statement!)
 
For that reason some systems and legislations where non-repudi=
ation services are required (e.g. QES) dictate that status value good or =
revoked in OCSP response MUST contain a positive statement a hash=
 value of certificate in singleExtensions.
 
=

 

Then that can be achieved by defining a new single response extension that does not interfer= e with what is being done in 2560bis.

=

 = 

Whe=
n hash of the certificate as a positive statement MUST be used, the situatio=
ns with OCSP responses for RP are clear and unique because:
1) good or revoked is only about know and issued=
 certificates,
<= /span>

=  

Great, so how then do you respond to a request for a serial number that has never been issued?

 

2) =
any other situations are moved =
into one group which is unclear and not analyzed – no evidence, no res=
ponsibility.

 

But the responder still need to respond.

 

&nb=
sp;
It is a radical simplification!=
<= p class=3D"MsoNormal"> <= /font>

Of = what?

 

&nb=
sp;
Instead of trying to solve presently not practical and theoret=
ical situations from the responsibility/liability point of view (like prepar=
ing us for situations: what we will offer for intergalactic green man, are v=
egetarian? ;) we can define steps which can be implemented by CAs and OCSP s=
ystems like usage of positive statement cert hash.<=
/o:p>
 
=

 

Asking for status of a never issued serial number is not impossible. It is not even hard.

A good protocol should provide a reasonable response to every possible request.<= /font>

 

E.g=
. define new or reuse already defined in private OID space.
PositiveStatement ::=3D SEQUENCE {
   hashAlgorithm    AlgorithmIdentifi=
er,
   certHash       =
;  OCTET STRING, -- Hash of Subjects certificate
}
 
And according it we cam move.

 

I have nothi= ng against such extension being defined.

But it still does not remove the need for the current discussed mechanism.

&n= bsp;

The current discussed mechanism address how to respond to legacy clients to requests for non-issu= ed serial numbers.

Your extension does not help, because it is not understood by legacy clients.=

 

So its not either or.

=

 

/Stefan

 

&nb=
sp;
Peter Rybar<=
font color=3D"black">=

<= span style=3D"font-size: 10.0pt;font-family:Arial;color:navy"> 

 

<= div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<= /div>

F= rom: Stefan Santesson [mailto:= stefan@aaa-sec.com]
Sent: Thursday, January 10= , 2013 2:19 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject:<= /b> Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8<= /font>=

 =

Peter, i think the reason for this has been thoroughly debated.

 

It is correct that a cert serial number that was on hold, may be released.=

The reque= sted cert serial number may actually be used in a future representing a real certific= ate.

So this is intentional and the whole purpose behind using the on hold reason.<= /font>

&n= bsp;=

/Stefan

=  

<= p class=3D"MsoNormal">From: Peter Rybar <rybar@nbusr.sk>Date: Thursday, January 10, 20= 13 12:13 PM
To: 'Piyush Jain' = <piyush@ditenity.com>, Stefan= Santesson <stefan@aaa-sec.com>, 'pkix' = <pkix@ietf.org>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8=

 

Stefan,<= o:p>

Fo= r me is unclear how this extension of revoked with reas= on code certificateHold is useful.=

It define th= at now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fak= e" cert does not exist.

=

 

I agree that extension of r= evoked can be helpful like:= 

   The "revoked" state indicates that the certificat=
e has been revoked
<= pre>   (either permanently or temporarily (on hold)= ). Response extensions
   may be used to convey additional informa=
tion on assertions made by
   the responder regarding the status o=
f the certificate such as=

   positive statement about issuance, va=
lidity, etc.

 

 

When the certificate serial number is not in the OCSP database/CRL then according to rfc2560bis there a= re defined following possible responses:=

1. sig= ned -  good (e.g. certific= ate serial number is not listed in CRL)

2. signed -  unknown = (e.g. certificate serial number is not listed in CRL)

3. unsigned – unauthorized as an error message

4. signed -  revoked where according to rfc2560bis ar= e defined values for:

<= p class=3D"MsoNormal">id= -pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC<= span style=3D"color:black">

=  

What is missing? The rfc2560bis must also specify values for:

This Update:  ?? ?? ?? &nb= sp;   10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

 

<= span lang=3D"EN-US" style=3D"font-size:12.0pt;color:black">X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) = it may be replaced by a (final) revocation; 3) it may be explicitly released;<= u3:p>

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced with = real status of a new real certificate which was issued with the same certificate= serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the certific= ate was not checked with CA public key.

 

It is based on the= following definitions:

 <=
/font>
According to rfc2560bis the certificate status value is:=

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 
 
   -  good … is not revoked, (does not necessarily mean that the certifi=
cate was ever issued)…
   -  revoked … has been revoked (This st=
ate MAY also be returned if the responder knows that the requested certifica=
te has never been issued during=
 the history of the associated CA using any current or previous issuing key.=
)
   -  unknown …=

 
   When a responder responds revoked to =
a status request for a non-
   issued certificate, the responder MUST also;
 
    - include the extended revoked definition r=
esponse extension
      (section 4.8), indicating that =
the OCSP responder supports the<=
/font>
      extended definition of revoked =
state to also cover non-issued
      certificates,
    - provide the revocation reason certificate=
Hold (6), and;
=
    - specify the revocation date January 1, 19=
70. 
 
=
 
According to ITU-T Rec. X.509
(11/2008), clause 8.5.2.2 Reason code extension:<=
/u1:p>
http://www.itu.int/rec/T-R=
EC-X.509
A certificate may be placed on
hold by issuing a CRL entry with a reason code of certificateHold. The
certificate hold notice may include an optional hold instruction code to co=
nvey
additional information to certificate users (see 8.5.2.3). 
Once a hold has been issued, it
may be handled in one of three ways: =

a) it =
may remain on the CRL
with no further action, causing users to reject transactions issued during =
the
hold period; or, 
b) it may be replaced by a=

(final) revocation for the same certificate, in which case the reason shall=
 be
one of the standard reasons for revocation, the revocation date shall be th=
e
date the certificate was placed on hold, and the optional instruction code
extension field shall not appear; or, 
c) it=
 may be explicitly
released and the entry removed from the CRL.
 
 <=
/font>
 
---=
--Original Message-----

From: Piyush Jain [mailto:piyush@diten=
ity.com]


Sent: Wednesday, January 09, 2013 6:17 PM

To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'

Subject: RE: [pkix] Question about extended Revoked Extension defined in
section 4.4.8 of ocsp draft 8
 
 
 
> -----Original Message-----<=
u1:p>
> From: Stefan Santesson [mailto:=
stefan@aaa-sec.com]
> Sent: Tuesday, January 08, 201=
3 8:40
PM
> To: Peter Rybar<=
/st1:personname>;
'Piyush Jain'; 'pkix'
> Subject: Re: [pkix] Question ab=
out
extended Revoked Extension defined in<=
/span>
> section 4.4.8 o=
f ocsp draft 8
> Importance: High
> =

> Peter;
> 
> O=
n 1/8/13 5:18 PM, "Peter Rybar"
<rybar@nbusr.sk> wrote:
> 
> >Stefan,
> >Th=
e terminology is not clear for
someone who will see:
> >The revocation is of
"non-issued certificate".
> >Because by reading the =
text it is
expected that the certificate was
> >issued, but fra=
udulently.
> 
> What part of the tex=
t supports that?
[Piyush] None explicitly, but many would
infer it that way. The certificate
space that is covered b=
y your interpretation
of "non-issued" includes=

=
certificates which are not signed=
 using
the CA key and those that are signed
fraudulently. RPs won=
't make queries for
certificate for which they cannot
verify the signature. So=
 the only genuine
requests for "non-issued=

=
certificates" coming to a respond=
er
would be those for fraudulently issued=

certificates unless=
 you are saying that
this specification will allow for
RPs to skip signature ch=
ecking.
> 
> >=

&=
gt; >The revocation with a new
extension is only about fraudulently issued<=
/o:p>
> >certi=
ficate. It means this new
extension and revocation is not used
> >when the cer=
tificate is not
issued and only fake random certificate
> >serial nu=
mber was created in OCSP
request.
> =

> What?
> How in this physical universe would
the OCSP responder tell the
> difference???
> Crystal ball?<=
/p>
<=
span style=3D"font-size:10.0pt;color:black">> 
> >
> >While it is intended only for
fraudulently issued certificate where<=
/span>
> >fraudulentl=
y issued certificate
can potentially reuse any already used=

> >certificat=
e-serial-number the extension
must contain e.g. a positive
> >confirmation of exis=
tence in the
form of hash value of fraudulently
> >issued certifi=
cate.
> 
> No that is a task for ano=
ther
possible effort.
> It's not part of this update.<=
/u3:p>
 
[Piyush] Can you clarify what is the goal=

for this update? I think it is one
of the following<=
/u3:p>
- Allow for extending definition of
revoked so other specifications can
extend the protocol
=
- Address handling of fraudulently issued
certificate.
- Address handling of any certificate not
issued by the CA.
 
But based on dif=
ferent threads on this
topic I get confused about what it
is. Having the goal cle=
ar would help us
keep the review of draft focused. 
 
> 
> But this update paves the way for
such extension. Which I'm not against.=

> It's just not =
part of this update
effort.
 =

> 
>=
; >
> >Only according to the hash value
of fraudulently issued certificate
> >relaying party=
 and OCSP responder
is able to identify fraudulently
> >issued certifica=
te because CA was
compromised and serial numbers of
> >certificates ar=
e not any longer
unique for compromised CA.
> >
>=
 >Conclusion:
> >Positive statement extension as a=

hash value of the certificate whose
> >status OCSP r=
esponse is providing
can be used in this case:
> >  when the certifi=
cate is
revoked,
> >  when the certificate is
good and also
> >  when the certificate is
fraudulently issued.
=

> >
> >F=
or that reason it can be more
helpful to define in RFC one positive<=
/span>
> >statement e=
xtension as a hash
value of the certificate whose status the
> >OCSP re=
sponse is providing and
define in RFC that it will support
> >situations whe=
n status is:
> >   -- good
> >   -- revoked
> >And for randomly=
 created
certificate serial numbers without records in
> >OCS=
P database will be use:
> >   -- unknown
=
> 
<=
p class=3D"MsoPlainText">> 
> No, we hav=
e been through this and
determined WG consensus.=

=
> Unknown is not the choice, s=
ince it
may not have the desired effect (to
> indicate that a c=
ertificate with this
serial number should not be
trusted).
>=
; 
> It's important that this works with
legacy clients. They will be around
for a
> while.
> 
[Piyush] That's an inte=
resting usage of
the word "legacy". I don't think
that any of the previous =
versions of OCSP
recommended interpreting "unknown"
or UNAUTHORIZED(unsigne=
d) responses to
imply that certificate can be
trusted. The right word woul=
d be to
"incorrectly implemented clients".
 
> /Stefan
> 
> >=

> >
>
>_______________________________________________
> &=
gt;pkix mailing list
<=
p class=3D"MsoPlainText">> >pkix@ietf.org
> >https://www.ietf.org/mailman/listinfo/pkix<=
/u3:p>
> >
<=
p class=3D"MsoPlainText">> 
 

__________________________________________= _____ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/li= stinfo/pkix

________________= _______________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/li= stinfo/pkix

=
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix --B_3441072541_40613054-- From denis.pinkas@bull.net Tue Jan 15 01:17: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 4F34821F88B0 for ; Tue, 15 Jan 2013 01:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.510, 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 CxkWn193UwIj for ; Tue, 15 Jan 2013 01:17:11 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB821F8873 for ; Tue, 15 Jan 2013 01:17:10 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 8D6951CFF5; Tue, 15 Jan 2013 10:17:09 +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 2013011510170853-17991 ; Tue, 15 Jan 2013 10:17:08 +0100 Message-ID: <50F51E90.1040005@bull.net> Date: Tue, 15 Jan 2013 10:17:04 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 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 15/01/2013 10:17:08, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 15/01/2013 10:17:09, Serialize complete at 15/01/2013 10:17:09 Content-Type: multipart/alternative; boundary="------------000304070207030702020606" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 09:17:16 -0000 This is a multi-part message in MIME format. --------------000304070207030702020606 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, You said: "The purpose of this exercise is to provide a solution that works with legacy clients". True, but not only. As proposed, new clients have no way to know that the OCSP responder is using the database of issued certificates from the CA. A non-critical extension to an individual response should be added to advertise it. You said: "the on hold bit is the only one that is known to represent a temporary revocation in current clients". This is not what RFC 5280 says, nor what X.509 states. I have made a search in X.509: *Text from X.509 using "temporarily" or "on hold"* *8.5 Basic CRL extensions* *8.5.1 Requirements* The following requirements relate to CRLs: a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 8.6) and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required. b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation. There is therefore a requirement for a CRL entry to indicate the reason for revocation. c) There is a requirement for an authority to be able to temporarily suspend validity of a certificate and subsequently either revoke or reinstate it. Possible reasons for such an action include: -- desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate information to determine whether it is valid; -- other business needs, such as temporarily disabling the certificate of an entity pending an audit or Investigation. *8.5.2.2 Reason code extension* A certificate may be placed on hold by issuing a CRL entry with a reason code of *certificateHold*. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). Once a hold has been issued, it may be handled in one of three ways: a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, c) it may be explicitly released and the entry removed from the CRL** *9 Delta CRL relationship to base* (...) A certificate's revocation notice, with revocation reason *certificateHold, *may appear on either a dCRL or a CRL that is complete for a given scope. This reason code is intended to indicate a temporary revocation of the certificate pending a further decision on whether to permanently revoke the certificate or reinstate it as one that is not revoked. You will also notice that all this appies to CRLs, since neither X.509, nor RFC 5280 say how to handle revocation in the context of OCSP. There is not even a path processing procedure, which is a fundamental defect of RFC 2560. RFC 2560 states: The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the sentence "(either permanantly or temporarily)" is in parenthesis. Anyway, we may clarify this and this was my original change proposal, which I copy again below (see may email from 11/01/2013 13:55): OLD: 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. NEW: The "revoked" state indicates that the certificate has been revoked, either permanently or temporarily (i.e. certificateHold or notIssuedOrIrregularlyIssued). In particular, this state MAY be returned if the responder knows that currently the serial number from the requested certificate has not been used by the CA to issue a certificate or has been used irregularly to issue a certificate. 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. Using certificateHold creates problems as already mentioned (see may email from 11/01/2013 13:55), whereas using case 7 in the enumeration does not. Note that there is yet another reason of not importing CRLReason from RFC 5280: removeFromCRL cannot be used in OCSP responses. *CRLReason ::= ENUMERATED {*** *unspecified(0),*** *keyCompromise(1),*** *cACompromise(2),*** *affiliationChanged(3),*** *superseded(4),*** *cessationOfOperation(5),*** *certificateHold(6),*** *-- value 7 is not used*** *removeFromCRL(8),*** *privilegeWithdrawn(9),*** *aACompromise(10) }*** ** Denis > Two things, > > 1) The purpose of this exercise is to provide a solution that works > with legacy clients. That is, the output provided by the responder > have to work and provide the desired effect when sent to a client > using a current implementation of OCSP. > 2) The extension was evidently required after discussions at the last > IETF meeting to reach WG rough consensus on this mechanism. The reason > being mainly to support audit when going back and examining what > happened, it must be evident that the responder operated using this > extended definition of revoked. > > Therefore, the on hold bit is the only one that is known to represent > a temporary revocation in current clients. > And therefore the extension is needed. > > The rationale you give for not using certificateHold, is provide no > problems. > I see no obligation to help your client understand that this serial > number will never be released from certificateHold. > Because your client must always consider that as a possibility when > seeing certificateHold, so it should not fail badly in any case. > > /Stefan > > > From: Denis Pinkas > > Date: Friday, January 11, 2013 5:24 PM > To: Stefan Santesson > > Cc: > > Subject: Re: [pkix] About extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Stefan, > > We both agree that the serial number is CURRENTLY regarded as > revoked, but this may change in the future, > i.e. a legitimate certificate may be issued with this serial number". > > However, the use of certificateHold is not a good match, as it is > explained below. > The use of the extended Revoked Extension defined in section 4.4.8 > is an overcomplication that is not necessary in my proposal. > > You have provided no argument about the proposal for using case 7 > in the enumeration of CRL revocation reasons. > > Denis > > >> The purpose is to signal that the serial number is CURRENTLY >> regarded as revoked, but this may change in the future, i.e. a >> legitimate certificate may be issued with this serial number. >> Thus the certificateHold is a good match. >> >> /Stefan >> >> >> From: Denis Pinkas > > >> Date: Friday, January 11, 2013 3:59 PM >> To: Erwann Abalea > >> Cc: > >> Subject: Re: [pkix] About extended Revoked Extension defined in >> section 4.4.8 of ocsp draft 8 >> >> Erwann, >> >> Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED >> >> Case 7 is unused. >> >> Denis >> >> >>> >>> 2013/1/11 Denis Pinkas >> > >>> >>> >>> The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold >>> >>> as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment >>> >>> on that reason code. Depending of the content of the signature policy, these applications may "wait and >>> >>> come back later" to see if there is a change in the revocation status. That change will never happen >>> >>> if the certificate has not been regularly issued. >>> >>> >>> >>> It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. >>> >>> >>> >>> The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. >>> >>> >>> If you're talking about bit instead of enumerated value, >>> then you're talking about the "ReasonFlags" definition that >>> is used in cRLDistributionPoints extension instead of the >>> "CRLReason" definition used to indicate the revocation >>> reason. And this "ReasonFlags" bit string already uses bit 7 ;) >>> >>> -- >>> Erwann. >> >> _______________________________________________ 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 > --------------000304070207030702020606 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

You said: "The purpose of this exercise is to provide a solution that works with legacy clients". True, but not only.

As proposed, new clients have no way to know that the OCSP responder is using the database of issued certificates from the CA.
A non-critical extension to an individual response should be added to advertise it.

You said: "the on hold bit is the only one that is known to represent a temporary revocation in current clients".

This is not what RFC 5280 says, nor what X.509 states. I have made a search in X.509:

Text from X.509 using “temporarily” or “on hold”

8.5 Basic CRL extensions

8.5.1 Requirements

The following requirements relate to CRLs:

a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 8.6)
and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required.

b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation.
There is therefore a requirement for a CRL entry to indicate the reason for revocation.

c) There is a requirement for an authority to be able to temporarily suspend validity of a certificate and subsequently
either revoke or reinstate it. Possible reasons for such an action include:

– desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate
information to determine whether it is valid;

– other business needs, such as temporarily disabling the certificate of an entity pending an audit or Investigation.

 

8.5.2.2 Reason code extension

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice
may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways:

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or,

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons
for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension
field shall not appear; or,

c) it may be explicitly released and the entry removed from the CRL

 

9 Delta CRL relationship to base

(…)

A certificate's revocation notice, with revocation reason certificateHold, may appear on either a dCRL or a CRL that is complete
for a given scope. This reason code is intended to indicate a temporary revocation of the certificate pending a further decision on
whether to permanently revoke the certificate or reinstate it as one that is not revoked.


You will also notice that all this appies to CRLs, since neither X.509, nor RFC 5280 say how to handle revocation in the context of OCSP.

There is not even a path processing procedure, which is a fundamental defect of RFC 2560.

RFC 2560 states:


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

   (either permanantly or temporarily (on hold)).


 It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the sentence "(either permanantly or temporarily)" is in parenthesis.

Anyway, we may clarify this and this was my original change proposal, which I copy again below
(see may email from 11/01/2013 13:55):

OLD:

  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.

NEW:

   The "revoked" state indicates that the certificate has been revoked,
   either permanently or temporarily (i.e. certificateHold or
   notIssuedOrIrregularlyIssued).  In particular, this state MAY be
   returned if the responder knows that currently the serial number
   from the requested certificate has not been used by the CA to issue
   a certificate or has been used irregularly to issue a certificate.
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.

Using certificateHold creates problems as already mentioned (see may email from 11/01/2013 13:55),
whereas using case 7 in the enumeration does not.

Note that there is yet another reason of not importing CRLReason from RFC 5280:
removeFromCRL cannot be used in OCSP responses.

CRLReason ::= ENUMERATED {

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

             -- value 7 is not used

        removeFromCRL           (8),

        privilegeWithdrawn      (9),

        aACompromise           (10) }

 


Denis


Two things,

1) The purpose of this exercise is to provide a solution that works with legacy clients. That is, the output provided by the responder have to work and provide the desired effect when sent to a client using a current implementation of OCSP.
2) The extension was evidently required after discussions at the last IETF meeting to reach WG rough consensus on this mechanism. The reason being mainly to support audit when going back and examining what happened, it must be evident that the responder operated using this extended definition of revoked.

Therefore, the on hold bit is the only one that is known to represent a temporary revocation in current clients.
And therefore the extension is needed.

The rationale you give for not using certificateHold, is provide no problems.
I see no obligation to help your client understand that this serial number will never be released from certificateHold.
Because your client must always consider that as a possibility when seeing certificateHold, so it should not fail badly in any case.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 5:24 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it is explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons.

Denis


The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number.
Thus the certificateHold is a good match.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea <eabalea@gmail.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Erwann,

Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold 
as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment 
on that reason code. Depending of the content of the signature policy, these applications may “wait and 
come back later” to see if there is a change in the revocation status. That change will never happen 
if the certificate has not been regularly issued.
 
It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.
 
The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs.  

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

_______________________________________________ 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

--------------000304070207030702020606-- From stefan@aaa-sec.com Tue Jan 15 01:38: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 D8E3F21F844F for ; Tue, 15 Jan 2013 01:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.376 X-Spam-Level: X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 ouYPQ3Gmgbdi for ; Tue, 15 Jan 2013 01:37:56 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEBA21F8470 for ; Tue, 15 Jan 2013 01:37:55 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 99F401DED306 for ; Tue, 15 Jan 2013 10:37:53 +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 DfG_00e3lDe7 for ; Tue, 15 Jan 2013 10:37:44 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B21A21E35280 for ; Tue, 15 Jan 2013 10:37:44 +0100 (CET) Received: (qmail 85705 invoked from network); 15 Jan 2013 09:37:44 -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 ; 15 Jan 2013 09:37:44 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Tue, 15 Jan 2013 10:37:43 +0100 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 In-Reply-To: <50F51E90.1040005@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441091065_41452786" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 09:38:02 -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_3441091065_41452786 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, The term irregularly is totally ambiguous. The CA either has, or has not issued a certificate with the serial number i= n question. That is all the responder need to know. If it has been issued and still is bad, then it should be revoked. In this case the protocol works as usual. Hence, I can't support your proposal. Also, old clients have no need to know what is going on, They will just see "revoked" and act accordingly, which is intended. In case of an audit, the extension is there and thus, parties can conclude what happened. That is the reason for the extension. /Stefan From: Denis Pinkas Date: Tuesday, January 15, 2013 10:17 AM To: Stefan Santesson Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > =20 > =20 > Stefan, > =20 > You said: "The purpose of this exercise is to provide a solution that wo= rks > with legacy clients". True, but not only. > =20 > As proposed, new clients have no way to know that the OCSP responder is = using > the database of issued certificates from the CA. > A non-critical extension to an individual response should be added to > advertise it. > =20 > You said: "the on hold bit is the only one that is known to represent a > temporary revocation in current clients". > =20 > This is not what RFC 5280 says, nor what X.509 states. I have made a sea= rch > in X.509: > =20 > =20 >=20 > Text from X.509 using =B3temporarily=B2 or =B3on hold=B2 > =20 > 8.5 Basic CRL extensions > =20 > 8.5.1 Requirements > =20 > The following requirements relate to CRLs: > =20 > a) Certificate users need to be able to track all CRLs issued from a CRL > issuer or CRL distribution point (see 8.6) > and be able to detect a missing CRL in the sequence. CRL sequence number= s are > therefore required. > =20 > b) Some CRL users may wish to respond differently to a revocation, depend= ing > upon the reason for the revocation. > There is therefore a requirement for a CRL entry to indicate the reason = for > revocation. > =20 > c) There is a requirement for an authority to be able to temporarily susp= end > validity of a certificate and subsequently > either revoke or reinstate it. Possible reasons for such an action inclu= de: > =20 > =AD desire to reduce liability for erroneous revocation when a revocation > request is unauthenticated and there is inadequate > information to determine whether it is valid; > =20 > =AD other business needs, such as temporarily disabling the certificate of = an > entity pending an audit or Investigation. > =20 > =20 > =20 > 8.5.2.2 Reason code extension > =20 > A certificate may be placed on hold by issuing a CRL entry with a reason = code > of certificateHold. The certificate hold notice > may include an optional hold instruction code to convey additional > information to certificate users (see 8.5.2.3). > =20 > Once a hold has been issued, it may be handled in one of three ways: > =20 > a) it may remain on the CRL with no further action, causing users to reje= ct > transactions issued during the hold period; or, > =20 > b) it may be replaced by a (final) revocation for the same certificate, i= n > which case the reason shall be one of the standard reasons > for revocation, the revocation date shall be the date the certificate wa= s > placed on hold, and the optional instruction code extension > field shall not appear; or, > =20 > c) it may be explicitly released and the entry removed from the CRL > =20 > =20 > =20 > 9 Delta CRL relationship to base > =20 > (=8A) > =20 > A certificate's revocation notice, with revocation reason certificateHold= , may > appear on either a dCRL or a CRL that is complete > for a given scope. This reason code is intended to indicate a temporary > revocation of the certificate pending a further decision on > whether to permanently revoke the certificate or reinstate it as one tha= t is > not revoked. > =20 >=20 > You will also notice that all this appies to CRLs, since neither X.509, = nor > RFC 5280 say how to handle revocation in the context of OCSP. > =20 > There is not even a path processing procedure, which is a fundamental de= fect > of RFC 2560. > =20 > RFC 2560 states: > =20 > =20 > =20 > The "revoked" state indicates that the certificate has been revoked > =20 > (either permanantly or temporarily (on hold)). > =20 > It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice als= o > that the sentence "(either permanantly or temporarily)" is in parenthesis= . > =20 > Anyway, we may clarify this and this was my original change proposal, wh= ich I > copy again below=20 > (see may email from 11/01/2013 13:55): > =20 > =20 > OLD: > =20 > =20 > 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. > =20 > NEW: > =20 > The "revoked" state indicates that the certificate has been revoked, > either permanently or temporarily (i.e. certificateHold or > notIssuedOrIrregularlyIssued). In particular, this state MAY be > returned if the responder knows that currently the serial number > from the requested certificate has not been used by the CA to issue > a certificate or has been used irregularly to issue a certificate. > =20 > NOTE: The "revoked" state is used rather than the =B3unknown=B2 state, to > make sure that relying parties that were conformant to RFC 2560 > will not use CRLs as a fall back mechanism. > =20 > Using certificateHold creates problems as already mentioned (see may ema= il > from 11/01/2013 13:55), > whereas using case 7 in the enumeration does not. > =20 > Note that there is yet another reason of not importing CRLReason from RF= C > 5280:=20 > removeFromCRL cannot be used in OCSP responses. > =20 > =20 > CRLReason ::=3D ENUMERATED { > =20 > unspecified (0), > =20 > keyCompromise (1), > =20 > cACompromise (2), > =20 > affiliationChanged (3), > =20 > superseded (4), > =20 > cessationOfOperation (5), > =20 > certificateHold (6), > =20 > -- value 7 is not used > =20 > removeFromCRL (8), > =20 > privilegeWithdrawn (9), > =20 > aACompromise (10) } > =20 > =20 > =20 > Denis > =20 > =20 > =20 > =20 >> =20 >> Two things, >> =20 >>=20 >> =20 >> =20 >> 1) The purpose of this exercise is to provide a solution that works with >> legacy clients. That is, the output provided by the responder have to wo= rk >> and provide the desired effect when sent to a client using a current >> implementation of OCSP. >> =20 >> 2) The extension was evidently required after discussions at the last IE= TF >> meeting to reach WG rough consensus on this mechanism. The reason being >> mainly to support audit when going back and examining what happened, it = must >> be evident that the responder operated using this extended definition of >> revoked. >> =20 >>=20 >> =20 >> =20 >> Therefore, the on hold bit is the only one that is known to represent a >> temporary revocation in current clients. >> =20 >> And therefore the extension is needed. >> =20 >>=20 >> =20 >> =20 >> The rationale you give for not using certificateHold, is provide no prob= lems. >> =20 >> I see no obligation to help your client understand that this serial numb= er >> will never be released from certificateHold. >> =20 >> Because your client must always consider that as a possibility when seei= ng >> certificateHold, so it should not fail badly in any case. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas >> Date: Friday, January 11, 2013 5:24 PM >> To: Stefan Santesson >> Cc: >> Subject: Re: [pkix] About extended Revoked Extension defined in sectio= n >> 4.4.8 of ocsp draft 8 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> Stefan, >>> =20 >>> We both agree that the serial number is CURRENTLY regarded as revoked,= but >>> this may change in the future, >>> i.e. a legitimate certificate may be issued with this serial number". >>> =20 >>> However, the use of certificateHold is not a good match, as it is >>> explained below. >>> The use of the extended Revoked Extension defined in section 4.4.8 is= an >>> overcomplication that is not necessary in my proposal. >>> =20 >>> You have provided no argument about the proposal for using case 7 in t= he >>> enumeration of CRL revocation reasons. >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>> =20 >>>> =20 >>>> The purpose is to signal that the serial number is CURRENTLY regarded = as >>>> revoked, but this may change in the future, i.e. a legitimate certific= ate >>>> may be issued with this serial number. >>>> =20 >>>> Thus the certificateHold is a good match. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: Denis Pinkas >>>> Date: Friday, January 11, 2013 3:59 PM >>>> To: Erwann Abalea >>>> Cc: >>>> Subject: Re: [pkix] About extended Revoked Extension defined in sect= ion >>>> 4.4.8 of ocsp draft 8 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Erwann, >>>>> =20 >>>>> Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED >>>>> =20 >>>>> Case 7 is unused. >>>>> =20 >>>>> Denis >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> 2013/1/11 Denis Pinkas >>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>> =20 >>>>>>> The re-use of onhold reason code is not meaningful, because it does= not >>>>>>> correspond to the meaning of onhold >>>>>>> =20 >>>>>>> as it is used today. Some applications dealing with electronic >>>>>>> signatures are already applying a specific treatment >>>>>>> =20 >>>>>>> on that reason code. Depending of the content of the signature poli= cy, >>>>>>> these applications may =B3wait and >>>>>>> =20 >>>>>>> come back later=B2 to see if there is a change in the revocation stat= us. >>>>>>> That change will never happen >>>>>>> =20 >>>>>>> if the certificate has not been regularly issued. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> It would be more appropriate to use a specific reason code that wil= l >>>>>>> only appear in OCSP Responses, and never in CRLs. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> The authors of RFC 5280 were very wise, because that have reserved = bit 7 >>>>>>> for a purpose that is not supported in CRLs. >>>>>>> =20 >>>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> If you're talking about bit instead of enumerated value, then you're >>>>>> talking about the "ReasonFlags" definition that is used in >>>>>> cRLDistributionPoints extension instead of the "CRLReason" definitio= n >>>>>> used to indicate the revocation reason. And this "ReasonFlags" bit s= tring >>>>>> already uses bit 7 ;) >>>>>> =20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Erwann.=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> _______________________________________________ pkix mailing list >>>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ pkix mailing list >>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3441091065_41452786 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>The term irregularly is totally ambiguous.

The = CA either has, or has not issued a certificate with the serial number in que= stion.
That is all the responder need to know.

If it has been issued and still is bad, then it should be revoked. In = this case the protocol works as usual.

Hence, I can= 't support your proposal.

Also, old clients have no= need to know what is going on, They will just see "revoked" and act accordi= ngly, which is intended.
In case of an audit, the extension is the= re and thus, parties can conclude what happened.
That is the reaso= n for the extension.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Tuesday, January 15, 2013 10:17 AM
<= span style=3D"font-weight:bold">To: Stefan Santesson <stefan@aaa-sec.com>
Cc: <pkix@ietf.org>=
Subject: Re: [pkix] About extende= d Revoked Extension defined in section 4.4.8 of ocsp draft 8
<= br>
Stefan,

You said: "The purpose of this exercise is to provide a solution that works with legacy clients". True, but not only.

As proposed, new clients have no way to know that the OCSP responder is using the database of issued certificates from the CA.
A non-critical extension to an individual response should be added to advertise it.

You said: "the on hold bit is the only one that is known to represent a temporary revocation in current clients".

This is not what RFC 5280 says, nor what X.509 states. I have made a search in X.509:

Text from X.509 using “temporarily” or “on hold= 221;

8.5 Basic CRL extensions

8.5.1 Requirements

The following requirements relate to CRLs:

a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 8.6)
and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required.=

b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation.
There is therefore a requirement for a CRL entry to indicate the reason for revocation.

c) There is a requirement for an authority to be able to temporarily suspend validity of a certificate and subsequently
either revoke or reinstate it. Possible reasons for such an action include:

– desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate
information to determine whether it is valid;

– other business needs, such as temporarily disabling the certificate of an entity pending an audit or Investigation.

 

8.5.2.2 Reason code extension

A certificate may be placed on hold by issuing a CRL entry with a reason code of certifi= cateHold. The certificate hold notice
may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways:

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or,=

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons
for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension
field shall not appear; or,

c) it may be explicitly released and the entry removed from the CRL

 

9 Delta CRL relationship to base

(…)

A certificate's revocation notice, with revocation reason certif= icateHold, may appear on either a dCRL or a CRL that is complete
for a given scope. This reason code is intended to indicate a temporary revocation of the certificate pending a further decision on
whether to permanently revoke the certificate or reinstate it as one that is not revoked.


You will also notice that all this appies to CRLs, since neither X.509, nor RFC 5280 say how to handle revocation in the context of OCSP.

<= o:p>There is not even a path processing procedure, which is a fundamental defect of RFC 2560.

RFC 2560 states:


<= o:p>

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

   (either permanantly or temporarily (on hold)).


 It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the sentence "(either permanantly or temporarily)" is in parenthesis.

Anyway, we may clarify this and this was my original change proposal, which I copy again below
(see may email from 11/01/2013 13:55):

OLD:

  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 certificat=
e has
  never been issued during the history of the associated CA usi=
ng any
  current or previous issuing key.

NEW: 

   The "revoked" state indicates th=
at the certificate has been revoked,
   either permanently or temporarily (i.e. certificateHold=
 or
   notIssuedOrIrregularlyIssued).  In particular, this state MAY be
   returned if the responder knows that currently the seri=
al number
   from the requested certificate has not been used by the=
 CA to issue
   a certificate or has been used irregularly to issue a c=
ertificate.
= 
NOTE: The "re=
voked" state is used rather than the “unknown” state, to
      make sure that relying parties that w=
ere conformant to RFC 2560
      will not use CRLs as a fall back mech=
anism.
<= span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">
Using certificateHold creates problems as already mentioned (see may email from 11/01/2013 13:55),
whereas using case 7 in the enumeration does not.

Note that there is yet another reason of not importing CRLReason from RFC 5280:
removeFr= omCRL cannot be used in OCSP responses.

<= span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">

CRLReason= ::=3D ENUMERATED {

        unsp= ecified      &n= bsp;      (0),

        keyC= ompromise      =      (1),

        cACo= mpromise      &= nbsp;     (2),

        affi= liationChanged      = (3),

        supe= rseded      &nb= sp;       (4),

        cess= ationOfOperation    (5)= ,<= /b>

        cert= ificateHold     &nbs= p;   (6),

         =     -- value 7 is not used<= b style=3D"mso-bidi-font-weight:normal">        priv= ilegeWithdrawn      = (9),=

        aACo= mpromise      &= nbsp;    (10) }=

 


Denis


=
Two things,

1) The purpose of this exercise is to provide a solution that works with legacy clients. That is, the output provided by the responder have to work and provide the desired effect when sent to a client using a current implementation of OCSP.
2) The extension was evidently required after discussions at the last IETF meeting to reach WG rough consensus on this mechanism. The reason being mainly to support audit when going back and examining what happened, it must be evident that the responder operated using this extended definition of revoked.
=

Therefore, the on hold bit is the only one that is known to represent a temporary revocation in current clients.
And therefore the extension is needed.

The rationale you give for not using certificateHold, is provide no problems.
I see no obligation to help your client understand that this serial number will never be released from certificateHold.
Because your client must always consider that as a possibility when seeing certificateHold, so it should not fail badly in any case.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 5:24 PM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it is explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons.

Denis


The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number.
Thus the certificateHold is a good match.

/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea <eabalea@gmail.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Erwann,

Yes indeed, it is not a bit, since CRLReason ::=3D ENUMERATED

Case 7 is unused.

Denis



2013/1/11 Denis Pinkas <denis.pinkas@bull.= net>

The re-use of onhol=
d reason code is not meaningful, because it does not correspond to the meani=
ng of onhold 
as it is used today=
. Some applications dealing with electronic signatures are already applying =
a specific treatment 
on that reason code=
. Depending of the content of the signature policy, these applications may &=
#8220;wait and 
come back laterR=
21; to see if there is a change in the revocation status. That change will n=
ever happen 
if the certificate =
has not been regularly issued.
 
= 
It would be more ap=
propriate to use a specific reason code that will only appear in OCSP Respon=
ses, and never in CRLs.
 
= 
The authors of RFC =
5280 were very wise, because that have reserved bit 7 for a purpose that is =
not supported in CRLs.  <=
/pre>

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

--
Erwann.

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

_______________________________________________ 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_3441091065_41452786-- From mrex@sap.com Tue Jan 15 02:46: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 8AB8F21F8804 for ; Tue, 15 Jan 2013 02:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.191 X-Spam-Level: X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 YnccbhcOQ1Su for ; Tue, 15 Jan 2013 02:46:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 17DFF21F87F7 for ; Tue, 15 Jan 2013 02:46:29 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0FAkQA6011551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2013 11:46:26 +0100 (MET) In-Reply-To: <50F51E90.1040005@bull.net> To: Denis Pinkas Date: Tue, 15 Jan 2013 11:46:26 +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: <20130115104626.8EEA11A457@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 10:46:39 -0000 Denis Pinkas wrote: > > Stefan, > > You said: "the on hold bit is the only one that is known to represent a > temporary revocation in current clients". Which appears to be a perfect match to your own findings: > > RFC 2560 states: > > The "revoked" state indicates that the certificate has been revoked > > (either permanantly or temporarily (on hold)). > > It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that > the sentence "(either permanantly or temporarily)" is in parenthesis. The stuff in the parenthesis is a further explanation to the stuff just preceding the parenthesis. Based on this explanation in rfc2560, a revocation will come in one of two forms: (1) permanent revocation and (2) temporary revocation. Temporary revocation is further explained to consist of the certificateHold status. As you note yourself, it does *NOT* say "e.g. on hold", so it can *not* be expected from OCSP clients to recognize any other ReasonCode besides "certificateHold" as a temporary revocation status. > > This is not what RFC 5280 says, nor what X.509 states. I have made a > search in X.509: What needs to be done is looking at the semantics defined for the certificateHold ReasonCode, the only revocation reason code that could be expected to be properly recognized as a temporary status indication by an rfc2560 client. > > *8.5.1 Requirements* > > The following requirements relate to CRLs: Requirements for CRLs are mostly irrelevant for OCSP, since OCSP is not a CRL. What is relevant is the semantics of the ReasonCode(s), which can be conveyed through OCSP, and which _may_ originate from a real CRL. Howver, there is *NO* requirement that this ReasonCode originates from a real CRL. Anyhow, the only thing that can be reasonably expected to be understood by an OCSP client is the X.509 semantics defined for the certificateHold ReasonCode, since that is the only definition that existed when the installed base was created. > > *8.5.2.2 Reason code extension* > > A certificate may be placed on hold by issuing a CRL entry with a reason > code of *certificateHold*. The certificate hold notice > may include an optional hold instruction code to convey additional > information to certificate users (see 8.5.2.3). > > Once a hold has been issued, it may be handled in one of three ways: > > a) it may remain on the CRL with no further action, causing users to > reject transactions issued during the hold period; or, Up to here is all what we need from X.509 ReasonCode semantics. We have our OCSP responder convey certificateHold with no further action, causing OCSP clients to reject transactions issued during the hold period. This is exactly the semantics we want to re-use for OCSP to convey the "not issued" status in a fashion that has a high likelyhood to be understood as a temporary revocation. > > You will also notice that all this appies to CRLs, since neither X.509, > nor RFC 5280 say how to handle revocation in the context of OCSP. This statement is somewhat silly. By making the ReasonCode extension an optional element of an OCSP singleResponse, the part of the semantics of the ReasonCodes that isn't wedlocked to CRLs, but has a generic meaning with respect to the revocation cause and revocation status has become part of the (optional) OCSP semantics. removeFromCRL is a ReasonCode with a semantics that is clearly wedlocked to CRLs, and an OCSP responder that would an OCSP response with the revoked(ReasonCode=removeFromCRL) must be considered defective. -Martin From piyush@ditenity.com Tue Jan 15 05:29: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 8AEBF21F8795 for ; Tue, 15 Jan 2013 05:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 DB1vvCHuoxjq for ; Tue, 15 Jan 2013 05:29:15 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2756D21F8792 for ; Tue, 15 Jan 2013 05:29:15 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id dn14so90727obc.16 for ; Tue, 15 Jan 2013 05:29:14 -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:x-mailer:thread-index :content-language:x-gm-message-state; bh=/zmSEAZ5vFV7YkCTOdtcjVkYCPUsGjI2shx2Kj5KZuo=; b=OLiMt/PrEVD/0w1lty+Q5FN841kTV3kOda46Ux4MgBG+CA4iGPAgwdwnL8rkOHuX+C MYJkRNy482eDdlb0xj61h5wcQxATSUmDXbzt6fhoABi+0tiGP10toJ62r64Q8Spk/s+k bczHdwWo7EjxCKtnvbVWTZOcS7kO/bMbM6mPAHB1c9ghOr5Vhdydx7o+5OkHkWreJpSc pIFU1d2w7pwsmBz1OFgDW6J7V6yQQei8u7uuiCN1RVyjjVQkeoUh6F6NtzZFH4/i5Oxi bhrWVoF0uGweZSBfCcfBHXAqNBxaY1R9E3jwkSxMZ9bRR7fiZniLpC/ZWZ8Ux8rB13Ll p6qw== X-Received: by 10.60.169.240 with SMTP id ah16mr56280379oec.9.1358256554577; Tue, 15 Jan 2013 05:29:14 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vs4sm13021217obb.14.2013.01.15.05.29.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 05:29:13 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Denis Pinkas'" References: <50F51E90.1040005@bull.net> In-Reply-To: Date: Tue, 15 Jan 2013 05:29:08 -0800 Message-ID: <033a01cdf324$4d565c50$e80314f0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033B_01CDF2E1.3F4B1120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI9SMnbVHX0Ajd3M+/5k3XCaQpu8pdrsGzw Content-Language: en-us X-Gm-Message-State: ALoCoQnkL3VDdYBJvWfJ+Gzq+4gDdsXB+/TGB4mkqEJMTPmR4F4Bu1wHZix07gmZ74PBpcbuTtP2 Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 13:29:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033B_01CDF2E1.3F4B1120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefan, notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given that this draft is deviating from the normally accepted definition of issued i.e. signed. The fact that responder cannot differentiate between certs not signed by the CA and those signed by a compromised CA does not make the distinction any less important for the client. In latter case, a security conscious client should not accept any certificate issued by the CA until the extent of CA compromised is determined. Moreover you have not provided a single example where a genuine client benefits from sending a request for non-existent certificate. In absence of such examples, you can only interpret that from client's point of view irregularly issued certificates are going to be more prevalent than non-existent certificates. Therefore using the term non-issued would be misleading to clients who do encounter a situation where they receive a revoked response for such class of certificate serial numbers. For audit purpose, the extension and notIssuedOrIrregularlyIssued are semantically equivalent. Auditors can look for either the presence of this new extension or the presence of reason code 'notIssuedOrIrregularlyIssued. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, January 15, 2013 1:38 AM To: Denis Pinkas Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Denis, The term irregularly is totally ambiguous. The CA either has, or has not issued a certificate with the serial number in question. That is all the responder need to know. If it has been issued and still is bad, then it should be revoked. In this case the protocol works as usual. Hence, I can't support your proposal. Also, old clients have no need to know what is going on, They will just see "revoked" and act accordingly, which is intended. In case of an audit, the extension is there and thus, parties can conclude what happened. That is the reason for the extension. /Stefan From: Denis Pinkas Date: Tuesday, January 15, 2013 10:17 AM To: Stefan Santesson Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Stefan, You said: "The purpose of this exercise is to provide a solution that works with legacy clients". True, but not only. As proposed, new clients have no way to know that the OCSP responder is using the database of issued certificates from the CA. A non-critical extension to an individual response should be added to advertise it. You said: "the on hold bit is the only one that is known to represent a temporary revocation in current clients". This is not what RFC 5280 says, nor what X.509 states. I have made a search in X.509: Text from X.509 using "temporarily" or "on hold" 8.5 Basic CRL extensions 8.5.1 Requirements The following requirements relate to CRLs: a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 8.6) and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required. b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation. There is therefore a requirement for a CRL entry to indicate the reason for revocation. c) There is a requirement for an authority to be able to temporarily suspend validity of a certificate and subsequently either revoke or reinstate it. Possible reasons for such an action include: - desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate information to determine whether it is valid; - other business needs, such as temporarily disabling the certificate of an entity pending an audit or Investigation. 8.5.2.2 Reason code extension A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). Once a hold has been issued, it may be handled in one of three ways: a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, c) it may be explicitly released and the entry removed from the CRL 9 Delta CRL relationship to base (.) A certificate's revocation notice, with revocation reason certificateHold, may appear on either a dCRL or a CRL that is complete for a given scope. This reason code is intended to indicate a temporary revocation of the certificate pending a further decision on whether to permanently revoke the certificate or reinstate it as one that is not revoked. You will also notice that all this appies to CRLs, since neither X.509, nor RFC 5280 say how to handle revocation in the context of OCSP. There is not even a path processing procedure, which is a fundamental defect of RFC 2560. RFC 2560 states: The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the sentence "(either permanantly or temporarily)" is in parenthesis. Anyway, we may clarify this and this was my original change proposal, which I copy again below (see may email from 11/01/2013 13:55): OLD: 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. NEW: The "revoked" state indicates that the certificate has been revoked, either permanently or temporarily (i.e. certificateHold or notIssuedOrIrregularlyIssued). In particular, this state MAY be returned if the responder knows that currently the serial number from the requested certificate has not been used by the CA to issue a certificate or has been used irregularly to issue a certificate. 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. Using certificateHold creates problems as already mentioned (see may email from 11/01/2013 13:55), whereas using case 7 in the enumeration does not. Note that there is yet another reason of not importing CRLReason from RFC 5280: removeFromCRL cannot be used in OCSP responses. CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), -- value 7 is not used removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } Denis Two things, 1) The purpose of this exercise is to provide a solution that works with legacy clients. That is, the output provided by the responder have to work and provide the desired effect when sent to a client using a current implementation of OCSP. 2) The extension was evidently required after discussions at the last IETF meeting to reach WG rough consensus on this mechanism. The reason being mainly to support audit when going back and examining what happened, it must be evident that the responder operated using this extended definition of revoked. Therefore, the on hold bit is the only one that is known to represent a temporary revocation in current clients. And therefore the extension is needed. The rationale you give for not using certificateHold, is provide no problems. I see no obligation to help your client understand that this serial number will never be released from certificateHold. Because your client must always consider that as a possibility when seeing certificateHold, so it should not fail badly in any case. /Stefan From: Denis Pinkas Date: Friday, January 11, 2013 5:24 PM To: Stefan Santesson Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Stefan, We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number". However, the use of certificateHold is not a good match, as it is explained below. The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal. You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons. Denis The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number. Thus the certificateHold is a good match. /Stefan From: Denis Pinkas Date: Friday, January 11, 2013 3:59 PM To: Erwann Abalea Cc: Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Erwann, Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED Case 7 is unused. Denis 2013/1/11 Denis Pinkas The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment on that reason code. Depending of the content of the signature policy, these applications may "wait and come back later" to see if there is a change in the revocation status. That change will never happen if the certificate has not been regularly issued. It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;) -- Erwann. _______________________________________________ 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 ------=_NextPart_000_033B_01CDF2E1.3F4B1120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given = that this draft is deviating from the normally accepted definition of = issued i.e. signed.

 

The fact that responder cannot differentiate between certs not signed = by the CA and those signed by a compromised CA does not make the = distinction any less important for the client. In latter case, a = security conscious client should not accept any certificate issued by = the CA until the extent of CA compromised is = determined.

 

Moreover you have not provided a single example where a genuine = client benefits from sending a request for non-existent certificate. In = absence of such examples, you can only interpret that from = client’s point of view irregularly issued certificates are going = to be more prevalent than non-existent certificates. Therefore using the = term non-issued would be misleading to clients who do encounter a = situation where they receive a revoked response for such class of = certificate serial numbers.

 

For audit purpose, the extension and notIssuedOrIrregularlyIssued are = semantically equivalent.

Auditors can look for either the presence of this new extension or = the presence of reason code = ‘notIssuedOrIrregularlyIssued.

 

-Piyush

 

 

 

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Stefan Santesson
Sent: Tuesday, January 15, 2013 1:38 = AM
To: Denis Pinkas
Cc: = pkix@ietf.org
Subject: Re: [pkix] About extended Revoked = Extension defined in section 4.4.8 of ocsp draft = 8

 

Denis,

 

The term irregularly is totally = ambiguous.

 

The CA either has, or has not issued a certificate with the serial = number in question.

That is all the responder need to = know.

 

If it has been issued and still is bad, then it should be revoked. In = this case the protocol works as = usual.

 

Hence, I can't support your = proposal.

 

Also, old clients have no need to know what is going on, They will just = see "revoked" and act accordingly, which is = intended.

In case of an audit, the extension is there and thus, parties can = conclude what happened.

That is the reason for the = extension.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Tuesday, January 15, 2013 10:17 AM
To: Stefan = Santesson <stefan@aaa-sec.com>
Cc: = <pkix@ietf.org>
Subject: = Re: [pkix] About extended Revoked Extension defined in section 4.4.8 = of ocsp draft 8

 

Stefan,

You said: "The purpose of this exercise is to = provide a solution that works with legacy clients". True, but not = only.

As proposed, new clients have no way to know that the OCSP = responder is using the database of issued certificates from the CA.
A = non-critical extension to an individual response should be added to = advertise it.

You said: "the on hold bit is the only one = that is known to represent a temporary revocation in current = clients".

This is not what RFC 5280 says, nor what X.509 = states. I have made a search in X.509:

Text = from X.509 using “temporarily” or “on = hold”

8.5 = Basic CRL extensions

8.5.1 = Requirements

The = following requirements relate to CRLs:

a) = Certificate users need to be able to track all CRLs issued from a CRL = issuer or CRL distribution point (see 8.6)
and be able to detect a = missing CRL in the sequence. CRL sequence numbers are therefore = required.

b) Some CRL = users may wish to respond differently to a revocation, depending upon = the reason for the revocation.
There is therefore a requirement for = a CRL entry to indicate the reason for revocation.

c) There is = a requirement for an authority to be able to temporarily = suspend validity of a certificate and subsequently
either revoke or = reinstate it. Possible reasons for such an action include:

– = desire to reduce liability for erroneous revocation when a revocation = request is unauthenticated and there is inadequate
information to = determine whether it is valid;

– = other business needs, such as temporarily = disabling the certificate of an entity pending an audit or = Investigation.

=  

8.5.2.2 = Reason code extension

A = certificate may be placed on hold by issuing a CRL entry = with a reason code of certificateHold. The certificate = hold notice
may include an optional hold instruction code to convey = additional information to certificate users (see 8.5.2.3).

Once a hold = has been issued, it may be handled in one of three ways:

a) it may = remain on the CRL with no further action, causing users to reject = transactions issued during the hold period; or,

b) it may = be replaced by a (final) revocation for the same certificate, in which = case the reason shall be one of the standard reasons
for revocation, = the revocation date shall be the date the certificate was placed on = hold, and the optional instruction code extension
field shall not = appear; or,

c) it may = be explicitly released and the entry removed from the CRL

=  

9 Delta = CRL relationship to base

= (…)

A = certificate's revocation notice, with revocation reason = certificateHold, may appear on either a dCRL or a CRL that is = complete
for a given scope. This reason code is intended to indicate = a temporary = revocation of the certificate pending a further decision on
whether = to permanently = revoke the certificate or reinstate it as one that is not = revoked.

=
You will also notice that = all this appies to CRLs, since neither X.509, nor RFC 5280 say how to = handle revocation in the context of OCSP.

There is not even a path processing procedure, which is a fundamental = defect of RFC 2560.

RFC 2560 states:



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

   (either permanantly or temporarily (on = hold)).


It does not say "(i.e. on hold)", nor "(e.g. on = hold)". Notice also that the sentence "(either permanantly or temporarily)" is in = parenthesis.

Anyway, we may clarify this and this was my original = change proposal, which I copy again below
(see may email from = 11/01/2013 13:55):

OLD:

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

NEW:

   The "revoked" state =
indicates that the certificate has been =
revoked,
   either permanently or temporarily =
(i.e. certificateHold or
   notIssuedOrIrregularlyIssued).  =
In particular, this state MAY be
   returned if the =
responder knows that currently the serial =
number
   from the requested certificate has =
not been used by the CA to issue
   a certificate or has =
been used irregularly to issue a certificate.
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.


Using certificateHold creates problems as already mentioned (see = may email from 11/01/2013 13:55),
whereas using case 7 in the = enumeration does not.

Note that there is yet another reason of = not importing CRLReason from RFC 5280:
removeFromCRL cannot be used = in OCSP responses.


CRLReason ::=3D ENUMERATED = {

     &nbs= p;  = unspecified          &n= bsp;  (0),

     &nbs= p;  = keyCompromise          = (1),

     &nbs= p;  = cACompromise          &= nbsp; (2),

     &nbs= p;  affiliationChanged      = (3),

     &nbs= p;  = superseded          &nb= sp;   (4),

     &nbs= p;  cessationOfOperation    (5),

     &nbs= p;  certificateHold         = (6),

     &nbs= p;       -- value 7 is not = used

     &nbs= p;  = removeFromCRL          = (8),

     &nbs= p;  privilegeWithdrawn      = (9),

     &nbs= p;  = aACompromise           = (10) }

 


Denis

Two things,

 

1) The purpose of this exercise is to provide a solution that works = with legacy clients. That is, the output provided by the responder have = to work and provide the desired effect when sent to a client using a = current implementation of OCSP.

2) The extension was evidently required after discussions at the last = IETF meeting to reach WG rough consensus on this mechanism. The reason = being mainly to support audit when going back and examining what = happened, it must be evident that the responder operated using this = extended definition of revoked.

 

Therefore, the on hold bit is the only one that is known to represent a = temporary revocation in current = clients.

And therefore the extension is = needed.

 

The rationale you give for not using certificateHold, is provide no = problems.

I see no obligation to help your client understand that this serial = number will never be released from = certificateHold.

Because your client must always consider that as a possibility when = seeing certificateHold, so it should not fail badly in any = case.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 5:24 PM
To: Stefan = Santesson <stefan@aaa-sec.com>
Cc: = <pkix@ietf.org>
Subject: = Re: [pkix] About extended Revoked Extension defined in section 4.4.8 = of ocsp draft 8

 

Stefan,

We both agree that the serial number is CURRENTLY = regarded as revoked, but this may change in the future,
i.e. a = legitimate certificate may be issued with this serial number". =

However, the use of certificateHold  is not a good match, = as it is explained below.
The use of the extended Revoked Extension = defined in section 4.4.8 is an overcomplication that is not necessary in = my proposal.

You have provided no argument about the proposal for = using case 7 in the enumeration of CRL revocation = reasons.

Denis

The purpose is to signal that the serial number is CURRENTLY regarded = as revoked, but this may change in the future, i.e. a legitimate = certificate may be issued with this serial = number.

Thus the certificateHold is a good = match.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea = <eabalea@gmail.com>
Cc: = <pkix@ietf.org>
Subject: = Re: [pkix] About extended Revoked Extension defined in section 4.4.8 = of ocsp draft 8

 

Erwann,

Yes indeed, it is not a bit, since CRLReason ::=3D = ENUMERATED

Case 7 is = unused.

Denis

 

2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

 

The re-use of onhold reason code is not =
meaningful, because it does not correspond to the meaning of onhold =

as it is used today. Some =
applications dealing with electronic signatures are already applying a =
specific treatment 
on that reason code. Depending of the content of =
the signature policy, these applications may “wait and =

come back later” to see if =
there is a change in the revocation status. That change will never =
happen 
if the certificate has not been regularly =
issued.
 
It would be more appropriate to use a specific =
reason code that will only appear in OCSP Responses, and never in =
CRLs.
 
The authors of RFC 5280 were very wise, because =
that have reserved bit 7 for a purpose that is not supported in CRLs. =
 

 

If you're talking about bit instead of enumerated value, then you're = talking about the "ReasonFlags" definition that is used in = cRLDistributionPoints extension instead of the "CRLReason" = definition used to indicate the revocation reason. And this = "ReasonFlags" bit string already uses bit 7 = ;)

 

--
Erwann.

 

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

------=_NextPart_000_033B_01CDF2E1.3F4B1120-- From denis.pinkas@bull.net Tue Jan 15 05:58: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 99A9A21F868F for ; Tue, 15 Jan 2013 05:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.340, 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 fEhCi1SDI-gB for ; Tue, 15 Jan 2013 05:58:11 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE521F866E for ; Tue, 15 Jan 2013 05:58:10 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id B5ED01CF11; Tue, 15 Jan 2013 14:58:09 +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 2013011514580959-18777 ; Tue, 15 Jan 2013 14:58:09 +0100 Message-ID: <50F5606D.7020909@bull.net> Date: Tue, 15 Jan 2013 14:58:05 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Piyush Jain , 'Stefan Santesson' References: <50F51E90.1040005@bull.net> <033a01cdf324$4d565c50$e80314f0$@ditenity.com> In-Reply-To: <033a01cdf324$4d565c50$e80314f0$@ditenity.com> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 15/01/2013 14:58:09, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 15/01/2013 14:58:09, Serialize complete at 15/01/2013 14:58:09 Content-Type: multipart/alternative; boundary="------------060506060203000409020505" Cc: pkix@ietf.org Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 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, 15 Jan 2013 13:58:16 -0000 This is a multi-part message in MIME format. --------------060506060203000409020505 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Piyush, We both agree. However, what is important first is to use the enumeration case 7 rather than the enumeration case 6 : "CertificateHold". Then, we can argument about the name of the enumeration case 7. However, the proposed term is well chosen: - "notIssued" may correspond to the case where the certificate serial number that was sent was erroneous and has never been used by the CA at the time of the query, - "irregularlyIssued" may correspond to the case where the certificate serial number that was sent really exists in a certificate that is correctly signed but the CA has not issued (to its knowledge) a certificate with such a serial number. However, it may indeed have been issued by the CA itself because the RA was compromised. This is why "irregularly issued" makes sense. The OCSP responder cannot distinguish between notIssued and IrregularlyIssued. Stefan, the single argument you raised is not a valid argument to refuse the whole text replacement proposal. In addition, new clients need to know what is going on. Your proposal does not allow for it. Stefan, it is time to move on now, since there will be other topics to be debated. Denis > Stefan, > > notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given > that this draft is deviating from the normally accepted definition of > issued i.e. signed. > > The fact that responder cannot differentiate between certs not signed > by the CA and those signed by a compromised CA does not make the > distinction any less important for the client. In latter case, a > security conscious client should not accept any certificate issued by > the CA until the extent of CA compromised is determined. > > Moreover you have not provided a single example where a genuine client > benefits from sending a request for non-existent certificate. In > absence of such examples, you can only interpret that from client's > point of view irregularly issued certificates are going to be more > prevalent than non-existent certificates. Therefore using the term > non-issued would be misleading to clients who do encounter a situation > where they receive a revoked response for such class of certificate > serial numbers. > > For audit purpose, the extension and notIssuedOrIrregularlyIssued are > semantically equivalent. > > Auditors can look for either the presence of this new extension or the > presence of reason code 'notIssuedOrIrregularlyIssued. > > -Piyush > > *From:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf > Of *Stefan Santesson > *Sent:* Tuesday, January 15, 2013 1:38 AM > *To:* Denis Pinkas > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] About extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Denis, > > The term irregularly is totally ambiguous. > > The CA either has, or has not issued a certificate with the serial > number in question. > > That is all the responder need to know. > > If it has been issued and still is bad, then it should be revoked. In > this case the protocol works as usual. > > Hence, I can't support your proposal. > > Also, old clients have no need to know what is going on, They will > just see "revoked" and act accordingly, which is intended. > > In case of an audit, the extension is there and thus, parties can > conclude what happened. > > That is the reason for the extension. > > /Stefan > > *From: *Denis Pinkas > > *Date: *Tuesday, January 15, 2013 10:17 AM > *To: *Stefan Santesson > > *Cc: *> > *Subject: *Re: [pkix] About extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > > Stefan, > > You said: "The purpose of this exercise is to provide a solution > that works with legacy clients". True, but not only. > > As proposed, new clients have no way to know that the OCSP > responder is using the database of issued certificates from the CA. > A non-critical extension to an individual response should be added > to advertise it. > > You said: "the on hold bit is the only one that is known to > represent a temporary revocation in current clients". > > This is not what RFC 5280 says, nor what X.509 states. I have made > a search in X.509: > > *Text from X.509 using "temporarily" or "on hold"* > > *8.5 Basic CRL extensions* > > *8.5.1 Requirements* > > The following requirements relate to CRLs: > > a) Certificate users need to be able to track all CRLs issued from > a CRL issuer or CRL distribution point (see 8.6) > and be able to detect a missing CRL in the sequence. CRL sequence > numbers are therefore required. > > b) Some CRL users may wish to respond differently to a revocation, > depending upon the reason for the revocation. > There is therefore a requirement for a CRL entry to indicate the > reason for revocation. > > c) There is a requirement for an authority to be able to > temporarily suspend validity of a certificate and subsequently > either revoke or reinstate it. Possible reasons for such an action > include: > > -- desire to reduce liability for erroneous revocation when a > revocation request is unauthenticated and there is inadequate > information to determine whether it is valid; > > -- other business needs, such as temporarily disabling the > certificate of an entity pending an audit or Investigation. > > *8.5.2.2 Reason code extension* > > A certificate may be placed on hold by issuing a CRL entry with a > reason code of *certificateHold*. The certificate hold notice > may include an optional hold instruction code to convey additional > information to certificate users (see 8.5.2.3). > > Once a hold has been issued, it may be handled in one of three ways: > > a) it may remain on the CRL with no further action, causing users > to reject transactions issued during the hold period; or, > > b) it may be replaced by a (final) revocation for the same > certificate, in which case the reason shall be one of the standard > reasons > for revocation, the revocation date shall be the date the > certificate was placed on hold, and the optional instruction code > extension > field shall not appear; or, > > c) it may be explicitly released and the entry removed from the CRL > > *9 Delta CRL relationship to base* > > (...) > > A certificate's revocation notice, with revocation reason > *certificateHold, *may appear on either a dCRL or a CRL that is > complete > for a given scope. This reason code is intended to indicate a > temporary revocation of the certificate pending a further decision on > whether to permanently revoke the certificate or reinstate it as > one that is not revoked. > > > You will also notice that all this appies to CRLs, since neither > X.509, nor RFC 5280 say how to handle revocation in the context of > OCSP. > > There is not even a path processing procedure, which is a > fundamental defect of RFC 2560. > > RFC 2560 states: > > > > The "revoked" state indicates that the certificate has been revoked > > (either permanantly or temporarily (on hold)). > > > It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice > also that the sentence "(either permanantly or temporarily)" is in > parenthesis. > > Anyway, we may clarify this and this was my original change > proposal, which I copy again below > (see may email from 11/01/2013 13:55): > > OLD: > > 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. > > NEW: > > The "revoked" state indicates that the certificate has been revoked, > > either permanently or temporarily (i.e. certificateHold or > > notIssuedOrIrregularlyIssued). In particular, this state MAY be > > returned if the responder knows that currently the serial number > > from the requested certificate has not been used by the CA to issue > > a certificate or has been used irregularly to issue a certificate. > > 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. > > > Using certificateHold creates problems as already mentioned (see > may email from 11/01/2013 13:55), > whereas using case 7 in the enumeration does not. > > Note that there is yet another reason of not importing CRLReason > from RFC 5280: > removeFromCRL cannot be used in OCSP responses. > > > *CRLReason ::= ENUMERATED {* > > * unspecified (0),* > > * keyCompromise (1),* > > * cACompromise (2),* > > * affiliationChanged (3),* > > * superseded (4),* > > * cessationOfOperation (5),* > > * certificateHold (6),* > > * -- value 7 is not used* > > * removeFromCRL (8),* > > * privilegeWithdrawn (9),* > > * aACompromise (10) }* > > ** > > > Denis > > Two things, > > 1) The purpose of this exercise is to provide a solution that > works with legacy clients. That is, the output provided by the > responder have to work and provide the desired effect when > sent to a client using a current implementation of OCSP. > > 2) The extension was evidently required after discussions at > the last IETF meeting to reach WG rough consensus on this > mechanism. The reason being mainly to support audit when going > back and examining what happened, it must be evident that the > responder operated using this extended definition of revoked. > > Therefore, the on hold bit is the only one that is known to > represent a temporary revocation in current clients. > > And therefore the extension is needed. > > The rationale you give for not using certificateHold, is > provide no problems. > > I see no obligation to help your client understand that this > serial number will never be released from certificateHold. > > Because your client must always consider that as a possibility > when seeing certificateHold, so it should not fail badly in > any case. > > /Stefan > > *From: *Denis Pinkas > > *Date: *Friday, January 11, 2013 5:24 PM > *To: *Stefan Santesson > > *Cc: *> > *Subject: *Re: [pkix] About extended Revoked Extension defined > in section 4.4.8 of ocsp draft 8 > > Stefan, > > We both agree that the serial number is CURRENTLY regarded > as revoked, but this may change in the future, > i.e. a legitimate certificate may be issued with this > serial number". > > However, the use of certificateHold is not a good match, > as it is explained below. > The use of the extended Revoked Extension defined in > section 4.4.8 is an overcomplication that is not necessary > in my proposal. > > You have provided no argument about the proposal for using > case 7 in the enumeration of CRL revocation reasons. > > Denis > > The purpose is to signal that the serial number is > CURRENTLY regarded as revoked, but this may change in > the future, i.e. a legitimate certificate may be > issued with this serial number. > > Thus the certificateHold is a good match. > > /Stefan > > *From: *Denis Pinkas > > *Date: *Friday, January 11, 2013 3:59 PM > *To: *Erwann Abalea > > *Cc: *> > *Subject: *Re: [pkix] About extended Revoked Extension > defined in section 4.4.8 of ocsp draft 8 > > Erwann, > > Yes indeed, it is not a bit, since CRLReason ::= > ENUMERATED > > Case 7 is unused. > > Denis > > 2013/1/11 Denis Pinkas > > > The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold > > as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment > > on that reason code. Depending of the content of the signature policy, these applications may "wait and > > come back later" to see if there is a change in the revocation status. That change will never happen > > if the certificate has not been regularly issued. > > > > It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs. > > > > The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs. > > If you're talking about bit instead of > enumerated value, then you're talking about > the "ReasonFlags" definition that is used in > cRLDistributionPoints extension instead of the > "CRLReason" definition used to indicate the > revocation reason. And this "ReasonFlags" bit > string already uses bit 7 ;) > > -- > Erwann. > > _______________________________________________ > 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 > --------------060506060203000409020505 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Piyush,

We both agree.

However, what is important first is to use the enumeration case 7 rather than the enumeration case 6 : "CertificateHold".

Then, we can argument about the name of the enumeration case 7.

However, the proposed term is well chosen:

- "notIssued" may correspond to the case where the certificate serial number that was sent was erroneous
   and has never been used by the CA at the time of the query,

- "irregularlyIssued" may correspond to the case where the certificate serial number that was sent really exists
   in a certificate that is correctly signed but the CA has not issued (to its knowledge) a certificate with such a serial number.
   However, it may indeed have been issued by the CA itself because the RA was compromised. This is why "irregularly issued"
   makes sense.

The OCSP responder cannot distinguish between notIssued and IrregularlyIssued.

Stefan, the single argument you raised is not a valid argument to refuse the whole text replacement proposal.

In addition, new clients need to know what is going on. Your proposal does not allow for it.

Stefan, it is time to move on now, since there will be other topics to be debated.

Denis

Stefan,

 

notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given that this draft is deviating from the normally accepted definition of issued i.e. signed.

 

The fact that responder cannot differentiate between certs not signed by the CA and those signed by a compromised CA does not make the distinction any less important for the client. In latter case, a security conscious client should not accept any certificate issued by the CA until the extent of CA compromised is determined.

 

Moreover you have not provided a single example where a genuine client benefits from sending a request for non-existent certificate. In absence of such examples, you can only interpret that from client’s point of view irregularly issued certificates are going to be more prevalent than non-existent certificates. Therefore using the term non-issued would be misleading to clients who do encounter a situation where they receive a revoked response for such class of certificate serial numbers.

 

For audit purpose, the extension and notIssuedOrIrregularlyIssued are semantically equivalent.

Auditors can look for either the presence of this new extension or the presence of reason code ‘notIssuedOrIrregularlyIssued.

 

-Piyush

 

 

 

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Tuesday, January 15, 2013 1:38 AM
To: Denis Pinkas
Cc: pkix@ietf.org
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Denis,

 

The term irregularly is totally ambiguous.

 

The CA either has, or has not issued a certificate with the serial number in question.

That is all the responder need to know.

 

If it has been issued and still is bad, then it should be revoked. In this case the protocol works as usual.

 

Hence, I can't support your proposal.

 

Also, old clients have no need to know what is going on, They will just see "revoked" and act accordingly, which is intended.

In case of an audit, the extension is there and thus, parties can conclude what happened.

That is the reason for the extension.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Tuesday, January 15, 2013 10:17 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Stefan,

You said: "The purpose of this exercise is to provide a solution that works with legacy clients". True, but not only.

As proposed, new clients have no way to know that the OCSP responder is using the database of issued certificates from the CA.
A non-critical extension to an individual response should be added to advertise it.

You said: "the on hold bit is the only one that is known to represent a temporary revocation in current clients".

This is not what RFC 5280 says, nor what X.509 states. I have made a search in X.509:

Text from X.509 using “temporarily” or “on hold”

8.5 Basic CRL extensions

8.5.1 Requirements

The following requirements relate to CRLs:

a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 8.6)
and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required.

b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation.
There is therefore a requirement for a CRL entry to indicate the reason for revocation.

c) There is a requirement for an authority to be able to temporarily suspend validity of a certificate and subsequently
either revoke or reinstate it. Possible reasons for such an action include:

– desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate
information to determine whether it is valid;

– other business needs, such as temporarily disabling the certificate of an entity pending an audit or Investigation.

 

8.5.2.2 Reason code extension

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice
may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways:

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or,

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons
for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension
field shall not appear; or,

c) it may be explicitly released and the entry removed from the CRL

 

9 Delta CRL relationship to base

(…)

A certificate's revocation notice, with revocation reason certificateHold, may appear on either a dCRL or a CRL that is complete
for a given scope. This reason code is intended to indicate a temporary revocation of the certificate pending a further decision on
whether to permanently revoke the certificate or reinstate it as one that is not revoked.


You will also notice that all this appies to CRLs, since neither X.509, nor RFC 5280 say how to handle revocation in the context of OCSP.

There is not even a path processing procedure, which is a fundamental defect of RFC 2560.

RFC 2560 states:



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

   (either permanantly or temporarily (on hold)).


It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the sentence "(either permanantly or temporarily)" is in parenthesis.

Anyway, we may clarify this and this was my original change proposal, which I copy again below
(see may email from 11/01/2013 13:55):

OLD:

  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.

NEW:

   The "revoked" state indicates that the certificate has been revoked,
   either permanently or temporarily (i.e. certificateHold or
   notIssuedOrIrregularlyIssued).  In particular, this state MAY be
   returned if the responder knows that currently the serial number
   from the requested certificate has not been used by the CA to issue
   a certificate or has been used irregularly to issue a certificate.
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.


Using certificateHold creates problems as already mentioned (see may email from 11/01/2013 13:55),
whereas using case 7 in the enumeration does not.

Note that there is yet another reason of not importing CRLReason from RFC 5280:
removeFromCRL cannot be used in OCSP responses.


CRLReason ::= ENUMERATED {

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

             -- value 7 is not used

        removeFromCRL           (8),

        privilegeWithdrawn      (9),

        aACompromise           (10) }

 


Denis

Two things,

 

1) The purpose of this exercise is to provide a solution that works with legacy clients. That is, the output provided by the responder have to work and provide the desired effect when sent to a client using a current implementation of OCSP.

2) The extension was evidently required after discussions at the last IETF meeting to reach WG rough consensus on this mechanism. The reason being mainly to support audit when going back and examining what happened, it must be evident that the responder operated using this extended definition of revoked.

 

Therefore, the on hold bit is the only one that is known to represent a temporary revocation in current clients.

And therefore the extension is needed.

 

The rationale you give for not using certificateHold, is provide no problems.

I see no obligation to help your client understand that this serial number will never be released from certificateHold.

Because your client must always consider that as a possibility when seeing certificateHold, so it should not fail badly in any case.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 5:24 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it is explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the enumeration of CRL revocation reasons.

Denis

The purpose is to signal that the serial number is CURRENTLY regarded as revoked, but this may change in the future, i.e. a legitimate certificate may be issued with this serial number.

Thus the certificateHold is a good match.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Friday, January 11, 2013 3:59 PM
To: Erwann Abalea <eabalea@gmail.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] About extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Erwann,

Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED

Case 7 is unused.

Denis

 

2013/1/11 Denis Pinkas <denis.pinkas@bull.net>

 

The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold 
as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment 
on that reason code. Depending of the content of the signature policy, these applications may “wait and 
come back later” to see if there is a change in the revocation status. That change will never happen 
if the certificate has not been regularly issued.
 
It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.
 
The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs.  

 

If you're talking about bit instead of enumerated value, then you're talking about the "ReasonFlags" definition that is used in cRLDistributionPoints extension instead of the "CRLReason" definition used to indicate the revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)

 

--
Erwann.

 

_______________________________________________ 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


--------------060506060203000409020505-- From prvs=072790a11f=rybar@nbusr.sk Tue Jan 15 06:51: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 7834F21F872C for ; Tue, 15 Jan 2013 06:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 ox0AcSE7yoy2 for ; Tue, 15 Jan 2013 06:51:53 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id C995D21F869A for ; Tue, 15 Jan 2013 06:51:51 -0800 (PST) Message-Id: <201301151451.r0FEpiRU082504@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , "'Piyush Jain'" , "'pkix'" Date: Tue, 15 Jan 2013 15:51:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CDF338.3D560C60" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac3y2OFHtv+1bKPqThecD8YLqazxTQAQS7wg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4462> : streams <890134> : uri <1319490> Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 14:51:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0021_01CDF338.3D560C60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Stefan, Probably you have missed my argument that CRLReason of certificateHold = is defined only in ITU-T X.509 and logical semantics specified for CRL = and delta CRL when certificateHold is used is problematic for the usage = in OCSP where request/response can be created several times in = unspecified time/date. =20 The usage of certificateHold as you have proposed is confusing and for = that reason I was proposing another solution where is addressed the = problem of issued certificate by CA without evidence in CA.=20 Because the sentence "revoked response for non-issued certificates" is = vague when it is only about wrong serial number and the certificate does = not exists at application creating OCSP request. It is absurd situations and OCSP responder must react with an error = message on such absurd request because that is not situation abut the = certificate status, that is wrong request which is only about the = integer number. OCSP is Online Certificate Status Protocol. It is not partial status about one or two component of the CertID! ( = serialNumber or issuerNameHash or issuerKeyHash ) =20 When OCSP has access to the CA database, what is the case defined in = rfc2560bis for "revoked response for non-issued certificates", then the = error message is right response,=20 because such certificate does not exist and=20 because the certificate does not exist also the status does not exist = about the certificate which does not exist. =20 According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 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. =20 Another argument why revocation with reason code certificateHold is = problematic:=20 ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)=20 8.5.2.2 Reason code extension Once a hold has been issued, it may be handled in one of three ways:=20 b) it may be replaced by a (final) revocation for the same certificate, = in which case the reason shall be one of the standard reasons for = revocation, the revocation date shall be the date the certificate was = placed on hold , and the optional instruction code extension field shall = not appear; or,, =20 According to =E2=80=9Cthe revocation date shall be the date the = certificate was placed on hold=E2=80=9D and according to usage of OCSP: The firs OCSP request will be in time t0 when certificate SerNum1 is not = issued. You propose OCSP response revoked where: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC =20 Then certificate will be issued in time t1 and revoked in time t2 in = CRL. =20 OCSP request will be created in time t3 and according to definition = =E2=80=9Cthe revocation date shall be the date the certificate was = placed on hold=E2=80=9D the revocation time will be =E2=80=A6 what a = problem is because two interpretations exist. Is OCSP based on CRL or not=E2=80=A6=20 When is not based on CRL as is stated in rfc2560bis for revoked then the = revocation time must be 1.1.1970 00:00:00 UTC I hope it is ridiculous :) =20 For that reason I propose to use in this situation OCSP responder error = message malformedRequest. =20 For example for clause 7.4 Repudiation of a digital signing (ISO/IEC = 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic = when certificateHold is used because transactions created in each time = when the certificate was in certificateHold must not be accepted. Also for that reason the certificateHold is forbidden in some systems or = legislations. It creates additional complexity where each CRL must be analyzed to have = the complete time line in which date/time and how long the certificate = was in the certificateHold state because the certificate can be in = certificateHold state several times. =20 =20 Martin Rex propose to use OCSP responder error message = noIssueRecordFound (7) instead of OCSPResponseStatus ::=3D ENUMERATED { ? probablyCADatabaseOrCAKeyCompromise (7) } =20 I agree, it is better and new OCSP RFC will define what will be done by = the OCSP client when OCSP responder error message malformedRequest is = received. OCSP client application will create a new OCSP request for the = certificate where this certificate will be included in the = singleRequestExtensions the extension identified by OBJECT IDENTIFIER = id-pkix-ocsp-CertOfNoIssueRecordFound . =20 According to it OCSP responder or CA will be able to solve the problems = with probably CA Database inconsistency or CA Key compromise and also = the problem how the OCSP must be able to response on certificate serial = number that don't match any issued cert. Because following response, when CA key was used, can be the real status = of the certificate or OCSP responder error message tryLater because the = analysis was started. When CA key was not used for signing the certificate in request the OCSP = responder will return error message unauthorized because OCSP is not = authorized. =20 Peter Rybar =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Tuesday, January 15, 2013 5:29 AM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients =20 Peter, =20 In general. For several reasons I'm not supportive of your proposals. =20 The basic problem is that you don't listen to the problem statement = being repeated here time after time after time. We are NOT trying to solve CA compromise. We are giving the protocol the = capability to reasonably respond to requests for serial numbers that = don't match any issued cert. =20 That may or may not be caused by CA compromise. =20 If you want to craft a perfect solution for handling CA compromise, = fine. But that is not part of this update effort. /Stefan =20 =20 From: Peter Rybar Date: Monday, January 14, 2013 4:20 PM To: Stefan Santesson , 'Piyush Jain' = , 'pkix' Subject: [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients =20 Stefan, > A good protocol should provide a reasonable response to every = possible request. =20 I agree with such general sentence but rfc2560bis-08 is not able to fix = discussed situations.=20 Good view was done by Piyush Jain [piyush@ditenity.com] in [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 =20 Let me propose another solution. We are trying to fix the situation, where the CA key was used for = signing certificate but CA is not able to provide evidence about it for = OCSP service. 1. It could be after disaster recovery procedure where the record was = lost because it was not archived. 2. Or when the CA key was compromised and was used for signing a fake = certificate. =20 I do not think that proposed solution =E2=80=9Cto provide revoked status = with a reason code certificateHold and extensions = id-pkix-ocsp-extended-revoke=E2=80=9D by OCSP to RP is helpful, because: 1. CA will not be informed about the potential inconsistency in the CA = database or about potential critical attack (DigiNotar); and=20 2. OCSP service will not be able to decide if it is a potential CA = compromise or only bad OCSP client is creating fake request because only = according to analyzing the certificate content true result can be = produces. Because according to rfc2560bis-08 the certificate is only on = the client side. 3. Solution is expensive and not useful because the signing of such = revocation response will only consume system key resources for creating = unclear response.=20 =20 At first, I propose to define a new type of the OCSP Responder error = message: OCSPResponseStatus ::=3D ENUMERATED { =E2=80=A6 probablyCADatabaseOrCAKeyCompromise (7) } =20 Or when solution is important to be understood by legacy clients then = what is defined for probablyCADatabaseOrCAKeyCompromise will be = applicable also for malformedRequest OCSP Responder error message:=20 The RFC must define rules for RP OCSP client applications where the = client will be able to repeat the OCSP request but together with the = certificate for which OCSP responder error message is = probablyCADatabaseOrCAKeyCompromise or malformedRequest. =20 This certificate will be included in singleRequestExtensions where the = extension will be identified with OBJECT IDENTIFIER id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise. =20 OCSP responder will analyze received certificate and in situations where = CA key was used the certificate will be provided to the CA for analysis = and making decisions. =20 The OCSP analysis will be the bases for the second OCSP response status = like: 1. Signed good, revoked if the certificate was missed only according to = recovery procedure; 2. Unsigned with OCSP Responder error message malformedRequest when the = CertID (issuerNameHash, issuerKeyHash, serialNumber) is not = corresponding to the form for which OCSP responder is able to provide = the status.=20 For example incorrect hash length in issuerNameHash or issuerKeyHash;=20 Incorrect serial number like when CA is using sequential number and in = request is present the serial number which is out of the maximum range = or is used unsigned/signed integer as a hash value stored in certificate = serial number=E2=80=A6 e.g. MD5 causes permanently problems with = negative serial numbers where some CA and client try to change the = negative integer of certificate serial number internally and are using = such positive integer in OCSP request what causes problems. 3. Unsigned with OCSP Responder error message unauthorized when OCSP = responder is not authorized for providing status for requested = issuerNameHash, issuerKeyHash; 4. Unsigned with OCSP Responder error message tryLater when certificate = was signed with CA key and CA must define decision what to do with it. =E2=80=A6 =20 I hope this proposal can be helpful as a starting point. =20 Peter Rybar National Security Authority Information Security and Electronic Signature Department =20 =20 =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Friday, January 11, 2013 4:05 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 From: Peter Rybar Date: Friday, January 11, 2013 3:38 PM To: Stefan Santesson , 'Piyush Jain' = , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Stefan, As you can see in my previous mail, when OCSP request contains incorrect = (malformed) serial number, because the certificate does not exist, the = OCSP Responder may return an error message malformedRequest or all other = types of responses except for revoked!!! =20 How does a serial number become malformed just because it doesn't = exists. Its just an integer. Its syntactically a well formed integer. =20 According to rfc2560bis is situation worse because the status revoked = which was about the real certificate status (in CRL or in previous OCSP = RFC) is now with extension of revoked with reason code certificateHold = defined as equivocal result when is not correctly implemented.=20 It means according to rfc2560bis all serial numbers are initially = revoked with reason code certificateHold=E2=80=A6 Is it useful? =20 Yes. =20 (The revoked with reason code certificateHold is based on CA database = and in some next steps database can also include the hash values of = certificates for positive statement!) =20 For that reason some systems and legislations where non-repudiation = services are required (e.g. QES) dictate that status value good or = revoked in OCSP response MUST contain a positive statement a hash value = of certificate in singleExtensions. =20 =20 Then that can be achieved by defining a new single response extension = that does not interfere with what is being done in 2560bis. =20 When hash of the certificate as a positive statement MUST be used, the = situations with OCSP responses for RP are clear and unique because: 1) good or revoked is only about know and issued certificates, =20 Great, so how then do you respond to a request for a serial number that = has never been issued? =20 2) any other situations are moved into one group which is unclear and = not analyzed =E2=80=93 no evidence, no responsibility. =20 But the responder still need to respond. =20 =20 It is a radical simplification! =20 Of what? =20 =20 Instead of trying to solve presently not practical and theoretical = situations from the responsibility/liability point of view (like = preparing us for situations: what we will offer for intergalactic green = man, are vegetarian? ;) we can define steps which can be implemented by = CAs and OCSP systems like usage of positive statement cert hash. =20 =20 Asking for status of a never issued serial number is not impossible. It = is not even hard. A good protocol should provide a reasonable response to every possible = request. =20 E.g. define new or reuse already defined in private OID space. PositiveStatement ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, certHash OCTET STRING, -- Hash of Subjects certificate } =20 And according it we cam move. =20 I have nothing against such extension being defined. But it still does not remove the need for the current discussed = mechanism. =20 The current discussed mechanism address how to respond to legacy clients = to requests for non-issued serial numbers. Your extension does not help, because it is not understood by legacy = clients. =20 So its not either or. =20 /Stefan =20 =20 Peter Rybar =20 =20 _____ =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, January 10, 2013 2:19 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Peter, i think the reason for this has been thoroughly debated. =20 It is correct that a cert serial number that was on hold, may be = released. The requested cert serial number may actually be used in a future = representing a real certificate. So this is intentional and the whole purpose behind using the on hold = reason. =20 /Stefan =20 From: Peter Rybar Date: Thursday, January 10, 2013 12:13 PM To: 'Piyush Jain' , Stefan Santesson = , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 Stefan, For me is unclear how this extension of revoked with reason code = certificateHold is useful. It define that now is possible to revoke what does not exist and it open = never ending cycle of trying to fixing or correcting the first incorrect = status that "fake" cert serial number is revoked but cert serial number = is not revoked because "fake" cert does not exist. =20 I agree that extension of revoked can be helpful like: The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. =20 =20 When the certificate serial number is not in the OCSP database/CRL then = according to rfc2560bis there are defined following possible responses: 1. signed - good (e.g. certificate serial number is not listed in CRL) 2. signed - unknown (e.g. certificate serial number is not listed in = CRL) 3. unsigned =E2=80=93 unauthorized as an error message 4. signed - revoked where according to rfc2560bis are defined values = for: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC =20 What is missing? The rfc2560bis must also specify values for: This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC =20 X.509 defines the reason code certificateHold as 1) it may remain on the = CRL; 2) it may be replaced by a (final) revocation; 3) it may be = explicitly released; and=20 4) as a consequence of rfc2560bis the status of certificate serial = number indicated as revoked with reason code certificateHold can be = replaced with real status of a new real certificate which was issued = with the same certificate serial number as was asked in the incorrect = OCSP request created by insufficiently implemented applications where = the signature of the certificate was not checked with CA public key. =20 It is based on the following definitions: =20 According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/=20 =20 - good =E2=80=A6 is not revoked, (does not necessarily mean that the = certificate was ever issued)=E2=80=A6 - revoked =E2=80=A6 has been revoked (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.) - unknown =E2=80=A6 =20 When a responder responds revoked to a status request for a non- issued certificate, the responder MUST also; =20 - 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.=20 =20 =20 According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code = extension: http://www.itu.int/rec/T-REC-X.509 A certificate may be placed on hold by issuing a CRL entry with a reason = code of certificateHold. The certificate hold notice may include an = optional hold instruction code to convey additional information to = certificate users (see 8.5.2.3).=20 Once a hold has been issued, it may be handled in one of three ways:=20 a) it may remain on the CRL with no further action, causing users to = reject transactions issued during the hold period; or,=20 b) it may be replaced by a (final) revocation for the same certificate, = in which case the reason shall be one of the standard reasons for = revocation, the revocation date shall be the date the certificate was = placed on hold, and the optional instruction code extension field shall = not appear; or,=20 c) it may be explicitly released and the entry removed from the CRL. =20 =20 =20 -----Original Message----- From: Piyush Jain [mailto:piyush@ditenity.com]=20 Sent: Wednesday, January 09, 2013 6:17 PM To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' Subject: RE: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8 =20 =20 =20 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined = in > section 4.4.8 of ocsp draft 8 > Importance: High >=20 > Peter; >=20 > On 1/8/13 5:18 PM, "Peter Rybar" wrote: >=20 > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. >=20 > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The = certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are = signed fraudulently. RPs won't make queries for certificate for which they = cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently = issued certificates unless you are saying that this specification will allow = for RPs to skip signature checking. >=20 > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. >=20 > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? >=20 > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already = used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. >=20 > No that is a task for another possible effort. > It's not part of this update. =20 [Piyush] Can you clarify what is the goal for this update? I think it is = one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. =20 But based on different threads on this topic I get confused about what = it is. Having the goal clear would help us keep the review of draft = focused.=20 =20 >=20 > But this update paves the way for such extension. Which I'm not = against. > It's just not part of this update effort. =20 >=20 > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status = the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records = in > >OCSP database will be use: > > -- unknown >=20 >=20 > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect = (to > indicate that a certificate with this serial number should not be trusted). >=20 > It's important that this works with legacy clients. They will be = around for a > while. >=20 [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting = "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". =20 > /Stefan >=20 > > > > > >_______________________________________________ > >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 _______________________________________________ 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 ------=_NextPart_000_0021_01CDF338.3D560C60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Stefan,

Probably you = have missed my argument that CRLReason of certificateHold is defined only in ITU-T = X.509 and logical semantics specified for CRL and delta CRL when certificateHold is used = is problematic for the usage in OCSP where request/response can be created = several times in unspecified time/date.

 = 

The usage of certificateHold as you have =
proposed is confusing and for that reason I was proposing another =
solution where is addressed the problem of issued certificate by CA =
without evidence in CA. 
Because the sentence "revoked response for non-issued certificates" is =
vague when it is only about wrong =
serial number and the certificate does not exists at application =
creating OCSP request.
It is absurd situations and OCSP responder =
must react with =
an error message =
on such absurd request because that is not situation abut the =
certificate status, that is wrong request which is only about the =
integer number.
OCSP is Online Certificate Status =
Protocol.
It is not partial status about one or two =
component of the CertID! ( serialNumber or issuerNameHash or =
issuerKeyHash )
 
<=
font
size=3D2 color=3Dnavy face=3DArial>When OCSP has access to the CA database, =
what is the case defined in rfc2560bis for "revoked response for non-issued =
certificates", then the error message is right =
response, 
because such certificate does not exist =
and 
because the certificate does not exist =
also the status does not exist about the certificate which does not =
exist.
 
<=
font
size=3D2 face=3D"Courier New">According to rfc2560bis the certificate =
status value is:

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/<= /font>

The "revoked" state indicates that =
the certificate has been =
revoked
=C2=A0=C2=A0 (either permanently or =
temporarily (on hold)). This state MAY also =
be
=C2=A0=C2=A0 returned if the responder knows =
that the requested certificate has
=C2=A0=C2=A0 never been issued during the =
history of the associated CA using =
any
=C2=A0=C2=A0 current or previous issuing =
key.

 =

Another argument = why revocation with reason code certificateHold is problematic: =

ISO/IEC = 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)

8.5.2.2 Reason = code extension

Once a hold has = been issued, it may be handled in one of three ways: =

b) it may be = replaced by a (final) revocation for the same certificate, in which case the reason = shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold , and the optional instruction code extension field shall = not appear; or,,

 =

According to = =E2=80=9Cthe revocation date shall = be the date the certificate was placed on hold=E2=80=9D and according to usage of = OCSP:

The firs OCSP = request will be in time t0 when certificate SerNum1 is not = issued.

You propose OCSP = response revoked where:

Extensions: = id-pkix-ocsp-extended-revoke

Revocation Reasons: = certificateHold

Revocation Time: = 1.1.1970 00:00:00 UTC

 =

Then certificate = will be issued in time t1 and revoked in time t2 in = CRL.

 =

OCSP request = will be created in time t3 and according to definition = =E2=80=9Cthe revocation date shall be the date the certificate was placed on hold=E2=80=9D the revocation time will be =E2=80=A6 what a = problem is because two interpretations exist.

Is OCSP based on = CRL or not=E2=80=A6

When is not = based on CRL as is stated in rfc2560bis for revoked = then the revocation time must be = 1.1.1970 00:00:00 UTC

I hope it is = ridiculous :)

 =

For that reason = I propose to use in this situation OCSP responder error message = malformedRequest.

 =

For example for = clause 7.4 Repudiation of a digital signing (ISO/IEC 9594-8:2008 (E) ITU-T Rec. = X.509 (11/2008)) is extremely problematic when certificateHold is used because transactions created in = each time when the certificate was in certificateHold must not be = accepted.

Also for that = reason the certificateHold is forbidden in some systems or = legislations.

It creates = additional complexity where each CRL must be analyzed to have the complete time = line in which date/time and how long the certificate was in the certificateHold = state because the certificate can be in certificateHold state several = times.

 =

 =

Martin Rex = propose to use OCSP responder error message noIssueRecordFound (7) instead of

OCSPResponseStatus ::=3D ENUMERATED { ?

=C2=A0=C2=A0=C2=A0 probablyCADatabaseOrCAKeyCompromise (7) }

 

I agree, it is = better and new OCSP RFC will define what will be done by the OCSP client when OCSP responder error message = malformedRequest is received.

OCSP client application will create a new OCSP request for the certificate where this = certificate will be included in the singleRequestExtensions the extension identified by = OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound .

 =

According to it = OCSP responder or CA will be able to solve the problems with = probably CA Database inconsistency or CA Key compromise and also the problem how = the OCSP must be able to response on certificate serial number = that don't match any issued = cert.

Because = following response, when CA key was used, can be the real status of the = certificate or OCSP responder error = message tryLater because the analysis was = started.

When CA key was not used for signing the certificate in = request the OCSP responder = will return error message unauthorized = because OCSP is not authorized.

 

Peter = Rybar

 =

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Tuesday, January = 15, 2013 5:29 AM
To: Peter Rybar; = 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for = legacy clients

 

Peter,

 

In = general.

For several = reasons I'm not supportive of your proposals.

 

The basic = problem is that you don't listen to the problem statement being repeated here time = after time after time.

We are NOT = trying to solve CA compromise. We are giving the protocol the capability to = reasonably respond to requests for serial numbers that don't match any issued = cert.

 

That may or = may not be caused by CA compromise.

 

If you want = to craft a perfect solution for handling CA compromise, fine. But that is not part = of this update effort.

/Stefan

 

 

From: Peter Rybar = <rybar@nbusr.sk>
Date: Monday, January 14, = 2013 4:20 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, 'Piyush = Jain' <piyush@ditenity.com>, 'pkix' = <pkix@ietf.org>
Subject: [pkix] Solution = with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for = legacy clients

 

Stefan,

 > = A good protocol should provide a = reasonable response to every possible request.

 

I agree with = such general sentence but rfc2560bis-08 is not able to fix discussed situations. =

Good view was = done by Piyush Jain [piyush@ditenity.com] = in

[pkix] = Addressing issues in 4.2.2.2 of rfc2560bis-08

 

Let me propose = another solution.

We are trying to = fix the situation, where the CA key was used for signing certificate but CA is = not able to provide evidence about it for OCSP = service.

1. It could be = after disaster recovery procedure where the record was lost because it was not archived.

2. Or when the = CA key was compromised and was used for signing a fake = certificate.

 

I do not think = that proposed solution =E2=80=9Cto provide revoked status with a reason code certificateHold and extensions id-pkix-ocsp-extended-revoke=E2=80=9D by OCSP to RP is helpful, because:

1. CA will not = be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and =

2. OCSP service = will not be able to decide if it is a potential CA compromise or only bad OCSP = client is creating fake request because only according to analyzing the = certificate content true result can be produces. Because according to rfc2560bis-08 = the certificate is only on the client side.

3. Solution is = expensive and not useful because the signing of such revocation response will only consume system key resources for creating unclear response. =

 

At first, I = propose to define a new type of the OCSP Responder error = message:

OCSPResponseStatu= s ::=3D ENUMERATED { =E2=80=A6

   = ;probablyCADatabaseOrCAKeyCompromise = (7)

}

 

Or when solution = is important to be understood by legacy clients = then what is defined for probablyCADatabaseOrCAKeyCompromise= will be applicable also for malformedRequest OCSP Responder error message: =

The RFC must = define rules for RP OCSP client applications where the client will be able to repeat = the OCSP request but together with the certificate for which OCSP responder error message is = probablyCADatabaseOrCAKeyCompromise= or malformedRequest.

 

This certificate = will be included in singleRequestExtensions where the extension will be = identified with OBJECT IDENTIFIER

id-pkix-ocsp-<= span style=3D'font-weight:bold'>CertOfProbablyCADatabaseOrCAKeyCompromise.

 

OCSP responder = will analyze received certificate and in situations where CA key was used the certificate will be provided to the CA for analysis and making = decisions.

 

The OCSP = analysis will be the bases for the second OCSP response status = like:

 1. Signed = good, revoked if the certificate was missed only according to recovery = procedure;

 2. = Unsigned with OCSP Responder error message malformedRequest when the CertID = (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to the form for which = OCSP responder is able to provide the status. =

  For = example incorrect hash length in issuerNameHash or issuerKeyHash; =

  Incorrect = serial number like when CA is using sequential number and in request is present = the serial number which is out of the maximum range or is used = unsigned/signed integer as a hash value = stored in certificate serial number=E2=80=A6 e.g. MD5 causes permanently problems = with negative serial numbers where some CA and client try to change the negative = integer of certificate serial number internally and are using such positive integer = in OCSP request what causes problems.

3. Unsigned with = OCSP Responder error message unauthorized when OCSP responder is not = authorized for providing status for requested issuerNameHash, = issuerKeyHash;

4. Unsigned with = OCSP Responder error message tryLater when certificate was signed with CA key and CA must define decision what to = do with it.

=E2=80=A6

 

I hope this = proposal can be helpful as a starting point.

 

Peter = Rybar
National = Security Authority
Information Security and Electronic Signature = Department

 

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, January 11, = 2013 4:05 PM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

 

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: Friday, January 11, = 2013 3:38 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, 'Piyush = Jain' <piyush@ditenity.com>, 'pkix' = <pkix@ietf.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Stefan,
As you can see in my previous mail, when OCSP request =
contains incorrect (malformed) serial number, because the certificate =
does not exist, the OCSP Responder may return an error message =
malformedRequest or all other types of responses =
except for =
revoked!!!

 

How does a = serial number become malformed just because it doesn't exists. Its just an = integer.

Its = syntactically a well formed integer.

 

According to rfc2560bis is =
situation worse because the status revoked which was about the real =
certificate status (in CRL or in previous OCSP RFC) is now with =
extension of revoked with reason code =
certificateHold defined as equivocal result when is not correctly =
implemented. =

It means according to rfc2560bis all serial numbers are =
initially revoked with reason code =
certificateHold=E2=80=A6 Is it =
useful?

 

Yes.

 

(The revoked with reason code =
certificateHold is based on CA database and in some next steps database =
can also include the hash values of certificates for positive =
statement!)
=
 
For that reason some systems and legislations where =
non-repudiation services are required (e.g. QES) dictate that status =
value good or revoked in OCSP response MUST =
contain a positive statement a hash value of certificate in =
singleExtensions.
 

 

Then that can = be achieved by defining a new single response extension that does not = interfere with what is being done in 2560bis.

 

When hash of the certificate as a =
positive statement MUST be used, the situations with OCSP responses for =
RP are clear and unique =
because:
1) good or =
revoked is only about know and =
issued certificates,

 

Great, so how = then do you respond to a request for a serial number that has never been = issued?

 

2) any other situations are moved =
into one group which is unclear and not analyzed =E2=80=93 no evidence, =
no =
responsibility.
<= /div>

 

But the = responder still need to respond.

 

 
It is a radical =
simplification!
<= /div>

 

Of = what?

 

 
Instead of trying to solve presently not practical and =
theoretical situations from the responsibility/liability point of view =
(like preparing us for situations: what we will offer for intergalactic =
green man, are vegetarian? ;) we can define steps which can be =
implemented by CAs and OCSP systems like usage of positive statement =
cert =
hash.
 

 

Asking for = status of a never issued serial number is not impossible. It is not even = hard.

A good = protocol should provide a reasonable response to every possible = request.

 

E.g. define new or reuse already =
defined in private OID =
space.
PositiveStatement ::=3D SEQUENCE =
{
   hashAlgorithm    =
AlgorithmIdentifier,
   =
certHash         OCTET STRING, =
-- Hash of Subjects =
certificate
=
}
 
And according it we cam =
move.

 

I have = nothing against such extension being defined.

But it still = does not remove the need for the current discussed = mechanism.

 

The current = discussed mechanism address how to respond to legacy clients to requests for = non-issued serial numbers.

Your = extension does not help, because it is not understood by legacy = clients.

 

So its not = either or.

 

/Stefan<= /u1:p>

 

 
Peter =
Rybar=

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Thursday, January = 10, 2013 2:19 PM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Peter, i = think the reason for this has been thoroughly = debated.

 

It is correct = that a cert serial number that was on hold, may be = released.

The requested = cert serial number may actually be used in a future representing a real = certificate.

So this is = intentional and the whole purpose behind using the on hold = reason.

 

/Stefan<= /u3:p>

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: Thursday, January = 10, 2013 12:13 PM
To: 'Piyush Jain' <piyush@ditenity.com>, Stefan = Santesson <stefan@aaa-sec.com>, = 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] = Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Stefan,

For me is unclear = how this extension of revoked with = reason code certificateHold is = useful.

It define that now = is possible to revoke what does not exist and it open never ending cycle of trying = to fixing or correcting the first incorrect status that "fake" = cert serial number is revoked but cert serial number is not revoked because = "fake" cert does not = exist.

 

I agree that = extension of revoked can be helpful = like:

= 
   The =
"revoked" state indicates that the certificate has been =
revoked
   (either permanently or temporarily (on hold)). =
Response =
extensions
   may be used to convey additional information =
on assertions made =
by
<=
pre>   the responder regarding the status of the =
certificate such =
as
<= pre>   positive statement about issuance, validity, = etc.

 

 

When the certificate = serial number is not in the OCSP database/CRL then according to rfc2560bis = there are defined following possible = responses:

1. signed - =  good (e.g. certificate serial = number is not listed in CRL)

2. signed - =  unknown (e.g. certificate serial = number is not listed in CRL)

3. unsigned = =E2=80=93 unauthorized as an error = message

4. signed - =  revoked where according to = rfc2560bis are defined values = for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC=

 =

What is missing? The = rfc2560bis must also specify values = for:

This Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC=

Next Update:  ?? ?? ??     = 10.1.2013 9:51:15 UTC=

 =

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; = 2) it may be replaced by a (final) revocation; 3) it may be explicitly = released;=

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced = with real status of a new real certificate which was issued with the same = certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the = certificate was not checked with CA public = key.

 

It is based on the = following definitions:

 
According to rfc2560bis the certificate status value =
is:
= 
http:/=
/tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ =
 
   -  good =E2=80=A6 is not revoked, =
(does not necessarily mean that the =
certificate was ever =
issued)=E2=80=A6
   -  revoked =E2=80=A6 has been revoked =
(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.)
   -  unknown =
=E2=80=A6=




 



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




 



 



According to ITU-T =
Rec. X.509
(11/2008), clause 8.5.2.2 Reason code =
extension:



http://www.itu.int/rec/T-REC-=
X.509=




A certificate may be =
placed on
hold by issuing a CRL entry with a reason code of certificateHold. The
certificate hold notice may include an optional hold instruction code to =
convey
additional information to certificate users (see 8.5.2.3). =




Once a hold has been =
issued, it
may be handled in one of three ways: =




a) it may remain on =
the CRL
with no further action, causing users to reject transactions issued =
during the
hold period; or, =




b) it may be =
replaced by a
(final) revocation for the same certificate, in which case the reason =
shall be
one of the standard reasons for revocation, the revocation date shall be =
the
date the certificate was placed on hold, and the optional instruction =
code
extension field shall not appear; or, =




c) it may be =
explicitly
released and the entry removed from the =
CRL.



 



 



 



-----Original =
Message-----

From: Piyush Jain [mailto:piyush@ditenity.com]


Sent: Wednesday, January 09, 2013 6:17 PM

To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'

Subject: RE: [pkix] Question about extended Revoked Extension defined in
section 4.4.8 of ocsp draft =
8



 



 



 



> -----Original =
Message-----



> From: Stefan =
Santesson [mailto:stefan@aaa-sec.com]



> Sent: Tuesday, =
January 08,
2013 8:40 =
PM



> To: =
Peter =
Rybar=
;
'Piyush Jain'; =
'pkix'


> Subject: Re: =
[pkix]
Question about extended Revoked Extension defined =
in



> section 4.4.8 =
of ocsp draft
8



> Importance: =
High



> =




> =
Peter;


> =




> On 1/8/13 5:18 =
PM, "Peter =
Rybar=
"
<rybar@nbusr.sk> =
wrote:


> =




> =
>Stefan,



> >The =
terminology is not
clear for someone who will =
see:



> >The =
revocation is of "non-issued
certificate".



> >Because by =
reading the
text it is expected that the certificate =
was



> >issued, but
fraudulently.



> =




> What part of =
the text
supports =
that?
=



[Piyush] None =
explicitly, but
many would infer it that way. The =
certificate



space that is =
covered by your
interpretation of "non-issued" =
includes<=
/p>


certificates which =
are not
signed using the CA key and those that are =
signed


fraudulently. RPs =
won't make
queries for certificate for which they =
cannot


verify the =
signature. So the
only genuine requests for =
"non-issued=




certificates" =
coming to a
responder would be those for fraudulently =
issued


certificates unless =
you are
saying that this specification will allow =
for



RPs to skip =
signature =
checking.=




> =




> =
>



> >The =
revocation with a
new extension is only about fraudulently =
issued


> =
>certificate. It means
this new extension and revocation is not =
used



> >when the =
certificate
is not issued and only fake random =
certificate



> >serial =
number was
created in OCSP =
request.<=
/p>


> =




> =
What?
=



> How in this =
physical
universe would the OCSP responder tell =
the



> =
difference???



> Crystal =
ball?
=



> =




> =
>



> >While it is =
intended
only for fraudulently issued certificate =
where
=



> =
>fraudulently issued
certificate can potentially reuse any already =
used



> =
>certificate-serial-number
the extension must contain e.g. a =
positive<=
/p>


> =
>confirmation of
existence in the form of hash value of =
fraudulently



> >issued =
certificate.



> =




> No that is a =
task for
another possible =
effort.


> It's not part =
of this
update.


 



[Piyush] Can you =
clarify what
is the goal for this update? I think it is =
one



of the =
following=




- Allow for =
extending
definition of revoked so other specifications =
can



extend the =
protocol<=
/p>


- Address handling =
of
fraudulently issued =
certificate.



- Address handling =
of any
certificate not issued by the =
CA.



 



But based on =
different threads
on this topic I get confused about what =
it



is. Having the goal =
clear would
help us keep the review of draft focused. =




 



> =




> But this update =
paves the
way for such extension. Which I'm not =
against.<=
/p>


> It's just not =
part of this
update =
effort.


 



> =




> =
>



> >Only =
according to the
hash value of fraudulently issued =
certificate



> >relaying =
party and
OCSP responder is able to identify =
fraudulently



> >issued =
certificate
because CA was compromised and serial numbers =
of



> =
>certificates are not
any longer unique for compromised =
CA.



> =
>



> =
>Conclusion:<=
/font>



> >Positive =
statement
extension as a hash value of the certificate =
whose
=



> >status OCSP =
response
is providing can be used in this =
case:
=



> >  when =
the
certificate is =
revoked,<=
/p>


> >  when =
the
certificate is good and =
also



> >  when =
the
certificate is fraudulently =
issued.


> =
>



> >For that =
reason it can
be more helpful to define in RFC one =
positive<=
/p>


> >statement =
extension as
a hash value of the certificate whose status =
the



> >OCSP =
response is
providing and define in RFC that it will =
support


> >situations =
when status
is:



> =
>   -- =
good



> =
>   -- =
revoked


> >And for =
randomly
created certificate serial numbers without records =
in



> >OCSP =
database will be
use:



> =
>   -- =
unknown


> =




> =




> No, we have =
been through
this and determined WG =
consensus.



> Unknown is not =
the choice,
since it may not have the desired effect =
(to



> indicate that a
certificate with this serial number should not =
be



trusted).



> =




> It's important =
that this
works with legacy clients. They will be =
around


for =
a



> =
while.


> =




[Piyush] That's an =
interesting
usage of the word "legacy". I don't =
think
=



that any of the =
previous
versions of OCSP recommended interpreting =
"unknown"



or =
UNAUTHORIZED(unsigned)
responses to imply that certificate can =
be



trusted. The right =
word would
be to "incorrectly implemented =
clients".



 



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

_______________________________________________ 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

------=_NextPart_000_0021_01CDF338.3D560C60-- From denis.pinkas@bull.net Tue Jan 15 07:42:29 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 7489521F8800 for ; Tue, 15 Jan 2013 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=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 Sdr8bAEhyx7S for ; Tue, 15 Jan 2013 07:42:20 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1864F21F87D9 for ; Tue, 15 Jan 2013 07:42:19 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 7402E1CFE6; Tue, 15 Jan 2013 16:42:18 +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 2013011516421776-19074 ; Tue, 15 Jan 2013 16:42:17 +0100 Message-ID: <50F578D6.50608@bull.net> Date: Tue, 15 Jan 2013 16:42:14 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Rybar References: <201301151451.r0FEpiRU082504@mail.nbusr.sk> In-Reply-To: <201301151451.r0FEpiRU082504@mail.nbusr.sk> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 15/01/2013 16:42:17, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 15/01/2013 16:42:18, Serialize complete at 15/01/2013 16:42:18 Content-Type: multipart/alternative; boundary="------------080704020707020306000907" Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 15:42:29 -0000 This is a multi-part message in MIME format. --------------080704020707020306000907 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Peter, I agree with you one point, but I disagree with you on two others: The agreement : CertificateHold should not be used to address the problem we want to solve The disagreements : a) the error message malformedRequest is not the right approach, since the request is well-formed. b) the error message unauthorized is not the right approach, since the request is unauthorized. Please read the message I sent to Stefan at 2:58 p.m. today for a proposal to address the problem. Denis > Stefan, > > Probably you have missed my argument that CRLReason of certificateHold > is defined only in ITU-T X.509 and logical semantics specified for CRL > and delta CRL when certificateHold is used is problematic for the > usage in OCSP where request/response can be created several times in > unspecified time/date. > > The usage of certificateHold as you have proposed is confusing and for that reason I was proposing another solution where is addressed the problem of issued certificate by CA without evidence in CA. > Because the sentence"revoked response for non-issued certificates" is vaguewhen it is only about wrong serial number and the certificate does not exists at application creating OCSP request. > It is absurd situations and OCSP responder*must react* with*an error message* on such absurd request because that is not situation abut the certificate status, that is wrong request which is only about the integer number. > OCSP is Online Certificate Status Protocol. > It is not partial status about one or two component of the CertID! ( serialNumber or issuerNameHash or issuerKeyHash ) > > When OCSP has access to the CA database, what is the case defined in rfc2560bis for"revoked response for non-issued certificates", then the error message is right response, > because such certificate does not exist and > because the certificate does not exist also the status does not exist about the certificate which does not exist. > > According to rfc2560bis the certificate status value is: > > http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ > > 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*. > > Another argument why revocation with reason code certificateHoldis > problematic: > > ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) > > 8.5.2.2 Reason code extension > > Once a hold has been issued, it may be handled in one of three ways: > > b) it may be replaced by a (final) revocation for the same > certificate, in which case the reason shall be one of the standard > reasons for revocation, *the revocation date shall be the date the > certificate was placed on hold *, and the optional instruction code > extension field shall not appear; or,, > > According to "*the revocation date shall be the date the certificate > was placed on hold*" and according to usage of OCSP: > > The firs OCSP request will be in time t0 when certificate SerNum1 is > not issued. > > You propose OCSP response *revoked*where: > > Extensions: id-pkix-ocsp-extended-revoke > > Revocation Reasons: certificateHold > > Revocation Time: 1.1.1970 00:00:00 UTC > > Then certificate will be issued in time t1 and revoked in time t2 in CRL. > > OCSP request will be created in time t3 and according to definition > "*the revocation date shall be the date the certificate was placed on > hold*" the revocation time will be ... what a problem is because two > interpretations exist. > > Is OCSP based on CRL or not... > > When is not based on CRL as is stated in rfc2560bis for revoked then > the revocation time must be 1.1.1970 00:00:00 UTC > > I hope it is ridiculous :) > > For that reason I propose to use in this situation OCSP responder > error message *malformedRequest*. > > For example for clause 7.4 Repudiation of a digital signing (ISO/IEC > 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic > when certificateHoldis used because transactions created in each time > when the certificate was in certificateHold must not be accepted. > > Also for that reason the certificateHold is forbidden in some systems > or legislations. > > It creates additional complexity where each CRL must be analyzed to > have the complete time line in which date/time and how long the > certificate was in the certificateHold state because the certificate > can be in certificateHold state several times. > > Martin Rex propose to use OCSP responder error message > noIssueRecordFound (7) instead of > > OCSPResponseStatus ::= ENUMERATED { ? > > probablyCADatabaseOrCAKeyCompromise (7) } > > I agree, it is better and new OCSP RFC will define what will be done > by the OCSP client when OCSP responder error message > *malformedRequest* is received. > > OCSP client application will create a new OCSP request for the > certificate where this certificate will be included in the > singleRequestExtensions the extension identified by OBJECT IDENTIFIER > id-pkix-ocsp-*CertOf**NoIssueRecordFound*. > > According to it OCSP responder or CA will be able to solve the > problems with probably CA Database inconsistency or CA Key compromise > and also the problem how the OCSP must be able to response on > certificate serial number that don't match any issued cert. > > Because following response, when CA key was used, can be the real > status of the certificate or OCSP responder error messagetryLater > because the analysis was started. > > When CA key was not used for signing the certificate in request the > OCSP responder will return error message *unauthorized*because OCSP is > not authorized. > > Peter Rybar > > ------------------------------------------------------------------------ > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Tuesday, January 15, 2013 5:29 AM > *To:* Peter Rybar; 'Piyush Jain'; 'pkix' > *Subject:* Re: [pkix] Solution with singleRequestExtensions > CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > > Peter, > > In general. > > For several reasons I'm not supportive of your proposals. > > The basic problem is that you don't listen to the problem statement > being repeated here time after time after time. > > We are NOT trying to solve CA compromise. We are giving the protocol > the capability to reasonably respond to requests for serial numbers > that don't match any issued cert. > > That may or may not be caused by CA compromise. > > If you want to craft a perfect solution for handling CA compromise, > fine. But that is not part of this update effort. > > /Stefan > > *From: *Peter Rybar> > *Date: *Monday, January 14, 2013 4:20 PM > *To: *Stefan Santesson >, 'Piyush Jain' >, 'pkix' > > *Subject: *[pkix] Solution with singleRequestExtensions > CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > > Stefan, > > > A good protocol should provide a reasonable response to every > possible request. > > I agree with such general sentence but rfc2560bis-08 is not able > to fix discussed situations. > > Good view was done by Piyush Jain [piyush@ditenity.com > ] in > > [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 > > Let me propose another solution. > > We are trying to fix the situation, where the CA key was used for > signing certificate but CA is not able to provide evidence about > it for OCSP service. > > 1. It could be after disaster recovery procedure where the record > was lost because it was not archived. > > 2. Or when the CA key was compromised and was used for signing a > fake certificate. > > I do not think that proposed solution "to provide *revoked* status > with a reason code *certificateHold* and extensions > id-pkix-ocsp-*extended-revoke*" by OCSP to RP is helpful, because: > > 1. CA will not be informed about the potential inconsistency in > the CA database or about potential critical attack (DigiNotar); and > > 2. OCSP service will not be able to decide if it is a potential CA > compromise or only bad OCSP client is creating fake request > because only according to analyzing the certificate content true > result can be produces. Because according to rfc2560bis-08 the > certificate is only on the client side. > > 3. Solution is expensive and not useful because the signing of > such revocation response will only consume system key resources > for creating unclear response. > > At first, I propose to define a new type of the OCSP Responder > error message: > > OCSPResponseStatus ::= ENUMERATED { ... > > *probablyCADatabaseOrCAKeyCompromise (7)* > > } > > Or when solution is important to be understood by legacy > clientsthen what is defined for > *probablyCADatabaseOrCAKeyCompromise* will be applicable also for > *malformedRequest* OCSP Responder error message*: * > > The RFC must define rules for RP OCSP client applications where > the client will be able to repeat the OCSP request but together > *with the certificate* for which OCSP responder error message is > *probablyCADatabaseOrCAKeyCompromise* or *malformedRequest*. > > This certificate will be included in singleRequestExtensions where > the extension will be identified with OBJECT IDENTIFIER > > id-pkix-ocsp-*CertOfProbablyCADatabaseOrCAKeyCompromise*. > > OCSP responder will analyze received certificate and in situations > where CA key was used the certificate will be provided to the CA > for analysis and making decisions. > > The OCSP analysis will be the bases for the second OCSP response > status like: > > 1. Signed good, revoked if the certificate was missed only > according to recovery procedure; > > 2. Unsigned with OCSP Responder error message malformedRequest > when the CertID (issuerNameHash, issuerKeyHash, serialNumber) is > not corresponding to the form for which OCSP responder is able to > provide the status. > > For example incorrect hash length in issuerNameHash or > issuerKeyHash; > > Incorrect serial number like when CA is using sequential number > and in request is present the serial number which is out of the > maximum range or is used unsigned/*signed integer as a* hash value > stored in certificate serial number... e.g. MD5 causes permanently > problems with negative serial numbers where some CA and client try > to change the negative integer of certificate serial number > internally and are using such positive integer in OCSP request > what causes problems. > > 3. Unsigned with OCSP Responder error message unauthorized when > OCSP responder is not authorized for providing status for > requested issuerNameHash, issuerKeyHash; > > 4. Unsigned with OCSP Responder error messagetryLater when > certificate was signed with CA key and CA must define decision > what to do with it. > > ... > > I hope this proposal can be helpful as a starting point. > > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > > ------------------------------------------------------------------------ > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Friday, January 11, 2013 4:05 PM > *To:* Peter Rybar; 'Piyush Jain'; 'pkix' > *Subject:* Re: [pkix] Question about extended Revoked Extension > defined in section 4.4.8 of ocsp draft 8 > > *From: *Peter Rybar> > *Date: *Friday, January 11, 2013 3:38 PM > *To: *Stefan Santesson >, 'Piyush Jain' >, 'pkix' > > *Subject: *Re: [pkix] Question about extended Revoked Extension > defined in section 4.4.8 of ocsp draft 8 > > Stefan, > > As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or*all* other types of responses*except for revoked*!!! > > How does a serial number become malformed just because it doesn't > exists. Its just an integer. > > Its syntactically a well formed integer. > > According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of*revoked* with reason code certificateHold defined as equivocal result when is not correctly implemented. > > It means according to rfc2560bis all serial numbers are initially*revoked* with reason code certificateHold... Is it useful? > > Yes. > > (The*revoked* with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!) > > > > For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value*good*or* revoked* in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions. > > > > Then that can be achieved by defining a new single response > extension that does not interfere with what is being done in 2560bis. > > When hash of the certificate as a positive statement MUST be used, the situations with OCSP responses for RP are clear and unique because: > > 1)*good* or*revoked* is only about know and issued certificates, > > Great, so how then do you respond to a request for a serial number > that has never been issued? > > 2)*any* other situations are moved into one group which is unclear and not analyzed -- no evidence, no responsibility. > > But the responder still need to respond. > > > > It is a radical simplification! > > Of what? > > > > Instead of trying to solve presently not practical and theoretical situations from the responsibility/liability point of view (like preparing us for situations: what we will offer for intergalactic green man, are vegetarian? ;) we can define steps which can be implemented by CAs and OCSP systems like usage of positive statement cert hash. > > > > Asking for status of a never issued serial number is not > impossible. It is not even hard. > > A good protocol should provide a reasonable response to every > possible request. > > E.g. define new or reuse already defined in private OID space. > > PositiveStatement ::= SEQUENCE { > > hashAlgorithm AlgorithmIdentifier, > > certHash OCTET STRING, -- Hash of Subjects certificate > > } > > > > And according it we cam move. > > I have nothing against such extension being defined. > > But it still does not remove the need for the current discussed > mechanism. > > The current discussed mechanism address how to respond to legacy > clients to requests for non-issued serial numbers. > > Your extension does not help, because it is not understood by > legacy clients. > > So its not either or. > > /Stefan > > > > Peter Rybar > > ------------------------------------------------------------------------ > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Thursday, January 10, 2013 2:19 PM > *To:* Peter Rybar; 'Piyush Jain'; 'pkix' > *Subject:* Re: [pkix] Question about extended Revoked > Extension defined in section 4.4.8 of ocsp draft 8 > > Peter, i think the reason for this has been thoroughly debated. > > It is correct that a cert serial number that was on hold, may > be released. > > The requested cert serial number may actually be used in a > future representing a real certificate. > > So this is intentional and the whole purpose behind using the > on hold reason. > > /Stefan > > *From: *Peter Rybar> > *Date: *Thursday, January 10, 2013 12:13 PM > *To: *'Piyush Jain' >, Stefan Santesson > >, 'pkix' > > > *Subject: *Re: [pkix] Question about extended Revoked > Extension defined in section 4.4.8 of ocsp draft 8 > > Stefan, > > For me is unclear how this extension of *revoked* with > reason code certificateHold is useful. > > It define that now is possible to revoke what does not > exist and it open never ending cycle of trying to fixing > or correcting the first incorrect status that "fake" cert > serial number is revoked but cert serial number is not > revoked because "fake" cert does not exist. > > I agree that extension of *revoked* can be helpful like: > > The "revoked" state indicates that the certificate has been revoked > > (either permanently or temporarily (on hold)). Response extensions > > may be used to convey additional information on assertions made by > > the responder regarding the status of the certificate such as > > positive statement about issuance, validity, etc. > > When the certificate serial number is not in the OCSP > database/CRL then according to rfc2560bis there are > defined following possible responses: > > 1. signed - *good (e.g. *certificate serial number is not > listed in CRL*)* > > 2. signed - *unknown (e.g. *certificate serial number is > not listed in CRL*)* > > 3. unsigned -- unauthorized as an error message > > 4. signed - *revoked* where according to rfc2560bis are > defined values for: > > Extensions: id-pkix-ocsp-extended-revoke > > Revocation Reasons: certificateHold > > Revocation Time: 1.1.1970 00:00:00 UTC > > What is missing? The rfc2560bis must also specify values for: > > This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC > > Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC > > X.509 defines the reason code certificateHold as 1) it may > remain on the CRL; 2) it may be replaced by a (final) > revocation; 3) it may be explicitly released; > > and > > 4) as a consequence of rfc2560bis the status of > certificate serial number indicated as revoked with reason > code certificateHold can be replaced with real status of a > new real certificate which was issued with the same > certificate serial number as was asked in the incorrect > OCSP request created by insufficiently implemented > applications where the signature of the certificate was > not checked with CA public key. > > It is based on the following definitions: > > > > According to rfc2560bis the certificate status value is: > > http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ > > > > - good ... is not revoked, (does* not* necessarily mean that the certificate was* ever issued*)... > > - revoked ... has been revoked (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.) > > - unknown ... > > 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. > > According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 > Reason code extension: > > http://www.itu.int/rec/T-REC-X.509 > > A certificate may be placed on hold by issuing a CRL entry > with a reason code of certificateHold. The certificate > hold notice may include an optional hold instruction code > to convey additional information to certificate users (see > 8.5.2.3). > > Once a hold has been issued, it may be handled in one of > three ways: > > a) it may remain on the CRL with no further action, > causing users to reject transactions issued during the > hold period; or, > > b) it may be replaced by a (final) revocation for the same > certificate, in which case the reason shall be one of the > standard reasons for revocation, the revocation date shall > be the date the certificate was placed on hold, and the > optional instruction code extension field shall not > appear; or, > > c) it may be explicitly released and the entry removed > from the CRL. > > -----Original Message----- > From: Piyush Jain [mailto:piyush@ditenity.com] > Sent: Wednesday, January 09, 2013 6:17 PM > To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' > Subject: RE: [pkix] Question about extended Revoked > Extension defined in section 4.4.8 of ocsp draft 8 > > > -----Original Message----- > > > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > > > Sent: Tuesday, January 08, 2013 8:40 PM > > > To:Peter Rybar; 'Piyush Jain'; 'pkix' > > > Subject: Re: [pkix] Question about extended Revoked Extension > defined in > > > section 4.4.8 of ocsp draft 8 > > > Importance: High > > > > > > Peter; > > > > > > On 1/8/13 5:18 PM, "Peter Rybar" > wrote: > > > > > > >Stefan, > > > >The terminology is not clear for someone who will see: > > > >The revocation is of "non-issued certificate". > > > >Because by reading the text it is expected that the > certificate was > > > >issued, but fraudulently. > > > > > > What part of the text supports that? > > [Piyush] None explicitly, but many would infer it that > way. The certificate > > space that is covered by your interpretation of > "non-issued" includes > > certificates which are not signed using the CA key and > those that are signed > > fraudulently. RPs won't make queries for certificate for > which they cannot > > verify the signature. So the only genuine requests for > "non-issued > > certificates" coming to a responder would be those for > fraudulently issued > > certificates unless you are saying that this specification > will allow for > > RPs to skip signature checking. > > > > > > > > > > >The revocation with a new extension is only about > fraudulently issued > > > >certificate. It means this new extension and revocation > is not used > > > >when the certificate is not issued and only fake random > certificate > > > >serial number was created in OCSP request. > > > > > > What? > > > How in this physical universe would the OCSP responder tell the > > > difference??? > > > Crystal ball? > > > > > > > > > > >While it is intended only for fraudulently issued certificate where > > > >fraudulently issued certificate can potentially reuse > any already used > > > >certificate-serial-number the extension must contain > e.g. a positive > > > >confirmation of existence in the form of hash value of > fraudulently > > > >issued certificate. > > > > > > No that is a task for another possible effort. > > > It's not part of this update. > > [Piyush] Can you clarify what is the goal for this update? > I think it is one > > of the following > > - Allow for extending definition of revoked so other > specifications can > > extend the protocol > > - Address handling of fraudulently issued certificate. > > - Address handling of any certificate not issued by the CA. > > But based on different threads on this topic I get > confused about what it > > is. Having the goal clear would help us keep the review of > draft focused. > > > > > > But this update paves the way for such extension. Which I'm not > against. > > > It's just not part of this update effort. > > > > > > > > > > >Only according to the hash value of fraudulently issued > certificate > > > >relaying party and OCSP responder is able to identify > fraudulently > > > >issued certificate because CA was compromised and serial numbers of > > > >certificates are not any longer unique for compromised CA. > > > > > > > >Conclusion: > > > >Positive statement extension as a hash value of the > certificate whose > > > >status OCSP response is providing can be used in this case: > > > > when the certificate is revoked, > > > > when the certificate is good and also > > > > when the certificate is fraudulently issued. > > > > > > > >For that reason it can be more helpful to define in RFC one > positive > > > >statement extension as a hash value of the certificate > whose status the > > > >OCSP response is providing and define in RFC that it will support > > > >situations when status is: > > > > -- good > > > > -- revoked > > > >And for randomly created certificate serial numbers without > records in > > > >OCSP database will be use: > > > > -- unknown > > > > > > > > > No, we have been through this and determined WG consensus. > > > Unknown is not the choice, since it may not have the desired effect (to > > > indicate that a certificate with this serial number should not be > > trusted). > > > > > > It's important that this works with legacy clients. They will > be around > > for a > > > while. > > > > > [Piyush] That's an interesting usage of the word "legacy". > I don't think > > that any of the previous versions of OCSP recommended > interpreting "unknown" > > or UNAUTHORIZED(unsigned) responses to imply that > certificate can be > > trusted. The right word would be to "incorrectly > implemented clients". > > > /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 > > _______________________________________________ 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 --------------080704020707020306000907 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Peter,

I agree with you one point, but I disagree with you on two others:

The agreement : CertificateHold should not be used to address the problem we want to solve

The disagreements :
   a) the error message malformedRequest is not the right approach, since the request is well-formed.
   b) the error message unauthorized is not the right approach, since the request is unauthorized.

Please read the message I sent to Stefan at 2:58 p.m. today for a proposal to address the problem.

Denis


Stefan,

Probably you have missed my argument that CRLReason of certificateHold is defined only in ITU-T X.509 and logical semantics specified for CRL and delta CRL when certificateHold is used is problematic for the usage in OCSP where request/response can be created several times in unspecified time/date.

 

The usage of certificateHold as you have proposed is confusing and for that reason I was proposing another solution where is addressed the problem of issued certificate by CA without evidence in CA. 
Because the sentence "revoked response for non-issued certificates" is vague when it is only about wrong serial number and the certificate does not exists at application creating OCSP request.
It is absurd situations and OCSP responder must react with an error message on such absurd request because that is not situation abut the certificate status, that is wrong request which is only about the integer number.
OCSP is Online Certificate Status Protocol.
It is not partial status about one or two component of the CertID! ( serialNumber or issuerNameHash or issuerKeyHash )
 
When OCSP has access to the CA database, what is the case defined in rfc2560bis for "revoked response for non-issued certificates", then the error message is right response, 
because such certificate does not exist and 
because the certificate does not exist also the status does not exist about the certificate which does not exist.
 
According to rfc2560bis the certificate status value is:

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/

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.

 

Another argument why revocation with reason code certificateHold is problematic:

ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)

8.5.2.2 Reason code extension

Once a hold has been issued, it may be handled in one of three ways:

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold , and the optional instruction code extension field shall not appear; or,,

 

According to “the revocation date shall be the date the certificate was placed on hold” and according to usage of OCSP:

The firs OCSP request will be in time t0 when certificate SerNum1 is not issued.

You propose OCSP response revoked where:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

 

Then certificate will be issued in time t1 and revoked in time t2 in CRL.

 

OCSP request will be created in time t3 and according to definition “the revocation date shall be the date the certificate was placed on hold” the revocation time will be … what a problem is because two interpretations exist.

Is OCSP based on CRL or not…

When is not based on CRL as is stated in rfc2560bis for revoked then the revocation time must be 1.1.1970 00:00:00 UTC

I hope it is ridiculous :)

 

For that reason I propose to use in this situation OCSP responder error message malformedRequest.

 

For example for clause 7.4 Repudiation of a digital signing (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic when certificateHold is used because transactions created in each time when the certificate was in certificateHold must not be accepted.

Also for that reason the certificateHold is forbidden in some systems or legislations.

It creates additional complexity where each CRL must be analyzed to have the complete time line in which date/time and how long the certificate was in the certificateHold state because the certificate can be in certificateHold state several times.

 

 

Martin Rex propose to use OCSP responder error message noIssueRecordFound (7) instead of

OCSPResponseStatus ::= ENUMERATED { ?

    probablyCADatabaseOrCAKeyCompromise (7) }

 

I agree, it is better and new OCSP RFC will define what will be done by the OCSP client when OCSP responder error message malformedRequest is received.

OCSP client application will create a new OCSP request for the certificate where this certificate will be included in the singleRequestExtensions the extension identified by OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound .

 

According to it OCSP responder or CA will be able to solve the problems with probably CA Database inconsistency or CA Key compromise and also the problem how the OCSP must be able to response on certificate serial number that don't match any issued cert.

Because following response, when CA key was used, can be the real status of the certificate or OCSP responder error message tryLater because the analysis was started.

When CA key was not used for signing the certificate in request the OCSP responder will return error message unauthorized because OCSP is not authorized.

 

Peter Rybar

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Tuesday, January 15, 2013 5:29 AM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

 

Peter,

 

In general.

For several reasons I'm not supportive of your proposals.

 

The basic problem is that you don't listen to the problem statement being repeated here time after time after time.

We are NOT trying to solve CA compromise. We are giving the protocol the capability to reasonably respond to requests for serial numbers that don't match any issued cert.

 

That may or may not be caused by CA compromise.

 

If you want to craft a perfect solution for handling CA compromise, fine. But that is not part of this update effort.

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Monday, January 14, 2013 4:20 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Piyush Jain' <piyush@ditenity.com>, 'pkix' <pkix@ietf.org>
Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

 

Stefan,

 > A good protocol should provide a reasonable response to every possible request.

 

I agree with such general sentence but rfc2560bis-08 is not able to fix discussed situations.

Good view was done by Piyush Jain [piyush@ditenity.com] in

[pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08

 

Let me propose another solution.

We are trying to fix the situation, where the CA key was used for signing certificate but CA is not able to provide evidence about it for OCSP service.

1. It could be after disaster recovery procedure where the record was lost because it was not archived.

2. Or when the CA key was compromised and was used for signing a fake certificate.

 

I do not think that proposed solution “to provide revoked status with a reason code certificateHold and extensions id-pkix-ocsp-extended-revoke” by OCSP to RP is helpful, because:

1. CA will not be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and

2. OCSP service will not be able to decide if it is a potential CA compromise or only bad OCSP client is creating fake request because only according to analyzing the certificate content true result can be produces. Because according to rfc2560bis-08 the certificate is only on the client side.

3. Solution is expensive and not useful because the signing of such revocation response will only consume system key resources for creating unclear response.

 

At first, I propose to define a new type of the OCSP Responder error message:

OCSPResponseStatus ::= ENUMERATED { …

   probablyCADatabaseOrCAKeyCompromise (7)

}

 

Or when solution is important to be understood by legacy clients then what is defined for probablyCADatabaseOrCAKeyCompromise will be applicable also for malformedRequest OCSP Responder error message:

The RFC must define rules for RP OCSP client applications where the client will be able to repeat the OCSP request but together with the certificate for which OCSP responder error message is probablyCADatabaseOrCAKeyCompromise or malformedRequest.

 

This certificate will be included in singleRequestExtensions where the extension will be identified with OBJECT IDENTIFIER

id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise.

 

OCSP responder will analyze received certificate and in situations where CA key was used the certificate will be provided to the CA for analysis and making decisions.

 

The OCSP analysis will be the bases for the second OCSP response status like:

 1. Signed good, revoked if the certificate was missed only according to recovery procedure;

 2. Unsigned with OCSP Responder error message malformedRequest when the CertID (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to the form for which OCSP responder is able to provide the status.

  For example incorrect hash length in issuerNameHash or issuerKeyHash;

  Incorrect serial number like when CA is using sequential number and in request is present the serial number which is out of the maximum range or is used unsigned/signed integer as a hash value stored in certificate serial number… e.g. MD5 causes permanently problems with negative serial numbers where some CA and client try to change the negative integer of certificate serial number internally and are using such positive integer in OCSP request what causes problems.

3. Unsigned with OCSP Responder error message unauthorized when OCSP responder is not authorized for providing status for requested issuerNameHash, issuerKeyHash;

4. Unsigned with OCSP Responder error message tryLater when certificate was signed with CA key and CA must define decision what to do with it.

…

 

I hope this proposal can be helpful as a starting point.

 

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department

 

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, January 11, 2013 4:05 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, January 11, 2013 3:38 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Piyush Jain' <piyush@ditenity.com>, 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Stefan,
As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or all other types of responses except for revoked!!!

 

How does a serial number become malformed just because it doesn't exists. Its just an integer.

Its syntactically a well formed integer.

 

According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of revoked with reason code certificateHold defined as equivocal result when is not correctly implemented. 
It means according to rfc2560bis all serial numbers are initially revoked with reason code certificateHold… Is it useful?

 

Yes.

 

(The revoked with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!)
 
For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value good or revoked in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions.
 

 

Then that can be achieved by defining a new single response extension that does not interfere with what is being done in 2560bis.

 

When hash of the certificate as a positive statement MUST be used, the situations with OCSP responses for RP are clear and unique because:
1) good or revoked is only about know and issued certificates,

 

Great, so how then do you respond to a request for a serial number that has never been issued?

 

2) any other situations are moved into one group which is unclear and not analyzed – no evidence, no responsibility.

 

But the responder still need to respond.

 

 
It is a radical simplification!

 

Of what?

 

 
Instead of trying to solve presently not practical and theoretical situations from the responsibility/liability point of view (like preparing us for situations: what we will offer for intergalactic green man, are vegetarian? ;) we can define steps which can be implemented by CAs and OCSP systems like usage of positive statement cert hash.
 

 

Asking for status of a never issued serial number is not impossible. It is not even hard.

A good protocol should provide a reasonable response to every possible request.

 

E.g. define new or reuse already defined in private OID space.
PositiveStatement ::= SEQUENCE {
   hashAlgorithm    AlgorithmIdentifier,
   certHash         OCTET STRING, -- Hash of Subjects certificate
}
 
And according it we cam move.

 

I have nothing against such extension being defined.

But it still does not remove the need for the current discussed mechanism.

 

The current discussed mechanism address how to respond to legacy clients to requests for non-issued serial numbers.

Your extension does not help, because it is not understood by legacy clients.

 

So its not either or.

 

/Stefan

 

 
Peter Rybar

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Thursday, January 10, 2013 2:19 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Peter, i think the reason for this has been thoroughly debated.

 

It is correct that a cert serial number that was on hold, may be released.

The requested cert serial number may actually be used in a future representing a real certificate.

So this is intentional and the whole purpose behind using the on hold reason.

 

/Stefan

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Thursday, January 10, 2013 12:13 PM
To: 'Piyush Jain' <piyush@ditenity.com>, Stefan Santesson <stefan@aaa-sec.com>, 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

Stefan,

For me is unclear how this extension of revoked with reason code certificateHold is useful.

It define that now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist.

 

I agree that extension of revoked can be helpful like:

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

 

 

When the certificate serial number is not in the OCSP database/CRL then according to rfc2560bis there are defined following possible responses:

1. signed -  good (e.g. certificate serial number is not listed in CRL)

2. signed -  unknown (e.g. certificate serial number is not listed in CRL)

3. unsigned – unauthorized as an error message

4. signed -  revoked where according to rfc2560bis are defined values for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

 

What is missing? The rfc2560bis must also specify values for:

This Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

 

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) it may be replaced by a (final) revocation; 3) it may be explicitly released;

and

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced with real status of a new real certificate which was issued with the same certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the certificate was not checked with CA public key.

 

It is based on the following definitions:

 
According to rfc2560bis the certificate status value is:
http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 
 
   -  good … is not revoked, (does not necessarily mean that the certificate was ever issued)…
   -  revoked … has been revoked (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.)
   -  unknown …

 

   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.

 

 

According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-X.509

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways:

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or,

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or,

c) it may be explicitly released and the entry removed from the CRL.

 

 

 

-----Original Message-----
From: Piyush Jain [mailto:piyush@ditenity.com]
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

 

 

 

> -----Original Message-----

> From: Stefan Santesson [mailto:stefan@aaa-sec.com]

> Sent: Tuesday, January 08, 2013 8:40 PM

> To: Peter Rybar; 'Piyush Jain'; 'pkix'

> Subject: Re: [pkix] Question about extended Revoked Extension defined in

> section 4.4.8 of ocsp draft 8

> Importance: High

>

> Peter;

>

> On 1/8/13 5:18 PM, "Peter Rybar" <rybar@nbusr.sk> wrote:

>

> >Stefan,

> >The terminology is not clear for someone who will see:

> >The revocation is of "non-issued certificate".

> >Because by reading the text it is expected that the certificate was

> >issued, but fraudulently.

>

> What part of the text supports that?

[Piyush] None explicitly, but many would infer it that way. The certificate

space that is covered by your interpretation of "non-issued" includes

certificates which are not signed using the CA key and those that are signed

fraudulently. RPs won't make queries for certificate for which they cannot

verify the signature. So the only genuine requests for "non-issued

certificates" coming to a responder would be those for fraudulently issued

certificates unless you are saying that this specification will allow for

RPs to skip signature checking.

>

> >

> >The revocation with a new extension is only about fraudulently issued

> >certificate. It means this new extension and revocation is not used

> >when the certificate is not issued and only fake random certificate

> >serial number was created in OCSP request.

>

> What?

> How in this physical universe would the OCSP responder tell the

> difference???

> Crystal ball?

>

> >

> >While it is intended only for fraudulently issued certificate where

> >fraudulently issued certificate can potentially reuse any already used

> >certificate-serial-number the extension must contain e.g. a positive

> >confirmation of existence in the form of hash value of fraudulently

> >issued certificate.

>

> No that is a task for another possible effort.

> It's not part of this update.

 

[Piyush] Can you clarify what is the goal for this update? I think it is one

of the following

- Allow for extending definition of revoked so other specifications can

extend the protocol

- Address handling of fraudulently issued certificate.

- Address handling of any certificate not issued by the CA.

 

But based on different threads on this topic I get confused about what it

is. Having the goal clear would help us keep the review of draft focused.

 

>

> But this update paves the way for such extension. Which I'm not against.

> It's just not part of this update effort.

 

>

> >

> >Only according to the hash value of fraudulently issued certificate

> >relaying party and OCSP responder is able to identify fraudulently

> >issued certificate because CA was compromised and serial numbers of

> >certificates are not any longer unique for compromised CA.

> >

> >Conclusion:

> >Positive statement extension as a hash value of the certificate whose

> >status OCSP response is providing can be used in this case:

> >  when the certificate is revoked,

> >  when the certificate is good and also

> >  when the certificate is fraudulently issued.

> >

> >For that reason it can be more helpful to define in RFC one positive

> >statement extension as a hash value of the certificate whose status the

> >OCSP response is providing and define in RFC that it will support

> >situations when status is:

> >   -- good

> >   -- revoked

> >And for randomly created certificate serial numbers without records in

> >OCSP database will be use:

> >   -- unknown

>

>

> No, we have been through this and determined WG consensus.

> Unknown is not the choice, since it may not have the desired effect (to

> indicate that a certificate with this serial number should not be

trusted).

>

> It's important that this works with legacy clients. They will be around

for a

> while.

>

[Piyush] That's an interesting usage of the word "legacy". I don't think

that any of the previous versions of OCSP recommended interpreting "unknown"

or UNAUTHORIZED(unsigned) responses to imply that certificate can be

trusted. The right word would be to "incorrectly implemented clients".

 

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

_______________________________________________ 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

--------------080704020707020306000907-- From piyush@ditenity.com Tue Jan 15 08:29:14 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 379FD21F85D7 for ; Tue, 15 Jan 2013 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, 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 vrSNOlWZiZOQ for ; Tue, 15 Jan 2013 08:29:00 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5247721F851E for ; Tue, 15 Jan 2013 08:29:00 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i18so323545oag.32 for ; Tue, 15 Jan 2013 08:28:59 -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:x-mailer:thread-index :content-language:x-gm-message-state; bh=RapgNDvbrVocWoBtq7XDw6swXE0aVhTUxAD5OYeglJg=; b=P5D9wN/XihvU6aNHGJCm52INQMGuXqJ96o/0epMOa+eI79tZlZds2lVv4xaB8GLf3u 0B8MyNjsEVJFosEdaGXtJ1hMB8fTEQoS51RvpelsKcwATs7TtiAju4c0JrR0cFApYZrk TsOM0naWYu7pLJRn8FW8+wW9wf/QW1VmuM72924cMVdHRFn9t+Xd3MGB5iJA9/8pZiJd byFXQO7t8Vg1Q9/8J4sehK1Zs5TarXQYObiF4FvBc+r6Hvh0W6nt41x0aB5SrCYMztTn uH3yPM6K8Qm0Y8WZG8I9qjX+KDt9FKADUmU31Rx7lxL6os8gWQtCAkNg7dI2BsIoAqEN Iplw== X-Received: by 10.182.36.8 with SMTP id m8mr65253402obj.93.1358267339632; Tue, 15 Jan 2013 08:28:59 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id y10sm13721093oeg.12.2013.01.15.08.28.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 08:28:58 -0800 (PST) From: "Piyush Jain" To: "'Denis Pinkas'" , "'Peter Rybar'" References: <201301151451.r0FEpiRU082504@mail.nbusr.sk> <50F578D6.50608@bull.net> In-Reply-To: <50F578D6.50608@bull.net> Date: Tue, 15 Jan 2013 08:28:53 -0800 Message-ID: <03e301cdf33d$6945a920$3bd0fb60$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E4_01CDF2FA.5B2FFDB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLFAF8yvnTj3Vew+xVuhTOaN55CcQJeDBVLlkl/+EA= Content-Language: en-us X-Gm-Message-State: ALoCoQnIpepKvWZPtCHiuDzErkFTzGUlTiDLWRLoDI+1bE++9N9pLR08worujTd/L5w+SW515WUr Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 16:29:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E4_01CDF2FA.5B2FFDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Denis, You said The disagreements : a) the error message malformedRequest is not the right approach, since the request is well-formed. b) the error message unauthorized is not the right approach, since the request is unauthorized. Based on your reasoning above, I would like to add c) The status revoked is not the right approach, since the certificate is not revoked. I support Peter's point that creating a signed revoked (or even signed unknown) for non-existent certificates is unnecessary waste. Given that the primary reason for OCSP is to address operational issues associated with CRLs, providing signed responses for non-existent certificates is unlikely to gain adoption, especially among large CAs who have deployed huge pre-signed OCSP infrastructure. Please note that returning a signed response for non-certificates makes pre-signing computationally infeasible. For reference, the 2 CAs who have the biggest share of SSL server market currently respond with unsigned UNAUTHORIZED and TRY_LATER for serial numbers that are not associated with a certificate. And a third one who provides managed PKI hosting uses a third party responder which returns TRY_LATER for non-existent certificates. I support your proposal for using notIssuedOrIrregularlyIssued(7) instead of certificateHold(6), if returning revoked for non-certificates is assumed to be axiomatic by this WG, which IMO should not be the case. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Tuesday, January 15, 2013 7:42 AM To: Peter Rybar Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients Peter, I agree with you one point, but I disagree with you on two others: The agreement : CertificateHold should not be used to address the problem we want to solve The disagreements : a) the error message malformedRequest is not the right approach, since the request is well-formed. b) the error message unauthorized is not the right approach, since the request is unauthorized. Please read the message I sent to Stefan at 2:58 p.m. today for a proposal to address the problem. Denis Stefan, Probably you have missed my argument that CRLReason of certificateHold is defined only in ITU-T X.509 and logical semantics specified for CRL and delta CRL when certificateHold is used is problematic for the usage in OCSP where request/response can be created several times in unspecified time/date. The usage of certificateHold as you have proposed is confusing and for that reason I was proposing another solution where is addressed the problem of issued certificate by CA without evidence in CA. Because the sentence "revoked response for non-issued certificates" is vague when it is only about wrong serial number and the certificate does not exists at application creating OCSP request. It is absurd situations and OCSP responder must react with an error message on such absurd request because that is not situation abut the certificate status, that is wrong request which is only about the integer number. OCSP is Online Certificate Status Protocol. It is not partial status about one or two component of the CertID! ( serialNumber or issuerNameHash or issuerKeyHash ) When OCSP has access to the CA database, what is the case defined in rfc2560bis for "revoked response for non-issued certificates", then the error message is right response, because such certificate does not exist and because the certificate does not exist also the status does not exist about the certificate which does not exist. According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 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. Another argument why revocation with reason code certificateHold is problematic: ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) 8.5.2.2 Reason code extension Once a hold has been issued, it may be handled in one of three ways: b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold , and the optional instruction code extension field shall not appear; or,, According to "the revocation date shall be the date the certificate was placed on hold" and according to usage of OCSP: The firs OCSP request will be in time t0 when certificate SerNum1 is not issued. You propose OCSP response revoked where: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC Then certificate will be issued in time t1 and revoked in time t2 in CRL. OCSP request will be created in time t3 and according to definition "the revocation date shall be the date the certificate was placed on hold" the revocation time will be . what a problem is because two interpretations exist. Is OCSP based on CRL or not. When is not based on CRL as is stated in rfc2560bis for revoked then the revocation time must be 1.1.1970 00:00:00 UTC I hope it is ridiculous :) For that reason I propose to use in this situation OCSP responder error message malformedRequest. For example for clause 7.4 Repudiation of a digital signing (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic when certificateHold is used because transactions created in each time when the certificate was in certificateHold must not be accepted. Also for that reason the certificateHold is forbidden in some systems or legislations. It creates additional complexity where each CRL must be analyzed to have the complete time line in which date/time and how long the certificate was in the certificateHold state because the certificate can be in certificateHold state several times. Martin Rex propose to use OCSP responder error message noIssueRecordFound (7) instead of OCSPResponseStatus ::= ENUMERATED { ? probablyCADatabaseOrCAKeyCompromise (7) } I agree, it is better and new OCSP RFC will define what will be done by the OCSP client when OCSP responder error message malformedRequest is received. OCSP client application will create a new OCSP request for the certificate where this certificate will be included in the singleRequestExtensions the extension identified by OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound . According to it OCSP responder or CA will be able to solve the problems with probably CA Database inconsistency or CA Key compromise and also the problem how the OCSP must be able to response on certificate serial number that don't match any issued cert. Because following response, when CA key was used, can be the real status of the certificate or OCSP responder error message tryLater because the analysis was started. When CA key was not used for signing the certificate in request the OCSP responder will return error message unauthorized because OCSP is not authorized. Peter Rybar _____ From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Tuesday, January 15, 2013 5:29 AM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients Peter, In general. For several reasons I'm not supportive of your proposals. The basic problem is that you don't listen to the problem statement being repeated here time after time after time. We are NOT trying to solve CA compromise. We are giving the protocol the capability to reasonably respond to requests for serial numbers that don't match any issued cert. That may or may not be caused by CA compromise. If you want to craft a perfect solution for handling CA compromise, fine. But that is not part of this update effort. /Stefan From: Peter Rybar Date: Monday, January 14, 2013 4:20 PM To: Stefan Santesson , 'Piyush Jain' , 'pkix' Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients Stefan, > A good protocol should provide a reasonable response to every possible request. I agree with such general sentence but rfc2560bis-08 is not able to fix discussed situations. Good view was done by Piyush Jain [piyush@ditenity.com] in [pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08 Let me propose another solution. We are trying to fix the situation, where the CA key was used for signing certificate but CA is not able to provide evidence about it for OCSP service. 1. It could be after disaster recovery procedure where the record was lost because it was not archived. 2. Or when the CA key was compromised and was used for signing a fake certificate. I do not think that proposed solution "to provide revoked status with a reason code certificateHold and extensions id-pkix-ocsp-extended-revoke" by OCSP to RP is helpful, because: 1. CA will not be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and 2. OCSP service will not be able to decide if it is a potential CA compromise or only bad OCSP client is creating fake request because only according to analyzing the certificate content true result can be produces. Because according to rfc2560bis-08 the certificate is only on the client side. 3. Solution is expensive and not useful because the signing of such revocation response will only consume system key resources for creating unclear response. At first, I propose to define a new type of the OCSP Responder error message: OCSPResponseStatus ::= ENUMERATED { . probablyCADatabaseOrCAKeyCompromise (7) } Or when solution is important to be understood by legacy clients then what is defined for probablyCADatabaseOrCAKeyCompromise will be applicable also for malformedRequest OCSP Responder error message: The RFC must define rules for RP OCSP client applications where the client will be able to repeat the OCSP request but together with the certificate for which OCSP responder error message is probablyCADatabaseOrCAKeyCompromise or malformedRequest. This certificate will be included in singleRequestExtensions where the extension will be identified with OBJECT IDENTIFIER id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise. OCSP responder will analyze received certificate and in situations where CA key was used the certificate will be provided to the CA for analysis and making decisions. The OCSP analysis will be the bases for the second OCSP response status like: 1. Signed good, revoked if the certificate was missed only according to recovery procedure; 2. Unsigned with OCSP Responder error message malformedRequest when the CertID (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to the form for which OCSP responder is able to provide the status. For example incorrect hash length in issuerNameHash or issuerKeyHash; Incorrect serial number like when CA is using sequential number and in request is present the serial number which is out of the maximum range or is used unsigned/signed integer as a hash value stored in certificate serial number. e.g. MD5 causes permanently problems with negative serial numbers where some CA and client try to change the negative integer of certificate serial number internally and are using such positive integer in OCSP request what causes problems. 3. Unsigned with OCSP Responder error message unauthorized when OCSP responder is not authorized for providing status for requested issuerNameHash, issuerKeyHash; 4. Unsigned with OCSP Responder error message tryLater when certificate was signed with CA key and CA must define decision what to do with it. . I hope this proposal can be helpful as a starting point. Peter Rybar National Security Authority Information Security and Electronic Signature Department _____ From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Friday, January 11, 2013 4:05 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 From: Peter Rybar Date: Friday, January 11, 2013 3:38 PM To: Stefan Santesson , 'Piyush Jain' , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Stefan, As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or all other types of responses except for revoked!!! How does a serial number become malformed just because it doesn't exists. Its just an integer. Its syntactically a well formed integer. According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of revoked with reason code certificateHold defined as equivocal result when is not correctly implemented. It means according to rfc2560bis all serial numbers are initially revoked with reason code certificateHold. Is it useful? Yes. (The revoked with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!) For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value good or revoked in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions. Then that can be achieved by defining a new single response extension that does not interfere with what is being done in 2560bis. When hash of the certificate as a positive statement MUST be used, the situations with OCSP responses for RP are clear and unique because: 1) good or revoked is only about know and issued certificates, Great, so how then do you respond to a request for a serial number that has never been issued? 2) any other situations are moved into one group which is unclear and not analyzed - no evidence, no responsibility. But the responder still need to respond. It is a radical simplification! Of what? Instead of trying to solve presently not practical and theoretical situations from the responsibility/liability point of view (like preparing us for situations: what we will offer for intergalactic green man, are vegetarian? ;) we can define steps which can be implemented by CAs and OCSP systems like usage of positive statement cert hash. Asking for status of a never issued serial number is not impossible. It is not even hard. A good protocol should provide a reasonable response to every possible request. E.g. define new or reuse already defined in private OID space. PositiveStatement ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, certHash OCTET STRING, -- Hash of Subjects certificate } And according it we cam move. I have nothing against such extension being defined. But it still does not remove the need for the current discussed mechanism. The current discussed mechanism address how to respond to legacy clients to requests for non-issued serial numbers. Your extension does not help, because it is not understood by legacy clients. So its not either or. /Stefan Peter Rybar _____ From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Thursday, January 10, 2013 2:19 PM To: Peter Rybar; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Peter, i think the reason for this has been thoroughly debated. It is correct that a cert serial number that was on hold, may be released. The requested cert serial number may actually be used in a future representing a real certificate. So this is intentional and the whole purpose behind using the on hold reason. /Stefan From: Peter Rybar Date: Thursday, January 10, 2013 12:13 PM To: 'Piyush Jain' , Stefan Santesson , 'pkix' Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 Stefan, For me is unclear how this extension of revoked with reason code certificateHold is useful. It define that now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist. I agree that extension of revoked can be helpful like: The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. When the certificate serial number is not in the OCSP database/CRL then according to rfc2560bis there are defined following possible responses: 1. signed - good (e.g. certificate serial number is not listed in CRL) 2. signed - unknown (e.g. certificate serial number is not listed in CRL) 3. unsigned - unauthorized as an error message 4. signed - revoked where according to rfc2560bis are defined values for: Extensions: id-pkix-ocsp-extended-revoke Revocation Reasons: certificateHold Revocation Time: 1.1.1970 00:00:00 UTC What is missing? The rfc2560bis must also specify values for: This Update: ?? ?? ?? 10.1.2013 9:51:15 UTC Next Update: ?? ?? ?? 10.1.2013 9:51:15 UTC X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) it may be replaced by a (final) revocation; 3) it may be explicitly released; and 4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced with real status of a new real certificate which was issued with the same certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the certificate was not checked with CA public key. It is based on the following definitions: According to rfc2560bis the certificate status value is: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ - good . is not revoked, (does not necessarily mean that the certificate was ever issued). - revoked . has been revoked (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.) - unknown . 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. According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code extension: http://www.itu.int/rec/T-REC-X.509 A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). Once a hold has been issued, it may be handled in one of three ways: a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, c) it may be explicitly released and the entry removed from the CRL. -----Original Message----- From: Piyush Jain [mailto:piyush@ditenity.com] Sent: Wednesday, January 09, 2013 6:17 PM To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix' Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Tuesday, January 08, 2013 8:40 PM > To: Peter Rybar; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Question about extended Revoked Extension defined in > section 4.4.8 of ocsp draft 8 > Importance: High > > Peter; > > On 1/8/13 5:18 PM, "Peter Rybar" wrote: > > >Stefan, > >The terminology is not clear for someone who will see: > >The revocation is of "non-issued certificate". > >Because by reading the text it is expected that the certificate was > >issued, but fraudulently. > > What part of the text supports that? [Piyush] None explicitly, but many would infer it that way. The certificate space that is covered by your interpretation of "non-issued" includes certificates which are not signed using the CA key and those that are signed fraudulently. RPs won't make queries for certificate for which they cannot verify the signature. So the only genuine requests for "non-issued certificates" coming to a responder would be those for fraudulently issued certificates unless you are saying that this specification will allow for RPs to skip signature checking. > > > > >The revocation with a new extension is only about fraudulently issued > >certificate. It means this new extension and revocation is not used > >when the certificate is not issued and only fake random certificate > >serial number was created in OCSP request. > > What? > How in this physical universe would the OCSP responder tell the > difference??? > Crystal ball? > > > > >While it is intended only for fraudulently issued certificate where > >fraudulently issued certificate can potentially reuse any already used > >certificate-serial-number the extension must contain e.g. a positive > >confirmation of existence in the form of hash value of fraudulently > >issued certificate. > > No that is a task for another possible effort. > It's not part of this update. [Piyush] Can you clarify what is the goal for this update? I think it is one of the following - Allow for extending definition of revoked so other specifications can extend the protocol - Address handling of fraudulently issued certificate. - Address handling of any certificate not issued by the CA. But based on different threads on this topic I get confused about what it is. Having the goal clear would help us keep the review of draft focused. > > But this update paves the way for such extension. Which I'm not against. > It's just not part of this update effort. > > > > >Only according to the hash value of fraudulently issued certificate > >relaying party and OCSP responder is able to identify fraudulently > >issued certificate because CA was compromised and serial numbers of > >certificates are not any longer unique for compromised CA. > > > >Conclusion: > >Positive statement extension as a hash value of the certificate whose > >status OCSP response is providing can be used in this case: > > when the certificate is revoked, > > when the certificate is good and also > > when the certificate is fraudulently issued. > > > >For that reason it can be more helpful to define in RFC one positive > >statement extension as a hash value of the certificate whose status the > >OCSP response is providing and define in RFC that it will support > >situations when status is: > > -- good > > -- revoked > >And for randomly created certificate serial numbers without records in > >OCSP database will be use: > > -- unknown > > > No, we have been through this and determined WG consensus. > Unknown is not the choice, since it may not have the desired effect (to > indicate that a certificate with this serial number should not be trusted). > > It's important that this works with legacy clients. They will be around for a > while. > [Piyush] That's an interesting usage of the word "legacy". I don't think that any of the previous versions of OCSP recommended interpreting "unknown" or UNAUTHORIZED(unsigned) responses to imply that certificate can be trusted. The right word would be to "incorrectly implemented clients". > /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 _______________________________________________ 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 ------=_NextPart_000_03E4_01CDF2FA.5B2FFDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Denis,

 

You said

The disagreements = :
   a) the error message malformedRequest is not the = right approach, since the request is well-formed.
   b) the = error message unauthorized is not the right approach, since the request = is unauthorized.

Based on your reasoning above, I would like to = add

c) The status revoked is not the right approach, since the = certificate is not revoked.

 

I support Peter’s point that creating a signed revoked (or even = signed unknown) for non-existent certificates is unnecessary waste. = Given that the primary reason for OCSP is to address operational issues = associated with CRLs, providing signed responses for non-existent = certificates is unlikely to gain adoption, especially among large CAs = who have deployed huge pre-signed OCSP infrastructure. Please note that = returning a signed response for non-certificates makes pre-signing = computationally infeasible.

For reference, the 2 CAs who have the biggest share of SSL server = market currently respond with unsigned UNAUTHORIZED and TRY_LATER for = serial numbers that are not associated with a certificate. And a third = one who provides managed PKI hosting uses a third party responder which = returns TRY_LATER for non-existent certificates.

 

I support your proposal for using notIssuedOrIrregularlyIssued(7) = instead of certificateHold(6), if returning revoked for non-certificates = is assumed to be axiomatic by this WG, which IMO should not be the = case.

 

-Piyush

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Denis Pinkas
Sent: Tuesday, January 15, 2013 7:42 = AM
To: Peter Rybar
Cc: = pkix@ietf.org
Subject: Re: [pkix] Solution with = singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for = legacy clients

 

Peter,

I agree with you one point, = but I disagree with you on two others:

The agreement : = CertificateHold should not be used to address the problem we want to = solve

The disagreements :
   a) the error message = malformedRequest is not the right approach, since the request is = well-formed.
   b) the error message unauthorized is not = the right approach, since the request is unauthorized.

Please = read the message I sent to Stefan at 2:58 p.m. today for a proposal to = address the = problem.

Denis

St= efan,

Pr= obably you have missed my argument that CRLReason of certificateHold is = defined only in ITU-T X.509 and logical semantics specified for CRL and = delta CRL when certificateHold is used is problematic for the usage in = OCSP where request/response can be created several times in unspecified = time/date.

&n= bsp;

The usage of =
certificateHold as you have proposed is confusing and for that reason I =
was proposing another solution where is addressed the problem of issued =
certificate by CA without evidence in CA. =

Because the =
sentence "revoked response for non-issued certificates" =
is vague when it is only =
about wrong serial number and the certificate does not exists at =
application creating OCSP request.
It is absurd =
situations and OCSP responder must =
react with =
an =
error message on such absurd =
request because that is not situation abut the certificate status, that =
is wrong request which is only about the integer =
number.
OCSP is Online =
Certificate Status Protocol.
It is not partial =
status about one or two component of the CertID! ( serialNumber or =
issuerNameHash or issuerKeyHash )
 <=
/o:p>
When OCSP has =
access to the CA database, what is the case defined in rfc2560bis for =
"revoked response for non-issued certificates", then the error =
message is right response, 
because such =
certificate does not exist and 
because the =
certificate does not exist also the status does not exist about the =
certificate which does not exist.
 <=
/o:p>
According to rfc2560bis the certificate status value =
is:

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/

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.

&n= bsp;

An= other argument why revocation with reason code = certificateHold = is problematic:

IS= O/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) =

8.= 5.2.2 Reason code extension

On= ce a hold has been issued, it may be handled in one of three ways: =

b)= it may be replaced by a (final) revocation for the same certificate, in = which case the reason shall be one of the standard reasons for = revocation, the= revocation date shall be the date the certificate was placed on hold = , = and the optional instruction code extension field shall not appear; = or,,

&n= bsp;

Ac= cording to “the= revocation date shall be the date the certificate was placed on = hold&#= 8221; and according to usage of OCSP:

Th= e firs OCSP request will be in time t0 when certificate SerNum1 is not = issued.

Yo= u propose OCSP response revoked where:

Extensions: = id-pkix-ocsp-extended-revoke

Revocation Reasons: = certificateHold

Revocation = Time: 1.1.1970 00:00:00 UTC

&n= bsp;

Th= en certificate will be issued in time t1 and revoked in time t2 in = CRL.

&n= bsp;

OC= SP request will be created in time t3 and according to definition = “the= revocation date shall be the date the certificate was placed on = hold&#= 8221; the revocation time will be … what a problem is because two = interpretations exist.

Is= OCSP based on CRL or not…

Wh= en is not based on CRL as is stated in rfc2560bis for revoked = th= en the revocation time must be 1.1.1970 = 00:00:00 UTC

I = hope it is ridiculous :)

&n= bsp;

Fo= r that reason I propose to use in this situation OCSP responder error = message mal= formedRequest.<= /span>

&n= bsp;

Fo= r example for clause 7.4 Repudiation of a digital signing (ISO/IEC = 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic = when certificateHold = is used because transactions created in each time when the certificate = was in certificateHold must not be accepted.

Al= so for that reason the certificateHold is forbidden in some systems or = legislations.

It= creates additional complexity where each CRL must be analyzed to have = the complete time line in which date/time and how long the certificate = was in the certificateHold state because the certificate can be in = certificateHold state several times.

&n= bsp;

&n= bsp;

Ma= rtin Rex propose to use OCSP responder error message noIssueRecord= Found (7) instead of

OCSPResponseS= tatus ::=3D ENUMERATED { ?

  &= nbsp; probablyCADatabaseOrCAKeyCompromise (7) }

 =

I agree, it = is better and new OCSP RFC will define what will be done by the OCSP = client when OC= SP responder error message mal= formedRequest is = received.

OCSP client = ap= plication will create a new OCSP request for the certificate where this = certificate will be included in the singleRequestExtensions the = extension identified by OBJECT IDENTIFIER = id-pkix-ocsp-CertOfNoIssueRecord= Found = .

&n= bsp;

Ac= cording to it OCSP responder or CA will be able to solve the problems = with probably CA = Database inconsistency or CA Key compromise and also the problem how the = OCSP must be able to response on certificate serial number that don't = match any issued cert.

Because = following response, when CA key was used, can be the real status of the = certificate or OC= SP responder error message tryLater = because the analysis was started.

When CA = key was not used for signing the certificate in request the OC= SP responder will return error message una= uthorized = because OCSP is not authorized.

 =

Peter = Rybar

&n= bsp;

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Tuesday, January 15, 2013 5:29 AM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Solution with = singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for = legacy clients

 

Peter,

 

In = general.

For = several reasons I'm not supportive of your = proposals.

 

The basic = problem is that you don't listen to the problem statement being repeated = here time after time after time.

We are NOT = trying to solve CA compromise. We are giving the protocol the capability = to reasonably respond to requests for serial numbers that don't match = any issued cert.

 

That may = or may not be caused by CA = compromise.

 

If you = want to craft a perfect solution for handling CA compromise, fine. But = that is not part of this update = effort.

/Stefan

 

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: = Monday, January 14, 2013 4:20 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Piyush Jain' <piyush@ditenity.com>, 'pkix' = <pkix@ietf.org>
Subject: = [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy = clients

 

St= efan,

=  > A good = protocol should provide a reasonable response to every possible = request.

&n= bsp;

I = agree with such general sentence but rfc2560bis-08 is not able to fix = discussed situations.

Go= od view was done by Piyush Jain [piyush@ditenity.com] = in

[p= kix] Addressing issues in 4.2.2.2 of = rfc2560bis-08

&n= bsp;

Le= t me propose another solution.

We= are trying to fix the situation, where the CA key was used for signing = certificate but CA is not able to provide evidence about it for OCSP = service.

1.= It could be after disaster recovery procedure where the record was lost = because it was not archived.

2.= Or when the CA key was compromised and was used for signing a fake = certificate.

&n= bsp;

I = do not think that proposed solution “to provide revoked = status with a reason code certificateHold and extensions = id-pkix-ocsp-extended-revoke” by OCSP to RP is helpful, = because:

1.= CA will not be informed about the potential inconsistency in the CA = database or about potential critical attack (DigiNotar); and =

2.= OCSP service will not be able to decide if it is a potential CA = compromise or only bad OCSP client is creating fake request because only = according to analyzing the certificate content true result can be = produces. Because according to rfc2560bis-08 the certificate is only on = the client side.

3.= Solution is expensive and not useful because the signing of such = revocation response will only consume system key resources for creating = unclear response.

&n= bsp;

At= first, I propose to define a new type of the OCSP Responder error = message:

OC= SPResponseStatus ::=3D ENUMERATED { …

&n= bsp;  probablyCADatabaseOrCAKeyCompromise = (7)

}<= /span>

&n= bsp;

Or= when solution is important to be understood = by legacy clients = then what is defined for probablyCADatabaseOrCAKeyCompromise will = be applicable also for malformedRequest OCSP Responder error = message:

Th= e RFC must define rules for RP OCSP client applications where the client = will be able to repeat the OCSP request but together with the = certificate for which OCSP responder error message is = probablyCADatabaseOrCAKeyCompromise or = malformedRequest.

&n= bsp;

Th= is certificate will be included in singleRequestExtensions where the = extension will be identified with OBJECT = IDENTIFIER

id= -pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise.<= /o:p>

&n= bsp;

OC= SP responder will analyze received certificate and in situations where = CA key was used the certificate will be provided to the CA for analysis = and making decisions.

&n= bsp;

Th= e OCSP analysis will be the bases for the second OCSP response status = like:

&n= bsp;1. Signed good, revoked if the certificate was missed only according = to recovery procedure;

&n= bsp;2. Unsigned with OCSP Responder error message malformedRequest when = the CertID (issuerNameHash, issuerKeyHash, serialNumber) is not = corresponding to the form for which OCSP responder is able to provide = the status.

&n= bsp; For example incorrect hash length in issuerNameHash or = issuerKeyHash;

&n= bsp; Incorrect serial number like when CA is using sequential number and = in request is present the serial number which is out of the maximum = range or is used unsigned/signed integer as a hash value stored = in certificate serial number… e.g. MD5 causes permanently problems = with negative serial numbers where some CA and client try to change the = negative integer of certificate serial number internally and are using = such positive integer in OCSP request what causes = problems.

3.= Unsigned with OCSP Responder error message unauthorized when OCSP = responder is not authorized for providing status for requested = issuerNameHash, issuerKeyHash;

4.= Unsigned with OCSP Responder error message tr= yLater when certificate was signed with CA key and CA must define = decision what to do with it.

&#= 8230;

&n= bsp;

I = hope this proposal can be helpful as a starting = point.

&n= bsp;

Peter = Rybar
National = Security Authority
Information Security and Electronic Signature = Department

&n= bsp;

&n= bsp;

&n= bsp;

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Friday, January 11, 2013 4:05 PM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question = about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

 

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: = Friday, January 11, 2013 3:38 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Piyush Jain' <piyush@ditenity.com>, 'pkix' = <pkix@ietf.org>
Subject: = Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8

 

Stefan,
As you can see in my previous mail, when OCSP request =
contains incorrect (malformed) serial number, because the certificate =
does not exist, the OCSP Responder may return an error message =
malformedRequest or all other types of responses except for =
revoked!!!

 

How does a = serial number become malformed just because it doesn't exists. Its just = an integer.

Its = syntactically a well formed integer.

 

According to =
rfc2560bis is situation worse because the status revoked which was about =
the real certificate status (in CRL or in previous OCSP RFC) is now with =
extension of revoked with reason code certificateHold defined as =
equivocal result when is not correctly implemented. =

It means according to rfc2560bis all serial =
numbers are initially revoked with reason code =
certificateHold… Is it =
useful?

 

Yes.=

 

(The =
revoked with reason code certificateHold is based on CA database =
and in some next steps database can also include the hash values of =
certificates for positive =
statement!)
 
For that =
reason some systems and legislations where non-repudiation services are =
required (e.g. QES) dictate that status value good or =
revoked in OCSP response MUST contain a positive statement a hash =
value of certificate in =
singleExtensions.
 

 

Then that = can be achieved by defining a new single response extension that does = not interfere with what is being done in = 2560bis.

 

When =
hash of the certificate as a positive statement MUST be used, the =
situations with OCSP responses for RP are clear and unique =
because:
1) good or revoked is only =
about know and issued =
certificates,

 

Great, so = how then do you respond to a request for a serial number that has never = been issued?

 

2) =
any other situations are moved into one group which is unclear =
and not analyzed – no evidence, no =
responsibility.

 

But the = responder still need to respond.

 

 
It is a radical =
simplification!

 

Of = what?

 

 
Instead of trying to solve presently not practical and =
theoretical situations from the responsibility/liability point of view =
(like preparing us for situations: what we will offer for intergalactic =
green man, are vegetarian? ;) we can define steps which can be =
implemented by CAs and OCSP systems like usage of positive statement =
cert =
hash.
 

 

Asking for = status of a never issued serial number is not impossible. It is not even = hard.

A good = protocol should provide a reasonable response to every possible = request.

 

E.g. =
define new or reuse already defined in private OID =
space.
PositiveStatement ::=3D SEQUENCE =
{
   hashAlgorithm    =
AlgorithmIdentifier,
   =
certHash         OCTET STRING, =
-- Hash of Subjects =
certificate
}
 =

And according it we cam =
move.

 

I have = nothing against such extension being = defined.

But it = still does not remove the need for the current discussed = mechanism.

 

The = current discussed mechanism address how to respond to legacy clients to = requests for non-issued serial = numbers.

Your = extension does not help, because it is not understood by legacy = clients.

 

So its not = either or.

 

/Stefan

 

 
Peter Rybar

&n= bsp;

&n= bsp;

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Thursday, January 10, 2013 2:19 PM
To: Peter = Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question = about extended Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

Peter, i = think the reason for this has been thoroughly = debated.

 

It is = correct that a cert serial number that was on hold, may be = released.

The = requested cert serial number may actually be used in a future = representing a real certificate.

So this is = intentional and the whole purpose behind using the on hold = reason.

 

/Stefan

 

From: = Peter = Rybar <rybar@nbusr.sk>
Date: = Thursday, January 10, 2013 12:13 PM
To: 'Piyush Jain' = <piyush@ditenity.com>, = Stefan Santesson <stefan@aaa-sec.com>, 'pkix' = <pkix@ietf.org>
Subject: = Re: [pkix] Question about extended Revoked Extension defined in = section 4.4.8 of ocsp draft 8

 

Stefan,

For me is unclear how this extension of = revoked with reason code certificateHold is = useful.

It define that now = is possible to revoke what does not exist and it open never ending cycle = of trying to fixing or correcting the first incorrect status that = "fake" cert serial number is revoked but cert serial number is = not revoked because "fake" cert does not = exist.

 

I agree that extension of revoked can be = helpful like:

   The =
"revoked" state indicates that the certificate has been =
revoked
   (either permanently or =
temporarily (on hold)). Response =
extensions
   may be used to convey =
additional information on assertions made =
by
   the responder regarding the status =
of the certificate such as
   positive =
statement about issuance, validity, etc.

 

 

When the certificate serial number is not in the = OCSP database/CRL then according to rfc2560bis there are defined = following possible responses:

1. signed -  good (e.g. certificate = serial number is not listed in CRL)

2. signed -  unknown (e.g. = certificate serial number is not listed in = CRL)

3. unsigned – = unauthorized as an error message

4. signed -  revoked where according = to rfc2560bis are defined values for:

Extensions: = id-pkix-ocsp-extended-revoke

Revocation Reasons: = certificateHold

Revocation Time: 1.1.1970 00:00:00 = UTC

 

What is missing? The rfc2560bis must also = specify values for:

This = Update:  ?? ?? ??     10.1.2013 9:51:15 = UTC

Next = Update:  ?? ?? ??     10.1.2013 9:51:15 = UTC

 <= /span>

X.509 defines the reason code certificateHold as = 1) it may remain on the CRL; 2) it may be replaced by a (final) = revocation; 3) it may be explicitly released;

and =

4) as a consequence of rfc2560bis the status of = certificate serial number indicated as revoked with reason code = certificateHold can be replaced with real status of a new real = certificate which was issued with the same certificate serial number as = was asked in the incorrect OCSP request created by insufficiently = implemented applications where the signature of the certificate was not = checked with CA public key.

 

It is based on the following = definitions:

 
Accord=
ing to rfc2560bis the certificate status value =
is:
http:/=
/tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ =

 
   - =
 good … is not revoked, (does not necessarily mean =
that the certificate was ever =
issued)…
   -  revoked =
… has been revoked (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.)
   -  unknown =
…

 

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

 

 

According to ITU-T Rec. X.509 (11/2008), clause = 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-= X.509

A certificate may be = placed on hold by issuing a CRL entry with a reason code of = certificateHold. The certificate hold notice may include an optional = hold instruction code to convey additional information to certificate = users (see 8.5.2.3).

Once a hold has been = issued, it may be handled in one of three ways:

a) it may remain on the CRL with no further = action, causing users to reject transactions issued during the hold = period; or,

b) it may be = replaced by a (final) revocation for the same certificate, in which case = the reason shall be one of the standard reasons for revocation, the = revocation date shall be the date the certificate was placed on hold, = and the optional instruction code extension field shall not appear; or, =

c) it may be = explicitly released and the entry removed from the = CRL.

 

 

 

-----Original = Message-----
From: Piyush Jain [mailto:piyush@ditenity.com] =
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; = 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended = Revoked Extension defined in section 4.4.8 of ocsp draft = 8

 

 

 

> -----Original = Message-----

> From: Stefan = Santesson [mailto:stefan@aaa-sec.com]<= o:p>

> Sent: Tuesday, = January 08, 2013 8:40 PM

> To: Peter Rybar; = 'Piyush Jain'; 'pkix'

> Subject: Re: = [pkix] Question about extended Revoked Extension defined = in

> section 4.4.8 of = ocsp draft 8

> Importance: = High

> =

> = Peter;

> =

> On 1/8/13 5:18 = PM, "Peter Rybar" <rybar@nbusr.sk> = wrote:

> =

> = >Stefan,

> >The = terminology is not clear for someone who will = see:

> >The = revocation is of "non-issued = certificate".

> >Because by = reading the text it is expected that the certificate = was

> >issued, but = fraudulently.

> =

> What part of the = text supports that?

[Piyush] None = explicitly, but many would infer it that way. The = certificate

space that is covered = by your interpretation of "non-issued" = includes

certificates which are = not signed using the CA key and those that are = signed

fraudulently. RPs = won't make queries for certificate for which they = cannot

verify the signature. = So the only genuine requests for = "non-issued

certificates" = coming to a responder would be those for fraudulently = issued

certificates unless = you are saying that this specification will allow = for

RPs to skip signature = checking.

> =

> = >

> >The = revocation with a new extension is only about fraudulently = issued

> >certificate. = It means this new extension and revocation is not = used

> >when the = certificate is not issued and only fake random = certificate

> >serial number = was created in OCSP request.

> =

> = What?

> How in this = physical universe would the OCSP responder tell = the

> = difference???

> Crystal = ball?

> =

> = >

> >While it is = intended only for fraudulently issued certificate = where

> >fraudulently = issued certificate can potentially reuse any already = used

> = >certificate-serial-number the extension must contain e.g. a = positive

> >confirmation = of existence in the form of hash value of = fraudulently

> >issued = certificate.

> =

> No that is a task = for another possible effort.

> It's not part of = this update.

 

[Piyush] Can you = clarify what is the goal for this update? I think it is = one

of the = following

- Allow for extending = definition of revoked so other specifications = can

extend the = protocol

- Address handling of = fraudulently issued certificate.

- Address handling of = any certificate not issued by the CA.

 

But based on different = threads on this topic I get confused about what = it

is. Having the goal = clear would help us keep the review of draft focused. =

 

> =

> But this update = paves the way for such extension. Which I'm not = against.

> It's just not = part of this update effort.

 

> =

> = >

> >Only = according to the hash value of fraudulently issued = certificate

> >relaying = party and OCSP responder is able to identify = fraudulently

> >issued = certificate because CA was compromised and serial numbers = of

> >certificates = are not any longer unique for compromised CA.

> = >

> = >Conclusion:

> >Positive = statement extension as a hash value of the certificate = whose

> >status OCSP = response is providing can be used in this case:

> >  when = the certificate is revoked,

> >  when = the certificate is good and also

> >  when = the certificate is fraudulently issued.

> = >

> >For that = reason it can be more helpful to define in RFC one = positive

> >statement = extension as a hash value of the certificate whose status = the

> >OCSP response = is providing and define in RFC that it will = support

> >situations = when status is:

> >   = -- good

> >   = -- revoked

> >And for = randomly created certificate serial numbers without records = in

> >OCSP database = will be use:

> >   = -- unknown

> =

> =

> No, we have been = through this and determined WG consensus.

> Unknown is not = the choice, since it may not have the desired effect = (to

> indicate that a = certificate with this serial number should not = be

trusted).

> =

> It's important = that this works with legacy clients. They will be = around

for = a

> = while.

> =

[Piyush] That's an = interesting usage of the word "legacy". I don't = think

that any of the = previous versions of OCSP recommended interpreting = "unknown"

or = UNAUTHORIZED(unsigned) responses to imply that certificate can = be

trusted. The right = word would be to "incorrectly implemented = clients".

 

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

<= p class=3DMsoNormal>___________= ____________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/= mailman/listinfo/pkix

<= p class=3DMsoNormal>___________= ____________________________________ 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

 

------=_NextPart_000_03E4_01CDF2FA.5B2FFDB0-- From mrex@sap.com Tue Jan 15 09:48: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 ECCD721F8703 for ; Tue, 15 Jan 2013 09:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.893 X-Spam-Level: X-Spam-Status: No, score=-9.893 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EenkTRLcrqDs for ; Tue, 15 Jan 2013 09:48:55 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6D84621F86F0 for ; Tue, 15 Jan 2013 09:48:54 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0FHmjCZ024599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2013 18:48:45 +0100 (MET) In-Reply-To: <201301151451.r0FEpiRU082504@mail.nbusr.sk> To: Peter Rybar Date: Tue, 15 Jan 2013 18:48:45 +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: <20130115174845.91A6D1A45A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 15 Jan 2013 17:48:57 -0000 Peter Rybar wrote: > > Probably you have missed my argument that CRLReason of certificateHold > is defined only in ITU-T X.509 Huh? You should get yourself a new copy of rfc5280 http://tools.ietf.org/html/rfc5280 if your's is missing certificateHold(6) CRLReason in the reasonCode extension. > > and logical semantics specified for CRL and delta CRL when > certificateHold is used is problematic for the usage > in OCSP That is non-sensical. This update does not create CRLs or delta CRLs, so the semantics of CRLs and deltaCRLs is irrelevant (for this update). Even then, any existing OCSP responder that feeds on URL will have to sensibly deal with this reason code when processing CRLs and delta CRLs, even without this update, so there is nothing about this complexity that you could blame onto the propsed update. > > where request/response can be created several times in > unspecified time/date. The semantics of the certificateHold ReasonCode for the "not-issued" situation is clear and well-defined. But what you appear to totally ignore is the problem of permanent revocation status. An RP may cache any OCSP response with a permanent revocation status FOREVER, entirely ignoring the nextUpdate field, because that is exactly what a permant revocation status implies. Therefore we MUST ABSOLUTELY avoid to convey a revoked status that an RP might consider a permanent revocation status! > > The usage of certificateHold as you have proposed is confusing Nope, the X.509 semantics of certificateHold that, which we want to use, is crystal clear in 8.5.2.2 (a): the hold status may remain with no further action, causing users to reject transactions issued during the hold period (the words "on the CRL" removed, since this is about the semantics of revocationReason within the OCSP SingleResponse, not the semantics of ReasonCode within a CrlEntryExtension). > > and for that reason I was proposing another solution where is > addressed the problem of issued certificate by CA without evidence in CA. > Because the sentence "revoked response for non-issued certificates" > is vague when it is only about wrong serial number and the certificate > does not exists at application creating OCSP request. As I've previously described, the certificate that the RP is holding is entirely irrelevant to the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients seem to never include the (optional) certificate in OCSP requests. > > It is absurd situations and OCSP responder must react with an error > message on such absurd request because that is not situation about > the certificate status, that is wrong request which is only about > the integer number. > OCSP is Online Certificate Status Protocol. rfc2560, and how it is used by the installed base, is provably about Certificate Serial Status, not about Certificate status. Some RPs may boldly infer Certificate status from Certificate Serial Status, but that is an inference from the OCSP response, not a function of the OCSP protocol the way it is used by common OCSP clients. There is no such thing as an absurd situation for the OCSP responder when looking up a cert serial from the CA cert issue records. Either an issue record will be found (likely returning a certificate hash along with the status that the serial was found), or no issue record will be found. These are two well-defined, easily distinguishable lookup results that can be trivially converted into determinstic OCSP responder behaviour with clear and obvious semantics. > > It is not partial status about one or two component of the CertID! > ( serialNumber or issuerNameHash or issuerKeyHash ) I'm sorry, this statement non-sensical. issuerNameHash and isserKeyHash refer to the CA cert, and as you can see from the ASN.1 definition, they are non-optional -- these two values MUST always be compared, and if they don't match, the result MUST be an "unknown" OCSP response. The serialNumber is the parameter that refers to the certificate. And in order to determine the certificate status this value MUST be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request or CA cert issue records. So there can not be such thing as a partial status or a partial match. > > When OCSP has access to the CA database, what is the case defined > in rfc2560bis for "revoked response for non-issued certificates", > then the error message is right response, This is also a non-sensical statement. An error message has the semantics "this information source is unable to provide cert status information", which would non only a pretty stupid response for any authoritative OCSP to return when that OCSP responder known pretty damn well that this cert serial does not exist on the CA cert issue records, and when two extremely common types of behaviours of RPs in the installed base for an "unknown" response from an authoritative OCSP responder are (1) fail soft and accept the cert or (2) fallback to CRL checking, where the revocation check is bound to return status "good", because it is impossible to detect the "not-issued" with CRLs. Bottom line, while returning "good" is permitted by rfc2560 in absence of the capability to detect "not issued", and will result in the same behaviour as the OCSP client soft failing or falling back to CRL checking, returning unknwon would be a pretty dumb response for an authoritative OCSP responder which *KNOWS* the status of the requested cert serial. > > Another argument why revocation with reason code certificateHold is problematic: > > ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) > > 8.5.2.2 Reason code extension > > Once a hold has been issued, it may be handled in one of three ways: > > b) it may be replaced by a (final) revocation for the same certificate, > in which case the reason shall be one of the standard reasons for > revocation, the revocation date shall be the date the certificate was > placed on hold, and the optional instruction code extension field > shall not appear; or,, You seem to be totally confused (or exhibit problems in understanding X.509) We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update. 8.5.2.2 (b) obviously does not apply to a cert serial that has "not issued" status. "not issued" is a temporary status until (if ever) a real cert with that serial gets issued. Once a real cert with that serial has been issued, OCSP requests for this cert serial will return the status of this real cert from the CA issue records, and no longer report "not issued". > > According to ?the revocation date shall be the date the certificate > was placed on hold? and according to usage of OCSP: Since there _exists_ no certiticte when certificateHold conveys the "not issued" status, this rule can obviously not apply, because there is no information source from which any "placedOnHoldTime" could be copied into the OCSP response. Consequently, the value to place in revocationTime for "not issued" is defined in 2560bis -- that should be intuitively apparent. > > The firs OCSP request will be in time t0 when certificate SerNum1 is not issued. > > You propose OCSP response revoked where: > Extensions: id-pkix-ocsp-extended-revoke > Revocation Reasons: certificateHold > Revocation Time: 1.1.1970 00:00:00 UTC > > Then certificate will be issued in time t1 and revoked in time t2 in CRL. > > OCSP request will be created in time t3 and according to definition? > the revocation date shall be the date the certificate was placed on hold? > the revocation time will be? what a problem is because two > interpretations exist. Really, why do you ask at all?? For a certificate that _exists_, and that is put onHold by the CA, the CA will know pretty damn well when it asserted that onHold, and it will very very very probably publish exactly that date on a CRL or delta CRL along with the onHold status. Whether and when the OCSP responder conveyed "notIssued" in an OCSP response using the onHold ReasonCode is invisible and irrelevant to the certificate status information maintained by the CA, so there can not possibly arise any confusion. When the CA publishes a certificate revocation status for a certificate that it has issued, the information conveyed through CRLs and the information conveyed through OCSP ought to remain consistent. What the rfc2560bis update changes is only the incorrectly asserted "good" status for cert serials that do not appear on the CA cert issue record. > > Is OCSP based on CRL or not? It will be a local decision of the OCSP responder whether it feeds on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue records or on CA cert issue+status records alone, or on any other combination of certificate status information sources it sees fit. This is called "implementation freedom", something that will be obvious to anyone with implementation experience. > > For that reason I propose to use in this situation OCSP responder > error message malformedRequest. That doesn't compute for the reason that have be regurgitated several times on this list. > > For example for clause 7.4 Repudiation of a digital signing > (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely > problematic when certificateHold is used because transactions > created in each time when the certificate was in certificateHold > must not be accepted. Transactions created with a keypair where the cert serial is unknown to the CA that is alleged to have issued that cert is EVEN MORE problematic, do you realize that? Because it is not unlikely that not only the CA doesn't know about this cert, but also that the subject asserted by that cert does not know about that cert (that is regular the intent of fraudulent certs), and it will be in the very best interest of the RP, in the very best interest of the CA and in the very best interest of a subject asserted by a fraudulently issued cert if the transaction is not accepted. THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT! Gosh, I feel like I'm talking to Eliza. Continuing to return "good" status for a potentially fraudulent cert, which the CA does not have on its record log for whatever reason, would be squarely against the interest of RP, CA and asserted subject, so continuing to do so would be gross negligent. > > Also for that reason the certificateHold is forbidden in some systems > or legislations. While it is true that a lot of politician/legislators are pretty clueless about technology, But I see it happen just as often that technical guys are clueless about understanding legislation. Legislation normally legislates duties of legal entities (e.g. Party A must do A and must not do B). and not try to legislate bits (such as: it is prohibited for bit 7 of PDU A field B to have a value of 1. On violation of this rule, bit 7 will face a prison term of up to 5 years for gross negligent values of 1 and a /dev/null penalty for wilful values of 1). Unless a specific legislation is completely and thoroughly goofed (which happens rarely), positively confirming the use a cert (serial) for use in a transaction for which a CA is fully aware that it has no proof of issuance (and therefore does not even know whose identity that cert asserts), will be a much more severe act of gross negligence and potentially make that CA an accomplice in fraud, than resorting to a safety measure by asserting certificateHold in the OCSP response. I don't know how legislation works in other countries, but in Germany, in order to become liable, there either needs to be gross negligence or intent to cause harm. In the above situation, the emergency reaction to return certificateHold in the OCSP response is evidently neither of gross negligence nor harm, so there is not going to be a problem. Aren't there QES specs that require the use of an explicit proof-of-existence certificate hash conveyed in an OCSP extension of an OCSP "good" response, specifically to accomodate the well-known shortcoming of base OCSP not being able to convey "not issued"? > > It creates additional complexity where each CRL must be analyzed to have > the complete time line in which date/time and how long the certificate > was in the certificateHold state because the certificate can be in > certificateHold state several times. I don't have the slightest clue what you mean, but it has certainly nothing to do whatsoever with conveying certificateHold for "not issued" certs. When your OCSP responder computes its responses from CRLs, then there is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are listed on CRLs in copying the CRLEntry contents into the OCSP response. So there is exactly ZERO additional complexity for processing CRLs. -Martin From piyush@ditenity.com Tue Jan 15 09:51: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 3889D21F8703 for ; Tue, 15 Jan 2013 09:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 NOZTo0sf3E9R for ; Tue, 15 Jan 2013 09:51:49 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id C90C621F86F0 for ; Tue, 15 Jan 2013 09:51:47 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so402869obb.40 for ; Tue, 15 Jan 2013 09:51:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=pds+wPnO5CtbljzBBJcbhgsQ0VrmIWWdhdgOVdfrGC0=; b=LgHkm5Ba0sUJLAfAfkwX30Hd4MVzc4awDqBRHVnqIxAioRVYcCruyCC/F0pBWhpR2Z gHJbDaQfQlIYABpfdC+IYc9FuT473iRT2yp+0ikmOC8RWk6CXmtLDsH0GBdgFPbvniy8 jasnJm2ePbX/WSQmTrpCxdvI3FJVmUfgwhOW5135Pmhxzy3vd/gq5CT3E9x31VT3qlWq 8bwMfr6dehOJjK8Mv45Zb7cCs3FzGARt7Eh3Jwdz9JMnFsCaB/xhUifxNQTuUD6wl2FZ x5yTiChjHJjBSUdRQQ9CkxGNV+dM3uw0/exFYTMNwXI3nEwAq5gpsCZX5zJ+vmhznRxn MjgQ== X-Received: by 10.60.32.235 with SMTP id m11mr57502552oei.129.1358272307184; Tue, 15 Jan 2013 09:51:47 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id 7sm13537198obu.4.2013.01.15.09.51.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 09:51:46 -0800 (PST) From: "Piyush Jain" To: Date: Tue, 15 Jan 2013 09:51:41 -0800 Message-ID: <043e01cdf348$fac17630$f0446290$@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: Ac3zR3mDrrKsbB83QC2EYlZZyBjRTA== Content-Language: en-us X-Gm-Message-State: ALoCoQkF/j8mr0gdkvguXutFq4XHhiz8wCu+waEMoC+0WkkXHAqfcK5GXkHn/QVdVz7x2uLjkf0m Subject: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate 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, 15 Jan 2013 17:51:50 -0000 Hi list, Here is the scenario. -A certificate with serial number n is signed using the CA private key and records of issuance are deleted from the database (RA/CA compromise or loss of issuance records) - CA issues another certificate with serial number n. -Piyush From prvs=0728d17867=rybar@nbusr.sk Wed Jan 16 00:33: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 994C721F85DF for ; Wed, 16 Jan 2013 00:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eLdbB7WSxWI for ; Wed, 16 Jan 2013 00:33:25 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id A955921F8512 for ; Wed, 16 Jan 2013 00:33:24 -0800 (PST) Message-Id: <201301160833.r0G8XKkY084968@mail.nbusr.sk> From: "Peter Rybar" To: mrex@sap.com Date: Wed, 16 Jan 2013 09:33:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20130115174845.91A6D1A45A@ld9781.wdf.sap.corp> Thread-Index: Ac3zSJguq28nkJcgT9CSKOzpKrQeuwAcpjdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4462> : streams <890276> : uri <1320098> Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 16 Jan 2013 08:33:26 -0000 Martin, Stefan, If the main case is to provide the final status for the OCSP client, = where the client will not subsequently try to use a CRL, then you must = also expect that the initial rules were checked and are valid. The initial rules: 1. X.509 is based on PKI and all objects are protected by PKI and the = first step is to check the signature of the object.=20 2. When the signature of the object is valid, only after that check the = fields of the object must be used as an input in other conditions which = can be checked. In the OCSP case where CertID {issuerKeyHash, issuerNameHash, = serialNumber} is created and used: 1. The OCSP client will use a public key of the CA to check the = signature of the certificate whose status need to be checked.=20 2. When the signature is valid, the client creates "issuerKeyHash". 3. The OCSP client will check the issuer name field of the certificate = whose status need to be checked. 4. When issuer names are identical, the client creates "issuerNameHash". 5. The OCSP client will use a serial number from the certificate whose = status need to be checked and will be created CertID {issuerKeyHash, = issuerNameHash, serialNumber} and OCSP REQUES. As you can see, the present protocol is clear that random cert serial = number must not be used. There is only the case when CA key is used as = correct CA key or as compromised CA key. For that reason the status REVOKED must be used only for issued (signed) = certificates in the OCSP and also in CRL. Including non-issued certificates in OCSP responses means ignoring PKI = and mixing some another part of protocols like some trustworthy = out-of-band procedure with procedure based on PKI. Peter Rybar -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, January 15, 2013 6:49 PM To: Peter Rybar Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix' Subject: Re: [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients Peter Rybar wrote: >=20 > Probably you have missed my argument that CRLReason of certificateHold > is defined only in ITU-T X.509 Huh? You should get yourself a new copy of rfc5280 http://tools.ietf.org/html/rfc5280 if your's is missing certificateHold(6) CRLReason in the reasonCode extension. > > and logical semantics specified for CRL and delta CRL when > certificateHold is used is problematic for the usage > in OCSP That is non-sensical. This update does not create CRLs or delta CRLs, so the semantics of CRLs and deltaCRLs is irrelevant (for this update). Even then, any existing OCSP responder that feeds on URL will have to sensibly deal with this reason code when processing CRLs and delta CRLs, even without this update, so there is nothing about this complexity that you could blame onto the propsed update. > > where request/response can be created several times in > unspecified time/date. The semantics of the certificateHold ReasonCode for the "not-issued" situation is clear and well-defined. But what you appear to totally ignore is the problem of permanent revocation status. An RP may cache any OCSP response with a permanent revocation status FOREVER, entirely ignoring the nextUpdate field, because that is exactly what a permant revocation status implies. Therefore we MUST ABSOLUTELY avoid to convey a revoked status that an RP might consider a permanent revocation status! >=20 > The usage of certificateHold as you have proposed is confusing Nope, the X.509 semantics of certificateHold that, which we want to use, is crystal clear in 8.5.2.2 (a): the hold status may remain with no further action, causing users to reject transactions issued during the hold period (the words "on the CRL" removed, since this is about the semantics of revocationReason within the OCSP SingleResponse, not the semantics of ReasonCode within a CrlEntryExtension). > > and for that reason I was proposing another solution where is > addressed the problem of issued certificate by CA without evidence in = CA.=20 > Because the sentence "revoked response for non-issued certificates" > is vague when it is only about wrong serial number and the certificate > does not exists at application creating OCSP request. As I've previously described, the certificate that the RP is holding is entirely irrelevant to the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients seem to never include the (optional) certificate in OCSP requests. > > It is absurd situations and OCSP responder must react with an error > message on such absurd request because that is not situation about > the certificate status, that is wrong request which is only about > the integer number. > OCSP is Online Certificate Status Protocol. rfc2560, and how it is used by the installed base, is provably about Certificate Serial Status, not about Certificate status. Some RPs may boldly infer Certificate status from Certificate Serial Status, but that is an inference from the OCSP response, not a function of the OCSP protocol the way it is used by common OCSP clients. There is no such thing as an absurd situation for the OCSP responder when looking up a cert serial from the CA cert issue records. Either an issue record will be found (likely returning a certificate hash along with the status that the serial was found), or no issue record will be found. These are two well-defined, easily distinguishable lookup results that can be trivially converted into determinstic OCSP responder = behaviour with clear and obvious semantics. > > It is not partial status about one or two component of the CertID! > ( serialNumber or issuerNameHash or issuerKeyHash ) I'm sorry, this statement non-sensical. issuerNameHash and isserKeyHash refer to the CA cert, and as you can see from the ASN.1 definition, they are non-optional -- these two values MUST always be compared, and if they don't match, the result MUST be an "unknown" OCSP response. The serialNumber is the parameter that refers to the certificate. And in order to determine the certificate status this value MUST be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request or CA cert issue records. So there can not be such thing as a partial status or a partial match. > =20 > When OCSP has access to the CA database, what is the case defined > in rfc2560bis for "revoked response for non-issued certificates", > then the error message is right response,=20 This is also a non-sensical statement. An error message has the = semantics "this information source is unable to provide cert status information", which would non only a pretty stupid response for any authoritative OCSP to return when that OCSP responder known pretty damn well that this cert serial does not exist on the CA cert issue records, and when two extremely common types of behaviours of RPs in the installed base for an "unknown" response from an authoritative OCSP responder are (1) fail soft and accept the cert or (2) fallback to CRL checking, where the revocation check is bound to return status "good", because it is impossible to detect the "not-issued" with CRLs. Bottom line, while returning "good" is permitted by rfc2560 in absence of the capability to detect "not issued", and will result in the same behaviour as the OCSP client soft failing or falling back to CRL = checking, returning unknwon would be a pretty dumb response for an authoritative OCSP responder which *KNOWS* the status of the requested cert serial. >=20 > Another argument why revocation with reason code certificateHold is = problematic:=20 >=20 > ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)=20 >=20 > 8.5.2.2 Reason code extension >=20 > Once a hold has been issued, it may be handled in one of three ways:=20 >=20 > b) it may be replaced by a (final) revocation for the same = certificate, > in which case the reason shall be one of the standard reasons for > revocation, the revocation date shall be the date the certificate was > placed on hold, and the optional instruction code extension field > shall not appear; or,, You seem to be totally confused (or exhibit problems in understanding = X.509) We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update. 8.5.2.2 (b) obviously does not apply to a cert serial that has "not issued" status. "not issued" is a temporary status until (if ever) a real cert with that serial gets issued. Once a real cert with that serial has been issued, OCSP requests for this cert serial will return the status of this real cert from the CA issue records, and no longer report "not issued". >=20 > According to ?the revocation date shall be the date the certificate > was placed on hold? and according to usage of OCSP: Since there _exists_ no certiticte when certificateHold conveys the "not issued" status, this rule can obviously not apply, because there is no information source from which any "placedOnHoldTime" could be copied into the OCSP response. Consequently, the value to place in revocationTime for "not issued" is defined in 2560bis -- that should be intuitively apparent. >=20 > The firs OCSP request will be in time t0 when certificate SerNum1 is = not issued. >=20 > You propose OCSP response revoked where: > Extensions: id-pkix-ocsp-extended-revoke > Revocation Reasons: certificateHold > Revocation Time: 1.1.1970 00:00:00 UTC >=20 > Then certificate will be issued in time t1 and revoked in time t2 in = CRL. >=20 > OCSP request will be created in time t3 and according to definition? > the revocation date shall be the date the certificate was placed on = hold? > the revocation time will be? what a problem is because two > interpretations exist. Really, why do you ask at all?? For a certificate that _exists_, and that is put onHold by the CA, the CA will know pretty damn well when it asserted that onHold, and it will very very very probably publish exactly that date on a CRL or delta CRL along with the onHold status. Whether and when the OCSP responder conveyed "notIssued" in an OCSP = response using the onHold ReasonCode is invisible and irrelevant to the = certificate status information maintained by the CA, so there can not possibly arise any confusion. When the CA publishes a certificate revocation status for a certificate that it has issued, the information conveyed through CRLs and the information conveyed through OCSP ought to remain = consistent. What the rfc2560bis update changes is only the incorrectly asserted = "good" status for cert serials that do not appear on the CA cert issue record. >=20 > Is OCSP based on CRL or not?=20 It will be a local decision of the OCSP responder whether it feeds on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue = records or on CA cert issue+status records alone, or on any other combination of certificate status information sources it sees fit. This is called "implementation freedom", something that will be obvious to anyone with implementation experience. >=20 > For that reason I propose to use in this situation OCSP responder > error message malformedRequest. That doesn't compute for the reason that have be regurgitated several times on this list. >=20 > For example for clause 7.4 Repudiation of a digital signing > (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely > problematic when certificateHold is used because transactions > created in each time when the certificate was in certificateHold > must not be accepted. Transactions created with a keypair where the cert serial is unknown to the CA that is alleged to have issued that cert is EVEN MORE = problematic, do you realize that? Because it is not unlikely that not only the CA doesn't know about this cert, but also that the subject asserted by that cert does not know about that cert (that is regular the intent of fraudulent certs), and it will be in the very best interest of the RP, in the very best interest of the CA and in the very best interest of a subject asserted by a fraudulently issued cert if the transaction is not accepted. THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT! Gosh, I feel like I'm talking to Eliza. Continuing to return "good" status for a potentially fraudulent cert, which the CA does not have on its record log for whatever reason, would be squarely against the interest of RP, CA and asserted subject, so continuing to do so would be gross negligent. >=20 > Also for that reason the certificateHold is forbidden in some systems > or legislations. While it is true that a lot of politician/legislators are pretty clueless about technology, But I see it happen just as often that technical guys are clueless about understanding legislation. Legislation normally legislates duties of legal entities (e.g. Party A must do A and must not do B). and not try to legislate bits (such as: it is prohibited for bit 7 of PDU A field B to have a value of 1. On violation of this rule, bit 7 will face a prison term of up to 5 years for gross negligent values of 1 and a /dev/null penalty for wilful values of 1). Unless a specific legislation is completely and thoroughly goofed (which happens rarely), positively confirming the use a cert (serial) for use in a transaction for which a CA is fully aware that it has no proof of issuance (and therefore does not even know whose identity that cert asserts), will be a much more severe act of gross negligence and potentially make that CA an accomplice in fraud, than resorting to a safety measure by asserting certificateHold in the OCSP response. I don't know how legislation works in other countries, but in Germany, in order to become liable, there either needs to be gross negligence or intent to cause harm. In the above situation, the emergency reaction to return certificateHold in the OCSP response is evidently neither of gross negligence nor harm, so there is not going to be a problem. Aren't there QES specs that require the use of an explicit proof-of-existence certificate hash conveyed in an OCSP extension of an OCSP "good" response, specifically to accomodate the well-known shortcoming of base OCSP not being able to convey "not issued"? >=20 > It creates additional complexity where each CRL must be analyzed to = have > the complete time line in which date/time and how long the certificate > was in the certificateHold state because the certificate can be in > certificateHold state several times. I don't have the slightest clue what you mean, but it has certainly nothing to do whatsoever with conveying certificateHold for "not issued" certs. When your OCSP responder computes its responses from CRLs, then there is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are listed on CRLs in copying the CRLEntry contents into the OCSP response. So there is exactly ZERO additional complexity for processing CRLs. -Martin From denis.pinkas@bull.net Wed Jan 16 01:00: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 0014121F86DD for ; Wed, 16 Jan 2013 01:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.476 X-Spam-Level: X-Spam-Status: No, score=-5.476 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_56=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 rW64-+9TlvQE for ; Wed, 16 Jan 2013 01:00:30 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id EDE9D21F86CE for ; Wed, 16 Jan 2013 01:00:29 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 367B31D003; Wed, 16 Jan 2013 10:00:29 +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 2013011610002823-20581 ; Wed, 16 Jan 2013 10:00:28 +0100 Message-ID: <50F66C29.30901@bull.net> Date: Wed, 16 Jan 2013 10:00:25 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Rybar References: <201301160833.r0G8XKkY084968@mail.nbusr.sk> In-Reply-To: <201301160833.r0G8XKkY084968@mail.nbusr.sk> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 16/01/2013 10:00:28, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 16/01/2013 10:00:29, Serialize complete at 16/01/2013 10:00:29 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 16 Jan 2013 09:00:32 -0000 Peter, From a protocol point of view, an OCSP responder may not rely on any check made by an OCSP client. So an OCSP responder MUST be ready to receive requests that contain any value (good or bad), including : - a random serial number, - a malformed ASN.1 request, - etc .... Martin gave you yesterday an extensive response that is fully correct. Your arguments are leading nowhere. Please do not waste our time. Denis > Martin, Stefan, > > If the main case is to provide the final status for the OCSP client, where the client will not subsequently try to use a CRL, then you must also expect that the initial rules were checked and are valid. > > The initial rules: > 1. X.509 is based on PKI and all objects are protected by PKI and the first step is to check the signature of the object. > 2. When the signature of the object is valid, only after that check the fields of the object must be used as an input in other conditions which can be checked. > > In the OCSP case where CertID {issuerKeyHash, issuerNameHash, serialNumber} is created and used: > > 1. The OCSP client will use a public key of the CA to check the signature of the certificate whose status need to be checked. > 2. When the signature is valid, the client creates "issuerKeyHash". > 3. The OCSP client will check the issuer name field of the certificate whose status need to be checked. > 4. When issuer names are identical, the client creates "issuerNameHash". > 5. The OCSP client will use a serial number from the certificate whose status need to be checked and will be created CertID {issuerKeyHash, issuerNameHash, serialNumber} and OCSP REQUES. > > As you can see, the present protocol is clear that random cert serial number must not be used. There is only the case when CA key is used as correct CA key or as compromised CA key. > > For that reason the status REVOKED must be used only for issued (signed) certificates in the OCSP and also in CRL. > > Including non-issued certificates in OCSP responses means ignoring PKI and mixing some another part of protocols like some trustworthy out-of-band procedure with procedure based on PKI. > > Peter Rybar > > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, January 15, 2013 6:49 PM > To: Peter Rybar > Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > > Peter Rybar wrote: >> Probably you have missed my argument that CRLReason of certificateHold >> is defined only in ITU-T X.509 > Huh? You should get yourself a new copy of rfc5280 > > http://tools.ietf.org/html/rfc5280 > > if your's is missing certificateHold(6) CRLReason in the reasonCode > extension. > > >> and logical semantics specified for CRL and delta CRL when >> certificateHold is used is problematic for the usage >> in OCSP > That is non-sensical. This update does not create CRLs or delta CRLs, > so the semantics of CRLs and deltaCRLs is irrelevant (for this update). > > Even then, any existing OCSP responder that feeds on URL will have to > sensibly deal with this reason code when processing CRLs and delta CRLs, > even without this update, so there is nothing about this complexity > that you could blame onto the propsed update. > > >> where request/response can be created several times in >> unspecified time/date. > The semantics of the certificateHold ReasonCode for the "not-issued" > situation is clear and well-defined. > > But what you appear to totally ignore is the problem of permanent > revocation status. An RP may cache any OCSP response with a permanent > revocation status FOREVER, entirely ignoring the nextUpdate field, > because that is exactly what a permant revocation status implies. > Therefore we MUST ABSOLUTELY avoid to convey a revoked status > that an RP might consider a permanent revocation status! > > >> The usage of certificateHold as you have proposed is confusing > Nope, the X.509 semantics of certificateHold that, which we want to use, > is crystal clear in 8.5.2.2 (a): > > the hold status may remain with no further action, causing users > to reject transactions issued during the hold period > > (the words "on the CRL" removed, since this is about the semantics of > revocationReason within the OCSP SingleResponse, not the semantics > of ReasonCode within a CrlEntryExtension). > >> and for that reason I was proposing another solution where is >> addressed the problem of issued certificate by CA without evidence in CA. >> Because the sentence "revoked response for non-issued certificates" >> is vague when it is only about wrong serial number and the certificate >> does not exists at application creating OCSP request. > As I've previously described, > > the certificate that the RP is holding is entirely irrelevant to > the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients > seem to never include the (optional) certificate in OCSP requests. > > >> It is absurd situations and OCSP responder must react with an error >> message on such absurd request because that is not situation about >> the certificate status, that is wrong request which is only about >> the integer number. >> OCSP is Online Certificate Status Protocol. > rfc2560, and how it is used by the installed base, is provably > about Certificate Serial Status, not about Certificate status. > Some RPs may boldly infer Certificate status from Certificate Serial > Status, but that is an inference from the OCSP response, not a function > of the OCSP protocol the way it is used by common OCSP clients. > > There is no such thing as an absurd situation for the OCSP responder > when looking up a cert serial from the CA cert issue records. Either > an issue record will be found (likely returning a certificate hash > along with the status that the serial was found), or no issue record > will be found. > > These are two well-defined, easily distinguishable lookup results > that can be trivially converted into determinstic OCSP responder behaviour > with clear and obvious semantics. > > >> It is not partial status about one or two component of the CertID! >> ( serialNumber or issuerNameHash or issuerKeyHash ) > I'm sorry, this statement non-sensical. > > issuerNameHash and isserKeyHash refer to the CA cert, and as you > can see from the ASN.1 definition, they are non-optional -- these > two values MUST always be compared, and if they don't match, the > result MUST be an "unknown" OCSP response. > > The serialNumber is the parameter that refers to the certificate. > And in order to determine the certificate status this value MUST > be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request > or CA cert issue records. > > So there can not be such thing as a partial status or a partial match. > > >> >> When OCSP has access to the CA database, what is the case defined >> in rfc2560bis for "revoked response for non-issued certificates", >> then the error message is right response, > This is also a non-sensical statement. An error message has the semantics > "this information source is unable to provide cert status information", > which would non only a pretty stupid response for any authoritative > OCSP to return when that OCSP responder known pretty damn well that > this cert serial does not exist on the CA cert issue records, and > when two extremely common types of behaviours of RPs in the installed > base for an "unknown" response from an authoritative OCSP responder > are (1) fail soft and accept the cert or (2) fallback to CRL checking, > where the revocation check is bound to return status "good", because > it is impossible to detect the "not-issued" with CRLs. > > Bottom line, while returning "good" is permitted by rfc2560 in absence > of the capability to detect "not issued", and will result in the same > behaviour as the OCSP client soft failing or falling back to CRL checking, > returning unknwon would be a pretty dumb response for an authoritative > OCSP responder which *KNOWS* the status of the requested cert serial. > > >> Another argument why revocation with reason code certificateHold is problematic: >> >> ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) >> >> 8.5.2.2 Reason code extension >> >> Once a hold has been issued, it may be handled in one of three ways: >> >> b) it may be replaced by a (final) revocation for the same certificate, >> in which case the reason shall be one of the standard reasons for >> revocation, the revocation date shall be the date the certificate was >> placed on hold, and the optional instruction code extension field >> shall not appear; or,, > You seem to be totally confused (or exhibit problems in understanding X.509) > > We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update. > > 8.5.2.2 (b) obviously does not apply to a cert serial that has > "not issued" status. > "not issued" is a temporary status until (if ever) a real cert with that > serial gets issued. Once a real cert with that serial has been issued, > OCSP requests for this cert serial will return the status of this real > cert from the CA issue records, and no longer report "not issued". > > >> According to ?the revocation date shall be the date the certificate >> was placed on hold? and according to usage of OCSP: > Since there _exists_ no certiticte when certificateHold conveys the > "not issued" status, this rule can obviously not apply, because there > is no information source from which any "placedOnHoldTime" could > be copied into the OCSP response. > > Consequently, the value to place in revocationTime for "not issued" > is defined in 2560bis -- that should be intuitively apparent. > >> The firs OCSP request will be in time t0 when certificate SerNum1 is not issued. >> >> You propose OCSP response revoked where: >> Extensions: id-pkix-ocsp-extended-revoke >> Revocation Reasons: certificateHold >> Revocation Time: 1.1.1970 00:00:00 UTC >> >> Then certificate will be issued in time t1 and revoked in time t2 in CRL. >> >> OCSP request will be created in time t3 and according to definition? >> the revocation date shall be the date the certificate was placed on hold? >> the revocation time will be? what a problem is because two >> interpretations exist. > Really, why do you ask at all?? > > For a certificate that _exists_, and that is put onHold by the CA, > the CA will know pretty damn well when it asserted that onHold, > and it will very very very probably publish exactly that date on > a CRL or delta CRL along with the onHold status. > > Whether and when the OCSP responder conveyed "notIssued" in an OCSP response > using the onHold ReasonCode is invisible and irrelevant to the certificate > status information maintained by the CA, so there can not possibly arise > any confusion. When the CA publishes a certificate revocation status > for a certificate that it has issued, the information conveyed through > CRLs and the information conveyed through OCSP ought to remain consistent. > > What the rfc2560bis update changes is only the incorrectly asserted "good" > status for cert serials that do not appear on the CA cert issue record. > > >> Is OCSP based on CRL or not? > It will be a local decision of the OCSP responder whether it feeds > on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue records > or on CA cert issue+status records alone, or on any other combination > of certificate status information sources it sees fit. > > This is called "implementation freedom", something that will be > obvious to anyone with implementation experience. > > >> For that reason I propose to use in this situation OCSP responder >> error message malformedRequest. > That doesn't compute for the reason that have be regurgitated > several times on this list. > > >> For example for clause 7.4 Repudiation of a digital signing >> (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely >> problematic when certificateHold is used because transactions >> created in each time when the certificate was in certificateHold >> must not be accepted. > > Transactions created with a keypair where the cert serial is unknown > to the CA that is alleged to have issued that cert is EVEN MORE problematic, > do you realize that? Because it is not unlikely that not only the > CA doesn't know about this cert, but also that the subject asserted > by that cert does not know about that cert (that is regular the intent > of fraudulent certs), and it will be in the very best interest of > the RP, in the very best interest of the CA and in the very best > interest of a subject asserted by a fraudulently issued cert > if the transaction is not accepted. > > THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT! > > Gosh, I feel like I'm talking to Eliza. > > Continuing to return "good" status for a potentially fraudulent cert, > which the CA does not have on its record log for whatever reason, > would be squarely against the interest of RP, CA and asserted subject, > so continuing to do so would be gross negligent. > > > >> Also for that reason the certificateHold is forbidden in some systems >> or legislations. > While it is true that a lot of politician/legislators are pretty > clueless about technology, But I see it happen just as often > that technical guys are clueless about understanding legislation. > > Legislation normally legislates duties of legal entities > (e.g. Party A must do A and must not do B). > and not try to legislate bits (such as: it is prohibited for bit 7 > of PDU A field B to have a value of 1. On violation of this rule, > bit 7 will face a prison term of up to 5 years for gross negligent > values of 1 and a /dev/null penalty for wilful values of 1). > > Unless a specific legislation is completely and thoroughly goofed > (which happens rarely), positively confirming the use a cert (serial) > for use in a transaction for which a CA is fully aware that it has > no proof of issuance (and therefore does not even know whose identity > that cert asserts), will be a much more severe act of gross negligence > and potentially make that CA an accomplice in fraud, than resorting > to a safety measure by asserting certificateHold in the OCSP response. > > I don't know how legislation works in other countries, but in > Germany, in order to become liable, there either needs to be > gross negligence or intent to cause harm. In the above situation, > the emergency reaction to return certificateHold in the OCSP response > is evidently neither of gross negligence nor harm, so there is not > going to be a problem. > > Aren't there QES specs that require the use of an explicit > proof-of-existence certificate hash conveyed in an OCSP extension > of an OCSP "good" response, specifically to accomodate the well-known > shortcoming of base OCSP not being able to convey "not issued"? > > > >> It creates additional complexity where each CRL must be analyzed to have >> the complete time line in which date/time and how long the certificate >> was in the certificateHold state because the certificate can be in >> certificateHold state several times. > I don't have the slightest clue what you mean, but it has certainly > nothing to do whatsoever with conveying certificateHold for "not issued" > certs. > > When your OCSP responder computes its responses from CRLs, then there > is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are > listed on CRLs in copying the CRLEntry contents into the OCSP response. > So there is exactly ZERO additional complexity for processing CRLs. > > > -Martin > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From prvs=0728d17867=rybar@nbusr.sk Wed Jan 16 08:59:03 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 9DAC221F8B0B for ; Wed, 16 Jan 2013 08:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPAXXgXzyFCk for ; Wed, 16 Jan 2013 08:59:02 -0800 (PST) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF221F8941 for ; Wed, 16 Jan 2013 08:59:01 -0800 (PST) Message-Id: <201301161658.r0GGwvbn087194@mail.nbusr.sk> From: "Peter Rybar" To: "'Denis Pinkas'" Date: Wed, 16 Jan 2013 17:59:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <50F66C29.30901@bull.net> Thread-Index: Ac3zx+8n7ifcF6GuST6R3FPbu4kzAAAGdOIA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4463> : streams <890345> : uri <1320374> Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 16 Jan 2013 16:59:03 -0000 Denis, I agree that Martin's and Stefan's description and also the last = Martin's mail contains clear information what they intend by it to fix. But when you look at it from the practical side the usage of revoked = status for the "not-issued" / "not used serial number by CA" is only = encapsulation of *UNKNOWN* result into the *REVOKED* result. So, I agree with you Denis, but from another side that such solution = where the status revoked is used as a carrier of UNKNOWN status leading = nowhere and its implementation only waste implementer's time. Can you create practical examples of statuses and how it is expected = that clients and CAs will use it? The mistake is in the precondition that responder *KNOWS* the status. Because authoritative OCSP responder with access to the CA database has = not e.g. information about the certificate issued by CA, e.g. record in = database was deleted or was not created. Proposed OCSP response: By Martin and Stefan Signed status Revoked,=20 Revocation Reasons: certificateHold,=20 Extensions: id-pkix-ocsp-extended-revoke Revocation Time: 1.1.1970 00:00:00 UTC Consequence:=20 It is not permanent status and can be changed but special rules must be = used. 1. Correct certificate, but without record in OCSP database will be = permanently revoked by rfc2560bis applications because in rfc2560bis is = not defined mechanism how it can be reported and corrected on CA/OCSP = side. When in this time it will be requested to be revoked e.g. as a = keyCompromise where user will provide all registration documentation to = the CA... the HOLD status will be changed to the real status but must be = used special logical rules for the time of revocation and not rules = defined for certificateHold in X.509/RFC.=20 (Client and RP applications were correctly using certificate for long = time with CRL checking as valid and only once when rfc2560bis OCSP = responder was used some unclear situation happened so client recommend = to RP to use only CRL :o) :-) ;) 2. Incorrect serial number of non existing certificate. It is unknown = case where it can be useful - probably as attacks e.g. consuming system = time for signing responses. =20 Proposed OCSP response: By Denis Signed status Revoked,=20 Revocation Reasons: notIssuedOrIrregularlyIssued,=20 Revocation Time: 1.1.1970 00:00:00 UTC Consequence: It is a permanent status according to actual definition where only = certificateHold can be changed. It is unclear what it will causes in applications in which is not = implemented proposed bit in revocation reason. Probably Stefan was = pointing on it to avoid such situations. My proposal (updated by comments of Martin and Denis) of OCSP response: For QES the positive statement certHash of the certificate must be used = for a good and revoked status. When the positive statement certHash of the certificate is not included = in the responder database, then the OCSP Responder must return an error = message noIssueRecordFound. Client applications if recognize the error message noIssueRecordFound = can create another OCSP request where will be included requested = certificate in =20 singleRequestExtensions extensin identified by OID = id-pkix-ocsp-CertOfNoIssueRecordFound. According to it OCSP responder or CA will be able to solve the problems = with probably CA Database inconsistency or CA Key compromise. The following OCSP response can be signed with positive statement = certHash tryLater while CA makes a decision or OCSP Responder can return = an error message malformedRequest when CertID does not correspond to = certificate in id-pkix-ocsp-CertOfNoIssueRecordFound or signed response = unknown (what is the same as revoked with reason certificateHold, = extensions id-pkix-ocsp-extended-revoke because client have no hint, = provided by OCSP, what to do with it). The extension included in singleRequestExtensions and identified by = OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound contains = certificate for which the status in OCSP request is requested. OCSPResponseStatus ::=3D ENUMERATED { successful (0), --Response has valid confirmations malformedRequest (1), --Illegal confirmation request internalError (2), --Internal error in issuer tryLater (3), --Try again later --(4) is not used sigRequired (5), --Must sign the request unauthorized (6), --Request unauthorized noIssueRecordFound (7) -- probably CA Database inconsistency=20 -- or CA Key compromise } Peter Rybar -----Original Message----- From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 Sent: Wednesday, January 16, 2013 10:00 AM To: Peter Rybar Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients Peter, From a protocol point of view, an OCSP responder may not rely on any=20 check made by an OCSP client. So an OCSP responder MUST be ready to receive requests that contain any=20 value (good or bad), including : - a random serial number, - a malformed ASN.1 request, - etc .... Martin gave you yesterday an extensive response that is fully correct. Your arguments are leading nowhere. Please do not waste our time. Denis > Martin, Stefan, > > If the main case is to provide the final status for the OCSP client, = where the client will not subsequently try to use a CRL, then you must = also expect that the initial rules were checked and are valid. > > The initial rules: > 1. X.509 is based on PKI and all objects are protected by PKI and the = first step is to check the signature of the object. > 2. When the signature of the object is valid, only after that check = the fields of the object must be used as an input in other conditions = which can be checked. > > In the OCSP case where CertID {issuerKeyHash, issuerNameHash, = serialNumber} is created and used: > > 1. The OCSP client will use a public key of the CA to check the = signature of the certificate whose status need to be checked. > 2. When the signature is valid, the client creates "issuerKeyHash". > 3. The OCSP client will check the issuer name field of the certificate = whose status need to be checked. > 4. When issuer names are identical, the client creates = "issuerNameHash". > 5. The OCSP client will use a serial number from the certificate whose = status need to be checked and will be created CertID {issuerKeyHash, = issuerNameHash, serialNumber} and OCSP REQUES. > > As you can see, the present protocol is clear that random cert serial = number must not be used. There is only the case when CA key is used as = correct CA key or as compromised CA key. > > For that reason the status REVOKED must be used only for issued = (signed) certificates in the OCSP and also in CRL. > > Including non-issued certificates in OCSP responses means ignoring PKI = and mixing some another part of protocols like some trustworthy = out-of-band procedure with procedure based on PKI. > > Peter Rybar > > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, January 15, 2013 6:49 PM > To: Peter Rybar > Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix' > Subject: Re: [pkix] Solution with singleRequestExtensions = CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > > Peter Rybar wrote: >> Probably you have missed my argument that CRLReason of = certificateHold >> is defined only in ITU-T X.509 > Huh? You should get yourself a new copy of rfc5280 > > http://tools.ietf.org/html/rfc5280 > > if your's is missing certificateHold(6) CRLReason in the reasonCode > extension. > > >> and logical semantics specified for CRL and delta CRL when >> certificateHold is used is problematic for the usage >> in OCSP > That is non-sensical. This update does not create CRLs or delta CRLs, > so the semantics of CRLs and deltaCRLs is irrelevant (for this = update). > > Even then, any existing OCSP responder that feeds on URL will have to > sensibly deal with this reason code when processing CRLs and delta = CRLs, > even without this update, so there is nothing about this complexity > that you could blame onto the propsed update. > > >> where request/response can be created several times in >> unspecified time/date. > The semantics of the certificateHold ReasonCode for the "not-issued" > situation is clear and well-defined. > > But what you appear to totally ignore is the problem of permanent > revocation status. An RP may cache any OCSP response with a permanent > revocation status FOREVER, entirely ignoring the nextUpdate field, > because that is exactly what a permant revocation status implies. > Therefore we MUST ABSOLUTELY avoid to convey a revoked status > that an RP might consider a permanent revocation status! > > >> The usage of certificateHold as you have proposed is confusing > Nope, the X.509 semantics of certificateHold that, which we want to = use, > is crystal clear in 8.5.2.2 (a): > > the hold status may remain with no further action, causing users > to reject transactions issued during the hold period > > (the words "on the CRL" removed, since this is about the semantics of > revocationReason within the OCSP SingleResponse, not the semantics > of ReasonCode within a CrlEntryExtension). > >> and for that reason I was proposing another solution where is >> addressed the problem of issued certificate by CA without evidence in = CA. >> Because the sentence "revoked response for non-issued certificates" >> is vague when it is only about wrong serial number and the = certificate >> does not exists at application creating OCSP request. > As I've previously described, > > the certificate that the RP is holding is entirely irrelevant to > the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients > seem to never include the (optional) certificate in OCSP requests. > > >> It is absurd situations and OCSP responder must react with an error >> message on such absurd request because that is not situation about >> the certificate status, that is wrong request which is only about >> the integer number. >> OCSP is Online Certificate Status Protocol. > rfc2560, and how it is used by the installed base, is provably > about Certificate Serial Status, not about Certificate status. > Some RPs may boldly infer Certificate status from Certificate Serial > Status, but that is an inference from the OCSP response, not a = function > of the OCSP protocol the way it is used by common OCSP clients. > > There is no such thing as an absurd situation for the OCSP responder > when looking up a cert serial from the CA cert issue records. Either > an issue record will be found (likely returning a certificate hash > along with the status that the serial was found), or no issue record > will be found. > > These are two well-defined, easily distinguishable lookup results > that can be trivially converted into determinstic OCSP responder = behaviour > with clear and obvious semantics. > > >> It is not partial status about one or two component of the CertID! >> ( serialNumber or issuerNameHash or issuerKeyHash ) > I'm sorry, this statement non-sensical. > > issuerNameHash and isserKeyHash refer to the CA cert, and as you > can see from the ASN.1 definition, they are non-optional -- these > two values MUST always be compared, and if they don't match, the > result MUST be an "unknown" OCSP response. > > The serialNumber is the parameter that refers to the certificate. > And in order to determine the certificate status this value MUST > be matched, whether sourcing from a CRL, delta CRL, proxied OCSP = request > or CA cert issue records. > > So there can not be such thing as a partial status or a partial match. > > >> =20 >> When OCSP has access to the CA database, what is the case defined >> in rfc2560bis for "revoked response for non-issued certificates", >> then the error message is right response, > This is also a non-sensical statement. An error message has the = semantics > "this information source is unable to provide cert status = information", > which would non only a pretty stupid response for any authoritative > OCSP to return when that OCSP responder known pretty damn well that > this cert serial does not exist on the CA cert issue records, and > when two extremely common types of behaviours of RPs in the installed > base for an "unknown" response from an authoritative OCSP responder > are (1) fail soft and accept the cert or (2) fallback to CRL = checking, > where the revocation check is bound to return status "good", because > it is impossible to detect the "not-issued" with CRLs. > > Bottom line, while returning "good" is permitted by rfc2560 in absence > of the capability to detect "not issued", and will result in the same > behaviour as the OCSP client soft failing or falling back to CRL = checking, > returning unknwon would be a pretty dumb response for an authoritative > OCSP responder which *KNOWS* the status of the requested cert serial. > > >> Another argument why revocation with reason code certificateHold is = problematic: >> >> ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) >> >> 8.5.2.2 Reason code extension >> >> Once a hold has been issued, it may be handled in one of three ways: >> >> b) it may be replaced by a (final) revocation for the same = certificate, >> in which case the reason shall be one of the standard reasons for >> revocation, the revocation date shall be the date the certificate was >> placed on hold, and the optional instruction code extension field >> shall not appear; or,, > You seem to be totally confused (or exhibit problems in understanding = X.509) > > We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update. > > 8.5.2.2 (b) obviously does not apply to a cert serial that has > "not issued" status. > "not issued" is a temporary status until (if ever) a real cert with = that > serial gets issued. Once a real cert with that serial has been = issued, > OCSP requests for this cert serial will return the status of this real > cert from the CA issue records, and no longer report "not issued". > > >> According to ?the revocation date shall be the date the certificate >> was placed on hold? and according to usage of OCSP: > Since there _exists_ no certiticte when certificateHold conveys the > "not issued" status, this rule can obviously not apply, because there > is no information source from which any "placedOnHoldTime" could > be copied into the OCSP response. > > Consequently, the value to place in revocationTime for "not issued" > is defined in 2560bis -- that should be intuitively apparent. > >> The firs OCSP request will be in time t0 when certificate SerNum1 is = not issued. >> >> You propose OCSP response revoked where: >> Extensions: id-pkix-ocsp-extended-revoke >> Revocation Reasons: certificateHold >> Revocation Time: 1.1.1970 00:00:00 UTC >> >> Then certificate will be issued in time t1 and revoked in time t2 in = CRL. >> >> OCSP request will be created in time t3 and according to definition? >> the revocation date shall be the date the certificate was placed on = hold? >> the revocation time will be? what a problem is because two >> interpretations exist. > Really, why do you ask at all?? > > For a certificate that _exists_, and that is put onHold by the CA, > the CA will know pretty damn well when it asserted that onHold, > and it will very very very probably publish exactly that date on > a CRL or delta CRL along with the onHold status. > > Whether and when the OCSP responder conveyed "notIssued" in an OCSP = response > using the onHold ReasonCode is invisible and irrelevant to the = certificate > status information maintained by the CA, so there can not possibly = arise > any confusion. When the CA publishes a certificate revocation status > for a certificate that it has issued, the information conveyed through > CRLs and the information conveyed through OCSP ought to remain = consistent. > > What the rfc2560bis update changes is only the incorrectly asserted = "good" > status for cert serials that do not appear on the CA cert issue = record. > > >> Is OCSP based on CRL or not? > It will be a local decision of the OCSP responder whether it feeds > on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue = records > or on CA cert issue+status records alone, or on any other combination > of certificate status information sources it sees fit. > > This is called "implementation freedom", something that will be > obvious to anyone with implementation experience. > > >> For that reason I propose to use in this situation OCSP responder >> error message malformedRequest. > That doesn't compute for the reason that have be regurgitated > several times on this list. > > >> For example for clause 7.4 Repudiation of a digital signing >> (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely >> problematic when certificateHold is used because transactions >> created in each time when the certificate was in certificateHold >> must not be accepted. > > Transactions created with a keypair where the cert serial is unknown > to the CA that is alleged to have issued that cert is EVEN MORE = problematic, > do you realize that? Because it is not unlikely that not only the > CA doesn't know about this cert, but also that the subject asserted > by that cert does not know about that cert (that is regular the intent > of fraudulent certs), and it will be in the very best interest of > the RP, in the very best interest of the CA and in the very best > interest of a subject asserted by a fraudulently issued cert > if the transaction is not accepted. > > THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT! > > Gosh, I feel like I'm talking to Eliza. > > Continuing to return "good" status for a potentially fraudulent cert, > which the CA does not have on its record log for whatever reason, > would be squarely against the interest of RP, CA and asserted subject, > so continuing to do so would be gross negligent. > > > >> Also for that reason the certificateHold is forbidden in some systems >> or legislations. > While it is true that a lot of politician/legislators are pretty > clueless about technology, But I see it happen just as often > that technical guys are clueless about understanding legislation. > > Legislation normally legislates duties of legal entities > (e.g. Party A must do A and must not do B). > and not try to legislate bits (such as: it is prohibited for bit 7 > of PDU A field B to have a value of 1. On violation of this rule, > bit 7 will face a prison term of up to 5 years for gross negligent > values of 1 and a /dev/null penalty for wilful values of 1). > > Unless a specific legislation is completely and thoroughly goofed > (which happens rarely), positively confirming the use a cert (serial) > for use in a transaction for which a CA is fully aware that it has > no proof of issuance (and therefore does not even know whose identity > that cert asserts), will be a much more severe act of gross negligence > and potentially make that CA an accomplice in fraud, than resorting > to a safety measure by asserting certificateHold in the OCSP response. > > I don't know how legislation works in other countries, but in > Germany, in order to become liable, there either needs to be > gross negligence or intent to cause harm. In the above situation, > the emergency reaction to return certificateHold in the OCSP response > is evidently neither of gross negligence nor harm, so there is not > going to be a problem. > > Aren't there QES specs that require the use of an explicit > proof-of-existence certificate hash conveyed in an OCSP extension > of an OCSP "good" response, specifically to accomodate the well-known > shortcoming of base OCSP not being able to convey "not issued"? > > > >> It creates additional complexity where each CRL must be analyzed to = have >> the complete time line in which date/time and how long the = certificate >> was in the certificateHold state because the certificate can be in >> certificateHold state several times. > I don't have the slightest clue what you mean, but it has certainly > nothing to do whatsoever with conveying certificateHold for "not = issued" > certs. > > When your OCSP responder computes its responses from CRLs, then there > is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are > listed on CRLs in copying the CRLEntry contents into the OCSP = response. > So there is exactly ZERO additional complexity for processing CRLs. > > > -Martin > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Thu Jan 17 08:40:43 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 EC68521F84A1 for ; Thu, 17 Jan 2013 08:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 BuXHXMG7PQ03 for ; Thu, 17 Jan 2013 08:40:41 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 479E521F87C6 for ; Thu, 17 Jan 2013 08:40:40 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 986731D0E5; Thu, 17 Jan 2013 17:40:38 +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 2013011717403687-25312 ; Thu, 17 Jan 2013 17:40:36 +0100 Message-ID: <50F82981.9050100@bull.net> Date: Thu, 17 Jan 2013 17:40:33 +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: Peter Rybar References: <201301161733.r0GGwvUr087193@mail.nbusr.sk> In-Reply-To: <201301161733.r0GGwvUr087193@mail.nbusr.sk> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 17/01/2013 17:40:37, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 17/01/2013 17:40:38, Serialize complete at 17/01/2013 17:40:38 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------090001050203050900070306" Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 17 Jan 2013 16:40:44 -0000 This is a multi-part message in MIME format. --------------090001050203050900070306 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Peter, Your proposal is not acceptable: - Old OCSP clients will simply fail because the error message noIssueRecordFound does not exist in RFC 2560 and/or (?) because they will be unable to process the singleRequestExtensions noIssueRecordFound . - Old OCSP clients cannot take advantage of certHash, but this is not a reason of not including it : it would be indeed a very valuable extension for new OCSP clients A response to one of your observations: certificateHold is not necessarily the single temporary revocation status, since we can change the wording in 2560bis in a backwards compatible way. Denis > Denis, > > I agree that Martin's and Stefan's description and also the last Martin's mail contains clear information what they intend by it to fix. > > But when you look at it from the practical side the usage of revoked status for the "not-issued" / "not used serial number by CA" is only encapsulation of *UNKNOWN* result into the *REVOKED* result. > > So, I agree with you Denis, but from another side that such solution where the status revoked is used as a carrier of UNKNOWN status leading nowhere and its implementation only waste implementer's time. > > Can you create practical examples of statuses and how it is expected that clients and CAs will use it? > > The mistake is in the precondition that responder *KNOWS* the status. > Because authoritative OCSP responder with access to the CA database has not e.g. information about the certificate issued by CA, e.g. record in database was deleted or was not created. > > Proposed OCSP response: > By Martin and Stefan > Signed status Revoked, > Revocation Reasons: certificateHold, > Extensions: id-pkix-ocsp-extended-revoke > Revocation Time: 1.1.1970 00:00:00 UTC > > Consequence: > It is not permanent status and can be changed but special rules must be used. > 1. Correct certificate, but without record in OCSP database will be permanently revoked by rfc2560bis applications because in rfc2560bis is not defined mechanism how it can be reported and corrected on CA/OCSP side. > When in this time it will be requested to be revoked e.g. as a keyCompromise where user will provide all registration documentation to the CA... the HOLD status will be changed to the real status but must be used special logical rules for the time of revocation and not rules defined for certificateHold in X.509/RFC. > (Client and RP applications were correctly using certificate for long time with CRL checking as valid and only once when rfc2560bis OCSP responder was used some unclear situation happened so client recommend to RP to use only CRL :o) :-) ;) > 2. Incorrect serial number of non existing certificate. It is unknown case where it can be useful - probably as attacks e.g. consuming system time for signing responses. > > Proposed OCSP response: > By Denis > Signed status Revoked, > Revocation Reasons: notIssuedOrIrregularlyIssued, > Revocation Time: 1.1.1970 00:00:00 UTC > > Consequence: > It is a permanent status according to actual definition where only certificateHold can be changed. > It is unclear what it will causes in applications in which is not implemented proposed bit in revocation reason. Probably Stefan was pointing on it to avoid such situations. > > > My proposal (updated by comments of Martin and Denis) of OCSP response: > For QES the positive statement certHash of the certificate must be used for a good and revoked status. > When the positive statement certHash of the certificate is not included in the responder database, then the OCSP Responder must return an error message noIssueRecordFound. > > Client applications if recognize the error message noIssueRecordFound can create another OCSP request where will be included requested certificate in > singleRequestExtensions extensin identified by OID id-pkix-ocsp-CertOfNoIssueRecordFound. > According to it OCSP responder or CA will be able to solve the problems with probably CA Database inconsistency or CA Key compromise. > > The following OCSP response can be signed with positive statement certHash tryLater while CA makes a decision or OCSP Responder can return an error message malformedRequest when CertID does not correspond to certificate in id-pkix-ocsp-CertOfNoIssueRecordFound or signed response unknown (what is the same as revoked with reason certificateHold, extensions id-pkix-ocsp-extended-revoke because client have no hint, provided by OCSP, what to do with it). > > > The extension included in singleRequestExtensions and identified by OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound contains certificate for which the status in OCSP request is requested. > > OCSPResponseStatus ::= ENUMERATED { > successful (0), --Response has valid confirmations > malformedRequest (1), --Illegal confirmation request > internalError (2), --Internal error in issuer > tryLater (3), --Try again later > --(4) is not used > sigRequired (5), --Must sign the request > unauthorized (6), --Request unauthorized > noIssueRecordFound (7) -- probably CA Database inconsistency > -- or CA Key compromise > } > > > Peter Rybar > > -----Original Message----- > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Sent: Wednesday, January 16, 2013 10:00 AM > To: Peter Rybar > Cc: pkix@ietf.org > Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients > > Peter, > > From a protocol point of view, an OCSP responder may not rely on any > check made by an OCSP client. > So an OCSP responder MUST be ready to receive requests that contain any > value (good or bad), including : > - a random serial number, > - a malformed ASN.1 request, > - etc .... > > Martin gave you yesterday an extensive response that is fully correct. > Your arguments are leading nowhere. > > Please do not waste our time. > > Denis > >> Martin, Stefan, >> >> If the main case is to provide the final status for the OCSP client, where the client will not subsequently try to use a CRL, then you must also expect that the initial rules were checked and are valid. >> >> The initial rules: >> 1. X.509 is based on PKI and all objects are protected by PKI and the first step is to check the signature of the object. >> 2. When the signature of the object is valid, only after that check the fields of the object must be used as an input in other conditions which can be checked. >> >> In the OCSP case where CertID {issuerKeyHash, issuerNameHash, serialNumber} is created and used: >> >> 1. The OCSP client will use a public key of the CA to check the signature of the certificate whose status need to be checked. >> 2. When the signature is valid, the client creates "issuerKeyHash". >> 3. The OCSP client will check the issuer name field of the certificate whose status need to be checked. >> 4. When issuer names are identical, the client creates "issuerNameHash". >> 5. The OCSP client will use a serial number from the certificate whose status need to be checked and will be created CertID {issuerKeyHash, issuerNameHash, serialNumber} and OCSP REQUES. >> >> As you can see, the present protocol is clear that random cert serial number must not be used. There is only the case when CA key is used as correct CA key or as compromised CA key. >> >> For that reason the status REVOKED must be used only for issued (signed) certificates in the OCSP and also in CRL. >> >> Including non-issued certificates in OCSP responses means ignoring PKI and mixing some another part of protocols like some trustworthy out-of-band procedure with procedure based on PKI. >> >> Peter Rybar >> >> >> -----Original Message----- >> From: Martin Rex [mailto:mrex@sap.com] >> Sent: Tuesday, January 15, 2013 6:49 PM >> To: Peter Rybar >> Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix' >> Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients >> >> Peter Rybar wrote: >>> Probably you have missed my argument that CRLReason of certificateHold >>> is defined only in ITU-T X.509 >> Huh? You should get yourself a new copy of rfc5280 >> >> http://tools.ietf.org/html/rfc5280 >> >> if your's is missing certificateHold(6) CRLReason in the reasonCode >> extension. >> >> >>> and logical semantics specified for CRL and delta CRL when >>> certificateHold is used is problematic for the usage >>> in OCSP >> That is non-sensical. This update does not create CRLs or delta CRLs, >> so the semantics of CRLs and deltaCRLs is irrelevant (for this update). >> >> Even then, any existing OCSP responder that feeds on URL will have to >> sensibly deal with this reason code when processing CRLs and delta CRLs, >> even without this update, so there is nothing about this complexity >> that you could blame onto the propsed update. >> >> >>> where request/response can be created several times in >>> unspecified time/date. >> The semantics of the certificateHold ReasonCode for the "not-issued" >> situation is clear and well-defined. >> >> But what you appear to totally ignore is the problem of permanent >> revocation status. An RP may cache any OCSP response with a permanent >> revocation status FOREVER, entirely ignoring the nextUpdate field, >> because that is exactly what a permant revocation status implies. >> Therefore we MUST ABSOLUTELY avoid to convey a revoked status >> that an RP might consider a permanent revocation status! >> >> >>> The usage of certificateHold as you have proposed is confusing >> Nope, the X.509 semantics of certificateHold that, which we want to use, >> is crystal clear in 8.5.2.2 (a): >> >> the hold status may remain with no further action, causing users >> to reject transactions issued during the hold period >> >> (the words "on the CRL" removed, since this is about the semantics of >> revocationReason within the OCSP SingleResponse, not the semantics >> of ReasonCode within a CrlEntryExtension). >> >>> and for that reason I was proposing another solution where is >>> addressed the problem of issued certificate by CA without evidence in CA. >>> Because the sentence "revoked response for non-issued certificates" >>> is vague when it is only about wrong serial number and the certificate >>> does not exists at application creating OCSP request. >> As I've previously described, >> >> the certificate that the RP is holding is entirely irrelevant to >> the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients >> seem to never include the (optional) certificate in OCSP requests. >> >> >>> It is absurd situations and OCSP responder must react with an error >>> message on such absurd request because that is not situation about >>> the certificate status, that is wrong request which is only about >>> the integer number. >>> OCSP is Online Certificate Status Protocol. >> rfc2560, and how it is used by the installed base, is provably >> about Certificate Serial Status, not about Certificate status. >> Some RPs may boldly infer Certificate status from Certificate Serial >> Status, but that is an inference from the OCSP response, not a function >> of the OCSP protocol the way it is used by common OCSP clients. >> >> There is no such thing as an absurd situation for the OCSP responder >> when looking up a cert serial from the CA cert issue records. Either >> an issue record will be found (likely returning a certificate hash >> along with the status that the serial was found), or no issue record >> will be found. >> >> These are two well-defined, easily distinguishable lookup results >> that can be trivially converted into determinstic OCSP responder behaviour >> with clear and obvious semantics. >> >> >>> It is not partial status about one or two component of the CertID! >>> ( serialNumber or issuerNameHash or issuerKeyHash ) >> I'm sorry, this statement non-sensical. >> >> issuerNameHash and isserKeyHash refer to the CA cert, and as you >> can see from the ASN.1 definition, they are non-optional -- these >> two values MUST always be compared, and if they don't match, the >> result MUST be an "unknown" OCSP response. >> >> The serialNumber is the parameter that refers to the certificate. >> And in order to determine the certificate status this value MUST >> be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request >> or CA cert issue records. >> >> So there can not be such thing as a partial status or a partial match. >> >> >>> >>> When OCSP has access to the CA database, what is the case defined >>> in rfc2560bis for "revoked response for non-issued certificates", >>> then the error message is right response, >> This is also a non-sensical statement. An error message has the semantics >> "this information source is unable to provide cert status information", >> which would non only a pretty stupid response for any authoritative >> OCSP to return when that OCSP responder known pretty damn well that >> this cert serial does not exist on the CA cert issue records, and >> when two extremely common types of behaviours of RPs in the installed >> base for an "unknown" response from an authoritative OCSP responder >> are (1) fail soft and accept the cert or (2) fallback to CRL checking, >> where the revocation check is bound to return status "good", because >> it is impossible to detect the "not-issued" with CRLs. >> >> Bottom line, while returning "good" is permitted by rfc2560 in absence >> of the capability to detect "not issued", and will result in the same >> behaviour as the OCSP client soft failing or falling back to CRL checking, >> returning unknwon would be a pretty dumb response for an authoritative >> OCSP responder which *KNOWS* the status of the requested cert serial. >> >> >>> Another argument why revocation with reason code certificateHold is problematic: >>> >>> ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) >>> >>> 8.5.2.2 Reason code extension >>> >>> Once a hold has been issued, it may be handled in one of three ways: >>> >>> b) it may be replaced by a (final) revocation for the same certificate, >>> in which case the reason shall be one of the standard reasons for >>> revocation, the revocation date shall be the date the certificate was >>> placed on hold, and the optional instruction code extension field >>> shall not appear; or,, >> You seem to be totally confused (or exhibit problems in understanding X.509) >> >> We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update. >> >> 8.5.2.2 (b) obviously does not apply to a cert serial that has >> "not issued" status. >> "not issued" is a temporary status until (if ever) a real cert with that >> serial gets issued. Once a real cert with that serial has been issued, >> OCSP requests for this cert serial will return the status of this real >> cert from the CA issue records, and no longer report "not issued". >> >> >>> According to ?the revocation date shall be the date the certificate >>> was placed on hold? and according to usage of OCSP: >> Since there _exists_ no certiticte when certificateHold conveys the >> "not issued" status, this rule can obviously not apply, because there >> is no information source from which any "placedOnHoldTime" could >> be copied into the OCSP response. >> >> Consequently, the value to place in revocationTime for "not issued" >> is defined in 2560bis -- that should be intuitively apparent. >> >>> The firs OCSP request will be in time t0 when certificate SerNum1 is not issued. >>> >>> You propose OCSP response revoked where: >>> Extensions: id-pkix-ocsp-extended-revoke >>> Revocation Reasons: certificateHold >>> Revocation Time: 1.1.1970 00:00:00 UTC >>> >>> Then certificate will be issued in time t1 and revoked in time t2 in CRL. >>> >>> OCSP request will be created in time t3 and according to definition? >>> the revocation date shall be the date the certificate was placed on hold? >>> the revocation time will be? what a problem is because two >>> interpretations exist. >> Really, why do you ask at all?? >> >> For a certificate that _exists_, and that is put onHold by the CA, >> the CA will know pretty damn well when it asserted that onHold, >> and it will very very very probably publish exactly that date on >> a CRL or delta CRL along with the onHold status. >> >> Whether and when the OCSP responder conveyed "notIssued" in an OCSP response >> using the onHold ReasonCode is invisible and irrelevant to the certificate >> status information maintained by the CA, so there can not possibly arise >> any confusion. When the CA publishes a certificate revocation status >> for a certificate that it has issued, the information conveyed through >> CRLs and the information conveyed through OCSP ought to remain consistent. >> >> What the rfc2560bis update changes is only the incorrectly asserted "good" >> status for cert serials that do not appear on the CA cert issue record. >> >> >>> Is OCSP based on CRL or not? >> It will be a local decision of the OCSP responder whether it feeds >> on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue records >> or on CA cert issue+status records alone, or on any other combination >> of certificate status information sources it sees fit. >> >> This is called "implementation freedom", something that will be >> obvious to anyone with implementation experience. >> >> >>> For that reason I propose to use in this situation OCSP responder >>> error message malformedRequest. >> That doesn't compute for the reason that have be regurgitated >> several times on this list. >> >> >>> For example for clause 7.4 Repudiation of a digital signing >>> (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely >>> problematic when certificateHold is used because transactions >>> created in each time when the certificate was in certificateHold >>> must not be accepted. >> Transactions created with a keypair where the cert serial is unknown >> to the CA that is alleged to have issued that cert is EVEN MORE problematic, >> do you realize that? Because it is not unlikely that not only the >> CA doesn't know about this cert, but also that the subject asserted >> by that cert does not know about that cert (that is regular the intent >> of fraudulent certs), and it will be in the very best interest of >> the RP, in the very best interest of the CA and in the very best >> interest of a subject asserted by a fraudulently issued cert >> if the transaction is not accepted. >> >> THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT! >> >> Gosh, I feel like I'm talking to Eliza. >> >> Continuing to return "good" status for a potentially fraudulent cert, >> which the CA does not have on its record log for whatever reason, >> would be squarely against the interest of RP, CA and asserted subject, >> so continuing to do so would be gross negligent. >> >> >> >>> Also for that reason the certificateHold is forbidden in some systems >>> or legislations. >> While it is true that a lot of politician/legislators are pretty >> clueless about technology, But I see it happen just as often >> that technical guys are clueless about understanding legislation. >> >> Legislation normally legislates duties of legal entities >> (e.g. Party A must do A and must not do B). >> and not try to legislate bits (such as: it is prohibited for bit 7 >> of PDU A field B to have a value of 1. On violation of this rule, >> bit 7 will face a prison term of up to 5 years for gross negligent >> values of 1 and a /dev/null penalty for wilful values of 1). >> >> Unless a specific legislation is completely and thoroughly goofed >> (which happens rarely), positively confirming the use a cert (serial) >> for use in a transaction for which a CA is fully aware that it has >> no proof of issuance (and therefore does not even know whose identity >> that cert asserts), will be a much more severe act of gross negligence >> and potentially make that CA an accomplice in fraud, than resorting >> to a safety measure by asserting certificateHold in the OCSP response. >> >> I don't know how legislation works in other countries, but in >> Germany, in order to become liable, there either needs to be >> gross negligence or intent to cause harm. In the above situation, >> the emergency reaction to return certificateHold in the OCSP response >> is evidently neither of gross negligence nor harm, so there is not >> going to be a problem. >> >> Aren't there QES specs that require the use of an explicit >> proof-of-existence certificate hash conveyed in an OCSP extension >> of an OCSP "good" response, specifically to accomodate the well-known >> shortcoming of base OCSP not being able to convey "not issued"? >> >> >> >>> It creates additional complexity where each CRL must be analyzed to have >>> the complete time line in which date/time and how long the certificate >>> was in the certificateHold state because the certificate can be in >>> certificateHold state several times. >> I don't have the slightest clue what you mean, but it has certainly >> nothing to do whatsoever with conveying certificateHold for "not issued" >> certs. >> >> When your OCSP responder computes its responses from CRLs, then there >> is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are >> listed on CRLs in copying the CRLEntry contents into the OCSP response. >> So there is exactly ZERO additional complexity for processing CRLs. >> >> >> -Martin >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > --------------090001050203050900070306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter,

Your proposal is not acceptable:

=C2=A0 - Old OCSP clients will simply fail because the error mess= age noIssueRecordFound does not exist in RFC 2560
=C2=A0=C2=A0=C2=A0 and/or (?)=C2=A0 because they will be unable t= o process the singleRequestExtensions noIssueRecordFound
=C2=A0.
-=C2=A0 Old OCSP clients cannot take advantage of certHash, but t= his is not a reason of not including it :
=C2=A0=C2=A0=C2=A0 it would be indeed a very valuable extension f= or new OCSP clients 

A response to one of your observations:

certificateHold is not necessarily the single temporary revocation status=
,=20
since we can change the wording in 2560bis in a backwards compatible way.

Denis

 
Denis,

I agree that Martin's and Stefan's description and also the last Martin's=
 mail contains clear information what they intend by it to fix.

But when you look at it from the practical side the usage of revoked stat=
us for the "not-issued" / "not used serial number by CA" is only encapsul=
ation of *UNKNOWN* result into the *REVOKED* result.

So, I agree with you Denis, but from another side that such solution wher=
e the status revoked is used as a carrier of UNKNOWN status leading nowhe=
re and its implementation only waste implementer's time.

Can you create practical examples of statuses and how it is expected that=
 clients and CAs will use it?

The mistake is in the precondition that responder *KNOWS* the status.
Because authoritative OCSP responder with access to the CA database has n=
ot e.g. information about the certificate issued by CA, e.g. record in da=
tabase was deleted or was not created.

Proposed OCSP response:
By Martin and Stefan
  Signed status Revoked,=20
     Revocation Reasons: certificateHold,=20
     Extensions: id-pkix-ocsp-extended-revoke
     Revocation Time: 1.1.1970 00:00:00 UTC

Consequence:=20
It is not permanent status and can be changed but special rules must be u=
sed.
1. Correct certificate, but without record in OCSP database will be perma=
nently revoked by rfc2560bis applications because in rfc2560bis is not de=
fined mechanism how it can be reported and corrected on CA/OCSP side.
When in this time it will be requested to be revoked e.g. as a keyComprom=
ise where user will provide all registration documentation to the CA... t=
he HOLD status will be changed to the real status but must be used specia=
l logical rules for the time of revocation and not rules defined for cert=
ificateHold in X.509/RFC.=20
(Client and RP applications were correctly using certificate for long tim=
e with CRL checking as valid and only once when rfc2560bis OCSP responder=
 was used some unclear situation happened so client recommend to RP to us=
e only CRL :o) :-) ;)
2. Incorrect serial number of non existing certificate. It is unknown cas=
e where it can be useful - probably as attacks e.g. consuming system time=
 for signing responses. =20

Proposed OCSP response:
By Denis
  Signed status Revoked,=20
     Revocation Reasons: notIssuedOrIrregularlyIssued,=20
     Revocation Time: 1.1.1970 00:00:00 UTC

Consequence:
It is a permanent status according to actual definition where only certif=
icateHold can be changed.
It is unclear what it will causes in applications in which is not impleme=
nted proposed bit in revocation reason. Probably Stefan was pointing on i=
t to avoid such situations.


My proposal (updated by comments of Martin and Denis) of OCSP response:
For QES the positive statement certHash of the certificate must be used f=
or a good and revoked status.
When the positive statement certHash of the certificate is not included i=
n the responder database, then the OCSP Responder must return an error me=
ssage noIssueRecordFound.

Client applications if recognize the error message noIssueRecordFound can=
 create another OCSP request where will be included requested certificate=
 in =20
singleRequestExtensions extensin identified by OID id-pkix-ocsp-CertOfNoI=
ssueRecordFound.
According to it OCSP responder or CA will be able to solve the problems w=
ith probably CA Database inconsistency or CA Key compromise.

The following OCSP response can be signed with positive statement certHas=
h tryLater while CA makes a decision or OCSP Responder can return an erro=
r message malformedRequest when CertID does not correspond to certificate=
 in id-pkix-ocsp-CertOfNoIssueRecordFound or signed response unknown (wha=
t is the same as revoked with reason certificateHold, extensions id-pkix-=
ocsp-extended-revoke because client have no hint, provided by OCSP, what =
to do with it).


The extension included in singleRequestExtensions and identified by OBJEC=
T IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound contains certificate f=
or which the status in OCSP request is requested.

OCSPResponseStatus ::=3D ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6),   --Request unauthorized
       noIssueRecordFound (7) -- probably CA Database inconsistency=20
                              -- or CA Key compromise
   }


Peter Rybar

-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20
Sent: Wednesday, January 16, 2013 10:00 AM
To: Peter Rybar
Cc: p=
kix@ietf.org
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyC=
ADatabaseOrCAKeyCompromise for legacy clients

Peter,

 From a protocol point of view, an OCSP responder may not rely on any=20
check made by an OCSP client.
So an OCSP responder MUST be ready to receive requests that contain any=20
value (good or bad), including :
  - a random serial number,
  - a malformed ASN.1 request,
  - etc ....

Martin gave you yesterday an extensive response that is fully correct.
Your arguments are leading nowhere.

Please do not waste our time.

Denis


Martin, Stefan,

If the main case is to provide the final status for the OCSP client, wher=
e the client will not subsequently try to use a CRL, then you must also e=
xpect that the initial rules were checked and are valid.

The initial rules:
1. X.509 is based on PKI and all objects are protected by PKI and the fir=
st step is to check the signature of the object.
2. When the signature of the object is valid, only after that check the f=
ields of the object must be used as an input in other conditions which ca=
n be checked.

In the OCSP case where CertID {issuerKeyHash, issuerNameHash, serialNumbe=
r} is created and used:

1. The OCSP client will use a public key of the CA to check the signature=
 of the certificate whose status need to be checked.
2. When the signature is valid, the client creates "issuerKeyHash".
3. The OCSP client will check the issuer name field of the certificate wh=
ose status need to be checked.
4. When issuer names are identical, the client creates "issuerNameHash".
5. The OCSP client will use a serial number from the certificate whose st=
atus need to be checked and will be created CertID {issuerKeyHash, issuer=
NameHash, serialNumber} and OCSP REQUES.

As you can see, the present protocol is clear that random cert serial num=
ber must not be used. There is only the case when CA key is used as corre=
ct CA key or as compromised CA key.

For that reason the status REVOKED must be used only for issued (signed) =
certificates in the OCSP and also in CRL.

Including non-issued certificates in OCSP responses means ignoring PKI an=
d mixing some another part of protocols like some trustworthy out-of-band=
 procedure with procedure based on PKI.

Peter Rybar


-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Tuesday, January 15, 2013 6:49 PM
To: Peter Rybar
Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyC=
ADatabaseOrCAKeyCompromise for legacy clients

Peter Rybar wrote:

Probably you have missed my argument that CRLRea=
son of certificateHold
is defined only in ITU-T X.509

Huh?  You should get yourself a new copy of rfc528=
0

   http://tools.ietf.org/html/rfc5280

if your's is missing certificateHold(6) CRLReason in the reasonCode
extension.



and logical semantics specified for CRL and delt=
a CRL when
certificateHold is used is problematic for the usage
in OCSP

That is non-sensical.  This update does not create=
 CRLs or delta CRLs,
so the semantics of CRLs and deltaCRLs is irrelevant (for this update).

Even then, any existing OCSP responder that feeds on URL will have to
sensibly deal with this reason code when processing CRLs and delta CRLs,
even without this update, so there is nothing about this complexity
that you could blame onto the propsed update.



where request/response can be created several ti=
mes in
unspecified time/date.

The semantics of the certificateHold ReasonCode fo=
r the "not-issued"
situation is clear and well-defined.

But what you appear to totally ignore is the problem of permanent
revocation status.  An RP may cache any OCSP response with a permanent
revocation status FOREVER, entirely ignoring the nextUpdate field,
because that is exactly what a permant revocation status implies.
Therefore we MUST ABSOLUTELY avoid to convey a revoked status
that an RP might consider a permanent revocation status!



The usage of certificateHold as you have propose=
d is confusing

Nope, the X.509 semantics of certificateHold that,=
 which we want to use,
is crystal clear in 8.5.2.2 (a):

    the hold status may remain with no further action, causing users
    to reject transactions issued during the hold period

(the words "on the CRL" removed, since this is about the semantics of
  revocationReason within the OCSP SingleResponse, not the semantics
  of ReasonCode within a CrlEntryExtension).


and for that reason I was proposing another solu=
tion where is
addressed the problem of issued certificate by CA without evidence in CA.
Because the sentence "revoked response for non-issued certificates"
is vague when it is only about wrong serial number and the certificate
does not exists at application creating OCSP request.

As I've previously described,

the certificate that the RP is holding is entirely irrelevant to
the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients
seem to never include the (optional) certificate in OCSP requests.



It is absurd situations and OCSP responder must =
react with an error
message on such absurd request because that is not situation about
the certificate status, that is wrong request which is only about
the integer number.
OCSP is Online Certificate Status Protocol.

rfc2560, and how it is used by the installed base,=
 is provably
about Certificate Serial Status, not about Certificate status.
Some RPs may boldly infer Certificate status from Certificate Serial
Status, but that is an inference from the OCSP response, not a function
of the OCSP protocol the way it is used by common OCSP clients.

There is no such thing as an absurd situation for the OCSP responder
when looking up a cert serial from the CA cert issue records.  Either
an issue record will be found (likely returning a certificate hash
along with the status that the serial was found), or no issue record
will be found.

These are two well-defined, easily distinguishable lookup results
that can be trivially converted into determinstic OCSP responder behaviou=
r
with clear and obvious semantics.



It is not partial status about one or two compon=
ent of the CertID!
( serialNumber or issuerNameHash or issuerKeyHash )

I'm sorry, this statement non-sensical.

issuerNameHash and isserKeyHash refer to the CA cert, and as you
can see from the ASN.1 definition, they are non-optional -- these
two values MUST always be compared, and if they don't match, the
result MUST be an "unknown" OCSP response.

The serialNumber is the parameter that refers to the certificate.
And in order to determine the certificate status this value MUST
be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request
or CA cert issue records.

So there can not be such thing as a partial status or a partial match.



 =20
When OCSP has access to the CA database, what is the case defined
in rfc2560bis for "revoked response for non-issued certificates",
then the error message is right response,

This is also a non-sensical statement.  An error m=
essage has the semantics
"this information source is unable to provide cert status information",
which would non only a pretty stupid response for any authoritative
OCSP to return when that OCSP responder known pretty damn well that
this cert serial does not exist on the CA cert issue records, and
when two extremely common types of behaviours of RPs in the installed
base for an "unknown" response from an authoritative OCSP responder
are  (1) fail soft and accept the cert or (2) fallback to CRL checking,
where the revocation check is bound to return status "good", because
it is impossible to detect the "not-issued" with CRLs.

Bottom line, while returning "good" is permitted by rfc2560 in absence
of the capability to detect "not issued", and will result in the same
behaviour as the OCSP client soft failing or falling back to CRL checking=
,
returning unknwon would be a pretty dumb response for an authoritative
OCSP responder which *KNOWS* the status of the requested cert serial.



Another argument why revocation with reason code=
 certificateHold is problematic:

ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)

8.5.2.2 Reason code extension

Once a hold has been issued, it may be handled in one of three ways:

b) it may be replaced by a (final) revocation for the same certificate,
in which case the reason shall be one of the standard reasons for
revocation, the revocation date shall be the date the certificate was
placed on hold, and the optional instruction code extension field
shall not appear; or,,

You seem to be totally confused (or exhibit proble=
ms in understanding X.509)

We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update.

8.5.2.2 (b) obviously does not apply to a cert serial that has
"not issued" status.
"not issued" is a temporary status until (if ever) a real cert with that
serial gets issued.  Once a real cert with that serial has been issued,
OCSP requests for this cert serial will return the status of this real
cert from the CA issue records, and no longer report "not issued".



According to ?the revocation date shall be the d=
ate the certificate
was placed on hold? and according to usage of OCSP:

Since there _exists_ no certiticte when certificat=
eHold conveys the
"not issued" status, this rule can obviously not apply, because there
is no information source from which any "placedOnHoldTime" could
be copied into the OCSP response.

Consequently, the value to place in revocationTime for "not issued"
is defined in 2560bis -- that should be intuitively apparent.


The firs OCSP request will be in time t0 when ce=
rtificate SerNum1 is not issued.

You propose OCSP response revoked where:
Extensions: id-pkix-ocsp-extended-revoke
Revocation Reasons: certificateHold
Revocation Time: 1.1.1970 00:00:00 UTC

Then certificate will be issued in time t1 and revoked in time t2 in CRL.

OCSP request will be created in time t3 and according to definition?
the revocation date shall be the date the certificate was placed on hold?
the revocation time will be? what a problem is because two
interpretations exist.

Really, why do you ask at all??

For a certificate that _exists_, and that is put onHold by the CA,
the CA will know pretty damn well when it asserted that onHold,
and it will very very very probably publish exactly that date on
a CRL or delta CRL along with the onHold status.

Whether and when the OCSP responder conveyed "notIssued" in an OCSP respo=
nse
using the onHold ReasonCode is invisible and irrelevant to the certificat=
e
status information maintained by the CA, so there can not possibly arise
any confusion.  When the CA publishes a certificate revocation status
for a certificate that it has issued, the information conveyed through
CRLs and the information conveyed through OCSP ought to remain consistent=
.

What the rfc2560bis update changes is only the incorrectly asserted "good=
"
status for cert serials that do not appear on the CA cert issue record.



Is OCSP based on CRL or not?

It will be a local decision of the OCSP responder =
whether it feeds
on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue records
or on CA cert issue+status records alone, or on any other combination
of certificate status information sources it sees fit.

This is called "implementation freedom", something that will be
obvious to anyone with implementation experience.



For that reason I propose to use in this situati=
on OCSP responder
error message malformedRequest.

That doesn't compute for the reason that have be r=
egurgitated
several times on this list.



For example for clause 7.4 Repudiation of a digi=
tal signing
(ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely
problematic when certificateHold is used because transactions
created in each time when the certificate was in certificateHold
must not be accepted.

Transactions created with a keypair where the cert serial is unknown
to the CA that is alleged to have issued that cert is EVEN MORE problemat=
ic,
do you realize that?  Because it is not unlikely that not only the
CA doesn't know about this cert, but also that the subject asserted
by that cert does not know about that cert (that is regular the intent
of fraudulent certs), and it will be in the very best interest of
the RP, in the very best interest of the CA and in the very best
interest of a subject asserted by a fraudulently issued cert
if the transaction is not accepted.

THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT!

Gosh, I feel like I'm talking to Eliza.

Continuing to return "good" status for a potentially fraudulent cert,
which the CA does not have on its record log for whatever reason,
would be squarely against the interest of RP, CA and asserted subject,
so continuing to do so would be gross negligent.




Also for that reason the certificateHold is forb=
idden in some systems
or legislations.

While it is true that a lot of politician/legislat=
ors are pretty
clueless about technology,  But I see it happen just as often
that technical guys are clueless about understanding legislation.

Legislation normally legislates duties of legal entities
(e.g. Party A must do A and must not do B).
and not try to legislate bits (such as: it is prohibited for bit 7
of PDU A field B to have a value of 1.  On violation of this rule,
bit 7 will face a prison term of up to 5 years for gross negligent
values of 1 and a /dev/null penalty for wilful values of 1).

Unless a specific legislation is completely and thoroughly goofed
(which happens rarely), positively confirming the use a cert (serial)
for use in a transaction for which a CA is fully aware that it has
no proof of issuance (and therefore does not even know whose identity
that cert asserts), will be a much more severe act of gross negligence
and potentially make that CA an accomplice in fraud, than resorting
to a safety measure by asserting certificateHold in the OCSP response.

I don't know how legislation works in other countries, but in
Germany, in order to become liable, there either needs to be
gross negligence or intent to cause harm.  In the above situation,
the emergency reaction to return certificateHold in the OCSP response
is evidently neither of gross negligence nor harm, so there is not
going to be a problem.

Aren't there QES specs that require the use of an explicit
proof-of-existence certificate hash conveyed in an OCSP extension
of an OCSP "good" response, specifically to accomodate the well-known
shortcoming of base OCSP not being able to convey "not issued"?




It creates additional complexity where each CRL =
must be analyzed to have
the complete time line in which date/time and how long the certificate
was in the certificateHold state because the certificate can be in
certificateHold state several times.

I don't have the slightest clue what you mean, but=
 it has certainly
nothing to do whatsoever with conveying certificateHold for "not issued"
certs.

When your OCSP responder computes its responses from CRLs, then there
is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are
listed on CRLs in copying the CRLEntry contents into the OCSP response.
So there is exactly ZERO additional complexity for processing CRLs.


-Martin

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

--------------090001050203050900070306-- From mrex@sap.com Thu Jan 17 08:56:56 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 1B44421F87E0 for ; Thu, 17 Jan 2013 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 zGM4TP0cKiZC for ; Thu, 17 Jan 2013 08:56:55 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB521F86AC for ; Thu, 17 Jan 2013 08:56:54 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0HGuqig022341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 17:56:53 +0100 (MET) In-Reply-To: <043e01cdf348$fac17630$f0446290$@ditenity.com> To: Piyush Jain Date: Thu, 17 Jan 2013 17:56:52 +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: <20130117165652.CB02A1A462@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:56:56 -0000 Piyush Jain wrote: > > Here is the scenario. > > (1) A certificate with serial number n is signed using the CA private key > and records of issuance are deleted from the database (RA/CA > compromise or loss of issuance records) > (2) CA issues another certificate with serial number n. There is nothing new or unusal about this scenario. The very similar scenario, where a fraudulent cert is purposely created with the serial of a valid existing cert has been explicitly described in this discussion before (I know I did). X.509/PKIX and CRLs/OCSP was designed with the assumption that serial are unique. We can not change that, because it would be fundamentally backwards-incompatible. Updating OCSP to account for this is easy, by including a certificate hash in the "good" responses as a proof-of-existence. Only updated OCSP clients that require that proof-of-existence and verify it, can notice such an attack, of course. Negative assertions, such as crlEntries in CRLs and OCSP "revoked" responses, should probably not include a certificate hash, because the revocation of a cert serial must be applied to *ALL* certs with that serial, not just the one that a CA might be aware to have issued. -Martin From piyush@ditenity.com Thu Jan 17 09:54: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 AEBC721F87E5 for ; Thu, 17 Jan 2013 09:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 H5ObCm9xTO6t for ; Thu, 17 Jan 2013 09:54:39 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23821F87D9 for ; Thu, 17 Jan 2013 09:54:38 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id l10so2878775oag.8 for ; Thu, 17 Jan 2013 09:54:38 -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=MDbEuDw4rMuPvnAi0M7QEGN8fViQmOYwE1ycW4VT3z8=; b=AclCLAxGhsoJo2IuMdkH1IaqnosheGvMOOmE4B55p9ofYoSB+bPR5NUW60+1jyeP/T 8oO3mI65sfCKKohu1lInNfIfmTCwF+A65E0kSGxK3tkdnhP+zTLiHnpmqmvtvPNJYzId Usz+RQk55dJPRPII9Sz/003s5sA89O2oQA+HdQn864J/yhFogF6W0xwQZRgPX77txf5U 1SJstXQlbpX4VyiWqdcNqarTbcUlSaeNiYImhiSxptH/tEpsn4eIYOC27bmI2eBHuMws Mj/+DNPUeUmhDoGPRUnw7DRy5vYL+b3mXyA+u3mo6M2i17C3vt21pUbJrZFsqfitQ7Xc hCVw== X-Received: by 10.60.32.235 with SMTP id m11mr4735982oei.129.1358445278432; Thu, 17 Jan 2013 09:54:38 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id e1sm1563841oef.4.2013.01.17.09.54.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:54:37 -0800 (PST) From: "Piyush Jain" To: References: <043e01cdf348$fac17630$f0446290$@ditenity.com> <20130117165652.CB02A1A462@ld9781.wdf.sap.corp> In-Reply-To: <20130117165652.CB02A1A462@ld9781.wdf.sap.corp> Date: Thu, 17 Jan 2013 09:54:33 -0800 Message-ID: <080001cdf4db$b5cd05a0$216710e0$@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: AQHXU9YEV8VW1LreE/ptQWrN5YIpnpg7CtFA Content-Language: en-us X-Gm-Message-State: ALoCoQmTYfUdxco2BZ5S3fu00RsNIlhUNOSjdolfVWafjDzJgGIvyTwEO9MC+Ezy+/Ls6VOUllCe Cc: pkix@ietf.org Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate 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, 17 Jan 2013 17:54:39 -0000 Please accept my apologies Martin. I should've been explicit while posting this question. I meant in context of the current update. I know there are a lot of ways to make the world a better place :), but we can only evaluate the proposals put in front of us. Based on your response below, can I conclude that a serial number (according to current draft) could be both good and non-issued and consequently that a responder that claims to return revoked for "non-issued" will return 'good' for some serial numbers associated with "non-issued" certificates. I would assume that if above is true then at the minimum, we need a paragraph in security considerations section to capture this scenario. > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, January 17, 2013 8:57 AM > To: Piyush Jain > Cc: pkix@ietf.org > Subject: Re: [pkix] what is status of a serial number associated with both > "issued" ans "non-issued" certificate > > Piyush Jain wrote: > > > > Here is the scenario. > > > > (1) A certificate with serial number n is signed using the CA private key > > and records of issuance are deleted from the database (RA/CA > > compromise or loss of issuance records) > > (2) CA issues another certificate with serial number n. > > There is nothing new or unusal about this scenario. The very similar scenario, > where a fraudulent cert is purposely created with the serial of a valid existing > cert has been explicitly described in this discussion before (I know I did). > > X.509/PKIX and CRLs/OCSP was designed with the assumption that serial are > unique. We can not change that, because it would be fundamentally > backwards-incompatible. > > Updating OCSP to account for this is easy, by including a certificate hash in > the "good" responses as a proof-of-existence. Only updated OCSP clients > that require that proof-of-existence and verify it, can notice such an attack, > of course. > > Negative assertions, such as crlEntries in CRLs and OCSP "revoked" > responses, should probably not include a certificate hash, because the > revocation of a cert serial must be applied to *ALL* certs with that serial, not > just the one that a CA might be aware to have issued. > > > -Martin From mrex@sap.com Thu Jan 17 11:20:29 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 E4DC421F86D2 for ; Thu, 17 Jan 2013 11:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 MgTS1sXbx2g7 for ; Thu, 17 Jan 2013 11:20:29 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 47F8021F8800 for ; Thu, 17 Jan 2013 11:20:28 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0HJKQRM005163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 20:20:26 +0100 (MET) In-Reply-To: <080001cdf4db$b5cd05a0$216710e0$@ditenity.com> To: Piyush Jain Date: Thu, 17 Jan 2013 20:20:26 +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: <20130117192026.08D581A463@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:20:30 -0000 Piyush Jain wrote: > > Based on your response, can I conclude that a serial number (according > to current draft) could be both good and non-issued Nope, that is impossible. Due to the fundamental assumption of X.509 that IssuerAndSerial is unique, "issued" is a true boolean, and not a tree-state. > and consequently that a > responder that claims to return revoked for "non-issued" will return 'good' > for some serial numbers associated with "non-issued" certificates. You forgot once again that rfc2560 OCSP is purely about the status of cert serial numbers, and *NOT* about the status of certificates! What your thoughts prove is that infering the status of certificates from the status of cert serials turns into a logical fallacy when the fundamental assumption of X.509, that IssuerAndSerial are unique, is circumvented. As it has been regurgitated several times by now, X.509 CRLs and rfc2560 OCSP are unable to properly deal with that situation. CRLs are a lost cause, but OCSP could be updated to convey a certificate hash as proof-of-issuance in the OCSP response, so that updated OCSP clients can recognize the certificate to which the certificate serial status really applies, and therefore recognize and properly reject certificates with duplicated IssuerAndSerials, that are not intended to exist, and to which the cert serial status does not apply. > > I would assume that if above is true then at the minimum, we need a > paragraph in security considerations section to capture this scenario. Due to the persistent misunderstanding by a few readers of rfc2560, that OCSP would be about certificate status, although it clearly (and provably) is *ONLY* about certificate _SERIAL_ status, probably warrants a clarifying rewording of the abstract and protocol overview section, and an explanation of the difference in the SecurityConsiderations section. -Martin From piyush@ditenity.com Thu Jan 17 12:04:09 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 5616A21F8A35 for ; Thu, 17 Jan 2013 12:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 m7clpxkfCz5C for ; Thu, 17 Jan 2013 12:04:08 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5B21F89CB for ; Thu, 17 Jan 2013 12:04:08 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id j6so3074287oag.26 for ; Thu, 17 Jan 2013 12:04:08 -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=AvPUiIklOEvusgsOXdxGasQVDf7rONs1gSfgAOFhm5Q=; b=Qo9ATH4A52X/rPzwskRRmZD+MM4pePMfLmpq0RiaMiMcl+1wxX9lPigRu6ORzyYf2Z UxRI273QuXs8ea3fEbpiQs1gti5Rg6d2Y6CWzUhjfBpurlLriDLg65lY0JtmOD/pPTZA B8q91mRQIigjjl8jBEnrxEM8cyvArcWiTn634YuHMElwNoqVdreUVn1j5dLo7QfC5AXU PFnhiWr2P3IZuVnyXixvdkiJ8Erg2B37mPzfqncSoLfWFkvbljnSprTKerET/Pt/qtrP QCHFCeEpJomTraBHb2OFL2/dmJBiwDe5W/2tKmkSxXyfh53fwxb4KLELN8ZDI9Wp0j8D CBqg== X-Received: by 10.182.146.13 with SMTP id sy13mr4938847obb.45.1358453047952; Thu, 17 Jan 2013 12:04:07 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id oj8sm1783515obb.3.2013.01.17.12.04.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 12:04:06 -0800 (PST) From: "Piyush Jain" To: References: <080001cdf4db$b5cd05a0$216710e0$@ditenity.com> <20130117192026.08D581A463@ld9781.wdf.sap.corp> In-Reply-To: <20130117192026.08D581A463@ld9781.wdf.sap.corp> Date: Thu, 17 Jan 2013 12:04:02 -0800 Message-ID: <086701cdf4ed$cc98e0d0$65caa270$@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: AQHcLrWXcNtayBBt387C8SsFoFhZhpgxdCJg Content-Language: en-us X-Gm-Message-State: ALoCoQnEwr4G0OsdW1L1aA4YRlpB/gZmPleK6lPjfu3+YMsnRZfEjND+kWseN/WOlC2gHeJHvs7S Cc: pkix@ietf.org Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate 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, 17 Jan 2013 20:04:09 -0000 > Piyush Jain wrote: > > > > Based on your response, can I conclude that a serial number > > (according to current draft) could be both good and non-issued > > Nope, that is impossible. Due to the fundamental assumption of X.509 that > IssuerAndSerial is unique, "issued" is a true boolean, and not a tree-state. [Piyush] I think that we agree that this fundamental assumption is incorrect, keeping in mind the scenario I described. However to move forward, we need to either - continue to believe this fundamental assumption. This would imply that non-issued is Boolean state, but also imply that it can be verified by a simple signature check if the certificate is available to the RP. - trash the assumption. This would imply that a serial could be good and non-issued at the same time. I am okay with either, as long as it is captured in the spec and used as the basis for future discussions. Switching from one to other, IMO is non-productive and causes a lot of confusion. > > > > and consequently that a > > responder that claims to return revoked for "non-issued" will return 'good' > > for some serial numbers associated with "non-issued" certificates. > > You forgot once again that rfc2560 OCSP is purely about the status of cert > serial numbers, and *NOT* about the status of certificates! [Piyush] I tried to keep it in mind :). Just trying to comprehend if "status of serial number" has different meaning depending on whether you are the client or the server. And if it is different, then designing a protocol to connect the two becomes useless. > > What your thoughts prove is that infering the status of certificates from the > status of cert serials turns into a logical fallacy when the fundamental > assumption of X.509, that IssuerAndSerial are unique, is circumvented. > [Piyush] +1. Given that all the OCSP clients do it anyway, we need to think of a way to address this. > As it has been regurgitated several times by now, X.509 CRLs and rfc2560 > OCSP are unable to properly deal with that situation. CRLs are a lost cause, > but OCSP could be updated to convey a certificate hash as proof-of-issuance > in the OCSP response, so that updated OCSP clients can recognize the > certificate to which the certificate serial status really applies, and therefore > recognize and properly reject certificates with duplicated IssuerAndSerials, > that are not intended to exist, and to which the cert serial status does not > apply. > [Piyush] As I said before, I wanted to keep this discussion focused on what we have in front of us today. I will be happy to review/provide input if I see a draft of this extended proposal. Based on what you are saying, the current update is incomplete and is not enough to address the problems that you describe above. > > > > I would assume that if above is true then at the minimum, we need a > > paragraph in security considerations section to capture this scenario. > > Due to the persistent misunderstanding by a few readers of rfc2560, that > OCSP would be about certificate status, although it clearly (and provably) is > *ONLY* about certificate _SERIAL_ status, probably warrants a clarifying > rewording of the abstract and protocol overview section, and an explanation > of the difference in the SecurityConsiderations section. > [Piyush] +1 to the second part of you sentence above. > > -Martin From tgindin@us.ibm.com Thu Jan 17 17:33: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 E46BE21F892D for ; Thu, 17 Jan 2013 17:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhisc+0UZXC1 for ; Thu, 17 Jan 2013 17:33:40 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id A108621F88BE for ; Thu, 17 Jan 2013 17:33:40 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 17 Jan 2013 20:33:40 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 17 Jan 2013 20:33:38 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 03F9B6E803A for ; Thu, 17 Jan 2013 20:33:37 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0I1Xbpv64553080 for ; Thu, 17 Jan 2013 20:33:37 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0I1XbO5030491 for ; Thu, 17 Jan 2013 20:33:37 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0I1XbMK030488; Thu, 17 Jan 2013 20:33:37 -0500 In-Reply-To: <086701cdf4ed$cc98e0d0$65caa270$@ditenity.com> References: <080001cdf4db$b5cd05a0$216710e0$@ditenity.com> <20130117192026.08D581A463@ld9781.wdf.sap.corp> <086701cdf4ed$cc98e0d0$65caa270$@ditenity.com> To: "Piyush Jain" MIME-Version: 1.0 X-KeepSent: 7D3023A4:A0117F5B-85257AF6:0076D5C5; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 17 Jan 2013 20:33:35 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 01/17/2013 20:33:37, Serialize complete at 01/17/2013 20:33:37 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13011801-7182-0000-0000-00000488108C Cc: pkix@ietf.org Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate 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, 18 Jan 2013 01:33:42 -0000 Piyush: Suppose we call the state of a certificate serial number which is used by both a non-recorded certificate and a valid certificate "collision". I think that we should tell issuers to relieve serial number collisions rather than expect RP's to work around them, especially since there are many places in PKI standards where the combination of issuer and serial number is presumed unique, including CRL's and CMS' SignerIdentifier. Is not the correct action for a CA to perform when it detects such a serial number to remove the collision by revoking the valid certificate with code "superseded" and (if it's still operating that issuer) issuing a new certificate with most of the valid certificate's attributes? Once that is done, the serial number is revoked and the valid subject has a valid certificate. This presumes that the CA doesn't revoke that issuer's key and start using a new key instead. Even then, it can reissue a new certificate for the valid subject if it chooses. There's some breakage, but less than having an irrevocable certificate around. Tom Gindin From: "Piyush Jain" To: , Cc: pkix@ietf.org Date: 01/17/2013 03:04 PM Subject: Re: [pkix] what is status of a serial number associated with both "issued" ans "non-issued" certificate Sent by: pkix-bounces@ietf.org > Piyush Jain wrote: > > > > Based on your response, can I conclude that a serial number > > (according to current draft) could be both good and non-issued > > Nope, that is impossible. Due to the fundamental assumption of X.509 that > IssuerAndSerial is unique, "issued" is a true boolean, and not a tree-state. [Piyush] I think that we agree that this fundamental assumption is incorrect, keeping in mind the scenario I described. However to move forward, we need to either - continue to believe this fundamental assumption. This would imply that non-issued is Boolean state, but also imply that it can be verified by a simple signature check if the certificate is available to the RP. - trash the assumption. This would imply that a serial could be good and non-issued at the same time. I am okay with either, as long as it is captured in the spec and used as the basis for future discussions. Switching from one to other, IMO is non-productive and causes a lot of confusion. > > > > and consequently that a > > responder that claims to return revoked for "non-issued" will return 'good' > > for some serial numbers associated with "non-issued" certificates. > > You forgot once again that rfc2560 OCSP is purely about the status of cert > serial numbers, and *NOT* about the status of certificates! [Piyush] I tried to keep it in mind :). Just trying to comprehend if "status of serial number" has different meaning depending on whether you are the client or the server. And if it is different, then designing a protocol to connect the two becomes useless. > > What your thoughts prove is that infering the status of certificates from the > status of cert serials turns into a logical fallacy when the fundamental > assumption of X.509, that IssuerAndSerial are unique, is circumvented. > [Piyush] +1. Given that all the OCSP clients do it anyway, we need to think of a way to address this. > As it has been regurgitated several times by now, X.509 CRLs and rfc2560 > OCSP are unable to properly deal with that situation. CRLs are a lost cause, > but OCSP could be updated to convey a certificate hash as proof-of-issuance > in the OCSP response, so that updated OCSP clients can recognize the > certificate to which the certificate serial status really applies, and therefore > recognize and properly reject certificates with duplicated IssuerAndSerials, > that are not intended to exist, and to which the cert serial status does not > apply. > [Piyush] As I said before, I wanted to keep this discussion focused on what we have in front of us today. I will be happy to review/provide input if I see a draft of this extended proposal. Based on what you are saying, the current update is incomplete and is not enough to address the problems that you describe above. > > > > I would assume that if above is true then at the minimum, we need a > > paragraph in security considerations section to capture this scenario. > > Due to the persistent misunderstanding by a few readers of rfc2560, that > OCSP would be about certificate status, although it clearly (and provably) is > *ONLY* about certificate _SERIAL_ status, probably warrants a clarifying > rewording of the abstract and protocol overview section, and an explanation > of the difference in the SecurityConsiderations section. > [Piyush] +1 to the second part of you sentence above. > > -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Thu Jan 17 21:28: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 BFD2921F8BAB for ; Thu, 17 Jan 2013 21:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.971 X-Spam-Level: X-Spam-Status: No, score=-99.971 tagged_above=-999 required=5 tests=[AWL=-1.719, BAYES_50=0.001, 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 dfk3ozARaGmR for ; Thu, 17 Jan 2013 21:28:48 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A21A721F8C01 for ; Thu, 17 Jan 2013 21:28:46 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 1DC6F12BEDA for ; Fri, 18 Jan 2013 06:28:42 +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 Y2d-kM2jQ_PZ for ; Fri, 18 Jan 2013 06:28:41 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 99D5012BE80 for ; Fri, 18 Jan 2013 06:28:41 +0100 (CET) Received: (qmail 24304 invoked from network); 18 Jan 2013 05:28:41 -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 ; 18 Jan 2013 05:28:41 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 18 Jan 2013 06:28:39 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: The process of updating 2560bis In-Reply-To: <033a01cdf324$4d565c50$e80314f0$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441335321_6092948" Subject: [pkix] The process of updating 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 05:28:48 -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_3441335321_6092948 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On some of the latest proposals where new reason codes etc are proposed. I will not administer introduction of new reason codes or alike features to the OCSP protocol without a major part of the implementing community showing up on this list and approving it. You may have noticed that there has been a whole lot of messages sent to this list on this subject by a few people. So as an example, having the same person saying things loudly many times, does not count as WG consensus. In particular not when we are dealing with a widely deployed protocol. The direction of the current draft is the result of a WG consensus process where many people on this list voiced their opinion. If you want a material, change of that direction, you need to attract support from enough people on this list to demonstrate wide support of the direction change. Unless that happens, I will not incorporate it in the draft. Scott Rea just sent me test results from real implementation of the current draft. This shows that implementers care about this even if they don't engage in this discussion. When we are dealing with a magnitude of platforms and clients, any change to the protocol is a potential disaster, so we need to be very careful. I do encourage as may implementers as possible to do tests and publish your findings, before we ship this. /Stefan --B_3441335321_6092948 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
On some of the latest propos= als where new reason codes etc are proposed.

I will= not administer introduction of new reason codes or alike features to the OC= SP protocol without a major part of the implementing community showing up on= this list and approving it.
You may have noticed that there has b= een a whole lot of messages sent to this list on this subject by a few peopl= e.

So as an example, having the same person saying = things loudly many times, does not count as WG consensus. In particular not = when we are dealing with a widely deployed protocol.

The direction of the current draft is the result of a WG consensus process= where many people on this list voiced their opinion.
If you want = a material, change of that direction, you need to attract support from enoug= h people on this list to demonstrate wide support of the direction change.
Unless that happens, I will not incorporate it in the draft.
<= div>
Scott Rea just sent me test results from real implementat= ion of the current draft. This shows that implementers care about this even = if they don't engage in this discussion.
When we are dealing with = a magnitude of platforms and clients, any change to the protocol is a potent= ial disaster, so we need to be very careful.

I do e= ncourage as may implementers as possible to do tests and publish your findin= gs, before we ship this.

/Stefan

--B_3441335321_6092948-- From stefan@aaa-sec.com Thu Jan 17 21:42: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 2EB3521F8BDE for ; Thu, 17 Jan 2013 21:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.985 X-Spam-Level: X-Spam-Status: No, score=-100.985 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 0l+PkrIK0-PQ for ; Thu, 17 Jan 2013 21:42:24 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD121F85D0 for ; Thu, 17 Jan 2013 21:42:23 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 52C6F12C134 for ; Fri, 18 Jan 2013 06:42:22 +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 aDk33PFjvTpo for ; Fri, 18 Jan 2013 06:42:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E162212C132 for ; Fri, 18 Jan 2013 06:42:21 +0100 (CET) Received: (qmail 52366 invoked from network); 18 Jan 2013 05:42:21 -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 ; 18 Jan 2013 05:42:21 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 18 Jan 2013 06:42:18 +0100 From: Stefan Santesson To: Piyush Jain , 'Denis Pinkas' , 'Peter Rybar' Message-ID: Thread-Topic: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients In-Reply-To: <03e301cdf33d$6945a920$3bd0fb60$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441336142_6178239" Cc: pkix@ietf.org Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients 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, 18 Jan 2013 05:42:25 -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_3441336142_6178239 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > For reference, the 2 CAs who have the biggest share of SSL server market > currently respond with unsigned UNAUTHORIZED and TRY_LATER for serial numbers > that are not associated with a certificate. And a third one who provides > managed PKI hosting uses a third party responder which returns TRY_LATER for > non-existent certificates. This is important. The update proposal does not change this. The curent draft proposal just allows the revoked response. It does not mandate it. The current draft allows communities, such as the CAB forum to craft a strategy for their responders that suits the needs of their infrastructure and threats. It gives them one more tool in their toolbox. So in this particular case, I would leave it up to the CAB Forum to decide what SSL cert responders should do to operate in the Web PKI environment. /Stefan --B_3441336142_6178239 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

= For reference, the 2 CAs who have the biggest share of SSL server market cur= rently respond with unsigned UNAUTHORIZED and TRY_LATER for serial numbers t= hat are not associated with a certificate. And a third one who provides mana= ged PKI hosting uses a third party responder which returns TRY_LATER for non= -existent certificates.

This i= s important.

The update proposal does not change th= is.
The curent draft proposal just allows the revoked response. It= does not mandate it.

The current draft allows comm= unities, such as the CAB forum to craft a strategy for their responders that= suits the needs of their infrastructure and threats.
It gives the= m one more tool in their toolbox.

So in this partic= ular case, I would leave it up to the CAB Forum to decide what SSL cert resp= onders should do to operate in the Web PKI environment.

=
/Stefan



--B_3441336142_6178239-- From stefan@aaa-sec.com Thu Jan 17 23:10: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 DFD8621F8956 for ; Thu, 17 Jan 2013 23:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.364 X-Spam-Level: X-Spam-Status: No, score=-101.364 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 Xoz2+G4fjd-D for ; Thu, 17 Jan 2013 23:10:30 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id CB50F21F87FA for ; Thu, 17 Jan 2013 23:10:29 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C1DFE12C42A for ; Fri, 18 Jan 2013 08:08:39 +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 gHc4t4t49g-D for ; Fri, 18 Jan 2013 08:08:38 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BFF9A12C42D for ; Fri, 18 Jan 2013 08:08:38 +0100 (CET) Received: (qmail 76757 invoked from network); 18 Jan 2013 07:08:38 -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 ; 18 Jan 2013 07:08:38 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 18 Jan 2013 08:08:36 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: New draft 09 on rfc2560bis In-Reply-To: <057501cdee89$4a987c90$dfc975b0$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] New draft 09 on 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, 18 Jan 2013 07:10:31 -0000 I have just submitted a new draft 09 to accommodate some nits and comments. Great thanks to Piyish Jain for your review, which digged up some things. I'll respond to how I dealt with your comments below; On 1/9/13 5:49 PM, "Piyush Jain" wrote: >Hi list, > >I just finished reviewing the latest draft. Here is the summary. > >1) Text from Section 1 >"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." >However, section 2.2 does not have a corresponding definition for >"non-issued certificates" It now is more clear on the use of this term. > >2a) Text from Section 2.2 >"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." > >Switching the subject (state) in the second sentence makes the text >confusing. Also "never been issued" is ambiguous. Please see the comments >in >Authorized responder section >Here is an alternative proposal. >"The "revoked" state indicates that either the certificate has been >revoked >(either permanently or temporarily (on hold)) or the associated CA has no >record of issuance of the requested certificate." I have to a major extent adopted your wording. > >An even better alternative would be to allow for revoked to be extended >for >any bad certificate and have the extended revoked extension specify the >actual meaning by including a OID. This document can define a OID for one >of >the meanings (fraudulently issued as revoked). This leave room for >extensibility without the need to change the main document should someone >come up with another requirement to return revoked as a negative proof. > >2b) Text from section 2.2 >"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. >" > >- IMO the above text belongs in the extension specification for extended >revoked. I disagree. The extension text is helpful for understanding the extension and its syntax. Section 2.2. Gives you the context for using it and other similar guidance related to responding revoked to non-issued certs. >- I repeat that use of non-issued is ambiguous. It will help to define >what >non-issued is and to explicitly mention that a certificate signed using >the >CA key can be non-issued as per this specification. >- Why force the responder to include optional revocation reason field. >Change MUST to MAY and change the text to say that if revocation reason is >included it must be set to 6. >-Reference to "revocation date" in above text is dangling. It should be >changed to "revocationTime in RevokedInfo" > >3) Text from section 2.5 >"nextUpdate: The time at or before which newer information will be >available >about the status of the certificate" > >4.2.2.1 states - " The thisUpdate and nextUpdate fields define a >recommended validity interval. This interval corresponds to the >{thisUpdate, nextUpdate} interval in CRLs" >SO guidance needs to be provided for setting nextUpdate in case where >extended revoked for "non-issued" is used because the response does not >correspond to a CRL. No, the text is correct. These parameters still corresponds to the meaning they have in CRL:s. > >4) Texts from Section 4.2.2.2 >"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." Updated the text > >The above text introduces a paradox if a response contains revoked for >non-issued certificates. >Any response that implies that certificate was not issued by the CA makes >that response non authoritative because the response is not issued by a >responder that is issued by the same CA as the one who issued the paylod >certificate. >One way to address this could be change all references to "issued" to >"signed". We should also explicitly call out that "signed" and "issued" >are >not synonymous as per this draft. >Please note that "issued" is used extensively in section 4.2.2.2 > >5) Section 4.4.2 - CRL references >This section needs to be updated with a note that this extension is >incompatible with extended revoked and should not be included if extended >revoked is included in the response. This is being made clear in 2.2 > >6) Section 4.4.5 - CRL Entry extensions >This section needs to include a note that "invalidityDate" extension >should >not be included as single response extension if extended revoked is being >returned. Good, added in 2.2 > >7) 4.4.8 - Extended revoked definition >If this extension is used to indicate responder capability, it should be >included with all responses, not just revoked. >If it is used to indicate changed meaning of revoked, it should be a >single >response extension. > >Also, IMO it is a misnomer to call it extended revoked. It might be more >meaningful to call it "Fraudulently Issued as revoked". Other option is to >keep the name extended revoked but allow for adding a list of OIDs that >represent the changed meaning of revoked. In current case it would be a >new >id - "id-pkix-ocsp-fraudulently-issued-as-revoked". In future someone >could >add id-pkix-ocsp-revoked-expired-as-revoked or >id-pkix-ocsp-ugly-moustache-as-revoked through an add-on RFC. Made no changes on this at this point. > >8) Section 2.5 - Response pre-production. >I think it will be useful to indicate that if responder choses to issue >revoked for fraudulently issued response pre-production becomes >computationally infeasible. >The note could be added here or in the section defining extended revoked. Yes, issuing pre-produced responses for any possible serial number is impossible. I had a discussion with Scott Rea where he showed that this could still be used in pre-production environment as response to a non-issued serial-number that is asked for repeatedly in the network. Then a reproduced response for this serial number could be produced as some kind of mitigation strategy. Some words of this kind would be good in the draft but is currently no included. /Stefan > >Thoughts/comments are welcome. > >-Piyush >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Friday, January 04, 2013 1:58 AM >> To: pkix@ietf.org >> Subject: [pkix] 2560bis WGLC >> >> Forwarding Steve's WGLC on RFC 2560bis. >> (It was misaddressed) >> >> >> On 1/2/13 4:43 PM, "Stephen Kent" wrote: >> >> >Folks, >> > >> >Stefan has just published the long-awaited 2560bis update, and has >> >requested WGLC. >> > >> >Let's begin a slightly longer WGLC, to accommodate those who may be on >> >a post-New year vacation. >> > >> >the WGLC will end on 1/20/13. >> > >> >Steve >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From bergtau@gmail.com Fri Jan 18 11:26:51 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 0A02021F870A for ; Fri, 18 Jan 2013 11:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, 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 5BWWA6abkWCE for ; Fri, 18 Jan 2013 11:26:50 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6580921F8684 for ; Fri, 18 Jan 2013 11:26:50 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id fa10so2292216pad.34 for ; Fri, 18 Jan 2013 11:26:50 -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:content-type; bh=1RpJkvULkc1VPZMe0St65r+FNM+iga8qak9dCO1qKDY=; b=DEwpT34X/F2lozsUsg37A6HMZIy1aZI6/2gweJxvNvHtDPkZYT5L5S7kGEo71tusBH vMJnwNhhs5oBFui3iG+xrbwnjWtdB05Fw6qv7HFmQ71GIQnmp/2xIoYuVkzaCyi+1gHz ulUXA7KxNhUEDJevol7/ZVfUZxi2wblbgnz3OHxcW5dplir3Q57dl7weAWN6nDaSxllU QJLlUoUHQK5eRSZnClLf5nFHkRmvgzysmqESMusC1EZsK0NWrbayRFLvr6StfNmKn4/0 ZetXVUDcF+G0qXMTRNxYjYJ+PytAFZKxZZQDU+IZb4aKzR7PhYFcyYzYebwX8ijTcxeS 1BBA== MIME-Version: 1.0 X-Received: by 10.68.253.230 with SMTP id ad6mr8335219pbd.84.1358537210083; Fri, 18 Jan 2013 11:26:50 -0800 (PST) Received: by 10.66.81.37 with HTTP; Fri, 18 Jan 2013 11:26:49 -0800 (PST) In-Reply-To: References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> <50C73BDF.4030508@gmail.com> <0443f8e7501cc114087a0b9a0631e49b.squirrel@www.trepanning.net> Date: Fri, 18 Jan 2013 14:26:49 -0500 Message-ID: From: Michael Jenkins To: "pkix@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e0bffd23a6e04d395178e Subject: Re: [pkix] EST trust anchor definition 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, 18 Jan 2013 19:26:51 -0000 --047d7b2e0bffd23a6e04d395178e Content-Type: text/plain; charset=ISO-8859-1 Dan, If the device is an enterprise-owned, special purpose device (like a router), what you say probably applies. If the device is a personally-owned and managed BYOD type device, then 1) the TA database won't ever just have one TA in it - even if you make it only have one, it'll have a bunch again after the next vendor system update; 2) as unlikely as it is that the device operator will bother to manage the TAs, even a savvy operator isn't going to remove all of the TAs that don't relate to EST (that would make the device useless for purchasing tunes); and 3) it's possible that the device won't even allow the operator to manage the TAs in the first place. Say the device is a wireless device, and comes to the edge of a wireless network to which the operator wants to connect. It receives a cert from an EST server - who's it signed by? The preferred CA - or TurkTrust (to pick on the latest poster-child for unfortunate judgement in CA behavior)? With a current NSS, Win, or Apple trust anchor database, it doesn't matter and there will be no indication that it wasn't your preferred one, it'll validate just fine. In fact, since what's supposed to be in the "right" cert is obtainable by issuing a /CACerts, the "wrong issuer but validates anyway" cert can even have the right URI in it. [So you might want to check the language about trusted URI while you're at it...] As crucial as TA management is, I actually think this is an easy fix for EST. The TA database is commonly a system resource. There really isn't any need to refer to the TA database or get into the management of it. Simply call out that there will be one specific TA that will be used for EST - whether that TA happens to come from the device vendor, is a public CA root cert, or is an enterprise-owned CA public key, it doesn't matter - and make the client responsible for ensuring that that TA is used. As you note, one way to do this is to only have one TA. Another way is to make a pointer to the right TA a configuration detail of the client (yeah, there's a configuration data integrity issue, but that's significantly more difficult than the vector described in the paragraph above). Then, the fact that that TA resides in and is managed as a datum in a database is irrelevant. (Well, not completely irrelevant of course but can be left to the device management policy.) Mike --047d7b2e0bffd23a6e04d395178e Content-Type: text/html; charset=ISO-8859-1
Dan,

If the device is an enterprise-owned, special purpose device (like a router), what you say probably applies. If the device is a personally-owned and managed BYOD type device, then 1) the TA database won't ever just have one TA in it - even if you make it only have one, it'll have a bunch again after the next vendor system update; 2) as unlikely as it is that the device operator will bother to manage the TAs, even a savvy operator isn't going to remove all of the TAs that don't relate to EST (that would make the device useless for purchasing tunes); and 3) it's possible that the device won't even allow the operator to manage the TAs in the first place.

Say the device is a wireless device, and comes to the edge of a wireless network to which the operator wants to connect. It receives a cert from an EST server - who's it signed by? The preferred CA - or TurkTrust (to pick on the latest poster-child for unfortunate judgement in CA behavior)? With a current NSS, Win, or Apple trust anchor database, it doesn't matter and there will be no indication that it wasn't your preferred one, it'll validate just fine. In fact, since what's supposed to be in the "right" cert is obtainable by issuing a /CACerts, the "wrong issuer but validates anyway" cert can even have the right URI in it. [So you might want to check the language about trusted URI while you're at it...]

As crucial as TA management is, I actually think this is an easy fix for EST. The TA database is commonly a system resource. There really isn't any need to refer to the TA database or get into the management of it. Simply call out that there will be one specific TA that will be used for EST - whether that TA happens to come from the device vendor, is a public CA root cert, or is an enterprise-owned CA public key, it doesn't matter - and make the client responsible for ensuring that that TA is used. As you note, one way to do this is to only have one TA. Another way is to make a pointer to the right TA a configuration detail of the client (yeah, there's a configuration data integrity issue, but that's significantly more difficult than the vector described in the paragraph above). Then, the fact that that TA resides in and is managed as a datum in a database is irrelevant. (Well, not completely irrelevant of course but can be left to the device management policy.)

Mike


--047d7b2e0bffd23a6e04d395178e-- From denis.pinkas@bull.net Sun Jan 20 08:12:56 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 7BFE821F855C for ; Sun, 20 Jan 2013 08:12:56 -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 iQVf7kbiQ7OL for ; Sun, 20 Jan 2013 08:12:56 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2854621F8552 for ; Sun, 20 Jan 2013 08:12:53 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id DC6AD1CECB; Sun, 20 Jan 2013 17:12:52 +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 2013012017124791-30265 ; Sun, 20 Jan 2013 17:12:47 +0100 Message-ID: <50FC177A.9050800@bull.net> Date: Sun, 20 Jan 2013 17:12:42 +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 , Stephen Kent X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 20/01/2013 17:12:52, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 20/01/2013 17:12:52, Serialize complete at 20/01/2013 17:12:52 Content-Type: multipart/alternative; boundary="------------040102030900050501040407" 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: Sun, 20 Jan 2013 16:12:56 -0000 This is a multi-part message in MIME format. --------------040102030900050501040407 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Please find 32 comments on draft-ietf-pkix-rfc2560bis 1.The document states: ** * "This Internet-Draft is submitted to IETF in full conformance with the* * provisions of BCP 78 and BCP79."* BCP 78 is RFC 3978. However, this draft, if transformed into an RFC, does not meet the requirements that are present in RFC 3978. RFC 3978 states: *"4.2.Granting of Rights and Permissions* ** *By submission of an RFC Editor Contribution, each person actually* *submitting the RFC Editor Contribution, and each named co-* *Contributor, is deemed to agree to the following terms and* *conditions, and to grant the following rights, on his or her own* *behalf and on behalf of the organization the Contributor represents* *or is sponsored by (if any) when submitting the RFC Editor* *Contribution.* ** *(...)* *7.1.Rights Granted in IETF Contributions* ** *The IETF/ISOC must obtain the right to publish an IETF Contribution* *as an RFC or an Internet-Draft from the Contributors.* ** *(...)* ** *7.2.Rights to use Contributed Material* ** *Because, under the laws of most countries and applicable* *international treaties, copyright rights come into existence whenever* *a work of authorship is created (but see Section 8 below regarding* *public domain documents), and IETF cannot make use of IETF* *Contributions if it does not have sufficient rights with respect to* *these copyright rights, it is important that the IETF receive* *assurances from all Contributors that they have the authority to* *grant the IETF the rights that they claim to grant.Without this* *assurance, IETF and its participants would run a greater risk of* *liability to the owners of these rights.* ** *To this end, IETF asks Contributors to give the assurances in Section 3.4 above."* Some of the contributors mentioned for this document have not sent any message related to OCSP for years, in particular: Michael Myers, Rich Ankney, Slava Galperin, and Carlisle Adams. The RFC editor will send an email to every author. Unfortunately, he will never receive an email from Rich Ankney because he has no email address in the "other world". http://www.rfc-editor.org/pubprocess.html#Authors states: "Authors' Final Review (AUTH48 State) Once an RFC has been edited and is ready for publication, the author(s) are given "48 hours" (in practice, this often stretches over weeks) to look over their document for errors, editorial and otherwise. We DO NOT make changes to RFCs once they have been published, so please look over your document carefully. Upon approval by all authors, the RFC will be published. The AUTH48 notification message sent to authors asks that they review the entire document, paying particular attention to: * IANA considerations updates (if applicable), * contact information, and * references. If an author is no longer available, there are several options (as listed in the FAQ http://www.rfc-editor.org/rfcfaq.html#missingauthor). Indefinite delays are not allowed, but when there is a choice, the RFC Editor would in general prefer to publish it right than to publish it early." http://www.rfc-editor.org/rfcfaq.html#missingauthor states: " *One of the authors is no longer available; how do we move forward?* We recommend one of the following paths forward: 1.The author can be removed as an author and moved to the Acknowledgements section. 2.The author can be removed as an author and moved to a Contributors section. 3.An AD can approve the document in place of the unavailable author. (See the IESG Statement on AUTH48 State .) Option 3 is typically used in instances where the missing author made significant contributions to the document, so the other authors are not feel comfortable removing the individual from the author list". The IESG Statement on AUTH48 states (5 Jan 2006): "The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks". *It looks more reasonable to anticipate the problem and to apply the path numbered 1, hence to move the names ** **of the original contributors to RFC **2560 in**to the Acknowledgments section. * Obviously, the consequence is that there will be far less people contributing to this draft: Stefan seems to be the single author/contributor, ... which is what he wanted : - he did not answered positively when, last summer, I sent him a private email proposing to share the editing of the draft. - after a meeting in London, he did not either responded at two proposals for a phone call. Most of the following comments take advantage of draft-pinkas-rfc2560bis-03 which was built after a detailed examination of the defects of RFC 2560. The writing of this draft took me about 40 hours of work. 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". 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.* 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. * 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.* 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. 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.* 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.* 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.* 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.** 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. 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. 12.Remainder: Section 2.6 should be deleted (see comment number 5). 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. 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. 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.* 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. 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.* 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. 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) }* 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.** ** 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.* 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:* 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.* 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* ** 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. ** 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.* ** ** 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.* ** ** 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.* 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.* 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.* End of comments Denis --------------040102030900050501040407 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1

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

 

1. The document states:

 

   “This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.”

 

BCP 78 is RFC 3978.

 

However, this draft, if transformed into an RFC, does not meet the requirements that are present in RFC 3978.

 

RFC 3978 states:

 

“4.2.  Granting of Rights and Permissions

 

   By submission of an RFC Editor Contribution, each person actually

   submitting the RFC Editor Contribution, and each named co-

   Contributor, is deemed to agree to the following terms and

   conditions, and to grant the following rights, on his or her own

   behalf and on behalf of the organization the Contributor represents

   or is sponsored by (if any) when submitting the RFC Editor

   Contribution.

 

(…)

 

7.1.  Rights Granted in IETF Contributions

 

   The IETF/ISOC must obtain the right to publish an IETF Contribution

   as an RFC or an Internet-Draft from the Contributors.

 

(…)

 

7.2.  Rights to use Contributed Material

 

   Because, under the laws of most countries and applicable

   international treaties, copyright rights come into existence whenever

   a work of authorship is created (but see Section 8 below regarding

   public domain documents), and IETF cannot make use of IETF

   Contributions if it does not have sufficient rights with respect to

   these copyright rights, it is important that the IETF receive

   assurances from all Contributors that they have the authority to

   grant the IETF the rights that they claim to grant.  Without this

   assurance, IETF and its participants would run a greater risk of

   liability to the owners of these rights.

 

   To this end, IETF asks Contributors to give the assurances in Section
   3.4 above.”

 

Some of the contributors mentioned for this document have not sent any message related to OCSP for years, in particular:
Michael Myers, Rich Ankney, Slava Galperin, and Carlisle Adams.

 

The RFC editor will send an email to every author. Unfortunately, he will never receive an email from Rich Ankney because
he has no email address in the “other world”.

 

http://www.rfc-editor.org/pubprocess.html#Authors states:

 

“Authors' Final Review (AUTH48 State)

Once an RFC has been edited and is ready for publication, the author(s) are given "48 hours" (in practice, this often stretches over weeks)
to look over their document for errors, editorial and otherwise. We DO NOT make changes to RFCs once they have been published, so
please look over your document carefully. Upon approval by all authors, the RFC will be published.

 

The AUTH48 notification message sent to authors asks that they review the entire document, paying particular attention to:

 

  • IANA considerations updates (if applicable),
  • contact information, and
  • references.

 

If an author is no longer available, there are several options (as listed in the FAQ http://www.rfc-editor.org/rfcfaq.html#missingauthor).
Indefinite delays are not allowed, but when there is a choice, the RFC Editor would in general prefer to publish it right than to publish it early.”

 

http://www.rfc-editor.org/rfcfaq.html#missingauthor states:

 

" One of the authors is no longer available; how do we move forward?

 

We recommend one of the following paths forward:

 

1.       The author can be removed as an author and moved to the Acknowledgements section.

2.       The author can be removed as an author and moved to a Contributors section.

3.       An AD can approve the document in place of the unavailable author. (See the IESG Statement on AUTH48 State.)

 

Option 3 is typically used in instances where the missing author made significant contributions to the document,
so the other authors are not feel comfortable removing the individual from the author list”.

 

The IESG Statement on AUTH48 states (5 Jan 2006):

 

“The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor
waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors
have not responded after a reasonable time, typically two weeks”.

 

It looks more reasonable to anticipate the problem and to apply the path numbered 1, hence to move the names
of the original contributors to RFC 2560 into the Acknowledgments section.

 

Obviously, the consequence is that there will be far less people contributing to this draft:


Stefan seems to be the single author/contributor, … which is what he wanted :

  - he did not answered positively when, last summer, I sent him a private email proposing to share the editing of the draft.
  - after a meeting in London, he did not either responded at two proposals for a phone call.

 

Most of the following comments take advantage of draft-pinkas-rfc2560bis-03 which was built after a detailed examination
of the defects of RFC 2560. The writing of this draft took me about 40 hours of work.

 

 

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

 
 

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.

 

 

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.

 

 

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.

 

 
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.

 

 

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.

 

 

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. 
 

 

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.

 
 

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.

 

 

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.

 

 

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

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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

 

 

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.

 

 

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.

 

 

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:

 

 

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.

 

 

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

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

End of comments


Denis

 

 --------------040102030900050501040407-- From stefan@aaa-sec.com Sun Jan 20 08:43: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 1536721F8583 for ; Sun, 20 Jan 2013 08:43:15 -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 PtC8E-mOaiSY for ; Sun, 20 Jan 2013 08:43:14 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A67E321F857D for ; Sun, 20 Jan 2013 08:43:10 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 80F891E3BA67 for ; Sun, 20 Jan 2013 17:43:07 +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 osM6DLG8P-w7 for ; Sun, 20 Jan 2013 17:42:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 969F512D0E3 for ; Sun, 20 Jan 2013 17:39:08 +0100 (CET) Received: (qmail 73130 invoked from network); 20 Jan 2013 16:39:06 -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 ; 20 Jan 2013 16:39:06 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 20 Jan 2013 17:39:01 +0100 From: Stefan Santesson To: Denis Pinkas , Stephen Kent Message-ID: Thread-Topic: [pkix] Review of 2560-bis draft 8. Answer to WGLC In-Reply-To: <50FC177A.9050800@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441548346_12598899" 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: Sun, 20 Jan 2013 16:43: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_3441548346_12598899 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, I will go trough the rest of your comments later, but I just wanted to respond quicklyto the first. This is an issue where I have thoroughly discussed the matter wth Sean Turner. He has approved the current way of including the past editors. I have received permission and support from all of those who are still aliv= e to have them as co-editors. I wil not further comment on your issue 1, but will leave it to Sean and Steve to espond to this. I'm sorry if you feel that you have not got enough special treatment. I hav= e responded to you to the best of m abilities and capacity. /Stefan 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 . Answer to WGLC > =20 > =20 >=20 > Please find 32 comments on draft-ietf-pkix-rc2560bis > =20 > =20 > =20 > 1. The document states: > =20 > =20 > =20 > =B3This Internet-Draft is submitted to IETF in full conformance with the > =20 > provisions of BC 78 and BCP 79.=B2 > =20 > =20 > =20 > BCP 78is RFC 3978. > =20 > =20 > =20 > However, this draft, if transformed into an RFC, does not met the > requirements that are present in RFC 3978. > =20 > =20 > =20 > =20 > RFC 398 states: > =20 > =20 > =20 > =B34.2. Granting of Rights and Permissions > =20 > =20 > =20 > By submission of an RFC Editor Contribution, each person actually > =20 > submiting the RFC Editor Contribution, and each named co- > =20 > Contributor, is deemed to agree to the follwing terms and > =20 > conditions, and to grat the following rights, on his or her own > =20 > behalf and on behalf of the oganization the Contributor represents > =20 > or is sponsored by (if any) wen submitting the RFC Editor > =20 > Contribution. > =20 > =20 > =20 > (=8A) > =20 >=20 > =20 > 7.1. Rights Granted in IETF Contributions > =20 > =20 > =20 > The IETF/ISOC must obtain theright to publish an IETF Contribution > =20 > as an RFC or an Internet-Draftfrom the Contributors. > =20 > =20 > =20 > (=8A) > =20 > =20 > =20 > 7.2. Rights to use ontributed Material > =20 > =20 > =20 > Because, under the laws of most countries and applicable > =20 > interational treaties, copyright rights come into existence whenever > =20 > a wrk of authorship is created (but see Section 8 below regarding > =20 > public domain documents), and IETF annot make use of IETF > =20 > Contributions if it does not have suffcient rights with respect to > =20 > these copyright rights, it is impotant that the IETF receive > =20 > assurances from all Contibutors that they have the authority to > =20 > grant the IETF the rights that the claim to grant. Without this > =20 > assurance, IETF and its partcipants would run a greater risk of > =20 > liability to the owners of these rights. > =20 > =20 > =20 > To this end, IETF asks Contributors to gie the assurances in Section > 3.4 above.=B2 > =20 > =20 > =20 > Some of the contributors mentioned for thi document have not sent any mes= sage > reated to OCSP for years, in particular: > Michael Myers, Rich Ankney, Slava Galperin,and Carlisle Adams. > =20 > =20 > =20 > The RFC editor will send an email to every author. Unfortunately, he will > never receive an email from ich Ankney because > he has no email address in the =B3other world=B2. > =20 > =20 > =20 > http://www.rfc-editororg/pubprocess.html#Authors states: > =20 > =20 > =20 > =B3Authors' Final Review (AUTH48 State) > =20 > Once an RFC has been edited ad is ready for publication, the author(s) ar= e > given "48 hours" (in practice, this often stretches over weeks) > to look over their document for errors, editorial and otherwise. e DO NO= T > make changes to RFCs once they have been published, so > please look over your document carefully. Upon approval by all authors, = the > RFC will be published. > =20 >=20 > =20 > =20 >=20 > The AUTH48 notification messag sent to authors asks that they review the > entire documen, paying particular attention to: > =20 >=20 > =20 > =20 > * IANA considerations updates (if applicable), > * contact information, and > * references.=20 > =20 >=20 > =20 > =20 >=20 > If an author is no longer available, there are several options (as listed= in > the FAQ > http://www.rfc-editor.org/rfcfaq.html#missingauthor). > Indefinite delays are not allowed, but when there is a choice, the RFC E= ditor > would in general prefer to publish it right than to publish it early.=B2 > =20 >=20 > =20 > =20 >=20 > http://www.rfc-editor.org/rfcfaq.html#missingauthor states: > =20 > =20 > =20 > " One of the authors is no longer available; how do we move forward? > =20 > =20 > =20 > We recommend one of the following paths forward: > =20 > =20 > =20 > 1. The author can be removed as an author and moved to the > Acknowledgements section. > =20 > 2. The author can be removed as an author and moved to a Contributo= rs > section.=20 > =20 > 3. An AD can approve the document in place of the unavailable autho= r. > (See the IESG Statement on AUTH48 State > .) > =20 > =20 > =20 > Option 3 is typically used in instances where the missing author made > significant contributions to the document, > so the other authors are not feel comfortable removing the individual fr= om > the author list=B2. > =20 > =20 > =20 > The IESG Statement on AUTH48 states (5 Jan 2006): > =20 >=20 > =20 > =20 >=20 > =B3The IESG has decided that as of now, any IESG-approved drafts that enter= the > AUTH48 state, where the RFC Editor > waits for final text approval from all listed authors, may be released o= n the > responsible AD's authority if any authors > have not responded after a reasonable time, typically two weeks=B2. > =20 >=20 > =20 > =20 > It looks more reasonable to anticipate the problem and to apply the path > numbered 1, hence to move the names > of the original contributors to RFC 2560 into the Acknowledgments sectio= n. > =20 > =20 > =20 > Obviously, the consequence is that there will be far less people contribu= ting > to this draft:=20 > =20 > =20 >=20 > Stefan seems to be the single author/contributor, =8A which is what he wan= ted : > =20 > - he did not answered positively when, last summer, I sent him a privat= e > email proposing to share the editing of the draft. > - after a meeting in London, he did not either responded at two propos= als > for a phone call. > =20 > =20 > =20 > Most of the following comments take advantage of draft-pinkas-rfc2560bis-= 03 > which was built after a detailed examination > of the defects of RFC 2560. The writing of this draft took me about 40 h= ours > of work.=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 periodic CRL, it > =20 > may be necessary to obtain 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 applications to > =20 > determine the (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 that OCPS necessarily > provides =B3timely information=B2. > =20 > =20 > =20 > Proposed text replacement: > =20 > =20 > =20 > The Online Certificate Status Protocol (OCSP) is a client-server > =20 > protocol which enables applications to obtain the revocation status > =20 > of one or more certificates either "good", "revoked", or "unknown". > =20 > =20 > =20 > The revocation status may be provided by the server either using a > =20 > real time access to a database of issued certificates, or 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 certificates, or using 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, whereas in 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 > 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 status. > =20 > =20 > =20 > Thus is insufficient for an overview. More details are needed to know wha= t 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. > =20 > =20 > =20 > Proposed text replacement: > =20 > =20 > =20 > When using OCSP, an OCSP client issues 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 responder provides a response. > =20 > =20 > =20 > This document 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 > OCSP may also provide additional status information using > =20 > extensions.=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 conditions 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 needed by the responder. > =20 > =20 > =20 > If 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 > =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 the certificate in question > =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, indicating > =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 diff= erent > terms and conditions. > If some one picks a sentence in one paragraph rather than another, it wi= ll > lead to a different conclusion. > RFCs are supposed to be clear. > =20 > =20 > =20 > On page 10, the current text states in section 2.6 OCSP Signature Authori= ty > Delegation states: > =20 > =20 > =20 > The key that signs a certificate's status information 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 for extendedKeyUsage in the OCSP signer's > =20 > certificate. This certificate 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 Responders=B2 dea= ling > 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 the > =20 > same key that signed the certificate. It is necessary however to > =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 or it MAY explicitly 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 response signer's certificate. This > =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 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 > The last sentence above in yellow is the key sentence that is missing in = the > two other sections. > =20 > =20 > =20 > Most implementations only support the case where the OCSP Responder recei= ves > an OCSP certificate that is signed by the same key > that was used to sign the target certificate. They do not support the cas= e > where the OCSP Responder receives an OCSP certificate > that is signed by a key that is different from the one that was used to s= ign > the target certificate. > =20 > =20 > =20 > It is inappropriate to have three sections dealing with the same topic wi= th 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, indicating > =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 tha= t 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 with t= he > same sentence:=20 > =20 > =20 >=20 > =B3The key that signs a certificate's status information need not be the s= ame > 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 detail= s. > =20 > =20 > =20 > =20 > =20 > 6. Page 7, the text states: > =20 > =20 > =20 > A definitive response message is composed of: > =20 > =20 > =20 > - version of the response syntax > =20 > - name of the responder > =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 does not fit with the ASN.1 syntax which is detailed lat= er > on, and in particular: > =20 > =20 > =20 > ResponseData ::=3D SEQUENCE { > =20 > version [0] EXPLICIT Version DEFAULT 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 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 > 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 an= d how > they should be processed. > =20 > There are also no explanations on how to process a single response and ho= w to > verify that it is its presence within the signed structure > is valid or not valid. This is a major deficiency of the current descrip= tion > 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 the > =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 correctly > =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 > 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 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 i= s > 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 (b= ut > 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 history = of > the associated CA =B3does not capture the fact > that it could be issued in the future, hence why using =B3not yet been use= d=B2 > would be more appropriate. > =20 > =20 > =20 > Finally, it would have been more logical to use =B3unknown=B2. So it is impor= tant > to add a note to explain why we have chosen that case for =B3legacy clients= =B2, > otherwise the people who have not participate to the exchanges will not > 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 > 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 > As already explained on the PKIX list, using the revocation reason > certificateHold is not appropriate > because it changes the meaning of certificateHold. > =20 > =20 > =20 > The extended revoked definition response extension is a means to signal t= hat > it not a true certificate hold but a =B3not issued certificate=B2. > Legacy applications cannot take advantage of it. > =20 > =20 > =20 > 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. > =20 > =20 > =20 > It is possible to use another enumeration for signalling that specific ca= se: > =20 > notIssuedOrIrregularlyIssued (7). > =20 > =20 > =20 > Thus for new applications it would be much better to use > notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list. > =20 > =20 > =20 > The above sentence uses the text: > =20 > =20 > =20 > =B3a status request for a non-issued certificate=B2 > =20 > =20 > =20 > whereas it would be more appropriate to state: > =20 > =20 > =20 > =B3a status request for a serial number which has not been used by the CA o= r > used irregularly to issue a certificate=B2. > =20 > =20 > =20 > Placing the ASN.1 description at such a place in the document is inapprop= riate > since the ASN.1 structures have not yet been described. > Thus only the functional aspects should be mentioned, but not the ASN.1 > implications. > =20 > =20 > =20 > BTW, the description should follow the same order as the ASN.1. This is n= ot > the case.=20 > =20 > =20 > =20 > This text should be deleted from this section and the appropriate text sh= ould > be added when the parameters of the response are described. > =20 > =20 > =20 > The text proposed in the previous comment should be sufficient at this ti= me of > reading. > =20 > =20 > =20 > In addition, section 4.4.8 Extended Revoked Definition should be deleted= . > =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 k= now > 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. > =20 > =20 > The text from this section is not aligned with the text that is present i= n > 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 > 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 different > places. > =20 > =20 > =20 > Delete section 2.4. See comment number 19 for the description of these > parameters. > =20 > =20 > =20 > =20 > =20 > 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. > =20 > =20 > =20 > =20 > =20 > 12. Remainder: Section 2.6 should be deleted (see comment number 5). > =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 follo= wing: > =20 > =20 > =20 > The relying party must verify that the singleResponse is signed by a resp= onder > which is entitled to do so. > =20 > =20 > =20 > a) If the CA key has been compromised and if the response is signed by th= at CA > key then the singleResponse will be discarded > when performing the certification path validation whatever the content o= f the > response may be. > =20 > =20 > =20 > b) If the CA key which has issued the OCSP certificate has been compromis= ed > 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. > =20 > =20 > =20 > =20 > =20 > Security must be provided using the validation of the certification path.= Thus > it does not matter what the OCSP responder states. > =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 will > =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 t= he > protocol description has not yet been made, > since it is the next section 4. Its text is not correct either. > =20 > =20 > =20 > This description does not take into account the fact that a BasicOCSPResp= onse > may contain one or several SingleResponses. > In particular, the sentence =B3The signer is currently authorized to sign = the > response=B2 is misleading because a signer > may be authorized to include some SingleResponses but not necessarily al= l of > them.=20 > =20 > =20 > =20 > The appropriate explanations should be done after the description of the > response, when describing the processing of the response. > =20 > =20 > =20 > Delete that section. > =20 > =20 > =20 > =20 > =20 > 15. On page 12, after the ASN.1 description, the only parameters which ar= e > 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 > following text is proposed: > =20 > =20 > =20 > requestorName is optional and MAY be used by the server for access > =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 > suggests several useful extensions. Additional extensions MAY be > =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 > hash shall be calculated over the DER encoding of the issuer's name > =20 > field in the certificate being checked. > =20 > =20 > =20 > issuerKeyHash is the hash of the Issuer's public key. The hash > =20 > shall be calculated over the value (excluding tag and length) of the > =20 > subject public key field in the issuer's certificate. The hash > =20 > algorithm used for both these hashes, is identified in > =20 > hashAlgorithm. > =20 > =20 > =20 > The primary reason to use the hash of the CA's public key in > =20 > addition to the hash of the CA's name, to identify the issuer, > =20 > is that it is possible that two CAs may choose to use the same > =20 > name (uniqueness in the Name is a recommendation that cannot be > =20 > enforced). Two CAs will never, however, have the same public key > =20 > unless the CAs either explicitly decided to share their private > =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 > status is being requested. > =20 > =20 > =20 > singleRequestExtensions is OPTIONAL. Any specific extension is > =20 > OPTIONAL. The critical flag SHOULD NOT be set for any of them. > =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 > 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 issuerKeyHash= and > thus is no more needed. > =20 > =20 > =20 > The second paragraph has been moved after the description of > requestExtensions. > However, the sentence > =B3 Unrecognized extensions MUST be ignored (unless they have the critical= flag > set and are not understood)=B2 > has been deleted since it applies to the OCSP responder and not to the O= CSP > client. Thus it is no more needed. > =20 > =20 > =20 > 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. > =20 > =20 > =20 > This section should be deleted. > =20 > =20 > =20 > =20 > =20 > 17. There should be a new section called: =B3Requirements for OCSP clients=B2= . > =20 > =20 > =20 > It is important first to re-advertise that the request may be about sever= al > certificates.=20 > Thus it is important to describe the process for building a request, whi= ch is > currently missing. > =20 > =20 > =20 > An OCSP request allows getting in the same response the revocation > =20 > status of one or more certificates. In order to request the > =20 > status of one or more certificates in a single request, OCSP > =20 > clients SHALL follow the following rules : > =20 > =20 > =20 > For each candidate certificate, OCSP clients SHALL verify > =20 > whether there exists a locally defined rule for the certificate in > =20 > question which indicates the URI where the OCSP responder is > =20 > located. If this rule exists, it SHALL be followed. > =20 > =20 > =20 > Otherwise, OCSP clients SHALL determine whether the candidate > =20 > certificate contains an AIA extension with an accessMethod which > =20 > contains the id-ad-ocsp OID. If it is the case, the accessLocation > =20 > contains a uniformResourceIdentifier (URI) which indicates the > =20 > location of the OCSP server for that certificate. > =20 > =20 > =20 > Certificates that contain the same URI MAY be grouped in a single > =20 > request. > =20 > =20 > =20 > Note: For each candidate certificate, when performing the path > =20 > validation algorithm, the OCSP client SHOULD verify that the > =20 > current time is within the validity period of the target > =20 > certificate. Certificates which are outside their validity > =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 > 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 the > =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 veri= fying=20 > every SingleResponse,=20 > it is important to include the relevant certificates which are pertinent= 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 > 19. Page 15. The ASN.1 syntax should be changed in order to be able to us= e the=20 > 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. 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, nextUpdate= and=20 > 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 AS= N.1=20 > parameters, the general text=20 > from section 4.2.2.3 Basic Response is no more need and should be delete= d. > =20 > =20 > =20 > =20 > =20 > 21. 0n page 16, there is a section 4.2.2.2 called =B3Authorized Responders=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 a= nd=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 > 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 the > =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 like = =B3They=20 > 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 > 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 > 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 > 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 > 26. On page 24, text should be added to the Security consideration sectio= n: > =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 verify=20 > =20 > the CRLs itself. Hence the revocation status may not be identical=20 > =20 > in both cases. > =20 > =20 > =20 > =20 > =20 > 27. On page 24, text should be added to the Security consideration sectio= n: > =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 > 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 inappropriate = 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 > 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 annex= es=20 > are being proposed. > =20 > =20 > =20 > Note: The texts are extracted from draft-pinkas-rfc2560bis-03. > =20 > =20 > =20 > =20 > =20 > 30. First annex being proposed. This annex is important, because key roll= over=20 > 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 descr= ibes=20 > the validation of an OCSP response in the past=20 > which is of a particular importance when validating electronic signature= s. > =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 provid= es=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 ord= er to=20 > 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 an=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 > End of comments > =20 > =20 >=20 > Denis > =20 > =20 > =20 > =20 > _______________________________________________ pkix mailing list=20 > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 --B_3441548346_12598899 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>I will go through the rest of your comments later, but I just wanted to = respond quickly to the first.

This is an issue wher= e I have thoroughly discussed the matter with Sean Turner.
He has = approved the current way of including the past editors.

=
I have received permission and support from all of those who are still = alive to have them as co-editors.
I will not further comment on yo= ur issue 1, but will leave it to Sean and Steve to respond to this.

I'm sorry if you feel that you have not got enough special = treatment. I have responded to you to the best of my abilities and capacity.=

/Stefan


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 dra= ft 8. Answer to WGLC

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

 

1. The document states:

 = 

   R=
20;This Internet-Draft is submitted to IETF in full conformance with the
   prov=
isions of BCP 78 and BCP 79.”

 

BCP 78 is RFC 3978.

 

However, this draft, if transformed into an RFC, does not meet the requirements that are present in RFC 3978.

 

RFC 3978 states:

 

“4.2.  Granting of Rights and Permissions=

 

=    By submission of an RFC Editor Contribution, each person actually

=    submitting the RFC Editor Contribution, and each named co-

=    Contributor, is deemed to agree to the following terms and

=    conditions, and to grant the following rights, on his or her own

=    behalf and on behalf of the organization the Contributor represents

=    or is sponsored by (if any) when submitting the RFC Editor=

=    Contribution.

 

(…)<= /o:p>

 

7.1.  Rights Granted in IETF Contributions

 

=    The IETF/ISOC must obtain the right to publish an IETF Contribution

=    as an RFC or an Internet-Draft from the Contributors.

 

(…)<= /o:p>

 

7.2.  Rights to use Contributed Material=

 

=    Because, under the laws of most countries and applicable

=    international treaties, copyright rights come into existence whenever

=    a work of authorship is created (but see Section 8 below regarding

=    public domain documents), and IETF cannot make use of IETF<= /span>

=    Contributions if it does not have sufficient rights with respect to

=    these copyright rights, it is important that the IETF receive

=    assurances from all Contributors that they have the authority to

=    grant the IETF the rights that they claim to grant.  Without this

=    assurance, IETF and its participants would run a greater risk of

=    liability to the owners of these rights.

 

=    To this end, IETF asks Contributors to give the assurances in Section
   3.4 above.&#= 8221;

 

Some of the contributors mentioned for this document have not sent any message related to OCSP for years, in particular:
Michael Myers, Rich Ankney, Slava Galperin, and Carlisle Adams.

 

The RFC editor will send an email to every author. Unfortunately, he will never receive an email from Rich Ankney because
he has no email address in the “other world”.

 

http://w= ww.rfc-editor.org/pubprocess.html#Authors states:

 

“Authors' Final Review (AUTH48 State)

Onc= e an RFC has been edited and is ready for publication, the author(s) are given "48 hours" (in practice, this often stretches over weeks)
to look over their document for errors, editorial and otherwise. We DO NOT make changes to RFCs once they have been published, so
please look over your document carefully. Upon approval by all authors, the RFC will be published.

 

The= AUTH48 notification message sent to authors asks that they review the entire document, paying particular attention to:

 

  • IANA considerations updates (if applicable),
  • contact information, and
  • references.

 

If an author is no longer available, there are several options (as listed in the FAQ http://www= .rfc-editor.org/rfcfaq.html#missingauthor).
Indefinite delays are not allowed, but when there is a choice, the RFC Editor would in general prefer to publish it right than to publish it early.”

 

http://www.rfc-editor.org/rfcfaq.html#missingauthor states:

 

" <= b>One of the authors is no longer available; how do we move forward? <= /a>

 

We recommend one of the following paths forward:

 

1.       The author can be removed as an author and moved to the Acknowledgements section.

2.       The author can be removed as an author and moved to a Contributors section.

3.    &= nbsp;  An AD can approve the document in place of the unavailable author. (Se= e the IESG Statement on AUTH48 State.)

 

Option 3 is typically used in instances where the missing author made significant contributions to the document,
so the other authors are not feel comfortable removing the individual from the author list”. <= /span>

 

The IESG Statement on AUTH48 states (5 Jan 2006):

 

“The IESG has decided that as of now, a= ny IESG-approved drafts that enter the AUTH48 state, where the RFC Editor
waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors
have not responded after a reasonable time, typically two weeks”.

 

It looks more reasonable to anticipate the problem and to apply the path numbered 1, hence to move the names
of the original contributors to RFC 2560 into the Acknowledgments section.

 

Obviously, the consequence is that there will be far less people contributing to this draft:


Stefan seems to be the single author/contributor, … which i= s what he wanted :

  - he did not answered positively when, last summer, I sent him a private email proposing to share the editing of the draft.
  - after a meeting in London, he did not either responded at two proposals for a phone call.

 

Most of the following comments take advantage of draft-pinkas-rfc2560bis-03 which was built after a detailed examination
of the defects of RFC 2560. The writing of this draft took me about 40 hours of work.

 

 

2. The current text from section 2 states:

 

2.  Protocol Overview
 
   In lieu of or as a supplement to check=
ing against a periodic CRL, it
   may be necessary to obtain timely information regarding the<=
/span>
   revocation status of a certificate (cf=
. RFC5280], Section 3.3).
   Examples include high-value funds tran=
sfer 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 ope=
rational requirements of
   providing more timely revocation information than is possible with=

   CRLs and may also be used to obtain ad=
ditional status information. 
 
This text is misleading because readers may think that OCPS nec=
essarily provides “timely information”.
 
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.

 
 

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 t=
o 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:
 

   = When using OCSP, an OCSP client issues a certificate revocation <= /span>

   = 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<= /span>

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

   = providing that status. 

 

   OCSP may also provide additional status information using

   extensions.

 

 

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.

 

 

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:<= /o:p>

 
   -  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 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<=
/b> 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.  Therefor=
e,
            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<=
/span>

      
   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 Respo=
nder 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.

      
 

      
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: 

        

      


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

      
 

      
 

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

      
 

      
   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.

      
 

      
 

      
7. The text states
          on page 7:

      
 

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

      
 
      
=
   -  target cer=
tificate
            identifier

      
=
   -  certificat=
e status
            value

      
=
   -  response v=
alidity
            interval

      
=
   -  optional e=
xtensions

      
 

      
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.

      
 

      
 

      
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. <=
o:p>

      
 

      
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,

      
   eith=
er permanently or temporarily.

      
 

      
   A certificate may be temporarily revok=
ed 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 ser=
ial 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 ̶=
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. =


      
 

      
 

      
9. The text states
          on page 8:

      
 

      
=
   When a
            responder responds revoked to a status request for a non-<=
/o:p>

      
=
   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 stat=
us request for a non-issued certifica=
te” 

      
 

      
whereas it would be more appropriate to state: 

      
 

      
“a stat=
us 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 i=
s inappropriate since the ASN.1 structures have not yet been described. 
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 appropria=
te text should be added when the parameters of the response are described. <=
o:p>

      
 

      
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.
      
 

      
 

      
10. The text states
          on page 8:

      
 

      
2.4 
            Semantics of thisUpdate, nextUpdate and producedAt<=
/o:p>

      
 

      
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.

      
 

      
 

      
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.

      
 

      
 

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

      
 

      
 

      
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.

      
 

      
 

      
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.<=
/span>

      
 
      
=
   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 SingleRespo=
nses. 

          In particular, the sentence
          “The signer is c=
urrently
            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.

      
 

      
 

      
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 has=
h
            

      
   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 <=
/o:p>

      
=
      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.&nb=
sp;
            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.

      
 

      
 

      
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.

      
 

      
 

      
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.&=
nbsp;
            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 NO=
T
            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.

      
 

      
 

      
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.<=
span style=3D"font-size:10.0pt;mso-ansi-language:EN-GB" lang=3D"EN-GB">

      
 

      
 

      
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 &nb=
sp;  [0]     =
EXPLICIT CRLReason
            OPTIONAL }

      
 

      
Proposed
          text change:

      
 
      
Current
          text:

      
 
      
=
      
            revocationReason  &n=
bsp; [0]     =
EXPLICIT
            RevocationReason OPTIONAL }

      
 

      
RevocationReaso=
n
::=3D
            ENUMERATED {

      
        unspecifie=
d       &n=
bsp;      &nb=
sp;     (0),

      
        keyComprom=
ise       =
       &=
nbsp;   (1),

      
        cACompromi=
se        =
      &n=
bsp;    (2)=
,

      
        affiliatio=
nChanged             (3),

      
        superseded=
       &nb=
sp;      &nbs=
p;      =
(4),

      
        cessationO=
fOperation           (5),

      
        certificat=
eHold              =
;  (6),

      
        notIssuedO=
rIrregularlyIssued
              (7),

      
        removeFrom=
CRL       =
       &=
nbsp;   (8),

      
        privilegeW=
ithdrawn       =
      (9),

      
        aACompromi=
se        =
      &n=
bsp;   (10) }

      
 

      
 

      
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).<=
/span>

      
 
      
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 

      
         seri=
al 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 

      
         cert=
ificate
            serial number that was
            sent really exists in a 

      
         cert=
ificate that
            is correctly signed,
            but to its knowledge 

      
         the =
CA has not
            issued a certificate
            with such a serial 

      
         numb=
er.  As an example, it may
            have been issued by the
            CA 

      
         beca=
use 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: <=
/p>
      
 
      
      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<=
span style=3D"font-family:"Times New
          Roman";mso-ansi-language:EN-GB" lang=3D"EN-GB">.

      
 
      
 

      
21. 0n page 16,
          there is a section =
4.2.2.2 c=
alled “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.&=
nbsp; 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.

      
 

      
 

      
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 i=
nto
          “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:

      
 

      
 

      
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.

      
 

      
 

      
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
      
 
      
 

      
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.

      
 =


      
 

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

      
 

      
 

      
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 <=
/span>

      
   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.

      
 

      
 

      
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]. <=
/p>
      
&=
nbsp;

      
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.
      
 

      
 

      
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.
      
 

      
 

      
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 m=
eet 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 us=
ed 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 cont=
ains 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 

      
         betw=
een 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.&n=
bsp;
            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.<=
/p>
      
 

      
   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 correspondin=
g
            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.<=
/p>
      
 

      
   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.<=
/p>
      
 

      
   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.

      
 

      
 

      
End of
          comments

        

      


        Denis

        

      
 
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3441548346_12598899-- From paul.hoffman@vpnc.org Sun Jan 20 11:12:29 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 2B5D621F868E for ; Sun, 20 Jan 2013 11:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUOgK89u-Ia0 for ; Sun, 20 Jan 2013 11:12:28 -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 9CAC521F8686 for ; Sun, 20 Jan 2013 11:12:28 -0800 (PST) Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0KJCNBW091842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jan 2013 12:12:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50FC177A.9050800@bull.net> Date: Sun, 20 Jan 2013 11:12:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B1DEB35-E9B8-4BDB-947B-1616724614AE@vpnc.org> References: <50FC177A.9050800@bull.net> To: Denis Pinkas X-Mailer: Apple Mail (2.1499) Cc: pkix Subject: [pkix] Authorship 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: Sun, 20 Jan 2013 19:12:29 -0000 On Jan 20, 2013, at 8:12 AM, Denis Pinkas wrote: > . . .=20 > 1. The author can be removed as an author and moved to the = Acknowledgements section. > 2. The author can be removed as an author and moved to a = Contributors section. > 3. An AD can approve the document in place of the unavailable = author. (See the IESG Statement on AUTH48 State.) > =20 > . . .=20 > It looks more reasonable to anticipate the problem and to apply the = path numbered 1, hence to move the names=20 > of the original contributors to RFC 2560 into the Acknowledgments = section. Fully agree. This would make the process better. > Obviously, the consequence is that there will be far less people = contributing to this draft:=20 Disagree. Anyone who is listed as an author who has not contributed by = now is probably not going to all of a sudden decide to contribute = between now and the end of IETF Last Call. > Stefan seems to be the single author/contributor, =85 which is what he = wanted : And what many of us wanted as well. > - he did not answered positively when, last summer, I sent him a = private email proposing to share the editing of the draft.=20 > - after a meeting in London, he did not either responded at two = proposals for a phone call. You have contributed many comments, some of them valuable to the effort. = However, WG chairs need to choose authors for WG document who are = expected to follow WG consensus. Stefan and Stephen may have decided = that you do not fit that criterion. If I were chair (and there are many = people who are thankful that I am not...), I would have come to the same = conclusion. --Paul Hoffman= From wwwrun@rfc-editor.org Fri Jan 18 14:09: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 73B1A21F8738 for ; Fri, 18 Jan 2013 14:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScBlELX5bElQ for ; Fri, 18 Jan 2013 14:09:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5621F86A8 for ; Fri, 18 Jan 2013 14:09:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 81A98622E9; Fri, 18 Jan 2013 13:58:20 -0800 (PST) To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130118215823.81A98622E9@rfc-editor.org> Date: Fri, 18 Jan 2013 13:58:20 -0800 (PST) X-Mailman-Approved-At: Mon, 21 Jan 2013 06:38:12 -0800 Cc: pkix@ietf.org, rfc-editor@rfc-editor.org, a.yousar@informatik.hu-berlin.de Subject: [pkix] [Editorial Errata Reported] RFC5280 (3466) 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, 18 Jan 2013 22:09:26 -0000 The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3466 -------------------------------------- Type: Editorial Reported by: Annie Yousar Section: 4.2.1.6 Original Text ------------- If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST | NOT issue certificates with subjectAltNames containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile. Corrected Text -------------- If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST | NOT issue certificates with subjectAltName extensions containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile. Notes ----- Certificates do not have "subjectAltNames" but only "subjectAltName extensions", which is the correct wording that is thoroughly used in the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From alexey.melnikov@isode.com Mon Jan 21 09:11: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 A5F2B21F8718 for ; Mon, 21 Jan 2013 09:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CimtnWKL62bu for ; Mon, 21 Jan 2013 09:11:48 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E95BB21F86D8 for ; Mon, 21 Jan 2013 09:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1358788302; d=isode.com; s=selector; i=@isode.com; bh=3S+EXIaigfCYIChjZ0o9iEMv60COBmq4rezTbQI++SA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=m5wS24B6bqChcOAzoDJn4lWXdK67yjwiLWwd6fCxiJ2JhR57xLTSJOBUItHlM9BDmuMjOw rlZcPhwXFjznAfK7veCbuYiM5fDgxTKfbw82Vo6zHbn0TH/gv8OCCGoFyIlOfEXFQO91Ah l4TeHOHykBsvRp3MEWH0fVKnKRXOoaY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 21 Jan 2013 17:11:41 +0000 Message-ID: <50FD76DD.3070009@isode.com> Date: Mon, 21 Jan 2013 17:11:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Stefan Santesson References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis 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, 21 Jan 2013 17:11:48 -0000 On 04/01/2013 09:57, Stefan Santesson wrote: > Forwarding Steve's WGLC on RFC 2560bis. > (It was misaddressed) > > > On 1/2/13 4:43 PM, "Stephen Kent" wrote: > >> Folks, >> >> Stefan has just published the long-awaited 2560bis update, and has >> requested WGLC. >> >> Let's begin a slightly longer WGLC, to accommodate those who may be on a >> post-New year vacation. >> >> the WGLC will end on 1/20/13. >> >> Steve Hi, I reviewed the document for the first time and I think it is reasonably clear. I do have however a list of almost trivial issues, which I think need to be looked at, as they would help IANA and first time readers: 1) In 2.1, list item: I think there is a missing dot before "If". It also looks like that sentence should be in its own paragraph and not in item 3. 2) In 3.1: URI RFC (RFC 3986) should be referenced normatively here. 3) The IANA Considerations section is empty, but Appendix C registers 2 Media Types. I think this is wrong, the IANA Considerations section needs to point to Appendix C, or just move Appendix C content into the IANA Considerations section. 4) RFC 2616 is normative, as the document defines a normative HTTP mapping. 5) In A.1.2: cache control header fields must be obeyed by proxies. I hope this section is not saying otherwise ("MAY ignore"). 6) In Appendix C: Published Specification - this RFC? The document should say so, so that RFC Editor doesn't forget to insert the RFC number here. 7) Change Controller for a WG document is a person? Make it "IETF". From kent@bbn.com Tue Jan 22 13:30:17 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 C9AFB21F894E for ; Tue, 22 Jan 2013 13:30:17 -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=[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 S6vM6oVTsxGH for ; Tue, 22 Jan 2013 13:30:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0FB21F894C for ; Tue, 22 Jan 2013 13:30:17 -0800 (PST) Received: from [128.89.89.145] (port=51215 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TxlQ8-000Pgq-KF for pkix@ietf.org; Tue, 22 Jan 2013 16:30:16 -0500 Message-ID: <50FF04E8.2090203@bbn.com> Date: Tue, 22 Jan 2013 16:30:16 -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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] 2560bis WGLC complete 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, 22 Jan 2013 21:30:17 -0000 Folks, The WGLC for 2560 bis ended on Sunday, 1/20. I have reviewed the recent message exchanges on list re this doc. Stefan posted an update on 1/18/13 (version -09). I am comfortable that this version does an adequate job in addressing the comments received over the past 3 weeks. Steve From piyush@ditenity.com Tue Jan 22 15:38: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 6D1C121F8ACE for ; Tue, 22 Jan 2013 15:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sTiLSwWgYsD for ; Tue, 22 Jan 2013 15:38:53 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3446321F8ABD for ; Tue, 22 Jan 2013 15:38:52 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id un3so7659261obb.21 for ; Tue, 22 Jan 2013 15:38:52 -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=KThuKqOnFjJZA42djMwD/hWN1dCFojFEd79eldnfC4M=; b=p3cmGQT6sExlAV/RbeLbmLJ4tE88b7HLDSY+Sdrgi61gtq6RWtPK5NCyHhOloGPYPA knwFdlfSF5YgeYRbdmEFZkR+jemn34I3P9nGBFqtw87H0LxBXrFO2Qe2V/AqqeDYoB5m JETMS8Hm90LuqeZBekC+kVhgvToIaHU9unjor5b5iZKndehx7b7hOBs/bCqn1Z4BfTs+ WFzOX5rZPedklp6CX0O5tt71qYtsq0zZUpnLuDyEAL/pCMTJLnLKdVlQorN/oc5ux/w4 KmauLY9t5vTE46OswItkKDvoZr4/yeCt04VNjZ5YFBDv/V/1aNpz92tiCj0NoxUiYCba eG1g== X-Received: by 10.60.31.195 with SMTP id c3mr18257216oei.57.1358897932018; Tue, 22 Jan 2013 15:38:52 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id y4sm14587753oea.7.2013.01.22.15.38.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Jan 2013 15:38:51 -0800 (PST) From: "Piyush Jain" To: "'Stephen Kent'" , "'pkix'" References: <50FF04E8.2090203@bbn.com> In-Reply-To: <50FF04E8.2090203@bbn.com> Date: Tue, 22 Jan 2013 15:38:49 -0800 Message-ID: <026a01cdf8f9$a20823c0$e6186b40$@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: AQEGEVRYYxeRHF87TtcZ4mcA6IG6U5nlz9ug Content-Language: en-us X-Gm-Message-State: ALoCoQkspMmAguqqMlykQytfctBCS2e5DGVyrHBj5SQ2IB8SIrYPzM72vOY8IisfCNmmOeN10uBX Subject: Re: [pkix] 2560bis WGLC complete 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, 22 Jan 2013 23:38:54 -0000 Stephen and Stefan, Can one of you please point me to the version 9 of the draft? I could not find a link to this document in any of the previous posts and the site http://datatracker.ietf.org/wg/pkix/ lists draft-08 as the latest. Thanks -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Tuesday, January 22, 2013 1:30 PM > To: pkix > Subject: [pkix] 2560bis WGLC complete > > Folks, > > The WGLC for 2560 bis ended on Sunday, 1/20. > > I have reviewed the recent message exchanges on list re this doc. Stefan > posted an update on 1/18/13 (version -09). I am comfortable that this version > does an adequate job in addressing the comments received over the past 3 > weeks. > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Tue Jan 22 23:47: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 98A8621F87B6 for ; Tue, 22 Jan 2013 23:47:56 -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=[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 SI4laRaMhALp for ; Tue, 22 Jan 2013 23:47:51 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3F621F84A1 for ; Tue, 22 Jan 2013 23:47:48 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id E20171D020; Wed, 23 Jan 2013 08:47:43 +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 2013012308474338-36992 ; Wed, 23 Jan 2013 08:47:43 +0100 Message-ID: <50FF959E.3060402@bull.net> Date: Wed, 23 Jan 2013 08:47:42 +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: Stephen Kent References: <50FF04E8.2090203@bbn.com> In-Reply-To: <50FF04E8.2090203@bbn.com> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 23/01/2013 08:47:43, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 23/01/2013 08:47:43, Serialize complete at 23/01/2013 08:47:43 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: pkix Subject: Re: [pkix] 2560bis WGLC complete 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, 23 Jan 2013 07:47:57 -0000 Steve, How can you feel "comfortable that this version does an adequate job in addressing the comments received over the past 3 weeks" ? How can a document posted on the 18 th respond to comments posted on the 20 th (and on the 21 rst )? Denis > > The WGLC for 2560 bis ended on Sunday, 1/20. > > I have reviewed the recent message exchanges on list re this doc. > Stefan posted an update > on 1/18/13 (version -09). I am comfortable that this version does an > adequate job in addressing > the comments received over the past 3 weeks. > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From ben@digicert.com Wed Jan 23 11:55:37 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 A4EDE21F8770 for ; Wed, 23 Jan 2013 11:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WmOGb6j40qRn for ; Wed, 23 Jan 2013 11:55:36 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2529821F85D4 for ; Wed, 23 Jan 2013 11:55:36 -0800 (PST) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 3B6FE8FA70C; Wed, 23 Jan 2013 12:55:29 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1358970929; bh=HMQWBN13xcLeGSIUYz4/kI4Tf9e549PNrGk7n5ichtU=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date; b=XOkW1qmF3SKi4hNjKFxx//ow8vhL0Xek7jUZdy1zX6XKq/efY36CxpnBSU8u8siDT o0sXrVjwvgR7WNsIBav+aH8UntecKoTKFbPGlZMWmO/L+7q+0oMpJIxKgTao8+oc+P 58DAyBGaL3DI8zk86d9eS1pq5KlIxn9cIwwxpMCQ= From: "Ben Wilson" To: "'Phillip Hallam-Baker'" , References: In-Reply-To: Date: Wed, 23 Jan 2013 12:55:28 -0700 Organization: DigiCert Message-ID: <017601cdf9a3$97d904a0$c78b0de0$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0177_01CDF968.EB7AC8E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIsYWEM0R8veDa8HUwN2g2ZyyDopJeafhjg Content-Language: en-us Subject: Re: [pkix] Update to OCSP Must Staple draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:55:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0177_01CDF968.EB7AC8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Has this issue with the "Must Staple" OID been resolved? CABF was looking at adopting "2.23.140.16.1" 2.23.140 is the ca-browser-forum, 16 is ocsp, and 1 would become "must-staple". (I'm currently working on OCSP stapling fixes to section 13.2.1 and appendix B of the CABF's Baseline Requirements.) From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Wednesday, November 14, 2012 7:27 PM To: pkix@ietf.org Subject: [pkix] Update to OCSP Must Staple draft Following conversations at IETF I have removed the minimum version attribute from the Must Staple draft. Basically Ryan Sleevi explained the pool of woe and misery that is TLS version numbering and so I dropped it. The updated version of the draft is http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-03.txt This is not a WG item of course but is of interest to folk here. The main outstanding issue is whether the OID should be cut from the IETF PKIX arc or some other arc (e.g. CABForum). After discussion with Russ (the secretary) and Stephan (as WG chair) it seems that the best approach would be to put it on the PKIX arc so that people know where to look to find the description (i.e. an RFC). This might raise an issue that the WG may need to consider before it closes, namely what the ongoing registration policy is going to be for PKIX OIDs when the registration function reverts to IANA. -- Website: http://hallambaker.com/ ------=_NextPart_000_0177_01CDF968.EB7AC8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has this issue with the “Must Staple” OID been resolved? =

 

CABF was looking at adopting “2.23.140.16.1”  = 2.23.140 is the ca-browser-forum, 16 is ocsp, and 1 would become = “must-staple”.  (I’m currently working on OCSP = stapling fixes to section 13.2.1 and appendix B of the CABF’s = Baseline Requirements.)

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Phillip Hallam-Baker
Sent: Wednesday, November 14, 2012 = 7:27 PM
To: pkix@ietf.org
Subject: [pkix] Update to = OCSP Must Staple draft

 

Following = conversations at IETF I have removed the minimum version attribute from = the Must Staple draft. Basically Ryan Sleevi explained the pool of woe = and misery that is TLS version numbering and so I dropped = it.

 

The updated version of the draft = is

 

 

 

This is not a WG item of course but is of interest to = folk here.

 

The main outstanding issue is whether the OID should = be cut from the IETF PKIX arc or some other arc (e.g. CABForum). After = discussion with Russ (the secretary) and Stephan (as WG chair) it seems = that the best approach would be to put it on the PKIX arc so that people = know where to look to find the description (i.e. an = RFC).

 

This might raise an issue that the WG may need to = consider before it closes, namely what the ongoing registration policy = is going to be for PKIX OIDs when the registration function reverts to = IANA.

 

--
Website: http://hallambaker.com/

------=_NextPart_000_0177_01CDF968.EB7AC8E0-- From kent@bbn.com Wed Jan 23 14:19:31 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 1D2FD21F8860 for ; Wed, 23 Jan 2013 14:19:31 -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=[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 Rwr1-PYynVCb for ; Wed, 23 Jan 2013 14:19:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5E21F85E0 for ; Wed, 23 Jan 2013 14:19:30 -0800 (PST) Received: from [128.89.89.145] (port=49421 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ty8fJ-0009DK-26; Wed, 23 Jan 2013 17:19:29 -0500 Message-ID: <510061F0.4030303@bbn.com> Date: Wed, 23 Jan 2013 17:19:28 -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 References: <50FF04E8.2090203@bbn.com> <50FF959E.3060402@bull.net> In-Reply-To: <50FF959E.3060402@bull.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] 2560bis WGLC complete 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, 23 Jan 2013 22:19:31 -0000 Denis, Sorry, I missed your "at the buzzer" message on 1/20. I'll allow some more time for Stefan to reply to all of your comments. But, in general, an author ought not expect to receive a large number of comments at the end of an extended WGLC. Steve > From wwwrun@rfc-editor.org Fri Jan 25 14:54:37 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 5F75F21F88BD; Fri, 25 Jan 2013 14:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bue+W+3Qh0u; Fri, 25 Jan 2013 14:54:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E524921F88B4; Fri, 25 Jan 2013 14:54:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8967172E11A; Fri, 25 Jan 2013 14:43:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130125224314.8967172E11A@rfc-editor.org> Date: Fri, 25 Jan 2013 14:43:14 -0800 (PST) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] RFC 6844 on DNS Certification Authority Authorization (CAA) Resource Record 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, 25 Jan 2013 22:54:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6844 Title: DNS Certification Authority Authorization (CAA) Resource Record Author: P. Hallam-Baker, R. Stradling Status: Standards Track Stream: IETF Date: January 2013 Mailbox: philliph@comodo.com, rob.stradling@comodo.com Pages: 18 Characters: 36848 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-caa-15.txt URL: http://www.rfc-editor.org/rfc/rfc6844.txt The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From piyush@ditenity.com Fri Jan 25 16:32: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 8536421F88B4 for ; Fri, 25 Jan 2013 16:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REzJwVCAspjr for ; Fri, 25 Jan 2013 16:32:57 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id E659A21F88B0 for ; Fri, 25 Jan 2013 16:32:56 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id l20so1148928oag.26 for ; Fri, 25 Jan 2013 16:32:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=oJCvyjmKZOUwgzubIyI16LvU1kva3HYc5aQVyARnw+8=; b=MZfn3JtEO2H9bYbJj3SdWg7Y5bF4o8fbXb2udIVuR9GqK1dP+DJ7k141g9lQMRJgmp EruOmjCz+5zApbu5F84oAPhbFwvXVS3r6SVGun1brrcV2gmImGnWIB+G4Yu5WQ1J/jm+ 1v/9C49AZjZCBvZ/AQhwAwzSUfM2P53Gp6VFeX+ie+c4hntX8xJye4tMEwXKnrC/xneN lgoraPAq2ICYW5xKhoiCsz6lVMQRZAIgB+2JuLvZKvLh1yFj3sYN523k41tS2UUG4Uxg qL3PfXZVpYUVDaRuBqj3aGdxSynFQzPp/Owf7nNJAas47Q/CL5bAeCxCyMBtzEGaUH+F qjew== X-Received: by 10.182.192.68 with SMTP id he4mr5905550obc.99.1359160376200; Fri, 25 Jan 2013 16:32:56 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id o3sm1915452obk.13.2013.01.25.16.32.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Jan 2013 16:32:55 -0800 (PST) From: "Piyush Jain" To: Date: Fri, 25 Jan 2013 16:32:50 -0800 Message-ID: <012901cdfb5c$acf89e30$06e9da90$@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: Ac37XA0X5TrESq6GRd+Y2HKlclM0MQ== Content-Language: en-us X-Gm-Message-State: ALoCoQkx+b47eUJUntaKvOb38Jr9VBy8pwZONZ7Fx6r2zbv1qEiWAC2NpVD+9UEB0c7y28YsXKjP Subject: [pkix] Where is 2560-bis draft 9 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, 26 Jan 2013 00:32:57 -0000 Hi list, Can someone please point me to the latest and greatest draft 9 of 2560-bis. Stefan said that he published it on 18th, but I have not seen any notifications and the site http://datatracker.ietf.org/wg/pkix/ lists draft 08 as the latest. Thanks in advance -Piyush From internet-drafts@ietf.org Sun Jan 27 01:12: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 8DE0921F8506; Sun, 27 Jan 2013 01:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 AMKTZTBwrO4k; Sun, 27 Jan 2013 01:12:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455421F84FB; Sun, 27 Jan 2013 01:12:55 -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: <20130127091255.32487.90099.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2013 01:12:55 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-09.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: Sun, 27 Jan 2013 09:12:56 -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 : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-09.txt Pages : 39 Date : 2013-01-27 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Sun Jan 27 01:17: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 BDC0E21F8506 for ; Sun, 27 Jan 2013 01:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 d+YHkq7DpGS9 for ; Sun, 27 Jan 2013 01:17:48 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id C5ECE21F84E3 for ; Sun, 27 Jan 2013 01:17:36 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6D0221B5186 for ; Sun, 27 Jan 2013 10:15:43 +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 gGUvYPIG-9Ns for ; Sun, 27 Jan 2013 10:15:43 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0711D1B517E for ; Sun, 27 Jan 2013 10:15:43 +0100 (CET) Received: (qmail 3623 invoked from network); 27 Jan 2013 09:15:42 -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 ; 27 Jan 2013 09:15:42 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 10:15:39 +0100 From: Stefan Santesson To: Piyush Jain , 'Stephen Kent' , 'pkix' Message-ID: Thread-Topic: [pkix] 2560bis WGLC complete In-Reply-To: <026a01cdf8f9$a20823c0$e6186b40$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] 2560bis WGLC complete 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, 27 Jan 2013 09:17:48 -0000 I'm sorry, I somehow had faild to push the final confirmation button on the submit page. I have fixed that now and 09 should be available just as posted 11 days ago. Only the date has changed to the date of today. I will go through the two comment posts since I posted this to see if further updates are necessary. /Stefan On 1/23/13 12:38 AM, "Piyush Jain" wrote: >Stephen and Stefan, > >Can one of you please point me to the version 9 of the draft? >I could not find a link to this document in any of the previous posts and >the site http://datatracker.ietf.org/wg/pkix/ lists draft-08 as the >latest. > >Thanks >-Piyush > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stephen Kent >> Sent: Tuesday, January 22, 2013 1:30 PM >> To: pkix >> Subject: [pkix] 2560bis WGLC complete >> >> Folks, >> >> The WGLC for 2560 bis ended on Sunday, 1/20. >> >> I have reviewed the recent message exchanges on list re this doc. Stefan >> posted an update on 1/18/13 (version -09). I am comfortable that this >version >> does an adequate job in addressing the comments received over the past 3 >> weeks. >> >> Steve >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Sun Jan 27 01:18: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 0C5A121F8630 for ; Sun, 27 Jan 2013 01:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 00kq2u3acz-p for ; Sun, 27 Jan 2013 01:18:20 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAB21F85B3 for ; Sun, 27 Jan 2013 01:18:19 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D39C01B549D for ; Sun, 27 Jan 2013 10:16:48 +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 os9lhr8d92of for ; Sun, 27 Jan 2013 10:16:48 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8227E1B5494 for ; Sun, 27 Jan 2013 10:16:48 +0100 (CET) Received: (qmail 5907 invoked from network); 27 Jan 2013 09:16:48 -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 ; 27 Jan 2013 09:16:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 10:16:45 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Where is 2560-bis draft 9 In-Reply-To: <012901cdfb5c$acf89e30$06e9da90$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Where is 2560-bis draft 9 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, 27 Jan 2013 09:18:21 -0000 Fixed. See other message. On 1/26/13 1:32 AM, "Piyush Jain" wrote: >Hi list, > >Can someone please point me to the latest and greatest draft 9 of >2560-bis. >Stefan said that he published it on 18th, but I have not seen any >notifications and the site http://datatracker.ietf.org/wg/pkix/ lists >draft >08 as the latest. > >Thanks in advance >-Piyush > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From internet-drafts@ietf.org Sun Jan 27 02:03: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 41D4821F8563; Sun, 27 Jan 2013 02:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 iR+5Mhn8dPhc; Sun, 27 Jan 2013 02:03:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919A821F857C; Sun, 27 Jan 2013 02:03:45 -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: <20130127100345.772.72949.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2013 02:03:45 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-10.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: Sun, 27 Jan 2013 10:03:46 -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 : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-10.txt Pages : 39 Date : 2013-01-27 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Sun Jan 27 02:08: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 E5FAA21F8506 for ; Sun, 27 Jan 2013 02:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 TH+jj8dhL84h for ; Sun, 27 Jan 2013 02:08:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0347A21F84C9 for ; Sun, 27 Jan 2013 02:08:48 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 75CC11B9516 for ; Sun, 27 Jan 2013 11:08:47 +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 Qcusrdc6bBMx for ; Sun, 27 Jan 2013 11:08:47 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0BCD21B9515 for ; Sun, 27 Jan 2013 11:08:47 +0100 (CET) Received: (qmail 28816 invoked from network); 27 Jan 2013 10:08:46 -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 ; 27 Jan 2013 10:08:46 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 11:08:43 +0100 From: Stefan Santesson To: Alexey Melnikov Message-ID: Thread-Topic: [pkix] 2560bis WGLC In-Reply-To: <50FD76DD.3070009@isode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis 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: Sun, 27 Jan 2013 10:08:50 -0000 Alexey, Thanks for your review. I have tried to address all your issues in draft 10, which I just posted in response to these comments. Does this resolve your issue list? I'm a bit uncertain regarding your point 5. I did no action on this as the "MAY ignore" relates to the receiving requester getting a response back and not proxies. I think that is clear form the text. /Stefan On 1/21/13 6:11 PM, "Alexey Melnikov" wrote: >On 04/01/2013 09:57, Stefan Santesson wrote: >> Forwarding Steve's WGLC on RFC 2560bis. >> (It was misaddressed) >> >> >> On 1/2/13 4:43 PM, "Stephen Kent" wrote: >> >>> Folks, >>> >>> Stefan has just published the long-awaited 2560bis update, and has >>> requested WGLC. >>> >>> Let's begin a slightly longer WGLC, to accommodate those who may be on >>>a >>> post-New year vacation. >>> >>> the WGLC will end on 1/20/13. >>> >>> Steve >Hi, >I reviewed the document for the first time and I think it is reasonably >clear. >I do have however a list of almost trivial issues, which I think need to >be looked at, as they would help IANA and first time readers: > >1) In 2.1, list item: I think there is a missing dot before "If". It >also looks like that sentence should be in its own paragraph and not in >item 3. > >2) In 3.1: URI RFC (RFC 3986) should be referenced normatively here. > >3) The IANA Considerations section is empty, but Appendix C registers 2 >Media Types. I think this is wrong, the IANA Considerations section >needs to point to Appendix C, or just move Appendix C content into the >IANA Considerations section. > >4) RFC 2616 is normative, as the document defines a normative HTTP >mapping. > >5) In A.1.2: cache control header fields must be obeyed by proxies. I >hope this section is not saying otherwise ("MAY ignore"). > >6) In Appendix C: Published Specification - this RFC? The document >should say so, so that RFC Editor doesn't forget to insert the RFC >number here. > >7) Change Controller for a WG document is a person? Make it "IETF". > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From peter.sylvester@edelweb.fr Sun Jan 27 02:52: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 BBB0021F84C9 for ; Sun, 27 Jan 2013 02:52:35 -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 kIlOCSkpCCNs for ; Sun, 27 Jan 2013 02:52:35 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED421F84C8 for ; Sun, 27 Jan 2013 02:52:35 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 2CCD45E0DD for ; Sun, 27 Jan 2013 11:52:40 +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 1E69F5E0A2 for ; Sun, 27 Jan 2013 11:52:40 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 228925E1AA for ; Sun, 27 Jan 2013 11:52:06 +0100 (CET) Received: from smtps.on-x.com (unknown [192.168.14.66]) by mail1.on-x.com (Postfix) with ESMTP id 140BA5E154 for ; Sun, 27 Jan 2013 11:52:06 +0100 (CET) Received: from [192.168.0.35] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 0191F5E0E6 for ; Sun, 27 Jan 2013 11:50:45 +0100 (CET) Message-ID: <510506EF.9050904@edelweb.fr> Date: Sun, 27 Jan 2013 11:52:31 +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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] 2560bis 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: Sun, 27 Jan 2013 10:52:35 -0000 In Chapter 4.2.2.2 Authorized Responders The order of the text seems rather unfortunate to me. It seems pretty reversed. The first of the three use cases mentioned at the end is not mentioned at the beginning. 1: Matches a local configuration of OCSP signing authority for the certificate in question; The current does not requireid-kp-OCSPSigning for this use case (only for case 3) I wonder whether all current clients accept this. In Chapter 2. Protocol the use case 1 of a locally configured responder does not provide more timely information. since this is the FIRST use case, it should be mentioned that the protocol can be used to delegate revocation checking. Peter From stefan@aaa-sec.com Sun Jan 27 04:29: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 AF8E521F84E3 for ; Sun, 27 Jan 2013 04:29:49 -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 ksCB1bqjkFbP for ; Sun, 27 Jan 2013 04:29:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6449921F84CC for ; Sun, 27 Jan 2013 04:29:46 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 3F8631C666B for ; Sun, 27 Jan 2013 13:29:44 +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 QiPON0WAsWFL for ; Sun, 27 Jan 2013 13:29:00 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4E0431C64A2 for ; Sun, 27 Jan 2013 13:29:00 +0100 (CET) Received: (qmail 44643 invoked from network); 27 Jan 2013 12:28:58 -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 ; 27 Jan 2013 12:28:58 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 13:28:53 +0100 From: Stefan Santesson To: Denis Pinkas , Stephen Kent Message-ID: Thread-Topic: [pkix] Review of 2560-bis draft 8. Answer to WGLC In-Reply-To: <50FC177A.9050800@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442138138_32212085" 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: Sun, 27 Jan 2013 12:29:49 -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_3442138138_32212085 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, Responding to your comments below. However, one genral remark to make recurring comments easier to understand. The WG decided to adopt a minimalistic approach to updating RFC 2560. That means that=20 1. We don't change anything from RFC 2560 nless it is broken, or the industry clearly need clarifications in order to aoid interoperability issues. 2. We retain the document structure of RFC 2560 as much as possible to allo= w easy comparison of wht the changes are in comparison withRFC 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 knw from experience which words worked to produce workig implementations, and which did not. Introducing new ways to say the same thingmay 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 wordng 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 > =20 > =20 >=20 > Pleas find 32 comments on draft-ietf-pkix-rfc2560bis > =20 > =20 > =20 > 1. The document states: > =20 > separately> > =20 Responded to separately. >=20 > =20 >=20 > =20 > =20 > =20 =20 > 2. The current text from section 2 states: > =20 > =20 > =20 > 2. Protocol Oerview > =20 > =20 > =20 > In lieu of or as a supplement to checking against aperiodic CRL, it > =20 > may be necessary to obtain timely information regarding the > =20 > reocation status of a certificate (cf. RFC5280], Section 3.3). > =20 > Example include high-value funds transfer or large stock trades. > =20 > =20 > =20 > he Online Certificate Status Protocol (OCSP) enables applications to > =20 > determine the (revocation) stae of an identified certificate. OCSP > =20 > may be used to satisfy some ofthe operational requirements of > =20 > providing more timely revocation information than is possible with> =20 > CRLs and may also be used to obtain additional status informaion. > =20 > =20 > =20 > This text is misleading because readers may think tha OCPS necessarily > provides =B3timely information=B2. > =20 > =20 may" does not mean "necessarily". > =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 revocation status > =20 > of one or more certificates either "good", "revoked", or "nknown". > =20 > =20 > =20 > The revocation status may be provided by the server either using a > =20 > eal time access to a database of issued ertificates, or using a > =20 > batch access to a database of issued certificates, o using a > =20 > real time access to a database of revocation statuses of issued > =20 > certificates, or using a batch access to a dataase of revocation > =20 > statuses of issued certificates, or using CRLs, or using a > =20 > combinaton of base CRLs and delta CRLs. > =20 > =20 > =20 > In the first case, it is possible to obtain timely revocation status > =20 > information, whereas in the other cases, the freshness of the > =20 > revocation status is not better than the mechanisms it is based on. > =20 > =20 > =20 > =20 Not broken > =20 >=20 > . 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 excanged 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 overview. More details are needed to know wha= t 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. > =20 > =20 > =20 > Proposed text replacement: > =20 > =20 > =20 > When using OCSP, an OCSP client issues 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 responder provides a response. > =20 > =20 > =20 > This document 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 > OCSP may also provide additional status information using > =20 > extensions.=20 > =20 > =20 > =20 > =20 Not broken > =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 conditions 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 needed by the responder. > =20 > =20 > =20 > If 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 > =20 Fixed in draft 10. > =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 the certificate in question > =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, indicating > =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 diff= erent > terms and conditions. > If some one picks a sentence in one paragraph rather than another, it wi= ll > lead to a different conclusion. > RFCs are supposed to be clear. > =20 > =20 > =20 > On page 10, the current text states in section 2.6 OCSP Signature Authori= ty > Delegation states: > =20 > =20 > =20 > The key that signs a certificate's status information 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 for extendedKeyUsage in the OCSP signer's > =20 > certificate. This certificate 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 Responders=B2 dea= ling > 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 the > =20 > same key that signed the certificate. It is necessary however to > =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 or it MAY explicitly 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 response signer's certificate. This > =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 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 > The last sentence above in yellow is the key sentence that is missing in = the > two other sections. > =20 > =20 > =20 > Most implementations only support the case where the OCSP Responder recei= ves > an OCSP certificate that is signed by the same key > that was used to sign the target certificate. They do not support the cas= e > where the OCSP Responder receives an OCSP certificate > that is signed by a key that is different from the one that was used to s= ign > the target certificate. > =20 > =20 > =20 > It is inappropriate to have three sections dealing with the same topic wi= th 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, indicating > =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 tha= t 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 with t= he > same sentence:=20 > =20 > =20 >=20 > =B3The key that signs a certificate's status information need not be the s= ame > 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 detail= s. > =20 > =20 > =20 > =20 I have added references to section 4.2.2.2 in the quoted sections in 2.2 an= d 2.6. (will be included in draft 11) > =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 responder > =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 does not fit with the ASN.1 syntax which is detailed lat= er > on, and in particular: > =20 > =20 > =20 > ResponseData ::=3D SEQUENCE { > =20 > version [0] EXPLICIT Version DEFAULT 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 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 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) > =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 an= d how > they should be processed. > =20 > There are also no explanations on how to process a single response and ho= w to > verify that it is its presence within the signed structure > is valid or not valid. This is a major deficiency of the current descrip= tion > 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 the > =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 correctly > =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 Not broken. All of this is already covered by the document. > =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 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 i= s > 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 (b= ut > 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 history = of > the associated CA =B3does not capture the fact > that it could be issued in the future, hence why using =B3not yet been use= d=B2 > would be more appropriate. > =20 > =20 > =20 > Finally, it would have been more logical to use =B3unknown=B2. So it is impor= tant > to add a note to explain why we have chosen that case for =B3legacy clients= =B2, > otherwise the people who have not participate to the exchanges will not > 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 I removed the double parenthesis and adopted your clarification with regard to "on hold".=20 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. > =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 > As already explained on the PKIX list, using the revocation reason > certificateHold is not appropriate > because it changes the meaning of certificateHold. > =20 > =20 > =20 > The extended revoked definition response extension is a means to signal t= hat > it not a true certificate hold but a =B3not issued certificate=B2. > Legacy applications cannot take advantage of it. > =20 > =20 > =20 > 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. > =20 > =20 > =20 > It is possible to use another enumeration for signalling that specific ca= se: > =20 > notIssuedOrIrregularlyIssued (7). > =20 > =20 > =20 > Thus for new applications it would be much better to use > notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list. > =20 > =20 > =20 > The above sentence uses the text: > =20 > =20 > =20 > =B3a status request for a non-issued certificate=B2 > =20 > =20 > =20 > whereas it would be more appropriate to state: > =20 > =20 > =20 > =B3a status request for a serial number which has not been used by the CA o= r > used irregularly to issue a certificate=B2. > =20 > =20 > =20 > Placing the ASN.1 description at such a place in the document is inapprop= riate > since the ASN.1 structures have not yet been described. > Thus only the functional aspects should be mentioned, but not the ASN.1 > implications. > =20 > =20 > =20 > BTW, the description should follow the same order as the ASN.1. This is n= ot > the case.=20 > =20 > =20 > =20 > This text should be deleted from this section and the appropriate text sh= ould > be added when the parameters of the response are described. > =20 > =20 > =20 > The text proposed in the previous comment should be sufficient at this ti= me of > reading. > =20 > =20 > =20 > In addition, section 4.4.8 Extended Revoked Definition should be deleted= . > =20 > =20 > =20 > =20 The referred text has been updates in draft 09. This has been discussed on the list and you have yet to convince the list o= f 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. > =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 k= now > 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. > =20 > =20 > The text from this section is not aligned with the text that is present i= n > 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 > 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 different > places. > =20 > =20 > =20 > Delete section 2.4. See comment number 19 for the description of these > parameters. > =20 Not broken. The current text segments fits well into a protocol overview section. > =20 > =20 > =20 > =20 > 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. > =20 > =20 Not broken. > =20 >=20 > =20 > =20 > 12. Remainder: Section 2.6 should be deleted (see comment number 5). > =20 > =20 > =20 Not broken. > =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 follo= wing: > =20 > =20 > =20 > The relying party must verify that the singleResponse is signed by a resp= onder > which is entitled to do so. > =20 > =20 > =20 > a) If the CA key has been compromised and if the response is signed by th= at CA > key then the singleResponse will be discarded > when performing the certification path validation whatever the content o= f the > response may be. > =20 > =20 > =20 > b) If the CA key which has issued the OCSP certificate has been compromis= ed > 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. > =20 > =20 > =20 > =20 > =20 > Security must be provided using the validation of the certification path.= Thus > it does not matter what the OCSP responder states. > =20 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. >=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 will > =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 t= he > protocol description has not yet been made, > since it is the next section 4. Its text is not correct either. > =20 > =20 > =20 > This description does not take into account the fact that a BasicOCSPResp= onse > may contain one or several SingleResponses. > In particular, the sentence =B3The signer is currently authorized to sign = the > response=B2 is misleading because a signer > may be authorized to include some SingleResponses but not necessarily al= l of > them.=20 > =20 > =20 > =20 > The appropriate explanations should be done after the description of the > response, when describing the processing of the response. > =20 > =20 > =20 > Delete that section. > =20 > =20 Not broken. > =20 >=20 > =20 > =20 > 15. On page 12, after the ASN.1 description, the only parameters which ar= e > 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 > following text is proposed: > =20 > =20 > =20 > requestorName is optional and MAY be used by the server for access > =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 > suggests several useful extensions. Additional extensions MAY be > =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 > hash shall be calculated over the DER encoding of the issuer's name > =20 > field in the certificate being checked. > =20 > =20 > =20 > issuerKeyHash is the hash of the Issuer's public key. The hash > =20 > shall be calculated over the value (excluding tag and length) of the > =20 > subject public key field in the issuer's certificate. The hash > =20 > algorithm used for both these hashes, is identified in > =20 > hashAlgorithm. > =20 > =20 > =20 > The primary reason to use the hash of the CA's public key in > =20 > addition to the hash of the CA's name, to identify the issuer, > =20 > is that it is possible that two CAs may choose to use the same > =20 > name (uniqueness in the Name is a recommendation that cannot be > =20 > enforced). Two CAs will never, however, have the same public key > =20 > unless the CAs either explicitly decided to share their private > =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 > status is being requested. > =20 > =20 > =20 > singleRequestExtensions is OPTIONAL. Any specific extension is > =20 > OPTIONAL. The critical flag SHOULD NOT be set for any of them. > =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 Not broken. The current text is short, but it is actually sufficient from the context o= f 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. > =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 issuerKeyHash= and > thus is no more needed. > =20 > =20 > =20 > The second paragraph has been moved after the description of > requestExtensions. > However, the sentence > =B3 Unrecognized extensions MUST be ignored (unless they have the critical= flag > set and are not understood)=B2 > has been deleted since it applies to the OCSP responder and not to the O= CSP > client. Thus it is no more needed. > =20 > =20 > =20 > 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. > =20 > =20 > =20 > This section should be deleted. > =20 > =20 > =20 Not broken. > =20 > =20 > 17. There should be a new section called: =B3Requirements for OCSP clients=B2= . > =20 > =20 > =20 > It is important first to re-advertise that the request may be about sever= al > certificates.=20 > Thus it is important to describe the process for building a request, whi= ch is > currently missing. > =20 > =20 > =20 > An OCSP request allows getting in the same response the revocation > =20 > status of one or more certificates. In order to request the > =20 > status of one or more certificates in a single request, OCSP > =20 > clients SHALL follow the following rules : > =20 > =20 > =20 > For each candidate certificate, OCSP clients SHALL verify > =20 > whether there exists a locally defined rule for the certificate in > =20 > question which indicates the URI where the OCSP responder is > =20 > located. If this rule exists, it SHALL be followed. > =20 > =20 > =20 > Otherwise, OCSP clients SHALL determine whether the candidate > =20 > certificate contains an AIA extension with an accessMethod which > =20 > contains the id-ad-ocsp OID. If it is the case, the accessLocation > =20 > contains a uniformResourceIdentifier (URI) which indicates the > =20 > location of the OCSP server for that certificate. > =20 > =20 > =20 > Certificates that contain the same URI MAY be grouped in a single > =20 > request. > =20 > =20 > =20 > Note: For each candidate certificate, when performing the path > =20 > validation algorithm, the OCSP client SHOULD verify that the > =20 > current time is within the validity period of the target > =20 > certificate. Certificates which are outside their validity > =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 Not broken. Your text may provide guidance that could be useful to some implementers, but is completely beyond this document and further, not generally applicabl= e or true. As an example, an organisation may setup an in house locally configured OCS= P 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. > =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 the > =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 veri= fying > every SingleResponse, > it is important to include the relevant certificates which are pertinent= to > every SingleResponse. > =20 > =20 > =20 > Proposed full text replacement: > =20 > =20 > =20 > The responder MAY include certificates in the certs field of > =20 > BasicOCSPResponse that help the OCSP client verify the responder's > =20 > signature. > =20 > =20 > =20 > For every SingleResponse where the responder is not a CA, the > =20 > responder SHALL include the relevant OCSP certificate in the certs > =20 > field of BasicOCSPResponse in order to allow the OCSP client > =20 > verifying the responder was entitled to include that SingleResponse > =20 > in the signed BasicOCSPResponse. > =20 > =20 > =20 > If no certificates are included then certs SHOULD be absent. > =20 > =20 > =20 Not broken. This requirement would break backwards compatibility with RFC 2560. Further this would not be needed for a locally configured responder. > =20 > =20 > 19. Page 15. The ASN.1 syntax should be changed in order to be able to us= e the=20 > 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 Not broken. You have to convince the list about your new reason code. > =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, nextUpdate= and=20 > 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 AS= N.1=20 > parameters, the general text=20 > from section 4.2.2.3 Basic Response is no more need and should be delete= d. > =20 > =20 > =20 Preliminary I would say "not broken". If you don't replace 4.2.2.3, then what really are you missing? > =20 > =20 > 21. 0n page 16, there is a section 4.2.2.2 called =B3Authorized Responders=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 a= nd=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 I disagree. The CA is actually free to do anything, but cannot expect the=20 client to recognise the responder as authorised unless the same private key= =20 is used. The current text places the requirement where they belong. > =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 the > =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 like = =B3They=20 > 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 No, this change is not backwards compatible. So state the requirements for rejection is not equivalent to stating=20 requirements for acceptance. There may be other locally configured reasons to reject in addition to thos= e=20 listed in the standard. > =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 No, issuing with another key is not prohibited, and may be accepted by some= =20 clients as an authorised responder. > =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 Moving this to a separate discussion. I'm not sure what the preferred way to describe this is. > =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 Not broken. > =20 >=20 > 26. On page 24, text should be added to the Security consideration sectio= n: > =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 verify=20 > =20 > the CRLs itself. Hence the revocation status may not be identical=20 > =20 > in both cases. > =20 > =20 > =20 > =20 I don't understand this one. > =20 >=20 > 27. On page 24, text should be added to the Security consideration sectio= n: > =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 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. I would suggest that it is beyond this update to do so. > =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 inappropriate = 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 Will move this (as stated above) to a separate discussion. > =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 annex= es=20 > are being proposed. > =20 > =20 > =20 > Note: The texts are extracted from draft-pinkas-rfc2560bis-03. > =20 > =20 > =20 > =20 Not broken. Each such amendment need to be thoroughly reviewed and motivated. > =20 >=20 > 30. First annex being proposed. This annex is important, because key roll= over=20 > 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 descr= ibes=20 > the validation of an OCSP response in the past=20 > which is of a particular importance when validating electronic signature= s. > =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 provid= es=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 ord= er to=20 > 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 an=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 Not broken. /Stefan > =20 > =20 > =20 > =20 > End of comments > =20 > =20 >=20 > Denis > =20 > =20 > =20 > =20 > _______________________________________________ pkix mailing list=20 > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 --B_3442138138_32212085 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

Responding to your comments below.

However, one general remark to make recurring comments easi= er to understand.

<= /div>
The WG decided to adopt= a minimalistic approach to updating RFC 2560. That means that 
  • We don't change anything from RFC 2560 unless it is broken, or the ind= ustry clearly need clarifications in order to avoid interoperability issues.=
  • 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.<= /li>

    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 experien= ce which words worked to produce working implementations, and which did not.=
    Introducing new ways t= o 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 ch= ange.



    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: pk= ix <pkix@ietf.org>
    Subject: Re: [pkix] Review of 2560-bis draft 8. An= swer 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 check=
ing against a periodic CRL, it
       may be necessary to obtain timely information regarding the<=
/span>
       revocation status of a certificate (cf=
. RFC5280], Section 3.3).
       Examples include high-value funds tran=
sfer 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 ope=
rational requirements of
       providing more timely revocation information than is possible with=

       CRLs and may also be used to obtain ad=
ditional status information. 
     
    This text is misleading because readers may think that OCPS nec=
essarily provides “timely information”.
     

    • "may" does not mean "necessari= ly".

    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.

     
     
    <= div style=3D"font-family: Calibri, sans-serif; ">
    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 t=
o 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:
     

       = When using OCSP, an OCSP client issues a certificate revocation <= /span>

       = 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<= /span>

       = 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. 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:<= /o:p>

     
       -  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 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<=
/b> 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.  Therefor=
e,
            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<=
/span>
    
      
       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 Respo=
nder 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.
    
      
     
    
      
    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: 
    
        
    
      

    
          “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.
    
      
     
    
      
     
    <= div style=3D"font-family: Calibri, sans-serif; ">
    I have added references to section 4.2.2.2 in t= he 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:

     

       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 ove= rview 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 er= ror-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 cer= tificate identifier

    =    -  certificat= e status value

    =    -  response v= alidity interval

    =    -  optional e= xtensions

     

    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 co= vered 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. <= o:p>

     

    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,
       eith=
er permanently or temporarily.
     
       A certificate may be temporarily revok=
ed 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 ser=
ial 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 ̶=
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 clarif= ication with regard to "on hold". 

    T= he text in draft 10 has changed from what you have commented on. I believe t= hat text is better.
    You "Note" has proble= ms.
    1. We do not preven= t responders to respond "unknown" if their assessment is that this is an app= ropriate response, considering what they know about the requested serial num= ber. 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. Thi= s 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 modifie= d version of your Note:

       NOTE: The "revoke= d" state for known non-issued certificate serial
             numbers is allowed in order= to reduce the risk of relying
    &nb= sp;        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-<= /o:p>

    =    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 stat=
us request for a non-issued certifica=
te” 
     
    whereas it would be more appropriate to state: 
     
    “a stat=
us 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 i=
s inappropriate since the ASN.1 structures have not yet been described. 
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 appropria=
te text should be added when the parameters of the response are described. <=
o:p>
     
    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. 

     
     

    <= /div>
    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 in= to problems with the deployed base of application is hugely larger with intr= oduction of a new reason code, rather than using certificateHold.
    = No application should be broken, since no application have business asking f= or non-issued cert serial numbers in the first place. Secondly, no applicati= on 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<= /o:p>

     

    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 ov= erview 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 c= hained to the broken CA. The relying party may have other trust configuratio= n 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.<= /span>

     

    =    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 SingleRespo= nses.
    In particular, the sentence     “The signer is c= urrently 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 has= h

       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 <= /o:p>

    =       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.&nb= sp; 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 sufficie= nt from the context of the ASN.1 definitions of the section. This is a detai= led protocol section and the reader need to understand ASN.1 in any case to = understand and implement the section.
    The information about critic= ality 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.&= nbsp; 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 NO= T 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 cou= ld be useful to some implementers, but is completely beyond this document an= d further, not generally applicable or true.
    As an example, an org= anisation may setup an in house locally configured OCSP responder that respo= nds to all certificates "out there" that is relevant to that organisation.
    Such clients would just blindly send OCSP requests to their local r= esponder, disregarding any information in the cert.
    It's totally b= eyond 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.<= span style=3D"font-size:10.0pt;mso-ansi-language:EN-GB" lang=3D"EN-GB">

     


    = 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 &nb= sp;  [0]     = EXPLICIT CRLReason OPTIONAL }

     

    Proposed text change:

     

    Current text:

     

    =        revocationReason  &n= bsp; [0]     = EXPLICIT RevocationReason OPTIONAL }

     

    RevocationReaso= n ::=3D ENUMERATED {

            unspecifie= d       &n= bsp;      &nb= sp;     (0),

            keyComprom= ise       =       &= nbsp;   (1),

            cACompromi= se        =       &n= bsp;    (2)= ,

            affiliatio= nChanged             (3),

            superseded=        &nb= sp;      &nbs= p;      = (4),

            cessationO= fOperation           (5),

            certificat= eHold              = ;  (6),

            notIssuedO= rIrregularlyIssued   (7),

            removeFrom= CRL       =       &= nbsp;   (8),

            privilegeW= ithdrawn       =       (9),

            aACompromi= se        =       &n= bsp;   (10) }

     


    = Not broken.

    You have to convince the list about you= r 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).<= /span>

     

    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

             seri= al 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

             cert= ificate serial number that was sent really exists in a

             cert= ificate that is correctly signed, but to its knowledge

             the = CA has not issued a certificate with such a serial

             numb= er.  As an example, it may have been issued by the CA

             beca= use 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: <= /p>

     

          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<= span style=3D"font-family:"Times New Roman";mso-ansi-language:EN-GB" lang=3D"EN-GB">.

     


    = 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 c= alled “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.&= nbsp; 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 ac= tually free to do anything, but cannot expect the client to recognise the re= sponder as authorised unless the same private key is used.
    The cur= rent 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 i= nto “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 sta= te the requirements for rejection is not equivalent to stating requirements = for acceptance.
    There may be other locally configured reasons to r= eject 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 separat= e 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.

    =

     

     


    <= /div>
    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 <= /span>

       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 respo= nders in this way, then the document itself need to introduce the subject.
    I would suggest that it is beyond this update to do so.
    <= br>

     

    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]. <= /p>

    &= nbsp;

    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.
    Ea= ch 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 m= eet 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 us= ed 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 cont= ains 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

             betw= een 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.&n= bsp; 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.<= /p>

     

       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 correspondin= g 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.<= /p>

     

       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.<= /p>

     

       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/m= ailman/listinfo/pkix
    --B_3442138138_32212085-- From stefan@aaa-sec.com Sun Jan 27 05:13: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 64F5A21F84DC for ; Sun, 27 Jan 2013 05:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.699, 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 7Ex2wRwhCdX4 for ; Sun, 27 Jan 2013 05:13:38 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7288F21F84D8 for ; Sun, 27 Jan 2013 05:13:38 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C80481CB773 for ; Sun, 27 Jan 2013 14:13:36 +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 OTXQjW-3-bkh for ; Sun, 27 Jan 2013 14:13:36 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 438091CB775 for ; Sun, 27 Jan 2013 14:13:36 +0100 (CET) Received: (qmail 50585 invoked from network); 27 Jan 2013 13:13:35 -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 ; 27 Jan 2013 13:13:35 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 14:13:31 +0100 From: Stefan Santesson To: Denis Pinkas , Stephen Kent , Jim Schaad , Paul Hoffman Message-ID: Thread-Topic: ASN.1 expression of extensions with absent extension value In-Reply-To: <50FC177A.9050800@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442140816_32418441" Cc: pkix Subject: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 13:13:39 -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_3442140816_32418441 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I feel uncertain how to nest deal with this comment from Denis. I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition. This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used. Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value? If this is the case, the same would apply to the new OCSP extension for extended revoke definition. /Stefan 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 > > 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 > > --B_3442140816_32418441 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
    I feel uncertain how to nest= deal with this comment from Denis.

    I have compared= with RFC 5912 and it does only define the extension OID, but provides no ex= tension definition.

    This seem to be the model used = in several places where an extension with absent extension value (empty octe= t string) is used.
    Is there any reason to go beyond this and do as= Denis suggests. That is, to provide an Extension definition with a Syntaxt = holding an element with a NULL value?

    If this is th= e case, the same would apply to the new OCSP extension for extended revoke d= efinition.

    /Stefan


    = 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

    24. On page 17, the text states:

    &n= bsp;

       This SHOULD be a non-critic= al extension. The value of the extension

      &n= bsp;SHALL be NULL.

     

    The ASN.1 syntax is mis= sing. Add:

     

    <= span>   NoC= heck ::=3D NULL

    &n= bsp;


    = --B_3442140816_32418441-- From internet-drafts@ietf.org Sun Jan 27 05: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 4A8B021F84E7; Sun, 27 Jan 2013 05:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 aiP0bdP9E8sv; Sun, 27 Jan 2013 05:15:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DAC21F84FB; Sun, 27 Jan 2013 05:15:23 -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: <20130127131523.4467.92653.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2013 05:15:23 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-11.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: Sun, 27 Jan 2013 13:15:24 -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 : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-11.txt Pages : 39 Date : 2013-01-27 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Sun Jan 27 05:19: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 8AC1821F8542 for ; Sun, 27 Jan 2013 05:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.376 X-Spam-Level: X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 LyJ-kqPk6+-9 for ; Sun, 27 Jan 2013 05:19:10 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9821F853E for ; Sun, 27 Jan 2013 05:19:09 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id BD2821CBE23 for ; Sun, 27 Jan 2013 14:19:08 +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 yHJuTxemLdFB for ; Sun, 27 Jan 2013 14:19:08 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7036C1CBEE5 for ; Sun, 27 Jan 2013 14:19:08 +0100 (CET) Received: (qmail 63128 invoked from network); 27 Jan 2013 13:19:08 -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 ; 27 Jan 2013 13:19:08 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 14:19:06 +0100 From: Stefan Santesson To: pkix Message-ID: Thread-Topic: The new RFC2560bis drafts In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442141148_32423219" Subject: [pkix] The new RFC2560bis drafts 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, 27 Jan 2013 13:19:10 -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_3442141148_32423219 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 3 new drafts on RFC2560bis merits an explanation. 1. Firs I resubmitted version 09, which I unsuccessfully tried to publish on the 16th of Jan. This draft captures changes to respond the the extensive debate and reviews on the list up until the 16th. 2. Draft 10 deals with Alexey's comments. 3. Draft 11 includes updates due to Deni's list of comments, excluding the ASN.1 question posted separately on the list. /Stefan --B_3442141148_32423219 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
    3 new drafts on RFC2560bis m= erits an explanation.
    1. Firs I resubmitted version 09, which I un= successfully tried to publish on the 16th of Jan. This draft captures change= s to respond the the extensive debate and reviews on the list up until the 1= 6th.
    2. Draft 10 deals with Alexey's comments.
    3. Draft 11 include= s updates due to Deni's list of comments, excluding the ASN.1 question poste= d separately on the list.
    /Stefan

    --B_3442141148_32423219-- From peter.sylvester@edelweb.fr Sun Jan 27 05:41:56 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 7AA0D21F85C3 for ; Sun, 27 Jan 2013 05:41:56 -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 pVvSdRtTjicu for ; Sun, 27 Jan 2013 05:41:56 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id E574521F84DE for ; Sun, 27 Jan 2013 05:41:55 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 0946C5E0F2 for ; Sun, 27 Jan 2013 14:41:58 +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 EDA035E0EF for ; Sun, 27 Jan 2013 14:41:57 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 37F9D5E1AA for ; Sun, 27 Jan 2013 14:41:24 +0100 (CET) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id 284645E153 for ; Sun, 27 Jan 2013 14:41:24 +0100 (CET) Received: from [192.168.0.35] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id B650E5E03E for ; Sun, 27 Jan 2013 14:40:58 +0100 (CET) Message-ID: <51052E95.4050402@edelweb.fr> Date: Sun, 27 Jan 2013 14:41:41 +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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 13:41:56 -0000 On 01/27/2013 02:13 PM, Stefan Santesson wrote: > I feel uncertain how to nest deal with this comment from Denis. > > I have compared with RFC 5912 and it does only define the extension OID, but provides no extension > definition. indeed, it doesn't define an extension for that OID. > > This seem to be the model used in several places where an extension with absent extension value > (empty octet string) is used. No. An instance of an ASN.1 type is not empty. If you want to have an extension, you have to define it as such, which is not done done thus the 5912 module does not define an extension identified by that oid with a syntax ??? defining the oid doesn't make the 5912 a wrong asn.1 it just doesn't implement all of ocsp. > Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension > definition with a Syntaxt holding an element with a NULL value? try to make a definition according 5912. > > If this is the case, the same would apply to the new OCSP extension for extended revoke definition. > indeed. as soon as there is a specification of an extension in Ocsp there must be syntax definitions of an oid and a type From piyush@ditenity.com Sun Jan 27 08:13: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 A51D321F86CC for ; Sun, 27 Jan 2013 08:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoWwHEqG8mdG for ; Sun, 27 Jan 2013 08:13:07 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2198521F853E for ; Sun, 27 Jan 2013 08:13:06 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so2067611oag.9 for ; Sun, 27 Jan 2013 08:13:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=hJo7S4bA4TRA5mRIic4SbfZKFRlnCWeNYXJgZLAAmx4=; b=M3pzFXjTFMmMwxW+1qc/EMox3lpObol6tkHZJs+d+O/y6uscBNfJL24dG1p0kuoHN6 9CBbjoUotv7M4p04i15FeY2wbY7yB+aGTFXDz/2VXhWNHzPC7tIth4885R5nbF/ZZDJ2 BgBByVkehQV9i3yWY7cwW1d3D0qcgb1emFDiA3iVLs2PPPYTeXxk60+D+pfdPGvdpHXl tJkJ2b9qsF/+xRg/qVuX30myE11/29GWx6f9kjbcOquFnhn9pkEIhffpwA++Q5Dt+vYE IF2Dw69nqT0pTNwZ28foy13mvJ7qEfAhIaIrW+4EVjUknogNYOy2YKOTu8jebPQJX1wp nKbA== X-Received: by 10.182.147.69 with SMTP id ti5mr7120035obb.88.1359303186571; Sun, 27 Jan 2013 08:13:06 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id b6sm5799063oee.3.2013.01.27.08.13.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 08:13:05 -0800 (PST) From: "Piyush Jain" To: "Stefan Santesson" , Date: Sun, 27 Jan 2013 08:12:59 -0800 Message-ID: <031501cdfca9$2df25060$89d6f120$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0316_01CDFC66.1FDDB660" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac38qRn1JlA1SAY/Rla0wKKMGyNlTQ== Content-Language: en-us X-Gm-Message-State: ALoCoQnaAmPSmNbvAI5+CMtIhc0scbLfGXWigEgiIYR0LY+GXFA6QIgngr7VK74xZwcUKK6Italb Subject: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 27 Jan 2013 16:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0316_01CDFC66.1FDDB660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefan, I raised the issue regarding responder trust in case of non-issued certificate earlier (please see attached email). In my opinion, section 4.2.2.2 in the current draft violates section 9 of RFC 2418 in cases where the responder indicates that the certificate is non-issued. Not sure if my proposal in the attached email handles this issue completely, but it is a step forward from the current text. Regards -Piyush ------=_NextPart_000_0316_01CDFC66.1FDDB660 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Piyush Jain" To: References: <004b01cdf0dc$6c392c50$44ab84f0$@ditenity.com> In-Reply-To: <004b01cdf0dc$6c392c50$44ab84f0$@ditenity.com> Subject: RE: Addressing issues in 4.2.2.2 of rfc2560bis-08 Date: Mon, 14 Jan 2013 16:16:59 -0800 Message-ID: <02cc01cdf2b5$a4474930$ecd5db90$@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: AQMMLUzWuxF9OdE2vr4K4/K7XRtq1gI1ISTm Content-Language: en-us I just realized that even my new proposal does not fix the paradox if the RP decides to consider the CA as compromised in context of current transaction. Unfortunately, I don't see any way to resolve this paradox under existing OCSP trust models. Here is the revised text where I changed the recommendation to consider CA compromised for future use instead of current and future uses. It is akin to saying - Trust me for once when I say "I always lie" :). NEW PROPOSED TEXT Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. 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: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that signed the certificate in question; or 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is signed by the CA that signed the certificate in question as stated above." If the response trust is established by using either (1) or (2) and if the response status is revoked with reason code notIssuedOrIrregularlyIssued (7), it implies that the CA has no record of issuance of some of the certificates that were signed using its private key. In this case, it is recommended that the relying application considers the CA that issued the certificate in question as compromised for any future use. > -----Original Message----- > From: Piyush Jain [mailto:piyush@ditenity.com] > Sent: Saturday, January 12, 2013 7:50 AM > To: pkix@ietf.org > Subject: Addressing issues in 4.2.2.2 of rfc2560bis-08 > > Hi list, > > Here is the proposal to address the issue in section 4.2.2.2 that I brought up > in bullet point 4 of my original review post . You don't need to refer to that > post. Context is provided below. > > CURRENT TEXT > > Systems or applications that rely on OCSP responses MUST be capable of > detecting and enforcing use of the id-kp-OCSPSigning value as described > above. They MAY provide a means of locally configuring one or more OCSP > signing authorities, and specifying the set of CAs for which each signing > authority is trusted. 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: > 1. Matches a local configuration of OCSP signing authority for the certificate > in question; or > 2. Is the certificate of the CA that issued the certificate in question; or > 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." > > ISSUES > - Creates a paradox If (2) or (3) are used to establish trust in the response > and if the response is marked as revoked because certificate was "not- > issued". If the RP trusts response, it implies that the certificate was not > issued by the CA which implies that the RP should not trust the response. > This can be addressed by changing all references to "issued" to "signed" in > the above text. Please not that this is a problem only for certificates that > exist, not for non-existent certificate. RPs who send queries for non-existent > certificates have no way to establish trust in the response if the response is > signed by a delegated responder. > - If the RP determines that certificate was signed by the CA and if the > response is marked as revoked with extended revoked definition, it implies > that RP has encountered a certificate signed by the CA for which CA has no > record of issuance. Most likely cause for this is RA/CA compromise. Others > have pointed out there may be some 'not so severe' reasons such as loss of > issuance record etc. Unfortunately, there is no way for the responder to > communicate the exact reason to the RP and RPs should assume the worst > case scenario. > > PROPOSED TEXT > > Systems or applications that rely on OCSP responses MUST be capable of > detecting and enforcing use of the id-kp-OCSPSigning value as described > above. They MAY provide a means of locally configuring one or more OCSP > signing authorities, and specifying the set of CAs for which each signing > authority is trusted. 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: > 1. Matches a local configuration of OCSP signing authority for the certificate > in question; or > 2. Is the certificate of the CA that signed the certificate in question; or > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension > and is signed by the CA that signed the certificate in question as stated > above." > > If the response trust is established by using either (1) or (2) and if the > response status is revoked with reason code notIssuedOrIrregularlyIssued > (7), it implies that the CA has no record of issuance of some of the certificates > that were signed using its private key. In this case, it is recommended that > the relying application considers the CA that issued the certificate in question > as compromised for any current or future use. > > COMMENTS: > I'm using Denis's proposal to represent "non-issued" by reason code > notIssuedOrIrregularlyIssued(7). If the consensus is that we extended > revoked extension is a better choice, then we can change the text > accordingly. ------=_NextPart_000_0316_01CDFC66.1FDDB660-- From paul.hoffman@vpnc.org Sun Jan 27 08:17:42 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 7698D21F891D for ; Sun, 27 Jan 2013 08:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuCEPGQF-km5 for ; Sun, 27 Jan 2013 08:17:42 -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 C80DD21F8756 for ; Sun, 27 Jan 2013 08:17:41 -0800 (PST) Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0RGH1pl043782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jan 2013 09:17:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sun, 27 Jan 2013 08:17:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5886B821-88DD-47BB-B187-52D437EAC675@vpnc.org> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1499) Cc: pkix , Jim Schaad Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 16:17:42 -0000 I'll defer to Jim Schaad on this, but I think what Denis is asking for = is alright, but overkill. A standalone definition without an example of = usage adds no value to the document; using a generic name like "NoCheck" = could in fact be dangerous to someone reading the document not terribly = carefully. But adding a definition and a usage for it seems fine. --Paul Hoffman= From ietf@augustcellars.com Sun Jan 27 10:05:56 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 DDE7E21F8742 for ; Sun, 27 Jan 2013 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 7X3R4T6k0zcz for ; Sun, 27 Jan 2013 10:05:55 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7291021F845D for ; Sun, 27 Jan 2013 10:05:55 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CB8F02C9F5; Sun, 27 Jan 2013 10:05:54 -0800 (PST) From: "Jim Schaad" To: "'Paul Hoffman'" , "'Stefan Santesson'" References: <5886B821-88DD-47BB-B187-52D437EAC675@vpnc.org> In-Reply-To: <5886B821-88DD-47BB-B187-52D437EAC675@vpnc.org> Date: Sun, 27 Jan 2013 10:05:27 -0800 Message-ID: <011d01cdfcb8$e4351b00$ac9f5100$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHE/rlLdKL4ZOzLoFb3/wBoJdQDSAJzLJRBmFvZVQA= Content-Language: en-us Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 18:05:56 -0000 In terms of what I did for 5912 - This fell into the general space of the document was underspecified. Defining the NULL is optional and not necessary but nice. The following would be added to 5912 re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } ---- with the type defined They are the effectively the same. Most ASN.1 compilers have a NULL type that can be directly referenced so adding the extra layer of indirection does not make the user's job any easier or harder. However, I would not know from reading the text if this was part of the extension sequence for ResponseData.responseExtensions or SingleResponse.singleExtensions or both. For this reason I did not create the ASN.1 object. Jim > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Sunday, January 27, 2013 8:17 AM > To: Stefan Santesson > Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix > Subject: Re: ASN.1 expression of extensions with absent extension value > > I'll defer to Jim Schaad on this, but I think what Denis is asking for is alright, > but overkill. A standalone definition without an example of usage adds no > value to the document; using a generic name like "NoCheck" could in fact be > dangerous to someone reading the document not terribly carefully. But > adding a definition and a usage for it seems fine. > > --Paul Hoffman= From housley@vigilsec.com Sun Jan 27 10:28: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 4253E21F8552 for ; Sun, 27 Jan 2013 10:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 749Gl9giT6R4 for ; Sun, 27 Jan 2013 10:28:12 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18F21F854E for ; Sun, 27 Jan 2013 10:28:12 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E7A559A4002 for ; Sun, 27 Jan 2013 13:28:15 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id coavjbmGwcpb for ; Sun, 27 Jan 2013 13:28:05 -0500 (EST) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 167A99A4001 for ; Sun, 27 Jan 2013 13:28:12 -0500 (EST) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-26-899480660 Date: Sun, 27 Jan 2013 13:28:06 -0500 In-Reply-To: To: IETF PKIX References: Message-Id: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> X-Mailer: Apple Mail (2.1085) Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 18:28:13 -0000 --Apple-Mail-26-899480660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom RFC 5280, the extension structure is: Extension ::=3D SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } We know that some software automatically tries to decode the content of = the OCTET STRING. Will this software fail if the OCTET STRIN is zero = length? Russ On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: > I feel uncertain how to nest deal with this comment from Denis. >=20 > I have compared with RFC 5912 and it does only define the extension = OID, but provides no extension definition. >=20 > This seem to be the model used in several places where an extension = with absent extension value (empty octet string) is used. > Is there any reason to go beyond this and do as Denis suggests. That = is, to provide an Extension definition with a Syntaxt holding an element = with a NULL value? >=20 > If this is the case, the same would apply to the new OCSP extension = for extended revoke definition. >=20 > /Stefan >=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 draft 8. Answer to WGLC >=20 >> 24. On page 17, the text states: >> =20 >> This SHOULD be a non-critical extension. The value of the = extension >> SHALL be NULL. >> =20 >> The ASN.1 syntax is missing. Add: >> =20 >> NoCheck ::=3D NULL >> =20 >>=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-26-899480660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    I feel uncertain how to = nest deal with this comment from Denis.

    I have = compared with RFC 5912 and it does only define the extension OID, but = provides no extension definition.

    This seem to = be the model used in several places where an extension with absent = extension value (empty octet string) is used.
    Is there any = reason to go beyond this and do as Denis suggests. That is, to provide = an Extension definition with a Syntaxt holding an element with a NULL = value?

    If this is the case, the same would = apply to the new OCSP extension for extended revoke = definition.

    /Stefan


    =
    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

    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
     

    _______________________________________________
    pkix mailing = list
    pkix@ietf.org
    https://www.ietf.org/m= ailman/listinfo/pkix

    = --Apple-Mail-26-899480660-- From stefan@aaa-sec.com Sun Jan 27 10:46:37 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 6B76821F844E for ; Sun, 27 Jan 2013 10:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.279, 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 P1skXPyojAtA for ; Sun, 27 Jan 2013 10:46:37 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id AB0A521F843B for ; Sun, 27 Jan 2013 10:46:35 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D55991F1B4D for ; Sun, 27 Jan 2013 19:46:26 +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 eDh7sP8rZjkW for ; Sun, 27 Jan 2013 19:46:26 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5CAA91F1B95 for ; Sun, 27 Jan 2013 19:46:26 +0100 (CET) Received: (qmail 23830 invoked from network); 27 Jan 2013 18:46:26 -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 ; 27 Jan 2013 18:46:26 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 19:46:23 +0100 From: Stefan Santesson To: Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: ASN.1 expression of extensions with absent extension value In-Reply-To: <011d01cdfcb8$e4351b00$ac9f5100$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 18:46:37 -0000 Jim, The noCheck is a cert extension. Its included in OCSP responder certs to signal that this responder cert does not have to be checked for revocation. Would it be OK if I just included the following in the ASN.1 module of 2560bis: re-ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-nocheck } That extension definition is not present in 5912, but the extension oid definition is: id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 } Or is even this needed=8A? Since this document does not define cert ASN.1 that extension definition will not be referred to. /Stefan On 1/27/13 7:05 PM, "Jim Schaad" wrote: >In terms of what I did for 5912 - This fell into the general space of the >document was underspecified. > >Defining the NULL is optional and not necessary but nice. > >The following would be added to 5912 > >re-ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- without the type defined >re-ocsp-nocheck EXTENSION :=3D {SYNTAX NoCheck IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- with the type defined > >They are the effectively the same. Most ASN.1 compilers have a NULL type >that can be directly referenced so adding the extra layer of indirection >does not make the user's job any easier or harder. > >However, I would not know from reading the text if this was part of the >extension sequence for ResponseData.responseExtensions or >SingleResponse.singleExtensions or both. For this reason I did not create >the ASN.1 object. > >Jim > > >> -----Original Message----- >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >> Sent: Sunday, January 27, 2013 8:17 AM >> To: Stefan Santesson >> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >> Subject: Re: ASN.1 expression of extensions with absent extension value >>=20 >> I'll defer to Jim Schaad on this, but I think what Denis is asking for >>is >alright, >> but overkill. A standalone definition without an example of usage adds >>no >> value to the document; using a generic name like "NoCheck" could in fact >be >> dangerous to someone reading the document not terribly carefully. But >> adding a definition and a usage for it seems fine. >>=20 >> --Paul Hoffman=3D > From carl@redhoundsoftware.com Sun Jan 27 10:56:31 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 350F721F851E for ; Sun, 27 Jan 2013 10:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRX-8+8cwlyy for ; Sun, 27 Jan 2013 10:56:30 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2361121F84FB for ; Sun, 27 Jan 2013 10:56:30 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so585908qah.0 for ; Sun, 27 Jan 2013 10:56:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=LFWWKSYtNekBtHrSyo7l/KAUX+y1M2lo2VJh/jz0HDY=; b=myhtF+Du3Sl/sT106dyMwGm7AzCpMxodfsrZ/IcJAsw3UYAxTPMxHkUtLPMo4B3Ws3 BYvGR01ZXrk80psxKGNg3jBvQ/yohTRXVXJ1mpxfpzztjihap++YEKiHG7IIS8mtuJao Zz7M8LWyeXE0WSrcxrfPHTYgrNLlSz/jOgT4c/vEOlT9A5Akwn9TWAi+l/8bGyKCdT6F 3TxDhFUerY/74YpEmr2lD1mHt+QEXoobIZ6BQMom+i71/bGL1VpKYi5Y2TwbGFEBpsQe iT8bJ9P2xMgcc7PaWxe1aYDlYhaE4upiU5LYUIXCCbVpjLshrbh0vKPIrNcSvVJ6A+Ff KrGA== X-Received: by 10.49.127.145 with SMTP id ng17mr15203483qeb.25.1359312989326; Sun, 27 Jan 2013 10:56:29 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-120-2.washdc.fios.verizon.net. [173.79.120.2]) by mx.google.com with ESMTPS id hr1sm4357388qeb.3.2013.01.27.10.56.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 10:56:28 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 13:56:17 -0500 From: Carl Wallace To: Stefan Santesson , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="Big5" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlDCHl/LtwmE43qvrODnlq3nig0bG14WVB6ghPWOYyBTS0lcz1P53tzLMAVv0oiWHtE3h+/ Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 18:56:31 -0000 On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >Jim, > >The noCheck is a cert extension. Its included in OCSP responder certs to >signal that this responder cert does not have to be checked for >revocation. > >Would it be OK if I just included the following in the ASN.1 module of >2560bis: > >re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-nocheck } > You should add some text discussing the fact that implementations need to handle both empty and NULL, since 2560 was not clear enough on this and there are apparently implementations of each in the field. I think encoding NULL is the common practice. You may want to add a MUST NOT to steer future implementations away from generating empty extensions. > > >That extension definition is not present in 5912, but the extension oid >definition is: >id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } > > >Or is even this needed?? Yes it is needed and should have been in the ASN.1 module of 2560, not just in the prose. It should probably land in the errata of 5912 as well. >Since this document does not define cert ASN.1 that extension definition >will not be referred to. There are many extensions defined in documents that do not define certificate ASN.1. > >/Stefan > > > >On 1/27/13 7:05 PM, "Jim Schaad" wrote: > >>In terms of what I did for 5912 - This fell into the general space of the >>document was underspecified. >> >>Defining the NULL is optional and not necessary but nice. >> >>The following would be added to 5912 >> >>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>id-pkix-ocsp-nocheck } ---- without the type defined >>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>id-pkix-ocsp-nocheck } ---- with the type defined >> >>They are the effectively the same. Most ASN.1 compilers have a NULL type >>that can be directly referenced so adding the extra layer of indirection >>does not make the user's job any easier or harder. >> >>However, I would not know from reading the text if this was part of the >>extension sequence for ResponseData.responseExtensions or >>SingleResponse.singleExtensions or both. For this reason I did not >>create >>the ASN.1 object. >> >>Jim >> >> >>> -----Original Message----- >>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>> Sent: Sunday, January 27, 2013 8:17 AM >>> To: Stefan Santesson >>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>> Subject: Re: ASN.1 expression of extensions with absent extension value >>> >>> I'll defer to Jim Schaad on this, but I think what Denis is asking for >>>is >>alright, >>> but overkill. A standalone definition without an example of usage adds >>>no >>> value to the document; using a generic name like "NoCheck" could in >>>fact >>be >>> dangerous to someone reading the document not terribly carefully. But >>> adding a definition and a usage for it seems fine. >>> >>> --Paul Hoffman= >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From ietf@augustcellars.com Sun Jan 27 11:05: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 3F1FF21F868B for ; Sun, 27 Jan 2013 11:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 43jFhYEPqBJe for ; Sun, 27 Jan 2013 11:05:57 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8141121F8549 for ; Sun, 27 Jan 2013 11:05:57 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E072938EA7; Sun, 27 Jan 2013 11:05:56 -0800 (PST) From: "Jim Schaad" To: "'Stefan Santesson'" , "'Paul Hoffman'" References: <011d01cdfcb8$e4351b00$ac9f5100$@augustcellars.com> In-Reply-To: Date: Sun, 27 Jan 2013 11:05:30 -0800 Message-ID: <012101cdfcc1$47325120$d596f360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMRjwmNvYXUAGrKygScsaGpJxlj4JXWYvOA Content-Language: en-us Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 19:05:58 -0000 If I had realized that this is how it is used, I would have done the following: 1. Defined the OCSP extension, but with the name ext-ocsp-nocheck (thus saying it is a certificate extension) 2. Defined a new object set -- -- This is the set of PKIX X.509 certificate extensions defined by this document -- Add this to the CertExtensions Object Set defined for RFC 5280 in RFC 5912 -- CertificateExtensions EXTENSION ::= {ext-ocsp-nocheck } 3. Do the same for the other OIDs that are defined but for which no ASN.1 Object is defined in that bottom list. Jim > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Sunday, January 27, 2013 10:46 AM > To: Jim Schaad; 'Paul Hoffman' > Cc: 'Denis Pinkas'; 'Stephen Kent'; 'pkix' > Subject: Re: ASN.1 expression of extensions with absent extension value > > Jim, > > The noCheck is a cert extension. Its included in OCSP responder certs to > signal that this responder cert does not have to be checked for revocation. > > Would it be OK if I just included the following in the ASN.1 module of > 2560bis: > > re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp- > nocheck } > > > > That extension definition is not present in 5912, but the extension oid > definition is: > id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } > > > Or is even this neededS? > Since this document does not define cert ASN.1 that extension definition will > not be referred to. > > /Stefan > > > > On 1/27/13 7:05 PM, "Jim Schaad" wrote: > > >In terms of what I did for 5912 - This fell into the general space of > >the document was underspecified. > > > >Defining the NULL is optional and not necessary but nice. > > > >The following would be added to 5912 > > > >re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY > >id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck > >EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } ---- > >with the type defined > > > >They are the effectively the same. Most ASN.1 compilers have a NULL > >type that can be directly referenced so adding the extra layer of > >indirection does not make the user's job any easier or harder. > > > >However, I would not know from reading the text if this was part of the > >extension sequence for ResponseData.responseExtensions or > >SingleResponse.singleExtensions or both. For this reason I did not > >create the ASN.1 object. > > > >Jim > > > > > >> -----Original Message----- > >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > >> Sent: Sunday, January 27, 2013 8:17 AM > >> To: Stefan Santesson > >> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix > >> Subject: Re: ASN.1 expression of extensions with absent extension > >> value > >> > >> I'll defer to Jim Schaad on this, but I think what Denis is asking > >>for is > >alright, > >> but overkill. A standalone definition without an example of usage > >>adds no value to the document; using a generic name like "NoCheck" > >>could in fact > >be > >> dangerous to someone reading the document not terribly carefully. But > >> adding a definition and a usage for it seems fine. > >> > >> --Paul Hoffman= > > From stefan@aaa-sec.com Sun Jan 27 11:16: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 B188121F8534 for ; Sun, 27 Jan 2013 11:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.233, 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 O1Atnv2VRFod for ; Sun, 27 Jan 2013 11:16:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1C21F84D8 for ; Sun, 27 Jan 2013 11:16:47 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0DE4A1F44DA for ; Sun, 27 Jan 2013 20:16:43 +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 cVL8Obt1qz8y for ; Sun, 27 Jan 2013 20:16:42 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 76CC81F44D3 for ; Sun, 27 Jan 2013 20:16:42 +0100 (CET) Received: (qmail 98015 invoked from network); 27 Jan 2013 19:16:42 -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 ; 27 Jan 2013 19:16:42 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 20:16:38 +0100 From: Stefan Santesson To: Carl Wallace , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 19:16:49 -0000 Sorry Carl, But my understanding of ASN-1 is apparently missing something. What is the difference between absent and NULL? What i mean by that is whether there is a difference between a NULL value and an absent value. I don't mean to totally omit the OCTET STRING, as that to me is a violation of RFC 5280 since the extnValue is not OPTIONAL. Or do you mean that some have implemented this extension omitting the OCTET STRING altogether. That should result in a decoding error in such case. /Stefan On 1/27/13 7:56 PM, "Carl Wallace" wrote: > >On 1/27/13 1:46 PM, "Stefan Santesson" wrote: > >>Jim, >> >>The noCheck is a cert extension. Its included in OCSP responder certs to >>signal that this responder cert does not have to be checked for >>revocation. >> >>Would it be OK if I just included the following in the ASN.1 module of >>2560bis: >> >>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>id-pkix-ocsp-nocheck } >> > >You should add some text discussing the fact that implementations need to >handle both empty and NULL, since 2560 was not clear enough on this and >there are apparently implementations of each in the field. I think >encoding NULL is the common practice. You may want to add a MUST NOT to >steer future implementations away from generating empty extensions. > >> >> >>That extension definition is not present in 5912, but the extension oid >>definition is: >>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >> >> >>Or is even this needed?? > >Yes it is needed and should have been in the ASN.1 module of 2560, not >just in the prose. It should probably land in the errata of 5912 as well. > > >>Since this document does not define cert ASN.1 that extension definition >>will not be referred to. > >There are many extensions defined in documents that do not define >certificate ASN.1. > >> >>/Stefan >> >> >> >>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >> >>>In terms of what I did for 5912 - This fell into the general space of >>>the >>>document was underspecified. >>> >>>Defining the NULL is optional and not necessary but nice. >>> >>>The following would be added to 5912 >>> >>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>id-pkix-ocsp-nocheck } ---- without the type defined >>>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>>id-pkix-ocsp-nocheck } ---- with the type defined >>> >>>They are the effectively the same. Most ASN.1 compilers have a NULL >>>type >>>that can be directly referenced so adding the extra layer of indirection >>>does not make the user's job any easier or harder. >>> >>>However, I would not know from reading the text if this was part of the >>>extension sequence for ResponseData.responseExtensions or >>>SingleResponse.singleExtensions or both. For this reason I did not >>>create >>>the ASN.1 object. >>> >>>Jim >>> >>> >>>> -----Original Message----- >>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>> Sent: Sunday, January 27, 2013 8:17 AM >>>> To: Stefan Santesson >>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>>> Subject: Re: ASN.1 expression of extensions with absent extension >>>>value >>>> >>>> I'll defer to Jim Schaad on this, but I think what Denis is asking for >>>>is >>>alright, >>>> but overkill. A standalone definition without an example of usage adds >>>>no >>>> value to the document; using a generic name like "NoCheck" could in >>>>fact >>>be >>>> dangerous to someone reading the document not terribly carefully. But >>>> adding a definition and a usage for it seems fine. >>>> >>>> --Paul Hoffman= >>> >> >> >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > From ietf@augustcellars.com Sun Jan 27 11:24:09 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 A962721F86E3 for ; Sun, 27 Jan 2013 11:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 poQ0-kW8i9tf for ; Sun, 27 Jan 2013 11:24:09 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0711C21F86CC for ; Sun, 27 Jan 2013 11:24:09 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9456B2CA06; Sun, 27 Jan 2013 11:24:08 -0800 (PST) From: "Jim Schaad" To: "'Stefan Santesson'" , "'Carl Wallace'" , "'Paul Hoffman'" References: In-Reply-To: Date: Sun, 27 Jan 2013 11:23:42 -0800 Message-ID: <012301cdfcc3$d1e85920$75b90b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI9HfH7gpmy23lgsxCSp27gLh4FJ5d/S4Jg Content-Language: en-us Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 19:24:09 -0000 Huge difference between absent and NULL 0x30 0x0 --- absent 0x30 0x2 0x5 0x0 -- null (may be wrong encoding but you get the drift. I did it off the top of my head without any verifications) Jim > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Sunday, January 27, 2013 11:17 AM > To: Carl Wallace; Jim Schaad; 'Paul Hoffman' > Cc: 'pkix' > Subject: Re: [pkix] ASN.1 expression of extensions with absent extension > value > > Sorry Carl, > > But my understanding of ASN-1 is apparently missing something. > > What is the difference between absent and NULL? > > > What i mean by that is whether there is a difference between a NULL value > and an absent value. > I don't mean to totally omit the OCTET STRING, as that to me is a violation of > RFC 5280 since the extnValue is not OPTIONAL. > > Or do you mean that some have implemented this extension omitting the > OCTET STRING altogether. > That should result in a decoding error in such case. > > /Stefan > > On 1/27/13 7:56 PM, "Carl Wallace" wrote: > > > > >On 1/27/13 1:46 PM, "Stefan Santesson" wrote: > > > >>Jim, > >> > >>The noCheck is a cert extension. Its included in OCSP responder certs > >>to signal that this responder cert does not have to be checked for > >>revocation. > >> > >>Would it be OK if I just included the following in the ASN.1 module of > >>2560bis: > >> > >>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY > >>id-pkix-ocsp-nocheck } > >> > > > >You should add some text discussing the fact that implementations need > >to handle both empty and NULL, since 2560 was not clear enough on this > >and there are apparently implementations of each in the field. I think > >encoding NULL is the common practice. You may want to add a MUST NOT > >to steer future implementations away from generating empty extensions. > > > >> > >> > >>That extension definition is not present in 5912, but the extension > >>oid definition is: > >>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } > >> > >> > >>Or is even this needed?? > > > >Yes it is needed and should have been in the ASN.1 module of 2560, not > >just in the prose. It should probably land in the errata of 5912 as well. > > > > > >>Since this document does not define cert ASN.1 that extension > >>definition will not be referred to. > > > >There are many extensions defined in documents that do not define > >certificate ASN.1. > > > >> > >>/Stefan > >> > >> > >> > >>On 1/27/13 7:05 PM, "Jim Schaad" wrote: > >> > >>>In terms of what I did for 5912 - This fell into the general space of > >>>the document was underspecified. > >>> > >>>Defining the NULL is optional and not necessary but nice. > >>> > >>>The following would be added to 5912 > >>> > >>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY > >>>id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck > >>>EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } > >>>---- with the type defined > >>> > >>>They are the effectively the same. Most ASN.1 compilers have a NULL > >>>type that can be directly referenced so adding the extra layer of > >>>indirection does not make the user's job any easier or harder. > >>> > >>>However, I would not know from reading the text if this was part of > >>>the extension sequence for ResponseData.responseExtensions or > >>>SingleResponse.singleExtensions or both. For this reason I did not > >>>create the ASN.1 object. > >>> > >>>Jim > >>> > >>> > >>>> -----Original Message----- > >>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > >>>> Sent: Sunday, January 27, 2013 8:17 AM > >>>> To: Stefan Santesson > >>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix > >>>> Subject: Re: ASN.1 expression of extensions with absent extension > >>>>value > >>>> > >>>> I'll defer to Jim Schaad on this, but I think what Denis is asking > >>>>for is > >>>alright, > >>>> but overkill. A standalone definition without an example of usage > >>>>adds no value to the document; using a generic name like "NoCheck" > >>>>could in fact > >>>be > >>>> dangerous to someone reading the document not terribly carefully. > >>>> But adding a definition and a usage for it seems fine. > >>>> > >>>> --Paul Hoffman= > >>> > >> > >> > >>_______________________________________________ > >>pkix mailing list > >>pkix@ietf.org > >>https://www.ietf.org/mailman/listinfo/pkix > > > > From stefan@aaa-sec.com Sun Jan 27 11:38: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 5F78921F8625 for ; Sun, 27 Jan 2013 11:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Cdp1BNLdsxYm for ; Sun, 27 Jan 2013 11:38:04 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6C21F85C6 for ; Sun, 27 Jan 2013 11:38:03 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CD3FD1F71A3 for ; Sun, 27 Jan 2013 20:38:01 +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 yw_uf_5BVP1J for ; Sun, 27 Jan 2013 20:38:01 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 794F11F71A2 for ; Sun, 27 Jan 2013 20:38:01 +0100 (CET) Received: (qmail 49523 invoked from network); 27 Jan 2013 19:38:01 -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 ; 27 Jan 2013 19:38:01 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 20:37:57 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 In-Reply-To: <031501cdfca9$2df25060$89d6f120$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 27 Jan 2013 19:38:04 -0000 We are not trying to solve CA compromise. CA compromise and strategies for dealing with them is far to complex to deal with in this update. Further I don't think we should put any requirements on clients to do anything in this regard in the base protocol standard. This and other PKI problem works as long as the trusted authorities are intact and honest. Dealing with and detecting compromise is not part of the protocol design. What you say is true, but including that information would be very incomplete. I would prefer not to go there at all. /Stefan On 1/27/13 5:12 PM, "Piyush Jain" wrote: >Stefan, > >I raised the issue regarding responder trust in case of non-issued >certificate earlier (please see attached email). > >In my opinion, section 4.2.2.2 in the current draft violates section 9 of >RFC 2418 in cases where the responder indicates that the certificate is >non-issued. >Not sure if my proposal in the attached email handles this issue >completely, but it is a step forward from the current text. > >Regards >-Piyush From carl@redhoundsoftware.com Sun Jan 27 11:38: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 38B7321F86E7 for ; Sun, 27 Jan 2013 11:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnHvfraxsjRL for ; Sun, 27 Jan 2013 11:38:34 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4782C21F86E3 for ; Sun, 27 Jan 2013 11:38:34 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id b40so977539qcq.24 for ; Sun, 27 Jan 2013 11:38:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=7ABwzuYVB/iN8f8Wc8Eg/9cb74Cm/gcWyBa3riaM6hY=; b=SjtTdhu+peJWt0a9J85cjXPi2Qm8mVuAfGBxYQNvX8QLQx3uTEg8CcvEqMXVfgY8S9 JrpM3Q5yki2Sl8VMzZW9yONtnWruNtijqs55eTC6Mhz22DyxPK6C95chUNrvteHWue5q PwNUJ849Op0xZb4+HvgQHRZ6cekfPyCAQMUtk0ccUllWkH+qkZmekD7Qf8XOhYFjTXK7 N/iliuWUDQEgaJAUuZ3IYktMDF4omSoDQao28lqZpHgMxf7OUL0Z+P5Vv5ep3FrSRLH8 IIHDUMrBoVsYwG8Q3NwNvWcgASXxwAKSakrlbVwUZlp55wYTJRNYM2tknmz9L/sr+R1Y ZOwg== X-Received: by 10.229.172.162 with SMTP id l34mr419752qcz.81.1359315513655; Sun, 27 Jan 2013 11:38:33 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-120-2.washdc.fios.verizon.net. [173.79.120.2]) by mx.google.com with ESMTPS id dt10sm4569294qab.0.2013.01.27.11.38.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 11:38:33 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 14:38:19 -0500 From: Carl Wallace To: Stefan Santesson , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmOHwjDakdC1M7MbCreJ+cseHJ8Gmu6Jinhr43c/6g6MDF+qry2W1d3ygEvrDMHY/8AkXk0 Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 19:38:35 -0000 On 1/27/13 2:16 PM, "Stefan Santesson" wrote: >Sorry Carl, > >But my understanding of ASN-1 is apparently missing something. > >What is the difference between absent and NULL? Jim gave a good example of the difference between NULL and absent. Here's a snip from a responder certificate that illustrates NULL usage in context (where the first column is the length): 15: SEQUENCE { 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) 2: OCTET STRING, encapsulates { 0: NULL : } : } Here's the hex of the dump above: 300F06092B060105050730010504020500. Replace 020500 with 00 and update the SEQUENCE length for the absent version. I don't ever recall seeing a certificate that used an empty OCTET STRING, but list traffic has indicated they exist so it probably warrants a mention. > > >What i mean by that is whether there is a difference between a NULL value >and an absent value. >I don't mean to totally omit the OCTET STRING, as that to me is a >violation of RFC 5280 since the extnValue is not OPTIONAL. > >Or do you mean that some have implemented this extension omitting the >OCTET STRING altogether. >That should result in a decoding error in such case. > >/Stefan > >On 1/27/13 7:56 PM, "Carl Wallace" wrote: > >> >>On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >> >>>Jim, >>> >>>The noCheck is a cert extension. Its included in OCSP responder certs to >>>signal that this responder cert does not have to be checked for >>>revocation. >>> >>>Would it be OK if I just included the following in the ASN.1 module of >>>2560bis: >>> >>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>id-pkix-ocsp-nocheck } >>> >> >>You should add some text discussing the fact that implementations need to >>handle both empty and NULL, since 2560 was not clear enough on this and >>there are apparently implementations of each in the field. I think >>encoding NULL is the common practice. You may want to add a MUST NOT to >>steer future implementations away from generating empty extensions. >> >>> >>> >>>That extension definition is not present in 5912, but the extension oid >>>definition is: >>>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >>> >>> >>>Or is even this needed?? >> >>Yes it is needed and should have been in the ASN.1 module of 2560, not >>just in the prose. It should probably land in the errata of 5912 as >>well. >> >> >>>Since this document does not define cert ASN.1 that extension definition >>>will not be referred to. >> >>There are many extensions defined in documents that do not define >>certificate ASN.1. >> >>> >>>/Stefan >>> >>> >>> >>>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >>> >>>>In terms of what I did for 5912 - This fell into the general space of >>>>the >>>>document was underspecified. >>>> >>>>Defining the NULL is optional and not necessary but nice. >>>> >>>>The following would be added to 5912 >>>> >>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>id-pkix-ocsp-nocheck } ---- without the type defined >>>>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>>>id-pkix-ocsp-nocheck } ---- with the type defined >>>> >>>>They are the effectively the same. Most ASN.1 compilers have a NULL >>>>type >>>>that can be directly referenced so adding the extra layer of >>>>indirection >>>>does not make the user's job any easier or harder. >>>> >>>>However, I would not know from reading the text if this was part of the >>>>extension sequence for ResponseData.responseExtensions or >>>>SingleResponse.singleExtensions or both. For this reason I did not >>>>create >>>>the ASN.1 object. >>>> >>>>Jim >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>>> Sent: Sunday, January 27, 2013 8:17 AM >>>>> To: Stefan Santesson >>>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>>>> Subject: Re: ASN.1 expression of extensions with absent extension >>>>>value >>>>> >>>>> I'll defer to Jim Schaad on this, but I think what Denis is asking >>>>>for >>>>>is >>>>alright, >>>>> but overkill. A standalone definition without an example of usage >>>>>adds >>>>>no >>>>> value to the document; using a generic name like "NoCheck" could in >>>>>fact >>>>be >>>>> dangerous to someone reading the document not terribly carefully. But >>>>> adding a definition and a usage for it seems fine. >>>>> >>>>> --Paul Hoffman= >>>> >>> >>> >>>_______________________________________________ >>>pkix mailing list >>>pkix@ietf.org >>>https://www.ietf.org/mailman/listinfo/pkix >> >> > > From stefan@aaa-sec.com Sun Jan 27 11:44: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 CEC5821F86E3 for ; Sun, 27 Jan 2013 11:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.074 X-Spam-Level: X-Spam-Status: No, score=-102.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 RTR6gcr672lI for ; Sun, 27 Jan 2013 11:44:40 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1E21F866E for ; Sun, 27 Jan 2013 11:44:39 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EFB891F7F88 for ; Sun, 27 Jan 2013 20:44: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 wR7pA1SZ0Ond for ; Sun, 27 Jan 2013 20:44:12 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 42C001F7F74 for ; Sun, 27 Jan 2013 20:44:12 +0100 (CET) Received: (qmail 63964 invoked from network); 27 Jan 2013 19:44:11 -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 ; 27 Jan 2013 19:44:11 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 20:44:08 +0100 From: Stefan Santesson To: Jim Schaad , 'Carl Wallace' , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: <012301cdfcc3$d1e85920$75b90b60$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 19:44:40 -0000 Jim, thanks, but I think we are talking cross each other. What I think you outline here is the extension DER encoding, starting with a SEQUENCE. When I talked about absent, I meant absent value, not absent OCTET STRING. I know,. That was sloppy wording. Perhaps I should say empty value instead of absent. Your absent example seems to be absent OCTET STRING, which to me seems like an ASN-1 error, given the definition of Extension: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } extnValue is not optional. /Stefan On 1/27/13 8:23 PM, "Jim Schaad" wrote: >Huge difference between absent and NULL > >0x30 0x0 --- absent >0x30 0x2 0x5 0x0 -- null > >(may be wrong encoding but you get the drift. I did it off the top of my >head without any verifications) > >Jim > > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Sunday, January 27, 2013 11:17 AM >> To: Carl Wallace; Jim Schaad; 'Paul Hoffman' >> Cc: 'pkix' >> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension >> value >> >> Sorry Carl, >> >> But my understanding of ASN-1 is apparently missing something. >> >> What is the difference between absent and NULL? >> >> >> What i mean by that is whether there is a difference between a NULL >>value >> and an absent value. >> I don't mean to totally omit the OCTET STRING, as that to me is a >violation of >> RFC 5280 since the extnValue is not OPTIONAL. >> >> Or do you mean that some have implemented this extension omitting the >> OCTET STRING altogether. >> That should result in a decoding error in such case. >> >> /Stefan >> >> On 1/27/13 7:56 PM, "Carl Wallace" wrote: >> >> > >> >On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >> > >> >>Jim, >> >> >> >>The noCheck is a cert extension. Its included in OCSP responder certs >> >>to signal that this responder cert does not have to be checked for >> >>revocation. >> >> >> >>Would it be OK if I just included the following in the ASN.1 module of >> >>2560bis: >> >> >> >>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >> >>id-pkix-ocsp-nocheck } >> >> >> > >> >You should add some text discussing the fact that implementations need >> >to handle both empty and NULL, since 2560 was not clear enough on this >> >and there are apparently implementations of each in the field. I think >> >encoding NULL is the common practice. You may want to add a MUST NOT >> >to steer future implementations away from generating empty extensions. >> > >> >> >> >> >> >>That extension definition is not present in 5912, but the extension >> >>oid definition is: >> >>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >> >> >> >> >> >>Or is even this needed?? >> > >> >Yes it is needed and should have been in the ASN.1 module of 2560, not >> >just in the prose. It should probably land in the errata of 5912 as >well. >> > >> > >> >>Since this document does not define cert ASN.1 that extension >> >>definition will not be referred to. >> > >> >There are many extensions defined in documents that do not define >> >certificate ASN.1. >> > >> >> >> >>/Stefan >> >> >> >> >> >> >> >>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >> >> >> >>>In terms of what I did for 5912 - This fell into the general space of >> >>>the document was underspecified. >> >>> >> >>>Defining the NULL is optional and not necessary but nice. >> >>> >> >>>The following would be added to 5912 >> >>> >> >>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >> >>>id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck >> >>>EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } >> >>>---- with the type defined >> >>> >> >>>They are the effectively the same. Most ASN.1 compilers have a NULL >> >>>type that can be directly referenced so adding the extra layer of >> >>>indirection does not make the user's job any easier or harder. >> >>> >> >>>However, I would not know from reading the text if this was part of >> >>>the extension sequence for ResponseData.responseExtensions or >> >>>SingleResponse.singleExtensions or both. For this reason I did not >> >>>create the ASN.1 object. >> >>> >> >>>Jim >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >> >>>> Sent: Sunday, January 27, 2013 8:17 AM >> >>>> To: Stefan Santesson >> >>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >> >>>> Subject: Re: ASN.1 expression of extensions with absent extension >> >>>>value >> >>>> >> >>>> I'll defer to Jim Schaad on this, but I think what Denis is asking >> >>>>for is >> >>>alright, >> >>>> but overkill. A standalone definition without an example of usage >> >>>>adds no value to the document; using a generic name like "NoCheck" >> >>>>could in fact >> >>>be >> >>>> dangerous to someone reading the document not terribly carefully. >> >>>> But adding a definition and a usage for it seems fine. >> >>>> >> >>>> --Paul Hoffman= >> >>> >> >> >> >> >> >>_______________________________________________ >> >>pkix mailing list >> >>pkix@ietf.org >> >>https://www.ietf.org/mailman/listinfo/pkix >> > >> > > > From stefan@aaa-sec.com Sun Jan 27 12:00: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 C07A821F8721 for ; Sun, 27 Jan 2013 12:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 3A7+nezp5kGO for ; Sun, 27 Jan 2013 12:00:29 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id D495121F87CE for ; Sun, 27 Jan 2013 12:00:28 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 67E951FA2C2 for ; Sun, 27 Jan 2013 20:59:04 +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 8hhPbRJ2HEfC for ; Sun, 27 Jan 2013 20:59:03 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B6B921FA2BA for ; Sun, 27 Jan 2013 20:59:03 +0100 (CET) Received: (qmail 263 invoked from network); 27 Jan 2013 19:59:03 -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 ; 27 Jan 2013 19:59:03 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 20:59:00 +0100 From: Stefan Santesson To: Carl Wallace , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 20:00:31 -0000 Oh thanks, The coin just dropped. NULL actually has a DER encoding of its own. 05 00 Which indeed means that absent and NULL is very different. OK. Since we have already decided that NoChek SHALL have a NULL value, then its just a matter of describing it accurately in the ASN.1 of the spec. What ever method we choose I will do the same with the extended revoke extension syntax. /Stefan On 1/27/13 8:38 PM, "Carl Wallace" wrote: > >On 1/27/13 2:16 PM, "Stefan Santesson" wrote: > >>Sorry Carl, >> >>But my understanding of ASN-1 is apparently missing something. >> >>What is the difference between absent and NULL? > >Jim gave a good example of the difference between NULL and absent. Here's >a snip from a responder certificate that illustrates NULL usage in context >(where the first column is the length): > >15: SEQUENCE { > 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) > 2: OCTET STRING, encapsulates { > 0: NULL > : } > : } > > >Here's the hex of the dump above: 300F06092B060105050730010504020500. >Replace 020500 with 00 and update the SEQUENCE length for the absent >version. > >I don't ever recall seeing a certificate that used an empty OCTET STRING, >but list traffic has indicated they exist so it probably warrants a >mention. > >> >> >>What i mean by that is whether there is a difference between a NULL value >>and an absent value. >>I don't mean to totally omit the OCTET STRING, as that to me is a >>violation of RFC 5280 since the extnValue is not OPTIONAL. >> >>Or do you mean that some have implemented this extension omitting the >>OCTET STRING altogether. >>That should result in a decoding error in such case. >> >>/Stefan >> >>On 1/27/13 7:56 PM, "Carl Wallace" wrote: >> >>> >>>On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >>> >>>>Jim, >>>> >>>>The noCheck is a cert extension. Its included in OCSP responder certs >>>>to >>>>signal that this responder cert does not have to be checked for >>>>revocation. >>>> >>>>Would it be OK if I just included the following in the ASN.1 module of >>>>2560bis: >>>> >>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>id-pkix-ocsp-nocheck } >>>> >>> >>>You should add some text discussing the fact that implementations need >>>to >>>handle both empty and NULL, since 2560 was not clear enough on this and >>>there are apparently implementations of each in the field. I think >>>encoding NULL is the common practice. You may want to add a MUST NOT to >>>steer future implementations away from generating empty extensions. >>> >>>> >>>> >>>>That extension definition is not present in 5912, but the extension oid >>>>definition is: >>>>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >>>> >>>> >>>>Or is even this needed?? >>> >>>Yes it is needed and should have been in the ASN.1 module of 2560, not >>>just in the prose. It should probably land in the errata of 5912 as >>>well. >>> >>> >>>>Since this document does not define cert ASN.1 that extension >>>>definition >>>>will not be referred to. >>> >>>There are many extensions defined in documents that do not define >>>certificate ASN.1. >>> >>>> >>>>/Stefan >>>> >>>> >>>> >>>>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >>>> >>>>>In terms of what I did for 5912 - This fell into the general space of >>>>>the >>>>>document was underspecified. >>>>> >>>>>Defining the NULL is optional and not necessary but nice. >>>>> >>>>>The following would be added to 5912 >>>>> >>>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>>id-pkix-ocsp-nocheck } ---- without the type defined >>>>>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>>>>id-pkix-ocsp-nocheck } ---- with the type defined >>>>> >>>>>They are the effectively the same. Most ASN.1 compilers have a NULL >>>>>type >>>>>that can be directly referenced so adding the extra layer of >>>>>indirection >>>>>does not make the user's job any easier or harder. >>>>> >>>>>However, I would not know from reading the text if this was part of >>>>>the >>>>>extension sequence for ResponseData.responseExtensions or >>>>>SingleResponse.singleExtensions or both. For this reason I did not >>>>>create >>>>>the ASN.1 object. >>>>> >>>>>Jim >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>>>> Sent: Sunday, January 27, 2013 8:17 AM >>>>>> To: Stefan Santesson >>>>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>>>>> Subject: Re: ASN.1 expression of extensions with absent extension >>>>>>value >>>>>> >>>>>> I'll defer to Jim Schaad on this, but I think what Denis is asking >>>>>>for >>>>>>is >>>>>alright, >>>>>> but overkill. A standalone definition without an example of usage >>>>>>adds >>>>>>no >>>>>> value to the document; using a generic name like "NoCheck" could in >>>>>>fact >>>>>be >>>>>> dangerous to someone reading the document not terribly carefully. >>>>>>But >>>>>> adding a definition and a usage for it seems fine. >>>>>> >>>>>> --Paul Hoffman= >>>>> >>>> >>>> >>>>_______________________________________________ >>>>pkix mailing list >>>>pkix@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pkix >>> >>> >> >> > > From stefan@aaa-sec.com Sun Jan 27 12:01: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 6D3A121F8759 for ; Sun, 27 Jan 2013 12:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 qUJfAqd5GP-S for ; Sun, 27 Jan 2013 12:01:40 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 65B6621F8721 for ; Sun, 27 Jan 2013 12:01:40 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 68AD51FA5DC for ; Sun, 27 Jan 2013 21:01:39 +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 HiCnDgOztPfJ for ; Sun, 27 Jan 2013 21:01:38 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AF3C21FA5D2 for ; Sun, 27 Jan 2013 21:01:38 +0100 (CET) Received: (qmail 7117 invoked from network); 27 Jan 2013 20:01:38 -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 ; 27 Jan 2013 20:01:38 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 21:01:34 +0100 From: Stefan Santesson To: Carl Wallace , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 20:01:41 -0000 Top clarify. OCTET STRING with no value would be: 04 00 OCTET STRING with NULL value is: 04 02 05 00 /Stefan On 1/27/13 8:59 PM, "Stefan Santesson" wrote: >Oh thanks, > >The coin just dropped. > >NULL actually has a DER encoding of its own. 05 00 >Which indeed means that absent and NULL is very different. > >OK. Since we have already decided that NoChek SHALL have a NULL value, >then its just a matter of describing it accurately in the ASN.1 of the >spec. >What ever method we choose I will do the same with the extended revoke >extension syntax. > >/Stefan > > >On 1/27/13 8:38 PM, "Carl Wallace" wrote: > >> >>On 1/27/13 2:16 PM, "Stefan Santesson" wrote: >> >>>Sorry Carl, >>> >>>But my understanding of ASN-1 is apparently missing something. >>> >>>What is the difference between absent and NULL? >> >>Jim gave a good example of the difference between NULL and absent. >>Here's >>a snip from a responder certificate that illustrates NULL usage in >>context >>(where the first column is the length): >> >>15: SEQUENCE { >> 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) >> 2: OCTET STRING, encapsulates { >> 0: NULL >> : } >> : } >> >> >>Here's the hex of the dump above: 300F06092B060105050730010504020500. >>Replace 020500 with 00 and update the SEQUENCE length for the absent >>version. >> >>I don't ever recall seeing a certificate that used an empty OCTET STRING, >>but list traffic has indicated they exist so it probably warrants a >>mention. >> >>> >>> >>>What i mean by that is whether there is a difference between a NULL >>>value >>>and an absent value. >>>I don't mean to totally omit the OCTET STRING, as that to me is a >>>violation of RFC 5280 since the extnValue is not OPTIONAL. >>> >>>Or do you mean that some have implemented this extension omitting the >>>OCTET STRING altogether. >>>That should result in a decoding error in such case. >>> >>>/Stefan >>> >>>On 1/27/13 7:56 PM, "Carl Wallace" wrote: >>> >>>> >>>>On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >>>> >>>>>Jim, >>>>> >>>>>The noCheck is a cert extension. Its included in OCSP responder certs >>>>>to >>>>>signal that this responder cert does not have to be checked for >>>>>revocation. >>>>> >>>>>Would it be OK if I just included the following in the ASN.1 module of >>>>>2560bis: >>>>> >>>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>>id-pkix-ocsp-nocheck } >>>>> >>>> >>>>You should add some text discussing the fact that implementations need >>>>to >>>>handle both empty and NULL, since 2560 was not clear enough on this and >>>>there are apparently implementations of each in the field. I think >>>>encoding NULL is the common practice. You may want to add a MUST NOT >>>>to >>>>steer future implementations away from generating empty extensions. >>>> >>>>> >>>>> >>>>>That extension definition is not present in 5912, but the extension >>>>>oid >>>>>definition is: >>>>>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >>>>> >>>>> >>>>>Or is even this needed?? >>>> >>>>Yes it is needed and should have been in the ASN.1 module of 2560, not >>>>just in the prose. It should probably land in the errata of 5912 as >>>>well. >>>> >>>> >>>>>Since this document does not define cert ASN.1 that extension >>>>>definition >>>>>will not be referred to. >>>> >>>>There are many extensions defined in documents that do not define >>>>certificate ASN.1. >>>> >>>>> >>>>>/Stefan >>>>> >>>>> >>>>> >>>>>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >>>>> >>>>>>In terms of what I did for 5912 - This fell into the general space of >>>>>>the >>>>>>document was underspecified. >>>>>> >>>>>>Defining the NULL is optional and not necessary but nice. >>>>>> >>>>>>The following would be added to 5912 >>>>>> >>>>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>>>id-pkix-ocsp-nocheck } ---- without the type defined >>>>>>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>>>>>id-pkix-ocsp-nocheck } ---- with the type defined >>>>>> >>>>>>They are the effectively the same. Most ASN.1 compilers have a NULL >>>>>>type >>>>>>that can be directly referenced so adding the extra layer of >>>>>>indirection >>>>>>does not make the user's job any easier or harder. >>>>>> >>>>>>However, I would not know from reading the text if this was part of >>>>>>the >>>>>>extension sequence for ResponseData.responseExtensions or >>>>>>SingleResponse.singleExtensions or both. For this reason I did not >>>>>>create >>>>>>the ASN.1 object. >>>>>> >>>>>>Jim >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>>>>> Sent: Sunday, January 27, 2013 8:17 AM >>>>>>> To: Stefan Santesson >>>>>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>>>>>> Subject: Re: ASN.1 expression of extensions with absent extension >>>>>>>value >>>>>>> >>>>>>> I'll defer to Jim Schaad on this, but I think what Denis is asking >>>>>>>for >>>>>>>is >>>>>>alright, >>>>>>> but overkill. A standalone definition without an example of usage >>>>>>>adds >>>>>>>no >>>>>>> value to the document; using a generic name like "NoCheck" could in >>>>>>>fact >>>>>>be >>>>>>> dangerous to someone reading the document not terribly carefully. >>>>>>>But >>>>>>> adding a definition and a usage for it seems fine. >>>>>>> >>>>>>> --Paul Hoffman= >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>pkix mailing list >>>>>pkix@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>> >>> >> From carl@redhoundsoftware.com Sun Jan 27 12:08:09 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 118F621F87B6 for ; Sun, 27 Jan 2013 12:08:09 -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=[AWL=-1.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] 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 9t3WbRktxHoK for ; Sun, 27 Jan 2013 12:08:08 -0800 (PST) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0E21F8522 for ; Sun, 27 Jan 2013 12:08:07 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 7so599253qea.37 for ; Sun, 27 Jan 2013 12:08:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=frOQTsjKtBVOQK/cjc6IxTmKdToifg9jbPkDWZ+FWGg=; b=hjNs5kh5jSDS1A25E4a6dJNWDBMyPfdIrPrErZ5ICOmGXUuH9MCJjIvCma+u509mGC YRBzPC4A9W1Tg7SfgBMumGKy44uEsjDY3h0/0XAJ79SyZC+IDiCGrlgYOqaT5RC2Fl4m 64z6Ja0sPwo8IMnuWe/U7yPAxWKo5drzqeclDWCWppVhNclJOu4gBDcOdUryczNf8Rr3 GdN1LBv3sPdPEHOFTY42FVZldKdLW9306hPpBgYnpakFj8RzC4xTcPaeFS4AmxlYjI9A wB/riCEOX6KAg3keYhK/mO3AYgexFJTItbKJhoVDAjBqb4Jss5gQRPgfwNoM6k58AKLU eT+w== X-Received: by 10.49.62.42 with SMTP id v10mr15887090qer.2.1359317287419; Sun, 27 Jan 2013 12:08:07 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-120-2.washdc.fios.verizon.net. [173.79.120.2]) by mx.google.com with ESMTPS id ou3sm4458143qeb.0.2013.01.27.12.08.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 12:08:06 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 27 Jan 2013 15:08:03 -0500 From: Carl Wallace To: Stefan Santesson , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmomybrlS6iEHjaaV64Q+uSc1GdhrGuENowrHduE+7jg7yXLxJDMg5wAAdEFZPf46ULRUKX Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 20:08:09 -0000 Yep. Or in the full context: 300F06092B060105050730010504020500 300D06092B06010505073001050400 On 1/27/13 3:01 PM, "Stefan Santesson" wrote: >Top clarify. > >OCTET STRING with no value would be: 04 00 >OCTET STRING with NULL value is: 04 02 05 00 > >/Stefan > > > > >On 1/27/13 8:59 PM, "Stefan Santesson" wrote: > >>Oh thanks, >> >>The coin just dropped. >> >>NULL actually has a DER encoding of its own. 05 00 >>Which indeed means that absent and NULL is very different. >> >>OK. Since we have already decided that NoChek SHALL have a NULL value, >>then its just a matter of describing it accurately in the ASN.1 of the >>spec. >>What ever method we choose I will do the same with the extended revoke >>extension syntax. >> >>/Stefan >> >> >>On 1/27/13 8:38 PM, "Carl Wallace" wrote: >> >>> >>>On 1/27/13 2:16 PM, "Stefan Santesson" wrote: >>> >>>>Sorry Carl, >>>> >>>>But my understanding of ASN-1 is apparently missing something. >>>> >>>>What is the difference between absent and NULL? >>> >>>Jim gave a good example of the difference between NULL and absent. >>>Here's >>>a snip from a responder certificate that illustrates NULL usage in >>>context >>>(where the first column is the length): >>> >>>15: SEQUENCE { >>> 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) >>> 2: OCTET STRING, encapsulates { >>> 0: NULL >>> : } >>> : } >>> >>> >>>Here's the hex of the dump above: 300F06092B060105050730010504020500. >>>Replace 020500 with 00 and update the SEQUENCE length for the absent >>>version. >>> >>>I don't ever recall seeing a certificate that used an empty OCTET >>>STRING, >>>but list traffic has indicated they exist so it probably warrants a >>>mention. >>> >>>> >>>> >>>>What i mean by that is whether there is a difference between a NULL >>>>value >>>>and an absent value. >>>>I don't mean to totally omit the OCTET STRING, as that to me is a >>>>violation of RFC 5280 since the extnValue is not OPTIONAL. >>>> >>>>Or do you mean that some have implemented this extension omitting the >>>>OCTET STRING altogether. >>>>That should result in a decoding error in such case. >>>> >>>>/Stefan >>>> >>>>On 1/27/13 7:56 PM, "Carl Wallace" wrote: >>>> >>>>> >>>>>On 1/27/13 1:46 PM, "Stefan Santesson" wrote: >>>>> >>>>>>Jim, >>>>>> >>>>>>The noCheck is a cert extension. Its included in OCSP responder certs >>>>>>to >>>>>>signal that this responder cert does not have to be checked for >>>>>>revocation. >>>>>> >>>>>>Would it be OK if I just included the following in the ASN.1 module >>>>>>of >>>>>>2560bis: >>>>>> >>>>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>>>id-pkix-ocsp-nocheck } >>>>>> >>>>> >>>>>You should add some text discussing the fact that implementations need >>>>>to >>>>>handle both empty and NULL, since 2560 was not clear enough on this >>>>>and >>>>>there are apparently implementations of each in the field. I think >>>>>encoding NULL is the common practice. You may want to add a MUST NOT >>>>>to >>>>>steer future implementations away from generating empty extensions. >>>>> >>>>>> >>>>>> >>>>>>That extension definition is not present in 5912, but the extension >>>>>>oid >>>>>>definition is: >>>>>>id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } >>>>>> >>>>>> >>>>>>Or is even this needed?? >>>>> >>>>>Yes it is needed and should have been in the ASN.1 module of 2560, not >>>>>just in the prose. It should probably land in the errata of 5912 as >>>>>well. >>>>> >>>>> >>>>>>Since this document does not define cert ASN.1 that extension >>>>>>definition >>>>>>will not be referred to. >>>>> >>>>>There are many extensions defined in documents that do not define >>>>>certificate ASN.1. >>>>> >>>>>> >>>>>>/Stefan >>>>>> >>>>>> >>>>>> >>>>>>On 1/27/13 7:05 PM, "Jim Schaad" wrote: >>>>>> >>>>>>>In terms of what I did for 5912 - This fell into the general space >>>>>>>of >>>>>>>the >>>>>>>document was underspecified. >>>>>>> >>>>>>>Defining the NULL is optional and not necessary but nice. >>>>>>> >>>>>>>The following would be added to 5912 >>>>>>> >>>>>>>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>>>>>>id-pkix-ocsp-nocheck } ---- without the type defined >>>>>>>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>>>>>>id-pkix-ocsp-nocheck } ---- with the type defined >>>>>>> >>>>>>>They are the effectively the same. Most ASN.1 compilers have a NULL >>>>>>>type >>>>>>>that can be directly referenced so adding the extra layer of >>>>>>>indirection >>>>>>>does not make the user's job any easier or harder. >>>>>>> >>>>>>>However, I would not know from reading the text if this was part of >>>>>>>the >>>>>>>extension sequence for ResponseData.responseExtensions or >>>>>>>SingleResponse.singleExtensions or both. For this reason I did not >>>>>>>create >>>>>>>the ASN.1 object. >>>>>>> >>>>>>>Jim >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>>>>>> Sent: Sunday, January 27, 2013 8:17 AM >>>>>>>> To: Stefan Santesson >>>>>>>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>>>>>>> Subject: Re: ASN.1 expression of extensions with absent extension >>>>>>>>value >>>>>>>> >>>>>>>> I'll defer to Jim Schaad on this, but I think what Denis is asking >>>>>>>>for >>>>>>>>is >>>>>>>alright, >>>>>>>> but overkill. A standalone definition without an example of usage >>>>>>>>adds >>>>>>>>no >>>>>>>> value to the document; using a generic name like "NoCheck" could >>>>>>>>in >>>>>>>>fact >>>>>>>be >>>>>>>> dangerous to someone reading the document not terribly carefully. >>>>>>>>But >>>>>>>> adding a definition and a usage for it seems fine. >>>>>>>> >>>>>>>> --Paul Hoffman= >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>pkix mailing list >>>>>>pkix@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>>> >>>> >>>> >>> > > From ben@digicert.com Sun Jan 27 14:10:43 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 BCCD021F87D3 for ; Sun, 27 Jan 2013 14:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qTo+hkBjbcls for ; Sun, 27 Jan 2013 14:10:41 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id A716B21F86FA for ; Sun, 27 Jan 2013 14:10:41 -0800 (PST) Received: from BWILSONL1 (c-98-202-210-96.hsd1.ut.comcast.net [98.202.210.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 9D0438FA034 for ; Sun, 27 Jan 2013 15:10:40 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1359324640; bh=k+Bc5nN15PwyGmFejHTkJab2FH0OBOGwSXrU8BZfy4E=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date; b=sRGQsnr04KEsuTJzZ6j1gawHw4cKQXcrYWmCcJP1IAd0AAn2k5KfWnIG20XCh/NlD LweTvF/oDMO/zrspE/nWhRvjV1ZqxVkr9R2hqVcj/+KRMQrAH7e8kFXYJFbFH4zWjI k4jCLg+UH2lJsprRToyn8WnxeoSitxPiuaQXlEcA= From: "Ben Wilson" To: References: <017601cdf9a3$97d904a0$c78b0de0$@digicert.com> In-Reply-To: <017601cdf9a3$97d904a0$c78b0de0$@digicert.com> Date: Sun, 27 Jan 2013 15:10:37 -0700 Organization: DigiCert Message-ID: <005801cdfcdb$2369dc30$6a3d9490$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01CDFCA0.770BC780" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIsYWEM0R8veDa8HUwN2g2ZyyDopAKbc2xql4wQBGA= Content-Language: en-us Subject: Re: [pkix] Update to OCSP Must Staple draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 22:10:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0059_01CDFCA0.770BC780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, I'm trying to close an open issue from the CAB Forum's September meeting. (I think that some of CABF members would like to move forward with further testing of OCSP stapling scenarios, and it would be better before CAB Forum members move forward with the must-staple OID listed below, it would be better to give this community one last opportunity to promulgate one.) Last Thursday when Phill and I discussed this issue during the CABF call, he said that he had not seen a response on this issue, but that members of this group had previously expressed the desire that the OID be within the PKIX space in case other people wanted to take a look at it and see how the OID is supposed to be treated, etc. Also, would it be better to move this discussion to the therightkey mailing list because if anyone is going to do a certificate pointer on must-staple OCSP, then maybe someone ought to identify the OID for delivery of CT proofs through stapled OCSP? Thanks, Ben From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Wednesday, January 23, 2013 12:55 PM To: 'Phillip Hallam-Baker'; pkix@ietf.org Subject: Re: [pkix] Update to OCSP Must Staple draft Has this issue with the "Must Staple" OID been resolved? CABF was looking at adopting "2.23.140.16.1" 2.23.140 is the ca-browser-forum, 16 is ocsp, and 1 would become "must-staple". (I'm currently working on OCSP stapling fixes to section 13.2.1 and appendix B of the CABF's Baseline Requirements.) From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Wednesday, November 14, 2012 7:27 PM To: pkix@ietf.org Subject: [pkix] Update to OCSP Must Staple draft Following conversations at IETF I have removed the minimum version attribute from the Must Staple draft. Basically Ryan Sleevi explained the pool of woe and misery that is TLS version numbering and so I dropped it. The updated version of the draft is http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-03.txt This is not a WG item of course but is of interest to folk here. The main outstanding issue is whether the OID should be cut from the IETF PKIX arc or some other arc (e.g. CABForum). After discussion with Russ (the secretary) and Stephan (as WG chair) it seems that the best approach would be to put it on the PKIX arc so that people know where to look to find the description (i.e. an RFC). This might raise an issue that the WG may need to consider before it closes, namely what the ongoing registration policy is going to be for PKIX OIDs when the registration function reverts to IANA. -- Website: http://hallambaker.com/ ------=_NextPart_000_0059_01CDFCA0.770BC780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    All,

    I’m trying to close an open issue from the CAB Forum’s = September meeting.  (I think that some of CABF  members would = like to move forward with further testing of OCSP stapling scenarios, = and it would be better before CAB Forum members move forward with the = must-staple OID listed below, it would be better to give this community = one last opportunity to promulgate one.)  Last Thursday when Phill = and I discussed this issue during the CABF call, he said that he had not = seen a response on this issue, but that members of this group had = previously expressed the desire that the OID be within the PKIX space in = case other people wanted to take a look at it and see how the OID is = supposed to be treated, etc.   Also, would it be better to = move this discussion to the therightkey mailing list because if anyone = is going to do a certificate pointer on must-staple OCSP, then maybe = someone ought to identify the OID for delivery of CT proofs through = stapled OCSP?

    Thanks,

    Ben    

     

    From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Ben Wilson
    Sent: Wednesday, January 23, 2013 12:55 = PM
    To: 'Phillip Hallam-Baker'; = pkix@ietf.org
    Subject: Re: [pkix] Update to OCSP Must Staple = draft

     

    Has this issue with the “Must Staple” OID been resolved? =

     

    CABF was looking at adopting “2.23.140.16.1”  = 2.23.140 is the ca-browser-forum, 16 is ocsp, and 1 would become = “must-staple”.  (I’m currently working on OCSP = stapling fixes to section 13.2.1 and appendix B of the CABF’s = Baseline Requirements.)

     

    From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Phillip Hallam-Baker
    Sent: Wednesday, = November 14, 2012 7:27 PM
    To: pkix@ietf.org
    Subject: = [pkix] Update to OCSP Must Staple draft

     

    Following = conversations at IETF I have removed the minimum version attribute from = the Must Staple draft. Basically Ryan Sleevi explained the pool of woe = and misery that is TLS version numbering and so I dropped = it.

     

    The updated version of the draft = is

     

     

     

    This is not a WG item of course but is of interest to = folk here.

     

    The main outstanding issue is whether the OID should = be cut from the IETF PKIX arc or some other arc (e.g. CABForum). After = discussion with Russ (the secretary) and Stephan (as WG chair) it seems = that the best approach would be to put it on the PKIX arc so that people = know where to look to find the description (i.e. an = RFC).

     

    This might raise an issue that the WG may need to = consider before it closes, namely what the ongoing registration policy = is going to be for PKIX OIDs when the registration function reverts to = IANA.

     

    --
    Website: http://hallambaker.com/

    ------=_NextPart_000_0059_01CDFCA0.770BC780-- From mstjohns@comcast.net Sun Jan 27 14:17:29 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 58CF921F84CC for ; Sun, 27 Jan 2013 14:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 k2TuDoGDXJ6e for ; Sun, 27 Jan 2013 14:17:28 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0521F8806 for ; Sun, 27 Jan 2013 14:17:28 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id t9pe1k00B0vyq2s59AHTMh; Sun, 27 Jan 2013 22:17:27 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta05.westchester.pa.mail.comcast.net with comcast id tAHT1k0022kB7pQ3RAHTz9; Sun, 27 Jan 2013 22:17:27 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Jan 2013 17:17:39 -0500 To: Russ Housley ,IETF PKIX From: Michael StJohns In-Reply-To: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_354926610==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359325047; bh=iwW7vp7fr9E5phiznxmd5iXMyObkH8Sv69kZ8/fRsxo=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=lQTjWRxyE69hmCxhZoTArTRT+39WT9fgPJziL/INX5dD7aWboDJNuuHEuzF5jYLCZ p//LOovFDI1ppFfu6WEKw+Nz4RIIiXvsDgilKx9xYr7KlmR1Rpus3Pi6l5HCQDmLhm Fz/mdxSaMGrXxz9x0riQHGbv8SjR9XYHGKXgCw8/dS/Uqm8AE+NUFGVFPpksvgCO8N CuHslOwofQMG8P4qwafuaJOrmsMq/m1bWhX4mBURy5iVVcZAtgkMU3naSyTGzu1Y5t ru2J2ActSnS2GxPSU6gJfPCkRYJhmh4YUzAYkfAWIWNTokUipgejfGjompCX7gCHlt /6E9CMA3/62BA== Message-Id: <20130127221728.68F0521F8806@ietfa.amsl.com> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 22:17:29 -0000 --=====================_354926610==.ALT Content-Type: text/plain; charset="us-ascii" At 01:28 PM 1/27/2013, Russ Housley wrote: >From RFC 5280, the extension structure is: > > Extension ::= SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > -- contains the DER encoding of an ASN.1 value > -- corresponding to the extension type identified > -- by extnID > } > >We know that some software automatically tries to decode the content of the OCTET STRING. Will this software fail if the OCTET STRIN is zero length? > >Russ The X.509 standard uses: >Extension ::= SEQUENCE { > extnId EXTENSION.&id ({ExtensionSet}), > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) > ENCODED BY der)} Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType. For NULL is a better choice than . >On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: > >>I feel uncertain how to nest deal with this comment from Denis. >> >>I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition. >> >>This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used. >>Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value? >> >>If this is the case, the same would apply to the new OCSP extension for extended revoke definition. >> >>/Stefan >> >> >>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 >> >>>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 >>> >>_______________________________________________ >>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 --=====================_354926610==.ALT Content-Type: text/html; charset="us-ascii" At 01:28 PM 1/27/2013, Russ Housley wrote:
    From RFC 5280, the extension structure is:

       Extension  ::=  SEQUENCE  {
            extnID      OBJECT IDENTIFIER,
            critical    BOOLEAN DEFAULT FALSE,
            extnValue   OCTET STRING
                        -- contains the DER encoding of an ASN.1 value
                        -- corresponding to the extension type identified
                        -- by extnID
            }

    We know that some software automatically tries to decode the content of the OCTET STRING.  Will this software fail if the OCTET STRIN is zero length?

    Russ


    The X.509 standard uses:

    Extension ::= SEQUENCE {
             extnId EXTENSION.&id ({ExtensionSet}),
             critical BOOLEAN DEFAULT FALSE,
             extnValue OCTET STRING
                   (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
                    ENCODED BY der)}

    Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType.  For  NULL is a better choice than <empty>.




    On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote:

    I feel uncertain how to nest deal with this comment from Denis.

    I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition.

    This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used.
    Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value?

    If this is the case, the same would apply to the new OCSP extension for extended revoke definition.

    /Stefan


    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

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

    --=====================_354926610==.ALT-- From mstjohns@comcast.net Sun Jan 27 14:30:14 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 833AC21F87E3 for ; Sun, 27 Jan 2013 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 uSW5H3j55Xda for ; Sun, 27 Jan 2013 14:30:13 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A946B21F87D9 for ; Sun, 27 Jan 2013 14:30:13 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id t8tu1k00216LCl051AWDFd; Sun, 27 Jan 2013 22:30:13 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta06.westchester.pa.mail.comcast.net with comcast id tAWB1k00T2kB7pQ3SAWBC2; Sun, 27 Jan 2013 22:30:13 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Jan 2013 17:30:23 -0500 To: Stefan Santesson , Denis Pinkas ,Stephen Kent , Jim Schaad , Paul Hoffman From: Michael StJohns In-Reply-To: References: <50FC177A.9050800@bull.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_355690828==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359325813; bh=sbfSaYGvqRFAYHZD+nxTC+MUyeVPEYSwdaiYAHVGmWA=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=gkdJv+jwfY++zB393OA509vgOUJHqUfhmwgwMAul3LAu4Afq9T6pMhwoY/Ar00eTQ gsntif4ytH4eenvVObMgOHlE9GsJoQQhsf7ihitlfxAjjBYMR5Q3l9AZMJcaeU2X92 9iMSjf+YAfV1turURWW7g9q+4I+efI6hAi7zZloCuGObSnCoO+FA0zop248vRqE8nx UOabKnLA2Man6LUziGk0fEdex4wA6SrJPqQOtx8rRvtDw0hjpBwRkXqmvQhDrEWs3J dOjG5AoJcAud77xhN1m3SHxhz96wTxYSIPEoEEr1Ev6HJh+zFhX1Zg/Oa5AeOJh0D6 ew4UuVhgPbnLw== Message-Id: <20130127223013.A946B21F87D9@ietfa.amsl.com> Cc: pkix Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 27 Jan 2013 22:30:14 -0000 --=====================_355690828==.ALT Content-Type: text/plain; charset="us-ascii" As a general question, not exactly related to the encoding problem, why are you using the presence of an extension to signal something? Did I see that there are other signal only extensions? Why not define: id-ce-CA-assertions -- -- extension id CAAssertions ::= SET OF CAAssertion -- could be SEQUENCE CAAssertion ::= OBJECT IDENTIFIER Or if you need a per assertion critical flag - CAAssertion :: SEQUENCE { assertion OBJECT IDENTIFIER, critical BOOLEAN DEFAULT TRUE } The presence of CA Assertions extension and the specific assertion in the list would be equivalent to what you're trying to do with the OCSP stuff, and could be reused for other assertions. (E.g. no revocation mechanism provided, sample certificate - relying parties should not rely, etc). The major difference between this and something like the Policy extensions is that its specific to the CA operation and not the chain of trust above the CA. Mike At 08:13 AM 1/27/2013, Stefan Santesson wrote: >I feel uncertain how to nest deal with this comment from Denis. > >I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition. > >This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used. >Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value? > >If this is the case, the same would apply to the new OCSP extension for extended revoke definition. > >/Stefan > > >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 > >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 > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix --=====================_355690828==.ALT Content-Type: text/html; charset="us-ascii" As a general question, not exactly related to the encoding problem, why are you using the presence of an extension to signal something?  Did I see that there are other signal only extensions?

    Why not define:

    id-ce-CA-assertions -- -- extension id

    CAAssertions ::= SET OF CAAssertion  -- could be SEQUENCE

    CAAssertion ::= OBJECT IDENTIFIER

    Or if you need a per assertion critical flag -

    CAAssertion ::  SEQUENCE  {
             assertion OBJECT IDENTIFIER,
             critical BOOLEAN DEFAULT TRUE
       } 


    The presence of CA Assertions extension and the specific assertion in the list would be equivalent to what you're trying to do with the OCSP stuff, and could be reused for other assertions.  (E.g. no revocation mechanism provided, sample certificate - relying parties should not rely, etc).

    The major difference between this and something like the Policy extensions is that its specific to the CA operation and not the chain of trust above the CA.

    Mike





    At 08:13 AM 1/27/2013, Stefan Santesson wrote:
    I feel uncertain how to nest deal with this comment from Denis.

    I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition.

    This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used.
    Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value?

    If this is the case, the same would apply to the new OCSP extension for extended revoke definition.

    /Stefan


    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

    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

     

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

    --=====================_355690828==.ALT-- From piyush@ditenity.com Sun Jan 27 16:47: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 8A9A121F856C for ; Sun, 27 Jan 2013 16:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K+zLKUvwFzB for ; Sun, 27 Jan 2013 16:47:55 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1521F853A for ; Sun, 27 Jan 2013 16:47:54 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id k7so642095oag.16 for ; Sun, 27 Jan 2013 16:47: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:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=Ebdo8vnYQ7QWVf4Vzsm+Fz2uP8Ek3U1XwYlvYxccEGo=; b=fM4EDVfutFpFXrBdp1uAwXrfQCh0BjWdfcsIupHR8L9qml0Xc6yZ+4C37I94eD3et1 w4DfHsQrqxTUCjauwoJ+EPFcIDAJyubZgkmhDAN0Mq3DmLAqWrsrdcQxVb228sYMO7kd cvQVrEziaB14hpuiQX9z1YPL1dCs7nTVt/3DZ7TIEev14sgbxYfr6kBrPgTM4UdIWjq9 NNjqrs0OimroCIx+CNtwdA6OgXasxllhEHalzfYMB6t0Z+DKbG+8nSXk1/Z6dYod4QjG DEZlFJ2a1xdTRQsXoK0FXBo+XtISyBIutqvoBLlw1F2U8XC9QEkzzG1QOIOBWPFAu1ED 2UBA== X-Received: by 10.60.8.65 with SMTP id p1mr10239361oea.4.1359334074281; Sun, 27 Jan 2013 16:47:54 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s8sm6568020obm.19.2013.01.27.16.47.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 16:47:53 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <031501cdfca9$2df25060$89d6f120$@ditenity.com> In-Reply-To: Date: Sun, 27 Jan 2013 16:47:48 -0800 Message-ID: <041d01cdfcf1$190a3670$4b1ea350$@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: AQF/x5oxPCSYGagt1uinG1khRD5hS5j6TQmQ Content-Language: en-us X-Gm-Message-State: ALoCoQkY30QpkHfEGT8MvjxkuGfcOpJnWbaImXfMaQDI6Pndaz3i7WkpNefzvFs4I50xQEu1p35J Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 00:47:55 -0000 Stefan, You've decided to introduce the concept of non-issued certificates as part of this update. Don't you think it makes sense to provide guidance to compliant clients as to what their behavior should be if they receive such a response? If clients continue to trust a responder that returned non-issued for a certificate for which the client has performed signature verification, it takes a huge risk by assuming that CA is not compromised. This is an excerpt from section 9 of RFC 2418 "It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs in a Security Considerations section. Note that merely noting a significant security hole is no longer sufficient. IETF developed technologies should not add insecurity to the environment in which they are run." > This and other PKI problem works as long as the trusted authorities are intact and honest. Unfortunately, this is not true according to current update. You need non-issued only if you questioning the value of signature on the certificate being validated. > Dealing with and detecting compromise is not part of the protocol design. I thought this was the only reason for the new changes in current draft, driven by requirements from CAB forum. If you just want them to allow changing the meaning of revoked, have them do it through a single response extension which defines the meaning through an object which is part of that extension. They can then define the extended meaning in a separate document and do the security analysis there. If you are introducing non-issued in main OCSP document, you should provide guidelines on how a compliant client should deal with such a response. > What you say is true, but including that information would be very incomplete. I agree with you there. Unfortunately what we have today is incomplete because we have not provided any guidance to compliant clients on how to deal with such a response securely. > I would prefer not to go there at all. We are already going there with this update. > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Sunday, January 27, 2013 11:38 AM > To: Piyush Jain; pkix@ietf.org > Subject: Re: Responder trust issue for non-issued certificates not addressed > in 2560 bis draft 11 > > We are not trying to solve CA compromise. CA compromise and strategies for > dealing with them is far to complex to deal with in this update. > Further I don't think we should put any requirements on clients to do > anything in this regard in the base protocol standard. > > This and other PKI problem works as long as the trusted authorities are intact > and honest. > Dealing with and detecting compromise is not part of the protocol design. > > What you say is true, but including that information would be very > incomplete. > I would prefer not to go there at all. > > /Stefan > > > On 1/27/13 5:12 PM, "Piyush Jain" wrote: > > >Stefan, > > > >I raised the issue regarding responder trust in case of non-issued > >certificate earlier (please see attached email). > > > >In my opinion, section 4.2.2.2 in the current draft violates section 9 > >of RFC 2418 in cases where the responder indicates that the certificate > >is non-issued. > >Not sure if my proposal in the attached email handles this issue > >completely, but it is a step forward from the current text. > > > >Regards > >-Piyush > From ietf@augustcellars.com Sun Jan 27 18:48: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 6A0A921F8450 for ; Sun, 27 Jan 2013 18:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL1ld2TzhHho for ; Sun, 27 Jan 2013 18:48:10 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E905E21F8447 for ; Sun, 27 Jan 2013 18:48:09 -0800 (PST) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7FAD738F02; Sun, 27 Jan 2013 18:48:09 -0800 (PST) From: "Jim Schaad" To: "'Michael StJohns'" , "'Russ Housley'" , "'IETF PKIX'" References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> In-Reply-To: <20130127221728.68F0521F8806@ietfa.amsl.com> Date: Sun, 27 Jan 2013 18:47:43 -0800 Message-ID: <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CDFCBE.CBEB8C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHE/rlLdKL4ZOzLoFb3/wBoJdQDSAI/qz9JAl8lcSeYSw7DEA== Content-Language: en-us Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 02:48:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CDFCBE.CBEB8C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, It is perfectly legal for it to not have a value even with the newer syntax. That is both absent and not absent are legal to put here. There is not current syntax to say that the internal value is optional. But if there is no type associated with the OID then the correct answer is that the ASN.1 for it would be an empty string. Russ, It would not surprise me if something that was just randomly decoding would have problems in this case. However, if the decoding is not directed by the OID then there is a problem because it will not know how to treat all of the ASN.1 it might encode. For example while it could decode the basic pieces of an implicitly tagged value, it would have no idea what any of it meant. I don't think I would overly worry about this case except for things like Peter's ASN.1 dumpper. Jim From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns Sent: Sunday, January 27, 2013 2:18 PM To: Russ Housley; IETF PKIX Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value At 01:28 PM 1/27/2013, Russ Housley wrote: >From RFC 5280, the extension structure is: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } We know that some software automatically tries to decode the content of the OCTET STRING. Will this software fail if the OCTET STRIN is zero length? Russ The X.509 standard uses: Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) ENCODED BY der)} Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType. For NULL is a better choice than . On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: I feel uncertain how to nest deal with this comment from Denis. I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition. This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used. Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value? If this is the case, the same would apply to the new OCSP extension for extended revoke definition. /Stefan 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 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 _______________________________________________ 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 ------=_NextPart_000_0019_01CDFCBE.CBEB8C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Michael,

     

    It is perfectly legal for it to not have a value even with the newer = syntax.  That is both absent and not absent are legal to put here. =  There is not current syntax to say that the internal value is = optional.  But if there is no type associated with the OID then the = correct answer is that the ASN.1 for it would be an empty = string.

     

    Russ,

     

    It would not surprise me if something that was just randomly decoding = would have problems in this case.  However, if the decoding is not = directed by the OID then there is a problem because it will not know how = to treat all of the ASN.1 it might encode.  For example while it = could decode the basic pieces of an implicitly tagged value, it would = have no idea what any of it meant.  I don’t think I would = overly worry about this case except for things like Peter’s ASN.1 = dumpper.

     

    Jim

     

     

    From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Michael StJohns
    Sent: Sunday, January 27, 2013 2:18 = PM
    To: Russ Housley; IETF PKIX
    Subject: Re: [pkix] = ASN.1 expression of extensions with absent extension = value

     

    At 01:28 PM = 1/27/2013, Russ Housley wrote:

    From RFC 5280, the extension structure = is:

       Extension  ::=3D  SEQUENCE  = {
            = extnID      OBJECT = IDENTIFIER,
            = critical    BOOLEAN DEFAULT = FALSE,
            = extnValue   OCTET = STRING
              &nb= sp;         -- contains the DER = encoding of an ASN.1 = value
              &nbs= p;         -- corresponding to = the extension type = identified
              = ;          -- by = extnID
            }

    We know = that some software automatically tries to decode the content of the = OCTET STRING.  Will this software fail if the OCTET STRIN is zero = length?

    Russ



    The X.509 = standard uses:


    Extension ::=3D SEQUENCE = {
             extnId = EXTENSION.&id = ({ExtensionSet}),
             = critical BOOLEAN DEFAULT = FALSE,
             extnValue = OCTET = STRING
              &nb= sp;    (CONTAINING = EXTENSION.&ExtnType({ExtensionSet}{@extnId})
       &nb= sp;            = ENCODED BY der)}


    Which = suggests that you can't just use an empty OCTET STRING since there is no = "empty" ExtnType.  For  NULL is a better choice than = <empty>.





    On Jan 27, 2013, at 8:13 AM, Stefan Santesson = wrote:


    I feel uncertain = how to nest deal with this comment from Denis.

    I have compared = with RFC 5912 and it does only define the extension OID, but provides no = extension definition.

    This seem to be the model used in several = places where an extension with absent extension value (empty octet = string) is used.
    Is there any reason to go beyond this and do as = Denis suggests. That is, to provide an Extension definition with a = Syntaxt holding an element with a NULL value?

    If this is the = case, the same would apply to the new OCSP extension for extended revoke = definition.

    /Stefan


    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


    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
     

    _______________________________________________
    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

     

    ------=_NextPart_000_0019_01CDFCBE.CBEB8C90-- From mstjohns@comcast.net Sun Jan 27 21:29: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 2E23721F86E8 for ; Sun, 27 Jan 2013 21:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.001, 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 WXkM0dPOraZ0 for ; Sun, 27 Jan 2013 21:29:18 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 627E321F8696 for ; Sun, 27 Jan 2013 21:29:13 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id tHRw1k0060Fqzac51HVC3n; Mon, 28 Jan 2013 05:29:12 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta08.westchester.pa.mail.comcast.net with comcast id tHVB1k00E2kB7pQ3UHVB7v; Mon, 28 Jan 2013 05:29:12 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jan 2013 00:29:25 -0500 To: "Jim Schaad" , "'Russ Housley'" ,"'IETF PKIX'" From: Michael StJohns In-Reply-To: <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> 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=1359350952; bh=RfppV8XlIheMIIy7AYJ+0ReAodF+MzU8Nte2zeckVwg=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=l7nWw2b4rqEaFyBW9ZxubnbMzJWNCfMy57Gbics8u5Hqsyl/wBXWrrkQsIY1+qN+C gy/LPXYKq48pro/UGEICwMpD4JS3r3Cb+2BNDi4HhdjYWuRjlpmeyJVNRBblWy38Ry YxU94m1g26J5d5dJvHd3txqZkIqKpubf3vV7eECECh2bHsVFc0osZNU8Zw1PQUNjpl 2iP9Kd2JHA0Rngi+l/6c+xs0iilnp7xc525yJCiZc1pAdoBcVVgCdgTic996IHG5pc g44F17ZIB5oKLpmM7Yg8C3LR3OR5rdZthGAjgLOhm8Zz99Pe3heAZ66yXB3BKidcRU 1yNZvop2BU2QQ== Message-Id: <20130128052913.627E321F8696@ietfa.amsl.com> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 05:29:19 -0000 At 09:47 PM 1/27/2013, Jim Schaad wrote: >It is perfectly legal for it to not have a value even with the newer syntax. That is both absent and not absent are legal to put here. There is not current syntax to say that the internal value is optional. But if there is no type associated with the OID then the correct answer is that the ASN.1 for it would be an empty string. > > Um - probably not. The "new" syntax (e.g. both X.509 and RFC5912) to define an extension is extensionName EXTENSION ::= { SYNTAX IDENTIFIED BY } NULL is a valid type. The empty string is not. Or is there a way you can see where this can be expressed? You had >re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- without the type defined >re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- with the type defined And either of those would work. But I don't think that re-ocsp-nocheck EXTENSION ::= { SYNTAX IDENTIFIED BY id-pkix-ocsp-nocheck } is valid ASN1. And I don't think that re-ocsp-nocheck EXTENSION ::= { IDENTIFIED BY id-pkix-ocsp-nocheck } is a valid extension definition. Mike From stefan@aaa-sec.com Sun Jan 27 22:19: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 57CAE21F88D8 for ; Sun, 27 Jan 2013 22:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.094 X-Spam-Level: X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 4Jj1SZw60oRG for ; Sun, 27 Jan 2013 22:19:32 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6CA21F87DF for ; Sun, 27 Jan 2013 22:19:31 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 699DB24D1FF for ; Mon, 28 Jan 2013 07:19: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 yJ-uS7emPkWY for ; Mon, 28 Jan 2013 07:19:28 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C103D24D204 for ; Mon, 28 Jan 2013 07:19:28 +0100 (CET) Received: (qmail 68422 invoked from network); 28 Jan 2013 06:19:28 -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 ; 28 Jan 2013 06:19:28 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 07:19:26 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 In-Reply-To: <041d01cdfcf1$190a3670$4b1ea350$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 06:19:33 -0000 Let me correct you on one thing. I have not decided to introduce the concept of non-issued. That is a WG decision. I personally don't expect clients to assume anything but the fact that the trust service they trust, is actually trustworthy and intact. I don't expect clients to be on the scout for detecting compromised CA's. Saying that clients SHOULD treat that CA as compromised, puts requirements on client code developers to: - Detect the reason for revocation - Trying to determine if it may be caused by CA compromise - Remembering that CA to alter the interpretation of results for certs issued by that CA in the future. This is going WAY beyond what clients should be expected to do. The fact that we give servers a legitimate way to not respond "god" to non-issued certificates, does not mean that we need to impose a new scope of operation upon the clients. /Stefan On 1/28/13 1:47 AM, "Piyush Jain" wrote: >Stefan, > >You've decided to introduce the concept of non-issued certificates as part >of this update. >Don't you think it makes sense to provide guidance to compliant clients as >to what their behavior should be if they receive such a response? > >If clients continue to trust a responder that returned non-issued for a >certificate for which the client has performed signature verification, it >takes a huge risk by assuming that CA is not compromised. > >This is an excerpt from section 9 of RFC 2418 >"It should be noted that all IETF working groups are required to examine >and >understand the security implications of any technology they develop. This >analysis must be included in any resulting RFCs in a Security >Considerations >section. Note that merely noting a significant security hole is no longer >sufficient. IETF developed technologies should not add insecurity to the >environment in which they are run." > >> This and other PKI problem works as long as the trusted authorities are >intact and honest. >Unfortunately, this is not true according to current update. You need >non-issued only if you questioning the value of signature on the >certificate >being validated. > >> Dealing with and detecting compromise is not part of the protocol >>design. >I thought this was the only reason for the new changes in current draft, >driven by requirements from CAB forum. > >If you just want them to allow changing the meaning of revoked, have them >do >it through a single response extension which defines the meaning through >an >object which is part of that extension. They can then define the extended >meaning in a separate document and do the security analysis there. >If you are introducing non-issued in main OCSP document, you should >provide >guidelines on how a compliant client should deal with such a response. > >> What you say is true, but including that information would be very >incomplete. >I agree with you there. Unfortunately what we have today is incomplete >because we have not provided any guidance to compliant clients on how to >deal with such a response securely. > >> I would prefer not to go there at all. >We are already going there with this update. > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Sunday, January 27, 2013 11:38 AM >> To: Piyush Jain; pkix@ietf.org >> Subject: Re: Responder trust issue for non-issued certificates not >addressed >> in 2560 bis draft 11 >> >> We are not trying to solve CA compromise. CA compromise and strategies >>for >> dealing with them is far to complex to deal with in this update. >> Further I don't think we should put any requirements on clients to do >> anything in this regard in the base protocol standard. >> >> This and other PKI problem works as long as the trusted authorities are >intact >> and honest. >> Dealing with and detecting compromise is not part of the protocol >>design. >> >> What you say is true, but including that information would be very >> incomplete. >> I would prefer not to go there at all. >> >> /Stefan >> >> >> On 1/27/13 5:12 PM, "Piyush Jain" wrote: >> >> >Stefan, >> > >> >I raised the issue regarding responder trust in case of non-issued >> >certificate earlier (please see attached email). >> > >> >In my opinion, section 4.2.2.2 in the current draft violates section 9 >> >of RFC 2418 in cases where the responder indicates that the certificate >> >is non-issued. >> >Not sure if my proposal in the attached email handles this issue >> >completely, but it is a step forward from the current text. >> > >> >Regards >> >-Piyush >> > > From peter.sylvester@edelweb.fr Mon Jan 28 00:16:22 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 DF24C21F890D for ; Mon, 28 Jan 2013 00:16:22 -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=[AWL=-0.001, 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 TArL+kzEMoBU for ; Mon, 28 Jan 2013 00:16:20 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id B160821F88A2 for ; Mon, 28 Jan 2013 00:16:12 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id E662F5E0F8 for ; Mon, 28 Jan 2013 09:16:13 +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 D16425E0CE for ; Mon, 28 Jan 2013 09:16:13 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 94D4F5E1C9 for ; Mon, 28 Jan 2013 09:15:41 +0100 (CET) Received: from smtps.on-x.com (unknown [192.168.14.66]) by mail1.on-x.com (Postfix) with ESMTP id 88D395E1BA for ; Mon, 28 Jan 2013 09:15:41 +0100 (CET) Received: from [192.168.0.35] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 4C8D25E0D5 for ; Mon, 28 Jan 2013 09:14:23 +0100 (CET) Message-ID: <510633CA.4000601@edelweb.fr> Date: Mon, 28 Jan 2013 09:16:10 +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: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> In-Reply-To: <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------000103030704020203080400" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 08:16:23 -0000 This is a multi-part message in MIME format. --------------000103030704020203080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/2013 03:47 AM, Jim Schaad wrote: > > Michael, > > It is perfectly legal for it to not have a value even with the newer syntax. That is both absent > and not absent are legal to put here. There is not current syntax to say that the internal value > is optional. But if there is no type associated with the OID then the correct answer is that the > ASN.1 for it would be an empty string. > -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID an asn.1 value is not empty. 5280 asn.1 syntax allows an empty octet string but this is not conformant with the comment. if a relying party knows about an extension there is a bilateral agreement with the issuer of the extension about a type and that there is an encoding of a value of that type. in this case the octet string cannot be empty. there may be relying parties that do not decode non recognized extensions, but creating one that has no value seems clearly wrong according to the definition. The newer syntax makes an empty octet string illegal in asn.1 a correctly implemented encoder would require a value in its api. decoders that reject this, that's another story. > Russ, > > It would not surprise me if something that was just randomly decoding would have problems in this > case. However, if the decoding is not directed by the OID then there is a problem because it will > not know how to treat all of the ASN.1 it might encode. For example while it could decode the > basic pieces of an implicitly tagged value, it would have no idea what any of it meant. I don't > think I would overly worry about this case except for things like Peter's ASN.1 dumpper. > > Jim > > *From:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf Of *Michael StJohns > *Sent:* Sunday, January 27, 2013 2:18 PM > *To:* Russ Housley; IETF PKIX > *Subject:* Re: [pkix] ASN.1 expression of extensions with absent extension value > > At 01:28 PM 1/27/2013, Russ Housley wrote: > > From RFC 5280, the extension structure is: > > Extension ::= SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > -- contains the DER encoding of an ASN.1 value > -- corresponding to the extension type identified > -- by extnID > } > > We know that some software automatically tries to decode the content of the OCTET STRING. Will > this software fail if the OCTET STRIN is zero length? > > Russ > > > > The X.509 standard uses: > > > *Extension ::= SEQUENCE { > extnId EXTENSION.&id ({ExtensionSet}), > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) > ENCODED BY der)}* > > > Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType. > For NULL is a better choice than . > > > > > > On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: > > > I feel uncertain how to nest deal with this comment from Denis. > > I have compared with RFC 5912 and it does only define the extension OID, but provides no extension > definition. > > This seem to be the model used in several places where an extension with absent extension value > (empty octet string) is used. > Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension > definition with a Syntaxt holding an element with a NULL value? > > If this is the case, the same would apply to the new OCSP extension for extended revoke definition. > > /Stefan > > > 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 > > > 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 > * > > _______________________________________________ > 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 --------------000103030704020203080400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 01/28/2013 03:47 AM, Jim Schaad wrote:

    Michael,

     

    It is perfectly legal for it to not have a value even with the newer syntax.  That is both absent and not absent are legal to put here.  There is not current syntax to say that the internal value is optional.  But if there is no type associated with the OID then the correct answer is that the ASN.1 for it would be an empty string.

                        -- contains the DER encoding of an ASN.1 value
                        -- corresponding to the extension type identified
                        -- by extnID

    an asn.1 value is not empty.
     
    5280 asn.1 syntax allows an empty octet string but this
    is not conformant with the comment. 

    if a relying party knows about an extension there is a bilateral
    agreement with the issuer of the extension about a type and
    that there is an encoding of a value of that type.
    in this case the octet string cannot be empty.

    there may be relying parties that do not decode non recognized
    extensions, but creating one that has no value seems clearly wrong
    according to the definition. 

    The newer syntax makes an empty octet string illegal in asn.1
    a correctly implemented encoder would require a value in its api.
    decoders that reject this, that's another story.

     

    Russ,

     

    It would not surprise me if something that was just randomly decoding would have problems in this case.  However, if the decoding is not directed by the OID then there is a problem because it will not know how to treat all of the ASN.1 it might encode.  For example while it could decode the basic pieces of an implicitly tagged value, it would have no idea what any of it meant.  I don’t think I would overly worry about this case except for things like Peter’s ASN.1 dumpper.

     

    Jim

     

     

    From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns
    Sent: Sunday, January 27, 2013 2:18 PM
    To: Russ Housley; IETF PKIX
    Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value

     

    At 01:28 PM 1/27/2013, Russ Housley wrote:

    From RFC 5280, the extension structure is:

       Extension  ::=  SEQUENCE  {
            extnID      OBJECT IDENTIFIER,
            critical    BOOLEAN DEFAULT FALSE,
            extnValue   OCTET STRING
                        -- contains the DER encoding of an ASN.1 value
                        -- corresponding to the extension type identified
                        -- by extnID
            }

    We know that some software automatically tries to decode the content of the OCTET STRING.  Will this software fail if the OCTET STRIN is zero length?

    Russ



    The X.509 standard uses:


    Extension ::= SEQUENCE {
             extnId EXTENSION.&id ({ExtensionSet}),
             critical BOOLEAN DEFAULT FALSE,
             extnValue OCTET STRING
                   (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
                    ENCODED BY der)}


    Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType.  For  NULL is a better choice than <empty>.





    On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote:


    I feel uncertain how to nest deal with this comment from Denis.

    I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition.

    This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used.
    Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value?

    If this is the case, the same would apply to the new OCSP extension for extended revoke definition.

    /Stefan


    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


    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
     

    _______________________________________________
    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

    --------------000103030704020203080400-- From alexey.melnikov@isode.com Mon Jan 28 00:55:03 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 7902B21F85FE for ; Mon, 28 Jan 2013 00:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 0-l++AeRv+2h for ; Mon, 28 Jan 2013 00:55:02 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7821F85D7 for ; Mon, 28 Jan 2013 00:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1359363301; d=isode.com; s=selector; i=@isode.com; bh=tfOpcI56u31NFCRsp0vcI1kItxZ1Lv7EdzOuTFM/0OU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dszlHYalsTuIcK+CZJHO8qTxLZfJnShxhcNuNqEbSx9xLF8v3FEuH8CkdE++aXWypMtQqo 5/mc6jUdwv2X6lwibxUAFY3scniUi3imyH7Vc58g/83y1OTElkl5oO2T6o75m6pjCWxeqQ QqDvKhMVAcsQawbP7Zrr41EPCkVmRto=; Received: from [10.5.211.101] ((unknown) [212.183.140.31]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 28 Jan 2013 08:55:01 +0000 X-SMTP-Protocol-Errors: NORDNS References: In-Reply-To: Message-Id: X-Mailer: iPhone Mail (10A523) From: Alexey Melnikov Date: Mon, 28 Jan 2013 08:59:03 +0000 To: Stefan Santesson MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6323CD78-90CB-4984-823D-2807FDCF7579 Cc: pkix Subject: Re: [pkix] The new RFC2560bis drafts 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, 28 Jan 2013 08:55:03 -0000 --Apple-Mail-6323CD78-90CB-4984-823D-2807FDCF7579 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Stefan, On 27 Jan 2013, at 13:19, Stefan Santesson wrote: > 3 new drafts on RFC2560bis merits an explanation. > Firs I resubmitted version 09, which I unsuccessfully tried to publish on t= he 16th of Jan. This draft captures changes to respond the the extensive deb= ate and reviews on the list up until the 16th. > Draft 10 deals with Alexey's comments. This looks good. I will reply to your point about proxies/clients separately= . > Draft 11 includes updates due to Deni's list of comments, excluding the AS= N.1 question posted separately on the list. > /Stefan >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-6323CD78-90CB-4984-823D-2807FDCF7579 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    Hi Stefan,

    On 27 Jan 2013, at 13:19, Stefan Santesson <stefan@aaa-sec.com> wrote:

    3 new drafts on RFC2560bis merits an explanation.
    1. Firs I resubmitted version 09, which I unsuccessfully tried to publish on the 16th of Jan. This draft captures changes to respond the the extensive debate and reviews on the list up until the 16th.
    2. Draft 10 deals with Alexey's comments.

    This looks good. I will reply to your point about proxies/clients separately.
    1. Draft 11 includes updates due to Deni's list of comments, excluding the ASN.1 question posted separately on the list.
    /Stefan

    _______________________________________________
    pkix mailing list
    pkix@ietf.org
    https://www.ietf.org/mailman/listinfo/pkix
    --Apple-Mail-6323CD78-90CB-4984-823D-2807FDCF7579-- From stefan@aaa-sec.com Mon Jan 28 00:56: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 D438521F8626 for ; Mon, 28 Jan 2013 00:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 wuSOD+ATXTTr for ; Mon, 28 Jan 2013 00:56:24 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC5621F84C8 for ; Mon, 28 Jan 2013 00:56:23 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2B15D266CF2 for ; Mon, 28 Jan 2013 09:56:22 +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 iHNd2jrFuy1h for ; Mon, 28 Jan 2013 09:56:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A95CC266CE9 for ; Mon, 28 Jan 2013 09:56:21 +0100 (CET) Received: (qmail 63059 invoked from network); 28 Jan 2013 08:56:21 -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 ; 28 Jan 2013 08:56:21 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 09:56:19 +0100 From: Stefan Santesson To: Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: ASN.1 expression of extensions with absent extension value In-Reply-To: <011d01cdfcb8$e4351b00$ac9f5100$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 08:56:24 -0000 Jim, RFC 2560bis currently has no 2002 syntax as it just refers to 5912. I realise that we need this not only for the nocheck extension, but also for the new extended-revoke extension, which is an OCSP extension BTW. I would hate for the RFC2560bis to have to wait for an update of 5912. Should I just import the ASN.1 from 5912 into RFC 2560 bis, get a new module OID and then add the extension definitions to this new module? I would then: - Add that rfc2560bis updates 5912 - Add: ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-nocheck } - Add: re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-extended-revoke } Is that a reasonable course of action? /Stefan On 1/27/13 7:05 PM, "Jim Schaad" wrote: >In terms of what I did for 5912 - This fell into the general space of the >document was underspecified. > >Defining the NULL is optional and not necessary but nice. > >The following would be added to 5912 > >re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- without the type defined >re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >id-pkix-ocsp-nocheck } ---- with the type defined > >They are the effectively the same. Most ASN.1 compilers have a NULL type >that can be directly referenced so adding the extra layer of indirection >does not make the user's job any easier or harder. > >However, I would not know from reading the text if this was part of the >extension sequence for ResponseData.responseExtensions or >SingleResponse.singleExtensions or both. For this reason I did not create >the ASN.1 object. > >Jim > > >> -----Original Message----- >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >> Sent: Sunday, January 27, 2013 8:17 AM >> To: Stefan Santesson >> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >> Subject: Re: ASN.1 expression of extensions with absent extension value >> >> I'll defer to Jim Schaad on this, but I think what Denis is asking for >>is >alright, >> but overkill. A standalone definition without an example of usage adds >>no >> value to the document; using a generic name like "NoCheck" could in fact >be >> dangerous to someone reading the document not terribly carefully. But >> adding a definition and a usage for it seems fine. >> >> --Paul Hoffman= > From era@x500.eu Mon Jan 28 03:48:22 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 9F23921F880B for ; Mon, 28 Jan 2013 03:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 sLUBj6KE+WOi for ; Mon, 28 Jan 2013 03:48:16 -0800 (PST) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id 720A821F87FE for ; Mon, 28 Jan 2013 03:48:14 -0800 (PST) Received: from ([62.44.135.83]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id NMY76609; Mon, 28 Jan 2013 12:48:09 +0100 From: "Erik Andersen" To: "'IETF PKIX'" References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> <20130128052913.627E321F8696@ietfa.amsl.com> In-Reply-To: <20130128052913.627E321F8696@ietfa.amsl.com> Date: Mon, 28 Jan 2013 12:48:06 +0100 Message-ID: <003101cdfd4d$5851aff0$08f50fd0$@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: Ac39GHSMGyP+8gmvQjOuLIHFP3VdGAAMiPtg Content-Language: da Cc: Jean-Paul Lemaire Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 11:48:22 -0000 >From a pure ASN.1 view point, both an empty octet string syntax and a = NULL syntax are legal. However, in the latter case, the NULL has to be = imbedded in the octet string, i.e., is encoded as: 24020500H. However, you have a much more fundamental problem. A general tool is not able to judge whether the syntax imbedded in the octet string is legal = or not. Only a specialised tool that "knows" the different extension can = make that check. An extension with syntax octet string without restriction is a goody for = an attacker attempting to do a collision attack. The X.509 definition of extension does not have that problem. Erik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af Michael StJohns Sendt: 28. januar 2013 06:29 Til: Jim Schaad; 'Russ Housley'; 'IETF PKIX' Emne: Re: [pkix] ASN.1 expression of extensions with absent extension = value At 09:47 PM 1/27/2013, Jim Schaad wrote: >It is perfectly legal for it to not have a value even with the newer syntax. That is both absent and not absent are legal to put here. = There is not current syntax to say that the internal value is optional. But if = there is no type associated with the OID then the correct answer is that the = ASN.1 for it would be an empty string. > >=20 Um - probably not. The "new" syntax (e.g. both X.509 and RFC5912) to define an extension = is=20 extensionName EXTENSION ::=3D { SYNTAX IDENTIFIED BY } NULL is a valid type. The empty string is not. Or is there a way you = can see where this can be expressed? You had=20 >re-ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL IDENTIFIED BY=20 >id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck=20 >EXTENSION :=3D {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } = ----=20 >with the type defined And either of those would work. But I don't think that re-ocsp-nocheck EXTENSION ::=3D { SYNTAX =20 IDENTIFIED BY id-pkix-ocsp-nocheck } is valid ASN1.=20 And I don't think that re-ocsp-nocheck EXTENSION ::=3D { IDENTIFIED BY id-pkix-ocsp-nocheck } is a valid extension definition. Mike _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Mon Jan 28 08:18: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 392EE21F87D5 for ; Mon, 28 Jan 2013 08:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfchaIRXuVtm for ; Mon, 28 Jan 2013 08:18:35 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id EF4D421F870E for ; Mon, 28 Jan 2013 08:18:34 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id un3so2925403obb.38 for ; Mon, 28 Jan 2013 08:18:34 -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=s5jKYmVi0W3JgSrkywEgH+dj8DwmRgQdy9bM8MnIrSE=; b=jqdc5oNrMlNOHTDoLeFbpFw1Wdw3PLxXmGHm9JxA4ubc3njTf5e71cY/iuNjtzTMut bTMdOLTHJHDAncm8b/ITIn5W4zpg04s3752tlJjl9BGsea9/Enxd5Z173Krz6m/isfUQ fhgr+5z3gxg9OlcVvYAZ63FkGoWYA21gUTOhb88xD00mp9gUTjDGuJ2Gsk/lTJK8S2Xd eL48WSOV2lrOVxMtWNPlUFTtBVqHoxHe+1ADn6wCf4tA3k4wEAwsgvKSEvGBrwkKwJPY HfZVggxTAIYzW/57LiPv9yKgjiU5d/b8u9kk5ElFHWtikfDcE+UBoAzXH/4r+WNixNpt cgeA== X-Received: by 10.60.12.99 with SMTP id x3mr11939784oeb.71.1359389914489; Mon, 28 Jan 2013 08:18:34 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id a9sm8246506oee.10.2013.01.28.08.18.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Jan 2013 08:18:34 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <041d01cdfcf1$190a3670$4b1ea350$@ditenity.com> In-Reply-To: Date: Mon, 28 Jan 2013 08:18:29 -0800 Message-ID: <054501cdfd73$1d2eb8c0$578c2a40$@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: AQFkaa6Sf2yorhPfG22PU6bAdp7pCJkx+HHg Content-Language: en-us X-Gm-Message-State: ALoCoQlFbXvOUE6MLrUJ1qlIaKU4gQChS1yxd0n7/HWJHTiD1M878poaK70R9yKQWEMcISm7QsvD Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 16:18:36 -0000 > I have not decided to introduce the concept of non-issued. That is a WG decision. My apologies. It was wrong choice of words on my part. > I personally don't expect clients to assume anything but the fact that the trust service they trust, is actually trustworthy and intact. This is a good point. Can you please clarify how the client can establish trust in a response signed by a delegated responder if the response says that certificate is non-issued. There will be developers who will read this RFC and ponder over the same question. For your reference I am including the relevant text from 2560-bis-11 that deals with responder trust --BEGIN QUOTE 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: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that issued the certificate in question; or 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." --END QUOTE You can see that based on above, the client MUST reject the response if it is signed by either the CA or a CA delegated responder and if the payload certificate is not issued by the same CA. >Saying that clients SHOULD treat that CA as compromised, puts requirements on client code developers to: > - Detect the reason for revocation > - Trying to determine if it may be caused by CA compromise > - Remembering that CA to alter the interpretation of results for certs issued > by that CA in the future. All fair points. I'm open to any other solution that addresses these issues that were brought up earlier. (I believe that you acknowledged them as well). - How can a compliant client establish trust in a response signed by a delegated responder that indicates that certificate is not issued by the CA? - How should a client deal with the scenario where it has a certificate that is signed by the CA but the CA delegated responder returns a response saying that the certificate is non-issued.? IMO, the only conclusion here is that the CA or RA is compromised and any proposed solution should capture this fact. May be we can have a provision for determining client behavior based on a local policy, to allow clients to make the choice for themselves. Nevertheless, the document should state the implications of any choice clearly. > The fact that we give servers a legitimate way to not respond "god" to non-issued certificates, Slight correction there. Servers can respond with unknown, UNAUTHORIZED, TRY LATER even before the current update and many large CA vendors already do this. You probably meant - legitimate way to respond 'revoked' for "non-issued". > does not mean that we need to impose a new scope of operation upon the clients. We have a new extension that is being defined in this update. I appreciate the backward compatibility requirement. However, the document still needs to define how future clients who decide to parse this extension, deal with this information. Otherwise, what is the point of including this extension at all? From stefan@aaa-sec.com Mon Jan 28 08:50:22 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 5FD1821F89B9 for ; Mon, 28 Jan 2013 08:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 wRjfOKEyBIaa for ; Mon, 28 Jan 2013 08:50:21 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08321F89C0 for ; Mon, 28 Jan 2013 08:50:20 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 756492B38B6 for ; Mon, 28 Jan 2013 17:50:17 +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 vCfTFVEOYLbh for ; Mon, 28 Jan 2013 17:50:16 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BB7782B38BB for ; Mon, 28 Jan 2013 17:50:16 +0100 (CET) Received: (qmail 95671 invoked from network); 28 Jan 2013 16:50:16 -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 ; 28 Jan 2013 16:50:16 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 17:50:14 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 In-Reply-To: <054501cdfd73$1d2eb8c0$578c2a40$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 16:50:22 -0000 Comments in line On 1/28/13 5:18 PM, "Piyush Jain" wrote: >Can you please clarify how the client can establish >trust in a response signed by a delegated responder if the response says >that certificate is non-issued. There will be developers who will read >this >RFC and ponder over the same question. >For your reference I am including the relevant text from 2560-bis-11 that >deals with responder trust I think I understand what you mean, but reading the question literally, I don't Trust in a responder is established before you try to interpret it's responses. If you ask how to deal with the response, then the client will not get a non-issued response. It will get a "revoked" status. This indicates that the certificate they asked about should not be trusted. This is all they are expected to do. They are not expected to contact the CA, call the fire department ore trigger a national alert :) This may not be perfect, but it is better than receiving a "good" response. > >--BEGIN QUOTE >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: > 1. Matches a local configuration of OCSP signing authority for the >certificate in question; or > 2. Is the certificate of the CA that issued the certificate in >question; >or > 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." >--END QUOTE > >You can see that based on above, the client MUST reject the response if it >is signed by either the CA or a CA delegated responder and if the payload >certificate is not issued by the same CA. It's quite easy. If they trust the responder, they are supposed to trust the response. If they have not established the trust described above, they MUST reject the response. This has nothing to do with what responses they get. > >>Saying that clients SHOULD treat that CA as compromised, puts >>requirements >on client code developers to: >> - Detect the reason for revocation >> - Trying to determine if it may be caused by CA compromise >> - Remembering that CA to alter the interpretation of results for certs >issued >> by that CA in the future. > >All fair points. I'm open to any other solution that addresses these >issues >that were brought up earlier. (I believe that you acknowledged them as >well). >- How can a compliant client establish trust in a response signed by a >delegated responder that indicates that certificate is not issued by the >CA? This is reiterating the same issue. Establishing trust and parsing responses are two separate issues. Getting a possible "revoked" instead of a "good" does not change this. A client may of course draw conclusions about a certificate that seems genuine, but shows signs of being non-issued, but they are not expected to do so. They are just expected to not accept the certificate if its marked "revoked". As they always have been. >- How should a client deal with the scenario where it has a certificate >that >is signed by the CA but the CA delegated responder returns a response >saying >that the certificate is non-issued.? IMO, the only conclusion here is that >the CA or RA is compromised and any proposed solution should capture this >fact. May be we can have a provision for determining client behavior based >on a local policy, to allow clients to make the choice for themselves. >Nevertheless, the document should state the implications of any choice >clearly. Again, the responder responds revoked. The fact that it is non-issued is hidden in heuristics that the client isn't expected to deal with or understand. In the "client" world, the client is dealing with a revoked cert that is placed on hold. > >> The fact that we give servers a legitimate way to not respond "god" to >non-issued certificates, >Slight correction there. Servers can respond with unknown, UNAUTHORIZED, >TRY >LATER even before the current update and many large CA vendors already do >this. You probably meant - legitimate way to respond 'revoked' for >"non-issued". Absolutely :) > >> does not mean that we need to impose a new scope of operation upon the >clients. >We have a new extension that is being defined in this update. I appreciate >the backward compatibility requirement. However, the document still needs >to >define how future clients who decide to parse this extension, deal with >this >information. Otherwise, what is the point of including this extension at >all? Actually not. There is no need to define client strategies for mitigating or detecting compromised CAs based on the fact that we allowed a revoked response to non-issued certs. This is beyond the scope of the defined protocol to provide such guidance. As long as the protocol is implemented correctly, vendors are free to add any functionality or strategy on top of this. Whatever guidance we would try to come up with, it would be incomplete or to narrow to be generally applicable. In addition, we could easily spend a couple of years debating what that strategy should be. If we ask the clients to be anything but a statless machine dealing with status requests independently according to it's configured trust model, we are asking too much. /Stefan From housley@vigilsec.com Mon Jan 28 09:35: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 E67CC21F8930 for ; Mon, 28 Jan 2013 09:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6hrGX4CwGlC for ; Mon, 28 Jan 2013 09:35:39 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CE04521F8928 for ; Mon, 28 Jan 2013 09:35:38 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7B66E9A400B; Mon, 28 Jan 2013 12:35:35 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id qh36h31sLxqc; Mon, 28 Jan 2013 12:35:13 -0500 (EST) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3EB1C9A4008; Mon, 28 Jan 2013 12:35:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-39-982717839 From: Russ Housley In-Reply-To: <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> Date: Mon, 28 Jan 2013 12:35:23 -0500 Message-Id: <77ECF511-D10F-4540-A6EA-1163A4A2C041@vigilsec.com> References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: IETF PKIX Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 17:35:40 -0000 --Apple-Mail-39-982717839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim: Peter's ASN.1 dumper is one example. What about Microsoft's certificate = viewer? Russ On Jan 27, 2013, at 9:47 PM, Jim Schaad wrote: > Michael, > =20 > It is perfectly legal for it to not have a value even with the newer = syntax. That is both absent and not absent are legal to put here. = There is not current syntax to say that the internal value is optional. = But if there is no type associated with the OID then the correct answer = is that the ASN.1 for it would be an empty string. > =20 > Russ, > =20 > It would not surprise me if something that was just randomly decoding = would have problems in this case. However, if the decoding is not = directed by the OID then there is a problem because it will not know how = to treat all of the ASN.1 it might encode. For example while it could = decode the basic pieces of an implicitly tagged value, it would have no = idea what any of it meant. I don=92t think I would overly worry about = this case except for things like Peter=92s ASN.1 dumpper. > =20 > Jim > =20 > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Michael StJohns > Sent: Sunday, January 27, 2013 2:18 PM > To: Russ Housley; IETF PKIX > Subject: Re: [pkix] ASN.1 expression of extensions with absent = extension value > =20 > At 01:28 PM 1/27/2013, Russ Housley wrote: >=20 > =46rom RFC 5280, the extension structure is: >=20 > Extension ::=3D SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > -- contains the DER encoding of an ASN.1 value > -- corresponding to the extension type identified > -- by extnID > } >=20 > We know that some software automatically tries to decode the content = of the OCTET STRING. Will this software fail if the OCTET STRIN is zero = length? >=20 > Russ >=20 >=20 > The X.509 standard uses: >=20 >=20 > Extension ::=3D SEQUENCE { > extnId EXTENSION.&id ({ExtensionSet}), > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > (CONTAINING = EXTENSION.&ExtnType({ExtensionSet}{@extnId}) > ENCODED BY der)} >=20 > Which suggests that you can't just use an empty OCTET STRING since = there is no "empty" ExtnType. For NULL is a better choice than = . >=20 >=20 >=20 >=20 >=20 > On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: >=20 >=20 > I feel uncertain how to nest deal with this comment from Denis. >=20 > I have compared with RFC 5912 and it does only define the extension = OID, but provides no extension definition. >=20 > This seem to be the model used in several places where an extension = with absent extension value (empty octet string) is used. > Is there any reason to go beyond this and do as Denis suggests. That = is, to provide an Extension definition with a Syntaxt holding an element = with a NULL value? >=20 > If this is the case, the same would apply to the new OCSP extension = for extended revoke definition. >=20 > /Stefan >=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 draft 8. Answer to WGLC >=20 >=20 > 24. On page 17, the text states: > =20 > This SHOULD be a non-critical extension. The value of the extension > SHALL be NULL. > =20 > The ASN.1 syntax is missing. Add: > =20 > NoCheck ::=3D NULL > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =20 --Apple-Mail-39-982717839 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    It is = perfectly legal for it to not have a value even with the newer = syntax.  That is both absent and not absent are legal to put here. =  There is not current syntax to say that the internal value is = optional.  But if there is no type associated with the OID then the = correct answer is that the ASN.1 for it would be an empty = string.
    It = would not surprise me if something that was just randomly decoding would = have problems in this case.  However, if the decoding is not = directed by the OID then there is a problem because it will not know how = to treat all of the ASN.1 it might encode.  For example while it = could decode the basic pieces of an implicitly tagged value, it would = have no idea what any of it meant.  I don=92t think I would overly = worry about this case except for things like Peter=92s ASN.1 = dumpper.
    From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org= ] On Behalf Of Michael = StJohns
    Sent: Sunday, January 27, 2013 = 2:18 PM
    To: Russ Housley; IETF = PKIX
    Subject: Re: [pkix] ASN.1 expression = of extensions with absent extension = value
    At 01:28 PM 1/27/2013, Russ = Housley wrote:

    =46rom RFC 5280, the = extension structure is:

       Extension  ::=3D  = SEQUENCE  {
            = extnID      OBJECT = IDENTIFIER,
            = critical    BOOLEAN DEFAULT = FALSE,
            = extnValue   OCTET = STRING
              &nbs= p;         -- contains the DER = encoding of an ASN.1 = value
               = ;         -- corresponding to = the extension type = identified
              =           -- by = extnID
            }

    We know = that some software automatically tries to decode the content of the = OCTET STRING.  Will this software fail if the OCTET STRIN is zero = length?

    Russ


    The X.509 = standard uses:


    Extension ::=3D SEQUENCE = {
             extnId = EXTENSION.&id = ({ExtensionSet}),
             = critical BOOLEAN DEFAULT = FALSE,
             extnValue = OCTET = STRING
              &nbs= p;    (CONTAINING = EXTENSION.&ExtnType({ExtensionSet}{@extnId})
       &nbs= p;            = ENCODED BY der)}

    Which = suggests that you can't just use an empty OCTET STRING since there is no = "empty" ExtnType.  For  NULL is a better choice than = <empty>.





    On Jan 27, 2013, at 8:13 AM, Stefan Santesson = wrote:


    I feel uncertain how to = nest deal with this comment from Denis.

    I have compared with RFC = 5912 and it does only define the extension OID, but provides no = extension definition.

    This seem to be the model used in several = places where an extension with absent extension value (empty octet = string) is used.
    Is there any reason to go beyond this and do as = Denis suggests. That is, to provide an Extension definition with a = Syntaxt holding an element with a NULL value?

    If this is the = case, the same would apply to the new OCSP extension for extended revoke = definition.

    /Stefan


    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


    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
     
    pkix@ietf.org
    pkix@ietf.org
    To: "'Stefan Santesson'" , References: <054501cdfd73$1d2eb8c0$578c2a40$@ditenity.com> In-Reply-To: Date: Mon, 28 Jan 2013 10:09:13 -0800 Message-ID: <05e001cdfd82$951d3eb0$bf57bc10$@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: AQNhcwKP/o7BKy4V0/Sy3RDgnTXfrpU4FIcw Content-Language: en-us X-Gm-Message-State: ALoCoQlvrrr4dfmWdkqTY/ZTNEdbKTSA9YSTSFTBOe+SW0MOWeO3BhU1JUdbHsdN3H9lYWxqB/ty Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 18:09:22 -0000 You said >"It's quite easy. If they trust the responder, they are supposed to trust the response. >If they have not established the trust described above, they MUST reject the response. >This has nothing to do with what responses they get." I disagree with this statement. The document clearly states that contents of responses should be looked at before accepting the response. This includes looking at signature and certid contained in the response. Not-issued response is something that is introduced in this draft and the current discussion is about how the client establishes trust in such a response. > If you ask how to deal with the response, then the client will not get a non- issued response. It will get a "revoked" status. > This indicates that the certificate they asked about should not be trusted. I was under the impression that syntax of 'revoked' is only being used for backward compatibility. And that revocation date-1970 in conjunction with revocation status onhold implies that certificate is not-issued. Also the new extended revoked extension implies that certificate is not-issued. Are you now arguing that 'revoked' and 'not-issued' should be semantically equivalent as well? Finally, here is a point regarding providing guidance to clients. Non-issued response is a new state that is being introduced in this update. The only reason revoked is being overloaded is to maintain backward compatibility with existing clients. However, to assume that future clients won't try to interpret the meaning of extended revoked extension is short-sighted. Avoiding guidelines on how clients deal with it is bound to cause confusion for anyone who uses this RFC to implement a OCSP client. The fact is that in absence of such guidelines, clients would probably continue to trust a responder that is issued by a CA which is compromised (level of compromise is irrelevant here). At the minimum, we should clarify the implications so clients can make informed choices. I repeat that failing to do so is violation of RFC 2418. [-----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Monday, January 28, 2013 8:50 AM > To: Piyush Jain; pkix@ietf.org > Subject: Re: [pkix] Responder trust issue for non-issued certificates not > addressed in 2560 bis draft 11 > > Comments in line > > On 1/28/13 5:18 PM, "Piyush Jain" wrote: > > >Can you please clarify how the client can establish trust in a response > >signed by a delegated responder if the response says that certificate > >is non-issued. There will be developers who will read this RFC and > >ponder over the same question. > >For your reference I am including the relevant text from 2560-bis-11 > >that deals with responder trust > > I think I understand what you mean, but reading the question literally, I don't > > Trust in a responder is established before you try to interpret it's responses. > If you ask how to deal with the response, then the client will not get a non- > issued response. It will get a "revoked" status. > This indicates that the certificate they asked about should not be trusted. > > This is all they are expected to do. > They are not expected to contact the CA, call the fire department ore trigger > a national alert :) > > This may not be perfect, but it is better than receiving a "good" response. > > > > >--BEGIN QUOTE > >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: > > 1. Matches a local configuration of OCSP signing authority for the > >certificate in question; or > > 2. Is the certificate of the CA that issued the certificate in > >question; or > > 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." > >--END QUOTE > > > >You can see that based on above, the client MUST reject the response if > >it is signed by either the CA or a CA delegated responder and if the > >payload certificate is not issued by the same CA. > > It's quite easy. If they trust the responder, they are supposed to trust the > response. > If they have not established the trust described above, they MUST reject the > response. > > This has nothing to do with what responses they get. > > > > >>Saying that clients SHOULD treat that CA as compromised, puts > >>requirements > >on client code developers to: > >> - Detect the reason for revocation > >> - Trying to determine if it may be caused by CA compromise > >> - Remembering that CA to alter the interpretation of results for > >> certs > >issued > >> by that CA in the future. > > > >All fair points. I'm open to any other solution that addresses these > >issues that were brought up earlier. (I believe that you acknowledged > >them as well). > >- How can a compliant client establish trust in a response signed by a > >delegated responder that indicates that certificate is not issued by > >the CA? > > > This is reiterating the same issue. > Establishing trust and parsing responses are two separate issues. Getting a > possible "revoked" instead of a "good" does not change this. > > A client may of course draw conclusions about a certificate that seems > genuine, but shows signs of being non-issued, but they are not expected to > do so. > They are just expected to not accept the certificate if its marked "revoked". > As they always have been. > > > >- How should a client deal with the scenario where it has a certificate > >that is signed by the CA but the CA delegated responder returns a > >response saying that the certificate is non-issued.? IMO, the only > >conclusion here is that the CA or RA is compromised and any proposed > >solution should capture this fact. May be we can have a provision for > >determining client behavior based on a local policy, to allow clients > >to make the choice for themselves. > >Nevertheless, the document should state the implications of any choice > >clearly. > > Again, the responder responds revoked. The fact that it is non-issued is > hidden in heuristics that the client isn't expected to deal with or understand. > In the "client" world, the client is dealing with a revoked cert that is placed on > hold. > > > > > >> The fact that we give servers a legitimate way to not respond "god" > >> to > >non-issued certificates, > >Slight correction there. Servers can respond with unknown, > >UNAUTHORIZED, TRY LATER even before the current update and many > large > >CA vendors already do this. You probably meant - legitimate way to > >respond 'revoked' for "non-issued". > > Absolutely :) > > > > >> does not mean that we need to impose a new scope of operation upon > >> the > >clients. > >We have a new extension that is being defined in this update. I > >appreciate the backward compatibility requirement. However, the > >document still needs to define how future clients who decide to parse > >this extension, deal with this information. Otherwise, what is the cx> >point of including this extension at all? > > > Actually not. > There is no need to define client strategies for mitigating or detecting > compromised CAs based on the fact that we allowed a revoked response to > non-issued certs. > > This is beyond the scope of the defined protocol to provide such guidance. > As long as the protocol is implemented correctly, vendors are free to add any > functionality or strategy on top of this. > > Whatever guidance we would try to come up with, it would be incomplete or > to narrow to be generally applicable. > In addition, we could easily spend a couple of years debating what that > strategy should be. > > If we ask the clients to be anything but a statless machine dealing with status > requests independently according to it's configured trust model, we are > asking too much. > > /Stefan > > > > > > > > > > > > > > > > > From ietf@augustcellars.com Mon Jan 28 10:32: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 A5D0321F8763 for ; Mon, 28 Jan 2013 10:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cqbqDVw7H1B for ; Mon, 28 Jan 2013 10:32:51 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0384F21F85B2 for ; Mon, 28 Jan 2013 10:32:50 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A25AE38F0D; Mon, 28 Jan 2013 10:32:50 -0800 (PST) From: "Jim Schaad" To: "'Russ Housley'" References: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> <77ECF511-D10F-4540-A6EA-1163A4A2C041@vigilsec.com> In-Reply-To: <77ECF511-D10F-4540-A6EA-1163A4A2C041@vigilsec.com> Date: Mon, 28 Jan 2013 10:32:26 -0800 Message-ID: <004501cdfd85$d28e47f0$77aad7d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CDFD42.C46E8A60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHE/rlLdKL4ZOzLoFb3/wBoJdQDSAI/qz9JAl8lcScCxRmYbwIziO2WmCRSS6A= Content-Language: en-us Cc: 'IETF PKIX' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 18:32:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0046_01CDFD42.C46E8A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If memory serves, for those things which it understands it decodes content. For everthing else it just does a hex dump of the contents and would handle an empty octet string just fine. jim From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, January 28, 2013 9:35 AM To: Jim Schaad Cc: IETF PKIX Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value Jim: Peter's ASN.1 dumper is one example. What about Microsoft's certificate viewer? Russ On Jan 27, 2013, at 9:47 PM, Jim Schaad wrote: Michael, It is perfectly legal for it to not have a value even with the newer syntax. That is both absent and not absent are legal to put here. There is not current syntax to say that the internal value is optional. But if there is no type associated with the OID then the correct answer is that the ASN.1 for it would be an empty string. Russ, It would not surprise me if something that was just randomly decoding would have problems in this case. However, if the decoding is not directed by the OID then there is a problem because it will not know how to treat all of the ASN.1 it might encode. For example while it could decode the basic pieces of an implicitly tagged value, it would have no idea what any of it meant. I don't think I would overly worry about this case except for things like Peter's ASN.1 dumpper. Jim From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns Sent: Sunday, January 27, 2013 2:18 PM To: Russ Housley; IETF PKIX Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value At 01:28 PM 1/27/2013, Russ Housley wrote: >From RFC 5280, the extension structure is: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } We know that some software automatically tries to decode the content of the OCTET STRING. Will this software fail if the OCTET STRIN is zero length? Russ The X.509 standard uses: Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) ENCODED BY der)} Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType. For NULL is a better choice than . On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: I feel uncertain how to nest deal with this comment from Denis. I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition. This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used. Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value? If this is the case, the same would apply to the new OCSP extension for extended revoke definition. /Stefan 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 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 _______________________________________________ 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 ------=_NextPart_000_0046_01CDFD42.C46E8A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    If memory serves, for those things which it understands it decodes = content.  For everthing else it just does a hex dump of the = contents and would handle an empty octet string just = fine.

     

    jim

     

    From:= = Russ Housley [mailto:housley@vigilsec.com]
    Sent: Monday, = January 28, 2013 9:35 AM
    To: Jim Schaad
    Cc: IETF = PKIX
    Subject: Re: [pkix] ASN.1 expression of extensions with = absent extension value

     

    Jim:

     

    Peter's ASN.1 dumper is one example.  What about = Microsoft's certificate viewer?

     

    Russ

     

     

    On = Jan 27, 2013, at 9:47 PM, Jim Schaad wrote:



    Michael,

     

    It is perfectly legal for it to not have a value even with the newer = syntax.  That is both absent and not absent are legal to put here. =  There is not current syntax to say that the internal value is = optional.  But if there is no type associated with the OID then the = correct answer is that the ASN.1 for it would be an empty = string.

     

    Russ,

     

    It would not surprise me if something that was just randomly decoding = would have problems in this case.  However, if the decoding is not = directed by the OID then there is a problem because it will not know how = to treat all of the ASN.1 it might encode.  For example while it = could decode the basic pieces of an implicitly tagged value, it would = have no idea what any of it meant.  I don’t think I would = overly worry about this case except for things like Peter’s ASN.1 = dumpper.

     

    Jim

     

     

    From:=  pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Michael = StJohns
    Sent: Sunday, January 27, 2013 2:18 = PM
    To: Russ = Housley; IETF PKIX
    Subject: Re: [pkix] ASN.1 expression = of extensions with absent extension = value

     

    At 01:28 PM 1/27/2013, Russ Housley = wrote:


    From = RFC 5280, the extension structure is:

       = Extension  ::=3D  SEQUENCE  = {
            = extnID      OBJECT = IDENTIFIER,
            = critical    BOOLEAN DEFAULT = FALSE,
            = extnValue   OCTET = STRING
              &nb= sp;         -- contains the DER = encoding of an ASN.1 = value
              &nbs= p;         -- corresponding to = the extension type = identified
              = ;          -- by = extnID
            }

    We know = that some software automatically tries to decode the content of the = OCTET STRING.  Will this software fail if the OCTET STRIN is zero = length?

    Russ



    The X.509 standard = uses:



    Extension ::=3D = SEQUENCE {
             extnId = EXTENSION.&id = ({ExtensionSet}),
             = critical BOOLEAN DEFAULT = FALSE,
             extnValue = OCTET = STRING
              &nb= sp;    (CONTAINING = EXTENSION.&ExtnType({ExtensionSet}{@extnId})
       &nb= sp;            = ENCODED BY der)}


    Which suggests that you can't just use an empty = OCTET STRING since there is no "empty" ExtnType.  = For  NULL is a better choice than = <empty>.






    On Jan 27, 2013, at 8:13 AM, Stefan Santesson = wrote:



    I = feel uncertain how to nest deal with this comment from Denis.

    I = have compared with RFC 5912 and it does only define the extension OID, = but provides no extension definition.

    This seem to be the model = used in several places where an extension with absent extension value = (empty octet string) is used.
    Is there any reason to go beyond this = and do as Denis suggests. That is, to provide an Extension definition = with a Syntaxt holding an element with a NULL value?

    If this is = the case, the same would apply to the new OCSP extension for extended = revoke definition.

    /Stefan


    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



    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
     

    _______________________________________________
    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

     

     

    ------=_NextPart_000_0046_01CDFD42.C46E8A60-- From hotz@jpl.nasa.gov Mon Jan 28 12:09: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 2E3FA21F86D4 for ; Mon, 28 Jan 2013 12:09:40 -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 NogYK2+EAjQH for ; Mon, 28 Jan 2013 12:09:38 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 454A521F8689 for ; Mon, 28 Jan 2013 12:09:38 -0800 (PST) Received: from dhcp-137-79-189-47.jpl.nasa.gov (dhcp-137-79-189-47.jpl.nasa.gov [137.79.189.47]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0SK9QA6007398 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 28 Jan 2013 12:09:27 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: "Henry B. Hotz" In-Reply-To: Date: Mon, 28 Jan 2013 12:09:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1EA9C8D6-7FEF-424A-854D-0B011C834B0C@jpl.nasa.gov> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1283) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized 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, 28 Jan 2013 20:09:40 -0000 Suggest changing "may" to "MAY". On Jan 27, 2013, at 4:28 AM, Stefan Santesson wrote: >> 2. The current text from section 2 states: >> =20 >> 2. Protocol Overview >> =20 >> 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. >> =20 >> 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.=20= >> =20 >> This text is misleading because readers may think that OCPS = necessarily provides =93timely information=94. >> =20 >=20 > "may" does not mean "necessarily". >=20 >> Proposed text replacement: >> =20 >> 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". >> =20 >> 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. >> =20 >> 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. >> =20 >> =20 >=20 > Not broken >=20 ------------------------------------------------------ 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 Mon Jan 28 12:10: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 3D05D21F89E9 for ; Mon, 28 Jan 2013 12:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 XwkQiMfPUFEr for ; Mon, 28 Jan 2013 12:10:05 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id CB96021F8A08 for ; Mon, 28 Jan 2013 12:10:04 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 91D0E2D6A46 for ; Mon, 28 Jan 2013 21:08:22 +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 Qyi6IdcISvPD for ; Mon, 28 Jan 2013 21:08:20 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 846E92D6795 for ; Mon, 28 Jan 2013 21:08:01 +0100 (CET) Received: (qmail 43382 invoked from network); 28 Jan 2013 20:08:01 -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 ; 28 Jan 2013 20:08:01 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 21:07:58 +0100 From: Stefan Santesson To: Stefan Santesson , Jim Schaad , 'Paul Hoffman' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'pkix' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 20:10:07 -0000 Before we drift too far away from the core issue, Is there an opinion about whether what I propose here would be the right way to go? /Stefan On 1/28/13 9:56 AM, "Stefan Santesson" wrote: >Jim, > >RFC 2560bis currently has no 2002 syntax as it just refers to 5912. > >I realise that we need this not only for the nocheck extension, but also >for the new extended-revoke extension, which is an OCSP extension BTW. > >I would hate for the RFC2560bis to have to wait for an update of 5912. >Should I just import the ASN.1 from 5912 into RFC 2560 bis, get a new >module OID and then add the extension definitions to this new module? > >I would then: >- Add that rfc2560bis updates 5912 >- Add: >ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-nocheck } > >- Add: >re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >id-pkix-ocsp-extended-revoke } > > > >Is that a reasonable course of action? > >/Stefan > > > >On 1/27/13 7:05 PM, "Jim Schaad" wrote: > >>In terms of what I did for 5912 - This fell into the general space of the >>document was underspecified. >> >>Defining the NULL is optional and not necessary but nice. >> >>The following would be added to 5912 >> >>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY >>id-pkix-ocsp-nocheck } ---- without the type defined >>re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY >>id-pkix-ocsp-nocheck } ---- with the type defined >> >>They are the effectively the same. Most ASN.1 compilers have a NULL type >>that can be directly referenced so adding the extra layer of indirection >>does not make the user's job any easier or harder. >> >>However, I would not know from reading the text if this was part of the >>extension sequence for ResponseData.responseExtensions or >>SingleResponse.singleExtensions or both. For this reason I did not >>create >>the ASN.1 object. >> >>Jim >> >> >>> -----Original Message----- >>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>> Sent: Sunday, January 27, 2013 8:17 AM >>> To: Stefan Santesson >>> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix >>> Subject: Re: ASN.1 expression of extensions with absent extension value >>> >>> I'll defer to Jim Schaad on this, but I think what Denis is asking for >>>is >>alright, >>> but overkill. A standalone definition without an example of usage adds >>>no >>> value to the document; using a generic name like "NoCheck" could in >>>fact >>be >>> dangerous to someone reading the document not terribly carefully. But >>> adding a definition and a usage for it seems fine. >>> >>> --Paul Hoffman= >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Mon Jan 28 12:24: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 6F79621F8574 for ; Mon, 28 Jan 2013 12:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 kzFtVBnhXfrS for ; Mon, 28 Jan 2013 12:24:58 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20F21F854F for ; Mon, 28 Jan 2013 12:24:56 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 3154C2D93D2 for ; Mon, 28 Jan 2013 21:24:54 +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 i8pGLuGqEiwT for ; Mon, 28 Jan 2013 21:24:53 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A1D6B2D93CB for ; Mon, 28 Jan 2013 21:24:53 +0100 (CET) Received: (qmail 87196 invoked from network); 28 Jan 2013 20:24:53 -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 ; 28 Jan 2013 20:24:53 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 21:24:51 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 In-Reply-To: <05e001cdfd82$951d3eb0$bf57bc10$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 20:24:59 -0000 On 1/28/13 7:09 PM, "Piyush Jain" wrote: >You said >>"It's quite easy. If they trust the responder, they are supposed to trust >the response. >>If they have not established the trust described above, they MUST reject >the response. >>This has nothing to do with what responses they get." > >I disagree with this statement. The document clearly states that contents >of >responses should be looked at before accepting the response. This includes >looking at signature and certid contained in the response. Of course, I didn't say it because its central and kind of obvious. > >Not-issued response is something that is introduced in this draft No, look closer. The draft does NOT define a "not-issued" response. It allows the "revoked" response if a certificate serial number has never been issued. That is two entirely different things. >and the >current discussion is about how the client establishes trust in such a >response. As it would with any other response. > >> If you ask how to deal with the response, then the client will not get a >non- issued response. It will get a "revoked" status. >> This indicates that the certificate they asked about should not be >trusted. > >I was under the impression that syntax of 'revoked' is only being used for >backward compatibility. And that revocation date-1970 in conjunction with >revocation status onhold implies that certificate is not-issued. No. The meaning is just to allow the server to provide a response that has the likely outcome that the client will not use that cert, if there even is such a cert and the request isn't simply an error. > Also the >new extended revoked extension implies that certificate is not-issued. >Are you now arguing that 'revoked' and 'not-issued' should be semantically >equivalent as well? No, the extension signals that the server supports this extended use of revoked. It says nothing about whether it is used for any of the certs in a particular response. > >Finally, here is a point regarding providing guidance to clients. >Non-issued response is a new state that is being introduced in this >update. This is getting tiresome. No, there is no new state. There is an extended use of "revoked". >The only reason revoked is being overloaded is to maintain backward >compatibility with existing clients. However, to assume that future >clients >won't try to interpret the meaning of extended revoked extension is >short-sighted. Avoiding guidelines on how clients deal with it is bound to >cause confusion for anyone who uses this RFC to implement a OCSP client. No, all may experience with PKI development suggests contrary to your prediction. However, if we tried to craft some extensive guidance on how to try to detect and mitigate CA compromise, that will definitely cause confusion and make implementers think they have to deal with this. >The fact is that in absence of such guidelines, clients would probably >continue to trust a responder that is issued by a CA which is compromised >(level of compromise is irrelevant here). Which is exactly what we expect them to do. It is not the clients task to spot and correct the problem of compromised CAs. That is the task of trust service providers and the controls they put in place. > At the minimum, we should clarify >the implications so clients can make informed choices. I repeat that >failing to do so is violation of RFC 2418. No. Security considerations requires you to discuss security issues introduced by a protocol. The added mechanism does not introduce any new security vulnerabilities that you have pointed out. To the contrary. /Stefan From simon@tardell.se Mon Jan 28 12:39: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 69E1621F8739 for ; Mon, 28 Jan 2013 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 uYJnmKZv2+mc for ; Mon, 28 Jan 2013 12:39:54 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7D21F86EC for ; Mon, 28 Jan 2013 12:39:54 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so4489747lba.37 for ; Mon, 28 Jan 2013 12:39:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=dPUT4/BsDpgBeqmUidHiu6S7YzeCmWV1jgIaiZ6dNag=; b=erh0mT3G0AtE5Owbtx/BG6ZsCRdiZxlz4regfjedNYTJ+xtlEyjpNZWIi1P6uk/HyY xE46VYtKwbyqYvUPzA0p2wiuojvfSeJR1HBVRVpoHPCSta9xpQHv1mNJ2/MvjR5pV6Qo FjbKHZIpoADNtf/s0dReu58PS2KurEAtGQBI1nPU7Cf8fPzk26gnaNlqy4o22+tZt+J5 Z6au7DLxZUMys1QK/Udjtr2SwWVbJ2mZUIn2J5MreCbESCXWubUpmUSqwXE9ApBROuZt QL0oVRtqAR2OuQwUyY7IkhIVDyT6wRfqsR3j4aiT1LxzzFZSWC3sRgsgZk/OckpirzcV Nfww== X-Received: by 10.112.87.40 with SMTP id u8mr6133935lbz.50.1359405592930; Mon, 28 Jan 2013 12:39:52 -0800 (PST) Received: from [192.168.0.3] (ua-83-227-240-7.cust.bredbandsbolaget.se. [83.227.240.7]) by mx.google.com with ESMTPS id ee5sm4209881lbb.14.2013.01.28.12.39.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 12:39:51 -0800 (PST) References: <1EA9C8D6-7FEF-424A-854D-0B011C834B0C@jpl.nasa.gov> Mime-Version: 1.0 (1.0) In-Reply-To: <1EA9C8D6-7FEF-424A-854D-0B011C834B0C@jpl.nasa.gov> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Simon Tardell Date: Mon, 28 Jan 2013 21:39:46 +0100 To: "Henry B. Hotz" X-Gm-Message-State: ALoCoQkQGobBdBDhTgzYgmVaHJ2oxcJ8pk2N2YZpAwY6Bwv1oiRy279ISaOAsJeiWCeIzs4yZXAL Cc: Stefan Santesson , 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, 28 Jan 2013 20:39:55 -0000 Sent from my iPhone On 28 jan 2013, at 21:09, "Henry B. Hotz" wrote: > Suggest changing "may" to "MAY". MAY to me means "it is permissible" (which is quite distinct from "may" in t= his context). I think Denis has a point, but uses to precise examples. It suffices to say t= hat the timelyness of the information depends on implementational details of= the responder and is in no way guaranteed by the protocol. /Simon >=20 > On Jan 27, 2013, at 4:28 AM, Stefan Santesson wrote: >=20 >>> 2. The current text from section 2 states: >>>=20 >>> 2. Protocol Overview >>>=20 >>> In lieu of or as a supplement to checking against a periodic CRL, it >>> may be necessary to obtain timel information regarding the >>> revocation status of a certificate (cf. RFC5280], Section 3.3). >>> Examples include high-value funds transfer or large stock trades. >>>=20 >>> 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.=20 >>>=20 >>> This text is misleading because readers may think that OCPS necessarily p= rovides =93timely information=94. >>=20 >> "may" does not mean "necessarily". >>=20 >>> Proposed text replacement: >>>=20 >>> 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". >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> Not broken >=20 > ------------------------------------------------------ > 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 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Mon Jan 28 13:10: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 7394721F8684 for ; Mon, 28 Jan 2013 13:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFbgeufhCgDu for ; Mon, 28 Jan 2013 13:10:05 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5DD21F866F for ; Mon, 28 Jan 2013 13:10:05 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id j1so3324778oag.29 for ; Mon, 28 Jan 2013 13:10:04 -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=4YpQn56nR93cuAS3A6vaVlh958iVrwm5hs13BqjtpDA=; b=G+jRXhTLz/Q3QcgJ6chVz+eTJ6MDZYQPq2nNwkgmU/G8e4h88CGhnIEo4CGNw8GdtW g0/3CU7xfMriVW5e8BX8ej7NnajwEXQ/Q+dvu24lpcGLSP293oHH6kJuA6Yk/C5t85H2 8f4xsV0Q8Df5Z0phR2oslVJciBT0Rjq++rNL1QFNyg6zLooywFmSGC6D22GEN7r/AA0R lKQcycPF7i9JBh0jXkaleJZ33jYqONsiuIZnnCM1s1DtJrJ4IpAAfutHliN93WZfUhSl bvO0jK4hNba6InbrVhh13c0fzNV/PPBkkff01yMGhdWvsAM7rJ5r4sLgKSRm6HI2E06a dWyQ== X-Received: by 10.60.32.200 with SMTP id l8mr12859876oei.43.1359407404556; Mon, 28 Jan 2013 13:10:04 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id hs6sm8627756obc.7.2013.01.28.13.10.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Jan 2013 13:10:03 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , References: <05e001cdfd82$951d3eb0$bf57bc10$@ditenity.com> In-Reply-To: Date: Mon, 28 Jan 2013 13:09:59 -0800 Message-ID: <069a01cdfd9b$d5da63b0$818f2b10$@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: AQH2PCh1dF3qeJeMlkB+mamM8wz0XpgOs9zg Content-Language: en-us X-Gm-Message-State: ALoCoQlnHaMsZYuvLbDjdr4e2ywRlrEcFTabWUgtfzMlo8dBIfV6581donAbaOPLDAXNEDUhdbW/ Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 21:10:07 -0000 Stefan, Clearly we have disagreement on how this issue is addressed in current draft. I'm actually surprised at your statement that clients should not differentiate between non-issued and revoked certs, given that the draft mandates that servers include extended revoked extension if it is changing the meaning of revoked. If it is so, why bloat the response with this extension at all. So far, besides you and me, Peter Rybar is the only one who has referred to this issue in one of his posts, acknowledging that it exists. I hope we have opinions of a few others folks before we decide one way or other. -Piyush > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Monday, January 28, 2013 12:25 PM > To: Piyush Jain; pkix@ietf.org > Subject: Re: [pkix] Responder trust issue for non-issued certificates not > addressed in 2560 bis draft 11 > > > > On 1/28/13 7:09 PM, "Piyush Jain" wrote: > > >You said > >>"It's quite easy. If they trust the responder, they are supposed to > >>trust > >the response. > >>If they have not established the trust described above, they MUST > >>reject > >the response. > >>This has nothing to do with what responses they get." > > > >I disagree with this statement. The document clearly states that > >contents of responses should be looked at before accepting the > >response. This includes looking at signature and certid contained in > >the response. > > Of course, I didn't say it because its central and kind of obvious. > > > > >Not-issued response is something that is introduced in this draft > > No, look closer. The draft does NOT define a "not-issued" response. It allows > the "revoked" response if a certificate serial number has never been issued. > That is two entirely different things. > > > >and the > >current discussion is about how the client establishes trust in such a > >response. > > As it would with any other response. > > > > >> If you ask how to deal with the response, then the client will not > >> get a > >non- issued response. It will get a "revoked" status. > >> This indicates that the certificate they asked about should not be > >trusted. > > > >I was under the impression that syntax of 'revoked' is only being used > >for backward compatibility. And that revocation date-1970 in > >conjunction with revocation status onhold implies that certificate is not- > issued. > > No. The meaning is just to allow the server to provide a response that has > the likely outcome that the client will not use that cert, if there even is such a > cert and the request isn't simply an error. > > > > Also the > >new extended revoked extension implies that certificate is not-issued. > >Are you now arguing that 'revoked' and 'not-issued' should be > >semantically equivalent as well? > > No, the extension signals that the server supports this extended use of > revoked. It says nothing about whether it is used for any of the certs in a > particular response. > > > > > >Finally, here is a point regarding providing guidance to clients. > >Non-issued response is a new state that is being introduced in this > >update. > > This is getting tiresome. No, there is no new state. There is an extended use > of "revoked". > > >The only reason revoked is being overloaded is to maintain backward > >compatibility with existing clients. However, to assume that future > >clients won't try to interpret the meaning of extended revoked > >extension is short-sighted. Avoiding guidelines on how clients deal > >with it is bound to cause confusion for anyone who uses this RFC to > >implement a OCSP client. > > No, all may experience with PKI development suggests contrary to your > prediction. > However, if we tried to craft some extensive guidance on how to try to > detect and mitigate CA compromise, that will definitely cause confusion and > make implementers think they have to deal with this. > > > >The fact is that in absence of such guidelines, clients would probably > >continue to trust a responder that is issued by a CA which is > >compromised (level of compromise is irrelevant here). > > Which is exactly what we expect them to do. It is not the clients task to spot > and correct the problem of compromised CAs. > That is the task of trust service providers and the controls they put in place. > > > > At the minimum, we should clarify > >the implications so clients can make informed choices. I repeat that > >failing to do so is violation of RFC 2418. > > No. Security considerations requires you to discuss security issues introduced > by a protocol. > The added mechanism does not introduce any new security vulnerabilities > that you have pointed out. > To the contrary. > > /Stefan > From stefan@aaa-sec.com Mon Jan 28 13:12: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 1C65A21F844F for ; Mon, 28 Jan 2013 13:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 7fGHBqOsiTex for ; Mon, 28 Jan 2013 13:12:52 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id F183221F843C for ; Mon, 28 Jan 2013 13:12:51 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id A21B81E30C49 for ; Mon, 28 Jan 2013 22:12:50 +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 u3phtVvJcS-j for ; Mon, 28 Jan 2013 22:12:50 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1C32012CAAF for ; Mon, 28 Jan 2013 22:12:50 +0100 (CET) Received: (qmail 25723 invoked from network); 28 Jan 2013 21:12:49 -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 ; 28 Jan 2013 21:12:49 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 22:12:47 +0100 From: Stefan Santesson To: Simon Tardell , "Henry B. Hotz" Message-ID: Thread-Topic: [pkix] Review of 2560-bis draft 8. Answer to WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, 28 Jan 2013 21:12:53 -0000 I believe the lower case "may":s are intentional as it does not express testable requirements for interoperability. This is just background information, helping the reader understand the rationale for the protocol. Thus I think the text is sufficiently OK to be left as it is. /Stefan On 1/28/13 9:39 PM, "Simon Tardell" wrote: > > >Sent from my iPhone > >On 28 jan 2013, at 21:09, "Henry B. Hotz" wrote: > >> Suggest changing "may" to "MAY". > > MAY to me means "it is permissible" (which is quite distinct from "may" >in this context). > >I think Denis has a point, but uses to precise examples. It suffices to >say that the timelyness of the information depends on implementational >details of the responder and is in no way guaranteed by the protocol. > >/Simon > > >>=20 >> On Jan 27, 2013, at 4:28 AM, Stefan Santesson wrote: >>=20 >>>> 2. The current text from section 2 states: >>>>=20 >>>> 2. Protocol Overview >>>>=20 >>>> In lieu of or as a supplement to checking against a periodic CRL, it >>>> may be necessary to obtain timel information regarding the >>>> revocation status of a certificate (cf. RFC5280], Section 3.3). >>>> Examples include high-value funds transfer or large stock trades. >>>>=20 >>>> 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. >>>>=20 >>>> This text is misleading because readers may think that OCPS >>>>necessarily provides =B3timely information=B2. >>>=20 >>> "may" does not mean "necessarily". >>>=20 >>>> Proposed text replacement: >>>>=20 >>>> 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". >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> Not broken >>=20 >> ------------------------------------------------------ >> 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 >>=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 From stefan@aaa-sec.com Mon Jan 28 13:37: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 0353621F86F8 for ; Mon, 28 Jan 2013 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 cPu-TayPmy6p for ; Mon, 28 Jan 2013 13:37:35 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0823621F8609 for ; Mon, 28 Jan 2013 13:37:35 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 29ADC2D9DEE for ; Mon, 28 Jan 2013 22:37: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 Lj7N21i-5DCH for ; Mon, 28 Jan 2013 22:37:33 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 672162D9DF2 for ; Mon, 28 Jan 2013 22:37:33 +0100 (CET) Received: (qmail 85542 invoked from network); 28 Jan 2013 21:37:33 -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 ; 28 Jan 2013 21:37:33 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 28 Jan 2013 22:37:31 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 In-Reply-To: <069a01cdfd9b$d5da63b0$818f2b10$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 28 Jan 2013 21:37:36 -0000 Piyush, On 1/28/13 10:09 PM, "Piyush Jain" wrote: >Stefan, > >Clearly we have disagreement on how this issue is addressed in current >draft. >I'm actually surprised at your statement that clients should not >differentiate between non-issued and revoked certs, given that the draft >mandates that servers include extended revoked extension if it is >changing >the meaning of revoked. If it is so, why bloat the response with this >extension at all. As it has been stated here before, and also communicated in the minutes of the last PKIX meeting in Atlanta, the rationale behind including this extension is to allow audits. If something goes wrong and you go through the records, there will be evidence that the responder that provided a particular response of interest, supported this functionality. No client is required to understand this extension or to do anything with it to function properly. My personal preference would be to not define this extension at all, but having this extension is so far WG rough consensus and hence it is included in the draft. Enough people feel strongly about it and it does no damage to have it there. /Stefan > >So far, besides you and me, Peter Rybar is the only one who has referred >to >this issue in one of his posts, acknowledging that it exists. >I hope we have opinions of a few others folks before we decide one way or >other. > >-Piyush > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Monday, January 28, 2013 12:25 PM >> To: Piyush Jain; pkix@ietf.org >> Subject: Re: [pkix] Responder trust issue for non-issued certificates >>not >> addressed in 2560 bis draft 11 >> >> >> >> On 1/28/13 7:09 PM, "Piyush Jain" wrote: >> >> >You said >> >>"It's quite easy. If they trust the responder, they are supposed to >> >>trust >> >the response. >> >>If they have not established the trust described above, they MUST >> >>reject >> >the response. >> >>This has nothing to do with what responses they get." >> > >> >I disagree with this statement. The document clearly states that >> >contents of responses should be looked at before accepting the >> >response. This includes looking at signature and certid contained in >> >the response. >> >> Of course, I didn't say it because its central and kind of obvious. >> >> > >> >Not-issued response is something that is introduced in this draft >> >> No, look closer. The draft does NOT define a "not-issued" response. It >allows >> the "revoked" response if a certificate serial number has never been >issued. >> That is two entirely different things. >> >> >> >and the >> >current discussion is about how the client establishes trust in such a >> >response. >> >> As it would with any other response. >> >> > >> >> If you ask how to deal with the response, then the client will not >> >> get a >> >non- issued response. It will get a "revoked" status. >> >> This indicates that the certificate they asked about should not be >> >trusted. >> > >> >I was under the impression that syntax of 'revoked' is only being used >> >for backward compatibility. And that revocation date-1970 in >> >conjunction with revocation status onhold implies that certificate is >not- >> issued. >> >> No. The meaning is just to allow the server to provide a response that >>has >> the likely outcome that the client will not use that cert, if there even >is such a >> cert and the request isn't simply an error. >> >> >> > Also the >> >new extended revoked extension implies that certificate is not-issued. >> >Are you now arguing that 'revoked' and 'not-issued' should be >> >semantically equivalent as well? >> >> No, the extension signals that the server supports this extended use of >> revoked. It says nothing about whether it is used for any of the certs >>in >a >> particular response. >> >> >> > >> >Finally, here is a point regarding providing guidance to clients. >> >Non-issued response is a new state that is being introduced in this >> >update. >> >> This is getting tiresome. No, there is no new state. There is an >>extended >use >> of "revoked". >> >> >The only reason revoked is being overloaded is to maintain backward >> >compatibility with existing clients. However, to assume that future >> >clients won't try to interpret the meaning of extended revoked >> >extension is short-sighted. Avoiding guidelines on how clients deal >> >with it is bound to cause confusion for anyone who uses this RFC to >> >implement a OCSP client. >> >> No, all may experience with PKI development suggests contrary to your >> prediction. >> However, if we tried to craft some extensive guidance on how to try to >> detect and mitigate CA compromise, that will definitely cause confusion >and >> make implementers think they have to deal with this. >> >> >> >The fact is that in absence of such guidelines, clients would probably >> >continue to trust a responder that is issued by a CA which is >> >compromised (level of compromise is irrelevant here). >> >> Which is exactly what we expect them to do. It is not the clients task >>to >spot >> and correct the problem of compromised CAs. >> That is the task of trust service providers and the controls they put in >place. >> >> >> > At the minimum, we should clarify >> >the implications so clients can make informed choices. I repeat that >> >failing to do so is violation of RFC 2418. >> >> No. Security considerations requires you to discuss security issues >introduced >> by a protocol. >> The added mechanism does not introduce any new security vulnerabilities >> that you have pointed out. >> To the contrary. >> >> /Stefan >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From peter.sylvester@edelweb.fr Mon Jan 28 13:44:17 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 EB6B821F865D for ; Mon, 28 Jan 2013 13:44:17 -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 p7auxeihkr4T for ; Mon, 28 Jan 2013 13:44:17 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97621F8625 for ; Mon, 28 Jan 2013 13:44:17 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 308885E0D7 for ; Mon, 28 Jan 2013 22:44:16 +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 175605E0CF for ; Mon, 28 Jan 2013 22:44:16 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id E4E1B5E152 for ; Mon, 28 Jan 2013 22:43:44 +0100 (CET) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id CF7335E14F for ; Mon, 28 Jan 2013 22:43:44 +0100 (CET) Received: from [10.42.181.214] (unknown [78.250.169.133]) by smtps.on-x.com (Postfix) with ESMTPSA id E85AE5E0E6 for ; Mon, 28 Jan 2013 22:43:18 +0100 (CET) Message-ID: <5106F129.80009@edelweb.fr> Date: Mon, 28 Jan 2013 22:44:09 +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: <73136AF2-6BEA-44F0-8C5E-307B1217A326@vigilsec.com> <20130127221728.68F0521F8806@ietfa.amsl.com> <001801cdfd01$da0c5b90$8e2512b0$@augustcellars.com> <77ECF511-D10F-4540-A6EA-1163A4A2C041@vigilsec.com> <004501cdfd85$d28e47f0$77aad7d0$@augustcellars.com> In-Reply-To: <004501cdfd85$d28e47f0$77aad7d0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------060604060701090703070207" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 21:44:18 -0000 This is a multi-part message in MIME format. --------------060604060701090703070207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/2013 07:32 PM, Jim Schaad wrote: > > If memory serves, for those things which it understands it decodes content. For everthing else it > just does a hex dump of the contents and would handle an empty octet string just fine. > yes: A relying party that doesn't understant the OID, refuses to do whatever. For the convenvience of the poor user it may try like the other Peter's dumpasn. Well, sorry dear user, there is an extension taht I don't understant etc, the content of the thingy is this and that. A consequence of this is that there may be somewhere a recommendation not to use implicit context tags for such syntaxes for primitive types --------------060604060701090703070207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 01/28/2013 07:32 PM, Jim Schaad wrote:

    If memory serves, for those things which it understands it decodes content.  For everthing else it just does a hex dump of the contents and would handle an empty octet string just fine.

    yes:

    A relying party that doesn't understant the OID, refuses to do whatever.
    For the convenvience of the poor user it may try like the other Peter's dumpasn.
    Well, sorry dear user, there is an extension  taht I don't understant etc, the content
    of the thingy is this and that. A consequence of this is that there may be somewhere
    a recommendation not to use implicit context tags for such syntaxes for primitive types
    --------------060604060701090703070207-- From James.H.Manger@team.telstra.com Mon Jan 28 14:52:37 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 1E77921E8039 for ; Mon, 28 Jan 2013 14:52:37 -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=[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 XTXeteTHY4W0 for ; Mon, 28 Jan 2013 14:52:36 -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 D67B021F84F3 for ; Mon, 28 Jan 2013 14:52:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,555,1355058000"; d="scan'208";a="114873674" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 29 Jan 2013 09:52:31 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6969"; a="108226329" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Jan 2013 09:52:30 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 29 Jan 2013 09:52:30 +1100 From: "Manger, James H" To: Stefan Santesson , Jim Schaad , 'pkix' Date: Tue, 29 Jan 2013 09:52:29 +1100 Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value Thread-Index: Ac39k3zZinx6SsKlRhSrvkyr+lSZcwAFUAag Message-ID: <255B9BB34FB7D647A506DC292726F6E115060D425D@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] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 22:52:37 -0000 PiA+UkZDIDI1NjBiaXMgY3VycmVudGx5IGhhcyBubyAyMDAyIHN5bnRheCBhcyBpdCBqdXN0IHJl ZmVycyB0byA1OTEyLg0KPiA+DQo+ID5JIHJlYWxpc2UgdGhhdCB3ZSBuZWVkIHRoaXMgbm90IG9u bHkgZm9yIHRoZSBub2NoZWNrIGV4dGVuc2lvbiwgYnV0DQo+ID5hbHNvIGZvciB0aGUgbmV3IGV4 dGVuZGVkLXJldm9rZSBleHRlbnNpb24sIHdoaWNoIGlzIGFuIE9DU1AgZXh0ZW5zaW9uDQo+IEJU Vy4NCj4gPg0KPiA+SSB3b3VsZCBoYXRlIGZvciB0aGUgUkZDMjU2MGJpcyB0byBoYXZlIHRvIHdh aXQgZm9yIGFuIHVwZGF0ZSBvZiA1OTEyLg0KPiA+U2hvdWxkIEkganVzdCBpbXBvcnQgdGhlIEFT Ti4xIGZyb20gNTkxMiBpbnRvIFJGQyAyNTYwIGJpcywgZ2V0IGEgbmV3DQo+ID5tb2R1bGUgT0lE IGFuZCB0aGVuIGFkZCB0aGUgZXh0ZW5zaW9uIGRlZmluaXRpb25zIHRvIHRoaXMgbmV3IG1vZHVs ZT8NCj4gPg0KPiA+SSB3b3VsZCB0aGVuOg0KPiA+LSBBZGQgdGhhdCByZmMyNTYwYmlzIHVwZGF0 ZXMgNTkxMg0KPiA+LSBBZGQ6DQo+ID5leHQtb2NzcC1ub2NoZWNrIEVYVEVOU0lPTiA6Oj0geyBT WU5UQVggTlVMTCBJREVOVElGSUVEIEJZDQo+ID5pZC1wa2l4LW9jc3Atbm9jaGVjayB9DQo+ID4N Cj4gPi0gQWRkOg0KPiA+cmUtb2NzcC1leHRlbmRlZC1yZXZva2UgRVhURU5TSU9OIDo6PSB7IFNZ TlRBWCBOVUxMIElERU5USUZJRUQgQlkNCj4gPmlkLXBraXgtb2NzcC1leHRlbmRlZC1yZXZva2Ug fQ0KPiA+DQo+ID4NCj4gPg0KPiA+SXMgdGhhdCBhIHJlYXNvbmFibGUgY291cnNlIG9mIGFjdGlv bj8NCj4gPg0KPiA+L1N0ZWZhbg0KDQo+IEJlZm9yZSB3ZSBkcmlmdCB0b28gZmFyIGF3YXkgZnJv bSB0aGUgY29yZSBpc3N1ZSwgSXMgdGhlcmUgYW4gb3Bpbmlvbg0KPiBhYm91dCB3aGV0aGVyIHdo YXQgSSBwcm9wb3NlIGhlcmUgd291bGQgYmUgdGhlIHJpZ2h0IHdheSB0byBnbz8NCj4gL1N0ZWZh bg0KDQoNClllcywgYWRkaW5nICJleHQtb2NzcC1ub2NoZWNrIEVYVEVOU0lPTiA6Oj0geyBTWU5U QVggTlVMTCBJREVOVElGSUVEIEJZIGlkLXBraXgtb2NzcC1ub2NoZWNrIH0iIGlzIHRoZSByaWdo dCB3YXkgdG8gZ28uDQoNClAuUy4gV2UgaGFkIHRoaXMgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3Qg NyBtb250aHMgYWdvLiBTZWUgdGhyZWFkIHRpdGxlZCAiaWQtcGtpeC1vY3NwLW5vY2hlY2sgZXh0 ZW5zaW9uOiBOVUxMIHZzIGVtcHR5Ijogc3RhcnRpbmcgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3BraXgvY3VycmVudC9tc2czMTIyMi5odG1sLCBjb25jbHVkaW5nIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wa2l4L2N1cnJlbnQvbXNnMzEyMjYu aHRtbC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From pgut001@cs.auckland.ac.nz Mon Jan 28 15:56:29 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 B1C8021E8039 for ; Mon, 28 Jan 2013 15:56:29 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XHN-xsKiolt for ; Mon, 28 Jan 2013 15:56:27 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3087821E8030 for ; Mon, 28 Jan 2013 15:56:26 -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=1359417387; x=1390953387; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xBBmg9hIaBAVBpUuMYXGSDKEQY+notdD/S5UfX5tLNY=; b=ZdmeOVaa79qMc4kVPCkNZOTX86S0pp0P5wKgoPKfyjn6opYbeypOzDj2 WQM/b4W27SQW5Ago23F6rF4/iPgCJ+3hJ07psDl2CSracW+dx7Cb21fi1 mby8MIPF1pyqtFJ+Y4vUS/SV6t1eF3+oMeFVc4m8E0zSGoFhdImwvVDcD Q=; X-IronPort-AV: E=Sophos;i="4.84,555,1355050800"; d="scan'208";a="167987164" 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; 29 Jan 2013 12:56:25 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.34]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:56:25 +1300 From: Peter Gutmann To: IETF PKIX , Jim Schaad Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value Thread-Index: Ac39sxRFEzAaxJo4Suq+dHWwNiQg3Q== Date: Mon, 28 Jan 2013 23:56:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333EF7B3@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] ASN.1 expression of extensions with absent extension value 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, 28 Jan 2013 23:56:29 -0000 Russ Housley writes:=0A= =0A= >Peter's ASN.1 dumper is one example.=0A= =0A= I should point out that dumpasn1 goes to great lengths to decode anything i= t=0A= can, no matter how... creatively it's encoded (for example it does content= =0A= sniffing of typical hole values like BIT STRING and OCTET STRING and decode= s=0A= opaque contents if they're also ASN.1), so the fact that dumpasn1 will disp= lay=0A= something doesn't mean that anything else can (or even should) decode it.= =0A= =0A= Peter.=0A= From mstjohns@comcast.net Mon Jan 28 16:13: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 4D44921E8039 for ; Mon, 28 Jan 2013 16:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oiKSG59yDd6T for ; Mon, 28 Jan 2013 16:13: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 1776921F8630 for ; Mon, 28 Jan 2013 16:13:30 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id tPMJ1k0090bG4ec53cDW6h; Tue, 29 Jan 2013 00:13:30 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta03.westchester.pa.mail.comcast.net with comcast id tcDV1k00P2kB7pQ3PcDVr5; Tue, 29 Jan 2013 00:13:30 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jan 2013 19:13:44 -0500 To: Peter Gutmann ,IETF PKIX , Jim Schaad From: Michael StJohns In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333EF7B3@uxcn10-2.UoA.auck land.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73333EF7B3@uxcn10-2.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=1359418410; bh=LocXHTM5VfXzkyGiIjKhCJA2k5XtDX2q1WQ502SNRmU=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=psmeI0a8eN18ONnqG0Yntp1fRQlysD2CLTL0+M30IBGmJr1hMK/8GgBO3PK2B6LOG D9bGucJEmB7P0DWB8qJ+trdmQcX2MI6+CKkYQXi7V+ZZNR60P9tloK6UeAyWKTfrcy 64cEdl4akb11wIFarKoE2YDlkLAkJPttut3alO2EVRQz8/eh5X4RZsA3Jl1fpz/dTO K/TKo2Cn9jVBROjNK/2yV03Y5aGCBuzRCcT6yu9Q7ptiLiCQhIBiYqIz6k/o+lUBHB wPLDKfTf2d1pS6CkAzIdY5Urla2DwhPg+AASKP3b4gDfglfpmGQySgg1ejlkMl3DMV hNmSMrhCK8Bow== Message-Id: <20130129001331.1776921F8630@ietfa.amsl.com> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 29 Jan 2013 00:13:33 -0000 Hi Peter - As I see it, your tool is the equivalent of an XML parser without support for schema or DTD checking. It may be well formed ASN1, and your tool will parse it, but the tool doesn't know - for example - that its parsing a certiificate and that it should ensure the OCTET STRING in an extension *also* needs to contain well formed ASN1. To get around this lack of knowledge (and to make the tool more useful), any time you see an OCTET STRING, you attempt to parse its contents as ASN1, but you don't count it an error if it doesn't parse. Correct? Mike ;At 06:56 PM 1/28/2013, Peter Gutmann wrote: >Russ Housley writes: > >>Peter's ASN.1 dumper is one example. > >I should point out that dumpasn1 goes to great lengths to decode anything it >can, no matter how... creatively it's encoded (for example it does content >sniffing of typical hole values like BIT STRING and OCTET STRING and decodes >opaque contents if they're also ASN.1), so the fact that dumpasn1 will display >something doesn't mean that anything else can (or even should) decode it. > >Peter. >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Tue Jan 29 00:08: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 3270621F8A43 for ; Tue, 29 Jan 2013 00:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.699, 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 1-tUB1e5GbUr for ; Tue, 29 Jan 2013 00:08:55 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id BE93421F8A0D for ; Tue, 29 Jan 2013 00:08:54 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id AE30F2DB176 for ; Tue, 29 Jan 2013 09:08:52 +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 vx7HvmcS2dTi for ; Tue, 29 Jan 2013 09:08:49 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AD9FB2DB0E4 for ; Tue, 29 Jan 2013 09:08:49 +0100 (CET) Received: (qmail 3976 invoked from network); 29 Jan 2013 08:08:48 -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 ; 29 Jan 2013 08:08:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Tue, 29 Jan 2013 09:08:47 +0100 From: Stefan Santesson To: Jim Schaad , 'Russ Housley' Message-ID: Thread-Topic: [pkix] ASN.1 expression of extensions with absent extension value In-Reply-To: <004501cdfd85$d28e47f0$77aad7d0$@augustcellars.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442295330_37321066" Cc: 'IETF PKIX' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value 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, 29 Jan 2013 08:08:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3442295330_37321066 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On a very minor side note. I have a JavaScript based DER decoder on my website: http://aaa-sec.com/other/jsasn1/index.html I can upload binary DER, paste hex dumps or paste Base64 coded certs to examine content. I pasted the Nocheck hex dump with NULL value (300F06092B060105050730010504020500) and that decodes just fine. Then I pasted the Nocheck example with absent value (300D06092B06010505073001050400) and that crashes. Not that this need to say much but=8A /Stefan From: Jim Schaad Date: Monday, January 28, 2013 7:32 PM To: Russ Housley Cc: 'IETF PKIX' Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value > If memory serves, for those things which it understands it decodes conten= t. > For everthing else it just does a hex dump of the contents and would hand= le an > empty octet string just fine. > =20 > jim > =20 >=20 > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, January 28, 2013 9:35 AM > To: Jim Schaad > Cc: IETF PKIX > Subject: Re: [pkix] ASN.1 expression of extensions with absent extension = value > =20 > Jim: >=20 > =20 >=20 > Peter's ASN.1 dumper is one example. What about Microsoft's certificate > viewer? >=20 > =20 >=20 > Russ >=20 > =20 >=20 > =20 >=20 > On Jan 27, 2013, at 9:47 PM, Jim Schaad wrote: >=20 >=20 > Michael, >=20 > =20 >=20 > It is perfectly legal for it to not have a value even with the newer synt= ax. > That is both absent and not absent are legal to put here. There is not > current syntax to say that the internal value is optional. But if there = is no > type associated with the OID then the correct answer is that the ASN.1 fo= r it > would be an empty string. >=20 > =20 >=20 > Russ, >=20 > =20 >=20 > It would not surprise me if something that was just randomly decoding wou= ld > have problems in this case. However, if the decoding is not directed by = the > OID then there is a problem because it will not know how to treat all of = the > ASN.1 it might encode. For example while it could decode the basic piece= s of > an implicitly tagged value, it would have no idea what any of it meant. = I > don=B9t think I would overly worry about this case except for things like > Peter=B9s ASN.1 dumpper. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Michael StJohns > Sent: Sunday, January 27, 2013 2:18 PM > To: Russ Housley; IETF PKIX > Subject: Re: [pkix] ASN.1 expression of extensions with absent extension = value >=20 > =20 >=20 > At 01:28 PM 1/27/2013, Russ Housley wrote: >=20 >=20 > From RFC 5280, the extension structure is: >=20 > Extension ::=3D SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > -- contains the DER encoding of an ASN.1 value > -- corresponding to the extension type identified > -- by extnID > } >=20 > We know that some software automatically tries to decode the content of t= he > OCTET STRING. Will this software fail if the OCTET STRIN is zero length? >=20 > Russ >=20 >=20 >=20 > The X.509 standard uses: >=20 >=20 >=20 > Extension ::=3D SEQUENCE { > extnId EXTENSION.&id ({ExtensionSet}), > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) > ENCODED BY der)} >=20 >=20 > Which suggests that you can't just use an empty OCTET STRING since there = is no > "empty" ExtnType. For NULL is a better choice than . >=20 >=20 >=20 >=20 >=20 >=20 > On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote: >=20 >=20 >=20 > I feel uncertain how to nest deal with this comment from Denis. >=20 > I have compared with RFC 5912 and it does only define the extension OID, = but > provides no extension definition. >=20 > This seem to be the model used in several places where an extension with > absent extension value (empty octet string) is used. > Is there any reason to go beyond this and do as Denis suggests. That is, = to > provide an Extension definition with a Syntaxt holding an element with a = NULL > value? >=20 > If this is the case, the same would apply to the new OCSP extension for > extended revoke definition. >=20 > /Stefan >=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 draft 8. Answer to WGLC >=20 >=20 >=20 > 24. On page 17, the text states: > =20 > This SHOULD be a non-critical extension. The value of the extension > SHALL be NULL. > =20 > The ASN.1 syntax is missing. Add: > =20 > NoCheck ::=3D NULL > =20 >=20 > _______________________________________________ > 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 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3442295330_37321066 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
    On a very minor side note.

    I have a JavaScript based DER decoder on my website:=  http://aaa-sec.co= m/other/jsasn1/index.html
    I can upload binary DER, paste hex d= umps or paste Base64 coded certs to examine content.

    I pasted the Nocheck hex dump with NULL value (300F06092B060105050730010504020500) and= that decodes just fine.
    Then I pasted the Nocheck example with ab= sent value (300D060= 92B06010505073001050400) and that crashes.

    N= ot that this need to say much but…

    /Stefan



    = From: Jim Schaad <ietf@au= gustcellars.com>
    Date: Mond= ay, January 28, 2013 7:32 PM
    To: R= uss Housley <housley@vigilsec.com>
    Cc: 'IETF PKIX' <    pkix@ietf.org>
    Subject: Re: [pkix] ASN.1 expression of extensions with absent e= xtension value

    If memory = serves, for those things which it understands it decodes content.  For = everthing else it just does a hex dump of the contents and would handle an e= mpty octet string just fine.

     

    ji= m

     =

    From: Russ Housley [mailto:housley@vigilsec.com]
    Sent: Monda= y, January 28, 2013 9:35 AM
    To: Jim Schaad
    Cc: IETF PKIX=
    Subject: Re: [pkix] ASN.1 expression of extensions with absent ex= tension value

    &nb= sp;

    Jim:

     

    Peter's ASN.1 dumper= is one example.  What about Microsoft's certificate viewer?=

     

    Russ

     <= /o:p>

     

    On Jan 27, 2013, at 9:47 PM, Jim Schaad wrote:



    Michael,

     

    It is perfectly legal for it to not have a value even = with the newer syntax.  That is both absent and not absent are legal to= put here.  There is not current syntax to say that the internal value = is optional.  But if there is no type associated with the OID then the = correct answer is that the ASN.1 for it would be an empty string.

     =

    Russ,

     

    It would not surprise = me if something that was just randomly decoding would have problems in this = case.  However, if the decoding is not directed by the OID then there i= s a problem because it will not know how to treat all of the ASN.1 it might = encode.  For example while it could decode the basic pieces of an impli= citly tagged value, it would have no idea what any of it meant.  I don&= #8217;t think I would overly worry about this case except for things like Pe= ter’s ASN.1 dumpper.

     

    Jim

    <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31= , 73, 125); "> 

     

    From: pkix-bounces@ietf.org=  [mailto:pkix-bounces@ietf.org] On Behalf Of&n= bsp;Michael StJohns
    Sent: Sunday, January 27, 2013 2:18 PM
    To: Russ Housley; IETF PKIX
    Subject:=  Re: [pkix] ASN.1 expres= sion of extensions with absent extension value

     

    At 01:28 PM 1/27/2013, Russ Housley wrote:


    From RFC 5280, the extension structure= is:

       Extension  ::=3D  SEQUENCE  {
     = ;       extnID      O= BJECT IDENTIFIER,
            critical&nbs= p;   BOOLEAN DEFAULT FALSE,
          = ;  extnValue   OCTET STRING
         =             &nbs= p;  -- contains the DER encoding of an ASN.1 value
       = ;            &nb= sp;    -- corresponding to the extension type identified
    &= nbsp;            = ;       -- by extnID
       &nbs= p;    }

    We know that some software automatically tries= to decode the content of the OCTET STRING.  Will this software fail if= the OCTET STRIN is zero length?

    Russ



    The X.509 standard uses:



    Extensio= n ::=3D SEQUENCE {
             extnId = EXTENSION.&id ({ExtensionSet}),
          &= nbsp;  critical BOOLEAN DEFAULT FALSE,
         = ;    extnValue OCTET STRING
         =           (CONTAINING EXTENSION= .&ExtnType({ExtensionSet}{@extnId})
         &nb= sp;          ENCODED BY der)}


    Which suggests t= hat you can't just use an empty OCTET STRING since there is no "empty" ExtnT= ype.  For  NULL is a better choice than <empty>.


    =



    On Jan 27, 20= 13, at 8:13 AM, Stefan Santesson wrote:



    =

    I feel uncertain how to nest deal with this commen= t from Denis.

    I have compared with RFC 5912 and it does only define t= he extension OID, but provides no extension definition.

    This seem to = be the model used in several places where an extension with absent extension= value (empty octet string) is used.
    Is there any reason to go beyond thi= s and do as Denis suggests. That is, to provide an Extension definition with= a Syntaxt holding an element with a NULL value?

    If this is the case,= the same would apply to the new OCSP extension for extended revoke definiti= on.

    /Stefan


    From: Denis Pinkas <denis.pinkas@bull.net >
    Date: Sunday, January 20, 2013 5:12 PM
    To: Stefan S= antesson <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



    24. On page 17, the text states:
    &n= bsp;
       This SHOULD be a non-critical extension. The value o= f the extension
       SHALL be NULL.
     
    The ASN.1 sy= ntax is missing. Add:
     
       NoCheck ::=3D NULL
     = ;

    ________________________= _______________________
    pkix mailing list
    pkix@ietf.org
    https://www.ietf.org/mailman/listinfo/pkix


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

     <= /o:p>

     

    <= /div>
    _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
    --B_3442295330_37321066-- From denis.pinkas@bull.net Tue Jan 29 00:52: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 4BF2921F8833 for ; Tue, 29 Jan 2013 00:52:59 -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 QJancKrsS0me for ; Tue, 29 Jan 2013 00:52:57 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5272821F87FA for ; Tue, 29 Jan 2013 00:52:52 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 65BA41D006; Tue, 29 Jan 2013 09:52:51 +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 2013012909525022-52230 ; Tue, 29 Jan 2013 09:52:50 +0100 Message-ID: <51078DDF.4020700@bull.net> Date: Tue, 29 Jan 2013 09:52:47 +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 29/01/2013 09:52:50, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 29/01/2013 09:52:51, Serialize complete at 29/01/2013 09:52:51 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------040204090804070708050009" Cc: pkix@ietf.org Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11 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, 29 Jan 2013 08:52:59 -0000 This is a multi-part message in MIME format. --------------040204090804070708050009 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, The discussion is now days and nights since we have participants from around the world. I have not yet started to review your answers to my comments, but in the mean time I took a look at the numerous messages that have been exchanged. You said: "My personal preference would be to not define this extension at all", Piyush does not want it either. I don't think it is needed either. Since the revocation date is set to January, 1rst 1970, I can't imagine *today *another real use case where we would have that date. So checking this value is entirely sufficient to know that the certificate serial number has not been used to the knowledge of the CA. So we are at least three persons who believe that we should not define that extension. Now, if some other persons can demonstrate that this extension is really needed, then it is time for them to speak up. Denis > Piyush, > > On 1/28/13 10:09 PM, "Piyush Jain" wrote: > >> Stefan, >> >> Clearly we have disagreement on how this issue is addressed in current >> draft. >> I'm actually surprised at your statement that clients should not >> differentiate between non-issued and revoked certs, given that the draft >> mandates that servers include extended revoked extension if it is >> changing >> the meaning of revoked. If it is so, why bloat the response with this >> extension at all. > As it has been stated here before, and also communicated in the minutes of > the last PKIX meeting in Atlanta, the rationale behind including this > extension is to allow audits. > If something goes wrong and you go through the records, there will be > evidence that the responder that provided a particular response of > interest, supported this functionality. > > No client is required to understand this extension or to do anything with > it to function properly. > My personal preference would be to not define this extension at all, but > having this extension is so far WG rough consensus and hence it is > included in the draft. > Enough people feel strongly about it and it does no damage to have it > there. > > /Stefan > > >> So far, besides you and me, Peter Rybar is the only one who has referred >> to >> this issue in one of his posts, acknowledging that it exists. >> I hope we have opinions of a few others folks before we decide one way or >> other. >> >> -Piyush >> >>> -----Original Message----- >>> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>> Sent: Monday, January 28, 2013 12:25 PM >>> To: Piyush Jain; pkix@ietf.org >>> Subject: Re: [pkix] Responder trust issue for non-issued certificates >>> not >>> addressed in 2560 bis draft 11 >>> >>> >>> >>> On 1/28/13 7:09 PM, "Piyush Jain" wrote: >>> >>>> You said >>>>> "It's quite easy. If they trust the responder, they are supposed to >>>>> trust >>>> the response. >>>>> If they have not established the trust described above, they MUST >>>>> reject >>>> the response. >>>>> This has nothing to do with what responses they get." >>>> I disagree with this statement. The document clearly states that >>>> contents of responses should be looked at before accepting the >>>> response. This includes looking at signature and certid contained in >>>> the response. >>> Of course, I didn't say it because its central and kind of obvious. >>> >>>> Not-issued response is something that is introduced in this draft >>> No, look closer. The draft does NOT define a "not-issued" response. It >> allows >>> the "revoked" response if a certificate serial number has never been >> issued. >>> That is two entirely different things. >>> >>> >>>> and the >>>> current discussion is about how the client establishes trust in such a >>>> response. >>> As it would with any other response. >>> >>>>> If you ask how to deal with the response, then the client will not >>>>> get a >>>> non- issued response. It will get a "revoked" status. >>>>> This indicates that the certificate they asked about should not be >>>> trusted. >>>> >>>> I was under the impression that syntax of 'revoked' is only being used >>>> for backward compatibility. And that revocation date-1970 in >>>> conjunction with revocation status onhold implies that certificate is >> not- >>> issued. >>> >>> No. The meaning is just to allow the server to provide a response that >>> has >>> the likely outcome that the client will not use that cert, if there even >> is such a >>> cert and the request isn't simply an error. >>> >>> >>>> Also the >>>> new extended revoked extension implies that certificate is not-issued. >>>> Are you now arguing that 'revoked' and 'not-issued' should be >>>> semantically equivalent as well? >>> No, the extension signals that the server supports this extended use of >>> revoked. It says nothing about whether it is used for any of the certs >>> in >> a >>> particular response. >>> >>> >>>> Finally, here is a point regarding providing guidance to clients. >>>> Non-issued response is a new state that is being introduced in this >>>> update. >>> This is getting tiresome. No, there is no new state. There is an >>> extended >> use >>> of "revoked". >>> >>>> The only reason revoked is being overloaded is to maintain backward >>>> compatibility with existing clients. However, to assume that future >>>> clients won't try to interpret the meaning of extended revoked >>>> extension is short-sighted. Avoiding guidelines on how clients deal >>>> with it is bound to cause confusion for anyone who uses this RFC to >>>> implement a OCSP client. >>> No, all may experience with PKI development suggests contrary to your >>> prediction. >>> However, if we tried to craft some extensive guidance on how to try to >>> detect and mitigate CA compromise, that will definitely cause confusion >> and >>> make implementers think they have to deal with this. >>> >>> >>>> The fact is that in absence of such guidelines, clients would probably >>>> continue to trust a responder that is issued by a CA which is >>>> compromised (level of compromise is irrelevant here). >>> Which is exactly what we expect them to do. It is not the clients task >>> to >> spot >>> and correct the problem of compromised CAs. >>> That is the task of trust service providers and the controls they put in >> place. >>> >>>> At the minimum, we should clarify >>>> the implications so clients can make informed choices. I repeat that >>>> failing to do so is violation of RFC 2418. >>> No. Security considerations requires you to discuss security issues >> introduced >>> by a protocol. >>> The added mechanism does not introduce any new security vulnerabilities >>> that you have pointed out. >>> To the contrary. >>> >>> /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 --------------040204090804070708050009 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
    Stefan,

    The discussion is now days and nights since we have participants from around the world.
    I have not yet started to review your answers to my comments, but in the mean time I took a look
    at the numerous messages that have been exchanged.

    You said: "My personal preference would be to not define this extension at all",

    Piyush does not want it either.

    I don't think it is needed either.

    Since the revocation date is set to January, 1rst 1970, I can't imagine today another real use case where we would have that date.
    So checking this value is entirely sufficient to know that the certificate serial number has not been used to the knowledge of the CA.

    So we are at least three persons who believe that we should not define that extension.

    Now, if some other persons can demonstrate that this extension is really needed, then it is time for them to speak up.

    Denis


    Piyush,

On 1/28/13 10:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    Stefan,

Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is
changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

    As it has been stated here before, and also communicated in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.

No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.

/Stefan



    So far, besides you and me, Peter Rybar is the only one who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.

-Piyush


    -----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not
addressed in 2560 bis draft 11



On 1/28/13 7:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    You said

    "It's quite easy. If they trust the responder, they are supposed to
trust

    the response.

    If they have not established the trust described above, they MUST
reject

    the response.

    This has nothing to do with what responses they get."

    I disagree with this statement. The document clearly states that
contents of responses should be looked at before accepting the
response. This includes looking at signature and certid contained in
the response.

    Of course, I didn't say it because its central and kind of obvious.


    Not-issued response is something that is introduced in this draft

    No, look closer. The draft does NOT define a "not-issued" response. It

    allows

    the "revoked" response if a certificate serial number has never been

    issued.

    That is two entirely different things.



    and the
current discussion is about how the client establishes trust in such a
response.

    As it would with any other response.


    
            
    
              
    If you ask how to deal with the response, then the client will not
get a

    
            
    
            
    non- issued response. It will get a "revoked" status.

    
            
    
              
    This indicates that the certificate they asked about should not be

    
            
    
            
    trusted.

I was under the impression that syntax of 'revoked' is only being used
for backward compatibility. And that revocation date-1970 in
conjunction with revocation status onhold implies that certificate is

    
          
    
        
    
        
    not-

    
        
    
          
    issued.

No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

    
        
    
        
    is such a

    
        
    
          
    cert and the request isn't simply an error.



    
          
    
            
    Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be
semantically equivalent as well?

    
          
    
          
    No, the extension signals that the server supports this extended use of
revoked. It says nothing about whether it is used for any of the certs
in

    
        
    
        
    a

    
        
    
          
    particular response.



    
          
    
            
    Finally, here is a point regarding providing guidance to clients.
Non-issued response is a new state that is being introduced in this
update.

    
          
    
          
    This is getting tiresome. No, there is no new state. There is an
extended

    
        
    
        
    use

    
        
    
          
    of "revoked".


    
          
    
            
    The only reason revoked is being overloaded is to maintain backward
compatibility with existing clients. However, to assume that future
clients won't try to interpret the meaning of extended revoked
extension is short-sighted. Avoiding guidelines on how clients deal
with it is bound to cause confusion for anyone who uses this RFC  to
implement a OCSP client.

    
          
    
          
    No, all may experience with PKI development suggests contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion

    
        
    
        
    and

    
        
    
          
    make implementers think they have to deal with this.



    
          
    
            
    The fact is that in absence of such guidelines, clients would probably
continue to trust a responder that is issued by a CA which is
compromised (level of compromise is irrelevant here).

    
          
    
          
    Which is exactly what we expect them to do. It is not the clients task
to

    
        
    
        
    spot

    
        
    
          
    and correct the problem of compromised CAs.
That is the task of trust service providers and the controls they put in

    
        
    
        
    place.

    
        
    
          
    

    
          
    
            
    At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

    
          
    
          
    No. Security considerations requires you to discuss security issues

    
        
    
        
    introduced

    
        
    
          
    by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.

/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

    
    
    
    
    
  


--------------040204090804070708050009--


From stefan@aaa-sec.com  Tue Jan 29 01:15: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 64F6921F8824 for ; Tue, 29 Jan 2013 01:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.318
X-Spam-Level: 
X-Spam-Status: No, score=-101.318 tagged_above=-999 required=5 tests=[AWL=-0.466, 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 YdkL5M-8QcGe for ; Tue, 29 Jan 2013 01:14:58 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 996A221F86FA for ; Tue, 29 Jan 2013 01:14:56 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id AB4762DA2CF for ; Tue, 29 Jan 2013 10:14:53 +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 6Ws_E0cLYoS3 for ; Tue, 29 Jan 2013 10:14:50 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 135C928B637 for ; Tue, 29 Jan 2013 10:14:17 +0100 (CET)
Received: (qmail 21971 invoked from network); 29 Jan 2013 09:14:16 -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 ; 29 Jan 2013 09:14:16 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Tue, 29 Jan 2013 10:14:09 +0100
From: Stefan Santesson 
To: Denis Pinkas 
Message-ID: 
Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
In-Reply-To: <51078DDF.4020700@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442299258_37525148"
Cc: pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
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, 29 Jan 2013 09:15:00 -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_3442299258_37525148
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

It's not a matter of what individuals want.

It is about finding to best common ground that everyone can live with.
It was evident form the last PKIX meeting in Atlanta, and from the
discussion on the list that preceded that meeting, that having this
extension was necessary to reach WG consensus on expanding the "revoked"
scope.

This has already been dealt with in the WG process. Those who need to speak
up are those wanting to change the decision and demonstrate why it need to
be removed.

/Stefan

From:  Denis Pinkas 
Date:  Tuesday, January 29, 2013 9:52 AM
To:  Stefan Santesson 
Cc:  
Subject:  Re: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

>     
>  
> Stefan,
>  
>  The discussion is now days and nights since we have participants from around
> the world.
>  I have not yet started to review your answers to my comments, but in the mean
> time I took a look
>  at the numerous messages that have been exchanged.
>  
>  You said: "My personal preference would be to not define this extension at
> all", 
>  
>  Piyush does not want it either.
>  
>  I don't think it is needed either.
>  
>  Since the revocation date is set to January, 1rst 1970, I can't imagine today
> another real use case where we would have that date.
>  So checking this value is entirely sufficient to know that the certificate
> serial number has not been used to the knowledge of the CA.
>  
>  So we are at least three persons who believe that we should not define that
> extension.
>  
>  Now, if some other persons can demonstrate that this extension is really
> needed, then it is time for them to speak up.
>  
>  Denis
>  
>  
>  
>  
>>  
>> Piyush,
>> 
>> On 1/28/13 10:09 PM, "Piyush Jain" 
>>   wrote:
>> 
>>  
>>>  
>>> Stefan,
>>> 
>>> Clearly we have disagreement on how this issue is addressed in current
>>> draft.  
>>> I'm actually surprised at your statement that clients should not
>>> differentiate between non-issued and revoked certs, given that the draft
>>> mandates that servers include extended revoked extension if it  is
>>> changing
>>> the meaning of revoked. If it is so, why bloat the response with this
>>> extension at all.
>>>  
>>  
>> As it has been stated here before, and also communicated in the minutes of
>> the last PKIX meeting in Atlanta, the rationale behind including this
>> extension is to allow audits.
>> If something goes wrong and you go through the records, there will be
>> evidence that the responder that provided a particular response of
>> interest, supported this functionality.
>> 
>> No client is required to understand this extension or to do anything with
>> it to function properly.
>> My personal preference would be to not define this extension at all, but
>> having this extension is so far WG rough consensus and hence it is
>> included in the draft.
>> Enough people feel strongly about it and it does no damage to have it
>> there.
>> 
>> /Stefan
>> 
>> 
>>  
>>>  
>>> So far, besides you and me, Peter Rybar is the only one who has referred
>>> to
>>> this issue in one of his posts, acknowledging that it exists.
>>> I hope we have opinions of a few others folks before we decide one way or
>>> other.
>>> 
>>> -Piyush
>>> 
>>>  
>>>>  
>>>> -----Original Message-----
>>>> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>>>> Sent: Monday, January 28, 2013 12:25 PM
>>>> To: Piyush Jain; pkix@ietf.org
>>>> Subject: Re: [pkix] Responder trust issue for non-issued certificates
>>>> not
>>>> addressed in 2560 bis draft 11
>>>> 
>>>> 
>>>> 
>>>> On 1/28/13 7:09 PM, "Piyush Jain" 
>>>>   wrote:
>>>> 
>>>>  
>>>>>  
>>>>> You said
>>>>>  
>>>>>>  
>>>>>> "It's quite easy. If they trust the responder, they are supposed to
>>>>>> trust
>>>>>>  
>>>>>  
>>>>> the response.
>>>>>  
>>>>>>  
>>>>>> If they have not established the trust described above, they MUST
>>>>>> reject
>>>>>>  
>>>>>  
>>>>> the response.
>>>>>  
>>>>>>  
>>>>>> This has nothing to do with what responses they get."
>>>>>>  
>>>>>  
>>>>> I disagree with this statement. The document clearly states that
>>>>> contents of responses should be looked at before accepting the
>>>>> response. This includes looking at signature and certid contained in
>>>>> the response.
>>>>>  
>>>>  
>>>> Of course, I didn't say it because its central and kind of obvious.
>>>> 
>>>>  
>>>>>  
>>>>> Not-issued response is something that is introduced in this draft
>>>>>  
>>>>  
>>>> No, look closer. The draft does NOT define a "not-issued" response. It
>>>>  
>>>  
>>> allows
>>>  
>>>>  
>>>> the "revoked" response if a certificate serial number has never been
>>>>  
>>>  
>>> issued.
>>>  
>>>>  
>>>> That is two entirely different things.
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>> and the
>>>>> current discussion is about how the client establishes trust in such a
>>>>> response.
>>>>>  
>>>>  
>>>> As it would with any other response.
>>>> 
>>>>  
>>>>>  
>>>>>  
>>>>>>  
>>>>>> If you ask how to deal with the response, then the client will not
>>>>>> get a
>>>>>>  
>>>>>  
>>>>> non- issued response. It will get a "revoked" status.
>>>>>  
>>>>>>  
>>>>>> This indicates that the certificate they asked about should not be
>>>>>>  
>>>>>  
>>>>> trusted.
>>>>> 
>>>>> I was under the impression that syntax of 'revoked' is only being used
>>>>> for backward compatibility. And that revocation date-1970 in
>>>>> conjunction with revocation status onhold implies that certificate is
>>>>>  
>>>>  
>>>  
>>> not-
>>>  
>>>>  
>>>> issued.
>>>> 
>>>> No. The meaning is just to allow the server to provide a response that
>>>> has
>>>> the likely outcome that the client will not use that cert, if there even
>>>>  
>>>  
>>> is such a
>>>  
>>>>  
>>>> cert and the request isn't simply an error.
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>> Also the
>>>>> new extended revoked extension implies that certificate is not-issued.
>>>>> Are you now arguing that 'revoked' and 'not-issued' should be
>>>>> semantically equivalent as well?
>>>>>  
>>>>  
>>>> No, the extension signals that the server supports this extended use of
>>>> revoked. It says nothing about whether it is used for any of the certs
>>>> in
>>>>  
>>>  
>>> a
>>>  
>>>>  
>>>> particular response.
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>> Finally, here is a point regarding providing guidance to clients.
>>>>> Non-issued response is a new state that is being introduced in this
>>>>> update.
>>>>>  
>>>>  
>>>> This is getting tiresome. No, there is no new state. There is an
>>>> extended
>>>>  
>>>  
>>> use
>>>  
>>>>  
>>>> of "revoked".
>>>> 
>>>>  
>>>>>  
>>>>> The only reason revoked is being overloaded is to maintain backward
>>>>> compatibility with existing clients. However, to assume that future
>>>>> clients won't try to interpret the meaning of extended revoked
>>>>> extension is short-sighted. Avoiding guidelines on how clients deal
>>>>> with it is bound to cause confusion for anyone who uses this RFC  to
>>>>> implement a OCSP client.
>>>>>  
>>>>  
>>>> No, all may experience with PKI development suggests contrary to your
>>>> prediction.
>>>> However, if we tried to craft some extensive guidance on how to try to
>>>> detect and mitigate CA compromise, that will definitely cause confusion
>>>>  
>>>  
>>> and
>>>  
>>>>  
>>>> make implementers think they have to deal with this.
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>> The fact is that in absence of such guidelines, clients would probably
>>>>> continue to trust a responder that is issued by a CA which is
>>>>> compromised (level of compromise is irrelevant here).
>>>>>  
>>>>  
>>>> Which is exactly what we expect them to do. It is not the clients task
>>>> to
>>>>  
>>>  
>>> spot
>>>  
>>>>  
>>>> and correct the problem of compromised CAs.
>>>> That is the task of trust service providers and the controls they put in
>>>>  
>>>  
>>> place.
>>>  
>>>>  
>>>>  
>>>>>  
>>>>> At the minimum, we should clarify
>>>>> the implications so clients can make informed choices.  I repeat that
>>>>> failing to do so is violation of RFC 2418.
>>>>>  
>>>>  
>>>> No. Security considerations requires you to discuss security issues
>>>>  
>>>  
>>> introduced
>>>  
>>>>  
>>>> by a protocol.
>>>> The added mechanism does not introduce any new security vulnerabilities
>>>> that you have pointed out.
>>>> To the contrary.
>>>> 
>>>> /Stefan
>>>> 
>>>>  
>>>  
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>  
>>  
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>  
>  
>  
> _______________________________________________ pkix mailing list
> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix



--B_3442299258_37525148
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


    It's not a matter of what in=
dividuals want.

    It is about finding to best common =
ground that everyone can live with.
    It was evident form the last P=
KIX meeting in Atlanta, and from the discussion on the list that preceded th=
at meeting, that having this extension was necessary to reach WG consensus o=
n expanding the "revoked" scope.

    This has already b=
een dealt with in the WG process. Those who need to speak up are those wanti=
ng to change the decision and demonstrate why it need to be removed.

    /Stefan

    Fr=
om:  Denis Pinkas <denis.pi=
nkas@bull.net>
    Date:  Tuesda=
y, January 29, 2013 9:52 AM
    To:  St=
efan Santesson <stefan@aaa-sec.com>
    Cc:  <    pkix@ietf.org>
    Subject: =
 Re: [pkix] Responder trust issue for non-issued certificates not add=
ressed in 2560 bis draft 11

    
  
    
  
  
    
    
    Stefan,
    
      
    
      The discussion is now days and nights since we have participants
      from around the world.
    
      I have not yet started to review your answers to my comments, but
      in the mean time I took a look 
    
      at the numerous messages that have been exchanged.
    
      
    
      You said: "My personal preference would be to not define this
      extension at all",
      
    
      
    
      Piyush does not want it either.
    
      
    
      I don't think it is needed either.
    
      
    
      Since the revocation date is set to January, 1rst 1970, I can't
      imagine today another real use case where we would have
      that date.
    
      So checking this value is entirely sufficient to know that the
      certificate serial number has not been used to the knowledge of
      the CA.
    
      
    
      So we are at least three persons who believe that we should not
      define that extension.
    
      
    
      Now, if some other persons can demonstrate that this extension is
      really needed, then it is time for them to speak up.
    
      
    
      Denis
    
      
    
      
    
    
    
    
    =

      
    Piyush,

On 1/28/13 10:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    
      
    
        
    Stefan,

Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is
changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

    
      
    
      
    As it has been stated here before, and also communicated=
 in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.

No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.

/Stefan



    
      
    
        
    So far, besides you and me, Peter Rybar is the only on=
e who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.

-Piyush


    
        
    
          
    -----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not
addressed in 2560 bis draft 11



On 1/28/13 7:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    
          
    
            
    You said

    
            
    
              
    "It's quite easy. If they trust the responder, t=
hey are supposed to
trust

    
            
    
            
    the response.

    
            
    
              
    If they have not established the trust described=
 above, they MUST
reject

    
            
    
            
    the response.

    
            
    
              
    This has nothing to do with what responses they =
get."

    
            
    
            
    I disagree with this statement. The document clear=
ly states that
contents of responses should be looked at before accepting the
response. This includes looking at signature and certid contained in
the response.

    
          
    
          
    Of course, I didn't say it because its central and k=
ind of obvious.


    
          
    
            
    Not-issued response is something that is introduce=
d in this draft

    
          
    
          
    No, look closer. The draft does NOT define a "not-is=
sued" response. It

    
        
    
        
    allows

    
        
    
          
    the "revoked" response if a certificate serial numbe=
r has never been

    
        
    
        
    issued.

    
        
    
          
    That is two entirely different things.



    
          
    
            
    and the
current discussion is about how the client establishes trust in such a
response.

    
          
    
          
    As it would with any other response.


    
          
    
            
    
            
    
              
    If you ask how to deal with the response, then t=
he client will not
get a

    
            
    
            
    non- issued response. It will get a "revoked" stat=
us.

    
            
    
              
    This indicates that the certificate they asked a=
bout should not be

    
            
    
            
    trusted.

I was under the impression that syntax of 'revoked' is only being used
for backward compatibility. And that revocation date-1970 in
conjunction with revocation status onhold implies that certificate is

    
          
    
        
    
        
    not-

    
        
    
          
    issued.

No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

    
        
    
        
    is such a

    
        
    
          
    cert and the request isn't simply an error.



    
          
    
            
    Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be
semantically equivalent as well?

    
          
    
          
    No, the extension signals that the server supports t=
his extended use of
revoked. It says nothing about whether it is used for any of the certs
in

    
        
    
        
    a

    
        
    
          
    particular response.



    
          
    
            
    Finally, here is a point regarding providing guida=
nce to clients.
Non-issued response is a new state that is being introduced in this
update.

    
          
    
          
    This is getting tiresome. No, there is no new state.=
 There is an
extended

    
        
    
        
    use

    
        
    
          
    of "revoked".


    
          
    
            
    The only reason revoked is being overloaded is to =
maintain backward
compatibility with existing clients. However, to assume that future
clients won't try to interpret the meaning of extended revoked
extension is short-sighted. Avoiding guidelines on how clients deal
with it is bound to cause confusion for anyone who uses this RFC  to
implement a OCSP client.

    
          
    
          
    No, all may experience with PKI development suggests=
 contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion

    
        
    
        
    and

    
        
    
          
    make implementers think they have to deal with this.=




    
          
    
            
    The fact is that in absence of such guidelines, cl=
ients would probably
continue to trust a responder that is issued by a CA which is
compromised (level of compromise is irrelevant here).

    
          
    
          
    Which is exactly what we expect them to do. It is no=
t the clients task
to

    
        
    
        
    spot

    
        
    
          
    and correct the problem of compromised CAs.
That is the task of trust service providers and the controls they put in

    
        
    
        
    place.

    
        
    
          
    
          
    
            
    At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

    
          
    
          
    No. Security considerations requires you to discuss =
security issues

    
        
    
        
    introduced

    
        
    
          
    by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.

/Stefan


    
        
    
        
    _______________________________________________
pkix mailing list
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix
    
      
    
      
    _______________________________________________
pkix mailing list
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix
    
    
    
    
    
  
    
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pkix

    

--B_3442299258_37525148--



From denis.pinkas@bull.net  Tue Jan 29 01:33: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 0675D21F8722 for ; Tue, 29 Jan 2013 01:33:40 -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 eTD-93ZbC9J5 for ; Tue, 29 Jan 2013 01:33:38 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id EC02821F8721 for ; Tue, 29 Jan 2013 01:33:37 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 584441D015; Tue, 29 Jan 2013 10:33:37 +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 2013012910333621-52397 ; Tue, 29 Jan 2013 10:33:36 +0100 
Message-ID: <5107976C.2060706@bull.net>
Date: Tue, 29 Jan 2013 10:33:32 +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 29/01/2013 10:33:36, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 29/01/2013 10:33:37, Serialize complete at 29/01/2013 10:33:37
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="------------070205080408000308080102"
Cc: pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
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, 29 Jan 2013 09:33:40 -0000

This is a multi-part message in MIME format.
--------------070205080408000308080102
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Stefan,

Since you say that from the last PKIX meeting in Atlanta, and from the 
discussion on the list that preceded that meeting,
it is *evident* that this extension is needed, would be please recall 
shortly why ?

In addition, would you be able to provide a counter argument to my 
argumentation below ?

Then we should also other people that are not on the same time zone to 
speak up.

Denis


> It's not a matter of what individuals want.
>
> It is about finding to best common ground that everyone can live with.
> It was evident form the last PKIX meeting in Atlanta, and from the 
> discussion on the list that preceded that meeting, that having this 
> extension was necessary to reach WG consensus on expanding the 
> "revoked" scope.
>
> This has already been dealt with in the WG process. Those who need to 
> speak up are those wanting to change the decision and demonstrate why 
> it need to be removed.
>
> /Stefan
>
> From: Denis Pinkas >
> Date: Tuesday, January 29, 2013 9:52 AM
> To: Stefan Santesson >
> Cc: >
> Subject: Re: [pkix] Responder trust issue for non-issued certificates 
> not addressed in 2560 bis draft 11
>
>     Stefan,
>
>     The discussion is now days and nights since we have participants
>     from around the world.
>     I have not yet started to review your answers to my comments, but
>     in the mean time I took a look
>     at the numerous messages that have been exchanged.
>
>     You said: "My personal preference would be to not define this
>     extension at all",
>
>     Piyush does not want it either.
>
>     I don't think it is needed either.
>
>     Since the revocation date is set to January, 1rst 1970, I can't
>     imagine *today *another real use case where we would have that date.
>     So checking this value is entirely sufficient to know that the
>     certificate serial number has not been used to the knowledge of
>     the CA.
>
>     So we are at least three persons who believe that we should not
>     define that extension.
>
>     Now, if some other persons can demonstrate that this extension is
>     really needed, then it is time for them to speak up.
>
>     Denis
>
>
>>     Piyush,
>>
>>     On 1/28/13 10:09 PM, "Piyush Jain"  wrote:
>>
>>>     Stefan,
>>>
>>>     Clearly we have disagreement on how this issue is addressed in current
>>>     draft.
>>>     I'm actually surprised at your statement that clients should not
>>>     differentiate between non-issued and revoked certs, given that the draft
>>>     mandates that servers include extended revoked extension if it  is
>>>     changing
>>>     the meaning of revoked. If it is so, why bloat the response with this
>>>     extension at all.
>>     As it has been stated here before, and also communicated in the minutes of
>>     the last PKIX meeting in Atlanta, the rationale behind including this
>>     extension is to allow audits.
>>     If something goes wrong and you go through the records, there will be
>>     evidence that the responder that provided a particular response of
>>     interest, supported this functionality.
>>
>>     No client is required to understand this extension or to do anything with
>>     it to function properly.
>>     My personal preference would be to not define this extension at all, but
>>     having this extension is so far WG rough consensus and hence it is
>>     included in the draft.
>>     Enough people feel strongly about it and it does no damage to have it
>>     there.
>>
>>     /Stefan
>>
>>
>>>     So far, besides you and me, Peter Rybar is the only one who has referred
>>>     to
>>>     this issue in one of his posts, acknowledging that it exists.
>>>     I hope we have opinions of a few others folks before we decide one way or
>>>     other.
>>>
>>>     -Piyush
>>>
>>>>     -----Original Message-----
>>>>     From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>>>>     Sent: Monday, January 28, 2013 12:25 PM
>>>>     To: Piyush Jain;pkix@ietf.org
>>>>     Subject: Re: [pkix] Responder trust issue for non-issued certificates
>>>>     not
>>>>     addressed in 2560 bis draft 11
>>>>
>>>>
>>>>
>>>>     On 1/28/13 7:09 PM, "Piyush Jain"  wrote:
>>>>
>>>>>     You said
>>>>>>     "It's quite easy. If they trust the responder, they are supposed to
>>>>>>     trust
>>>>>     the response.
>>>>>>     If they have not established the trust described above, they MUST
>>>>>>     reject
>>>>>     the response.
>>>>>>     This has nothing to do with what responses they get."
>>>>>     I disagree with this statement. The document clearly states that
>>>>>     contents of responses should be looked at before accepting the
>>>>>     response. This includes looking at signature and certid contained in
>>>>>     the response.
>>>>     Of course, I didn't say it because its central and kind of obvious.
>>>>
>>>>>     Not-issued response is something that is introduced in this draft
>>>>     No, look closer. The draft does NOT define a "not-issued" response. It
>>>     allows
>>>>     the "revoked" response if a certificate serial number has never been
>>>     issued.
>>>>     That is two entirely different things.
>>>>
>>>>
>>>>>     and the
>>>>>     current discussion is about how the client establishes trust in such a
>>>>>     response.
>>>>     As it would with any other response.
>>>>
>>>>>>     If you ask how to deal with the response, then the client will not
>>>>>>     get a
>>>>>     non- issued response. It will get a "revoked" status.
>>>>>>     This indicates that the certificate they asked about should not be
>>>>>     trusted.
>>>>>
>>>>>     I was under the impression that syntax of 'revoked' is only being used
>>>>>     for backward compatibility. And that revocation date-1970 in
>>>>>     conjunction with revocation status onhold implies that certificate is
>>>     not-
>>>>     issued.
>>>>
>>>>     No. The meaning is just to allow the server to provide a response that
>>>>     has
>>>>     the likely outcome that the client will not use that cert, if there even
>>>     is such a
>>>>     cert and the request isn't simply an error.
>>>>
>>>>
>>>>>     Also the
>>>>>     new extended revoked extension implies that certificate is not-issued.
>>>>>     Are you now arguing that 'revoked' and 'not-issued' should be
>>>>>     semantically equivalent as well?
>>>>     No, the extension signals that the server supports this extended use of
>>>>     revoked. It says nothing about whether it is used for any of the certs
>>>>     in
>>>     a
>>>>     particular response.
>>>>
>>>>
>>>>>     Finally, here is a point regarding providing guidance to clients.
>>>>>     Non-issued response is a new state that is being introduced in this
>>>>>     update.
>>>>     This is getting tiresome. No, there is no new state. There is an
>>>>     extended
>>>     use
>>>>     of "revoked".
>>>>
>>>>>     The only reason revoked is being overloaded is to maintain backward
>>>>>     compatibility with existing clients. However, to assume that future
>>>>>     clients won't try to interpret the meaning of extended revoked
>>>>>     extension is short-sighted. Avoiding guidelines on how clients deal
>>>>>     with it is bound to cause confusion for anyone who uses this RFC  to
>>>>>     implement a OCSP client.
>>>>     No, all may experience with PKI development suggests contrary to your
>>>>     prediction.
>>>>     However, if we tried to craft some extensive guidance on how to try to
>>>>     detect and mitigate CA compromise, that will definitely cause confusion
>>>     and
>>>>     make implementers think they have to deal with this.
>>>>
>>>>
>>>>>     The fact is that in absence of such guidelines, clients would probably
>>>>>     continue to trust a responder that is issued by a CA which is
>>>>>     compromised (level of compromise is irrelevant here).
>>>>     Which is exactly what we expect them to do. It is not the clients task
>>>>     to
>>>     spot
>>>>     and correct the problem of compromised CAs.
>>>>     That is the task of trust service providers and the controls they put in
>>>     place.
>>>>>     At the minimum, we should clarify
>>>>>     the implications so clients can make informed choices.  I repeat that
>>>>>     failing to do so is violation of RFC 2418.
>>>>     No. Security considerations requires you to discuss security issues
>>>     introduced
>>>>     by a protocol.
>>>>     The added mechanism does not introduce any new security vulnerabilities
>>>>     that you have pointed out.
>>>>     To the contrary.
>>>>
>>>>     /Stefan
>>>>
>>>     _______________________________________________
>>>     pkix mailing list
>>>     pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>     _______________________________________________
>>     pkix mailing list
>>     pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>
>     _______________________________________________ pkix mailing list
>     pkix@ietf.org 
>     https://www.ietf.org/mailman/listinfo/pkix 
>


--------------070205080408000308080102
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=ISO-8859-1


  
    
  
  
    
    Stefan,
    
      
    
      Since you say that from the last PKIX meeting in Atlanta, and from
      the discussion on the list that preceded that meeting, 
    
      it is evident that this extension is needed, would be
      please recall shortly why ?
    
      
    
      In addition, would you be able to provide a counter argument to my
      argumentation below ?
    
      
    
      Then we should also other people that are not on the same time
      zone to speak up.
    
       
    
      Denis
    
      
    
      
    
    
    
    
    
      
    It's not a matter of what individuals want.
    
      

    
      
    
      
    It is about finding to best common ground that everyone can
        live with.
    
      
    It was evident form the last PKIX meeting in Atlanta, and
        from the discussion on the list that preceded that meeting, that
        having this extension was necessary to reach WG consensus on
        expanding the "revoked" scope.
    
      

    
      
    
      
    This has already been dealt with in the WG process. Those who
        need to speak up are those wanting to change the decision and
        demonstrate why it need to be removed.
    
      

    
      
    
      
    /Stefan
    
      

    
      
    
      
        
    From:  Denis Pinkas <denis.pinkas@bull.net>
    
          Date:  Tuesday, January
          29, 2013 9:52 AM
    
          To:  Stefan Santesson
          <stefan@aaa-sec.com>
    
          Cc:  <pkix@ietf.org>
    
          Subject:  Re: [pkix]
          Responder trust issue for non-issued certificates not
          addressed in 2560 bis draft 11
    
        
    
        

    
        
    
        
    
          
    
            
            
    
              
    Stefan,
    
                
    
                The discussion is now days and nights since we have
                participants from around the world.
    
                I have not yet started to review your answers to my
                comments, but in the mean time I took a look 
    
                at the numerous messages that have been exchanged.
    
                
    
                You said: "My personal preference would be to not define
                this extension at all", 
    
                
    
                Piyush does not want it either.
    
                
    
                I don't think it is needed either.
    
                
    
                Since the revocation date is set to January, 1rst 1970,
                I can't imagine today another real use case
                where we would have that date.
    
                So checking this value is entirely sufficient to know
                that the certificate serial number has not been used to
                the knowledge of the CA.
    
                
    
                So we are at least three persons who believe that we
                should not define that extension.
    
                
    
                Now, if some other persons can demonstrate that this
                extension is really needed, then it is time for them to
                speak up.
    
                
    
                Denis
    
                
    
                
    
              
    
              
    
                
    Piyush,

On 1/28/13 10:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    
                
    
                  
    Stefan,

Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is
changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

    
                
    
                
    As it has been stated here before, and also communicated in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.

No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.

/Stefan



    
                
    
                  
    So far, besides you and me, Peter Rybar is the only one who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.

-Piyush


    
                  
    
                    
    -----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not
addressed in 2560 bis draft 11



On 1/28/13 7:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:


    
                    
    
                      
    You said

    
                      
    
                        
    "It's quite easy. If they trust the responder, they are supposed to
trust

    
                      
    
                      
    the response.

    
                      
    
                        
    If they have not established the trust described above, they MUST
reject

    
                      
    
                      
    the response.

    
                      
    
                        
    This has nothing to do with what responses they get."

    
                      
    
                      
    I disagree with this statement. The document clearly states that
contents of responses should be looked at before accepting the
response. This includes looking at signature and certid contained in
the response.

    
                    
    
                    
    Of course, I didn't say it because its central and kind of obvious.


    
                    
    
                      
    Not-issued response is something that is introduced in this draft

    
                    
    
                    
    No, look closer. The draft does NOT define a "not-issued" response. It

    
                  
    
                  
    allows

    
                  
    
                    
    the "revoked" response if a certificate serial number has never been

    
                  
    
                  
    issued.

    
                  
    
                    
    That is two entirely different things.



    
                    
    
                      
    and the
current discussion is about how the client establishes trust in such a
response.

    
                    
    
                    
    As it would with any other response.


    
                    
    
                      
    
                        
    If you ask how to deal with the response, then the client will not
get a

    
                      
    
                      
    non- issued response. It will get a "revoked" status.

    
                      
    
                        
    This indicates that the certificate they asked about should not be

    
                      
    
                      
    trusted.

I was under the impression that syntax of 'revoked' is only being used
for backward compatibility. And that revocation date-1970 in
conjunction with revocation status onhold implies that certificate is

    
                    
    
                  
    
                  
    not-

    
                  
    
                    
    issued.

No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

    
                  
    
                  
    is such a

    
                  
    
                    
    cert and the request isn't simply an error.



    
                    
    
                      
    Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be
semantically equivalent as well?

    
                    
    
                    
    No, the extension signals that the server supports this extended use of
revoked. It says nothing about whether it is used for any of the certs
in

    
                  
    
                  
    a

    
                  
    
                    
    particular response.



    
                    
    
                      
    Finally, here is a point regarding providing guidance to clients.
Non-issued response is a new state that is being introduced in this
update.

    
                    
    
                    
    This is getting tiresome. No, there is no new state. There is an
extended

    
                  
    
                  
    use

    
                  
    
                    
    of "revoked".


    
                    
    
                      
    The only reason revoked is being overloaded is to maintain backward
compatibility with existing clients. However, to assume that future
clients won't try to interpret the meaning of extended revoked
extension is short-sighted. Avoiding guidelines on how clients deal
with it is bound to cause confusion for anyone who uses this RFC  to
implement a OCSP client.

    
                    
    
                    
    No, all may experience with PKI development suggests contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion

    
                  
    
                  
    and

    
                  
    
                    
    make implementers think they have to deal with this.



    
                    
    
                      
    The fact is that in absence of such guidelines, clients would probably
continue to trust a responder that is issued by a CA which is
compromised (level of compromise is irrelevant here).

    
                    
    
                    
    Which is exactly what we expect them to do. It is not the clients task
to

    
                  
    
                  
    spot

    
                  
    
                    
    and correct the problem of compromised CAs.
That is the task of trust service providers and the controls they put in

    
                  
    
                  
    place.

    
                  
    
                    
    
                      
    At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

    
                    
    
                    
    No. Security considerations requires you to discuss security issues

    
                  
    
                  
    introduced

    
                  
    
                    
    by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.

/Stefan


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


--------------070205080408000308080102--


From internet-drafts@ietf.org  Tue Jan 29 01:34: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 C115221F871E; Tue, 29 Jan 2013 01:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 i5MWNxRWHH-R; Tue, 29 Jan 2013 01:34:40 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED7621F8740; Tue, 29 Jan 2013 01:34:20 -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: <20130129093420.11826.75777.idtracker@ietfa.amsl.com>
Date: Tue, 29 Jan 2013 01:34:20 -0800
Cc: pkix@ietf.org
Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-12.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jan 2013 09:34:42 -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           : X.509 Internet Public Key Infrastructure Online Certific=
ate Status Protocol - OCSP
	Author(s)       : Stefan Santesson
                          Michael Myers
                          Rich Ankney
                          Ambarish Malpani
                          Slava Galperin
                          Carlisle Adams
	Filename        : draft-ietf-pkix-rfc2560bis-12.txt
	Pages           : 43
	Date            : 2013-01-29

Abstract:
   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.


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

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

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


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


From era@x500.eu  Tue Jan 29 01:35: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 EC18B21F881E for ; Tue, 29 Jan 2013 01:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level: 
X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009]
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 TUxtc3XGahi4 for ; Tue, 29 Jan 2013 01:35:48 -0800 (PST)
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1163421F8721 for ; Tue, 29 Jan 2013 01:35:47 -0800 (PST)
Received: from ([62.44.135.92]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id OKM65944 for ; Tue, 29 Jan 2013 10:35:44 +0100
From: "Erik Andersen" 
To: "'pkix'" 
References: 	 <255B9BB34FB7D647A506DC292726F6E115060D425D@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115060D425D@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 29 Jan 2013 10:35:40 +0100
Message-ID: <004901cdfe04$02adc7c0$08095740$@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: Ac39k3zZinx6SsKlRhSrvkyr+lSZcwAFUAagABandOA=
Content-Language: da
Subject: Re: [pkix] [Spam] Re: ASN.1 expression of extensions with absent extension	value
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, 29 Jan 2013 09:35:49 -0000

I agree with James. This correct ASN.1 and will complete the ASN.1 =
module.
It will also be consistent with other specifications, e.g. X.509.

Erik Andersen=20

-----Oprindelig meddelelse-----
Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af
Manger, James H
Sendt: 28. januar 2013 23:52
Til: Stefan Santesson; Jim Schaad; 'pkix'
Emne: [Spam] Re: [pkix] ASN.1 expression of extensions with absent =
extension
value

> >RFC 2560bis currently has no 2002 syntax as it just refers to 5912.
> >
> >I realise that we need this not only for the nocheck extension, but=20
> >also for the new extended-revoke extension, which is an OCSP=20
> >extension
> BTW.
> >
> >I would hate for the RFC2560bis to have to wait for an update of =
5912.
> >Should I just import the ASN.1 from 5912 into RFC 2560 bis, get a new =

> >module OID and then add the extension definitions to this new module?
> >
> >I would then:
> >- Add that rfc2560bis updates 5912
> >- Add:
> >ext-ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL IDENTIFIED BY=20
> >id-pkix-ocsp-nocheck }
> >
> >- Add:
> >re-ocsp-extended-revoke EXTENSION ::=3D { SYNTAX NULL IDENTIFIED BY=20
> >id-pkix-ocsp-extended-revoke }
> >
> >
> >
> >Is that a reasonable course of action?
> >
> >/Stefan

> Before we drift too far away from the core issue, Is there an opinion=20
> about whether what I propose here would be the right way to go?
> /Stefan


Yes, adding "ext-ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL IDENTIFIED =
BY
id-pkix-ocsp-nocheck }" is the right way to go.

P.S. We had this discussion on this list 7 months ago. See thread titled
"id-pkix-ocsp-nocheck extension: NULL vs empty": starting at
http://www.ietf.org/mail-archive/web/pkix/current/msg31222.html, =
concluding
http://www.ietf.org/mail-archive/web/pkix/current/msg31226.html.

--
James Manger

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


From stefan@aaa-sec.com  Tue Jan 29 01:43: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 A34F121F8860 for ; Tue, 29 Jan 2013 01:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.201
X-Spam-Level: 
X-Spam-Status: No, score=-101.201 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 bQGvZ6FvVx2W for ; Tue, 29 Jan 2013 01:43:19 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A7C7121F8B8B for ; Tue, 29 Jan 2013 01:43:14 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 1A6ED12CC77 for ; Tue, 29 Jan 2013 10:43: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 4DFmUFxaF7sF for ; Tue, 29 Jan 2013 10:43:12 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A407915FD6A for ; Tue, 29 Jan 2013 10:43:12 +0100 (CET)
Received: (qmail 63404 invoked from network); 29 Jan 2013 09:43:12 -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 ; 29 Jan 2013 09:43:12 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Tue, 29 Jan 2013 10:43:12 +0100
From: Stefan Santesson 
To: 
Message-ID: 
Thread-Topic: 2560bis draft 12 posted
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442300994_37628400"
Subject: [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, 29 Jan 2013 09:43:20 -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_3442300994_37628400
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Draft 12 is posted.

This update includes:
- The ASN.1 is consolidated and now contains just one 88 syntax section and
one 2002 syntax section. The OCSP module from 5912 has been imported and
updated.
- The ASN.1 update includes extension definitions for the no check extension
as well as the new extended revoke extension.
- A few minor editorial cleanups
- Added a note in the extended revoke extension section 4.4.8 to clarify
that clients do not have to process this extension in order to determine
status on certificates.

This document now only lacks the new OIDs for the new ASN.1 modules. As soon
as I have them, I will post draft 13.

I know that not everyone is super happy with the result, but on the other
hand, that seldom is the case with updates of this kind.

It is however my view that the document in it's current shape is a
reasonable capture of rough WG consensus, and that it now is ready for
shipping to the IESG.

/Stefan



--B_3442300994_37628400
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


    Draft 12 is posted.

    This update includes:
    - The ASN.1 is consolidated=
 and now contains just one 88 syntax section and one 2002 syntax section. Th=
e OCSP module from 5912 has been imported and updated.
    - The ASN.1=
 update includes extension definitions for the no check extension as well as=
 the new extended revoke extension.
    - A few minor editorial cleanu=
ps
    - Added a note in the extended revoke extension section 4.4.8 t=
o clarify that clients do not have to process this extension in order to det=
ermine status on certificates.

    This document now on=
ly lacks the new OIDs for the new ASN.1 modules. As soon as I have them, I w=
ill post draft 13.

    I know that not everyone is supe=
r happy with the result, but on the other hand, that seldom is the case with=
 updates of this kind.

    It is however my view that t=
he document in it's current shape is a reasonable capture of rough WG consen=
sus, and that it now is ready for shipping to the IESG.

    /Stefa=
n
    

--B_3442300994_37628400--



From stefan@aaa-sec.com  Tue Jan 29 01:54: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 ECC0021F85AD for ; Tue, 29 Jan 2013 01:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.131
X-Spam-Level: 
X-Spam-Status: No, score=-101.131 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 x7yfZdQlc3Xx for ; Tue, 29 Jan 2013 01:54:13 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D321F85A4 for ; Tue, 29 Jan 2013 01:54:12 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 05BBB1E3B931 for ; Tue, 29 Jan 2013 10:54:02 +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 oWqG289fFmmJ for ; Tue, 29 Jan 2013 10:53:59 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E0F2D12C681 for ; Tue, 29 Jan 2013 10:53:59 +0100 (CET)
Received: (qmail 19162 invoked from network); 29 Jan 2013 09:53:59 -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 ; 29 Jan 2013 09:53:59 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Tue, 29 Jan 2013 10:53:59 +0100
From: Stefan Santesson 
To: Denis Pinkas 
Message-ID: 
Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
In-Reply-To: <5107976C.2060706@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442301641_37715866"
Cc: pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
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, 29 Jan 2013 09:54: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_3442301641_37715866
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Denis,

It would be easier if you read the messages on the list.
I answered the same very question on the list less than 24 hours ago.

Your contribution to this process is most welcome, but if you want to be
part of it, then please participate while the issue is discussed and not at
the very last minute months after the issue is decided and closed.

During the straw poll on this list on the way forward regarding this
extended revoked definition, this was discussed and agreed.
The issue was than discussed further at Atlanta and concluded in the
minutes.
http://www.ietf.org/proceedings/85/minutes/minutes-85-pkix

Just because you now raise the issue again, does not mean that the people
who participated while the issue was discussed has to rush to their
keyboards and defending their position.
In general, if you want to change the directions of things we already have
concluded, then you need to gather support for your arguments to change it.

We need to keep the process going.

/Stefan



From:  Denis Pinkas 
Date:  Tuesday, January 29, 2013 10:33 AM
To:  Stefan Santesson 
Cc:  
Subject:  Re: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

>     
>  
> Stefan,
>  
>  Since you say that from the last PKIX meeting in Atlanta, and from the
> discussion on the list that preceded that meeting,
>  it is evident that this extension is needed, would be please recall shortly
> why ?
>  
>  In addition, would you be able to provide a counter argument to my
> argumentation below ?
>  
>  Then we should also other people that are not on the same time zone to speak
> up.
>   
>  Denis
>  
>  
>  
>  
>>  
>> It's not a matter of what individuals want.
>>  
>> 
>>  
>>  
>> It is about finding to best common ground that everyone can live with.
>>  
>> It was evident form the last PKIX meeting in Atlanta, and from the discussion
>> on the list that preceded that meeting, that having this extension was
>> necessary to reach WG consensus on expanding the "revoked" scope.
>>  
>> 
>>  
>>  
>> This has already been dealt with in the WG process. Those who need to speak
>> up are those wanting to change the decision and demonstrate why it need to be
>> removed.
>>  
>> 
>>  
>>  
>> /Stefan
>>  
>> 
>>  
>>   
>> From:  Denis Pinkas 
>>  Date:  Tuesday, January 29, 2013 9:52 AM
>>  To:  Stefan Santesson 
>>  Cc:  
>>  Subject:  Re: [pkix] Responder trust issue for non-issued certificates not
>> addressed in 2560 bis draft 11
>>  
>>  
>> 
>>  
>>  
>>>  
>>>   
>>>  
>>> Stefan,
>>>  
>>>  The discussion is now days and nights since we have participants from
>>> around the world.
>>>  I have not yet started to review your answers to my comments, but in the
>>> mean time I took a look
>>>  at the numerous messages that have been exchanged.
>>>  
>>>  You said: "My personal preference would be to not define this extension at
>>> all", 
>>>  
>>>  Piyush does not want it either.
>>>  
>>>  I don't think it is needed either.
>>>  
>>>  Since the revocation date is set to January, 1rst 1970, I can't imagine
>>> today another real use case where we would have that date.
>>>  So checking this value is entirely sufficient to know that the certificate
>>> serial number has not been used to the knowledge of the CA.
>>>  
>>>  So we are at least three persons who believe that we should not define that
>>> extension.
>>>  
>>>  Now, if some other persons can demonstrate that this extension is really
>>> needed, then it is time for them to speak up.
>>>  
>>>  Denis
>>>  
>>>  
>>>  
>>>  
>>>>  
>>>> Piyush,
>>>> 
>>>> On 1/28/13 10:09 PM, "Piyush Jain" 
>>>>   wrote:
>>>> 
>>>>  
>>>>>  
>>>>> Stefan,
>>>>> 
>>>>> Clearly we have disagreement on how this issue is addressed in current
>>>>> draft.  
>>>>> I'm actually surprised at your statement that clients should not
>>>>> differentiate between non-issued and revoked certs, given that the draft
>>>>> mandates that servers include extended revoked extension if it  is
>>>>> changing
>>>>> the meaning of revoked. If it is so, why bloat the response with this
>>>>> extension at all.
>>>>>  
>>>>  
>>>> As it has been stated here before, and also communicated in the minutes of
>>>> the last PKIX meeting in Atlanta, the rationale behind including this
>>>> extension is to allow audits.
>>>> If something goes wrong and you go through the records, there will be
>>>> evidence that the responder that provided a particular response of
>>>> interest, supported this functionality.
>>>> 
>>>> No client is required to understand this extension or to do anything with
>>>> it to function properly.
>>>> My personal preference would be to not define this extension at all, but
>>>> having this extension is so far WG rough consensus and hence it is
>>>> included in the draft.
>>>> Enough people feel strongly about it and it does no damage to have it
>>>> there.
>>>> 
>>>> /Stefan
>>>> 
>>>> 
>>>>  
>>>>>  
>>>>> So far, besides you and me, Peter Rybar is the only one who has referred
>>>>> to
>>>>> this issue in one of his posts, acknowledging that it exists.
>>>>> I hope we have opinions of a few others folks before we decide one way or
>>>>> other.
>>>>> 
>>>>> -Piyush
>>>>> 
>>>>>  
>>>>>>  
>>>>>> -----Original Message-----
>>>>>> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>>>>>> Sent: Monday, January 28, 2013 12:25 PM
>>>>>> To: Piyush Jain; pkix@ietf.org
>>>>>> Subject: Re: [pkix] Responder trust issue for non-issued certificates
>>>>>> not
>>>>>> addressed in 2560 bis draft 11
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 1/28/13 7:09 PM, "Piyush Jain" 
>>>>>>   wrote:
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> You said
>>>>>>>  
>>>>>>>  
>>>>>>> "It's quite easy. If they trust the responder, they are supposed to
>>>>>>> trust
>>>>>>>  
>>>>>>>  
>>>>>>> the response.
>>>>>>>  
>>>>>>>  
>>>>>>> If they have not established the trust described above, they MUST
>>>>>>> reject
>>>>>>>  
>>>>>>>  
>>>>>>> the response.
>>>>>>>  
>>>>>>>  
>>>>>>> This has nothing to do with what responses they get."
>>>>>>>  
>>>>>>>  
>>>>>>> I disagree with this statement. The document clearly states that
>>>>>>> contents of responses should be looked at before accepting the
>>>>>>> response. This includes looking at signature and certid contained in
>>>>>>> the response.
>>>>>>>  
>>>>>>  
>>>>>> Of course, I didn't say it because its central and kind of obvious.
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> Not-issued response is something that is introduced in this draft
>>>>>>>  
>>>>>>  
>>>>>> No, look closer. The draft does NOT define a "not-issued" response. It
>>>>>>  
>>>>>  
>>>>> allows
>>>>>  
>>>>>>  
>>>>>> the "revoked" response if a certificate serial number has never been
>>>>>>  
>>>>>  
>>>>> issued.
>>>>>  
>>>>>>  
>>>>>> That is two entirely different things.
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> and the
>>>>>>> current discussion is about how the client establishes trust in such a
>>>>>>> response.
>>>>>>>  
>>>>>>  
>>>>>> As it would with any other response.
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> If you ask how to deal with the response, then the client will not
>>>>>>> get a
>>>>>>>  
>>>>>>>  
>>>>>>> non- issued response. It will get a "revoked" status.
>>>>>>>  
>>>>>>>  
>>>>>>> This indicates that the certificate they asked about should not be
>>>>>>>  
>>>>>>>  
>>>>>>> trusted.
>>>>>>> 
>>>>>>> I was under the impression that syntax of 'revoked' is only being used
>>>>>>> for backward compatibility. And that revocation date-1970 in
>>>>>>> conjunction with revocation status onhold implies that certificate is
>>>>>>>  
>>>>>>  
>>>>>  
>>>>> not-
>>>>>  
>>>>>>  
>>>>>> issued.
>>>>>> 
>>>>>> No. The meaning is just to allow the server to provide a response that
>>>>>> has
>>>>>> the likely outcome that the client will not use that cert, if there even
>>>>>>  
>>>>>  
>>>>> is such a
>>>>>  
>>>>>>  
>>>>>> cert and the request isn't simply an error.
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> Also the
>>>>>>> new extended revoked extension implies that certificate is not-issued.
>>>>>>> Are you now arguing that 'revoked' and 'not-issued' should be
>>>>>>> semantically equivalent as well?
>>>>>>>  
>>>>>>  
>>>>>> No, the extension signals that the server supports this extended use of
>>>>>> revoked. It says nothing about whether it is used for any of the certs
>>>>>> in
>>>>>>  
>>>>>  
>>>>> a
>>>>>  
>>>>>>  
>>>>>> particular response.
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> Finally, here is a point regarding providing guidance to clients.
>>>>>>> Non-issued response is a new state that is being introduced in this
>>>>>>> update.
>>>>>>>  
>>>>>>  
>>>>>> This is getting tiresome. No, there is no new state. There is an
>>>>>> extended
>>>>>>  
>>>>>  
>>>>> use
>>>>>  
>>>>>>  
>>>>>> of "revoked".
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> The only reason revoked is being overloaded is to maintain backward
>>>>>>> compatibility with existing clients. However, to assume that future
>>>>>>> clients won't try to interpret the meaning of extended revoked
>>>>>>> extension is short-sighted. Avoiding guidelines on how clients deal
>>>>>>> with it is bound to cause confusion for anyone who uses this RFC  to
>>>>>>> implement a OCSP client.
>>>>>>>  
>>>>>>  
>>>>>> No, all may experience with PKI development suggests contrary to your
>>>>>> prediction.
>>>>>> However, if we tried to craft some extensive guidance on how to try to
>>>>>> detect and mitigate CA compromise, that will definitely cause confusion
>>>>>>  
>>>>>  
>>>>> and
>>>>>  
>>>>>>  
>>>>>> make implementers think they have to deal with this.
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>> The fact is that in absence of such guidelines, clients would probably
>>>>>>> continue to trust a responder that is issued by a CA which is
>>>>>>> compromised (level of compromise is irrelevant here).
>>>>>>>  
>>>>>>  
>>>>>> Which is exactly what we expect them to do. It is not the clients task
>>>>>> to
>>>>>>  
>>>>>  
>>>>> spot
>>>>>  
>>>>>>  
>>>>>> and correct the problem of compromised CAs.
>>>>>> That is the task of trust service providers and the controls they put in
>>>>>>  
>>>>>  
>>>>> place.
>>>>>  
>>>>>>  
>>>>>>>  
>>>>>>> At the minimum, we should clarify
>>>>>>> the implications so clients can make informed choices.  I repeat that
>>>>>>> failing to do so is violation of RFC 2418.
>>>>>>>  
>>>>>>  
>>>>>> No. Security considerations requires you to discuss security issues
>>>>>>  
>>>>>  
>>>>> introduced
>>>>>  
>>>>>>  
>>>>>> by a protocol.
>>>>>> The added mechanism does not introduce any new security vulnerabilities
>>>>>> that you have pointed out.
>>>>>> To the contrary.
>>>>>> 
>>>>>> /Stefan
>>>>>> 
>>>>>>  
>>>>>  
>>>>> _______________________________________________
>>>>> pkix mailing list
>>>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>>  
>>>>  
>>>> _______________________________________________
>>>> pkix mailing list
>>>> pkix@ietf.orghttps://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



--B_3442301641_37715866
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


    Denis,

    <=
div>It would be easier if you read the messages on the list.
    I ans=
wered the same very question on the list less than 24 hours ago.
    <=
br>
    Your contribution to this process is most welcome, but if you =
want to be part of it, then please participate while the issue is discussed =
and not at the very last minute months after the issue is decided and closed=
.

    During the straw poll on this list on the way for=
ward regarding this extended revoked definition, this was discussed and agre=
ed.
    The issue was than discussed further at Atlanta and concluded =
in the minutes.

    Just because you now raise the issue again, d=
oes not mean that the people who participated while the issue was discussed =
has to rush to their keyboards and defending their position.
    In ge=
neral, if you want to change the directions of things we already have conclu=
ded, then you need to gather support for your arguments to change it.
    <=
div>
    We need to keep the process going.

    /Stefan



    From:  Denis Pinkas <denis.pinkas@bull.net>
    Date:=
  Tuesday, January 29, 2013 10:33 AM
    To:  Stefan Santesson <stefa=
n@aaa-sec.com>
    Cc:  <pkix@ietf.org>
    Subject:  Re: [pkix] Responder trust issue for non-issued cert=
ificates not addressed in 2560 bis draft 11

    
  
    
  
  
    
    
    Stefan,
    
      
    
      Since you say that from the last PKIX meeting in Atlanta, and from
      the discussion on the list that preceded that meeting, 
    
      it is evident that this extension is needed, would be
      please recall shortly why ?
    
      
    
      In addition, would you be able to provide a counter argument to my
      argumentation below ?
    
      
    
      Then we should also other people that are not on the same time
      zone to speak up.
    
       
    
      Denis
    
      
    
      
    
    
    
    
    =

      
    It's not a matter of what individuals want.
    
      

    
      
    
      
    It is about finding to best common ground that everyone can
        live with.
    
      
    It was evident form the last PKIX meeting in Atlanta, and
        from the discussion on the list that preceded that meeting, that
        having this extension was necessary to reach WG consensus on
        expanding the "revoked" scope.
    
      

    
      
    
      
    This has already been dealt with in the WG process. Those who
        need to speak up are those wanting to change the decision and
        demonstrate why it need to be removed.
    
      

    
      
    
      
    /Stefan
    
      

    
      
    
      
        
    From:  Denis Pinkas <denis.pinkas@bull.net>
    
          Date:  Tuesday, January
          29, 2013 9:52 AM
    
          To:  Stefan Santesson
          <st=
efan@aaa-sec.com>
    
          Cc:  <pkix@ietf.org>
    
          Subject:  Re: [pkix]
          Responder trust issue for non-issued certificates not
          addressed in 2560 bis draft 11
    
        
    
        

    
        
    
        
    
          
    
            
            
    
              
    Stefan,
    
                
    
                The discussion is now days and nights since we have
                participants from around the world.
    
                I have not yet started to review your answers to my
                comments, but in the mean time I took a look 
    
                at the numerous messages that have been exchanged.
    
                
    
                You said: "My personal preference would be to not define
                this extension at all", 
    
                
    
                Piyush does not want it either.
    
                
    
                I don't think it is needed either.
    
                
    
                Since the revocation date is set to January, 1rst 1970,
                I can't imagine today another real use case
                where we would have that date.
    
                So checking this value is entirely sufficient to know
                that the certificate serial number has not been used to
                the knowledge of the CA.
    
                
    
                So we are at least three persons who believe that we
                should not define that extension.
    
                
    
                Now, if some other persons can demonstrate that this
                extension is really needed, then it is time for them to
                speak up.
    
                
    
                Denis
    
                
    
                
    
              
    
              
    
                
    Piyush,

On 1/28/13 10:09 PM, "Piyush Jain" <piyush@ditenity.com>=
; wrote:


    
                
    
                  
    Stefan,

Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is
changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

    
                
    
                
    As it has been stated here before, and also co=
mmunicated in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.

No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.

/Stefan



    
                
    
                  
    So far, besides you and me, Peter Rybar is t=
he only one who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.

-Piyush


    
                  
    
                    
    -----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not
addressed in 2560 bis draft 11



On 1/28/13 7:09 PM, "Piyush Jain" <piyush@ditenity.com>=
 wrote:


    
                    
    
                      
    You said

    
                      
    
                        
    "It's quite easy. If they trust the re=
sponder, they are supposed to
trust

    
                      
    
                      
    the response.

    
                      
    
                        
    If they have not established the trust=
 described above, they MUST
reject

    
                      
    
                      
    the response.

    
                      
    
                        
    This has nothing to do with what respo=
nses they get."

    
                      
    
                      
    I disagree with this statement. The docu=
ment clearly states that
contents of responses should be looked at before accepting the
response. This includes looking at signature and certid contained in
the response.

    
                    
    
                    
    Of course, I didn't say it because its cen=
tral and kind of obvious.


    
                    
    
                      
    Not-issued response is something that is=
 introduced in this draft

    
                    
    
                    
    No, look closer. The draft does NOT define=
 a "not-issued" response. It

    
                  
    
                  
    allows

    
                  
    
                    
    the "revoked" response if a certificate se=
rial number has never been

    
                  
    
                  
    issued.

    
                  
    
                    
    That is two entirely different things.



    
                    
    
                      
    and the
current discussion is about how the client establishes trust in such a
response.

    
                    
    
                    
    As it would with any other response.


    
                    
    
                      
    
                        
    If you ask how to deal with the respon=
se, then the client will not
get a

    
                      
    
                      
    non- issued response. It will get a "rev=
oked" status.

    
                      
    
                        
    This indicates that the certificate th=
ey asked about should not be

    
                      
    
                      
    trusted.

I was under the impression that syntax of 'revoked' is only being used
for backward compatibility. And that revocation date-1970 in
conjunction with revocation status onhold implies that certificate is

    
                    
    
                  
    
                  
    not-

    
                  
    
                    
    issued.

No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

    
                  
    
                  
    is such a

    
                  
    
                    
    cert and the request isn't simply an error=
.



    
                    
    
                      
    Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be
semantically equivalent as well?

    
                    
    
                    
    No, the extension signals that the server =
supports this extended use of
revoked. It says nothing about whether it is used for any of the certs
in

    
                  
    
                  
    a

    
                  
    
                    
    particular response.



    
                    
    
                      
    Finally, here is a point regarding provi=
ding guidance to clients.
Non-issued response is a new state that is being introduced in this
update.

    
                    
    
                    
    This is getting tiresome. No, there is no =
new state. There is an
extended

    
                  
    
                  
    use

    
                  
    
                    
    of "revoked".


    
                    
    
                      
    The only reason revoked is being overloa=
ded is to maintain backward
compatibility with existing clients. However, to assume that future
clients won't try to interpret the meaning of extended revoked
extension is short-sighted. Avoiding guidelines on how clients deal
with it is bound to cause confusion for anyone who uses this RFC  to
implement a OCSP client.

    
                    
    
                    
    No, all may experience with PKI developmen=
t suggests contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion

    
                  
    
                  
    and

    
                  
    
                    
    make implementers think they have to deal =
with this.



    
                    
    
                      
    The fact is that in absence of such guid=
elines, clients would probably
continue to trust a responder that is issued by a CA which is
compromised (level of compromise is irrelevant here).

    
                    
    
                    
    Which is exactly what we expect them to do=
. It is not the clients task
to

    
                  
    
                  
    spot

    
                  
    
                    
    and correct the problem of compromised CAs=
.
That is the task of trust service providers and the controls they put in

    
                  
    
                  
    place.

    
                  
    
                    
    
                      
    At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

    
                    
    
                    
    No. Security considerations requires you t=
o discuss security issues

    
                  
    
                  
    introduced

    
                  
    
                    
    by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.

/Stefan


    
                  
    
                  
    ____________________________________________=
___
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix
    
                
    
                
    ______________________________________________=
_
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix
    
              
    
              
    
            
    
          
    
          _______________________________________________
          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_3442301641_37715866--



From piyush@ditenity.com  Tue Jan 29 08:06:42 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 B833C21F8992 for ; Tue, 29 Jan 2013 08:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 mg2QP4EGNGQ1 for ; Tue, 29 Jan 2013 08:06:38 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3121F890F for ; Tue, 29 Jan 2013 08:06:38 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id ni5so564495obc.40 for ; Tue, 29 Jan 2013 08:06: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:x-mailer:thread-index :content-language:x-gm-message-state; bh=roYBx6TKbvnHG0jw3f1bQwiwj3ZNdyoPF5CJ4e+a79Y=; b=Q5gqna4r/LuoOVwE5/xcjSlUJkolrn4PPdiZke3/ucq+r0mop6+Dbj+fvFzIau2FWp 5XZQBoTufyFCYsGdJ2ezXAsvljQ5/PlZkuEG1++YSdlOlCPUXp4mpzNDttitdjRU6i8W Lo6RWxSLQ+lr5HbuaEFCnn8i2wHsx9rOBFKNHwRH31v+3tqQfdNPH3FxndtU0IjeYZJi pljr71iK6pwMGxhqrkjv40MBS9x+dWIw1e3JzUFZGIoCIuLytajpRMhO7Fyk0xfg6U9G jdf/+xo3sJdP3QS2O5/ZxMEUf9YFXiouHHhRNsCrQBM2msHgcDK919uQwnE8rmRKvJM1 FOvA==
X-Received: by 10.60.3.193 with SMTP id e1mr1181051oee.39.1359475597812; Tue, 29 Jan 2013 08:06:37 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id 7sm10564905obu.4.2013.01.29.08.06.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 08:06:37 -0800 (PST)
From: "Piyush Jain" 
To: "'Denis Pinkas'" , "'Stefan Santesson'" 
References:  <51078DDF.4020700@bull.net>
In-Reply-To: <51078DDF.4020700@bull.net>
Date: Tue, 29 Jan 2013 08:06:33 -0800
Message-ID: <017701cdfe3a$9ce034f0$d6a09ed0$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01CDFDF7.8EC161C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJQHL/g1ySpKiEzHTY5tkx9Sj913gG5HcqHl05vcMA=
Content-Language: en-us
X-Gm-Message-State: ALoCoQmIyTbQiA932QS9bNX6otAFqfVc1oig4EXNav/j8oDKxisRVGcpvcJJ/NVQUmYyMIdnfMol
Cc: pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
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, 29 Jan 2013 16:06:42 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0178_01CDFDF7.8EC161C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Just want to clarify.

 

While I agree with Denis that semantics of extended revoked extension are
equivalent to a revoked response with revocation date set to 1970, it is a
minor issue from my point of view.

 

My bigger concern is the assumption in Stefan's argument that clients do not
need to interpret the meaning of extended revoked except for
logging/auditing purpose. This assumption is not stated in the document
anywhere even though the document clearly states what extended revoked
response looks like and how it can be differentiated from a regular revoked
response.

 

Assuming that COMPLIANT client implementations will automatically treat
extended revoked as regular revoked is IMO short sighted. I know that this
will work for legacy clients, but is bound to cause confusion for future
implementations.

 

-Piyush

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
Sent: Tuesday, January 29, 2013 12:53 AM
To: Stefan Santesson
Cc: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

 

Stefan,

The discussion is now days and nights since we have participants from around
the world.
I have not yet started to review your answers to my comments, but in the
mean time I took a look 
at the numerous messages that have been exchanged.

You said: "My personal preference would be to not define this extension at
all", 

Piyush does not want it either.

I don't think it is needed either.

Since the revocation date is set to January, 1rst 1970, I can't imagine
today another real use case where we would have that date.
So checking this value is entirely sufficient to know that the certificate
serial number has not been used to the knowledge of the CA.

So we are at least three persons who believe that we should not define that
extension.

Now, if some other persons can demonstrate that this extension is really
needed, then it is time for them to speak up.

Denis



Piyush,
 
On 1/28/13 10:09 PM, "Piyush Jain"  
 wrote:
 

Stefan,
 
Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is
changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

 
As it has been stated here before, and also communicated in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.
 
No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.
 
/Stefan
 
 

 
So far, besides you and me, Peter Rybar is the only one who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.
 
-Piyush
 

-----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not
addressed in 2560 bis draft 11
 
 
 
On 1/28/13 7:09 PM, "Piyush Jain"  
 wrote:
 

You said

"It's quite easy. If they trust the responder, they are supposed to
trust

the response.

If they have not established the trust described above, they MUST
reject

the response.

This has nothing to do with what responses they get."

 
I disagree with this statement. The document clearly states that
contents of responses should be looked at before accepting the
response. This includes looking at signature and certid contained in
the response.

 
Of course, I didn't say it because its central and kind of obvious.
 

 
Not-issued response is something that is introduced in this draft

 
No, look closer. The draft does NOT define a "not-issued" response. It

allows

the "revoked" response if a certificate serial number has never been

issued.

That is two entirely different things.
 
 

and the
current discussion is about how the client establishes trust in such a
response.

 
As it would with any other response.
 

 

If you ask how to deal with the response, then the client will not
get a

non- issued response. It will get a "revoked" status.

This indicates that the certificate they asked about should not be

trusted.
 
I was under the impression that syntax of 'revoked' is only being used
for backward compatibility. And that revocation date-1970 in
conjunction with revocation status onhold implies that certificate is

not-

issued.
 
No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

is such a

cert and the request isn't simply an error.
 
 

Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be
semantically equivalent as well?

 
No, the extension signals that the server supports this extended use of
revoked. It says nothing about whether it is used for any of the certs
in

a

particular response.
 
 

 
Finally, here is a point regarding providing guidance to clients.
Non-issued response is a new state that is being introduced in this
update.

 
This is getting tiresome. No, there is no new state. There is an
extended

use

of "revoked".
 

The only reason revoked is being overloaded is to maintain backward
compatibility with existing clients. However, to assume that future
clients won't try to interpret the meaning of extended revoked
extension is short-sighted. Avoiding guidelines on how clients deal
with it is bound to cause confusion for anyone who uses this RFC  to
implement a OCSP client.

 
No, all may experience with PKI development suggests contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion

and

make implementers think they have to deal with this.
 
 

The fact is that in absence of such guidelines, clients would probably
continue to trust a responder that is issued by a CA which is
compromised (level of compromise is irrelevant here).

 
Which is exactly what we expect them to do. It is not the clients task
to

spot

and correct the problem of compromised CAs.
That is the task of trust service providers and the controls they put in

place.

 
 

At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

 
No. Security considerations requires you to discuss security issues

introduced

by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.
 
/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

 


------=_NextPart_000_0178_01CDFDF7.8EC161C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Just want to clarify.
     
    While I agree with Denis that semantics of extended revoked extension =
are equivalent to a revoked response with revocation date set to 1970, =
it is a minor issue from my point of view.
     
    My bigger concern is the assumption in Stefan’s argument that =
clients do not need to interpret the meaning of extended revoked except =
for logging/auditing purpose. This assumption is not stated in the =
document anywhere even though the document clearly states what extended =
revoked response looks like and how it can be differentiated from a =
regular revoked response.
     
    Assuming that COMPLIANT client implementations will automatically =
treat extended revoked as regular revoked is IMO short sighted. I know =
that this will work for legacy clients, but is bound to cause confusion =
for future implementations.
     
    -Piyush
     
    From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
    Sent: =
Tuesday, January 29, 2013 12:53 AM
    To: Stefan =
Santesson
    Cc: Piyush Jain; pkix@ietf.org
    Subject: =
Re: [pkix] Responder trust issue for non-issued certificates not =
addressed in 2560 bis draft 11
     
    Stefan,

    The discussion is now days =
and nights since we have participants from around the world.
    I have =
not yet started to review your answers to my comments, but in the mean =
time I took a look 
    at the numerous messages that have been =
exchanged.

    You said: "My personal preference would be to not =
define this extension at all", 

    Piyush does not want it =
either.

    I don't think it is needed either.

    Since the =
revocation date is set to January, 1rst 1970, I can't imagine today =
another real use case where we would have that date.
    So checking =
this value is entirely sufficient to know that the certificate serial =
number has not been used to the knowledge of the CA.

    So we are at =
least three persons who believe that we should not define that =
extension.

    Now, if some other persons can demonstrate that this =
extension is really needed, then it is time for them to speak =
up.

    Denis

    Piyush,
     
    On 1/28/13 10:09 PM, "Piyush =
Jain" <piyush@ditenity.com> =
wrote:
     
    Stefan,
     
    Clearly we have disagreement on how =
this issue is addressed in current
    draft.  =

    I'm actually surprised at your statement that =
clients should not
    differentiate between non-issued =
and revoked certs, given that the draft
    mandates =
that servers include extended revoked extension if it  =
is
    changing
    the meaning of =
revoked. If it is so, why bloat the response with =
this
    extension at =
all.
     
    As it =
has been stated here before, and also communicated in the minutes =
of
    the last PKIX meeting in Atlanta, the rationale =
behind including this
    extension is to allow =
audits.
    If something goes wrong and you go through =
the records, there will be
    evidence that the =
responder that provided a particular response =
of
    interest, supported this =
functionality.
     
    No =
client is required to understand this extension or to do anything =
with
    it to function =
properly.
    My personal preference would be to not =
define this extension at all, but
    having this =
extension is so far WG rough consensus and hence it =
is
    included in the =
draft.
    Enough people feel strongly about it and it =
does no damage to have =
it
    there.
     
    /Stefan
     
    &nbs=
p;
     
    So far, besides you and me, Peter Rybar is the only one who has =
referred
    to
    this issue in one =
of his posts, acknowledging that it exists.
    I hope =
we have opinions of a few others folks before we decide one way =
or
    other.
     
    -Piyush
     
    -----Original =
Message-----
    From: Stefan Santesson [mailto:stefan@aaa-sec.com]
    Sent: Monday, January 28, 2013 12:25 =
PM
    To: Piyush Jain; pkix@ietf.org
    Subj=
ect: Re: [pkix] Responder trust issue for non-issued =
certificates
    not
    addressed in =
2560 bis draft =
11
     
     
     
    On 1/28/13 7:09 PM, "Piyush =
Jain" <piyush@ditenity.com> =
wrote:
     
    You =
said
    "It's quite =
easy. If they trust the responder, they are supposed =
to
    trust
    the =
response.
    If they have not =
established the trust described above, they =
MUST
    reject
    the =
response.
    This has nothing to =
do with what responses they =
get."
     
    =
I disagree with this statement. The document clearly states =
that
    contents of responses should be looked at =
before accepting the
    response. This includes =
looking at signature and certid contained in
    the =
response.
     
    O=
f course, I didn't say it because its central and kind of =
obvious.
     
     
    Not-issued response is something that is introduced in this =
draft
     
    No, =
look closer. The draft does NOT define a "not-issued" =
response. =
It
    allows
    the =
"revoked" response if a certificate serial number has never =
been
    issued.
    That is two =
entirely different =
things.
     
     
    and =
the
    current discussion is about how the client =
establishes trust in such =
a
    response.
    &=
nbsp;
    As it would with any other =
response.
     
     
    If you =
ask how to deal with the response, then the client will =
not
    get a
    non- =
issued response. It will get a "revoked" =
status.
    This indicates that =
the certificate they asked about should not =
be
    trusted.
    &=
nbsp;
    I was under the impression that syntax of =
'revoked' is only being used
    for backward =
compatibility. And that revocation date-1970 =
in
    conjunction with revocation status onhold =
implies that certificate =
is
    not-
    issued.
     
    No. The meaning is just to allow the =
server to provide a response =
that
    has
    the likely outcome =
that the client will not use that cert, if there =
even
    is such =
a
    cert and the request =
isn't simply an =
error.
     
     =

    Also =
the
    new extended revoked extension implies that =
certificate is not-issued.
    Are you now arguing that =
'revoked' and 'not-issued' should be
    semantically =
equivalent as =
well?
     
    No, =
the extension signals that the server supports this extended use =
of
    revoked. It says nothing about whether it is =
used for any of the =
certs
    in
    a
    particular =
response.
     
     
     
    Finally, here is a point regarding providing guidance to =
clients.
    Non-issued response is a new state that is =
being introduced in =
this
    update.
    =
 
    This is getting tiresome. No, there is no new =
state. There is =
an
    extended
    use
    of =
"revoked".
     
    The only reason =
revoked is being overloaded is to maintain =
backward
    compatibility with existing clients. =
However, to assume that future
    clients won't try to =
interpret the meaning of extended revoked
    extension =
is short-sighted. Avoiding guidelines on how clients =
deal
    with it is bound to cause confusion for anyone =
who uses this RFC  to
    implement a OCSP =
client.
     
    No,=
 all may experience with PKI development suggests contrary to =
your
    prediction.
    However, if =
we tried to craft some extensive guidance on how to try =
to
    detect and mitigate CA compromise, that will =
definitely cause =
confusion
    and
    make implementers =
think they have to deal with =
this.
     
     <=
/pre>
    The =
fact is that in absence of such guidelines, clients would =
probably
    continue to trust a responder that is =
issued by a CA which is
    compromised (level of =
compromise is irrelevant =
here).
     
    Whic=
h is exactly what we expect them to do. It is not the clients =
task
    to
    spot<=
/o:p>
    and correct the =
problem of compromised CAs.
    That is the task of =
trust service providers and the controls they put =
in
    place.
     
     
    At the minimum, we =
should clarify
    the implications so clients can make =
informed choices.  I repeat that
    failing to do =
so is violation of RFC =
2418.
     
    No. =
Security considerations requires you to discuss security =
issues
    introduced
    by a =
protocol.
    The added mechanism does not introduce =
any new security vulnerabilities
    that you have =
pointed out.
    To the =
contrary.
     
    /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
     
    
------=_NextPart_000_0178_01CDFDF7.8EC161C0--


From prvs=0741dac89f=rybar@nbusr.sk  Tue Jan 29 09:06: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 D394D21F8A91 for ; Tue, 29 Jan 2013 09:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.693
X-Spam-Level: 
X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 tEEwQlS6jSOe for ; Tue, 29 Jan 2013 09:06:25 -0800 (PST)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5835A21F8955 for ; Tue, 29 Jan 2013 09:06:17 -0800 (PST)
Message-Id: <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
From: "Peter Rybar" 
To: "'Stefan Santesson'" , pkix@ietf.org
Date: Tue, 29 Jan 2013 18:06:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CDFE4B.5B93AF20"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: 
Thread-Index: Ac3+BRhTiaQ/Xc5aRbmc837mGISnUQANd8CA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level: **
X-NAI-Spam-Threshold: 6
X-NAI-Spam-Score: 2.5
X-NAI-Spam-Version: 2.2.0.9309 : core <4476> : streams <897005> : uri <1331135>
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, 29 Jan 2013 17:06:27 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01CDFE4B.5B93AF20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I agree with Piyush Jain about the unclear situations for RP with the =
"revoked" status for non-issued =E2=80=A6 (probably issued but the =
record is not in database or the key was compromised).

Especially it is unclear from the liability point of view.

=20

What 2560bis draft 12 is trying to be solved with extension of "revoked" =
status? :

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

=20

This situation is already covered in standard way as you can see later =
in my mail when "unauthorized" is returned.

=20

Another problematic part is using the certificateHold in revocations.

The text in 4.4.8 Extended Revoked Definition contains =E2=80=9Cto allow =
audits to determine the type of operation by the responder=E2=80=9D

=20

As it was many times presented, the usage of the status certificateHold =
is forbidden in many systems because e.g. in mutual authentications when =
user SSL/TSL certificate is several times in certificateHold for some =
reason and then again valid you have not evidence in last CRL or in =
actual OCSP when in the past was access according to certificateHold of =
user SSL/TSL certificate forbidden for user. The usage of =
certificateHold is a killer for audits or validation systems.

You have not evidence why and when in the past some actions were or were =
not correct.

=20

But can you imagine how you will validate e.g. signatures with signature =
timestamp when the usage of certificateHold is possible and certificate =
can be several times in certificateHold. When certificate is in =
certificateHold then such transaction in that time must not be valid!=20

For that reason when transactions realized in the past are also =
important is some resent actions and not only as online actual then PKI =
must be able to provide evidence and for that reason certificateHold =
must not be used.=20

=20

=20

http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12

The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server or the server is not
   capable of responding authoritatively (cf. [RFC5019], Section =
  2.2.3).

=20

http://tools.ietf.org/html/rfc5019#section-2.2.3


  2.2.3.  =
OCSPResponseStatus Values

=20
=20
   As long as the OCSP infrastructure has authoritative records for a
   particular certificate, an OCSPResponseStatus of "successful" will be
   returned.  When access to authoritative records for a particular
   certificate is not available, the responder MUST return an
   OCSPResponseStatus of "unauthorized".  As such, this profile extends
   the RFC 2560   [OCSP =
 ] definition of =
"unauthorized" as follows:
=20
      The response "unauthorized" is returned in cases where the client
      is not authorized to make this query to this server or the server
      is not capable of responding authoritatively.
=20
   For example, OCSP responders that do not have access to authoritative
   records for a requested certificate, such as those that generate and
   distribute OCSP responses in advance and thus do not have the ability
   to properly respond with a signed "successful" yet "unknown"
   response, will respond with an OCSPResponseStatus of "unauthorized".
   Also, in order to ensure the database of revocation information does
   not grow unbounded over time, the responder MAY remove the status
   records of expired certificates.  Requests from clients for
   certificates whose record has been removed will result in an
   OCSPResponseStatus of "unauthorized".
=20
   Security considerations regarding the use of unsigned responses are
   discussed in [OCSP  ].

=20

=20

  _____ =20

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Stefan Santesson
Sent: Tuesday, January 29, 2013 10:43 AM
To: pkix@ietf.org
Subject: [pkix] 2560bis draft 12 posted

=20

Draft 12 is posted.

=20

This update includes:

- The ASN.1 is consolidated and now contains just one 88 syntax section =
and one 2002 syntax section. The OCSP module from 5912 has been imported =
and updated.

- The ASN.1 update includes extension definitions for the no check =
extension as well as the new extended revoke extension.

- A few minor editorial cleanups

- Added a note in the extended revoke extension section 4.4.8 to clarify =
that clients do not have to process this extension in order to determine =
status on certificates.

=20

This document now only lacks the new OIDs for the new ASN.1 modules. As =
soon as I have them, I will post draft 13.

=20

I know that not everyone is super happy with the result, but on the =
other hand, that seldom is the case with updates of this kind.

=20

It is however my view that the document in it's current shape is a =
reasonable capture of rough WG consensus, and that it now is ready for =
shipping to the IESG.

=20

/Stefan


------=_NextPart_000_002F_01CDFE4B.5B93AF20
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable














    


    Stefan,
    


     =

    


    I agree with Piyush Jain about the unclear situations for RP =
with the "revoked" status for =
non-issued =E2=80=A6
(probably issued but the record is not in database or the key was =
compromised).
    


    Especially it =
is unclear from
the liability point of view.
    


     
    


    What 2560bis =
draft 12 is
trying to be solved with extension of "revoked"
status? :


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


     
    


    This situation =
is already
covered in standard way as you can see later in my mail when =
"unauthorized" is returned.


     
    


    Another =
problematic part
is using the certificateHold in =
revocations.
    


    The text in 4.4.8 Extended Revoked Definition =
contains =E2=80=9Cto allow audits to determine the type of =
operation by the responder=E2=80=9D
    


    =C2=A0
    


    As it was many =
times presented,
the usage of the status certificateHold is forbidden in many systems =
because e.g.
in mutual authentications when user SSL/TSL certificate is several times =
in certificateHold
for some reason and then again valid you have not evidence in last CRL =
or in actual
OCSP when in the past was access according to certificateHold of user =
SSL/TSL
certificate forbidden for user. The usage of certificateHold is a killer =
for
audits or validation systems.
    


    You have not =
evidence why
and when in the past some actions were or were not =
correct.
    


     
    


    But can you =
imagine how you
will validate e.g. signatures with signature timestamp when the usage of =
certificateHold
is possible and certificate can be several times in certificateHold. =
When
certificate is in certificateHold then such transaction in that time =
must not
be valid! 
    


    For that =
reason when transactions
realized in the past are also important is some resent actions and not =
only as
online actual then PKI must be able to provide evidence and for that =
reason certificateHold
must not be used. 
    


     
    


     =

    


    http://=
tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
    


    The response "unauthorized" is =
returned in cases where the client =
is
    =C2=A0=C2=A0 not authorized to make this =
query to this server or the server is =
not
    =C2=A0=C2=A0 capable of responding =
authoritatively (cf. [RFC5019], =
Section 2.2.3).
    


     =

    


    http://tools.ie=
tf.org/html/rfc5019#section-2.2.3
    


    2.2.3.=C2=A0
OCSPResponseStatus Values
    


     
     
    =C2=A0=C2=A0 As long as the OCSP =
infrastructure has authoritative records for =
a
    =C2=A0=C2=A0 particular certificate, an =
OCSPResponseStatus of "successful" will =
be
    =C2=A0=C2=A0 returned.=C2=A0 When access to =
authoritative records for a =
particular
    =C2=A0=C2=A0 certificate is not available, =
the responder =
MUST return =
an
    =C2=A0=C2=A0 OCSPResponseStatus of =
"unauthorized".=C2=A0 As such, this profile =
extends
    =C2=A0=C2=A0 the RFC 2560 [OCSP] definition of =
"unauthorized" as =
follows:
     
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The response =
"unauthorized" is returned in cases where the =
client
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not =
authorized to make this query to this server or the =
server
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not capable =
of responding authoritatively.
     
    =C2=A0=C2=A0 For example, OCSP responders =
that do not have access to =
authoritative
    =C2=A0=C2=A0 records for a requested =
certificate, such as those that generate =
and
    =C2=A0=C2=A0 distribute OCSP responses in =
advance and thus do not have the =
ability
    =C2=A0=C2=A0 to properly respond with a =
signed "successful" yet =
"unknown"
    =C2=A0=C2=A0 response, will respond with an =
OCSPResponseStatus of =
"unauthorized".
    =C2=A0=C2=A0 Also, in order to ensure the =
database of revocation information =
does
    =C2=A0=C2=A0 not grow unbounded over time, =
the responder MAY remove the =
status
    =C2=A0=C2=A0 records of expired =
certificates.=C2=A0 Requests from clients =
for
    =C2=A0=C2=A0 certificates whose record has =
been removed will result in an
    =C2=A0=C2=A0 OCSPResponseStatus of =
"unauthorized".
     
    =C2=A0=C2=A0 Security considerations =
regarding the use of unsigned responses =
are
    =C2=A0=C2=A0 discussed in [OCSP].
    


     =

    


     =

    


    


    


    


    


    From:
pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
    
Sent: Tuesday, January =
29, 2013
10:43 AM
    
To: pkix@ietf.org
    
Subject: [pkix] 2560bis =
draft 12
posted
    


    


     
    


    


    Draft 12 is =
posted.
    


    


    


     
    


    


    


    This update =
includes:
    


    


    


    - The ASN.1 =
is
consolidated and now contains just one 88 syntax section and one 2002 =
syntax
section. The OCSP module from 5912 has been imported and =
updated.
    


    


    


    - The ASN.1 =
update
includes extension definitions for the no check extension as well as the =
new
extended revoke extension.
    


    


    


    - A few minor
editorial cleanups
    


    


    


    - Added a =
note in the
extended revoke extension section 4.4.8 to clarify that clients do not =
have to
process this extension in order to determine status on =
certificates.
    


    


    


     
    


    


    


    This document =
now only
lacks the new OIDs for the new ASN.1 modules. As soon as I have them, I =
will
post draft 13.
    


    


    


     
    


    


    


    I know that =
not
everyone is super happy with the result, but on the other hand, that =
seldom is
the case with updates of this kind.
    


    


    


     
    


    


    


    It is however =
my view
that the document in it's current shape is a reasonable capture of rough =
WG
consensus, and that it now is ready for shipping to the =
IESG.
    


    


     
    


    


    /Stefan
    


    


    





------=_NextPart_000_002F_01CDFE4B.5B93AF20--


From denis.pinkas@bull.net  Tue Jan 29 09:57: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 65CC621F89FD for ; Tue, 29 Jan 2013 09:57:39 -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 PLyHavKo9jwx for ; Tue, 29 Jan 2013 09:57:36 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC121F86CC for ; Tue, 29 Jan 2013 09:57:35 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id AF1211CF80 for ; Tue, 29 Jan 2013 18:57: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 2013012918573387-53970 ; Tue, 29 Jan 2013 18:57:33 +0100 
Message-ID: <51080D8A.5000201@bull.net>
Date: Tue, 29 Jan 2013 18:57:30 +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: <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
In-Reply-To: <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 29/01/2013 18:57:34, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 29/01/2013 18:57:34, Serialize complete at 29/01/2013 18:57:34
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="------------000708020103080905080407"
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, 29 Jan 2013 17:57:39 -0000

This is a multi-part message in MIME format.
--------------000708020103080905080407
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I agree that certificateHold should not be used. See explanations below.

However, I disagree with Peter on several points:

        The use of the "unauthorized" error is not the right approach.It 
is changing its semantics.

        It is perfectly possible to use the onhold state when validating 
electronic signature.
        If the certificate is onhold, then the global status for the 
validation of the electronic signature is "unknown".

But since an onhold state MUST NOT stay for ever, some software will 
trying again later on to see whether the certificate is valid or revoked.
Since the semantics of onhold was changed, these application will be 
locked for ever (i.e. will wait for ever unless their code is modified).
This means *this change is not backwards compatible with existing 
implementations*.

In the mean time, some countries do not allow to place a certificate 
onhold, which is also a problem.
This means *this change is not backwards compatible with existing 
legislations.**
*
This is why the use of the reason code notIssuedOrIrregularlyIssued (7) 
is a clean way to solve the problem.

Denis

> Stefan,
>
> I agree with Piyush Jain about the unclear situations for RP with the 
> "revoked" status for non-issued... (probably issued but the record is 
> not in database or the key was compromised).
>
> Especially it is unclear from the liability point of view.
>
> What 2560bis draft 12 is trying to be solved with extension of 
> "revoked" status? :
>
> "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..."
>
> This situation is already covered in standard way as you can see later 
> in my mail when "unauthorized" is returned.
>
> Another problematic part is using the certificateHold in revocations.
>
> The text in 4.4.8 Extended Revoked Definition contains "to allow*audits*  to determine the type of operation by the responder"
>
> As it was many times presented, the usage of the status 
> certificateHold is forbidden in many systems because e.g. in mutual 
> authentications when user SSL/TSL certificate is several times in 
> certificateHold for some reason and then again valid you have not 
> evidence in last CRL or in actual OCSP when in the past was access 
> according to certificateHold of user SSL/TSL certificate forbidden for 
> user. The usage of certificateHold is a killer for audits or 
> validation systems.
>
> You have not evidence why and when in the past some actions were or 
> were not correct.
>
> But can you imagine how you will validate e.g. signatures with 
> signature timestamp when the usage of certificateHold is possible and 
> certificate can be several times in certificateHold. When certificate 
> is in certificateHold then such transaction in that time must not be 
> valid!
>
> For that reason when transactions realized in the past are also 
> important is some resent actions and not only as online actual then 
> PKI must be able to provide evidence and for that reason 
> certificateHold must not be used.
>
> http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
>
> The response "unauthorized" is returned in cases where the client is
>     not authorized to make this query to this server or the server is not
>     capable of responding authoritatively (cf.[RFC5019], Section 2.2.3  ).
>
> http://tools.ietf.org/html/rfc5019#section-2.2.3
>
>
>         2.2.3 .
>         OCSPResponseStatus Values
>
>   
>   
>     As long as the OCSP infrastructure has authoritative records for a
>     particular certificate, an OCSPResponseStatus of "successful" will be
>     returned.  When access to authoritative records for a particular
>     certificate is not available,*the responder MUST return an*
> *    OCSPResponseStatus of "unauthorized".*   As such, this profile extends
>     theRFC 2560    [OCSP  ] definition of "unauthorized" as follows:
>   
>        The response "unauthorized" is returned in cases where the client
>        is not authorized to make this query to this server or the server
>        is not capable of responding authoritatively.
>   
>     For example, OCSP responders that do not have access to authoritative
>     records for a requested certificate, such as those that generate and
>     distribute OCSP responses in advance and thus do not have the ability
>     to properly respond with a signed "successful" yet "unknown"
>     response, will respond with an OCSPResponseStatus of "unauthorized".
>     Also, in order to ensure the database of revocation information does
>     not grow unbounded over time, the responder MAY remove the status
>     records of expired certificates.  Requests from clients for
>     certificates whose record has been removed will result in an
>     OCSPResponseStatus of "unauthorized".
>   
>     Security considerations regarding the use of unsigned responses are
>     discussed in [OCSP  ].
>
> ------------------------------------------------------------------------
>
> *From:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf 
> Of *Stefan Santesson
> *Sent:* Tuesday, January 29, 2013 10:43 AM
> *To:* pkix@ietf.org
> *Subject:* [pkix] 2560bis draft 12 posted
>
> Draft 12 is posted.
>
> This update includes:
>
> - The ASN.1 is consolidated and now contains just one 88 syntax 
> section and one 2002 syntax section. The OCSP module from 5912 has 
> been imported and updated.
>
> - The ASN.1 update includes extension definitions for the no check 
> extension as well as the new extended revoke extension.
>
> - A few minor editorial cleanups
>
> - Added a note in the extended revoke extension section 4.4.8 to 
> clarify that clients do not have to process this extension in order to 
> determine status on certificates.
>
> This document now only lacks the new OIDs for the new ASN.1 modules. 
> As soon as I have them, I will post draft 13.
>
> I know that not everyone is super happy with the result, but on the 
> other hand, that seldom is the case with updates of this kind.
>
> It is however my view that the document in it's current shape is a 
> reasonable capture of rough WG consensus, and that it now is ready for 
> shipping to the IESG.
>
> /Stefan
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


--------------000708020103080905080407
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=ISO-8859-1


  
    
  
  
    
    I agree that certificateHold
should
          not be used. See explanations below.
    
          
    
          However, I disagree with Peter
              on several points:
    
              
    
                     The use of the "unauthorized" error
                is not the right approach.It is changing its semantics.
    
                
    
                       It is perfectly possible to use
                  the onhold state when validating
                    electronic signature.
    
                           If the
                        certificate is onhold, then the
                          global status for the validation of the
                          electronic signature is "unknown".
    
                          
    
                          But since an
                              onhold state MUST NOT
                              stay for ever, some
                                software will trying again later on to
                                see whether the certificate is valid or revoked.
    
                                  Since the semantics of
                                    onhold was changed, these
                                    application will be locked for ever
                                    (i.e. will wait for ever unless
                                    their code is modified).
    
                                    This means this
                                        change is not backwards
                                        compatible with existing
                                        implementations.
    
                                    
    
                                    In the mean time,
                                      some countries do not allow to
                                      place a certificate onhold, which
                                      is also a problem.
    
                                      This
                                                          means this
                                                          change is not
                                                          backwards
                                                          compatible
                                                          with existing
                                                          legislations.
    
                                                          
    
                                                              This is why the use of    
      the reason code notIssuedOrIrregularlyIssued (7) is a clean way to solve
                                      the problem.
    
                                      
    
                                      Denis
    
      
    
    
    
    
    
      
      
      
      
      
    
        
    Stefan,
    
        
     
    
        
    I agree with Piyush Jain about
              the unclear situations for RP with the "revoked" status for
              non-issued …
              (probably issued but the record is not in database or the
              key was compromised).
    
        
    Especially
              it is unclear from
              the liability point of view.
    
        
     
    
        
    What
              2560bis draft 12 is
              trying to be solved with extension of "revoked"
            status? :
    
        
    "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..."
    
        
     
    
        
    This
              situation is already
              covered in standard way as you can see later in my mail
              when "unauthorized" is
            returned.
    
        
     
    
        
    Another
              problematic part
              is using the certificateHold in revocations.
    
        
    The text in 4.4.8 Extended Revoked Definition contains “to allow audits to determine the type of operation by the responder”
    
        
     
    
        
    As
              it was many times presented,
              the usage of the status certificateHold is forbidden in
              many systems because e.g.
              in mutual authentications when user SSL/TSL certificate is
              several times in certificateHold
              for some reason and then again valid you have not evidence
              in last CRL or in actual
              OCSP when in the past was access according to
              certificateHold of user SSL/TSL
              certificate forbidden for user. The usage of
              certificateHold is a killer for
              audits or validation systems.
    
        
    You
              have not evidence why
              and when in the past some actions were or were not
              correct.
    
        
     
    
        
    But
              can you imagine how you
              will validate e.g. signatures with signature timestamp
              when the usage of certificateHold
              is possible and certificate can be several times in
              certificateHold. When
              certificate is in certificateHold then such transaction in
              that time must not
              be valid! 
    
        
    For
              that reason when transactions
              realized in the past are also important is some resent
              actions and not only as
              online actual then PKI must be able to provide evidence
              and for that reason certificateHold
              must not be used. 
    
        
     
    
        
     
    
        
    http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
    
        
    The response "unauthorized" is returned in cases where the client is
    
        
       not authorized to make this query to this server or the server is not
    
        
       capable of responding authoritatively (cf. [RFC5019], Section 2.2.3).
    
        
     
    
        
    http://tools.ietf.org/html/rfc5019#section-2.2.3
    
        
    2.2.3. 
              OCSPResponseStatus Values
    
        
     
    
        
     
    
        
       As long as the OCSP infrastructure has authoritative records for a
    
        
       particular certificate, an OCSPResponseStatus of "successful" will be
    
        
       returned.  When access to authoritative records for a particular
    
        
       certificate is not available, the responder MUST return an
    
        
       OCSPResponseStatus of "unauthorized".  As such, this profile extends
    
        
       the RFC 2560 [OCSP] definition of "unauthorized" as follows:
    
        
     
    
        
          The response "unauthorized" is returned in cases where the client
    
        
          is not authorized to make this query to this server or the server
    
        
          is not capable of responding authoritatively.
    
        
     
    
        
       For example, OCSP responders that do not have access to authoritative
    
        
       records for a requested certificate, such as those that generate and
    
        
       distribute OCSP responses in advance and thus do not have the ability
    
        
       to properly respond with a signed "successful" yet "unknown"
    
        
       response, will respond with an OCSPResponseStatus of "unauthorized".
    
        
       Also, in order to ensure the database of revocation information does
    
        
       not grow unbounded over time, the responder MAY remove the status
    
        
       records of expired certificates.  Requests from clients for
    
        
       certificates whose record has been removed will result in an
    
        
       OCSPResponseStatus of "unauthorized".
    
        
     
    
        
       Security considerations regarding the use of unsigned responses are
    
        
       discussed in [OCSP].
    
        
     
    
        
     
    
        
    
          
    
                
    
              
    
          
    From:
                pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
    
                Sent:
                Tuesday, January 29, 2013
                10:43 AM
    
                To:
                pkix@ietf.org
    
                Subject:
                [pkix] 2560bis draft 12
                posted
    
        
    
        
     
    
        
    
          
    Draft 12 is posted.
    
        
    
        
    
          
     
    
        
    
        
    
          
    This update includes:
    
        
    
        
    
          
    - The ASN.1 is
                consolidated and now contains just one 88 syntax section
                and one 2002 syntax
                section. The OCSP module from 5912 has been imported and
                updated.
    
        
    
        
    
          
    - The ASN.1 update
                includes extension definitions for the no check
                extension as well as the new
                extended revoke extension.
    
        
    
        
    
          
    - A few minor
                editorial cleanups
    
        
    
        
    
          
    - Added a note in the
                extended revoke extension section 4.4.8 to clarify that
                clients do not have to
                process this extension in order to determine status on
                certificates.
    
        
    
        
    
          
     
    
        
    
        
    
          
    This document now only
                lacks the new OIDs for the new ASN.1 modules. As soon as
                I have them, I will
                post draft 13.
    
        
    
        
    
          
     
    
        
    
        
    
          
    I know that not
                everyone is super happy with the result, but on the
                other hand, that seldom is
                the case with updates of this kind.
    
        
    
        
    
          
     
    
        
    
        
    
          
    It is however my view
                that the document in it's current shape is a reasonable
                capture of rough WG
                consensus, and that it now is ready for shipping to the
                IESG.
    
        
    
        
     
    
        
    
          
    /Stefan
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

    
    
    
    
    
  


--------------000708020103080905080407--


From stefan@aaa-sec.com  Tue Jan 29 10:47: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 2AA1121F86CA for ; Tue, 29 Jan 2013 10:47:33 -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 Ru42lMSPMxPA for ; Tue, 29 Jan 2013 10:47:29 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id B178021F869B for ; Tue, 29 Jan 2013 10:47:27 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EC71F1E345F4 for ; Tue, 29 Jan 2013 19:47:25 +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 AuBMl83JxGPN for ; Tue, 29 Jan 2013 19:47:21 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0A53F1E34BBD for ; Tue, 29 Jan 2013 19:47:21 +0100 (CET)
Received: (qmail 39539 invoked from network); 29 Jan 2013 18:47:20 -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 ; 29 Jan 2013 18:47:20 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Tue, 29 Jan 2013 19:47:16 +0100
From: Stefan Santesson 
To: Piyush Jain , 'Denis Pinkas' 
Message-ID: 
Thread-Topic: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
In-Reply-To: <017701cdfe3a$9ce034f0$d6a09ed0$@ditenity.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442333639_672865"
Cc: pkix@ietf.org
Subject: Re: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11
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, 29 Jan 2013 18:47: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_3442333639_672865
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I added some text about this in 4.4.8 as a result of our discussion to make
it clear that clients do not have to parse this extension at all.

/Stefan




From:  Piyush Jain 
Date:  Tuesday, January 29, 2013 5:06 PM
To:  'Denis Pinkas' , Stefan Santesson

Cc:  
Subject:  RE: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

> Just want to clarify.
> =20
> While I agree with Denis that semantics of extended revoked extension are
> equivalent to a revoked response with revocation date set to 1970, it is =
a
> minor issue from my point of view.
> =20
> My bigger concern is the assumption in Stefan=B9s argument that clients do =
not
> need to interpret the meaning of extended revoked except for logging/audi=
ting
> purpose. This assumption is not stated in the document anywhere even thou=
gh
> the document clearly states what extended revoked response looks like and=
 how
> it can be differentiated from a regular revoked response.
> =20
> Assuming that COMPLIANT client implementations will automatically treat
> extended revoked as regular revoked is IMO short sighted. I know that thi=
s
> will work for legacy clients, but is bound to cause confusion for future
> implementations.
> =20
> -Piyush
> =20
>=20
> From: Denis Pinkas [mailto:denis.pinkas@bull.net]
> Sent: Tuesday, January 29, 2013 12:53 AM
> To: Stefan Santesson
> Cc: Piyush Jain; pkix@ietf.org
> Subject: Re: [pkix] Responder trust issue for non-issued certificates not
> addressed in 2560 bis draft 11
> =20
>=20
> Stefan,
>=20
> The discussion is now days and nights since we have participants from aro=
und
> the world.
> I have not yet started to review your answers to my comments, but in the =
mean
> time I took a look
> at the numerous messages that have been exchanged.
>=20
> You said: "My personal preference would be to not define this extension a=
t
> all",=20
>=20
> Piyush does not want it either.
>=20
> I don't think it is needed either.
>=20
> Since the revocation date is set to January, 1rst 1970, I can't imagine t=
oday
> another real use case where we would have that date.
> So checking this value is entirely sufficient to know that the certificat=
e
> serial number has not been used to the knowledge of the CA.
>=20
> So we are at least three persons who believe that we should not define th=
at
> extension.
>=20
> Now, if some other persons can demonstrate that this extension is really
> needed, then it is time for them to speak up.
>=20
> Denis
>=20
>> Piyush,
>> =20
>> On 1/28/13 10:09 PM, "Piyush Jain" 
>>   wrote:
>> =20
>>> Stefan,
>>> =20
>>> Clearly we have disagreement on how this issue is addressed in current
>>> draft. =20
>>> I'm actually surprised at your statement that clients should not
>>> differentiate between non-issued and revoked certs, given that the draf=
t
>>> mandates that servers include extended revoked extension if it  is
>>> changing
>>> the meaning of revoked. If it is so, why bloat the response with this
>>> extension at all.
>> =20
>> As it has been stated here before, and also communicated in the minutes =
of
>> the last PKIX meeting in Atlanta, the rationale behind including this
>> extension is to allow audits.
>> If something goes wrong and you go through the records, there will be
>> evidence that the responder that provided a particular response of
>> interest, supported this functionality.
>> =20
>> No client is required to understand this extension or to do anything wit=
h
>> it to function properly.
>> My personal preference would be to not define this extension at all, but
>> having this extension is so far WG rough consensus and hence it is
>> included in the draft.
>> Enough people feel strongly about it and it does no damage to have it
>> there.
>> =20
>> /Stefan
>> =20
>> =20
>>> =20
>>> So far, besides you and me, Peter Rybar is the only one who has referre=
d
>>> to
>>> this issue in one of his posts, acknowledging that it exists.
>>> I hope we have opinions of a few others folks before we decide one way =
or
>>> other.
>>> =20
>>> -Piyush
>>> =20
>>>> -----Original Message-----
>>>> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>>>> Sent: Monday, January 28, 2013 12:25 PM
>>>> To: Piyush Jain; pkix@ietf.org
>>>> Subject: Re: [pkix] Responder trust issue for non-issued certificates
>>>> not
>>>> addressed in 2560 bis draft 11
>>>> =20
>>>> =20
>>>> =20
>>>> On 1/28/13 7:09 PM, "Piyush Jain" 
>>>>   wrote:
>>>> =20
>>>>> You said
>>>>>> "It's quite easy. If they trust the responder, they are supposed to
>>>>>> trust
>>>>> the response.
>>>>>> If they have not established the trust described above, they MUST
>>>>>> reject
>>>>> the response.
>>>>>> This has nothing to do with what responses they get."
>>>>> =20
>>>>> I disagree with this statement. The document clearly states that
>>>>> contents of responses should be looked at before accepting the
>>>>> response. This includes looking at signature and certid contained in
>>>>> the response.
>>>> =20
>>>> Of course, I didn't say it because its central and kind of obvious.
>>>> =20
>>>>> =20
>>>>> Not-issued response is something that is introduced in this draft
>>>> =20
>>>> No, look closer. The draft does NOT define a "not-issued" response. It
>>> allows
>>>> the "revoked" response if a certificate serial number has never been
>>> issued.
>>>> That is two entirely different things.
>>>> =20
>>>> =20
>>>>> and the
>>>>> current discussion is about how the client establishes trust in such =
a
>>>>> response.
>>>> =20
>>>> As it would with any other response.
>>>> =20
>>>>> =20
>>>>>> If you ask how to deal with the response, then the client will not
>>>>>> get a
>>>>> non- issued response. It will get a "revoked" status.
>>>>>> This indicates that the certificate they asked about should not be
>>>>> trusted.
>>>>> =20
>>>>> I was under the impression that syntax of 'revoked' is only being use=
d
>>>>> for backward compatibility. And that revocation date-1970 in
>>>>> conjunction with revocation status onhold implies that certificate is
>>> not-
>>>> issued.
>>>> =20
>>>> No. The meaning is just to allow the server to provide a response that
>>>> has
>>>> the likely outcome that the client will not use that cert, if there ev=
en
>>> is such a
>>>> cert and the request isn't simply an error.
>>>> =20
>>>> =20
>>>>> Also the
>>>>> new extended revoked extension implies that certificate is not-issued=
.
>>>>> Are you now arguing that 'revoked' and 'not-issued' should be
>>>>> semantically equivalent as well?
>>>> =20
>>>> No, the extension signals that the server supports this extended use o=
f
>>>> revoked. It says nothing about whether it is used for any of the certs
>>>> in
>>> a
>>>> particular response.
>>>> =20
>>>> =20
>>>>> =20
>>>>> Finally, here is a point regarding providing guidance to clients.
>>>>> Non-issued response is a new state that is being introduced in this
>>>>> update.
>>>> =20
>>>> This is getting tiresome. No, there is no new state. There is an
>>>> extended
>>> use
>>>> of "revoked".
>>>> =20
>>>>> The only reason revoked is being overloaded is to maintain backward
>>>>> compatibility with existing clients. However, to assume that future
>>>>> clients won't try to interpret the meaning of extended revoked
>>>>> extension is short-sighted. Avoiding guidelines on how clients deal
>>>>> with it is bound to cause confusion for anyone who uses this RFC  to
>>>>> implement a OCSP client.
>>>> =20
>>>> No, all may experience with PKI development suggests contrary to your
>>>> prediction.
>>>> However, if we tried to craft some extensive guidance on how to try to
>>>> detect and mitigate CA compromise, that will definitely cause confusio=
n
>>> and
>>>> make implementers think they have to deal with this.
>>>> =20
>>>> =20
>>>>> The fact is that in absence of such guidelines, clients would probabl=
y
>>>>> continue to trust a responder that is issued by a CA which is
>>>>> compromised (level of compromise is irrelevant here).
>>>> =20
>>>> Which is exactly what we expect them to do. It is not the clients task
>>>> to
>>> spot
>>>> and correct the problem of compromised CAs.
>>>> That is the task of trust service providers and the controls they put =
in
>>> place.
>>>> =20
>>>> =20
>>>>> At the minimum, we should clarify
>>>>> the implications so clients can make informed choices.  I repeat that
>>>>> failing to do so is violation of RFC 2418.
>>>> =20
>>>> No. Security considerations requires you to discuss security issues
>>> introduced
>>>> by a protocol.
>>>> The added mechanism does not introduce any new security vulnerabilitie=
s
>>>> that you have pointed out.
>>>> To the contrary.
>>>> =20
>>>> /Stefan
>>>> =20
>>> =20
>>> =20
>>> _______________________________________________
>>> 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



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


    I added some text about this=
 in 4.4.8 as a result of our discussion to make it clear that clients do not=
 have to parse this extension at all.

    /Stefan
    =





    From:  Piyush Jain <piyush@ditenity.com>
    Date:  Tuesday, January 29, 2013 5:06 PM
    To: <=
/span> 'Denis Pinkas' <denis.pinka=
s@bull.net>, Stefan Santesson <stefan@aaa-sec.com>
    Cc:  &l=
t;pkix@ietf.org>
    Subject:  RE: [pkix] Responder trust issue for non-issue=
d certificates not addressed in 2560 bis draft 11

    Just want to clarify.
     
    Whi=
le I agree with Denis that semantics of extended revoked extension are equiv=
alent to a revoked response with revocation date set to 1970, it is a minor =
issue from my point of view.
     
    My=
 bigger concern is the assumption in Stefan’s argument that clients do=
 not need to interpret the meaning of extended revoked except for logging/au=
diting purpose. This assumption is not stated in the document anywhere even =
though the document clearly states what extended revoked response looks like=
 and how it can be differentiated from a regular revoked response.
     
    =

    Assuming that COMPLIANT client implement=
ations will automatically treat extended revoked as regular revoked is IMO s=
hort sighted. I know that this will work for legacy clients, but is bound to=
 cause confusion for future implementations.
     
    <=
span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31=
, 73, 125); ">-Piyush
     Denis Pinkas [mailto:denis.pinkas@bull.net] 
    Sent: Tuesday, January 29, =
2013 12:53 AM
    To: Stefan Santesson
    Cc: Piyush Jain; pkix@ietf.org
    Subject: Re: [pkix] R=
esponder trust issue for non-issued certificates not addressed in 2560 bis d=
raft 11
     
    Stefan,
    The discussion is now days and nights since we have participants from aroun=
d the world.
    I have not yet started to review your answers to my comments=
, but in the mean time I took a look 
    at the numerous messages that have =
been exchanged.

    You said: "My personal preference would be to not def=
ine this extension at all", 

    Piyush does not want it either.

    I=
 don't think it is needed either.

    Since the revocation date is set to=
 January, 1rst 1970, I can't imagine today another real use case wher=
e we would have that date.
    So checking this value is entirely sufficient =
to know that the certificate serial number has not been used to the knowledg=
e of the CA.

    So we are at least three persons who believe that we sho=
uld not define that extension.

    Now, if some other persons can demonst=
rate that this extension is really needed, then it is time for them to speak=
 up.

    Denis

    Piyush,
     
    On 1/28/13 10:09 PM, "Piyush Jain" <piyush@ditenity.com> wrote:
    &n=
bsp;
    Stefan,
     
    Clearly we have d=
isagreement on how this issue is addressed in current
    d=
raft.  
    I'm actually surprised at your statement t=
hat clients should not
    differentiate between non-issued=
 and revoked certs, given that the draft
    mandates that =
servers include extended revoked extension if it  is
    changing
    the meaning of revoked. If it is so, why bl=
oat the response with this
    extension at all.=

     
    As it has been stated he=
re before, and also communicated in the minutes of
    the =
last PKIX meeting in Atlanta, the rationale behind including this=

    extension is to allow audits.
    If something g=
oes wrong and you go through the records, there will be
    evidence that the responder that provided a particular response of
    interest, supported this functionality.
     
    No client is required to understand this extension=
 or to do anything with
    it to function properly.
    My personal preference would be to not define this extension =
at all, but
    having this extension is so far WG rough co=
nsensus and hence it is
    included in the draft.
    Enough people feel strongly about it and it does no damage to h=
ave it
    there.
     
    /Stefan
     
     =

     
    So far, besides you and me, Peter Rybar is the onl=
y one who has referred
    to
    this iss=
ue in one of his posts, acknowledging that it exists.
    I=
 hope we have opinions of a few others folks before we decide one way or
    other.
     
    -P=
iyush
     
    -----Original Message-----
    From: Stefan Santesson [mailto:s=
tefan@aaa-sec.com]
    Sent: Monday, January 28, 2013 1=
2:25 PM
    To: Piyush Jain; pkix@ietf.org
    Subject: Re: [pkix] Responder trust =
issue for non-issued certificates
    not
    <=
pre>addressed in 2560 bis draft 11
     
     
     
    On 1/28/13 7=
:09 PM, "Piyush Jain" <piyush@diteni=
ty.com> wrote:
     
    You said
    "It's quite e=
asy. If they trust the responder, they are supposed to
    =
trust
    the response.
    If they have not est=
ablished the trust described above, they MUST
    reject
    the response.
    This has nothing to do with =
what responses they get."
     
    I disagree with this statement. The document clearly states that=

    contents of responses should be looked at before accep=
ting the
    response. This includes looking at signature a=
nd certid contained in
    the response.
     
    Of course, I didn't say it becau=
se its central and kind of obvious.
     
     =
;
    Not-issued response is something that is introduced in thi=
s draft
     
    No, lo=
ok closer. The draft does NOT define a "not-issued" response. It<=
/pre>
    allows
    the "revoked" response if a certificate seri=
al number has never been
    issued.
    That is=
 two entirely different things.
     
    =

     
    and the
    current discussion is about how t=
he client establishes trust in such a
    response.
     
    As it would with any =
other response.
     
     
    If you ask how to dea=
l with the response, then the client will not
    get a
    non- issued response. It will get a "revoked"=
 status.
    This indicates that the certificate they asked about should not b=
e
    trusted.
     =
;
    I was under the impression that syntax of 'revoked' is onl=
y being used
    for backward compatibility. And that revoc=
ation date-1970 in
    conjunction with revocation status o=
nhold implies that certificate is
    =

    not-
    issued.
     
    No. The=
 meaning is just to allow the server to provide a response that
    has
    the likely outcome that the client will no=
t use that cert, if there even
    is such a
    cert and the request isn't simply an error.
     =
;
     
    Also the
    new extended revoke=
d extension implies that certificate is not-issued.
    Are=
 you now arguing that 'revoked' and 'not-issued' should be
    <=
pre>semantically equivalent as well?
    =
 
    No, the extension signals that the server supports th=
is extended use of
    revoked. It says nothing about wheth=
er it is used for any of the certs
    in
    <=
/blockquote>
    a
    particular response.
     
     
     
    Finally, here is a point=
 regarding providing guidance to clients.
    Non-issued re=
sponse is a new state that is being introduced in this
    =
update.
     
    This i=
s getting tiresome. No, there is no new state. There is an
    <=
pre>extended
    use
    of "revoked".
     
    The only reason revoked is being overloaded is to maint=
ain backward
    compatibility with existing clients. Howev=
er, to assume that future
    clients won't try to interpre=
t the meaning of extended revoked
    extension is short-si=
ghted. Avoiding guidelines on how clients deal
    with it =
is bound to cause confusion for anyone who uses this RFC  to=

    implement a OCSP client.
    &=
nbsp;
    No, all may experience with PKI development suggests c=
ontrary to your
    prediction.
    Howeve=
r, if we tried to craft some extensive guidance on how to try to<=
/pre>
    detect and mitigate CA compromise, that will definitely cause conf=
usion
    and
    make implementers think they h=
ave to deal with this.
     
     
    =

    The fact is that in absence of such guidelines, clients would probably<=
o:p>
    continue to trust a responder that is issued by a CA wh=
ich is
    compromised (level of compromise is irrelevant h=
ere).
     
    Which is=
 exactly what we expect them to do. It is not the clients task
    to
    spot
    and correct the problem =
of compromised CAs.
    That is the task of trust service p=
roviders and the controls they put in
    plac=
e.
    =

     
     
    At the minimum, we should clarify<=
o:p>
    the implications so clients can make informed choices.&=
nbsp; I repeat that
    failing to do so is violation of RF=
C 2418.
     
    No. Se=
curity considerations requires you to discuss security issues
    introduced
    by a protocol.
    The add=
ed mechanism does not introduce any new security vulnerabilities<=
/pre>
    that you have pointed out.
    To the contrary.
     
    /Stefan
     
     
    &=
nbsp;
    _______________________________________________
    pkix mailing list
    pkix@ietf.org
    https://www.ietf.org/mailman/listinfo/pkix=

     
     <=
/pre>
    _______________________________________________
    pkix mailing list
    pki=
x@ietf.org
    https://www.ietf.org/mailman/listinfo/pkix
    =

     
    

--B_3442333639_672865--



From mrex@sap.com  Tue Jan 29 16:25:56 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 1D28D21F8837 for ; Tue, 29 Jan 2013 16:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 McFGzQSWRrnp for ; Tue, 29 Jan 2013 16:25:55 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19E21F87BB for ; Tue, 29 Jan 2013 16:25:55 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0U0PkjK009588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jan 2013 01:25:47 +0100 (MET)
In-Reply-To: <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
To: Peter Rybar 
Date: Wed, 30 Jan 2013 01:25:46 +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: <20130130002546.D4D2A1A4BA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: 'Stefan Santesson' , 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: Wed, 30 Jan 2013 00:25:56 -0000

Peter Rybar wrote:
> 
> This situation is already covered in standard way as you can see later
> in my mail when "unauthorized" is returned.

That is a misunderstanding based on a defective document.


> 
> http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
> 
>    The response "unauthorized" is returned in cases where the client is
>    not authorized to make this query to this server or the server is not
>    capable of responding authoritatively (cf. [RFC5019],
>    Section   2.2.3).
 

It's the first time that I see that idea.  IMO it is a pretty bad idea.
As you may note, rfc5019 does not claim to update rfc2560, and so
it does not do that.  The quoted re-interpretation is also in serious
conflict with the original definition/meanding of "unauthorized".

>From how the error codes are defined in rfc2560
  http://tools.ietf.org/html/rfc2560#section-2.3


2.3  Exception Cases

   In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.


Unauthorized means that the client is not authorized to use the service,
and a reasonable client will use such a response to blacklist an
OCSP responder and *NEVER* ask it again for anything.

An OCSP server that uses "unauthorized" in the extended fashion of
rfc5019 or the way that you suggest, is FULLY BROKEN on my scorecard.

-Martin

From mrex@sap.com  Tue Jan 29 16:54: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 193EE21F870E for ; Tue, 29 Jan 2013 16:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kDeydZfH5O4r for ; Tue, 29 Jan 2013 16:54:54 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2198521F8727 for ; Tue, 29 Jan 2013 16:54:52 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0U0sp4u016210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jan 2013 01:54:51 +0100 (MET)
In-Reply-To: <20130130002546.D4D2A1A4BA@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Wed, 30 Jan 2013 01:54:51 +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: <20130130005451.374861A4BA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: 'Stefan Santesson' , 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: Wed, 30 Jan 2013 00:54:57 -0000

Martin Rex wrote:
> 
> That is a misunderstanding based on a defective document.
> 
> > 
> > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
> > 
> >    The response "unauthorized" is returned in cases where the client is
> >    not authorized to make this query to this server or the server is not
> >    capable of responding authoritatively (cf. [RFC5019],
> >    Section   2.2.3).
>  
> 
> It's the first time that I see that idea.  IMO it is a pretty bad idea.
> As you may note, rfc5019 does not claim to update rfc2560, and so
> it does not do that.  The quoted re-interpretation is also in serious
> conflict with the original definition/meanding of "unauthorized".


Sorry for not having noticed this goof earlier.

The "unauthorized" response of rfc2560 means

"this is not a public service, and your OCSP request is outside of
 our terms-of-service.  Go away."

This typically also means, that the OCSP responder probably did not
even look at the contents on the request at all, but decided only based
on the clients signature or the client's network address.


Ignoring "terms of service" of a Server that is accessed via the
internet, is a pretty bad idea, because in some jurisdication this
can currently be artificially inflated to be a felony.


While I agree that OCSP wasn't designed with a lot of thought about
extensibility (with respect to cert status an exceptions),
retroactively misappropiating an "unauthorized" response in the
fashion of 5019 looks like a very bad idea to me.


-Martin

From piyush@ditenity.com  Tue Jan 29 16:56:56 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 D005721F874E for ; Tue, 29 Jan 2013 16:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XECDypjApPKK for ; Tue, 29 Jan 2013 16:56:55 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8938821F8717 for ; Tue, 29 Jan 2013 16:56:55 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id o6so1159830oag.32 for ; Tue, 29 Jan 2013 16:56:55 -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=64zd5REYAFf73l29e5KUsoMjLUGCQ6HEZtbpzGxA6Cs=; b=kQ0wODsnPCW5/Cqie8iPnuo3w94ltkZviuggcmtlHrGbe89k49BjN6fSkyKL6pnCQ/ K+DI8kLkOFoN6PYhuogGRO3QTBXpnCUa4KCo1y1FcvHmmjPh5nVN+yv9ORDuvler2WVo HbvHaux5w5SQKWTtstANU/rmjBsJt0mgh1X9otwXPZrP0hRbdTjdezyi25hpyxvG+yNy RZKP33Fa6d55h2YUzrguh564gJ/BnDsN/cvYrGzYJ7M4mGmLnUIWg+7Q7/DGYyxh51RY w3z9Srnw7a/9dSj3fNY0Ha1U+ZV0vWeW3atcr8M/vynxGR5vmU6sixpeh07sb0p3Ypmd 8sSQ==
X-Received: by 10.60.1.168 with SMTP id 8mr2358029oen.46.1359507415023; Tue, 29 Jan 2013 16:56:55 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v8sm12211939obj.1.2013.01.29.16.56.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 16:56:54 -0800 (PST)
From: "Piyush Jain" 
To: "'Peter Rybar'" , "'Stefan Santesson'" , 
References:  <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
In-Reply-To: <201301291706.r0TH6Ecp026364@mail.nbusr.sk>
Date: Tue, 29 Jan 2013 16:56:51 -0800
Message-ID: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028C_01CDFE41.A3C70170"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKyQGa62Ea2VkSON2yzklD5I9k8qZaYhHVg
Content-Language: en-us
X-Gm-Message-State: ALoCoQmWvaJSdGir/LkSOSUx1BOikYBd3oHr6eJWOZu14SSzkhK4qfEXHawZRr/8TFwf20no1yKO
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: Wed, 30 Jan 2013 00:56:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_028C_01CDFE41.A3C70170
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

That is an interesting catch Peter.

So another implication of adopting revoked for non-issued is that it =
breaks compliance with 5019.

=20

I=E2=80=99m wondering if it makes sense to list these implications in a =
different RFC, so CA responders can make an informed choice about =
adopting revoked for non-issued.

So far I have

-          Ambiguity in responder trust model for such responses

-          Inability to perform pre-signing.

-          Breaking compliance with 5019

-          Incompatibility with legislations that prohibit use of onHold

=20

=20

-Piyush

=20

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Peter Rybar
Sent: Tuesday, January 29, 2013 9:06 AM
To: 'Stefan Santesson'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

=20

Stefan,

=20

I agree with Piyush Jain about the unclear situations for RP with the =
"revoked" status for non-issued =E2=80=A6 (probably issued but the =
record is not in database or the key was compromised).

Especially it is unclear from the liability point of view.

=20

What 2560bis draft 12 is trying to be solved with extension of "revoked" =
status? :

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

=20

This situation is already covered in standard way as you can see later =
in my mail when "unauthorized" is returned.

=20

Another problematic part is using the certificateHold in revocations.

The text in 4.4.8 Extended Revoked Definition contains =E2=80=9Cto allow =
audits to determine the type of operation by the responder=E2=80=9D

=20

As it was many times presented, the usage of the status certificateHold =
is forbidden in many systems because e.g. in mutual authentications when =
user SSL/TSL certificate is several times in certificateHold for some =
reason and then again valid you have not evidence in last CRL or in =
actual OCSP when in the past was access according to certificateHold of =
user SSL/TSL certificate forbidden for user. The usage of =
certificateHold is a killer for audits or validation systems.

You have not evidence why and when in the past some actions were or were =
not correct.

=20

But can you imagine how you will validate e.g. signatures with signature =
timestamp when the usage of certificateHold is possible and certificate =
can be several times in certificateHold. When certificate is in =
certificateHold then such transaction in that time must not be valid!=20

For that reason when transactions realized in the past are also =
important is some resent actions and not only as online actual then PKI =
must be able to provide evidence and for that reason certificateHold =
must not be used.=20

=20

=20

http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12

The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server or the server is not
   capable of responding authoritatively (cf. [RFC5019], Section =
  2.2.3).

=20

http://tools.ietf.org/html/rfc5019#section-2.2.3


  2.2.3.  =
OCSPResponseStatus Values

=20
=20
   As long as the OCSP infrastructure has authoritative records for a
   particular certificate, an OCSPResponseStatus of "successful" will be
   returned.  When access to authoritative records for a particular
   certificate is not available, the responder MUST return an
   OCSPResponseStatus of "unauthorized".  As such, this profile extends
   the RFC 2560   [OCSP =
 ] definition of =
"unauthorized" as follows:
=20
      The response "unauthorized" is returned in cases where the client
      is not authorized to make this query to this server or the server
      is not capable of responding authoritatively.
=20
   For example, OCSP responders that do not have access to authoritative
   records for a requested certificate, such as those that generate and
   distribute OCSP responses in advance and thus do not have the ability
   to properly respond with a signed "successful" yet "unknown"
   response, will respond with an OCSPResponseStatus of "unauthorized".
   Also, in order to ensure the database of revocation information does
   not grow unbounded over time, the responder MAY remove the status
   records of expired certificates.  Requests from clients for
   certificates whose record has been removed will result in an
   OCSPResponseStatus of "unauthorized".
=20
   Security considerations regarding the use of unsigned responses are
   discussed in [OCSP  ].

=20

=20

  _____ =20

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Stefan Santesson
Sent: Tuesday, January 29, 2013 10:43 AM
To: pkix@ietf.org
Subject: [pkix] 2560bis draft 12 posted

=20

Draft 12 is posted.

=20

This update includes:

- The ASN.1 is consolidated and now contains just one 88 syntax section =
and one 2002 syntax section. The OCSP module from 5912 has been imported =
and updated.

- The ASN.1 update includes extension definitions for the no check =
extension as well as the new extended revoke extension.

- A few minor editorial cleanups

- Added a note in the extended revoke extension section 4.4.8 to clarify =
that clients do not have to process this extension in order to determine =
status on certificates.

=20

This document now only lacks the new OIDs for the new ASN.1 modules. As =
soon as I have them, I will post draft 13.

=20

I know that not everyone is super happy with the result, but on the =
other hand, that seldom is the case with updates of this kind.

=20

It is however my view that the document in it's current shape is a =
reasonable capture of rough WG consensus, and that it now is ready for =
shipping to the IESG.

=20

/Stefan


------=_NextPart_000_028C_01CDFE41.A3C70170
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


    That is an interesting catch Peter.
    So another implication of adopting revoked for non-issued is that it =
breaks compliance with 5019.
     
    I=E2=80=99m wondering if it makes sense to list these implications in =
a different RFC, so CA responders can make an informed choice about =
adopting revoked for non-issued.
    So far I have
    -          =
Ambiguity in responder trust model for such =
responses
    -          =
Inability to perform pre-signing.
    -          =
Breaking compliance with 5019
    -          =
Incompatibility with legislations that prohibit use of =
onHold
     
     
    -Piyush
     
    From:=
 =
pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Peter Rybar
    Sent: Tuesday, January 29, 2013 9:06 =
AM
    To: 'Stefan Santesson'; pkix@ietf.org
    Subject: =
Re: [pkix] 2560bis draft 12 posted
     
    St=
efan,
     
    I =
agree with Piyush Jain about the unclear situations for RP with =
the "revoked" status for =
non-issued =E2=80=A6 =
(probably issued but the record is not in database or the key was =
compromised).
    Especially =
it is unclear from the liability point of view.
     
    What 2560bis =
draft 12 is trying to be solved with extension of =
"revoked" status? :
    "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..."
     
    This =
situation is already covered in standard way as you can see later in my =
mail when "unauthorized" is returned.<=
/span>
     
    Another =
problematic part is using the certificateHold in =
revocations.
    The text in 4.4.8 Extended =
Revoked Definition contains =E2=80=9Cto allow audits to =
determine the type of operation by the responder=E2=80=9D
     
    As it was =
many times presented, the usage of the status certificateHold is =
forbidden in many systems because e.g. in mutual authentications when =
user SSL/TSL certificate is several times in certificateHold for some =
reason and then again valid you have not evidence in last CRL or in =
actual OCSP when in the past was access according to certificateHold of =
user SSL/TSL certificate forbidden for user. The usage of =
certificateHold is a killer for audits or validation =
systems.
    You have not =
evidence why and when in the past some actions were or were not =
correct.
     
    But can you =
imagine how you will validate e.g. signatures with signature timestamp =
when the usage of certificateHold is possible and certificate can be =
several times in certificateHold. When certificate is in certificateHold =
then such transaction in that time must not be valid! =

    For that =
reason when transactions realized in the past are also important is some =
resent actions and not only as online actual then PKI must be able to =
provide evidence and for that reason certificateHold must not be used. =

     
     
    http://=
tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12
    The response "unauthorized" is returned in cases where =
the client is
       not authorized to make =
this query to this server or the server is =
not
       capable of responding =
authoritatively (cf. [RFC5019], =
Section 2.2.3).
     
    http://tools.ie=
tf.org/html/rfc5019#section-2.2.3
    2.2.3.  OCSPResponseStatus =
Values
     
     =

       As long as the OCSP infrastructure has =
authoritative records for a
       particular =
certificate, an OCSPResponseStatus of "successful" will =
be
       returned.  When access to =
authoritative records for a particular
       =
certificate is not available, the responder =
MUST return an
       OCSPResponseStatus of =
"unauthorized".  As such, this profile =
extends
       the RFC 2560 [OCSP] definition of =
"unauthorized" as =
follows:
     
      &nb=
sp;   The response "unauthorized" is returned in =
cases where the =
client
          is not =
authorized to make this query to this server or the =
server
          is not =
capable of responding =
authoritatively.
     
     &=
nbsp; For example, OCSP responders that do not have access to =
authoritative
       records for a requested =
certificate, such as those that generate =
and
       distribute OCSP responses in =
advance and thus do not have the =
ability
       to properly respond with a =
signed "successful" yet =
"unknown"
       response, will =
respond with an OCSPResponseStatus of =
"unauthorized".
       Also, in =
order to ensure the database of revocation information =
does
       not grow unbounded over time, the =
responder MAY remove the status
       =
records of expired certificates.  Requests from clients =
for
       certificates whose record has been =
removed will result in an
       =
OCSPResponseStatus of =
"unauthorized".
     
       Security considerations regarding the use of unsigned =
responses are
       discussed in [OCSP].
     
     
    From:=
 =
pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Stefan Santesson
    Sent: Tuesday, January 29, 2013 10:43 =
AM
    To: pkix@ietf.org
    Subject: [pkix] 2560bis draft =
12 posted
     
    Draft 12 is posted.
     
    This update includes:
    - The ASN.1 is consolidated and now contains just one 88 syntax section =
and one 2002 syntax section. The OCSP module from 5912 has been imported =
and updated.
    - The ASN.1 update includes extension definitions for the no check =
extension as well as the new extended revoke =
extension.
    - A few minor editorial cleanups
    - Added a note in the extended revoke extension section 4.4.8 to =
clarify that clients do not have to process this extension in order to =
determine status on certificates.
     
    This document now only lacks the new OIDs for the new ASN.1 modules. As =
soon as I have them, I will post draft =
13.
     
    I know that not everyone is super happy with the result, but on the =
other hand, that seldom is the case with updates of this =
kind.
     
    It is however my view that the document in it's current shape is a =
reasonable capture of rough WG consensus, and that it now is ready for =
shipping to the IESG.
     
    /Stefan
    
------=_NextPart_000_028C_01CDFE41.A3C70170--


From mrex@sap.com  Tue Jan 29 17:25: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 11DB421F8837 for ; Tue, 29 Jan 2013 17:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 G-GJomUNZwwZ for ; Tue, 29 Jan 2013 17:25:31 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1421F848B for ; Tue, 29 Jan 2013 17:25:30 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0U1PMk5021784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jan 2013 02:25:22 +0100 (MET)
In-Reply-To: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>
To: Piyush Jain 
Date: Wed, 30 Jan 2013 02:25:22 +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: <20130130012522.5DEEB1A4BA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: 'Stefan Santesson' , 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: Wed, 30 Jan 2013 01:25:32 -0000

Piyush Jain wrote:
> 
> I'm wondering if it makes sense to list these implications in a
> different RFC, so CA responders can make an informed choice about
> adopting revoked for non-issued.
> 
> So far I have
> 
> -          Ambiguity in responder trust model for such responses

That is a purely philosophical concept, not a technical one.


> 
> -          Inability to perform pre-signing.

This is a clear misunderstanding.  You can still pre-sign responses for
all existing and revoked certs just like with rfc2560.


> 
> -          Breaking compliance with 5019

with respect to the abuse of "unauthorized", 5019 itself is seriously broken.


> 
> -          Incompatibility with legislations that prohibit use of onHold

That is complete and utter non-sense (as I've previously explained),
any such prohibition for "onHold" can not apply to not-issued cert serials.

However expecting OCSP clients to continue talking to an OCSP responder
that returned "unauthorized" will make you liable under the current
US CFAA crminial statute, that breakage of 5019 should be much more
of a concern for folks that are sensitive to legal issues.



-Martin

From James.H.Manger@team.telstra.com  Tue Jan 29 18:35: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 CE2CF21F8442 for ; Tue, 29 Jan 2013 18:35:12 -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 OcGBVIJDx+OE for ; Tue, 29 Jan 2013 18:35:12 -0800 (PST)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7A21F843B for ; Tue, 29 Jan 2013 18:35:11 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,565,1355058000"; d="scan'208";a="111922895"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 30 Jan 2013 13:35:09 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6970"; a="110044206"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 30 Jan 2013 13:35:09 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 30 Jan 2013 13:35:08 +1100
From: "Manger, James H" 
To: "pkix@ietf.org" 
Date: Wed, 30 Jan 2013 13:35:07 +1100
Thread-Topic: [pkix] 2560bis draft 12 posted
Thread-Index: AQKyQGa62Ea2VkSON2yzklD5I9k8qZaYhHVggAAbTDA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E115068D7E08@WSMSG3153V.srv.dir.telstra.com>
References:  <201301291706.r0TH6Ecp026364@mail.nbusr.sk> <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>
In-Reply-To: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>
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] 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: Wed, 30 Jan 2013 02:35:12 -0000

W1JGQyA1MDE5ICJMaWdodHdlaWdodCBPQ1NQIFByb2ZpbGUiLCBzZWN0aW9uIDIuMi4zLiIgT0NT
UFJlc3BvbnNlU3RhdHVzIFZhbHVlcyJdDQoNCj4+IFdoZW4gYWNjZXNzIHRvIGF1dGhvcml0YXRp
dmUgcmVjb3JkcyBmb3IgYSBwYXJ0aWN1bGFyDQo+PiBjZXJ0aWZpY2F0ZSBpcyBub3QgYXZhaWxh
YmxlLCB0aGUgcmVzcG9uZGVyIE1VU1QgcmV0dXJuIGFuDQo+PiBPQ1NQUmVzcG9uc2VTdGF0dXMg
b2YgInVuYXV0aG9yaXplZCIuDQo+PiAuLi4NCj4+ICBUaGUgcmVzcG9uc2UgInVuYXV0aG9yaXpl
ZCIgaXMgcmV0dXJuZWQgaW4gY2FzZXMgd2hlcmUgdGhlIGNsaWVudA0KPj4gIGlzIG5vdCBhdXRo
b3JpemVkIHRvIG1ha2UgdGhpcyBxdWVyeSB0byB0aGlzIHNlcnZlciBvciB0aGUgc2VydmVyDQo+
PiAgaXMgbm90IGNhcGFibGUgb2YgcmVzcG9uZGluZyBhdXRob3JpdGF0aXZlbHkuDQoNCg0KVGhl
IDI1NjBiaXMgdXBkYXRlIGRvZXNuJ3QgY2xhc2ggd2l0aCBSRkM1MDE5IGhlcmUuDQpBIHNlcnZl
ciB3aXRoIGEgbGlzdCBvZiBhbGwga25vd24tZ29vZCBjZXJ0IHNlcmlhbCBudW1iZXJzIElTIGNh
cGFibGUgb2YgcmVzcG9uZGluZyBhdXRob3JpdGF0aXZlbHkuIEl0IGF1dGhvcml0YXRpdmVseSBr
bm93cyB0aGVyZSBpcyBubyByZWNvcmRzIGZvciBhbnkgIm5vbi1pc3N1ZWQiIHNlcmlhbCBudW1i
ZXIgaXQgaXMgYXNrZWQgYWJvdXQgLS0gdGhlcmUgaXMgbm8gYWNjZXNzIHRoYXQgaXQgbGFja3Mu
IFNvIHRoZSBSRkM1MDE5IHVzZSBvZiAidW5hdXRob3JpemVkIiBkb2VzIG5vdCBhcHBseS4NCg0K
LS0NCkphbWVzIE1hbmdlcg0K

From stefan@aaa-sec.com  Tue Jan 29 20:53: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 C7E5321F8ADB for ; Tue, 29 Jan 2013 20:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.463
X-Spam-Level: 
X-Spam-Status: No, score=-101.463 tagged_above=-999 required=5 tests=[AWL=-0.611, 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 M3aQ3hZ6FiXh for ; Tue, 29 Jan 2013 20:53:54 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8294121F8540 for ; Tue, 29 Jan 2013 20:53:53 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 890862DE2FD for ; Wed, 30 Jan 2013 05:53:07 +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 0T9GyWm_Q8XQ for ; Wed, 30 Jan 2013 05:53:06 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 63FF22DE308 for ; Wed, 30 Jan 2013 05:53:06 +0100 (CET)
Received: (qmail 29411 invoked from network); 30 Jan 2013 04:53: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 ; 30 Jan 2013 04:53:05 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Wed, 30 Jan 2013 05:53:02 +0100
From: Stefan Santesson 
To: Piyush Jain , 'Peter Rybar' , 
Message-ID: 
Thread-Topic: [pkix] 2560bis draft 12 posted
In-Reply-To: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442369986_1517994"
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: Wed, 30 Jan 2013 04:53:55 -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_3442369986_1517994
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

This one is not true,

It is obvious that no responder will pre sign revoked responses for all
possible non-issued certificates.

Does this prevent a responder from generating pre signed responses =AD No.
Does this means that a responder will never generate pre signed responses
for a non-issued cert serial number =AD No

I taked to Scott Rea about this. They have a global network for distributin=
g
pre signed responses and they are constantly monitoring the requests. If
there would be a certain pattern of requests for a particular un-known cert
serial number, they could add that serial number to the pre-signed batches.
I assume that also would trigger an investigation about the cause of these
requests, but that's a completely different story.

/Stefan


From:  Piyush Jain 
Date:  Wednesday, January 30, 2013 1:56 AM
To:  'Peter Rybar' , Stefan Santesson ,

Subject:  RE: [pkix] 2560bis draft 12 posted

> -          Inability to perform pre-signing.



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


    This one is not true,
    <=
div>
    It is obvious that no responder will pre sign revoked res=
ponses for all possible non-issued certificates.

    Do=
es this prevent a responder from generating pre signed responses – No.=

    Does this means that a responder will never generate pre signed r=
esponses for a non-issued cert serial number – No

    =

    I taked to Scott Rea about this. They have a global network for distrib=
uting pre signed responses and they are constantly monitoring the requests. =
If there would be a certain pattern of requests for a particular un-known ce=
rt serial number, they could add that serial number to the pre-signed batche=
s. I assume that also would trigger an investigation about the cause of thes=
e requests, but that's a completely different story.

    /Stefan


    Fro=
m:  Piyush Jain <piyush@diten=
ity.com>
    Date:  Wednesday, J=
anuary 30, 2013 1:56 AM
    To:  'Peter=
 Rybar' <rybar@nbusr.sk>, Stefan S=
antesson <stefan@aaa-sec.com>,=
 <pkix@ietf.org>
    Subject:  RE: [pkix] 2560bis draft 12 posted

    - Inability t=
o perform pre-signing.
    

--B_3442369986_1517994--



From piyush@ditenity.com  Tue Jan 29 22:40: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 93FE421F8A54 for ; Tue, 29 Jan 2013 22:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJkzuXD2rvAe for ; Tue, 29 Jan 2013 22:40:35 -0800 (PST)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id D6DAC21F89A3 for ; Tue, 29 Jan 2013 22:40:34 -0800 (PST)
Received: by mail-oa0-f51.google.com with SMTP id n12so1325279oag.24 for ; Tue, 29 Jan 2013 22:40:34 -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=H4uLCkCxFW7m3nmC3XWumaTTSBTtaGafnxb3VltuIU4=; b=k/iXypdzk8LMf99We7APJ4jcz2eaZJqtPRBW8LbJihdUM1yHd1t7U1bEuJF5Poe45J Bl1K8ZrgNv20EO5RrnREMyJYTT4X4C5KDvYuqcoGS/JUdmakFVrS0EICP8tvkk1U0E/k TGB4AiPdFstPzbI3xUbBWMbJtjgWiwrUTkzNMFRg/S9dmFquypoWl4JmTq0qSF6YGrMy e9X7sQTn1+sqEruyD2BGkdGbEXt7RpanzSZpF8QBcuBrXQKlh1S03F+cvN52Yv4JAliI otQiEPdJTZckUA/8CDNz9Dr/CQhl4NDJdKMcxLNmVVyxv/sWVdoxJQi8AfgO0up3w/Gm 9r6Q==
X-Received: by 10.182.220.10 with SMTP id ps10mr2933567obc.21.1359528033957; Tue, 29 Jan 2013 22:40:33 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id c4sm669467oee.0.2013.01.29.22.40.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 22:40:33 -0800 (PST)
From: "Piyush Jain" 
To: "'Stefan Santesson'" , "'Peter Rybar'" , 
References: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com> 
In-Reply-To: 
Date: Tue, 29 Jan 2013 22:40:31 -0800
Message-ID: <030d01cdfeb4$b3ff6500$1bfe2f00$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_030E_01CDFE71.A5DDABA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF3E3qmDilzxlLH8VNbH3wlvpQaUpkPJPTw
Content-Language: en-us
X-Gm-Message-State: ALoCoQlec1zfoa7rGke75NGCkunAAJktTy0EdCK7Z3PEh1m1MUAx2tSKSMISOnK3PuKg/ZNq4D6t
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: Wed, 30 Jan 2013 06:40:36 -0000

This is a multipart message in MIME format.

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

Inline

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com] 
Sent: Tuesday, January 29, 2013 8:53 PM
To: Piyush Jain; 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

 

This one is not true,

[Piyush] Only if you change the meaning of pre-signed J

It is obvious that no responder will pre sign revoked responses for all
possible non-issued certificates.

[Piyush] true that.

 

Does this prevent a responder from generating pre signed responses - No.

Does this means that a responder will never generate pre signed responses
for a non-issued cert serial number - No

I taked to Scott Rea about this. They have a global network for distributing
pre signed responses and they are constantly monitoring the requests. If
there would be a certain pattern of requests for a particular un-known cert
serial number, they could add that serial number to the pre-signed batches.
I assume that also would trigger an investigation about the cause of these
requests, but that's a completely different story.

[Piyush] If you are familiar with pre-signing infrastructure, you would know
that in most cases, generating a live response is not an option. Pre-signed
responses are distributed to CDNs or keyless caching responder. So the
implication is that most of the time the responder will have to return
UNAUTHORIZED for non-issued serials.

 

Claiming that responders can do pre-signing for non-issued serials because
of presence for a few non-issued serials in the pre-signed cache is
misleading IMO. 

Unless you are changing your stance now and saying that non-issued serials
case is interesting only for a few certificates and it is okay for the
responder to return UNAUTHORIZED in most cases.

/Stefan

 

 

From: Piyush Jain 
Date: Wednesday, January 30, 2013 1:56 AM
To: 'Peter Rybar' , Stefan Santesson ,

Subject: RE: [pkix] 2560bis draft 12 posted

 

-          Inability to perform pre-signing.


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


    Inline
     
    From:=
 =
Stefan Santesson [mailto:stefan@aaa-sec.com] 
    Sent: Tuesday, =
January 29, 2013 8:53 PM
    To: Piyush Jain; 'Peter Rybar'; =
pkix@ietf.org
    Subject: Re: [pkix] 2560bis draft 12 =
posted
     
    This one is not true,
    [Piyush] Only if you change the meaning of pre-signed =
J
    It is obvious that no responder will pre sign revoked responses for all =
possible non-issued certificates.
    [Piyush] true that.
     
    Does this prevent a responder from generating pre signed responses =
– No.
    Does this means that a responder will never generate pre signed =
responses for a non-issued cert serial number – =
No
    I taked to Scott Rea about this. They have a global network for =
distributing pre signed responses and they are constantly monitoring the =
requests. If there would be a certain pattern of requests for a =
particular un-known cert serial number, they could add that serial =
number to the pre-signed batches. I assume that also would trigger an =
investigation about the cause of these requests, but that's a completely =
different story.
    [Piyush] If you are familiar with pre-signing infrastructure, you =
would know that in most cases, generating a live response is not an =
option. Pre-signed responses are distributed to CDNs or keyless caching =
responder. So the implication is that most of the time the responder =
will have to return UNAUTHORIZED for non-issued =
serials.
     
    Claiming that responders can do pre-signing for non-issued serials =
because of presence for a few non-issued serials in the pre-signed cache =
is misleading IMO. 
    Unless you are changing your stance now and saying that non-issued =
serials case is interesting only for a few certificates and it is okay =
for the responder to return UNAUTHORIZED in most =
cases.
    /Stefan
     
     
    From: Piyush Jain <piyush@ditenity.com>
    Dat=
e: Wednesday, January 30, 2013 1:56 AM
    To: 'Peter Rybar' =
<rybar@nbusr.sk>, Stefan =
Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
    Subject: =
RE: [pkix] 2560bis draft 12 =
posted
     
    -     &nb=
sp;    Inability to perform pre-signing.
    
------=_NextPart_000_030E_01CDFE71.A5DDABA0--


From piyush@ditenity.com  Tue Jan 29 23:06:56 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 90BA521F8A89 for ; Tue, 29 Jan 2013 23:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prCPx8VPmC35 for ; Tue, 29 Jan 2013 23:06:55 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE321F8A77 for ; Tue, 29 Jan 2013 23:06:55 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id o6so1328017oag.4 for ; Tue, 29 Jan 2013 23:06:55 -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=m3k/AFTf8tLFeoaxx7gSsYMcJTxSLudbidGSdVVzna4=; b=k2/iK2OeeV/Vd/hqQ4WBKeCqdNC6jaWmPD7fcPopaONEe1FnixTKte4rNQV27Fl2tc 4m6WaJephHRIYiDXT17Jz1rpW8XOYsNfQHGeoX1ka2xbyNktkmUywKsbg912W+5FWFqd S9jeH6o36KN1I9JtoH2NpsnbBrG/uRd8UWAwVvm+p+dvboH0kvkeivjIs5F27mPdvCPn CD4YbO58Gbs3kEUVCAjFJC3P/HK68KrJlR2oz1jPbM4bn44YtkRFfvtH2TRUJLNKa+rr r2DoDl6ZhSIpsE8bLIAbzc1HLM7pZfLab6Xs3Yh6xwkbL66QHRfEPKJfWUMHAH37tizA cdeg==
X-Received: by 10.182.40.71 with SMTP id v7mr2807297obk.85.1359529615099; Tue, 29 Jan 2013 23:06:55 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id e1sm712732oef.4.2013.01.29.23.06.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 23:06:54 -0800 (PST)
From: "Piyush Jain" 
To: "'Manger, James H'" , 
References:  <201301291706.r0TH6Ecp026364@mail.nbusr.sk> <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com> <255B9BB34FB7D647A506DC292726F6E115068D7E08@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115068D7E08@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 29 Jan 2013 23:06:53 -0800
Message-ID: <031a01cdfeb8$62c2bee0$28483ca0$@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: AQHytDvNts0ig9UeBHrAqTBHbJo78AKyQGa6AnqPRKIBwfeXl5fgjLow
Content-Language: en-us
X-Gm-Message-State: ALoCoQnVrkOMBxJETdL1RXNMzkAWCacc5awC+++ZC0ykvqUppoH9QBqxVS+yPQ1t2iLLSkIWK3et
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: Wed, 30 Jan 2013 07:06:56 -0000

I think that authority of server becomes contextual in case of non-issued
serial numbers.

 Query for non-issued serials can only imply one of two things :
1) Client is in possession of the certificate for which server has no
issuance record (fraudulently issued)
2) Client is not in possession of the certificate (malicious or
non-compliant client)

If server assumes one, it ceases to be authoritative and should return
UNAUTHORIZED (according to 5019)
If it assumes 2, the content of response is immaterial and it should return
the response that minimizes its resource expenditure i.e. unsigned
UNAUTHORIZED.

You can always argue that one can remain authoritative even after being
compromised.

-Piyush

> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Tuesday, January 29, 2013 6:35 PM
> To: pkix@ietf.org
> Subject: Re: [pkix] 2560bis draft 12 posted
> 
> [RFC 5019 "Lightweight OCSP Profile", section 2.2.3." OCSPResponseStatus
> Values"]
> 
> >> When access to authoritative records for a particular certificate is
> >> not available, the responder MUST return an OCSPResponseStatus of
> >> "unauthorized".
> >> ...
> >>  The response "unauthorized" is returned in cases where the client
> >> is not authorized to make this query to this server or the server  is
> >> not capable of responding authoritatively.
> 
> 
> The 2560bis update doesn't clash with RFC5019 here.
> A server with a list of all known-good cert serial numbers IS capable of
> responding authoritatively. It authoritatively knows there is no records
for
> any "non-issued" serial number it is asked about -- there is no access
that it
> lacks. So the RFC5019 use of "unauthorized" does not apply.
> 
> --
> James Manger
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


From ryan.hurst@globalsign.com  Tue Jan 29 23:35:09 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 C936A21F8AE6 for ; Tue, 29 Jan 2013 23:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qsj9+K-iBD2 for ; Tue, 29 Jan 2013 23:35:08 -0800 (PST)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id E072821F8ADB for ; Tue, 29 Jan 2013 23:35:07 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id un15so801130pbc.38 for ; Tue, 29 Jan 2013 23:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=pBDC9qsQuTl0PwILSLFyz3QXLFNLR5/cAsXohxE5JW8=; b=DguIZAYNtB/WemSd2wWg4EM0zpPr2jyRZgK+lOe9E8pSVAhWOMrk547sSRWcqYouP6 mrEwEdxoib305Y4C80Ve8XGzCuGOng5wg0RQmwdKowHWUFVu3vDNve+HmrPFnqhYMDul eqw6qD+7bT9/wUb9HAcL/z6pZdyHdhZCObz9g=
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=pBDC9qsQuTl0PwILSLFyz3QXLFNLR5/cAsXohxE5JW8=; b=YHhxmLIPPe2Fpwjf9wBXBq90yiN1BH0Ls79wWGRa0wOnieJpC3JFWRy1oYFnk4OhIG B54BjW28zm8OYbDQfSftdjUgi6JXYJzslsLQsYTKD6uRSbLWOWmy1WSeQism9/W8KTLz zDZp44Hvyj178AETLi0q9Y3ccCIwqgBEEA81VrhM2g/7eSx/SkI6hpTV3qL/i5j1N3vJ kSaUhY8RGdnNYaB/OF5Av2NvIwI8hfdb16xsYQjq0pwbsthhoq2kqLGk0KgN6Lu43yyB 3r278T0Fe+n7j0vyrW+Y/71D5uwOPRGwzPwoDr9qBzJ92QBUqD5xs7crxWRqtvWE9nnd ACvA==
X-Received: by 10.66.75.100 with SMTP id b4mr9302088paw.0.1359531307425; Tue, 29 Jan 2013 23:35:07 -0800 (PST)
Received: from RyanUltrabook ([50.46.232.231]) by mx.google.com with ESMTPS id az8sm1227741pab.3.2013.01.29.23.35.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 23:35:06 -0800 (PST)
From: "Ryan Hurst" 
To: "'Piyush Jain'" , "'Stefan Santesson'" , "'Peter Rybar'" , 
References: <028b01cdfe84$b1e670e0$15b352a0$@ditenity.com>  <030d01cdfeb4$b3ff6500$1bfe2f00$@ditenity.com>
In-Reply-To: <030d01cdfeb4$b3ff6500$1bfe2f00$@ditenity.com>
Date: Tue, 29 Jan 2013 23:33:32 -0800
Message-ID: <465401cdfebc$1c6c0380$55440a80$@globalsign.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_4655_01CDFE79.0E4DF3A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6j0SiWug4Oj055bO3K9vVeKMYZAF3E3qmAiJ9PfuW640DcA==
Content-Language: en-us
X-Gm-Message-State: ALoCoQngFAVv575Ez/f2LpG6BeN9KCHW2jVfneJUneIIWPK1iG//Q4tOgrbxj+ui6Kp/2YlSOzkC
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: Wed, 30 Jan 2013 07:35:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_4655_01CDFE79.0E4DF3A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

There are plenty of cumulative caching pre-producing OCSP responders out
there.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
Piyush Jain
Sent: Tuesday, January 29, 2013 10:41 PM
To: 'Stefan Santesson'; 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

 

Inline

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com] 
Sent: Tuesday, January 29, 2013 8:53 PM
To: Piyush Jain; 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

 

This one is not true,

[Piyush] Only if you change the meaning of pre-signed J

It is obvious that no responder will pre sign revoked responses for all
possible non-issued certificates.

[Piyush] true that.

 

Does this prevent a responder from generating pre signed responses - No.

Does this means that a responder will never generate pre signed responses
for a non-issued cert serial number - No

I taked to Scott Rea about this. They have a global network for distributing
pre signed responses and they are constantly monitoring the requests. If
there would be a certain pattern of requests for a particular un-known cert
serial number, they could add that serial number to the pre-signed batches.
I assume that also would trigger an investigation about the cause of these
requests, but that's a completely different story.

[Piyush] If you are familiar with pre-signing infrastructure, you would know
that in most cases, generating a live response is not an option. Pre-signed
responses are distributed to CDNs or keyless caching responder. So the
implication is that most of the time the responder will have to return
UNAUTHORIZED for non-issued serials.

 

Claiming that responders can do pre-signing for non-issued serials because
of presence for a few non-issued serials in the pre-signed cache is
misleading IMO. 

Unless you are changing your stance now and saying that non-issued serials
case is interesting only for a few certificates and it is okay for the
responder to return UNAUTHORIZED in most cases.

/Stefan

 

 

From: Piyush Jain 
Date: Wednesday, January 30, 2013 1:56 AM
To: 'Peter Rybar' , Stefan Santesson ,

Subject: RE: [pkix] 2560bis draft 12 posted

 

-          Inability to perform pre-signing.


------=_NextPart_000_4655_01CDFE79.0E4DF3A0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


    There are plenty of cumulative caching pre-producing OCSP responders =
out there.
     
    From:=
 =
pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Piyush Jain
    Sent: Tuesday, January 29, 2013 10:41 =
PM
    To: 'Stefan Santesson'; 'Peter Rybar'; =
pkix@ietf.org
    Subject: Re: [pkix] 2560bis draft 12 =
posted
     
    Inline
     
    From:=
 =
Stefan Santesson [mailto:stefan@aaa-sec.com] =

    Sent: Tuesday, January 29, 2013 8:53 PM
    To: Piyush =
Jain; 'Peter Rybar'; pkix@ietf.org
    Subject: Re: =
[pkix] 2560bis draft 12 posted
     
    This one is not true,
    [Piyush] Only if you change the meaning of pre-signed =
J
    It is obvious that no responder will pre sign revoked responses for all =
possible non-issued certificates.
    [Piyush] true that.
     
    Does this prevent a responder from generating pre signed responses =
– No.
    Does this means that a responder will never generate pre signed =
responses for a non-issued cert serial number – =
No
    I taked to Scott Rea about this. They have a global network for =
distributing pre signed responses and they are constantly monitoring the =
requests. If there would be a certain pattern of requests for a =
particular un-known cert serial number, they could add that serial =
number to the pre-signed batches. I assume that also would trigger an =
investigation about the cause of these requests, but that's a completely =
different story.
    [Piyush] If you are familiar with pre-signing infrastructure, you =
would know that in most cases, generating a live response is not an =
option. Pre-signed responses are distributed to CDNs or keyless caching =
responder. So the implication is that most of the time the responder =
will have to return UNAUTHORIZED for non-issued =
serials.
     
    Claiming that responders can do pre-signing for non-issued serials =
because of presence for a few non-issued serials in the pre-signed cache =
is misleading IMO. 
    Unless you are changing your stance now and saying that non-issued =
serials case is interesting only for a few certificates and it is okay =
for the responder to return UNAUTHORIZED in most =
cases.
    /Stefan
     
     
    From: Piyush Jain <piyush@ditenity.com>
    Dat=
e: Wednesday, January 30, 2013 1:56 AM
    To: 'Peter Rybar' =
<rybar@nbusr.sk>, Stefan =
Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
    Subject: =
RE: [pkix] 2560bis draft 12 =
posted
     
    -     &nb=
sp;    Inability to perform pre-signing.
    
------=_NextPart_000_4655_01CDFE79.0E4DF3A0--


From stefan@aaa-sec.com  Tue Jan 29 23:38:42 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 DF96021F8AD6 for ; Tue, 29 Jan 2013 23:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.427
X-Spam-Level: 
X-Spam-Status: No, score=-101.427 tagged_above=-999 required=5 tests=[AWL=-0.575, 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 v9sF7Uklc6Lj for ; Tue, 29 Jan 2013 23:38:42 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1121F84C2 for ; Tue, 29 Jan 2013 23:38:41 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 1AA422DECA4 for ; Wed, 30 Jan 2013 08:38:40 +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 lWQwPcFZRkKD for ; Wed, 30 Jan 2013 08:38:39 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9EDD82DEC9C for ; Wed, 30 Jan 2013 08:38:39 +0100 (CET)
Received: (qmail 76520 invoked from network); 30 Jan 2013 07:38:39 -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 ; 30 Jan 2013 07:38:39 -0000
User-Agent: Microsoft-MacOutlook/14.2.5.121010
Date: Wed, 30 Jan 2013 08:38:37 +0100
From: Stefan Santesson 
To: Piyush Jain , 'Peter Rybar' , 
Message-ID: 
Thread-Topic: [pkix] 2560bis draft 12 posted
In-Reply-To: <030d01cdfeb4$b3ff6500$1bfe2f00$@ditenity.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3442379920_2109102"
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: Wed, 30 Jan 2013 07:38:43 -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_3442379920_2109102
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit


> [Piyush] If you are familiar with pre-signing infrastructure, you would know
> that in most cases, generating a live response is not an option. Pre-signed
> responses are distributed to CDNs or keyless caching responder. So the
> implication is that most of the time the responder will have to return
> UNAUTHORIZED for non-issued serials.

Yes, I'm very familiar with that.

And yes, they would respond "unauthorized" by default. That has not changed
either.
The new thing is that they could add a pre signed "revoked" response if they
monitor requests for a non-issued serial number asked in a certain manner or
pattern.

I'm not suggesting. I'm just telling you what a current CA on the market,
that is using CDNs for distribution of pre-signed responses are considering.
And YES, it is still perfectly legal and valid to return "unauthorized"
according to the non changed Light weight profile.
This is just another tool in the toolbox that does not create a perfect
world, but might make it marginally better.

Your approach to this subject seems like a perfect example of "perfect is
the enemy of good".
http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

/Stefan



--B_3442379920_2109102
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



    [Piyush]=
 If you are familiar with pre-signing infrastructure, you would know that in=
 most cases, generating a live response is not an option. Pre-signed respons=
es are distributed to CDNs or keyless caching responder. So the implication =
is that most of the time the responder will have to return UNAUTHORIZED for =
non-issued serials.

    Ye=
s, I'm very familiar with that.

    And yes, they would=
 respond "unauthorized" by default. That has not changed either.
    T=
he new thing is that they could add a pre signed "revoked" response if they =
monitor requests for a non-issued serial number asked in a certain manner or=
 pattern.

    I'm not suggesting. I'm just telling you =
what a current CA on the market, that is using CDNs for distribution of pre-=
signed responses are considering.
    And YES, it is still perfectly l=
egal and valid to return "unauthorized" according to the non changed Light w=
eight profile.
    This is just another tool in the toolbox that does =
not create a perfect world, but might make it marginally better.
    <=
br>
    Your approach to this subject seems like a perfect example of =
"perfect is the enemy of good".

    /Stefan
    

--B_3442379920_2109102--



From prvs=0742db7694=rybar@nbusr.sk  Wed Jan 30 01:15: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 2B54821F8467 for ; Wed, 30 Jan 2013 01:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.693
X-Spam-Level: 
X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 A908k79OVMt4 for ; Wed, 30 Jan 2013 01:15:53 -0800 (PST)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0621F86D8 for ; Wed, 30 Jan 2013 01:15:52 -0800 (PST)
Message-Id: <201301300915.r0U9FnsO028348@mail.nbusr.sk>
From: "Peter Rybar" 
To: "'Stefan Santesson'" , "'Piyush Jain'" , pkix@ietf.org
Date: Wed, 30 Jan 2013 10:16:03 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CDFED2.CFBBEFC0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: 
Thread-Index: Ac3+vNOK6iqGCYMMQzm1deReYdkIQQABodDg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level: **
X-NAI-Spam-Threshold: 6
X-NAI-Spam-Score: 2.5
X-NAI-Spam-Version: 2.2.0.9309 : core <4476> : streams <897371> : uri <1331714>
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: Wed, 30 Jan 2013 09:15:54 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0027_01CDFED2.CFBBEFC0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

When RFC defines only possibility to provide =E2=80=9Crevoked=E2=80=9D =
for =E2=80=9Cnon-issued=E2=80=9D without providing mechanism how the CA =
can recovery from the situation when RP have certificate signed by CA =
but CA have not evidence about issuance is an ostrich-like policy.

=20

You have explained:=20

When RP permanently disturbing CA with OCSP requests of certificate =
serial number which is not in CA electronic evidence then CA can use =
pre-signed response where this serial number will be revoked as =
certificateHold.=20

In this way it is expected that RP clients will not anymore creating =
OCSP request for validation of some electronic evidence supported by =
such certificate.

It is ostrich-like policy and it has nothing solved and certificateHold =
causes that legacy client will repeatedly try to get a new status of =
actual certificateHold state.

=20

Instead of such unclear revocation it will be more helpful to include in =
draft a new singleRequestExtensions extension:=20

ext-ocsp-CertOfNoIssueRecordFound EXTENSION ::=3D { SYNTAX Certificate=20

   IDENTIFIED BY id-pkix-ocsp-CertOfNoIssueRecordFound }

=20

This singleRequestExtensions will be used by RP clients when =
=E2=80=9Cright=E2=80=9D OCSP responder will return "unknown" state or =
unauthorized error message.

=20

According to it OCSP responder will be able to analyze received =
certificate and together with CA create analysis and making decisions =
how it can be solved.

=20

Peter Rybar

=20

=20

  _____ =20

From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20
Sent: Wednesday, January 30, 2013 8:39 AM
To: Piyush Jain; 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

=20

=20

[Piyush] If you are familiar with pre-signing infrastructure, you would =
know that in most cases, generating a live response is not an option. =
Pre-signed responses are distributed to CDNs or keyless caching =
responder. So the implication is that most of the time the responder =
will have to return UNAUTHORIZED for non-issued serials.

=20

Yes, I'm very familiar with that.

=20

And yes, they would respond "unauthorized" by default. That has not =
changed either.

The new thing is that they could add a pre signed "revoked" response if =
they monitor requests for a non-issued serial number asked in a certain =
manner or pattern.

=20

I'm not suggesting. I'm just telling you what a current CA on the =
market, that is using CDNs for distribution of pre-signed responses are =
considering.

And YES, it is still perfectly legal and valid to return "unauthorized" =
according to the non changed Light weight profile.

This is just another tool in the toolbox that does not create a perfect =
world, but might make it marginally better.

=20

Your approach to this subject seems like a perfect example of "perfect =
is the enemy of good".

http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

=20

/Stefan


------=_NextPart_000_0027_01CDFED2.CFBBEFC0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable















    


    Stefan,
    


     =

    


    When RFC defines =
only possibility
to provide =E2=80=9Crevoked=E2=80=9D for =E2=80=9Cnon-issued=E2=80=9D =
without providing mechanism how the CA can
recovery from the situation when RP have certificate signed by CA but CA =
have
not evidence about issuance is an ostrich-like policy.
    


     =

    


    You have =
explained: 
    


    When RP =
permanently disturbing
CA with OCSP requests of certificate serial number which is not in CA =
electronic
evidence then CA can use pre-signed response where this serial number =
will be
revoked as certificateHold. 
    


    In this way it =
is
expected that RP clients will not anymore creating OCSP request for =
validation of
some electronic evidence supported by such =
certificate.
    


    It is =
ostrich-like policy and it =
has nothing
solved and certificateHold causes that legacy client will repeatedly try to =
get a new
status of actual certificateHold state.
    


     =

    


    Instead of such =
unclear revocation
it will be more helpful to include in draft a new =
singleRequestExtensions extension:

    


    ext-ocsp-CertOfNoIssueRecord=
Found
EXTENSION ::=3D { SYNTAX Certificate 
    


    =C2=A0=C2=A0 =
IDENTIFIED BY id-pkix-ocsp-CertOfNoIssueRecordFound
}
    


     =

    


    This =
singleRequestExtensions
will be used by RP clients when =E2=80=9Cright=E2=80=9D OCSP responder =
will return "unknown"
state or unauthorized error message.
    


     =

    


    According to it =
OCSP
responder will be able to analyze received certificate and together with =
CA create
analysis and making decisions how it can be =
solved.
    


     =

    


    Peter =
Rybar
    


     =

    


     =

    


    


    


    


    


    From:
Stefan Santesson [mailto:stefan@aaa-sec.com] 
    
Sent: Wednesday, January =
30, 2013
8:39 AM
    
To: Piyush Jain; 'Peter =
Rybar';
pkix@ietf.org
    
Subject: Re: [pkix] =
2560bis draft
12 posted
    


    


     
    


    


     
    


    


    


    [Piyush] If you are =
familiar
with pre-signing infrastructure, you would know that in most cases, =
generating
a live response is not an option. Pre-signed responses are distributed =
to CDNs
or keyless caching responder. So the implication is that most of the =
time the
responder will have to return UNAUTHORIZED for non-issued =
serials.
    


    




    


     
    


    


    


    Yes, I'm very =
familiar
with that.
    


    


    


     
    


    


    


    And yes, they =
would
respond "unauthorized" by default. That has not changed =
either.
    


    


    


    The new thing =
is that
they could add a pre signed "revoked" response if they monitor
requests for a non-issued serial number asked in a certain manner or =
pattern.
    


    


    


     
    


    


    


    I'm not =
suggesting.
I'm just telling you what a current CA on the market, that is using CDNs =
for
distribution of pre-signed responses are =
considering.
    


    


    


    And YES, it =
is still
perfectly legal and valid to return "unauthorized" according =
to the
non changed Light weight profile.
    


    


    


    This is just =
another
tool in the toolbox that does not create a perfect world, but might make =
it
marginally better.
    


    


    


     
    


    


    


    Your approach =
to this
subject seems like a perfect example of "perfect is the enemy of
good".
    


    




    


     
    


    


    


    /Stefan
    


    


    





------=_NextPart_000_0027_01CDFED2.CFBBEFC0--


From kent@bbn.com  Wed Jan 30 07:21: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 ECC8021F8A5F for ; Wed, 30 Jan 2013 07:21:44 -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=[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 Q5mIaF74n4aA for ; Wed, 30 Jan 2013 07:21:44 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C18DF21F89CE for ; Wed, 30 Jan 2013 07:21:43 -0800 (PST)
Received: from [128.89.89.145] (port=49475 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0ZTq-000Hlh-Hc; Wed, 30 Jan 2013 10:21:42 -0500
Message-ID: <51093A86.6010303@bbn.com>
Date: Wed, 30 Jan 2013 10:21:42 -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: mrex@sap.com
References: <20130130012522.5DEEB1A4BA@ld9781.wdf.sap.corp>
In-Reply-To: <20130130012522.5DEEB1A4BA@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 30 Jan 2013 15:21:45 -0000

Martin,

...
> That is complete and utter non-sense (as I've previously explained),
> any such prohibition for "onHold" can not apply to not-issued cert serials.
>
> However expecting OCSP clients to continue talking to an OCSP responder
> that returned "unauthorized" will make you liable under the current
> US CFAA crminial statute, that breakage of 5019 should be much more
> of a concern for folks that are sensitive to legal issues.
Might I ask from which law school you received your JD?

Steve

From simon@tardell.se  Wed Jan 30 07: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 9099721F877B for ; Wed, 30 Jan 2013 07:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 kgZvTsn06JRr for ; Wed, 30 Jan 2013 07:51:12 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C82C921F8757 for ; Wed, 30 Jan 2013 07:51:09 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t11so1393529wey.28 for ; Wed, 30 Jan 2013 07:51:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=udqHn9KAUT7uFdUgtGJn+2CEJ4OsZxwU4WxIkreRRrY=; b=Cd5oaz65WLg+BrMG8rZUbnvoQoXLEnhGU4xeXTZCx8JArrcS/IpokERm/CXDu61mdj CY3TDszP1Hl1x8h2rLIrWedfkcTh7QXSB5FnWBPYG51p/+Kr5p0nWWn8J0pZxjGL9xvb RUcyBBXgOSsnvwv+G5EZ+Ibp8CG5i4zFicjcjZagoMsaiWUNst5DBMgm99c8yMEWHOs5 Unf+yDDc9bDZbdeARL3gWCcYLe/qClNWlpFzxrSZwtDU+vDbw8/MU+Il4VAjmnnJZpmF KppUFRMdo/JF39T85k1h+HxQx5S/I7TFTKHtUCIyXROjPEq2+Nfg/MLRxiMwG0NMLBRk s2ZA==
MIME-Version: 1.0
X-Received: by 10.180.96.194 with SMTP id du2mr9805357wib.19.1359561068443; Wed, 30 Jan 2013 07:51:08 -0800 (PST)
Received: by 10.216.202.28 with HTTP; Wed, 30 Jan 2013 07:51:07 -0800 (PST)
In-Reply-To: <51080D8A.5000201@bull.net>
References: <201301291706.r0TH6Ecp026364@mail.nbusr.sk> <51080D8A.5000201@bull.net>
Date: Wed, 30 Jan 2013 16:51:07 +0100
Message-ID: 
From: Simon Tardell 
To: Denis Pinkas 
Content-Type: multipart/alternative; boundary=f46d0442827c88f91e04d4837a14
X-Gm-Message-State: ALoCoQlfPFQ5uQkz6tjUwODB5Cfx+zmEurrOGCAzrSGqIP/G0cn9RPMmrE5hjKdoAByPL8pEapNs
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: Wed, 30 Jan 2013 15:51:13 -0000

--f46d0442827c88f91e04d4837a14
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 29, 2013 at 6:57 PM, Denis Pinkas  wrote:

> But since an onhold state MUST NOT stay for ever, some software will
> trying again later on to see whether the certificate is valid or revoked.
>

But this is wrong. It is quite clear that if a certificate is revoked with
whatever reason code, the certificate is not valid for use at that point in
time. Nothing more, nothing less. That use (at a time of invalidity) does
not become valid if the certificate is unsuspended later. The certificate
will be valid for new uses after the time of unsuspension, but you do not
need, and should not, recheck the revocation status. There is of course a
problem that there could be a time lag between the use of the certificate
and the revocation checking during which it could be unsuspended, but this
problem is no different from the time lag at the other end of the
revocation period (i.e. that you could be looking at revocation data that
represents a time period somewhat before the time you are interested in).
As always, the cure is to minimize these windows and balance the cost for
doing so against the risk and size of any potential damage.


> Since the semantics of onhold was changed, these application will be
> locked for ever (i.e. will wait for ever unless their code is modified).
>

This means *this change is not backwards compatible with existing
> implementations*.
>

The semantics aren't changed. These applications are buggy. You have to be
a lot more specific for this to be worthy of consideration, I'd say.

In the mean time, some countries do not allow to place a certificate
> onhold, which is also a problem.
> This means *this change is not backwards compatible with existing
> legislations.*


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

/Simon

--f46d0442827c88f91e04d4837a14
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



    On Tue, Jan 29, 2013 at 6:57 PM, Denis Pinkas <denis.pinka=
s@bull.net> wrote:
    

    But since an
                              onhold state MUST NOT
                              stay for ever, some
                                software will trying again later on to
                                see whether the certificate is valid =
or revoked.

    But this is wrong. It is quite clear that if a certificate is =
revoked with whatever reason code, the certificate is not valid for use at =
that point in time. Nothing more, nothing less. That use (at a time of inva=
lidity) does not become valid if the certificate is unsuspended later. The =
certificate will be valid for new uses after the time of unsuspension, but =
you do not need, and should not, recheck the revocation status. There is of=
 course a problem that there could be a time lag between the use of the cer=
tificate and the revocation checking during which it could be unsuspended, =
but this problem is no different from the time lag at the other end of the =
revocation period (i.e. that you could be looking at revocation data that r=
epresents a time period somewhat before the time you are interested in). As=
 always, the cure is to minimize these windows and balance the cost for doi=
ng so against the risk and size of any potential damage.
    

    =A0
    
                                  Since the semantics of
                                    onhold was changed, these
                                    application will be locked for ever
                                    (i.e. will wait for ever unless
                                    their code is modified).

    
This means this
                                        change is not backwards
                                        compatible with existing
                                        implementations.

    The semantics=
 aren't changed. These applications are buggy. You have to be a lot mor=
e specific for this to be worthy of consideration, I'd say.=A0
    


    <=
font>In the mean time, some=
 countries do not allow to place a certificate onhold, which is also a prob=
lem.
    
    This means=A0t=
his change is not backwards compatible with existing legislations.<=
/font>
    


    The French legislation you quoted earlier i=
s 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 w=
orded 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 th=
e German law does have).
    

    =A0
    /Simon
    

--f46d0442827c88f91e04d4837a14--

From mrex@sap.com  Wed Jan 30 09:24: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 7E12421F8867 for ; Wed, 30 Jan 2013 09:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xWjdTjV5w5rZ for ; Wed, 30 Jan 2013 09:24:06 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BB74D21F87D6 for ; Wed, 30 Jan 2013 09:24:05 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0UHNqSM025105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jan 2013 18:23:52 +0100 (MET)
In-Reply-To: <51093A86.6010303@bbn.com>
To: Stephen Kent 
Date: Wed, 30 Jan 2013 18:23:52 +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: <20130130172352.2D2B11A4CB@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: Wed, 30 Jan 2013 17:24:06 -0000

Stephen Kent wrote:
> 
> > That is complete and utter non-sense (as I've previously explained),
> > any such prohibition for "onHold" can not apply to not-issued cert serials.
> >
> > However expecting OCSP clients to continue talking to an OCSP responder
> > that returned "unauthorized" will make you liable under the current
> > US CFAA crminial statute, that breakage of 5019 should be much more
> > of a concern for folks that are sensitive to legal issues.
>
> Might I ask from which law school you received your JD?


What is relevant here is the opionion and actions of US federal
prosecutors, e.g. US Attourneys Steve Heymann and Carmen Ortiz,
who seriously believe that a terms-of-use violation is a
felony crime under the CFAA.

They exercised there state-assigned powers and tortured Aaron Swartz
with plea-boarding and threatened him to the point that he commited suicide.

-Martin

From kent@bbn.com  Wed Jan 30 10:26: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 DA7BD21F8869 for ; Wed, 30 Jan 2013 10:25: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=[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 FqSTIbjVEuaO for ; Wed, 30 Jan 2013 10:25:59 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 59E5C21F8867 for ; Wed, 30 Jan 2013 10:25:59 -0800 (PST)
Received: from [128.89.89.145] (port=51529 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0cM9-000MFR-RY; Wed, 30 Jan 2013 13:25:57 -0500
Message-ID: <510965B5.9020608@bbn.com>
Date: Wed, 30 Jan 2013 13:25:57 -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: ben@digicert.com, pkix ,  Sean Turner 
References:  <017601cdf9a3$97d904a0$c78b0de0$@digicert.com> <005801cdfcdb$2369dc30$6a3d9490$@digicert.com>
In-Reply-To: <005801cdfcdb$2369dc30$6a3d9490$@digicert.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] Update to OCSP Must Staple draft
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 18:26:01 -0000

Ben,

PKIX will not consider any new work items, as noted previously. So, I 
suggest you contact
Sean Turner to see what he suggets re how to pursue OCSP stapling in the 
IETF.

Steve


From ben@digicert.com  Wed Jan 30 10:31:31 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 6BE6121F8871 for ; Wed, 30 Jan 2013 10:31:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  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 bbP7nzP3suGY for ; Wed, 30 Jan 2013 10:31:31 -0800 (PST)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 09FDB21F886C for ; Wed, 30 Jan 2013 10:31:31 -0800 (PST)
Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 8CC218FA257; Wed, 30 Jan 2013 11:31:30 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1359570690; bh=tgnD4y9EWwhHGbHLN9/U1OpnAttuNILogWI5LIP5zIE=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date; b=t75z+cvEIGPtZDPi9U8p9rkHGH8fCoUM7/FXI012k3/XKxQFHR7qx90iGGkGIqyYj G9jhjiQ09IITzawj6/JQr73KuzezkfEnYMelLXUCyoQCzBMDb5DLEpf36OIrhzXuGs 1cv+/TxUAWQhn6DOZnMFI8i7uGvqtFRULOsPUUjQ=
From: "Ben Wilson" 
To: "'Stephen Kent'" , "'pkix'" , "'Sean Turner'" 
References:  <017601cdf9a3$97d904a0$c78b0de0$@digicert.com> <005801cdfcdb$2369dc30$6a3d9490$@digicert.com> <510965B5.9020608@bbn.com>
In-Reply-To: <510965B5.9020608@bbn.com>
Date: Wed, 30 Jan 2013 11:31:26 -0700
Organization: DigiCert
Message-ID: <00ae01cdff18$035eb9d0$0a1c2d70$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIsYWEM0R8veDa8HUwN2g2ZyyDopAKbc2xqAdryyzsCYXW8w5durjOQ
Content-Language: en-us
Subject: Re: [pkix] Update to OCSP Must Staple draft
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ben@digicert.com
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 18:31:31 -0000

Thanks, Steve.  Sean - drop me an email on this.  
Thanks,
Ben

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Wednesday, January 30, 2013 11:26 AM
To: ben@digicert.com; pkix; Sean Turner
Subject: Re: [pkix] Update to OCSP Must Staple draft

Ben,

PKIX will not consider any new work items, as noted previously. So, I
suggest you contact Sean Turner to see what he suggets re how to pursue OCSP
stapling in the IETF.

Steve


From kent@bbn.com  Wed Jan 30 10:33: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 5295321F8881 for ; Wed, 30 Jan 2013 10:33:36 -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 FmEKpPuCc9iP for ; Wed, 30 Jan 2013 10:33:35 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D28BF21F887F for ; Wed, 30 Jan 2013 10:33:35 -0800 (PST)
Received: from [128.89.89.145] (port=51540 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0cTX-000MQY-1v; Wed, 30 Jan 2013 13:33:35 -0500
Message-ID: <5109677E.3020609@bbn.com>
Date: Wed, 30 Jan 2013 13:33:34 -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: mrex@sap.com
References: <20130130172352.2D2B11A4CB@ld9781.wdf.sap.corp>
In-Reply-To: <20130130172352.2D2B11A4CB@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 30 Jan 2013 18:33:36 -0000

Martin,
> What is relevant here is the opionion and actions of US federal
> prosecutors, e.g. US Attourneys Steve Heymann and Carmen Ortiz,
> who seriously believe that a terms-of-use violation is a
> felony crime under the CFAA.
What is relevant is that you are not an attorney and have no
basis for admonishing this list re the legal implications of OCSP
processing.

We're developing voluntary, not de jure, standards.

Steve

From mrex@sap.com  Wed Jan 30 11:10: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 EB54F21F8855 for ; Wed, 30 Jan 2013 11:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 2eorsfMoc8t9 for ; Wed, 30 Jan 2013 11:10:44 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6C21F884A for ; Wed, 30 Jan 2013 11:10:36 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0UJAQdl004955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jan 2013 20:10:26 +0100 (MET)
In-Reply-To: <5109677E.3020609@bbn.com>
To: Stephen Kent 
Date: Wed, 30 Jan 2013 20:10:26 +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: <20130130191026.AF6351A4CF@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: Wed, 30 Jan 2013 19:10:45 -0000

Stephen Kent wrote:
> Martin,
> >
> > What is relevant here is the opionion and actions of US federal
> > prosecutors, e.g. US Attourneys Steve Heymann and Carmen Ortiz,
> > who seriously believe that a terms-of-use violation is a
> > felony crime under the CFAA.
>
> What is relevant is that you are not an attorney and have no
> basis for admonishing this list re the legal implications of OCSP
> processing.

This is BS.

Here in Germany, and maybe in a few other decent democracies,
there are quite strict requirements for criminal statutes.
That requirement is, that it MUST be obvious to the average human
being that an action is a criminal offense.  In Germany, if the
criminal statute is not sufficiently clear, then it may not be
used for that purpose, because any such use would be unconstitutional
and therefore null and void.  Our constitutional court has been
pretty clear about this everytime that it was asked.  And the
European Court of Human Right (ECHR) has been at least as strict
(if not stricter) in applying that dogma.


So "are you an attourney" is somewhat of a clueless question.


> 
> We're developing voluntary, not de jure, standards.

But the behaviour and the semantics that we specify in our standards,
and the behaviour exhibited by implementations of our standards,
will have de jure implications in the real world.


When rfc2560 was published, the semantics of the Exception Case
"unauthorized" was published as:

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.


And it would be technically entirely inappropriate to completely withdraw
that response code and re-issue it with a completely different meaning
after almost 14 years.

A semantic of the kind "this server is unable to obtain authoritative
information about the status of this cert serial", has exactly nothing
in common with the original meaning of "unauthorized" from rfc2560.


-Martin

From piyush@ditenity.com  Wed Jan 30 11:29: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 1FE9721F87EE for ; Wed, 30 Jan 2013 11:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level: 
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 8Zy2y9GZEQfS for ; Wed, 30 Jan 2013 11:29:51 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B121F87D5 for ; Wed, 30 Jan 2013 11:29:50 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id va7so2029656obc.13 for ; Wed, 30 Jan 2013 11:29:50 -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=OdwUiAd8wluS4Wa8rrZmGnTgVgygAHBo3WQgVkC/Gl0=; b=BmBpGP6MjazWak3PFS/aK9f64JnR2h/QyYJudGKrBbVMZXg/TB3kDJM9dgXTeOdcOP AdI57GStQj4HwXuoHyuPZR+9zp9/kW1LsObDkIs3VC1Q0bNFnK+y7yU7Wrf6RAgLKDiB 0NE/sbgwHN8U9+4XtniwYj4ef0/xmfz3eJK50bUEciA23WefK8nXYK5079tBzWAd5UDY +yY8fBrcOBEpw9Pv+5av37FPcU5H2nquf06MTFnC4QqaiWLNrZTHUxNIwRaN4cGniwxn 8GOJbhaycIbxxItcJ2Z6vewnLr4NHoh13CcVFR9zw9PG6NgOx/3hpauBkKH9qaKrapkK 0MFA==
X-Received: by 10.182.38.69 with SMTP id e5mr4512392obk.79.1359574190290; Wed, 30 Jan 2013 11:29:50 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id yn8sm2542684obb.12.2013.01.30.11.29.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Jan 2013 11:29:49 -0800 (PST)
From: "Piyush Jain" 
To: "'Stefan Santesson'" , "'Peter Rybar'" , 
References: <030d01cdfeb4$b3ff6500$1bfe2f00$@ditenity.com> 
In-Reply-To: 
Date: Wed, 30 Jan 2013 11:29:47 -0800
Message-ID: <048c01cdff20$2ba62ec0$82f28c40$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_048D_01CDFEDD.1D869840"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKE8Bd9rbI+iCt38LaP25Y579HwrJb0G8tw
Content-Language: en-us
X-Gm-Message-State: ALoCoQn7xBxrLC/yeZDphid16mPtUBmlx1LYJaxQ2xlJ/h/H2cWw4Z8D4H4RZvXJ5RzhWQakYd9p
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: Wed, 30 Jan 2013 19:29:54 -0000

This is a multipart message in MIME format.

------=_NextPart_000_048D_01CDFEDD.1D869840
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Let me see if I understood it right.

What you are implying is that a responder who has indicated that it returns
revoked for non-issued can legally return either UNAUTHORIZED or revoked for
a non-issued certificate.

In fact all CA responders will need to do this if they pre-sign responses.

 

>This is just another tool in the toolbox that does not create a perfect
world, but might make it marginally better.

I don't argue with this. However, that incremental benefit to a small
community of responders is coming at a cost to other compliant clients and
future implementations, just because the main document is being changed all
over the place. The changes are not trivial because they deviate from two
basic design assumptions of original OCSP (and those of other pkix
documents) 

1)      Signed by CA and Issued by CA are synonymous. This is not true after
this update. The sad thing is that in many places even this updated document
uses 'signed' and 'issued' interchangeably.

2)      Certificate status can be either good or revoked. Not true anymore.
This is particularly interesting. In discussion over last few months, there
have been arguments about non-issued being a different status and then
follow-up arguments that clients should treat non-issued as revoked to
establish trust in the response even though the clients have a clear way of
differentiating between revoked and non-issued state.

 

If you think about it, the only thing that was needed in the toolbox was to
allow revoked for any negative proof. It could've been achieved without
getting into the debate of issued/non-issued.

"The "revoked" state indicates that the certificate has been revoked(either
permanantly or temporarily (on hold)). It may also indicate that the
responder has determined that the certificate is untrustworthy due to some
other reason". How the responder makes that determination is beyond the
scope of this document"
 
The above text leaves the implementations accountable for their choice,
which arguably is a short term patch for addressing fraudulently issued
certificate. 
 
I agree perfectionism is impractical. But you still need to understand what
perfectionism is, to make an informed choice of deviating from it. Twisting
its definition does not help.
Open standards, IMO should strive to be perfect and should not introduce any
vulnerability just to satisfy the needs of non-compliant implementations.
The problem that you are trying to solve here won't have existed if the
client implementations had complied with original 2560 and 5280.
OPERA browser is one example which has evolved to a state where it correctly
rejects a certificate if it cannot determine the status of a certificate.
Other clients will have no motivation to change when this new guidance is
published, and will remain vulnerable to simple attack where an attacker
breaks the communication between the client and the responder.
 
 
  

 

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com] 
Sent: Tuesday, January 29, 2013 11:39 PM
To: Piyush Jain; 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] 2560bis draft 12 posted

 

 

[Piyush] If you are familiar with pre-signing infrastructure, you would know
that in most cases, generating a live response is not an option. Pre-signed
responses are distributed to CDNs or keyless caching responder. So the
implication is that most of the time the responder will have to return
UNAUTHORIZED for non-issued serials.

 

Yes, I'm very familiar with that.

 

And yes, they would respond "unauthorized" by default. That has not changed
either.

The new thing is that they could add a pre signed "revoked" response if they
monitor requests for a non-issued serial number asked in a certain manner or
pattern.

 

I'm not suggesting. I'm just telling you what a current CA on the market,
that is using CDNs for distribution of pre-signed responses are considering.

And YES, it is still perfectly legal and valid to return "unauthorized"
according to the non changed Light weight profile.

 

Your approach to this subject seems like a perfect example of "perfect is
the enemy of good".

http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

 

/Stefan


------=_NextPart_000_048D_01CDFEDD.1D869840
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Let me see if I understood it right.
    What you are implying is that a responder who has indicated that it =
returns revoked for non-issued can legally return either UNAUTHORIZED or =
revoked for a non-issued certificate.
    In fact all CA responders will need to do this if they pre-sign =
responses.
     
    >This is just another tool in the toolbox that does not create a =
perfect world, but might make it marginally =
better.
    I don’t argue with this. However, that incremental benefit to a =
small community of responders is coming at a cost to other compliant =
clients and future implementations, just because the main document is =
being changed all over the place. The changes are not trivial because =
they deviate from two basic design assumptions of original OCSP (and =
those of other pkix documents) 
    1)      =
Signed by CA and Issued by CA are synonymous. This is not true after =
this update. The sad thing is that in many places even this updated =
document uses ‘signed’ and ‘issued’ =
interchangeably.
    2)      =
Certificate status can be either good or revoked. Not true anymore. =
This is particularly interesting. In discussion over last few months, =
there have been arguments about non-issued being a different status and =
then follow-up arguments that clients should treat non-issued as revoked =
to establish trust in the response even though the clients have a clear =
way of differentiating between revoked and non-issued =
state.
     
    If you think about it, the only thing that was needed in the toolbox =
was to allow revoked for any negative proof. It could’ve been =
achieved without getting into the debate of =
issued/non-issued.
    “The "revoked" state indicates that the =
certificate has been revoked(either permanantly or temporarily (on =
hold)). It may also indicate that the responder has determined that the =
certificate is untrustworthy due to some other reason”. How the =
responder makes that determination is beyond the scope of this =
document”
     
    The above text leaves the implementations accountable for their =
choice, which arguably is a short term patch for addressing fraudulently =
issued certificate. =

     
    I agree perfectionism is impractical. But you still need to =
understand what perfectionism is, to make an informed choice of =
deviating from it. Twisting its definition does not =
help.
    Open standards, IMO should strive to be perfect and should not =
introduce any vulnerability just to satisfy the needs of non-compliant =
implementations.
    The problem that you are trying to solve here won’t have =
existed if the client implementations had complied with original 2560 =
and 5280.
    OPERA browser is one example which has evolved to a state where it =
correctly rejects a certificate if it cannot determine the status of a =
certificate.
    Other clients will have no motivation to change when this new =
guidance is published, and will remain vulnerable to simple attack where =
an attacker breaks the communication between the client and the =
responder.
     
     
      
     
     
    From:=
 =
Stefan Santesson [mailto:stefan@aaa-sec.com] 
    Sent: Tuesday, =
January 29, 2013 11:39 PM
    To: Piyush Jain; 'Peter Rybar'; =
pkix@ietf.org
    Subject: Re: [pkix] 2560bis draft 12 =
posted
     
     
    [Piyush] If you are familiar with pre-signing infrastructure, you =
would know that in most cases, generating a live response is not an =
option. Pre-signed responses are distributed to CDNs or keyless caching =
responder. So the implication is that most of the time the responder =
will have to return UNAUTHORIZED for non-issued =
serials.
     
    Yes, I'm very familiar with that.
     
    And yes, they would respond "unauthorized" by default. That =
has not changed either.
    The new thing is that they could add a pre signed "revoked" =
response if they monitor requests for a non-issued serial number asked =
in a certain manner or pattern.
     
    I'm not suggesting. I'm just telling you what a current CA on the =
market, that is using CDNs for distribution of pre-signed responses are =
considering.
    And YES, it is still perfectly legal and valid to return =
"unauthorized" according to the non changed Light weight =
profile.
     
    Your approach to this subject seems like a perfect example of =
"perfect is the enemy of =
good".
     
    /Stefan
    
------=_NextPart_000_048D_01CDFEDD.1D869840--


From pkix@inbox.lv  Thu Jan 31 02:17: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 CF4AE21F867A for ; Thu, 31 Jan 2013 02:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=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 ffP-vx+Cmyeq for ; Thu, 31 Jan 2013 02:17:53 -0800 (PST)
Received: from shark3.inbox.lv (shark3.inbox.lv [89.111.3.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2989121F863B for ; Thu, 31 Jan 2013 02:17:52 -0800 (PST)
Received: by shark3.inbox.lv (Postfix, from userid 1000) id DD42F1097F; Thu, 31 Jan 2013 12:17:49 +0200 (EET)
Received: from localhost (localhost [127.0.0.1]) by shark3-plain-b64d2.inbox.lv (Postfix) with ESMTP id 8F44410992 for ; Thu, 31 Jan 2013 12:17:49 +0200 (EET)
Received: from localhost ([10.0.1.15]) by localhost (shark3.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id IgW2fwZkWhXS for ; Thu, 31 Jan 2013 12:17:49 +0200 (EET)
Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 31 Jan 2013 12:17:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Compose: web=mail.inbox.lv, node=w5.inbox.lv, l=en, compose=Plaintext
X-REMOTE-ADDR: 193.40.12.10
X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Ubuntu Chromium/23.0.1271.97 Chrome/23.0.1271.97 Safari/537.11
Message-ID: <1359627469.510a44cd683e7@mail.inbox.lv>
Date: Thu, 31 Jan 2013 12:17:49 +0200
From: "Andris Berzins" 
To: pkix@ietf.org
User-Agent: Inbox.lv Webmail
Subject: [pkix] non critical basicConstraints and keyUsage extensions
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, 31 Jan 2013 10:17:53 -0000

Hello,
=20
Lets assume there is certificate issued by CA where basicConstraints CA:FAL=
SE
and keyUsage extension does not include certSign, but the extensions
are not marked as critical.

Is it allowed for relying party to use this certificate as CA certificate?
I know that openssl would not allow that even if extensions are not critica=
l,
but is this a loophole and should it be very much advisable for CA to set
these extensions as critical?


From eabalea@gmail.com  Thu Jan 31 02:50: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 9E72221F869B for ; Thu, 31 Jan 2013 02:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 xjl9UaVwV0Ze for ; Thu, 31 Jan 2013 02:50:21 -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 7EA6321F8628 for ; Thu, 31 Jan 2013 02:50:20 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id fl17so1676090vcb.27 for ; Thu, 31 Jan 2013 02:50:19 -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=AdFSaP+i8IZUVNw/CJ/bhel7SaeTmxaC79orDtYx3Q4=; b=qWorfuGoIfkI17Zx8iEin4/P+XbUNvUxqZ6BtE1MV1OurHDkDtTm3y1MUKTwLPd8ru SA3E18iTOrqRlv2edQ5100nbC45831LUfZ4SsukC3T7Ky4sagz84meKfggfu/lpq+/F/ vJIX7VFPIFR5CS5upUwFj9QGbKclyjKNqVTz0Xz95hcozeEA3/OWwvegHnGZujoHuMBg N9ItGkgTYvSFnWz70V6YuaOw3Fmwj1Upkgpc/Oh7AtflVqILDvHKH5d5BzTOT+AFjQan GQKbbmuHWsPw/WM53RKnYV5OD4vw6Ibqn8fB+NhjSi7mepsrUTOHsM70+ka858aC6gsE 4dDg==
MIME-Version: 1.0
X-Received: by 10.220.230.135 with SMTP id jm7mr7655764vcb.32.1359629419666; Thu, 31 Jan 2013 02:50:19 -0800 (PST)
Received: by 10.52.69.44 with HTTP; Thu, 31 Jan 2013 02:50:19 -0800 (PST)
In-Reply-To: <1359627469.510a44cd683e7@mail.inbox.lv>
References: <1359627469.510a44cd683e7@mail.inbox.lv>
Date: Thu, 31 Jan 2013 11:50:19 +0100
Message-ID: 
From: Erwann Abalea 
To: Andris Berzins 
Content-Type: multipart/alternative; boundary=14dae9cdc80595db6704d4936412
Cc: pkix@ietf.org
Subject: Re: [pkix] non critical basicConstraints and keyUsage extensions
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, 31 Jan 2013 10:50:21 -0000

--14dae9cdc80595db6704d4936412
Content-Type: text/plain; charset=UTF-8

PKIX states that for a certificate to be usable for certificate
verification, it MUST have both a (MUST be critical)
BasicConstraints:CA=true and a (SHOULD be critical) keyUsage with
keyCertSign.
This is written in sections 4.2.1.3 and 4.2.1.9 for certificate issuers.
This is also repeated in section 6.1 (the validation algorithm) for
certificate consumers.

X.509 says things differently, the criticality is reversed, but that
doesn't really change the result.

A non compliant application (certificate consumer) could effectively ignore
non critical extensions and consider that any certificate is potentially a
CA one usable for certificate verification. But such a non compliant
application could also be so non compliant that it ignores the critical
bit. It could even only return "true" (or whatever suits a "all checks
passed, this certificate chain is OK" response).

PKIX can't do much more against non compliant applications.

2013/1/31 Andris Berzins 

> Hello,
>
> Lets assume there is certificate issued by CA where basicConstraints
> CA:FALSE
> and keyUsage extension does not include certSign, but the extensions
> are not marked as critical.
>
> Is it allowed for relying party to use this certificate as CA certificate?
> I know that openssl would not allow that even if extensions are not
> critical,
> but is this a loophole and should it be very much advisable for CA to set
> these extensions as critical?
>


-- 
Erwann.

--14dae9cdc80595db6704d4936412
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

PKIX states that for a certificate to be usable for certificate verificatio=
n, it MUST have both a (MUST be critical) BasicConstraints:CA=3Dtrue and a =
(SHOULD be critical) keyUsage with keyCertSign.
    This is written in sect=
ions 4.2.1.3 and 4.2.1.9 for certificate issuers. This is also repeated in =
section 6.1 (the validation algorithm) for certificate consumers.
    


    X.509 says things differently, the criticality is rever=
sed, but that doesn't really change the result.

    A non compliant application (certificate consumer) could effectively igno=
re non critical extensions and consider that any certificate is potentially=
 a CA one usable for certificate verification. But such a non compliant app=
lication could also be so non compliant that it ignores the critical bit. I=
t could even only return "true" (or whatever suits a "all ch=
ecks passed, this certificate chain is OK" response).
    


    PKIX can't do much more against non compliant appli=
cations.

    2013/1/31 Andris Berzins <pkix@inbo=
x.lv>
    

    Hello,
    

    
Lets assume there is certificate issued by CA where basicConstraints CA:FAL=
SE
    
and keyUsage extension does not include certSign, but the extensions
    
are not marked as critical.
    

    
Is it allowed for relying party to use this certificate as CA certificate?<=
br>
I know that openssl would not allow that even if extensions are not critica=
l,
    
but is this a loophole and should it be very much advisable for CA to set
these extensions as critical?

    =

    -- 
    Erwann.

    

--14dae9cdc80595db6704d4936412--

From bruce.stephens@isode.com  Thu Jan 31 02:52:02 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 CB7D921F869B for ; Thu, 31 Jan 2013 02:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnp4c3FNKXzN for ; Thu, 31 Jan 2013 02:52:01 -0800 (PST)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5CE21F8628 for ; Thu, 31 Jan 2013 02:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1359629519; d=isode.com; s=selector; i=@isode.com; bh=WcAS9kDMgExM6w6yqsCocslCFiogiN5yIRzUB1wvexQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w3w0+n/8/AHiG+A0HcGT+XF4BV8reQWbZuBl3GX09fy47nBwKTLklnasZ3XVggm4uJNhDo PXZh4s19RjQfkjmr+28lNnxZqTrXyCwd2e9TzVyDY8Fld5+WDMSOUqoOGruks2539jW8E5 hIdfWkkbpun6dI6SEBXLl0Uet8W7xzk=;
Received: from tinier.isode.net (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id ; Thu, 31 Jan 2013 10:51:58 +0000
Received: by tinier.isode.net (sSMTP sendmail emulation); Thu, 31 Jan 2013 10:51:58 +0000
From: Bruce Stephens 
To: "Andris Berzins" 
References: <1359627469.510a44cd683e7@mail.inbox.lv>
X-Hashcash: 1:20:130131:pkix@ietf.org::E41wyWhYUuQOGPvC:000008Di
X-Hashcash: 1:20:130131:pkix@inbox.lv::cqIxoTb9H6K+S8CV:00006WRK
Date: Thu, 31 Jan 2013 10:51:58 +0000
In-Reply-To: <1359627469.510a44cd683e7@mail.inbox.lv> (Andris Berzins's message of "Thu, 31 Jan 2013 12:17:49 +0200")
Message-ID: <80622doca9.fsf@tinier.isode.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: pkix@ietf.org
Subject: Re: [pkix] non critical basicConstraints and keyUsage extensions
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, 31 Jan 2013 10:52:02 -0000

"Andris Berzins"  writes:

> Hello,
>  
> Lets assume there is certificate issued by CA where basicConstraints CA:FALSE
> and keyUsage extension does not include certSign, but the extensions
> are not marked as critical.
>
> Is it allowed for relying party to use this certificate as CA certificate?

No. See :

   If the basic constraints extension is not present in a version 3
   certificate, or the extension is present but the cA boolean is not
   asserted, then the certified public key MUST NOT be used to verify
   certificate signatures.

[...]


From david.cooper@nist.gov  Thu Jan 31 06:54: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 58C5B21F863F for ; Thu, 31 Jan 2013 06:54:19 -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_25=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 AUkIcIURKzAx for ; Thu, 31 Jan 2013 06:54:18 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8121F86AD for ; Thu, 31 Jan 2013 06:54:18 -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.2.328.9; Thu, 31 Jan 2013 09:53:57 -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.2.328.9; Thu, 31 Jan 2013 09:54:15 -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 r0VEsE9c021745; Thu, 31 Jan 2013 09:54:15 -0500
Message-ID: <510A8596.6090207@nist.gov>
Date: Thu, 31 Jan 2013 09:54:14 -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: Andris Berzins 
References: <1359627469.510a44cd683e7@mail.inbox.lv>
In-Reply-To: <1359627469.510a44cd683e7@mail.inbox.lv>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] non critical basicConstraints and keyUsage extensions
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, 31 Jan 2013 14:54:19 -0000

It's not really a loophole.  RFC 5280, similar to X.509, already says:

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

Since it would be difficult to find path validation software that does 
not recognize these extensions, it would be difficult to find path 
validation software that could comply with this aspect of the standard 
and still not process the contents of these extensions, even if they 
were marked as non-critical.  Furthermore, Section 4.2 of RFC 5280 
requires conforming applications to recognize these extensions.

In addition, RFC 5280 already says that conforming CAs SHOULD mark the 
keyUsage extension as critical.

Finally, as noted before, the basicConstraints extension is somewhat 
"special" in that the path processing rules state for a version 3 
intermediate certificate, the application must "verify that the 
basicConstraints extension is present and that cA is set to TRUE."  If 
an application couldn't recognize the basicConstraints extension then it 
couldn't verify that it is present.

On 01/31/2013 05:17 AM, Andris Berzins wrote:
> Hello,
>   
> Lets assume there is certificate issued by CA where basicConstraints CA:FALSE
> and keyUsage extension does not include certSign, but the extensions
> are not marked as critical.
>
> Is it allowed for relying party to use this certificate as CA certificate?
> I know that openssl would not allow that even if extensions are not critical,
> but is this a loophole and should it be very much advisable for CA to set
> these extensions as critical?
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>


From mrex@sap.com  Thu Jan 31 07:21: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 DB2BB21F84F9 for ; Thu, 31 Jan 2013 07:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Level: 
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psbI-PxtXPnB for ; Thu, 31 Jan 2013 07:21:59 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CC64821F846E for ; Thu, 31 Jan 2013 07:21:58 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0VFLunp001705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 16:21:56 +0100 (MET)
In-Reply-To: <80622doca9.fsf@tinier.isode.net>
To: Bruce Stephens 
Date: Thu, 31 Jan 2013 16:21:56 +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: <20130131152156.AD23F1A4E6@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: pkix@ietf.org
Subject: Re: [pkix] non critical basicConstraints and keyUsage extensions
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 15:22:00 -0000

Bruce Stephens wrote:
> "Andris Berzins"  writes:
> > 
> > Lets assume there is certificate issued by CA where basicConstraints
> > CA:FALSE and keyUsage extension does not include certSign, but the
> > extensions are not marked as critical.
> >
> > Is it allowed for relying party to use this certificate as CA certificate?
> 
> No. See :
> 
>    If the basic constraints extension is not present in a version 3
>    certificate, or the extension is present but the cA boolean is not
>    asserted, then the certified public key MUST NOT be used to verify
>    certificate signatures.

Technically, the _above_ pointer into rfc5280 is wrong.  ;-)

rfc5280  is very explicit and RECOMMENDs __against__ including conformance
checks to the requirements listed in Section 4 and 5 of rfc5280!


  rfc5280, Section 6.1 Basic Path Validation (3rd paragraph):

  http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
*> profile.  While the algorithm could be extended to include checks for
*> conformance to the profiles in Sections 4 and 5, this profile
*> RECOMMENDS against including such checks.


Therefore the appropriate pointers would be either

  rfc5280, Section 6.1 Basic Path Processing

     6.1.4  Preparation for Certificate i+1

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

or

  ITU T-REC X.509 08/2005  Section 10.5 Certificate processing

   10.5.1 Basic certificate checks

   The following checks are applied to a certificate. Self-signed
   certificates, if encountered in the path, are ignored.

      b) For an intermediate version 3 certificate, check that
         basicConstraints is present and that the cA component
         in the basicConstraints extension is TRUE. If the
         pathLenConstraint component is present, check that the
         current certification path does not violate that constraint
         (ignoring intermediate self-issued certificates).


-Martin

From paul.hoffman@vpnc.org  Thu Jan 31 07:32: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 4E17A21F842C for ; Thu, 31 Jan 2013 07:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztx1MZ16aP1T for ; Thu, 31 Jan 2013 07:32:26 -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 E675221F83EF for ; Thu, 31 Jan 2013 07:32:25 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0VFWN3I005472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jan 2013 08:32:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: <1359627469.510a44cd683e7@mail.inbox.lv>
Date: Thu, 31 Jan 2013 07:32:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1359627469.510a44cd683e7@mail.inbox.lv>
To: Andris Berzins 
X-Mailer: Apple Mail (2.1499)
Cc: pkix@ietf.org
Subject: Re: [pkix] non critical basicConstraints and keyUsage extensions
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, 31 Jan 2013 15:32:26 -0000

On Jan 31, 2013, at 2:17 AM, Andris Berzins  wrote:

> Is it allowed for relying party to use this certificate as CA =
certificate?

Allow me to throw a wrench in here. Did you mean "use this certificate =
as a CA certificate" or "use the key in this certificate as a trust =
anchor"? Those are two different questions that are often confused in =
practice.

--Paul Hoffman


From Internet-Drafts@ietf.org  Thu Jan 31 08:06:29 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 6EC8421F85E0; Thu, 31 Jan 2013 08:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 7+aCKKsEfwHU; Thu, 31 Jan 2013 08:06:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2BF21F842A; Thu, 31 Jan 2013 08:06:29 -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.37
Message-ID: <20130131160629.19095.17903.idtracker@ietfa.amsl.com>
Date: Thu, 31 Jan 2013 08:06:29 -0800
Cc: pkix@ietf.org
Subject: [pkix] I-D ACTION:draft-ietf-pkix-rfc2560bis-13.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 16:06:29 -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          : Jan. 31, 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-13.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-01-31080629.I-D@ietf.org>


--NextPart--