From internet-drafts@ietf.org Wed Mar 7 12:47:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5421F8778; Wed, 7 Mar 2012 12:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JcFL5hGeKpr; Wed, 7 Mar 2012 12:47:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6B21F8772; Wed, 7 Mar 2012 12:47:41 -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.00 Message-ID: <20120307204741.19792.76148.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 12:47:41 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-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, 07 Mar 2012 20:47:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-05.txt Pages : 16 Date : 2012-03-07 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt From hallam@gmail.com Wed Mar 7 12:55:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1024711E80AE for ; Wed, 7 Mar 2012 12:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGF-DQIRV154 for ; Wed, 7 Mar 2012 12:55:42 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E011E8098 for ; Wed, 7 Mar 2012 12:55:41 -0800 (PST) Received: by obbta4 with SMTP id ta4so6318528obb.31 for ; Wed, 07 Mar 2012 12:55:41 -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 :content-type:content-transfer-encoding; bh=wNp08vQ/NZWL3NbhMuS4BYijOroAOGhAB13Pm3pd7kI=; b=yzwcLGg4AImljXm9jh3NBKom/8E4vr0epYVZIM2dt9oO2SSbDolOzynzstDV5hZ6Rm K+keEsnSzIy08fxymNHkTXKTBK6Twa7A7iutj+HNbP+d6Vf2izrFEB3lYX3svUS3cgVj oPGk+7F1EZB0CrEHCj2o/BDYzmnhMbxLolg0qREBTZLYnfRQrpFjx+xLziNVcbgF00xh Q9qMWIJPAm3N/6l4DxGGBxbZjFXlLtFq387uDaW4Vo231dZbtFHEPq9t4fdB42QWhkqg 4wCgKdgTvwo9tCTPN87YjPjfLO8R6vPRXIfTbPEurD2ibMsAUWBZ5i1YBXtqVvscgdiW aAtw== MIME-Version: 1.0 Received: by 10.182.38.8 with SMTP id c8mr1371965obk.34.1331153741405; Wed, 07 Mar 2012 12:55:41 -0800 (PST) Received: by 10.182.121.34 with HTTP; Wed, 7 Mar 2012 12:55:41 -0800 (PST) In-Reply-To: <20120307204741.19792.76148.idtracker@ietfa.amsl.com> References: <20120307204741.19792.76148.idtracker@ietfa.amsl.com> Date: Wed, 7 Mar 2012 15:55:41 -0500 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-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, 07 Mar 2012 20:55:43 -0000 This has only got one major change, and this is to tweak the definition of the Extended Issuer Authorization set so that it is now strictly hierarchical. While doing this, I decided that the term 'public delegation point' was most likely to be interpreted as being the suffix under which names are delegated rather than the delegation. [i.e. the PDP for example.com would be .com]. I tried to fix that but I have just noticed that I wrote prefix rather than suffix. I have corrected the editors copy and will roll that with any other changes that are proposed. On Wed, Mar 7, 2012 at 3:47 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Public-Key Infrastructure (X.509) W= orking Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : DNS Certification Authority Au= thorization (CAA) Resource Record > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Phillip Hallam-Baker > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rob Stradling > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-pkix-caa-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-07 > > =A0 The Certification Authority Authorization (CAA) DNS Resource Record > =A0 allows a DNS domain name holder to specify the certificate signing > =A0 certificate(s) authorized to issue certificates for that domain. =A0C= AA > =A0 resource records allow a public Certification Authority to implement > =A0 additional controls to reduce the risk of unintended certificate mis- > =A0 issue. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From tgindin@us.ibm.com Sat Mar 10 09:50:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1821F858A for ; Sat, 10 Mar 2012 09:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.283 X-Spam-Level: X-Spam-Status: No, score=-9.283 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5UiYRCIr2Tr for ; Sat, 10 Mar 2012 09:50:46 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3829421F8581 for ; Sat, 10 Mar 2012 09:50:44 -0800 (PST) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 10 Mar 2012 12:50:38 -0500 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 10 Mar 2012 12:50:23 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id C1B9E6E8049 for ; Sat, 10 Mar 2012 12:50:22 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2AHoMdL147636 for ; Sat, 10 Mar 2012 12:50:22 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2AHoMUL008397 for ; Sat, 10 Mar 2012 14:50:22 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2AHoMXt008383 for ; Sat, 10 Mar 2012 14:50:22 -0300 To: pkix MIME-Version: 1.0 X-KeepSent: 5B4C989F:BC524606-852579B2:000E0C69; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Sat, 10 Mar 2012 12:50:20 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/10/2012 12:50:21, Serialize complete at 03/10/2012 12:50:21 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12031017-1976-0000-0000-00000B5A201E Subject: [pkix] Possible OCSP 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: Sat, 10 Mar 2012 17:50:52 -0000 Why isn't there an OCSP response extension containing "never issued" or "outside validity period" which a responder may use if they have the CA's certificate repository available? Getting a request that produces such an error would not be anything which the responder would be expected to report. A client who had received a response with such an extension could then demonstrate that an actual compromise had occurred by resending the request with a request extension containing the actual certificate, or perhaps the chain, which had provoked that response extension above. Receiving such a certificate would allow the OCSP server to verify that the CA had actually been cracked and then react. I think that such a feature would be useful to responders operated by a CA with many subordinate CA's, and possibly to others as well. Tom Gindin P.S. - The above suggestion is mine, and not necessarily that of my employer. From hallam@gmail.com Sun Mar 11 09:17:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0925621F8750 for ; Sun, 11 Mar 2012 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbX7rBla3NVW for ; Sun, 11 Mar 2012 09:17:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C45AC21F874C for ; Sun, 11 Mar 2012 09:17:54 -0700 (PDT) Received: by yenm5 with SMTP id m5so2132950yen.31 for ; Sun, 11 Mar 2012 09:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PRy8Ys2X+UYjSFT4kwgCHVYuJzk4bYfoc8EU92nZfAw=; b=jfFfA56Tk/2NayC7++7o6El73Kxd1WBRVNsEnvWRhbQnN6i9YNB3uF433urFUkSgJk EXq2DIfPpYK/b+Duj8195jN+lFwpeM8pFyQQ8fzBg+j9tp1z9Rui2bxvAjpFqwQ0eBBG 6n9suBH9EADdtbYq5DHDBsWPlTuhKDlmuw28rxD+ZMFpBHfUFj+/S3UH83EXWsLxub22 kiCuyCjzt+Xm1n9DK4ZlcIUzyFVqg+mctOtoKn/t4fM4+GOyLJkdiEoXgQ+b52+JFdoD CeqXr3DfmN0ZlRfa2d7aemoZo3EVJ0vYH3zPiExpTNcOwrEHBnAk95q1LkcPXkEt5T3/ OtEg== MIME-Version: 1.0 Received: by 10.60.30.66 with SMTP id q2mr4771258oeh.25.1331482673984; Sun, 11 Mar 2012 09:17:53 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Sun, 11 Mar 2012 09:17:53 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Mar 2012 12:17:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Tom Gindin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Sun, 11 Mar 2012 16:17:56 -0000 I think it would be good to have a way to state precisely what the server knows about the certificate. This can lead to problems though if the OCSP server is on a batch update from the certificate service. If we are going to make this scale it has to be possible to pre-sign the proofs of non-existence as an option. That means adopting the NSEC-type approach of signing the gaps between the existing records. So what I think is needed is actually two pieces of response data: 1) This service has no knowledge of any certificate between serial # X and = Y 2) This assertion was generated from data current at time X The signing time is arguably a proxy for the second - or could be made such= . What I totally reject is the notion that we should constrain the spec according to the architecture of certain third party OCSP responders as has been proposed in the past. The CAs have this data and the relying apps have a purpose that requires it. There may well be a role for fourth parties (not a CA, subject or RP) to add value to PKIX certificates as I have proposed on the Right Key list. I just don't think OCSP is the right protocol for doing that. Nor is DNS. On Sat, Mar 10, 2012 at 12:50 PM, Tom Gindin wrote: > =A0 =A0 =A0 =A0Why isn't there an OCSP response extension containing "nev= er > issued" or "outside validity period" which a responder may use if they > have the CA's certificate repository available? =A0Getting a request that > produces such an error would not be anything which the responder would be > expected to report. =A0A client who had received a response with such an > extension could then demonstrate that an actual compromise had occurred b= y > resending the request with a request extension containing the actual > certificate, or perhaps the chain, which had provoked that response > extension above. =A0Receiving such a certificate would allow the OCSP ser= ver > to verify that the CA had actually been cracked and then react. > =A0 =A0 =A0 =A0I think that such a feature would be useful to responders = operated > by a CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my > employer. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From piyush@identicate.com Sun Mar 11 10:17:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4621F870E for ; Sun, 11 Mar 2012 10:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AoabZVZ9hF5 for ; Sun, 11 Mar 2012 10:17:44 -0700 (PDT) Received: from col0-omc4-s16.col0.hotmail.com (col0-omc4-s16.col0.hotmail.com [65.55.34.218]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9621F8682 for ; Sun, 11 Mar 2012 10:17:44 -0700 (PDT) Received: from COL119-DS23 ([65.55.34.201]) by col0-omc4-s16.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 10:17:43 -0700 X-Originating-IP: [75.25.128.241] X-Originating-Email: [piyush@identicate.com] Message-ID: From: Piyush Jain To: "'Tom Gindin'" , "'pkix'" References: In-Reply-To: Date: Sun, 11 Mar 2012 10:17:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHHYhp/Z8CsTtQObM6EQ37Pn1ZUI5ZwjxbA Content-Language: en-us X-OriginalArrivalTime: 11 Mar 2012 17:17:43.0949 (UTC) FILETIME=[DF1AA3D0:01CCFFAA] Subject: Re: [pkix] Possible OCSP 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: Sun, 11 Mar 2012 17:17:45 -0000 Is this trying to address the case where CA continues to operate after it has been compromised? I'm assuming that in this case EE certificates have been signed using the CA key and somehow deleted from the CA's issued certificates repository. What happens if the attacker issued an OCSP signing certificate (with OCSP-no-check) as opposed to an EE certificate? Many of us would believe that only way to address this breach is to revoke the CA. There could be limited use of this extension for the CA to determine if it has been compromised. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Tom Gindin > Sent: Saturday, March 10, 2012 9:50 AM > To: pkix > Subject: [pkix] Possible OCSP Extensions > > Why isn't there an OCSP response extension containing "never issued" or > "outside validity period" which a responder may use if they have the CA's > certificate repository available? Getting a request that produces such an > error would not be anything which the responder would be expected to > report. A client who had received a response with such an extension could > then demonstrate that an actual compromise had occurred by resending the > request with a request extension containing the actual certificate, or perhaps > the chain, which had provoked that response extension above. Receiving > such a certificate would allow the OCSP server to verify that the CA had > actually been cracked and then react. > I think that such a feature would be useful to responders operated by a > CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my employer. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Sun Mar 11 20:50:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4528321F8557 for ; Sun, 11 Mar 2012 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFVZhIpmPUTC for ; Sun, 11 Mar 2012 20:50:48 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C021F854A for ; Sun, 11 Mar 2012 20:50:48 -0700 (PDT) Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 11 Mar 2012 23:50:47 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 11 Mar 2012 23:50:45 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8AF3D38C805A for ; Sun, 11 Mar 2012 23:50:44 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2C3oi7g3596468 for ; Sun, 11 Mar 2012 23:50:44 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2C3ogPZ028142 for ; Mon, 12 Mar 2012 00:50:43 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2C3of8w028097; Mon, 12 Mar 2012 00:50:41 -0300 In-Reply-To: References: To: Piyush Jain , Phillip Hallam-Baker MIME-Version: 1.0 X-KeepSent: 821F8D43:80DC6D9E-852579BF:000F0A91; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Sun, 11 Mar 2012 23:50:41 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/11/2012 23:50:41, Serialize complete at 03/11/2012 23:50:41 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12031203-5930-0000-0000-000006024FB9 Cc: 'pkix' Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 03:50:49 -0000 Piyush: One purpose of this is to identify cases where the issuer has apparently been compromised, and the major purpose of the request extension (call it "requested certificate body" or "requested certificate chain") is to allow such a case to be substantiated. Once the request is substantiated, I would expect the issuer key to be treated as compromised unless the submitted certificate is a digest duplicate against an actual issued certificate. That would be an algorithmic issue rather than a key compromise. I'd like to adapt part of Phill's suggestion, and redefine the proposed "never issued" status as "Not issued before" and a time. The presigned variant, which might be called "no serial number within range", seems right for issuers with increasing serial numbers but makes less sense for issuers who assign serial numbers which don't monotonically increase with time. Phill, is that supposed to be the closed interval (with the two endpoint serial numbers not issued) or the open one (with the two endpoint serial numbers issued)? Also, is there an option in which the upper bound is not specified which means "no serial number above L had been issued as of time T"? Tom Gindin From: Piyush Jain To: Tom Gindin/Watson/IBM@IBMUS, "'pkix'" , Date: 03/11/2012 01:17 PM Subject: RE: [pkix] Possible OCSP Extensions Is this trying to address the case where CA continues to operate after it has been compromised? I'm assuming that in this case EE certificates have been signed using the CA key and somehow deleted from the CA's issued certificates repository. What happens if the attacker issued an OCSP signing certificate (with OCSP-no-check) as opposed to an EE certificate? Many of us would believe that only way to address this breach is to revoke the CA. There could be limited use of this extension for the CA to determine if it has been compromised. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Tom Gindin > Sent: Saturday, March 10, 2012 9:50 AM > To: pkix > Subject: [pkix] Possible OCSP Extensions > > Why isn't there an OCSP response extension containing "never issued" or > "outside validity period" which a responder may use if they have the CA's > certificate repository available? Getting a request that produces such an > error would not be anything which the responder would be expected to > report. A client who had received a response with such an extension could > then demonstrate that an actual compromise had occurred by resending the > request with a request extension containing the actual certificate, or perhaps > the chain, which had provoked that response extension above. Receiving > such a certificate would allow the OCSP server to verify that the CA had > actually been cracked and then react. > I think that such a feature would be useful to responders operated by a > CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my employer. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Mon Mar 12 05:57:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4C21F87B4 for ; Mon, 12 Mar 2012 05:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjL0K+ClusZr for ; Mon, 12 Mar 2012 05:57:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D739D21F86C8 for ; Mon, 12 Mar 2012 05:57:21 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2884981ggm.31 for ; Mon, 12 Mar 2012 05:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pilNm7rfJeSuP5orwEsnCQHb8VJKi13pCdHqQOwEem4=; b=kyGanys/FUxUnFn70lQ266d8fnjav729SPaRN2qxw/bl7hb+mWiwB+z7fq4i0/OH4h yKpjedMuKaRuBYc5PZVUlQlk6dXhouHinDMvsVtmoMwL3FlXq2AlTdnBvX0bF4Fo/eA1 jzNT83fRxYpU+kh5Nz1Lkz7IRyH9RUtIODJuVHvjKXPayz3sAbjsAZxAD7YAcIf/AofD NcccDGwfzfdECP4ylxg4vo9fIAHZEzFc+a373WD/gVzAm4Mg2cXEctHwCd81A8e86f+V xPn4F761ospMrkFKaAJJBj2uyQdYPUmCWNSRdORNlW6GjNcHj6JToRr6Lkrb/nSka0U6 7UFA== MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr7467084obb.25.1331557041428; Mon, 12 Mar 2012 05:57:21 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 12 Mar 2012 05:57:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Mar 2012 08:57:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Piyush Jain Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 12:57:22 -0000 And many of us think that we should fix the damn spec to do what it was originally intended to do until a bunch of people with a business model and a startup ruined it. There are many reasons why this functionality would be required. There are tens of thousands of certs revoked for cause every year. less than 1% of those so revoked last year were due to mis-issue. Why do we have so many people obsessing about what has been the rarest use case for OCSP and not the fact that the browsers don't actually hard fail on OSCP? On Sun, Mar 11, 2012 at 1:17 PM, Piyush Jain wrote: > Is this trying to address the case where CA continues to operate after it > has been compromised? > I'm assuming that in this case EE certificates have been signed using the= CA > key and somehow deleted from the CA's issued certificates repository. > What happens if the attacker issued an OCSP signing certificate (with > OCSP-no-check) as opposed to an EE certificate? > > Many of us would believe that only way to address this breach is to revok= e > the CA. > > There could be limited use of this extension for the CA to determine if i= t > has been compromised. > > -Piyush > > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Tom Gindin >> Sent: Saturday, March 10, 2012 9:50 AM >> To: pkix >> Subject: [pkix] Possible OCSP Extensions >> >> =A0 =A0 =A0 =A0 Why isn't there an OCSP response extension containing "n= ever > issued" or >> "outside validity period" which a responder may use if they have the CA'= s >> certificate repository available? =A0Getting a request that produces suc= h an >> error would not be anything which the responder would be expected to >> report. =A0A client who had received a response with such an extension c= ould >> then demonstrate that an actual compromise had occurred by resending the >> request with a request extension containing the actual certificate, or > perhaps >> the chain, which had provoked that response extension above. =A0Receivin= g >> such a certificate would allow the OCSP server to verify that the CA had >> actually been cracked and then react. >> =A0 =A0 =A0 =A0 I think that such a feature would be useful to responder= s operated > by a >> CA with many subordinate CA's, and possibly to others as well. >> >> Tom Gindin >> P.S. - The above suggestion is mine, and not necessarily that of my > employer. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Mon Mar 12 06:29:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88421F8683 for ; Mon, 12 Mar 2012 06:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0-Y4H9MDHuu for ; Mon, 12 Mar 2012 06:29:37 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1501621F867A for ; Mon, 12 Mar 2012 06:29:37 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2903458yhp.31 for ; Mon, 12 Mar 2012 06:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lMs5zXEWQm88K7+tLll2flMq0tkC2xDe1TJJEUgOTII=; b=grsKL7cM+ZkpcYhpnwWgkYo1w+kAIRo9ZsAh6EofcDUg8RDxY9Ds2t1veoV44Qeh5c bzjKSGujhVOpdH7kcTpcHGGEW85wGDMSrHGex513yJJ5JMxq3ppZNJ4/YNs0IURueLZ1 FWudmRVQTnn6G5v1PwYUdluBihzazSd5gfnW1wd4CqsrhRsjh2bK0x7TeRwxn8H8NK2F KK40kOG98GXWCTlmNYmOPqOwY0/UpZZDEP7/LDSJyrErLxqxsNCWww0g/ktKsGu4F5nr 37E6qTF2Hifrv7n6oke00QUBEquNZDQA+7y0GxjpMkqbXAkBlaI9vGG9oMP4wrCrGmCQ AlMA== MIME-Version: 1.0 Received: by 10.60.30.66 with SMTP id q2mr7418328oeh.25.1331558976487; Mon, 12 Mar 2012 06:29:36 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 12 Mar 2012 06:29:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Mar 2012 09:29:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Tom Gindin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 13:29:38 -0000 Actually, the idea for the serial numbers was not that they would necessarily be monotonic, rather the idea is just to sign the gaps. If the CA signs non-monotonic serial numbers then they would have to sort them into order first. So the way a CA would work is that every OCSP signing increment, say 1 hour, they would create OCSP responses for 1) Every known cert issued 2) The gaps between the serial numbers. So with 100 certs issued, this would be 200 OCSP responses. If a cert is issued within that time interval, the CA creates three additional OCSP responses, one for the new cert and two for the new serial number intervals that have just been created. This approach allows CAs to avoid creating additional timing errors but is still robust if they are introduced by others. On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin wrote: > =A0 =A0 =A0 =A0Piyush: > > =A0 =A0 =A0 =A0One purpose of this is to identify cases where the issuer = has > apparently been compromised, and the major purpose of the request > extension (call it "requested certificate body" or "requested certificate > chain") is to allow such a case to be substantiated. =A0Once the request = is > substantiated, I would expect the issuer key to be treated as compromised > unless the submitted certificate is a digest duplicate against an actual > issued certificate. =A0That would be an algorithmic issue rather than a k= ey > compromise. > =A0 =A0 =A0 =A0I'd like to adapt part of Phill's suggestion, and redefine= the > proposed "never issued" status as "Not issued before" and a time. =A0The > presigned variant, which might be called "no serial number within range", > seems right for issuers with increasing serial numbers but makes less > sense for issuers who assign serial numbers which don't monotonically > increase with time. =A0Phill, is that supposed to be the closed interval > (with the two endpoint serial numbers not issued) or the open one (with > the two endpoint serial numbers issued)? =A0Also, is there an option in > which the upper bound is not specified which means "no serial number abov= e > L had been issued as of time T"? > > > Tom Gindin > > > > > > From: =A0 Piyush Jain > To: =A0 =A0 Tom Gindin/Watson/IBM@IBMUS, "'pkix'" , > Date: =A0 03/11/2012 01:17 PM > Subject: =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions > > > > Is this trying to address the case where CA continues to operate after it > has been compromised? > I'm assuming that in this case EE certificates have been signed using the > CA > key and somehow deleted from the CA's issued certificates repository. > What happens if the attacker issued an OCSP signing certificate (with > OCSP-no-check) as opposed to an EE certificate? > > Many of us would believe that only way to address this breach is to revok= e > the CA. > > There could be limited use of this extension for the CA to determine if i= t > has been compromised. > > -Piyush > > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Tom Gindin >> Sent: Saturday, March 10, 2012 9:50 AM >> To: pkix >> Subject: [pkix] Possible OCSP Extensions >> >> =A0 =A0 =A0 =A0 Why isn't there an OCSP response extension containing "n= ever > issued" or >> "outside validity period" which a responder may use if they have the > CA's >> certificate repository available? =A0Getting a request that produces suc= h > an >> error would not be anything which the responder would be expected to >> report. =A0A client who had received a response with such an extension > could >> then demonstrate that an actual compromise had occurred by resending the >> request with a request extension containing the actual certificate, or > perhaps >> the chain, which had provoked that response extension above. =A0Receivin= g >> such a certificate would allow the OCSP server to verify that the CA had >> actually been cracked and then react. >> =A0 =A0 =A0 =A0 I think that such a feature would be useful to responder= s > operated > by a >> CA with many subordinate CA's, and possibly to others as well. >> >> Tom Gindin >> P.S. - The above suggestion is mine, and not necessarily that of my > employer. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > --=20 Website: http://hallambaker.com/ From rob.stradling@comodo.com Mon Mar 12 06:45:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B7821F878E for ; Mon, 12 Mar 2012 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibbKw-Jg5-qK for ; Mon, 12 Mar 2012 06:45:41 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id C47B421F8776 for ; Mon, 12 Mar 2012 06:45:37 -0700 (PDT) Received: (qmail 14929 invoked from network); 12 Mar 2012 13:45:36 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Mar 2012 13:45:36 -0000 Received: (qmail 15540 invoked by uid 1000); 12 Mar 2012 13:45:36 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 12 Mar 2012 13:45:36 +0000 Message-ID: <4F5DFDE8.3010207@comodo.com> Date: Mon, 12 Mar 2012 13:45:12 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 13:45:43 -0000 On 12/03/12 13:29, Phillip Hallam-Baker wrote: > Actually, the idea for the serial numbers was not that they would > necessarily be monotonic, rather the idea is just to sign the gaps. If > the CA signs non-monotonic serial numbers then they would have to sort > them into order first. > > So the way a CA would work is that every OCSP signing increment, say 1 > hour, they would create OCSP responses for > > 1) Every known cert issued > 2) The gaps between the serial numbers. > > So with 100 certs issued, this would be 200 OCSP responses. > > > If a cert is issued within that time interval, the CA creates three > additional OCSP responses, one for the new cert and two for the new > serial number intervals that have just been created. > > This approach allows CAs to avoid creating additional timing errors > but is still robust if they are introduced by others. The CA may have issued three additional OCSP Responses, but how do you force clients to use them instead of cached copies of the previous Responses? Would the Responder have to set the various HTTP "no cache" headers when it sends a "gaps between the serial numbers" Response? Or would we just have to accept that newly issued certs may cause spurious OCSP errors within the first 1 hour of their lifetime? > On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin wrote: >> Piyush: >> >> One purpose of this is to identify cases where the issuer has >> apparently been compromised, and the major purpose of the request >> extension (call it "requested certificate body" or "requested certificate >> chain") is to allow such a case to be substantiated. Once the request is >> substantiated, I would expect the issuer key to be treated as compromised >> unless the submitted certificate is a digest duplicate against an actual >> issued certificate. That would be an algorithmic issue rather than a key >> compromise. >> I'd like to adapt part of Phill's suggestion, and redefine the >> proposed "never issued" status as "Not issued before" and a time. The >> presigned variant, which might be called "no serial number within range", >> seems right for issuers with increasing serial numbers but makes less >> sense for issuers who assign serial numbers which don't monotonically >> increase with time. Phill, is that supposed to be the closed interval >> (with the two endpoint serial numbers not issued) or the open one (with >> the two endpoint serial numbers issued)? Also, is there an option in >> which the upper bound is not specified which means "no serial number above >> L had been issued as of time T"? >> >> >> Tom Gindin >> >> >> >> >> >> From: Piyush Jain >> To: Tom Gindin/Watson/IBM@IBMUS, "'pkix'", >> Date: 03/11/2012 01:17 PM >> Subject: RE: [pkix] Possible OCSP Extensions >> >> >> >> Is this trying to address the case where CA continues to operate after it >> has been compromised? >> I'm assuming that in this case EE certificates have been signed using the >> CA >> key and somehow deleted from the CA's issued certificates repository. >> What happens if the attacker issued an OCSP signing certificate (with >> OCSP-no-check) as opposed to an EE certificate? >> >> Many of us would believe that only way to address this breach is to revoke >> the CA. >> >> There could be limited use of this extension for the CA to determine if it >> has been compromised. >> >> -Piyush >> >> >> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Tom Gindin >>> Sent: Saturday, March 10, 2012 9:50 AM >>> To: pkix >>> Subject: [pkix] Possible OCSP Extensions >>> >>> Why isn't there an OCSP response extension containing "never >> issued" or >>> "outside validity period" which a responder may use if they have the >> CA's >>> certificate repository available? Getting a request that produces such >> an >>> error would not be anything which the responder would be expected to >>> report. A client who had received a response with such an extension >> could >>> then demonstrate that an actual compromise had occurred by resending the >>> request with a request extension containing the actual certificate, or >> perhaps >>> the chain, which had provoked that response extension above. Receiving >>> such a certificate would allow the OCSP server to verify that the CA had >>> actually been cracked and then react. >>> I think that such a feature would be useful to responders >> operated >> by a >>> CA with many subordinate CA's, and possibly to others as well. >>> >>> Tom Gindin >>> P.S. - The above suggestion is mine, and not necessarily that of my >> employer. >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> > > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From denis.pinkas@bull.net Mon Mar 12 06:45:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676B521F8790 for ; Mon, 12 Mar 2012 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw5pzeG7c2Hb for ; Mon, 12 Mar 2012 06:45:52 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2021F875B for ; Mon, 12 Mar 2012 06:45:52 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 523FA180FB; Mon, 12 Mar 2012 14:45:51 +0100 (CET) In-Reply-To: References: To: Tom Gindin MIME-Version: 1.0 X-KeepSent: 6FA79A7E:8F4431A3-C12579BF:00481F74; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 12 Mar 2012 14:45:49 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 12/03/2012 14:45:50, Serialize complete at 12/03/2012 14:45:50 Content-Type: multipart/alternative; boundary="=_alternative 004B8B9DC12579BF_=" Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 13:45:53 -0000 Message en plusieurs parties au format MIME --=_alternative 004B8B9DC12579BF_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Your email is not crystal clear (at least to me) and seems to address at=20 the same time two different topics: - an OCSP response extension containing "never issued" and - an OCSP response extension containing "outside validity period".=20 I can understand "never issued", but I don't know what you mean, in the=20 context of OCSP, with "outside validity period" Your proposal seems allowing an OCSP server "to verify that a CA had=20 actually been cracked and then react". The problem is that we cannot do this, until we first specify a way to=20 return a status like "never issued". Simply adding an additional status report like "never issued" would not be = sufficient as explained below. The problem is that OSCP was originally designed to work either : - with CRLs only, or=20 - with a revocation status data base for revoked certificates only, or - with a revocation status data base for all issued certificates managed=20 directly by the CA which issued that certificate. We currently have no way to indicate either in the request or in the=20 response=20 which of the three modes is/was requested or used. An OCSP server might only indicate "never issued", if it also indicates=20 that it got this information using=20 a revocation status data base for all issued certificates managed directly = by the CA which has issued that certificate. This means that this extension may only be present if the OCSP responder=20 is using a revocation status data base=20 for all issued certificates managed directly by the CA which has issued=20 that certificate. =20 This extension would then contain a boolean to say whether of not the=20 certificate was issued. I remember that we discuss this topic on the PKIX list but I don't=20 remember any concrete proposal. Once we have such a mechanism (or a similar one), then we can build on it=20 and discuss (and understand better) your proposal. Denis De : Tom Gindin A : pkix Date : 10/03/2012 18:51 Objet : [pkix] Possible OCSP Extensions Envoy=E9 par : pkix-bounces@ietf.org Why isn't there an OCSP response extension containing "never=20 issued" or "outside validity period" which a responder may use if they=20 have the CA's certificate repository available? Getting a request that=20 produces such an error would not be anything which the responder would be=20 expected to report. A client who had received a response with such an=20 extension could then demonstrate that an actual compromise had occurred by = resending the request with a request extension containing the actual=20 certificate, or perhaps the chain, which had provoked that response=20 extension above. Receiving such a certificate would allow the OCSP server = to verify that the CA had actually been cracked and then react. I think that such a feature would be useful to responders operated = by a CA with many subordinate CA's, and possibly to others as well. Tom Gindin P.S. - The above suggestion is mine, and not necessarily that of my=20 employer. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004B8B9DC12579BF_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom,

Your email is not crystal clear (at least to me) and seems to address at the same time two different topics:
   - an OCSP response extension containing "never issued" and
  - an OCSP response extension conta= ining "outside validity period".

I can understand "never issued&= quot;, but I don't know what you mean, in the context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP serv= er "to verify that a CA had actually been cracked and then react".
The problem is that we cannot do this, un= til we first specify a way to return a status like "never issued".

Simply adding an additional status r= eport like "never issued" would not be sufficient as explained below.

The problem is that OSCP was origina= lly designed to work either :

 - with CRLs only, or
 - with a revocation status data base for revoked certificates only, or
 - with a revocation status data base for all issued certificates managed directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the response
which of the three modes is/was requested or used.

An OCSP server might only indicate &= quot;never issued", if  it also indicates that it got this information using
a revocation status data base for all issued certificates managed directly by the CA which has issued that certificate.

This means that this extension may o= nly be present if the OCSP responder is using  a revocation status data base
for all issued certificates managed directly by the CA which has issued that certificate.
 
This extension would then contain a boolean to say whether of not the certi= ficate was issued.

I remember that we discuss this topic on the PKIX  list but I don't remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it and discuss (and understand better) your proposal.

Denis




De :     &= nbsp;  Tom Gindin <tgindin@us.i= bm.com>
A :     &n= bsp;  pkix <pkix@ietf.org><= /font>
Date :    =    10/03/2012 18:51
Objet :        [pkix] Possible OCSP Extensions
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



        Why isn't there an OCSP response extension containing "never
issued" or "outside validity period" which a responder may use if they
have the CA's certificate repository available?  Getting a request that
produces such an error would not be anything which the responder would be
expected to report.  A client who had received a response with such an
extension could then demonstrate that an actual compromise had occurred by
resending the request with a request extension containing the actual
certificate, or perhaps the chain, which had provoked that response
extension above.  Receiving such a certificate would allow the OCSP server
to verify that the CA had actually been cracked and then react.
       I think that such a feature would be useful to responders operated
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my
employer.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 004B8B9DC12579BF_=-- From tgindin@us.ibm.com Mon Mar 12 07:21:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6979C21F87EC for ; Mon, 12 Mar 2012 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.721 X-Spam-Level: X-Spam-Status: No, score=-9.721 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nvgl748y2tF for ; Mon, 12 Mar 2012 07:21:44 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6E221F87E8 for ; Mon, 12 Mar 2012 07:21:44 -0700 (PDT) Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Mar 2012 10:21:41 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e3.ny.us.ibm.com (192.168.1.103) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 12 Mar 2012 10:20:42 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1EF326E805E for ; Mon, 12 Mar 2012 10:20:42 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2CEKfkS188592 for ; Mon, 12 Mar 2012 10:20:41 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2CEKecq021455 for ; Mon, 12 Mar 2012 11:20:41 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2CEKYat020804; Mon, 12 Mar 2012 11:20:39 -0300 In-Reply-To: References: To: denis.pinkas@bull.net MIME-Version: 1.0 X-KeepSent: A1AF68F0:B03C9E86-852579BF:004C98A8; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Mon, 12 Mar 2012 10:20:32 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/12/2012 10:20:39, Serialize complete at 03/12/2012 10:20:39 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12031214-8974-0000-0000-0000072E63AC Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 14:21:45 -0000 Denis: "Outside validity period" means, in most cases, that the serial=20 number requested was indeed issued by the CA but is now expired. It could = also mean that the "NotBefore" time is still in the future, but that would = be much rarer. It would be feasible to distinguish Expired from Not Yet=20 Valid in the response extension, of course. Naturally, an OCSP responder must have access to a repository=20 containing those certificates which are currently valid for a given issuer = to determine any of these statuses. That's your third case, but you can't = distinguish never issued from outside validity period if expired=20 certificates are purged from the repository. Neither the "revocation=20 database" case nor the "CRL only" case give the responder any basis to say = whether a given serial number belongs to a currently valid certificate, an = expired certificate which was never revoked, or neither. A full database=20 of certificates which have ever been issued with a given issuer name=20 should allow the responder to classify any given certificate serial number = for that issuer as "revoked" (including suspended), "valid", "expired",=20 "not yet", or "unknown". If you feel it's desirable for the responder to include which=20 repository mode it's using in an extension, I personally see no reason to=20 object to such a proposal. Including the repository mode is not necessary = for the use of these extensions, because two of the modes are inconsistent = with using them. Tom Gindin From: denis.pinkas@bull.net To: Tom Gindin/Watson/IBM@IBMUS,=20 Cc: pkix@ietf.org Date: 03/12/2012 09:46 AM Subject: RE: [pkix] Possible OCSP Extensions Tom,=20 Your email is not crystal clear (at least to me) and seems to address at=20 the same time two different topics: - an OCSP response extension containing "never issued" and=20 - an OCSP response extension containing "outside validity period".=20 I can understand "never issued", but I don't know what you mean, in the=20 context of OCSP, with "outside validity period"=20 Your proposal seems allowing an OCSP server "to verify that a CA had=20 actually been cracked and then react".=20 The problem is that we cannot do this, until we first specify a way to=20 return a status like "never issued".=20 Simply adding an additional status report like "never issued" would not be = sufficient as explained below.=20 The problem is that OSCP was originally designed to work either :=20 - with CRLs only, or=20 - with a revocation status data base for revoked certificates only, or=20 - with a revocation status data base for all issued certificates managed=20 directly by the CA which issued that certificate.=20 We currently have no way to indicate either in the request or in the=20 response=20 which of the three modes is/was requested or used.=20 An OCSP server might only indicate "never issued", if it also indicates=20 that it got this information using=20 a revocation status data base for all issued certificates managed directly = by the CA which has issued that certificate.=20 This means that this extension may only be present if the OCSP responder=20 is using a revocation status data base=20 for all issued certificates managed directly by the CA which has issued=20 that certificate.=20 =20 This extension would then contain a boolean to say whether of not the=20 certificate was issued.=20 I remember that we discuss this topic on the PKIX list but I don't=20 remember any concrete proposal.=20 Once we have such a mechanism (or a similar one), then we can build on it=20 and discuss (and understand better) your proposal.=20 Denis=20 De : Tom Gindin =20 A : pkix =20 Date : 10/03/2012 18:51=20 Objet : [pkix] Possible OCSP Extensions=20 Envoy=E9 par : pkix-bounces@ietf.org=20 Why isn't there an OCSP response extension containing "never=20 issued" or "outside validity period" which a responder may use if they=20 have the CA's certificate repository available? Getting a request that=20 produces such an error would not be anything which the responder would be=20 expected to report. A client who had received a response with such an=20 extension could then demonstrate that an actual compromise had occurred by = resending the request with a request extension containing the actual=20 certificate, or perhaps the chain, which had provoked that response=20 extension above. Receiving such a certificate would allow the OCSP server = to verify that the CA had actually been cracked and then react. I think that such a feature would be useful to responders operated=20 by a CA with many subordinate CA's, and possibly to others as well. Tom Gindin P.S. - The above suggestion is mine, and not necessarily that of my=20 employer. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From internet-drafts@ietf.org Mon Mar 12 09:30:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F383311E80A5; Mon, 12 Mar 2012 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQZ+bJm8wYSZ; Mon, 12 Mar 2012 09:30:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA3311E8099; Mon, 12 Mar 2012 09:30:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312163010.21842.40515.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 09:30:10 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:30:11 -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) Wor= king Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile Author(s) : David Cooper Filename : draft-ietf-pkix-rfc5280-clarifications-04.txt Pages : 7 Date : 2012-03-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-= 04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-0= 4.txt From internet-drafts@ietf.org Mon Mar 12 15:46:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2237621F8ACA; Mon, 12 Mar 2012 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvYGOD6JchyI; Mon, 12 Mar 2012 15:46:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AF221F8A90; Mon, 12 Mar 2012 15:46:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312224617.26212.12399.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:46:17 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-est-01.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:46:18 -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) Wor= king Group of the IETF. Title : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Filename : draft-ietf-pkix-est-01.txt Pages : 31 Date : 2012-03-12 This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-est-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-est-01.txt From piyush@identicate.com Mon Mar 12 15:51:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A136C21E8176 for ; Mon, 12 Mar 2012 15:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROSOpPNAX9zM for ; Mon, 12 Mar 2012 15:51:31 -0700 (PDT) Received: from col0-omc4-s15.col0.hotmail.com (col0-omc4-s15.col0.hotmail.com [65.55.34.217]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9321E8170 for ; Mon, 12 Mar 2012 15:51:31 -0700 (PDT) Received: from COL119-W36 ([65.55.34.201]) by col0-omc4-s15.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 15:51:32 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_067981f3-dde8-43ba-8c29-e355f767e52e_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: Date: Mon, 12 Mar 2012 15:51:31 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 22:51:32.0134 (UTC) FILETIME=[AB3EE460:01CD00A2] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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: Mon, 12 Mar 2012 22:51:32 -0000 --_067981f3-dde8-43ba-8c29-e355f767e52e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Mon=2C 12 Mar 2012 08:57:21 -0400 > Subject: Re: [pkix] Possible OCSP Extensions > From: hallam@gmail.com > To: piyush@identicate.com > CC: tgindin@us.ibm.com=3B pkix@ietf.org >=20 > And many of us think that we should fix the damn spec to do what it > was originally intended to do until a bunch of people with a business > model and a startup ruined it. So what was the original intention of the spec?Here is the excerpt from fir= st section of RFC 2560 " This document specifies a protocol useful in determining the current st= atus of a digital certificate without requiring CRLs." and the existing specs seem to be adequate to satisfy this intention. > There are many reasons why this functionality would be required. There > are tens of thousands of certs revoked for cause every year. less than > 1% of those so revoked last year were due to mis-issue. A few examples would really be helpful in understanding how this functional= ity will address the needs that simple signature checking cannot address. >=20 > Why do we have so many people obsessing about what has been the rarest > use case for OCSP and not the fact that the browsers don't actually > hard fail on OSCP? >=20 >=20 = --_067981f3-dde8-43ba-8c29-e355f767e52e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Mon=2C 12 Mar= 2012 08:57:21 -0400
>=3B Subject: Re: [pkix] Possible OCSP Extensions=
>=3B From: hallam@gmail.com
>=3B To: piyush@identicate.com
&g= t=3B CC: tgindin@us.ibm.com=3B pkix@ietf.org
>=3B =3B
>=3B An= d many of us think that we should fix the damn spec to do what it
>=3B= was originally intended to do until a bunch of people with a business
&= gt=3B model and a startup ruined it.

So what was the orig= inal intention of the spec?
Here is the excerpt from first sectio= n of RFC 2560

" This document specifies a protocol useful in det= ermining the current status of a digital certificate without requiring CRLs."
<= br>
and the existing specs seem to be adequate to satisfy this intention.
=

>=3B There are many reasons why this functionality wo= uld be required. There
>=3B are tens of thousands of certs revoked for= cause every year. less than
>=3B 1% of those so revoked last year wer= e due to mis-issue.

A few examples would really be= helpful in understanding how this functionality will address the needs tha= t simple signature checking cannot address.

>=3B=  =3B
>=3B Why do we have so many people obsessing about what has b= een the rarest
>=3B use case for OCSP and not the fact that the browse= rs don't actually
>=3B hard fail on OSCP?
>=3B =3B
>=3B&= nbsp=3B
= --_067981f3-dde8-43ba-8c29-e355f767e52e_-- From hotz@jpl.nasa.gov Mon Mar 12 18:53:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8C321F8853 for ; Mon, 12 Mar 2012 18:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVigyDTE2zYW for ; Mon, 12 Mar 2012 18:53:07 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3964A21F880E for ; Mon, 12 Mar 2012 18:53:07 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2D1r45r022183 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 12 Mar 2012 18:53:04 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 12 Mar 2012 18:53:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 01:53:07 -0000 Seems to me that it ought to be possible for OCSP to provide complete = information about the possibly-knowable status of a certificate. If the = OCSP server has complete current and historical information about what = certs a CA has issued, then it should be possible say if the cert is = good, bad, or doesn't (shouldn't) exist. While I've no objection to supporting optimizations in how OCSP = responses can be pre-generated or cached, that seems mostly like = implementation and deployment rather than protocol. On Mar 12, 2012, at 5:57 AM, Phillip Hallam-Baker wrote: > And many of us think that we should fix the damn spec to do what it > was originally intended to do until a bunch of people with a business > model and a startup ruined it. ;-) > I think it would be good to have a way to state precisely what the > server knows about the certificate. Are you asking that a client be able to tell if "never issued" wasn't = returned because the COSP responder doesn't support that extension (as = opposed to because the cert really had been issued)? Seems like a = useful complementary capability. ------------------------------------------------------ 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 hotz@jpl.nasa.gov Mon Mar 12 19:00:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0A21F88D9 for ; Mon, 12 Mar 2012 19:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53W5kbA+VkJ3 for ; Mon, 12 Mar 2012 19:00:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91121F88CA for ; Mon, 12 Mar 2012 19:00:11 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2D209eJ025658 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 12 Mar 2012 19:00:09 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 12 Mar 2012 19:00:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 02:00:12 -0000 Seems to me that it ought to be possible for OCSP to provide complete = information about the possibly-knowable status of a certificate. If the = OCSP server has complete current and historical information about what = certs a CA has issued, then it should be possible say if the cert is = good, bad, or doesn't (shouldn't) exist. While I've no objection to supporting optimizations in how OCSP = responses can be pre-generated or cached, that seems mostly like = implementation and deployment rather than protocol. On Mar 12, 2012, at 5:57 AM, Phillip Hallam-Baker wrote: > And many of us think that we should fix the spec to do what = it > was originally intended to do until a bunch of people with a business > model and a startup ruined it. ;-) > I think it would be good to have a way to state precisely what the > server knows about the certificate. Are you asking that a client be able to tell if "never issued" wasn't = returned because the COSP responder doesn't support that extension (as = opposed to because the cert really had been issued)? Seems like a = useful complementary capability. ------------------------------------------------------ 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 SChokhani@cygnacom.com Mon Mar 12 19:27:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881721F87CD for ; Mon, 12 Mar 2012 19:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-1.858, BAYES_00=-2.599, FRT_PROFIT1=3.858] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h2x-1ZgQrli for ; Mon, 12 Mar 2012 19:27:51 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1121F87E6 for ; Mon, 12 Mar 2012 19:27:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,573,1325480400"; d="scan'208";a="550108" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 12 Mar 2012 22:27:36 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 12 Mar 2012 22:27:36 -0400 From: Santosh Chokhani To: Tom Gindin , Piyush Jain , Phillip Hallam-Baker Date: Mon, 12 Mar 2012 22:27:35 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0AA1zWNUXTGAidQsKG4msJVv0/sAAvVlNw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'pkix' Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 02:27:52 -0000 If the Issuer is compromised, unless there is a trust established in the Re= sponder independent of the Issuer, the attacker can manufacture proof it wi= shes to. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Tom= Gindin Sent: Sunday, March 11, 2012 11:51 PM To: Piyush Jain; Phillip Hallam-Baker Cc: 'pkix' Subject: Re: [pkix] Possible OCSP Extensions Piyush: One purpose of this is to identify cases where the issuer has appar= ently been compromised, and the major purpose of the request extension (cal= l it "requested certificate body" or "requested certificate chain") is to allow such a case to be substantiated. Once the request is s= ubstantiated, I would expect the issuer key to be treated as compromised un= less the submitted certificate is a digest duplicate against an actual issu= ed certificate. That would be an algorithmic issue rather than a key compr= omise. I'd like to adapt part of Phill's suggestion, and redefine the prop= osed "never issued" status as "Not issued before" and a time. The presigne= d variant, which might be called "no serial number within range", seems rig= ht for issuers with increasing serial numbers but makes less sense for issu= ers who assign serial numbers which don't monotonically increase with time.= Phill, is that supposed to be the closed interval (with the two endpoint = serial numbers not issued) or the open one (with the two endpoint serial nu= mbers issued)? Also, is there an option in which the upper bound is not sp= ecified which means "no serial number above L had been issued as of time T"= ? Tom Gindin From: Piyush Jain To: Tom Gindin/Watson/IBM@IBMUS, "'pkix'" ,=20 Date: 03/11/2012 01:17 PM Subject: RE: [pkix] Possible OCSP Extensions Is this trying to address the case where CA continues to operate after it h= as been compromised? I'm assuming that in this case EE certificates have been signed using the C= A key and somehow deleted from the CA's issued certificates repository. What happens if the attacker issued an OCSP signing certificate (with OCSP-no-check) as opposed to an EE certificate? Many of us would believe that only way to address this breach is to revoke = the CA. There could be limited use of this extension for the CA to determine if it = has been compromised. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Tom Gindin > Sent: Saturday, March 10, 2012 9:50 AM > To: pkix > Subject: [pkix] Possible OCSP Extensions >=20 > Why isn't there an OCSP response extension containing "never issued" or > "outside validity period" which a responder may use if they have the CA's > certificate repository available? Getting a request that produces=20 > such an > error would not be anything which the responder would be expected to=20 > report. A client who had received a response with such an extension could > then demonstrate that an actual compromise had occurred by resending=20 > the request with a request extension containing the actual=20 > certificate, or perhaps > the chain, which had provoked that response extension above. =20 > Receiving such a certificate would allow the OCSP server to verify=20 > that the CA had actually been cracked and then react. > I think that such a feature would be useful to responders operated by a > CA with many subordinate CA's, and possibly to others as well. >=20 > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my employer. >=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 denis.pinkas@bull.net Tue Mar 13 00:49:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3E21F87E7 for ; Tue, 13 Mar 2012 00:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbgXWIOyJVKd for ; Tue, 13 Mar 2012 00:49:13 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 829D121F87DD for ; Tue, 13 Mar 2012 00:49:12 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id DE35518082; Tue, 13 Mar 2012 08:49:11 +0100 (CET) In-Reply-To: References: To: Tom Gindin MIME-Version: 1.0 X-KeepSent: BE1B5398:74B4651B-C12579BF:005206F3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 13 Mar 2012 08:49:11 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 13/03/2012 08:49:11, Serialize complete at 13/03/2012 08:49:11 Content-Type: multipart/alternative; boundary="=_alternative 002ACA5FC12579C0_=" Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 07:49:14 -0000 Message en plusieurs parties au format MIME --=_alternative 002ACA5FC12579C0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom, One of your arguments is to say that the proposal "can't distinguish never = issued from outside validity period=20 if expired certificates are purged from the repository". The question is=20 whether this is really necessary.=20 The answer is that it is not necessary, as explained below. A key point is that OSCP has only been designed to provide the revocation=20 status of a certificate at the current time. It should be the responsibility of the OCSP client, before making the OCSP = request, to test that the current time=20 is within the validity period of the certificate. Thus if a certificate=20 serial number refers to a certificate that has expired,=20 the OCSP response is not meaningful. However, if the proposal is included, explanations should clearly indicate = that the additional status is only meaningful=20 if the client has locally tested that the the current time is within the=20 validity period of the certificate.=20 Denis De : Tom Gindin A : denis.pinkas@bull.net Cc : pkix@ietf.org Date : 12/03/2012 15:21 Objet : RE: [pkix] Possible OCSP Extensions Denis: "Outside validity period" means, in most cases, that the serial=20 number requested was indeed issued by the CA but is now expired. It could = also mean that the "NotBefore" time is still in the future, but that would = be much rarer. It would be feasible to distinguish Expired from Not Yet=20 Valid in the response extension, of course. Naturally, an OCSP responder must have access to a repository=20 containing those certificates which are currently valid for a given issuer = to determine any of these statuses. That's your third case, but you can't = distinguish never issued from outside validity period if expired=20 certificates are purged from the repository. Neither the "revocation=20 database" case nor the "CRL only" case give the responder any basis to say = whether a given serial number belongs to a currently valid certificate, an = expired certificate which was never revoked, or neither. A full database=20 of certificates which have ever been issued with a given issuer name=20 should allow the responder to classify any given certificate serial number = for that issuer as "revoked" (including suspended), "valid", "expired",=20 "not yet", or "unknown". If you feel it's desirable for the responder to include which=20 repository mode it's using in an extension, I personally see no reason to=20 object to such a proposal. Including the repository mode is not necessary = for the use of these extensions, because two of the modes are inconsistent = with using them. Tom Gindin From: denis.pinkas@bull.net To: Tom Gindin/Watson/IBM@IBMUS,=20 Cc: pkix@ietf.org Date: 03/12/2012 09:46 AM Subject: RE: [pkix] Possible OCSP Extensions Tom,=20 Your email is not crystal clear (at least to me) and seems to address at=20 the same time two different topics: - an OCSP response extension containing "never issued" and=20 - an OCSP response extension containing "outside validity period".=20 I can understand "never issued", but I don't know what you mean, in the=20 context of OCSP, with "outside validity period"=20 Your proposal seems allowing an OCSP server "to verify that a CA had=20 actually been cracked and then react".=20 The problem is that we cannot do this, until we first specify a way to=20 return a status like "never issued".=20 Simply adding an additional status report like "never issued" would not be = sufficient as explained below.=20 The problem is that OSCP was originally designed to work either :=20 - with CRLs only, or=20 - with a revocation status data base for revoked certificates only, or=20 - with a revocation status data base for all issued certificates managed=20 directly by the CA which issued that certificate.=20 We currently have no way to indicate either in the request or in the=20 response=20 which of the three modes is/was requested or used.=20 An OCSP server might only indicate "never issued", if it also indicates=20 that it got this information using=20 a revocation status data base for all issued certificates managed directly = by the CA which has issued that certificate.=20 This means that this extension may only be present if the OCSP responder=20 is using a revocation status data base=20 for all issued certificates managed directly by the CA which has issued=20 that certificate.=20 =20 This extension would then contain a boolean to say whether of not the=20 certificate was issued.=20 I remember that we discuss this topic on the PKIX list but I don't=20 remember any concrete proposal.=20 Once we have such a mechanism (or a similar one), then we can build on it=20 and discuss (and understand better) your proposal.=20 Denis=20 De : Tom Gindin =20 A : pkix =20 Date : 10/03/2012 18:51=20 Objet : [pkix] Possible OCSP Extensions=20 Envoy=E9 par : pkix-bounces@ietf.org=20 Why isn't there an OCSP response extension containing "never=20 issued" or "outside validity period" which a responder may use if they=20 have the CA's certificate repository available? Getting a request that=20 produces such an error would not be anything which the responder would be=20 expected to report. A client who had received a response with such an=20 extension could then demonstrate that an actual compromise had occurred by = resending the request with a request extension containing the actual=20 certificate, or perhaps the chain, which had provoked that response=20 extension above. Receiving such a certificate would allow the OCSP server = to verify that the CA had actually been cracked and then react. I think that such a feature would be useful to responders operated=20 by a CA with many subordinate CA's, and possibly to others as well. Tom Gindin P.S. - The above suggestion is mine, and not necessarily that of my=20 employer. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002ACA5FC12579C0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom,

One of your arguments is to say that the proposal "can't distinguish never issued from outside validity period
if expired certificates are purged from the repository". The question is whether this is really necessary.
The answer is that it is not necessary, as explained below.

A key point is that OSCP has only been de= signed to provide the revocation status of a certificate at the current time.

It should be the responsibility of the OC= SP client, before making the OCSP request, to test that the current time
is within the validity period of the certificate. Thus if a certificate serial number refers to a certificate that has expired,
the OCSP response is not meaningful.

However, if the proposal is included, exp= lanations should clearly indicate that the additional status is only meaningful
if the client has locally tested that the the current time is within the validity period of the certificate.  

Denis




De :     &= nbsp;  Tom Gindin <tgindin@us.i= bm.com>
A :     &n= bsp;  denis.pinkas@bull.net
Cc :   &nb= sp;    pkix@ietf.org
Date :    =    12/03/2012 15:21
Objet :        RE: [pkix] Possible OCSP Extensions



        Denis:

       "Outside validity period" means, in most cases, that the serial
number requested was indeed issued by the CA but is now expired.  It could
also mean that the "NotBefore" time is still in the future, but that would
be much rarer.  It would be feasible to distinguish Expired from Not Yet
Valid in the response extension, of course.
       Naturally, an OCSP responder must have access to a repository
containing those certificates which are currently valid for a given issuer
to determine any of these statuses.  That's your third case, but you can't
distinguish never issued from outside validity period if expired
certificates are purged from the repository.  Neither the "revoca= tion
database" case nor the "CRL only" case give the responder any basis to say
whether a given serial number belongs to a currently valid certificate, an
expired certificate which was never revoked, or neither.  A full datab= ase
of certificates which have ever been issued with a given issuer name
should allow the responder to classify any given certificate serial number
for that issuer as "revoked" (including suspended), "valid&q= uot;, "expired",
"not yet", or "unknown".
       If you feel it's desirable for the responder to include which
repository mode it's using in an extension, I personally see no reason to
object to such a proposal.  Including the repository mode is not neces= sary
for the use of these extensions, because two of the modes are inconsistent
with using them.

Tom Gindin




From:   denis.pinkas@bull.net
To:     Tom Gindin/Watson/IBM@IBMUS,
Cc:     pkix@ietf.org
Date:   03/12/2012 09:46 AM
Subject:        RE: [pkix] Possible OCSP Extensions



Tom,

Your email is not crystal clear (at least to me) and seems to address at
the same time two different topics:

  - an OCSP response extension containing "never issued" and
 - an OCSP response extension containing "outside validity perio= d".

I can understand "never issued", but I don't know what you mean, in the
context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP server "to verify that a CA had
actually been cracked and then react".
The problem is that we cannot do this, until we first specify a way to
return a status like "never issued".

Simply adding an additional status report like "never issued" would not be
sufficient as explained below.

The problem is that OSCP was originally designed to work either :

- with CRLs only, or
- with a revocation status data base for revoked certificates only, or
- with a revocation status data base for all issued certificates managed
directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the
response
which of the three modes is/was requested or used.

An OCSP server might only indicate "never issued", if  it also indicates
that it got this information using
a revocation status data base for all issued certificates managed directly
by the CA which has issued that certificate.

This means that this extension may only be present if the OCSP responder
is using  a revocation status data base
for all issued certificates managed directly by the CA which has issued
that certificate.

This extension would then contain a boolean to say whether of not the
certificate was issued.

I remember that we discuss this topic on the PKIX  list but I don't
remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it
and discuss (and understand better) your proposal.

Denis




De :        Tom Gindin <tgindin@us.ibm.com>
A :        pkix <pkix@ietf.org>
Date :        10/03/2012 18:51
Objet :        [pkix] Possible OCSP Extensions
Envoy=E9 par :        pkix-bounces@ietf.org



       Why isn't there an OCSP response extension containing "never
issued" or "outside validity period" which a responder may use if they
have the CA's certificate repository available?  Getting a request that
produces such an error would not be anything which the responder would be
expected to report.  A client who had received a response with such an
extension could then demonstrate that an actual compromise had occurred by

resending the request with a request extension containing the actual
certificate, or perhaps the chain, which had provoked that response
extension above.  Receiving such a certificate would allow the OCSP server

to verify that the CA had actually been cracked and then react.
      I think that such a feature would be useful to respon= ders operated
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my
employer.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002ACA5FC12579C0_=-- From tomas@primekey.se Tue Mar 13 01:11:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF021F8859 for ; Tue, 13 Mar 2012 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YJrsQ-PdvMF for ; Tue, 13 Mar 2012 01:11:55 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1978B21F8858 for ; Tue, 13 Mar 2012 01:11:55 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 6FDFEE0BCA for ; Tue, 13 Mar 2012 09:12:00 +0100 (CET) Received: from [192.168.3.115] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 5783CE0BC4 for ; Tue, 13 Mar 2012 09:12:00 +0100 (CET) Message-ID: <4F5F0148.4020702@primekey.se> Date: Tue, 13 Mar 2012 09:11:52 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 08:11:56 -0000 On 03/12/2012 02:29 PM, Phillip Hallam-Baker wrote: > Actually, the idea for the serial numbers was not that they would > necessarily be monotonic, rather the idea is just to sign the gaps. If > the CA signs non-monotonic serial numbers then they would have to sort > them into order first. > > So the way a CA would work is that every OCSP signing increment, say 1 > hour, they would create OCSP responses for > > 1) Every known cert issued > 2) The gaps between the serial numbers. > > So with 100 certs issued, this would be 200 OCSP responses. This is not clear to me? If we, for example, use random 64 bit serial numbers (which is good for several reasons). After 100 issued certificates I would not for any practical reasons be able to calculate any "gaps". "Gaps" for certificate serial number seems to me to be a non existing thing. Cheers, Tomas > > > If a cert is issued within that time interval, the CA creates three > additional OCSP responses, one for the new cert and two for the new > serial number intervals that have just been created. > > This approach allows CAs to avoid creating additional timing errors > but is still robust if they are introduced by others. > > > On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin wrote: >> Piyush: >> >> One purpose of this is to identify cases where the issuer has >> apparently been compromised, and the major purpose of the request >> extension (call it "requested certificate body" or "requested certificate >> chain") is to allow such a case to be substantiated. Once the request is >> substantiated, I would expect the issuer key to be treated as compromised >> unless the submitted certificate is a digest duplicate against an actual >> issued certificate. That would be an algorithmic issue rather than a key >> compromise. >> I'd like to adapt part of Phill's suggestion, and redefine the >> proposed "never issued" status as "Not issued before" and a time. The >> presigned variant, which might be called "no serial number within range", >> seems right for issuers with increasing serial numbers but makes less >> sense for issuers who assign serial numbers which don't monotonically >> increase with time. Phill, is that supposed to be the closed interval >> (with the two endpoint serial numbers not issued) or the open one (with >> the two endpoint serial numbers issued)? Also, is there an option in >> which the upper bound is not specified which means "no serial number above >> L had been issued as of time T"? >> >> >> Tom Gindin >> >> >> >> >> >> From: Piyush Jain >> To: Tom Gindin/Watson/IBM@IBMUS, "'pkix'" , >> Date: 03/11/2012 01:17 PM >> Subject: RE: [pkix] Possible OCSP Extensions >> >> >> >> Is this trying to address the case where CA continues to operate after it >> has been compromised? >> I'm assuming that in this case EE certificates have been signed using the >> CA >> key and somehow deleted from the CA's issued certificates repository. >> What happens if the attacker issued an OCSP signing certificate (with >> OCSP-no-check) as opposed to an EE certificate? >> >> Many of us would believe that only way to address this breach is to revoke >> the CA. >> >> There could be limited use of this extension for the CA to determine if it >> has been compromised. >> >> -Piyush >> >> >> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Tom Gindin >>> Sent: Saturday, March 10, 2012 9:50 AM >>> To: pkix >>> Subject: [pkix] Possible OCSP Extensions >>> >>> Why isn't there an OCSP response extension containing "never >> issued" or >>> "outside validity period" which a responder may use if they have the >> CA's >>> certificate repository available? Getting a request that produces such >> an >>> error would not be anything which the responder would be expected to >>> report. A client who had received a response with such an extension >> could >>> then demonstrate that an actual compromise had occurred by resending the >>> request with a request extension containing the actual certificate, or >> perhaps >>> the chain, which had provoked that response extension above. Receiving >>> such a certificate would allow the OCSP server to verify that the CA had >>> actually been cracked and then react. >>> I think that such a feature would be useful to responders >> operated >> by a >>> CA with many subordinate CA's, and possibly to others as well. >>> >>> Tom Gindin >>> P.S. - The above suggestion is mine, and not necessarily that of my >> employer. >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> > > > From david.cooper@nist.gov Tue Mar 13 06:14:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B722221F867C for ; Tue, 13 Mar 2012 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThNWyBsUzmwX for ; Tue, 13 Mar 2012 06:14:07 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3148C21F863C for ; Tue, 13 Mar 2012 06:14:06 -0700 (PDT) Received: from hqtDC.local ([129.6.225.131]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2DDDwu6031613 for ; Tue, 13 Mar 2012 09:13:58 -0400 Message-ID: <4F5F4816.8090600@nist.gov> Date: Tue, 13 Mar 2012 09:13:58 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "pkix@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090202070205040808020801" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 13:14:08 -0000 This is a multi-part message in MIME format. --------------090202070205040808020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit RFC 2560, Section 4.4.4, Archive Cutoff An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date. OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. OCSP servers that provide support for such historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime. id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTime To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years). On 3/13/12 3:49 AM, denis.pinkas@bull.net wrote: > Tom, > > One of your arguments is to say that the proposal "can't distinguish > never issued from outside validity period > if expired certificates are purged from the repository". The question > is whether this is really necessary. > The answer is that it is not necessary, as explained below. > > A key point is that OSCP has only been designed to provide the > revocation status of a certificate at the current time. > > It should be the responsibility of the OCSP client, before making the > OCSP request, to test that the current time > is within the validity period of the certificate. Thus if a > certificate serial number refers to a certificate that has expired, > the OCSP response is not meaningful. > > However, if the proposal is included, explanations should clearly > indicate that the additional status is only meaningful > if the client has locally tested that the the current time is within > the validity period of the certificate. > > Denis > > > > > De : Tom Gindin > A : denis.pinkas@bull.net > Cc : pkix@ietf.org > Date : 12/03/2012 15:21 > Objet : RE: [pkix] Possible OCSP Extensions > ------------------------------------------------------------------------ > > > > Denis: > > "Outside validity period" means, in most cases, that the serial > number requested was indeed issued by the CA but is now expired. It > could > also mean that the "NotBefore" time is still in the future, but that > would > be much rarer. It would be feasible to distinguish Expired from Not Yet > Valid in the response extension, of course. > Naturally, an OCSP responder must have access to a repository > containing those certificates which are currently valid for a given > issuer > to determine any of these statuses. That's your third case, but you > can't > distinguish never issued from outside validity period if expired > certificates are purged from the repository. Neither the "revocation > database" case nor the "CRL only" case give the responder any basis to > say > whether a given serial number belongs to a currently valid > certificate, an > expired certificate which was never revoked, or neither. A full database > of certificates which have ever been issued with a given issuer name > should allow the responder to classify any given certificate serial > number > for that issuer as "revoked" (including suspended), "valid", "expired", > "not yet", or "unknown". > If you feel it's desirable for the responder to include which > repository mode it's using in an extension, I personally see no reason to > object to such a proposal. Including the repository mode is not > necessary > for the use of these extensions, because two of the modes are > inconsistent > with using them. > > Tom Gindin > > > > > From: denis.pinkas@bull.net > To: Tom Gindin/Watson/IBM@IBMUS, > Cc: pkix@ietf.org > Date: 03/12/2012 09:46 AM > Subject: RE: [pkix] Possible OCSP Extensions > > > > Tom, > > Your email is not crystal clear (at least to me) and seems to address at > the same time two different topics: > > - an OCSP response extension containing "never issued" and > - an OCSP response extension containing "outside validity period". > > I can understand "never issued", but I don't know what you mean, in the > context of OCSP, with "outside validity period" > > Your proposal seems allowing an OCSP server "to verify that a CA had > actually been cracked and then react". > The problem is that we cannot do this, until we first specify a way to > return a status like "never issued". > > Simply adding an additional status report like "never issued" would > not be > sufficient as explained below. > > The problem is that OSCP was originally designed to work either : > > - with CRLs only, or > - with a revocation status data base for revoked certificates only, or > - with a revocation status data base for all issued certificates managed > directly by the CA which issued that certificate. > > We currently have no way to indicate either in the request or in the > response > which of the three modes is/was requested or used. > > An OCSP server might only indicate "never issued", if it also indicates > that it got this information using > a revocation status data base for all issued certificates managed > directly > by the CA which has issued that certificate. > > This means that this extension may only be present if the OCSP responder > is using a revocation status data base > for all issued certificates managed directly by the CA which has issued > that certificate. > > This extension would then contain a boolean to say whether of not the > certificate was issued. > > I remember that we discuss this topic on the PKIX list but I don't > remember any concrete proposal. > > Once we have such a mechanism (or a similar one), then we can build on it > and discuss (and understand better) your proposal. > > Denis > > > > > De : Tom Gindin > A : pkix > Date : 10/03/2012 18:51 > Objet : [pkix] Possible OCSP Extensions > Envoyé par : pkix-bounces@ietf.org > > > > Why isn't there an OCSP response extension containing "never > issued" or "outside validity period" which a responder may use if they > have the CA's certificate repository available? Getting a request that > produces such an error would not be anything which the responder would be > expected to report. A client who had received a response with such an > extension could then demonstrate that an actual compromise had > occurred by > > resending the request with a request extension containing the actual > certificate, or perhaps the chain, which had provoked that response > extension above. Receiving such a certificate would allow the OCSP > server > > to verify that the CA had actually been cracked and then react. > I think that such a feature would be useful to responders operated > by a CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my > employer. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > --------------090202070205040808020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit RFC 2560, Section 4.4.4, Archive Cutoff

   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. The date obtained by subtracting this
   retention interval value from the producedAt time in a response is
   defined as the certificate's "archive cutoff" date.

   OCSP-enabled applications would use an OCSP archive cutoff date to
   contribute to a proof that a digital signature was (or was not)
   reliable on the date it was produced even if the certificate needed
   to validate the signature has long since expired.

   OCSP servers that provide support for such historical reference
   SHOULD include an archive cutoff date extension in responses.  If
   included, this value SHALL be provided as an OCSP singleExtensions
   extension identified by id-pkix-ocsp-archive-cutoff and of syntax
   GeneralizedTime.

   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

   ArchiveCutoff ::= GeneralizedTime

   To illustrate, if a server is operated with a 7-year retention
   interval policy and status was produced at time t1 then the value for
   ArchiveCutoff in the response would be (t1 - 7 years).


On 3/13/12 3:49 AM, denis.pinkas@bull.net wrote:
Tom,

One of your arguments is to say that the proposal "can't distinguish never issued from outside validity period
if expired certificates are purged from the repository". The question is whether this is really necessary.
The answer is that it is not necessary, as explained below.

A key point is that OSCP has only been designed to provide the revocation status of a certificate at the current time.

It should be the responsibility of the OCSP client, before making the OCSP request, to test that the current time
is within the validity period of the certificate. Thus if a certificate serial number refers to a certificate that has expired,
the OCSP response is not meaningful.

However, if the proposal is included, explanations should clearly indicate that the additional status is only meaningful
if the client has locally tested that the the current time is within the validity period of the certificate.  

Denis




De :        Tom Gindin <tgindin@us.ibm.com>
A :        denis.pinkas@bull.net
Cc :        pkix@ietf.org
Date :        12/03/2012 15:21
Objet :        RE: [pkix] Possible OCSP Extensions



        Denis:

       "Outside validity period" means, in most cases, that the serial
number requested was indeed issued by the CA but is now expired.  It could
also mean that the "NotBefore" time is still in the future, but that would
be much rarer.  It would be feasible to distinguish Expired from Not Yet
Valid in the response extension, of course.
       Naturally, an OCSP responder must have access to a repository
containing those certificates which are currently valid for a given issuer
to determine any of these statuses.  That's your third case, but you can't
distinguish never issued from outside validity period if expired
certificates are purged from the repository.  Neither the "revocation
database" case nor the "CRL only" case give the responder any basis to say
whether a given serial number belongs to a currently valid certificate, an
expired certificate which was never revoked, or neither.  A full database
of certificates which have ever been issued with a given issuer name
should allow the responder to classify any given certificate serial number
for that issuer as "revoked" (including suspended), "valid", "expired",
"not yet", or "unknown".
       If you feel it's desirable for the responder to include which
repository mode it's using in an extension, I personally see no reason to
object to such a proposal.  Including the repository mode is not necessary
for the use of these extensions, because two of the modes are inconsistent
with using them.

Tom Gindin




From:   denis.pinkas@bull.net
To:     Tom Gindin/Watson/IBM@IBMUS,
Cc:     pkix@ietf.org
Date:   03/12/2012 09:46 AM
Subject:        RE: [pkix] Possible OCSP Extensions



Tom,

Your email is not crystal clear (at least to me) and seems to address at
the same time two different topics:

  - an OCSP response extension containing "never issued" and
 - an OCSP response extension containing "outside validity period".

I can understand "never issued", but I don't know what you mean, in the
context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP server "to verify that a CA had
actually been cracked and then react".
The problem is that we cannot do this, until we first specify a way to
return a status like "never issued".

Simply adding an additional status report like "never issued" would not be
sufficient as explained below.

The problem is that OSCP was originally designed to work either :

- with CRLs only, or
- with a revocation status data base for revoked certificates only, or
- with a revocation status data base for all issued certificates managed
directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the
response
which of the three modes is/was requested or used.

An OCSP server might only indicate "never issued", if  it also indicates
that it got this information using
a revocation status data base for all issued certificates managed directly
by the CA which has issued that certificate.

This means that this extension may only be present if the OCSP responder
is using  a revocation status data base
for all issued certificates managed directly by the CA which has issued
that certificate.

This extension would then contain a boolean to say whether of not the
certificate was issued.

I remember that we discuss this topic on the PKIX  list but I don't
remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it
and discuss (and understand better) your proposal.

Denis




De :        Tom Gindin <tgindin@us.ibm.com>
A :        pkix <pkix@ietf.org>
Date :        10/03/2012 18:51
Objet :        [pkix] Possible OCSP Extensions
Envoyé par :        pkix-bounces@ietf.org



       Why isn't there an OCSP response extension containing "never
issued" or "outside validity period" which a responder may use if they
have the CA's certificate repository available?  Getting a request that
produces such an error would not be anything which the responder would be
expected to report.  A client who had received a response with such an
extension could then demonstrate that an actual compromise had occurred by

resending the request with a request extension containing the actual
certificate, or perhaps the chain, which had provoked that response
extension above.  Receiving such a certificate would allow the OCSP server

to verify that the CA had actually been cracked and then react.
      I think that such a feature would be useful to responders operated
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my
employer.

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

--------------090202070205040808020801-- From denis.pinkas@bull.net Tue Mar 13 07:46:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6021F8939 for ; Tue, 13 Mar 2012 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uebtqks31xYT for ; Tue, 13 Mar 2012 07:46:26 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id E0ED521F8938 for ; Tue, 13 Mar 2012 07:46:25 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 142FD180A4; Tue, 13 Mar 2012 15:46:24 +0100 (CET) In-Reply-To: <4F5F4816.8090600@nist.gov> References: <4F5F4816.8090600@nist.gov> To: "David A. Cooper" MIME-Version: 1.0 X-KeepSent: 853CEE91:CC3B631F-C12579C0:004F4221; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 13 Mar 2012 15:46:23 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 13/03/2012 15:46:23, Serialize complete at 13/03/2012 15:46:23 Content-Type: multipart/alternative; boundary="=_alternative 00512462C12579C0_=" Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 13 Mar 2012 14:46:27 -0000 Message en plusieurs parties au format MIME --=_alternative 00512462C12579C0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable David, You have provided a copy of section 4.4.4 but without providing any text=20 modification proposal. My text proposal was only a strawman proposal and was making the=20 assumption that the=20 id-pkix-ocsp-archive-cutoff extension was not included in the response. Taking into account section 4.4.4, a sentence from my previous email=20 should be expanded as follows: Thus if a certificate serial number refers to a certificate that has=20 expired,=20 the OCSP response is not meaningful when the id-pkix-ocsp-archive-cutoff=20 extension is not present, but it is when the id-pkix-ocsp-archive-cutoff=20 extension is present.=20 It should be noticed that when the id-pkix-ocsp-archive-cutoff extension=20 is present, the status is not=20 the revocation status at the current time, but the revocation status at=20 the end of the validity period of the certificate.=20 It would be worthwhile to mention it in section 4.4.4 in the next draft ( draft-ietf-pkix-rfc2560bis-05).=20 Since you are a co-editor ... Denis De : "David A. Cooper" A : "pkix@ietf.org" Date : 13/03/2012 14:14 Objet : Re: [pkix] Possible OCSP Extensions Envoy=E9 par : pkix-bounces@ietf.org RFC 2560, Section 4.4.4, Archive Cutoff An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date. OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. OCSP servers that provide support for such historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime. id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 6 } ArchiveCutoff ::=3D GeneralizedTime To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years). On 3/13/12 3:49 AM, denis.pinkas@bull.net wrote:=20 Tom,=20 One of your arguments is to say that the proposal "can't distinguish never = issued from outside validity period=20 if expired certificates are purged from the repository". The question is=20 whether this is really necessary.=20 The answer is that it is not necessary, as explained below.=20 A key point is that OSCP has only been designed to provide the revocation=20 status of a certificate at the current time.=20 It should be the responsibility of the OCSP client, before making the OCSP = request, to test that the current time=20 is within the validity period of the certificate. Thus if a certificate=20 serial number refers to a certificate that has expired,=20 the OCSP response is not meaningful.=20 However, if the proposal is included, explanations should clearly indicate = that the additional status is only meaningful=20 if the client has locally tested that the the current time is within the=20 validity period of the certificate. =20 Denis=20 De : Tom Gindin =20 A : denis.pinkas@bull.net=20 Cc : pkix@ietf.org=20 Date : 12/03/2012 15:21=20 Objet : RE: [pkix] Possible OCSP Extensions=20 Denis: "Outside validity period" means, in most cases, that the serial=20 number requested was indeed issued by the CA but is now expired. It could = also mean that the "NotBefore" time is still in the future, but that would = be much rarer. It would be feasible to distinguish Expired from Not Yet=20 Valid in the response extension, of course. Naturally, an OCSP responder must have access to a repository=20 containing those certificates which are currently valid for a given issuer = to determine any of these statuses. That's your third case, but you can't = distinguish never issued from outside validity period if expired=20 certificates are purged from the repository. Neither the "revocation=20 database" case nor the "CRL only" case give the responder any basis to say = whether a given serial number belongs to a currently valid certificate, an = expired certificate which was never revoked, or neither. A full database=20 of certificates which have ever been issued with a given issuer name=20 should allow the responder to classify any given certificate serial number = for that issuer as "revoked" (including suspended), "valid", "expired",=20 "not yet", or "unknown". If you feel it's desirable for the responder to include which=20 repository mode it's using in an extension, I personally see no reason to=20 object to such a proposal. Including the repository mode is not necessary = for the use of these extensions, because two of the modes are inconsistent = with using them. Tom Gindin From: denis.pinkas@bull.net To: Tom Gindin/Watson/IBM@IBMUS,=20 Cc: pkix@ietf.org Date: 03/12/2012 09:46 AM Subject: RE: [pkix] Possible OCSP Extensions Tom,=20 Your email is not crystal clear (at least to me) and seems to address at=20 the same time two different topics: - an OCSP response extension containing "never issued" and=20 - an OCSP response extension containing "outside validity period".=20 I can understand "never issued", but I don't know what you mean, in the=20 context of OCSP, with "outside validity period"=20 Your proposal seems allowing an OCSP server "to verify that a CA had=20 actually been cracked and then react".=20 The problem is that we cannot do this, until we first specify a way to=20 return a status like "never issued".=20 Simply adding an additional status report like "never issued" would not be = sufficient as explained below.=20 The problem is that OSCP was originally designed to work either :=20 - with CRLs only, or=20 - with a revocation status data base for revoked certificates only, or=20 - with a revocation status data base for all issued certificates managed=20 directly by the CA which issued that certificate.=20 We currently have no way to indicate either in the request or in the=20 response=20 which of the three modes is/was requested or used.=20 An OCSP server might only indicate "never issued", if it also indicates=20 that it got this information using=20 a revocation status data base for all issued certificates managed directly = by the CA which has issued that certificate.=20 This means that this extension may only be present if the OCSP responder=20 is using a revocation status data base=20 for all issued certificates managed directly by the CA which has issued=20 that certificate.=20 This extension would then contain a boolean to say whether of not the=20 certificate was issued.=20 I remember that we discuss this topic on the PKIX list but I don't=20 remember any concrete proposal.=20 Once we have such a mechanism (or a similar one), then we can build on it=20 and discuss (and understand better) your proposal.=20 Denis=20 De : Tom Gindin =20 A : pkix =20 Date : 10/03/2012 18:51=20 Objet : [pkix] Possible OCSP Extensions=20 Envoy=E9 par : pkix-bounces@ietf.org=20 Why isn't there an OCSP response extension containing "never=20 issued" or "outside validity period" which a responder may use if they=20 have the CA's certificate repository available? Getting a request that=20 produces such an error would not be anything which the responder would be=20 expected to report. A client who had received a response with such an=20 extension could then demonstrate that an actual compromise had occurred by = resending the request with a request extension containing the actual=20 certificate, or perhaps the chain, which had provoked that response=20 extension above. Receiving such a certificate would allow the OCSP server = to verify that the CA had actually been cracked and then react. I think that such a feature would be useful to responders operated=20 by a CA with many subordinate CA's, and possibly to others as well. Tom Gindin P.S. - The above suggestion is mine, and not necessarily that of my=20 employer. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00512462C12579C0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable David,

You have provided a copy of section 4.4.4 but without providing any text modification proposal.

My text proposal was only a strawman proposal and was making the assumption that the
id-pkix-ocsp-archive-cutoff extension was not included in the response.

Taking into account section 4.4.4, a sentence from my previous email should be expanded as follows:

Thus if a certificate serial number refers to a certificate that has expired,
the OCSP response is not meaningful when the id-pkix-ocsp-archive-cutoff
extension is not present, but it is when the id-pkix-ocsp-archive-cutoff
extension is present.  

It should be noticed that when the <= /font> id-pkix-ocsp-archive-cutoff extension is present, the status is not
the revocation status at the current time, but the revocation status at the end of the validity period of the certificate.

It would be worthwhile to mention it in s= ection 4.4.4 in the next draft (draft-ietf-pkix-rfc2560bis-05).

Since you are a co-editor ...

Denis





De :     &= nbsp;  "David A. Cooper" <david.cooper@nist.gov>
A :     &n= bsp;  "pkix@ietf.org" <pkix@ietf.org>
Date :    =    13/03/2012 14:14
Objet :        Re: [pkix] Possible OCSP Extensions
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



RFC 2560, Section 4.4.4, Archive Cutoff

  An OCSP responder MAY choose to retain revocation information beyon= d
  a certificate's expiration. The date obtained by subtracting this   retention interval value from the producedAt time in a response is
  defined as the certificate's "archive cutoff" date.

  OCSP-enabled applications would use an OCSP archive cutoff date to
  contribute to a proof that a digital signature was (or was not)
  reliable on the date it was produced even if the certificate needed=
  to validate the signature has long since expired.

  OCSP servers that provide support for such historical reference
  SHOULD include an archive cutoff date extension in responses.  = ;If
  included, this value SHALL be provided as an OCSP singleExtensions<= br>   extension identified by id-pkix-ocsp-archive-cutoff and of syntax   GeneralizedTime.

  id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::=3D { id-pkix= -ocsp 6 }

  ArchiveCutoff ::=3D GeneralizedTime

  To illustrate, if a server is operated with a 7-year retention
  interval policy and status was produced at time t1 then the value for
  ArchiveCutoff in the response would be (t1 - 7 years).


On 3/13/12 3:49 AM, denis.pinkas@bull.net wrote:
Tom,

One of your arguments is to say that the proposal "can't distinguish never issued from outside validity period
if expired certificates are purged from the repository". The question is whether this is really necessary.
The answer is that it is not necessary, as explained below.

A key point is that OSCP has only been designed to provide the revocation status of a certificate at the current time.

It should be the responsibility of the OCSP client, before making the OCSP request, to test that the current time
is within the validity period of the certificate. Thus if a certificate serial number refers to a certificate that has expired,
the OCSP response is not meaningful.

However, if the proposal is included, explanations should clearly indicate that the additional status is only meaningful
if the client has locally tested that the the current time is within the validity period of the certificate.  

Denis




De :        T= om Gindin <tgindin@us.ibm.com>
A :        denis.pinkas@bull.net<= /u>
Cc :        pkix@ietf.org<= font size=3D3>
Date :        12/03/2012 15:21
Objet :        RE: [pkix] Possible OCSP Extensions



       Denis:

      "Outside validity period" means, in most cases, that the serial
number requested was indeed issued by the CA but is now expired.  It could
also mean that the "NotBefore" time is still in the future, but that would
be much rarer.  It would be feasible to distinguish Expired from Not Yet
Valid in the response extension, of course.
      Naturally, an OCSP responder must have access to a repository
containing those certificates which are currently valid for a given issuer
to determine any of these statuses.  That's your third case, but you can't
distinguish never issued from outside validity period if expired
certificates are purged from the repository.  Neither the "revoca= tion
database" case nor the "CRL only" case give the responder any basis to say
whether a given serial number belongs to a currently valid certificate, an
expired certificate which was never revoked, or neither.  A full datab= ase
of certificates which have ever been issued with a given issuer name
should allow the responder to classify any given certificate serial number
for that issuer as "revoked" (including suspended), "valid&q= uot;, "expired",
"not yet", or "unknown".
      If you feel it's desirable for the responder to inclu= de which
repository mode it's using in an extension, I personally see no reason to
object to such a proposal.  Including the repository mode is not neces= sary
for the use of these extensions, because two of the modes are inconsistent
with using them.

Tom Gindin




From:   denis.pinkas@bull.net
To:     Tom Gindin/Watson/IBM@IBMUS,
Cc:     pkix@ietf.org Date:   03/12/2012 09:46 AM
Subject:        RE: [pkix] Possible OCSP Extensions



Tom,

Your email is not crystal clear (at least to me) and seems to address at
the same time two different topics:

 - an OCSP response extension containing "never issued" and
- an OCSP response extension containing "outside validity period"= ;.

I can understand "never issued", but I don't know what you mean, in the
context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP server "to verify that a CA had
actually been cracked and then react".
The problem is that we cannot do this, until we first specify a way to
return a status like "never issued".

Simply adding an additional status report like "never issued" would not be
sufficient as explained below.

The problem is that OSCP was originally designed to work either :

- with CRLs only, or
- with a revocation status data base for revoked certificates only, or
- with a revocation status data base for all issued certificates managed
directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the
response
which of the three modes is/was requested or used.

An OCSP server might only indicate "never issued", if  it also indicates
that it got this information using
a revocation status data base for all issued certificates managed directly
by the CA which has issued that certificate.

This means that this extension may only be present if the OCSP responder
is using  a revocation status data base
for all issued certificates managed directly by the CA which has issued
that certificate.

This extension would then contain a boolean to say whether of not the
certificate was issued.

I remember that we discuss this topic on the PKIX  list but I don't
remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it
and discuss (and understand better) your proposal.

Denis




De :        Tom Gindin <tgindin@us.ibm.com&g= t;
A :        pkix <pkix@ietf.org>
Date :        10/03/2012 18:51
Objet :        [pkix] Possible OCSP Extensions
Envoy=E9 par :        pkix-bounces@ietf.or= g



      Why isn't there an OCSP response extension containing "never
issued" or "outside validity period" which a responder may use if they
have the CA's certificate repository available?  Getting a request that
produces such an error would not be anything which the responder would be
expected to report.  A client who had received a response with such an
extension could then demonstrate that an actual compromise had occurred by

resending the request with a request extension containing the actual
certificate, or perhaps the chain, which had provoked that response
extension above.  Receiving such a certificate would allow the OCSP server

to verify that the CA had actually been cracked and then react.
     I think that such a feature would be useful to respond= ers operated
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my
employer.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00512462C12579C0_=-- From anders.rundgren@telia.com Tue Mar 13 09:03:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFDE21F87B9 for ; Tue, 13 Mar 2012 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfCjui5E3Qf4 for ; Tue, 13 Mar 2012 09:03:50 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id C15EB21F87B2 for ; Tue, 13 Mar 2012 09:03:49 -0700 (PDT) Received: from [129.6.252.196] (129.6.252.196) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E000F2B07 for pkix@ietf.org; Tue, 13 Mar 2012 17:03:47 +0100 Message-ID: <4F5F6FDA.6070600@telia.com> Date: Tue, 13 Mar 2012 12:03:38 -0400 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <20120312224617.26212.12399.idtracker@ietfa.amsl.com> In-Reply-To: <20120312224617.26212.12399.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-01.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, 13 Mar 2012 16:03:50 -0000 I'm currently participating in a NSTIC event at NIST. A person from NASA who I talked to acknowledged that the US government are indeed thinking of using their PIV cards as "Bootstrap" for enrolling derived credentials on mobile devices with embedded security hardware. I don't see that the IETF has anything to offer these guys (smart cards have been ruled out by PKIX) so the US government's only hope is that "The Big Three" unite on a solution. Anders On 2012-03-12 18:46, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Enrollment over Secure Transport > Author(s) : Max Pritikin > Peter E. Yee > Filename : draft-ietf-pkix-est-01.txt > Pages : 31 > Date : 2012-03-12 > > This document profiles certificate enrollment for clients using > Certificate Management over CMS (CMC) messages over a secure > transport. This profile, called Enrollment over Secure Transport > (EST), describes a simple yet functional certificate management > protocol targeting simple Public Key Infrastructure clients that need > to acquire client certificate(s) and associated Certification > Authority (CA) certificate(s). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-est-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-est-01.txt > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Tue Mar 13 18:15:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFA021F8557 for ; Tue, 13 Mar 2012 18:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4BmbBQ2jHcX for ; Tue, 13 Mar 2012 18:15:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A075821F8555 for ; Tue, 13 Mar 2012 18:15:36 -0700 (PDT) Received: by yenm5 with SMTP id m5so1427806yen.31 for ; Tue, 13 Mar 2012 18:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MGZqfqKZtLiwh3YX2uc2TwFdPu6n1VJImk5PK/jXGrQ=; b=ttUedxR7VujIxB2nZkWun0of6JEd7cVN7zcswl6g5guLhKoImFncfGqoL9vtZh2Y+j 3pz27oI25LVU2cKrCq4Bcjw+mTVLYNSRN71S/NWlowh+uPXudzqZVtI/oGy3cMLW32bS iNpJJGpI8FcHCW4u7TrU9NqkJ+dkC/qet9mv8pWNqh0nngcCmvGyPh+U1MgT2hVYXwk2 1fT3PPecoDF9i++ckLgSqmL2WOxPZGqLkNGpEnlOWnf/h8uHw6n+FCVEOkd6r8cJuj4U 6Y+anqnFYYG28YCs4GvKBzYF+fPs9fr6nv4hzzBfCWNFDtbQGRAgOoq5urux7XNl5CSo lIqA== MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr826613obb.25.1331687736089; Tue, 13 Mar 2012 18:15:36 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 13 Mar 2012 18:15:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 21:15:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 01:15:37 -0000 Yes, but my point was that once the point you make is understood it becomes obvious that half the alternative proposals are completely unworkable as well. The problems you cite with hardfail will be true of DNSSEC for a very long time to come. So the DANE folk are wasting their time. As for 'Sovereign Keys', that is not simply a hardfail proposal it is a 'permanent perpetual fail' proposal. So good luck with that as well. The problem with OCSP has been that the proportion of dangerous certs in the population from all causes has always been low enough for ignoring revocation to be an acceptable risk/performance tradeoff for many users. I would not say it was 99.99% but at least 99.5%. Now that some of the bad guys are putting effort into getting bad certs, the percentage is likely to change and the risk probably ceases to be acceptable. On Mon, Mar 12, 2012 at 8:15 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > >>Why do we have so many people obsessing about what has been the rarest us= e >>case for OCSP and not the fact that the browsers don't actually hard fail= on >>OSCP? > > Because failing hard would be a massive self-inflicted DoS on every brows= er > user on the planet. =A0The problem isn't "browsers don't fail hard", it's > "99.99% of all OCSP failures [*] are benign, how do we deal with that". > > Peter. > > [*] Figure freely pulled out of thin air, although Google and Firefox's p= ublic > =A0 =A0observations on the matter indicate that it's very high. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Mar 13 18:24:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E216411E8073 for ; Tue, 13 Mar 2012 18:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWwkSFC2vVgz for ; Tue, 13 Mar 2012 18:24:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9392421F841A for ; Tue, 13 Mar 2012 18:24:12 -0700 (PDT) Received: by yenm5 with SMTP id m5so1434360yen.31 for ; Tue, 13 Mar 2012 18:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uFxPZoH3UHvh1lNfNF5m/hLT3QetN+Ok4K07bKOuCA0=; b=nXDG5DMllPOhEOhooj53aXH/hJnoLh7+diAXpavsshDcXFg45y38Lm8xalR+pPtBEY 1bh7d1H6VHLTH1z4JQpRXYJHnirUK/KPnCPf0Az2kfdm49DUY/HvmN8h3GYc54zXH9GY XaRH6qXzotuYZCVgpD9gF0YpAAPNDHtqTncWyfRfVjwzy9uvLXnBwsyWtAwZIWxkhPqj q+37XvGwLzLr6t/DAFaDfWbfic4BcWrk5Naxkb2fCvo6Ngp1LnPJd8JSfdWnp10hdw1j zyQxM+XizMpxSTAxA/Is033pERncMpnfdTAV5LGW12rJiL5e5088/QMZErme0w+1VFIt dxkw== MIME-Version: 1.0 Received: by 10.60.22.70 with SMTP id b6mr895082oef.5.1331688252174; Tue, 13 Mar 2012 18:24:12 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 13 Mar 2012 18:24:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 21:24:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Piyush Jain Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 01:24:16 -0000 The original intention was to provide a scalable solution to revocation that was not encumbered by the Entrust distribution point partitioning patent that I had just discovered and to support authenticode and to enable the selling of per transaction insurance. The original spec that I wrote with Mike Meyers was hijacked by Valicert who rewrote our proposal in ASN.1. I still think that was a better spec to be honest. Certainly I got a bit peeved when the people who changed our OCSP spec to make it 'extensible' then decided that extending OCSP to support SCVP type functionality was not the way to go. Next time people in charge let someone pull a stunt like that they need to remember that I will still be bringing it up ten and twenty years from now whenever the opportunity should arise. On Mon, Mar 12, 2012 at 6:51 PM, Piyush Jain wrote: > > >> Date: Mon, 12 Mar 2012 08:57:21 -0400 > >> Subject: Re: [pkix] Possible OCSP Extensions >> From: hallam@gmail.com >> To: piyush@identicate.com >> CC: tgindin@us.ibm.com; pkix@ietf.org > >> >> And many of us think that we should fix the damn spec to do what it >> was originally intended to do until a bunch of people with a business >> model and a startup ruined it. > > So what was the original intention of the spec? > Here is the excerpt from first section of RFC 2560 > > " This document specifies a protocol useful in determining the current > status of a digital certificate without requiring CRLs." > > and the existing specs seem to be adequate to satisfy this intention. > >> There are many reasons why this functionality would be required. There >> are tens of thousands of certs revoked for cause every year. less than >> 1% of those so revoked last year were due to mis-issue. > > A few examples would really be helpful in understanding how this > functionality will address the needs that simple signature checking cannot > address. > >> >> Why do we have so many people obsessing about what has been the rarest >> use case for OCSP and not the fact that the browsers don't actually >> hard fail on OSCP? >> >> -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Mar 13 18:30:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFD21E8015 for ; Tue, 13 Mar 2012 18:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X4lR1mfsx-B for ; Tue, 13 Mar 2012 18:30:57 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF8FD11E8073 for ; Tue, 13 Mar 2012 18:30:56 -0700 (PDT) Received: by yenm5 with SMTP id m5so1439512yen.31 for ; Tue, 13 Mar 2012 18:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SexoEwYM5pyMz37EjSlr+MZZLfsJaSh713dW2o7OwZI=; b=lMdNV9UgTYbBo2qs2b0LeiDXlAAasK0e0jXFDTdbHpQBUob9/K/04Knvvf9kjPzgGo iEfnbYLcphbXovUk7mnIacSpghJDa7FjhjDunIUpXVHBvsyVtnt7WJFnV2rDiWzERBbu PjVFOgsn+6Dc7qmrkHEJsQgeq1s5M0V4Fdhb07Wq/AjjJQStnAm5M7OJIQri58wEHfG0 1eN4pas2A+xhftcREOvzHwYFqwl6VPUTz7tye8woACHBIMgfPb+EzMBT3o9nTrrNQ8aE axtlDzW7ihd/d5z3CPdGHe5ZSj+hw5aTODg/BeYpLdx+HhbPcnXtwH/UfQHdVU5ntX// bpaQ== MIME-Version: 1.0 Received: by 10.60.30.66 with SMTP id q2mr847110oeh.25.1331688656460; Tue, 13 Mar 2012 18:30:56 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 13 Mar 2012 18:30:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 21:30:56 -0400 Message-ID: From: Phillip Hallam-Baker To: denis.pinkas@bull.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 01:30:58 -0000 No, that is untrue, OCSP was originally designed to report archival status at a specific point in time. People can pull out the good stuff out of the specs if they like but they don't get to say that it was never the intention to do it. On Tue, Mar 13, 2012 at 3:49 AM, wrote: > Tom, > > One of your arguments is to say that the proposal "can't distinguish neve= r > issued from outside validity period > if expired certificates are purged from the repository". The question is > whether this is really necessary. > The answer is that it is not necessary, as explained below. > > A key point is that OSCP has only been designed to provide the revocation > status of a certificate at the current time. > > It should be the responsibility of the OCSP client, before making the OCS= P > request, to test that the current time > is within the validity period of the certificate. Thus if a certificate > serial number refers to a certificate that has expired, > the OCSP response is not meaningful. > > However, if the proposal is included, explanations should clearly indicat= e > that the additional status is only meaningful > if the client has locally tested that the the current time is within the > validity period of the certificate. > > Denis > > > > > De : =A0 =A0 =A0 =A0Tom Gindin > A : =A0 =A0 =A0 =A0denis.pinkas@bull.net > Cc=A0: =A0 =A0 =A0 =A0pkix@ietf.org > Date : =A0 =A0 =A0 =A012/03/2012 15:21 > Objet : =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions > ________________________________ > > > > =A0 =A0 =A0 =A0 Denis: > > =A0 =A0 =A0 =A0"Outside validity period" means, in most cases, that the s= erial > number requested was indeed issued by the CA but is now expired. =A0It co= uld > also mean that the "NotBefore" time is still in the future, but that woul= d > be much rarer. =A0It would be feasible to distinguish Expired from Not Ye= t > Valid in the response extension, of course. > =A0 =A0 =A0 =A0Naturally, an OCSP responder must have access to a reposit= ory > containing those certificates which are currently valid for a given issue= r > to determine any of these statuses. =A0That's your third case, but you ca= n't > distinguish never issued from outside validity period if expired > certificates are purged from the repository. =A0Neither the "revocation > database" case nor the "CRL only" case give the responder any basis to sa= y > whether a given serial number belongs to a currently valid certificate, a= n > expired certificate which was never revoked, or neither. =A0A full databa= se > of certificates which have ever been issued with a given issuer name > should allow the responder to classify any given certificate serial numbe= r > for that issuer as "revoked" (including suspended), "valid", "expired", > "not yet", or "unknown". > =A0 =A0 =A0 =A0If you feel it's desirable for the responder to include wh= ich > repository mode it's using in an extension, I personally see no reason to > object to such a proposal. =A0Including the repository mode is not necess= ary > for the use of these extensions, because two of the modes are inconsisten= t > with using them. > > Tom Gindin > > > > > From: =A0 denis.pinkas@bull.net > To: =A0 =A0 Tom Gindin/Watson/IBM@IBMUS, > Cc: =A0 =A0 pkix@ietf.org > Date: =A0 03/12/2012 09:46 AM > Subject: =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions > > > > Tom, > > Your email is not crystal clear (at least to me) and seems to address at > the same time two different topics: > > =A0 - an OCSP response extension containing "never issued" and > =A0- an OCSP response extension containing "outside validity period". > > I can understand "never issued", but I don't know what you mean, in the > context of OCSP, with "outside validity period" > > Your proposal seems allowing an OCSP server "to verify that a CA had > actually been cracked and then react". > The problem is that we cannot do this, until we first specify a way to > return a status like "never issued". > > Simply adding an additional status report like "never issued" would not b= e > sufficient as explained below. > > The problem is that OSCP was originally designed to work either : > > - with CRLs only, or > - with a revocation status data base for revoked certificates only, or > - with a revocation status data base for all issued certificates managed > directly by the CA which issued that certificate. > > We currently have no way to indicate either in the request or in the > response > which of the three modes is/was requested or used. > > An OCSP server might only indicate "never issued", if =A0it also indicate= s > that it got this information using > a revocation status data base for all issued certificates managed directl= y > by the CA which has issued that certificate. > > This means that this extension may only be present if the OCSP responder > is using =A0a revocation status data base > for all issued certificates managed directly by the CA which has issued > that certificate. > > This extension would then contain a boolean to say whether of not the > certificate was issued. > > I remember that we discuss this topic on the PKIX =A0list but I don't > remember any concrete proposal. > > Once we have such a mechanism (or a similar one), then we can build on it > and discuss (and understand better) your proposal. > > Denis > > > > > De : =A0 =A0 =A0 =A0Tom Gindin > A : =A0 =A0 =A0 =A0pkix > Date : =A0 =A0 =A0 =A010/03/2012 18:51 > Objet : =A0 =A0 =A0 =A0[pkix] Possible OCSP Extensions > Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org > > > > =A0 =A0 =A0 =A0Why isn't there an OCSP response extension containing "nev= er > issued" or "outside validity period" which a responder may use if they > have the CA's certificate repository available? =A0Getting a request that > produces such an error would not be anything which the responder would be > expected to report. =A0A client who had received a response with such an > extension could then demonstrate that an actual compromise had occurred b= y > > resending the request with a request extension containing the actual > certificate, or perhaps the chain, which had provoked that response > extension above. =A0Receiving such a certificate would allow the OCSP ser= ver > > to verify that the CA had actually been cracked and then react. > =A0 =A0 =A0 I think that such a feature would be useful to responders ope= rated > by a CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my > employer. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Mar 13 18:36:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D175221E8032 for ; Tue, 13 Mar 2012 18:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGAsqWRyhbNf for ; Tue, 13 Mar 2012 18:36:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B309921E801B for ; Tue, 13 Mar 2012 18:36:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so1443911yen.31 for ; Tue, 13 Mar 2012 18:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NchgPHhXM2m7gyvuCg30HIcCkHRFdC+jSdIV09NJ4s4=; b=KNUbGDSoyBPUkhS7sdUhUuNQ2ZOWNk0NmIdSNoCcX29hCBsPLTLmNAu6mrew7ozDy/ I+psgu+5luAE/4cFiF1R7AOVZaxzJk+db2mAbGPMilfX2ZvYERAFpW55FGkFml53e591 cTEUuX46gsycvU2mtTrfvxv76Z1gmfGDNzlhDQKzgInpGfty+MT0v8Nl+S6SchjKca3Y fS7fjf+ZqxGnKBMaN+7UfH/ag9lebKlb2AdYHj32xBFtd5IyGqUGlLGvftyyPj2eP+X3 uRNdXACPvxSpOL5J1tF6+8jJi6YmFyabg+gFNGldusf04xOoIuQSKbhngZ7tW6O/Vpwh SjTQ== MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr870566obb.25.1331688979209; Tue, 13 Mar 2012 18:36:19 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 13 Mar 2012 18:36:19 -0700 (PDT) In-Reply-To: <4F5F0148.4020702@primekey.se> References: <4F5F0148.4020702@primekey.se> Date: Tue, 13 Mar 2012 21:36:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Tomas Gustavsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 01:36:26 -0000 So to work out the gaps: Take the set of issued certs C_set Sort by serial number to produce a list C_list [0..99] Create OCSP status responses for C[0].serial C[1].serial ... C[99].serial Create OCSP non-existence responses for C[0].serial+1 -> C[1].serial-1 C[1].serial+1 -> C[2].serial-1 ... C[98].serial+1 -> C[99].serial-1 C[99].serial+1 -> C[0].serial-1 Does that answer the question? On Tue, Mar 13, 2012 at 4:11 AM, Tomas Gustavsson wrote= : > > > On 03/12/2012 02:29 PM, Phillip Hallam-Baker wrote: >> Actually, the idea for the serial numbers was not that they would >> necessarily be monotonic, rather the idea is just to sign the gaps. If >> the CA signs non-monotonic serial numbers then they would have to sort >> them into order first. >> >> So the way a CA would work is that every OCSP signing increment, say 1 >> hour, they would create OCSP responses for >> >> 1) Every known cert issued >> 2) The gaps between the serial numbers. >> >> So with 100 certs issued, this would be 200 OCSP responses. > > This is not clear to me? If we, for example, use random 64 bit serial > numbers (which is good for several reasons). After 100 issued > certificates I would not for any practical reasons be able to calculate > any "gaps". > > "Gaps" for certificate serial number seems to me to be a non existing thi= ng. > > Cheers, > Tomas > >> >> >> If a cert is issued within that time interval, the CA creates three >> additional OCSP responses, one for the new cert and two for the new >> serial number intervals that have just been created. >> >> This approach allows CAs to avoid creating additional timing errors >> but is still robust if they are introduced by others. >> >> >> On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin wrote: >>> =A0 =A0 =A0 =A0Piyush: >>> >>> =A0 =A0 =A0 =A0One purpose of this is to identify cases where the issue= r has >>> apparently been compromised, and the major purpose of the request >>> extension (call it "requested certificate body" or "requested certifica= te >>> chain") is to allow such a case to be substantiated. =A0Once the reques= t is >>> substantiated, I would expect the issuer key to be treated as compromis= ed >>> unless the submitted certificate is a digest duplicate against an actua= l >>> issued certificate. =A0That would be an algorithmic issue rather than a= key >>> compromise. >>> =A0 =A0 =A0 =A0I'd like to adapt part of Phill's suggestion, and redefi= ne the >>> proposed "never issued" status as "Not issued before" and a time. =A0Th= e >>> presigned variant, which might be called "no serial number within range= ", >>> seems right for issuers with increasing serial numbers but makes less >>> sense for issuers who assign serial numbers which don't monotonically >>> increase with time. =A0Phill, is that supposed to be the closed interva= l >>> (with the two endpoint serial numbers not issued) or the open one (with >>> the two endpoint serial numbers issued)? =A0Also, is there an option in >>> which the upper bound is not specified which means "no serial number ab= ove >>> L had been issued as of time T"? >>> >>> >>> Tom Gindin >>> >>> >>> >>> >>> >>> From: =A0 Piyush Jain >>> To: =A0 =A0 Tom Gindin/Watson/IBM@IBMUS, "'pkix'" , >>> Date: =A0 03/11/2012 01:17 PM >>> Subject: =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions >>> >>> >>> >>> Is this trying to address the case where CA continues to operate after = it >>> has been compromised? >>> I'm assuming that in this case EE certificates have been signed using t= he >>> CA >>> key and somehow deleted from the CA's issued certificates repository. >>> What happens if the attacker issued an OCSP signing certificate (with >>> OCSP-no-check) as opposed to an EE certificate? >>> >>> Many of us would believe that only way to address this breach is to rev= oke >>> the CA. >>> >>> There could be limited use of this extension for the CA to determine if= it >>> has been compromised. >>> >>> -Piyush >>> >>> >>> >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> Tom Gindin >>>> Sent: Saturday, March 10, 2012 9:50 AM >>>> To: pkix >>>> Subject: [pkix] Possible OCSP Extensions >>>> >>>> =A0 =A0 =A0 =A0 Why isn't there an OCSP response extension containing = "never >>> issued" or >>>> "outside validity period" which a responder may use if they have the >>> CA's >>>> certificate repository available? =A0Getting a request that produces s= uch >>> an >>>> error would not be anything which the responder would be expected to >>>> report. =A0A client who had received a response with such an extension >>> could >>>> then demonstrate that an actual compromise had occurred by resending t= he >>>> request with a request extension containing the actual certificate, or >>> perhaps >>>> the chain, which had provoked that response extension above. =A0Receiv= ing >>>> such a certificate would allow the OCSP server to verify that the CA h= ad >>>> actually been cracked and then react. >>>> =A0 =A0 =A0 =A0 I think that such a feature would be useful to respond= ers >>> operated >>> by a >>>> CA with many subordinate CA's, and possibly to others as well. >>>> >>>> Tom Gindin >>>> P.S. - The above suggestion is mine, and not necessarily that of my >>> employer. >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> >> >> >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From mmyers@fastq.com Tue Mar 13 18:53:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B8A21E8033 for ; Tue, 13 Mar 2012 18:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x5bwdPUEB7b for ; Tue, 13 Mar 2012 18:53:59 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2621E803A for ; Tue, 13 Mar 2012 18:53:57 -0700 (PDT) Received: from [192.168.1.105] ([140.99.65.9]) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2E1rnVT003533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 18:53:50 -0700 Message-Id: <7111B534-6D82-47F9-9BC0-5903E26246D5@fastq.com> From: Michael Myers To: Phillip Hallam-Baker , pkix@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Mar 2012 18:59:13 -0700 References: X-Mailer: Apple Mail (2.936) Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 01:53:59 -0000 On Mar 13, 2012, at 6:30 PM, Phillip Hallam-Baker wrote: > No, that is untrue, OCSP was originally designed to report archival > status at a specific point in time. PHB, A nit. :s/archival status/best known revocation status/w/q Mike From hallam@gmail.com Tue Mar 13 19:31:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92AE21E8049 for ; Tue, 13 Mar 2012 19:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuUNdqi1Tdhn for ; Tue, 13 Mar 2012 19:31:33 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 230B621E803A for ; Tue, 13 Mar 2012 19:31:33 -0700 (PDT) Received: by yenm5 with SMTP id m5so1486798yen.31 for ; Tue, 13 Mar 2012 19:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f2WYJFbcJK0ZoU9EmCgvH3GrDERmQldYPBgkJ7VVLk8=; b=heN+9Eskq9rPTbujeiiW0teg4RrUD5jDKIgU48o+n4hPu54gvg6+45wwTAtQqMM+My kSM1+7K9JgxCco9zfcWWQtZ3YWB90ZWUx3h6Mnc66IpV8jPSq1TCAXsDyvu4cZeKT76g seugUQjNfsjpuY5VkRBfWP9x1/UWsSc459+AY9NApJIXZsDZKShLGPxDrzsmyo10e7Bx k4lseDsGA5z5vpMl2nTLpY4v/gAbfNQ9MRB5fVarzpddqx2tpWNKsrtNtieylyIG84+D aaZrnsTKM6WP0yFQKYqYMEM8Lou01NoRx7EfB/X/8s+tHui3fn5qFoeaQ+CB40KaAOzZ pRWg== MIME-Version: 1.0 Received: by 10.60.22.70 with SMTP id b6mr1032346oef.5.1331692292591; Tue, 13 Mar 2012 19:31:32 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 13 Mar 2012 19:31:32 -0700 (PDT) In-Reply-To: <7111B534-6D82-47F9-9BC0-5903E26246D5@fastq.com> References: <7111B534-6D82-47F9-9BC0-5903E26246D5@fastq.com> Date: Tue, 13 Mar 2012 22:31:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Myers Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 02:31:33 -0000 Good point, yep. Though quite what archival status would be in that case... But certainly one of the use cases motivating the work was being able to get a status on a signed document (e.g. a mortgage or a bill of lading) twenty years later. On Tue, Mar 13, 2012 at 9:59 PM, Michael Myers wrote: > > On Mar 13, 2012, at 6:30 PM, Phillip Hallam-Baker wrote: > >> No, that is untrue, OCSP was originally designed to report archival >> status at a specific point in time. > > > PHB, > > A nit. > > :s/archival status/best known revocation status/w/q > > Mike > -- Website: http://hallambaker.com/ From piyush@identicate.com Tue Mar 13 23:18:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004E721F85F2 for ; Tue, 13 Mar 2012 23:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsZb3gvv3aHo for ; Tue, 13 Mar 2012 23:18:37 -0700 (PDT) Received: from col0-omc4-s9.col0.hotmail.com (col0-omc4-s9.col0.hotmail.com [65.55.34.211]) by ietfa.amsl.com (Postfix) with ESMTP id 83D3221F85F0 for ; Tue, 13 Mar 2012 23:18:37 -0700 (PDT) Received: from COL119-W49 ([65.55.34.201]) by col0-omc4-s9.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 23:18:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_146ade78-9141-483f-a8bc-84a259e01da6_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Tue, 13 Mar 2012 23:18:37 -0700 Importance: Normal In-Reply-To: References: , , , , <4F5F0148.4020702@primekey.se>, MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 06:18:37.0420 (UTC) FILETIME=[4AC672C0:01CD01AA] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 06:18:39 -0000 --_146ade78-9141-483f-a8bc-84a259e01da6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like idea of returning the status for a range of serial numbers. It can be used to return "other" certificate statuses as well. Not that I l= ike the idea of bulk revocations=2C but it is quite prevalent in some big e= nterprise PKI deployments in the US. The information in a 20 MB CRL=2C whi= ch is a result of a few rounds of bulk revocation can be captured in a very= few OCSP responses. Also=2C as Philip suggested earlier=2C it'll make it p= ossible to pre-sign responses for CAs who generate certificates with non se= quential serial numbers. Going back to the possible status values - revoked (present in CRL - issued by all kind of responders) - not present in CRL (issued by responder which does not have access to CA = database) - good (issued by responder which has access to to CA database) - unknown (CRL not available - issued by responder which does not have acce= ss to CA database) - not issued (issued by responder which has access to to CA database) - expired (issued by responder which has access to to CA database) What confuses me is why the last two values are needed at all. If the clien= t can parse the cert and verify signatures=2C it can figure out if the cert= was issued and if it is expired. If the client is a dumb client=2C it is b= etter off using SCVP.=20 > Date: Tue=2C 13 Mar 2012 21:36:19 -0400 > From: hallam@gmail.com > To: tomas@primekey.se > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 > So to work out the gaps: >=20 > Take the set of issued certs C_set > Sort by serial number to produce a list C_list [0..99] >=20 > Create OCSP status responses for > C[0].serial > C[1].serial > ... > C[99].serial >=20 > Create OCSP non-existence responses for > C[0].serial+1 -> C[1].serial-1 > C[1].serial+1 -> C[2].serial-1 > ... > C[98].serial+1 -> C[99].serial-1 > C[99].serial+1 -> C[0].serial-1 >=20 > Does that answer the question? >=20 > On Tue=2C Mar 13=2C 2012 at 4:11 AM=2C Tomas Gustavsson wrote: > > > > > > On 03/12/2012 02:29 PM=2C Phillip Hallam-Baker wrote: > >> Actually=2C the idea for the serial numbers was not that they would > >> necessarily be monotonic=2C rather the idea is just to sign the gaps. = If > >> the CA signs non-monotonic serial numbers then they would have to sort > >> them into order first. > >> > >> So the way a CA would work is that every OCSP signing increment=2C say= 1 > >> hour=2C they would create OCSP responses for > >> > >> 1) Every known cert issued > >> 2) The gaps between the serial numbers. > >> > >> So with 100 certs issued=2C this would be 200 OCSP responses. > > > > This is not clear to me? If we=2C for example=2C use random 64 bit seri= al > > numbers (which is good for several reasons). After 100 issued > > certificates I would not for any practical reasons be able to calculate > > any "gaps". > > > > "Gaps" for certificate serial number seems to me to be a non existing t= hing. > > > > Cheers=2C > > Tomas > > > >> > >> > >> If a cert is issued within that time interval=2C the CA creates three > >> additional OCSP responses=2C one for the new cert and two for the new > >> serial number intervals that have just been created. > >> > >> This approach allows CAs to avoid creating additional timing errors > >> but is still robust if they are introduced by others. > >> > >> > >> On Sun=2C Mar 11=2C 2012 at 11:50 PM=2C Tom Gindin wrote: > >>> Piyush: > >>> > >>> One purpose of this is to identify cases where the issuer has > >>> apparently been compromised=2C and the major purpose of the request > >>> extension (call it "requested certificate body" or "requested certifi= cate > >>> chain") is to allow such a case to be substantiated. Once the reques= t is > >>> substantiated=2C I would expect the issuer key to be treated as compr= omised > >>> unless the submitted certificate is a digest duplicate against an act= ual > >>> issued certificate. That would be an algorithmic issue rather than a= key > >>> compromise. > >>> I'd like to adapt part of Phill's suggestion=2C and redefine t= he > >>> proposed "never issued" status as "Not issued before" and a time. Th= e > >>> presigned variant=2C which might be called "no serial number within r= ange"=2C > >>> seems right for issuers with increasing serial numbers but makes less > >>> sense for issuers who assign serial numbers which don't monotonically > >>> increase with time. Phill=2C is that supposed to be the closed inter= val > >>> (with the two endpoint serial numbers not issued) or the open one (wi= th > >>> the two endpoint serial numbers issued)? Also=2C is there an option = in > >>> which the upper bound is not specified which means "no serial number = above > >>> L had been issued as of time T"? > >>> > >>> > >>> Tom Gindin > >>> > >>> > >>> > >>> > >>> > >>> From: Piyush Jain > >>> To: Tom Gindin/Watson/IBM@IBMUS=2C "'pkix'" =2C > >>> Date: 03/11/2012 01:17 PM > >>> Subject: RE: [pkix] Possible OCSP Extensions > >>> > >>> > >>> > >>> Is this trying to address the case where CA continues to operate afte= r it > >>> has been compromised? > >>> I'm assuming that in this case EE certificates have been signed using= the > >>> CA > >>> key and somehow deleted from the CA's issued certificates repository. > >>> What happens if the attacker issued an OCSP signing certificate (with > >>> OCSP-no-check) as opposed to an EE certificate? > >>> > >>> Many of us would believe that only way to address this breach is to r= evoke > >>> the CA. > >>> > >>> There could be limited use of this extension for the CA to determine = if it > >>> has been compromised. > >>> > >>> -Piyush > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf= Of > >>>> Tom Gindin > >>>> Sent: Saturday=2C March 10=2C 2012 9:50 AM > >>>> To: pkix > >>>> Subject: [pkix] Possible OCSP Extensions > >>>> > >>>> Why isn't there an OCSP response extension containing "never > >>> issued" or > >>>> "outside validity period" which a responder may use if they have the > >>> CA's > >>>> certificate repository available? Getting a request that produces s= uch > >>> an > >>>> error would not be anything which the responder would be expected to > >>>> report. A client who had received a response with such an extension > >>> could > >>>> then demonstrate that an actual compromise had occurred by resending= the > >>>> request with a request extension containing the actual certificate= =2C or > >>> perhaps > >>>> the chain=2C which had provoked that response extension above. Rece= iving > >>>> such a certificate would allow the OCSP server to verify that the CA= had > >>>> actually been cracked and then react. > >>>> I think that such a feature would be useful to responders > >>> operated > >>> by a > >>>> CA with many subordinate CA's=2C and possibly to others as well. > >>>> > >>>> Tom Gindin > >>>> P.S. - The above suggestion is mine=2C and not necessarily that of m= y > >>> employer. > >>>> > >>>> _______________________________________________ > >>>> 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 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_146ade78-9141-483f-a8bc-84a259e01da6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I like idea of returning the status for a range of serial numbers.
It ca= n be used to return "other" certificate statuses as well. Not that I like t= he idea of bulk revocations=2C but it is quite prevalent in some big enterp= rise PKI deployments in the US. The information in a 20 MB =3B CRL=2C w= hich is a result of a few rounds of bulk revocation can be captured in a ve= ry few OCSP responses. Also=2C as Philip suggested earlier=2C it'll make it= possible to pre-sign responses for CAs who generate certificates with non = sequential serial numbers.

Going back to the possible status values<= br>- revoked (present in CRL - issued by all kind of responders)
- not p= resent in CRL (issued by responder which does not have access to CA databas= e)
- good (issued by responder which has access to to CA database)
- = unknown (CRL not available - issued by responder which does not have access= to CA database)
- not issued (issued by responder which has access to t= o CA database)
- expired (issued by responder which has access to to CA = database)

What confuses me is why the last two values are needed at = all. If the client can parse the cert and verify signatures=2C it can figur= e out if the cert was issued and if it is expired. If the client is a dumb = client=2C it is better off using SCVP.


>=3B Date: Tue=2C 13 Mar 2012 21:36:19 -0400
>=3B= From: hallam@gmail.com
>=3B To: tomas@primekey.se
>=3B CC: pkix@= ietf.org
>=3B Subject: Re: [pkix] Possible OCSP Extensions
>=3B <= br>>=3B So to work out the gaps:
>=3B
>=3B Take the set of iss= ued certs C_set
>=3B Sort by serial number to produce a list C_list [0= ..99]
>=3B
>=3B Create OCSP status responses for
>=3B C[= 0].serial
>=3B C[1].serial
>=3B ...
>=3B C[99].seri= al
>=3B
>=3B Create OCSP non-existence responses for
>=3B = C[0].serial+1 ->=3B C[1].serial-1
>=3B C[1].serial+1 ->=3B = C[2].serial-1
>=3B ...
>=3B C[98].serial+1 ->=3B C[99].= serial-1
>=3B C[99].serial+1 ->=3B C[0].serial-1
>=3B
&= gt=3B Does that answer the question?
>=3B
>=3B On Tue=2C Mar 13= =2C 2012 at 4:11 AM=2C Tomas Gustavsson <=3Btomas@primekey.se>=3B wrote= :
>=3B >=3B
>=3B >=3B
>=3B >=3B On 03/12/2012 02:29 PM= =2C Phillip Hallam-Baker wrote:
>=3B >=3B>=3B Actually=2C the idea= for the serial numbers was not that they would
>=3B >=3B>=3B nece= ssarily be monotonic=2C rather the idea is just to sign the gaps. If
>= =3B >=3B>=3B the CA signs non-monotonic serial numbers then they would = have to sort
>=3B >=3B>=3B them into order first.
>=3B >=3B= >=3B
>=3B >=3B>=3B So the way a CA would work is that every OCSP= signing increment=2C say 1
>=3B >=3B>=3B hour=2C they would creat= e OCSP responses for
>=3B >=3B>=3B
>=3B >=3B>=3B 1) Every= known cert issued
>=3B >=3B>=3B 2) The gaps between the serial nu= mbers.
>=3B >=3B>=3B
>=3B >=3B>=3B So with 100 certs issu= ed=2C this would be 200 OCSP responses.
>=3B >=3B
>=3B >=3B T= his is not clear to me? If we=2C for example=2C use random 64 bit serial>=3B >=3B numbers (which is good for several reasons). After 100 issue= d
>=3B >=3B certificates I would not for any practical reasons be ab= le to calculate
>=3B >=3B any "gaps".
>=3B >=3B
>=3B >= =3B "Gaps" for certificate serial number seems to me to be a non existing t= hing.
>=3B >=3B
>=3B >=3B Cheers=2C
>=3B >=3B Tomas>=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >= =3B>=3B If a cert is issued within that time interval=2C the CA creates t= hree
>=3B >=3B>=3B additional OCSP responses=2C one for the new ce= rt and two for the new
>=3B >=3B>=3B serial number intervals that = have just been created.
>=3B >=3B>=3B
>=3B >=3B>=3B This = approach allows CAs to avoid creating additional timing errors
>=3B &g= t=3B>=3B but is still robust if they are introduced by others.
>=3B = >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B On Sun=2C Mar 11= =2C 2012 at 11:50 PM=2C Tom Gindin <=3Btgindin@us.ibm.com>=3B wrote:>=3B >=3B>=3B>=3B  =3B  =3B  =3B  =3BPiyush:
&g= t=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B  =3B  =3B &nbs= p=3B  =3BOne purpose of this is to identify cases where the issuer has<= br>>=3B >=3B>=3B>=3B apparently been compromised=2C and the major p= urpose of the request
>=3B >=3B>=3B>=3B extension (call it "requ= ested certificate body" or "requested certificate
>=3B >=3B>=3B>= =3B chain") is to allow such a case to be substantiated.  =3BOnce the r= equest is
>=3B >=3B>=3B>=3B substantiated=2C I would expect the = issuer key to be treated as compromised
>=3B >=3B>=3B>=3B unless= the submitted certificate is a digest duplicate against an actual
>= =3B >=3B>=3B>=3B issued certificate.  =3BThat would be an algorit= hmic issue rather than a key
>=3B >=3B>=3B>=3B compromise.
&g= t=3B >=3B>=3B>=3B  =3B  =3B  =3B  =3BI'd like to adap= t part of Phill's suggestion=2C and redefine the
>=3B >=3B>=3B>= =3B proposed "never issued" status as "Not issued before" and a time.  = =3BThe
>=3B >=3B>=3B>=3B presigned variant=2C which might be cal= led "no serial number within range"=2C
>=3B >=3B>=3B>=3B seems r= ight for issuers with increasing serial numbers but makes less
>=3B &g= t=3B>=3B>=3B sense for issuers who assign serial numbers which don't mo= notonically
>=3B >=3B>=3B>=3B increase with time.  =3BPhill= =2C is that supposed to be the closed interval
>=3B >=3B>=3B>=3B= (with the two endpoint serial numbers not issued) or the open one (with>=3B >=3B>=3B>=3B the two endpoint serial numbers issued)?  = =3BAlso=2C is there an option in
>=3B >=3B>=3B>=3B which the upp= er bound is not specified which means "no serial number above
>=3B >= =3B>=3B>=3B L had been issued as of time T"?
>=3B >=3B>=3B>= =3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B Tom Gindin>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>= =3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>= =3B >=3B>=3B>=3B From:  =3B Piyush Jain <=3Bpiyush@identicate.c= om>=3B
>=3B >=3B>=3B>=3B To:  =3B  =3B Tom Gindin/Wats= on/IBM@IBMUS=2C "'pkix'" <=3Bpkix@ietf.org>=3B=2C
>=3B >=3B>= =3B>=3B Date:  =3B 03/11/2012 01:17 PM
>=3B >=3B>=3B>=3B S= ubject:  =3B  =3B  =3B  =3BRE: [pkix] Possible OCSP Extensi= ons
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >= =3B>=3B>=3B
>=3B >=3B>=3B>=3B Is this trying to address the = case where CA continues to operate after it
>=3B >=3B>=3B>=3B ha= s been compromised?
>=3B >=3B>=3B>=3B I'm assuming that in this = case EE certificates have been signed using the
>=3B >=3B>=3B>= =3B CA
>=3B >=3B>=3B>=3B key and somehow deleted from the CA's i= ssued certificates repository.
>=3B >=3B>=3B>=3B What happens if= the attacker issued an OCSP signing certificate (with
>=3B >=3B>= =3B>=3B OCSP-no-check) as opposed to an EE certificate?
>=3B >=3B&= gt=3B>=3B
>=3B >=3B>=3B>=3B Many of us would believe that only= way to address this breach is to revoke
>=3B >=3B>=3B>=3B the C= A.
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B There could be= limited use of this extension for the CA to determine if it
>=3B >= =3B>=3B>=3B has been compromised.
>=3B >=3B>=3B>=3B
>= =3B >=3B>=3B>=3B -Piyush
>=3B >=3B>=3B>=3B
>=3B >= =3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B&g= t=3B -----Original Message-----
>=3B >=3B>=3B>=3B>=3B From: pk= ix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
>=3B &= gt=3B>=3B>=3B>=3B Tom Gindin
>=3B >=3B>=3B>=3B>=3B Sent:= Saturday=2C March 10=2C 2012 9:50 AM
>=3B >=3B>=3B>=3B>=3B To= : pkix
>=3B >=3B>=3B>=3B>=3B Subject: [pkix] Possible OCSP Ext= ensions
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= =3B  =3B  =3B  =3B  =3B Why isn't there an OCSP response ex= tension containing "never
>=3B >=3B>=3B>=3B issued" or
>=3B= >=3B>=3B>=3B>=3B "outside validity period" which a responder may u= se if they have the
>=3B >=3B>=3B>=3B CA's
>=3B >=3B>= =3B>=3B>=3B certificate repository available?  =3BGetting a request= that produces such
>=3B >=3B>=3B>=3B an
>=3B >=3B>=3B&= gt=3B>=3B error would not be anything which the responder would be expect= ed to
>=3B >=3B>=3B>=3B>=3B report.  =3BA client who had r= eceived a response with such an extension
>=3B >=3B>=3B>=3B coul= d
>=3B >=3B>=3B>=3B>=3B then demonstrate that an actual compro= mise had occurred by resending the
>=3B >=3B>=3B>=3B>=3B reque= st with a request extension containing the actual certificate=2C or
>= =3B >=3B>=3B>=3B perhaps
>=3B >=3B>=3B>=3B>=3B the chain= =2C which had provoked that response extension above.  =3BReceiving
= >=3B >=3B>=3B>=3B>=3B such a certificate would allow the OCSP ser= ver to verify that the CA had
>=3B >=3B>=3B>=3B>=3B actually b= een cracked and then react.
>=3B >=3B>=3B>=3B>=3B  =3B &nb= sp=3B  =3B  =3B I think that such a feature would be useful to resp= onders
>=3B >=3B>=3B>=3B operated
>=3B >=3B>=3B>=3B b= y a
>=3B >=3B>=3B>=3B>=3B CA with many subordinate CA's=2C and= possibly to others as well.
>=3B >=3B>=3B>=3B>=3B
>=3B &= gt=3B>=3B>=3B>=3B Tom Gindin
>=3B >=3B>=3B>=3B>=3B P.S. = - The above suggestion is mine=2C and not necessarily that of my
>=3B = >=3B>=3B>=3B employer.
>=3B >=3B>=3B>=3B>=3B
>=3B &= gt=3B>=3B>=3B>=3B _______________________________________________
= >=3B >=3B>=3B>=3B>=3B pkix mailing list
>=3B >=3B>=3B>= =3B>=3B pkix@ietf.org
>=3B >=3B>=3B>=3B>=3B https://www.ietf= .org/mailman/listinfo/pkix
>=3B >=3B>=3B>=3B
>=3B >=3B>= =3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B
>=3B >= =3B>=3B
>=3B >=3B>=3B
>=3B >=3B _________________________= ______________________
>=3B >=3B pkix mailing list
>=3B >=3B = pkix@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/pkix>=3B
>=3B
>=3B
>=3B --
>=3B Website: http://hal= lambaker.com/
>=3B _______________________________________________
= >=3B pkix mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf= .org/mailman/listinfo/pkix
= --_146ade78-9141-483f-a8bc-84a259e01da6_-- From jlopez.ha@gmail.com Wed Mar 14 01:19:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE6B21F86D7 for ; Wed, 14 Mar 2012 01:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnKR+MzHk41M for ; Wed, 14 Mar 2012 01:19:47 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB8321F86CB for ; Wed, 14 Mar 2012 01:19:46 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1721619ggm.31 for ; Wed, 14 Mar 2012 01:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nur6TnYryUiuPayPkYoNvdIVypAPfRZL78QdnKp8ZmA=; b=O4GB2NpQHnNrDINkAnAh4Ut5fA+te1xmLzjvG8QzmJfEYPJOG8ATWNQ6IxxaF7yl0f paZ7eZJ2+lySIVyNx+DwWu4fzLXBv9z++eU86iDWrhuDDEigPvJYCVrm995qnsYHYN44 G0eNlNv5bq8qZuXF8+OkstZ3ZA6hCQa3RaRKJcDbI+cAtqWzT0MBHlSewzuXd8apl902 M4V3JF0hB2ZhTMzRRdEslSH2kH+0H55xCKAyoKL/qox4H+rE8uEBhTNCHxwEwocpO9vG ixNsLw53uyYRznzeMZvQ/JTlOlpq/eTvknU4EQlxMaY8naARpJeaMHAWbXt+DjDH+Ggi 86Kw== MIME-Version: 1.0 Received: by 10.101.128.23 with SMTP id f23mr608813ann.9.1331713186398; Wed, 14 Mar 2012 01:19:46 -0700 (PDT) Received: by 10.100.59.9 with HTTP; Wed, 14 Mar 2012 01:19:46 -0700 (PDT) In-Reply-To: References: <4F3D8AEB.1060408@lockstep.com.au> Date: Wed, 14 Mar 2012 09:19:46 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=001636c597ef6b012004bb2fa332 Cc: pkix Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 08:19:50 -0000 --001636c597ef6b012004bb2fa332 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Just one remark: As Dan mentioned, collision attacks (find 2 messages such that their hashes coincide) are of higher concern than pre-image (having a hash h find a message M / hash(M) =3D h) and second pre-image attacks (havi= ng a message M find a second message M' / hash(M) =3D hash(M'), but the algorithmic complexity of the former (collision attacks) is not half of the latter, but much lower. Particularly, it is 2^(n/2), n being the length of the hash, while for pre-image and second pre-image attacks is 2^n. There is an exponential difference, not linear. Having said that, there are theoretical attacks that reduce the complexity needed to find a collision that are below brute force. I say theoretical because though they are below 2^64 for SHA-1 they are still impractical. As far as I now, in 2010 Marc Stevens implemented a differential path attack against SHA-1 with a complexity of about 2^57. I am not very updated on this topic, so maybe there have been some contributions to the field in the last year that have gone even beyond that. Best, Jorge. 2012/2/17 Miller, Timothy J. > Arjen Lenstra and Benne de Weger's work with MD5 may be of interest to > you. Not a preimage attack, but the method of integrating a collision > into X.509 may be relevant. > > http://www.win.tue.nl/~bdeweger/CollidingCertificates/ > > -- T > > On 2/16/12 5:02 PM, "Stephen Wilson" wrote: > > > > > > > > > > > Many thanks Dan for this and the subsequent clarification. > > > > Can I ask a silly question: I've assumed that in preimage attacks > > [where synthetic data A' is computed so that Hash(A') =3D=3D Hash(A) > > original data A] it is not necessary for A and A' to have the same > > bit length. I am guessing that computing A' is a whole lot easier > > if you can make it as long as you like. > > > > Now, you ponder "how much flexibility there is in the X.509 format" > > and I it's fair to say there is a lot. You can add totally custom > > fields to a certificate and in general, most X.509 parsers will skip > > over them. > > > > So here's a thought. If A' can be longer than A, then a preimage > > attacker could add a nonsense field to the SHA1+RSA profile of > > interest, and populate that extra field with whatever data is needed > > to 'compensate' for tampering with data in the original body of the > > certificate (say the public key value). The nonsense field might be > > arbitrarily long and still escape the notice of the applications > > consuming the certificates. > > > > Cheers, > > > > Steve Wilson. > > > > > > > > On 17/02/2012 8:16 AM, Dan Brown wrote: > > > > > > > > > > > > > > Hi > > Stephen, > > > > Regarding > > your supplementary question: > > > > > > 1) > > You=B9re > > right that the pre-image would need to meet the X.509 > > ToBeSigend format, so it would depend on the nature of the > > pre-image attack. Any pre-image attack on SHA-1 would > > require about 160 bits of flexibility in the pre-image > > format (i.e. to have a large enough target pre-image space > > to ensure that pre-images of the hash value to be inverted > > exists). I=B9m not sure how much flexibility there is in th= e > > X.509 format, but I think the serial number could support a > > sequence of freely chosen bits, which may be a simple enough > > formatting restriction to accommodate some pre-image > > attacks. (Although the resulting serial number may be larger > > than usual, so could be viewed as suspicious.) The public > > exponent in an RSA key could support 160 bits, but the > > result would look suspicious. The subject name has a large > > amount of flexibility, but it seems especially unlikely that > > an actual faster-than-generic pre-image attack have the > > needed control in the pre-image. > > > > 2) > > The > > answer also depends the vulnerability of the signature > > algorithm to hash pre-image attacks. The algorithms DSA and > > ECDSA admit existential forgery using a hash pre-image > > finder, and so does RSA-PSS as specified in PKCS#1 version > > 2.1 (but as far as I can tell not RSA-PSS as originally > > propose by Bellare and Rogaway). I don=B9t see how a hash > > pre-image finder suffices to forge an RSA-PKCS1-v1.5 > > signature. > > > > 3) > > Under > > generic attacks, a hash functions=B9s pre-image resistance h= as > > about the twice the security level of the collision > > resistance (exhaustive search vs. birthday). Typically, the > > public key is chosen to have a security level half that of > > the pre-image resistance of hash. So, normally hash > > pre-image attacks are not a concern for signatures, unless > > they are very drastic improvements over exhaustive search. > > > > > > Best > > regards, > > > > > > > > > > > > > > Daniel > > Brown > > > > > > > > > > Research > > In Motion Limited > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: > > pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] > > On Behalf Of Stephen Wilson > > Sent: Thursday, February 09, 2012 2:44 PM > > To: pkix > > Subject: [pkix] Off topic: Preimage attack on > > SHA-1 > > > > > > > > > > Colleagues, > > > > Trying the PKIX > > list for its cryptographic expertise, I hope you don't > > mind: > > > > > > Is anyone aware > > of a demonstrated preimage attack (or demonstrated > > feasibility of a practical preimage attack) on SHA-1? > > Is it still the case, as it was when RFC4270 was > > published in 2005, that there is only the possibility > > of Collision attack? > > > > Supplementary > > question: Does anyone think a preimage attack on the > > signature of a PKC, even if mounted, would be a > > practical problem? I would have thought there would > > be so much interference with the rest of the data > > structures that the certificate would become > > unparseable. > > > > Cheers, > > > > > > > > Stephen Wilson > > Lockstep > > http://lockstep.com.au > > Lockstep Consulting provides independent specialist > > advice and analysis > > on digital identity and privacy. Lockstep Technologies > > develops unique > > new smart ID solutions that enhance privacy and prevent > > identity theft. > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > > This transmission (including any attachments) may contain > > confidential information, privileged material (including material > > protected by the solicitor-client or other applicable privileges), > > or constitute non-public information. Any use of this information > > by anyone other than the intended recipient is prohibited. If you > > have received this transmission in error, please immediately reply > > to the sender and delete this information from your system. Use, > > dissemination, distribution, or reproduction of this transmission > > by unintended recipients is not authorized and may be unlawful. > > > > > > > > > >_______________________________________________ > >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 > --001636c597ef6b012004bb2fa332 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Just one remark: As Dan mentioned, collision attacks= (find 2 messages such that their hashes coincide) are of higher concern th= an pre-image (having a hash h find a message M / hash(M) =3D h) and second = pre-image attacks (having a message M find a second message M' / hash(M= ) =3D hash(M'), but the algorithmic complexity of the former (collision= attacks) is not half of the latter, but much lower. Particularly, it is 2^= (n/2), n being the length of the hash, while for pre-image and second pre-i= mage attacks is 2^n. There is an exponential difference, not linear.

Having said that, there are theoretical attacks that re= duce the complexity needed to find a collision that are=A0below brute force= . I say theoretical because though they are below 2^64 for SHA-1 they are s= till impractical. As far as I now, in 2010=A0= Marc Stevens implemented a differentia= l path attack against SHA-1 with a complexity of about 2^57. I=A0am = not very updated on this topic, so maybe there have been some contributions= to the field in the last year that have gone even beyond that.

Best,

Jorge.

2012/2/17 Miller, Timothy J. <tmiller@mitre.org>
Arjen Lenstra and Benne de Weger's work with MD5 may be of interest to<= br> you. =A0Not a preimage attack, but the method of integrating a collision into X.509 may be relevant.

http://www.win.tue.nl/~bdeweger/CollidingCertificates/

-- T

On 2/16/12 5:02 PM, "Stephen Wilson" <swilson@lockstep.com.au> wrote:

>
>
>
>
> =A0 =A0Many thanks Dan for this and the subsequent clarification.
>
> =A0 =A0Can I ask a silly question: I've assumed that in preimage a= ttacks
> =A0 =A0[where synthetic data A' is computed so that Hash(A') = =3D=3D Hash(A)
> =A0 =A0original data A] it is not necessary for A and A' to have t= he same
> =A0 =A0bit length. =A0I am guessing that computing A' is a whole l= ot easier
> =A0 =A0if you can make it as long as you like.
>
> =A0 =A0Now, you ponder "how much flexibility there is in the X.50= 9 format"
> =A0 =A0and I it's fair to say there is a lot. =A0You can add total= ly custom
> =A0 =A0fields to a certificate and in general, most X.509 parsers will= skip
> =A0 =A0over them.
>
> =A0 =A0So here's a thought. =A0If A' can be longer than A, the= n a preimage
> =A0 =A0attacker could add a nonsense field to the SHA1+RSA profile of<= br> > =A0 =A0interest, and populate that extra field with whatever data is n= eeded
> =A0 =A0to 'compensate' for tampering with data in the original= body of the
> =A0 =A0certificate (say the public key value). The nonsense field migh= t be
> =A0 =A0arbitrarily long and still escape the notice of the application= s
> =A0 =A0consuming the certificates.
>
> =A0 =A0Cheers,
>
> =A0 =A0Steve Wilson.
>
>
>
> =A0 =A0On 17/02/2012 8:16 AM, Dan Brown wrote:
>
>
>
>
>
>
> =A0 =A0 =A0 =A0Hi
> =A0 =A0 =A0 =A0 =A0 =A0Stephen,
>
> =A0 =A0 =A0 =A0Regarding
> =A0 =A0 =A0 =A0 =A0 =A0your supplementary question:
>
>
> =A0 =A0 =A0 =A01)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0You=B9re
> =A0 =A0 =A0 =A0 =A0 =A0right that the pre-image would need to meet the= X.509
> =A0 =A0 =A0 =A0 =A0 =A0ToBeSigend format, so it would depend on the na= ture of the
> =A0 =A0 =A0 =A0 =A0 =A0pre-image attack. =A0Any pre-image attack on SH= A-1 would
> =A0 =A0 =A0 =A0 =A0 =A0require about 160 bits of flexibility in the pr= e-image
> =A0 =A0 =A0 =A0 =A0 =A0format (i.e. to have a large enough target pre-= image space
> =A0 =A0 =A0 =A0 =A0 =A0to ensure that pre-images of the hash value to = be inverted
> =A0 =A0 =A0 =A0 =A0 =A0exists). =A0I=B9m not sure how much flexibility= there is in the
> =A0 =A0 =A0 =A0 =A0 =A0X.509 format, but I think the serial number cou= ld support a
> =A0 =A0 =A0 =A0 =A0 =A0sequence of freely chosen bits, which may be a = simple enough
> =A0 =A0 =A0 =A0 =A0 =A0formatting restriction to accommodate some pre-= image
> =A0 =A0 =A0 =A0 =A0 =A0attacks. (Although the resulting serial number = may be larger
> =A0 =A0 =A0 =A0 =A0 =A0than usual, so could be viewed as suspicious.) = =A0The public
> =A0 =A0 =A0 =A0 =A0 =A0exponent in an RSA key could support 160 bits, = but the
> =A0 =A0 =A0 =A0 =A0 =A0result would look suspicious. =A0The subject na= me has a large
> =A0 =A0 =A0 =A0 =A0 =A0amount of flexibility, but it seems especially = unlikely that
> =A0 =A0 =A0 =A0 =A0 =A0an actual faster-than-generic pre-image attack = have the
> =A0 =A0 =A0 =A0 =A0 =A0needed control in the pre-image.
>
> =A0 =A0 =A0 =A02)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0The
> =A0 =A0 =A0 =A0 =A0 =A0answer also depends the vulnerability of the si= gnature
> =A0 =A0 =A0 =A0 =A0 =A0algorithm to hash pre-image attacks. =A0The alg= orithms DSA and
> =A0 =A0 =A0 =A0 =A0 =A0ECDSA admit existential forgery using a hash pr= e-image
> =A0 =A0 =A0 =A0 =A0 =A0finder, and so does RSA-PSS as specified in PKC= S#1 version
> =A0 =A0 =A0 =A0 =A0 =A02.1 (but as far as I can tell not RSA-PSS as or= iginally
> =A0 =A0 =A0 =A0 =A0 =A0propose by Bellare and Rogaway). =A0I don=B9t s= ee how a hash
> =A0 =A0 =A0 =A0 =A0 =A0pre-image finder suffices to forge an RSA-PKCS1= -v1.5
> =A0 =A0 =A0 =A0 =A0 =A0signature.
>
> =A0 =A0 =A0 =A03)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Under
> =A0 =A0 =A0 =A0 =A0 =A0generic attacks, a hash functions=B9s pre-image= resistance has
> =A0 =A0 =A0 =A0 =A0 =A0about the twice the security level of the colli= sion
> =A0 =A0 =A0 =A0 =A0 =A0resistance (exhaustive search vs. birthday). = =A0Typically, the
> =A0 =A0 =A0 =A0 =A0 =A0public key is chosen to have a security level h= alf that of
> =A0 =A0 =A0 =A0 =A0 =A0the pre-image resistance of hash. =A0So, normal= ly hash
> =A0 =A0 =A0 =A0 =A0 =A0pre-image attacks are not a concern for signatu= res, unless
> =A0 =A0 =A0 =A0 =A0 =A0they are very drastic improvements over exhaust= ive search.
>
>
> =A0 =A0 =A0 =A0Best
> =A0 =A0 =A0 =A0 =A0 =A0regards,
>
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Daniel
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Brown
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In Motion Limited
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From= :
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On Behalf Of Stephen Wilson
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Thursday, February 09, 20= 12 2:44 PM
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To: pkix
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: [pkix] Off topic: Prei= mage attack on
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SHA-1
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Colleagues,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Trying the PKIX
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0list for its cryptographic expertis= e, I hope you don't
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mind:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Is anyone aware
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of a demonstrated preimage attack (= or demonstrated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0feasibility of a practical preimage= attack) on SHA-1?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is it still the case, as it was whe= n RFC4270 was
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0published in 2005, that there is on= ly the possibility
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of Collision attack?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Supplementary
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0question: Does anyone think a preim= age attack on the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0signature of a PKC, even if mounted= , would be a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0practical problem? =A0I would have = thought there would
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be so much interference with the re= st of the data
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0structures that the certificate wou= ld become
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unparseable.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cheers,
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0Stephen Wilson
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Lockstep
> =A0 =A0 =A0 =A0 =A0 =A0http://lockstep.com.au <http://www.lockstep.com.au>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Lockstep Consulting p= rovides independent specialist
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0advice and analysis
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on digital identity and privacy. =A0Loc= kstep Technologies
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0develops unique
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new smart ID solutions that enhance pri= vacy and prevent
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0identity theft.
>
>
>
>
>
>
>
>--------------------------------------------------------------------- >
> =A0 =A0 =A0This transmission (including any attachments) may contain > =A0 =A0 =A0confidential information, privileged material (including ma= terial
> =A0 =A0 =A0protected by the solicitor-client or other applicable privi= leges),
> =A0 =A0 =A0or constitute non-public information. Any use of this infor= mation
> =A0 =A0 =A0by anyone other than the intended recipient is prohibited. = If you
> =A0 =A0 =A0have received this transmission in error, please immediatel= y reply
> =A0 =A0 =A0to the sender and delete this information from your system.= Use,
> =A0 =A0 =A0dissemination, distribution, or reproduction of this transm= ission
> =A0 =A0 =A0by unintended recipients is not authorized and may be unlaw= ful.
>
>
>
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix

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

--001636c597ef6b012004bb2fa332-- From tomas@primekey.se Wed Mar 14 01:37:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061A721F86F1 for ; Wed, 14 Mar 2012 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfBk-BFLnVO4 for ; Wed, 14 Mar 2012 01:37:40 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id E873521F86EE for ; Wed, 14 Mar 2012 01:37:39 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 46758E0B92; Wed, 14 Mar 2012 09:37:45 +0100 (CET) Received: from [192.168.3.193] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 3091CE0B27; Wed, 14 Mar 2012 09:37:45 +0100 (CET) Message-ID: <4F6058D2.1000502@primekey.se> Date: Wed, 14 Mar 2012 09:37:38 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120309 Thunderbird/11.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4F5F0148.4020702@primekey.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 08:37:41 -0000 My problem lies in: > Create OCSP non-existence responses for > C[0].serial+1 -> C[1].serial-1 Since it says "responses". The gap "C[0].serial+1 -> C[1].serial-1" might very well be 10 billion serials, making that completely infeasible with modern hardware. From a scalability point of view the use case with 100 issued certificates is not very interesting. The solutions should work with 100 million certificates, and an issuance frequency of 100 certificates per second, or something like that. Or are you targeting a corner case with a relatively static CA that does not do much? Cheers, Tomas On 03/14/2012 02:36 AM, Phillip Hallam-Baker wrote: > So to work out the gaps: > > Take the set of issued certs C_set > Sort by serial number to produce a list C_list [0..99] > > Create OCSP status responses for > C[0].serial > C[1].serial > ... > C[99].serial > > Create OCSP non-existence responses for > C[0].serial+1 -> C[1].serial-1 > C[1].serial+1 -> C[2].serial-1 > ... > C[98].serial+1 -> C[99].serial-1 > C[99].serial+1 -> C[0].serial-1 > > Does that answer the question? > > On Tue, Mar 13, 2012 at 4:11 AM, Tomas Gustavsson wrote: >> >> >> On 03/12/2012 02:29 PM, Phillip Hallam-Baker wrote: >>> Actually, the idea for the serial numbers was not that they would >>> necessarily be monotonic, rather the idea is just to sign the gaps. If >>> the CA signs non-monotonic serial numbers then they would have to sort >>> them into order first. >>> >>> So the way a CA would work is that every OCSP signing increment, say 1 >>> hour, they would create OCSP responses for >>> >>> 1) Every known cert issued >>> 2) The gaps between the serial numbers. >>> >>> So with 100 certs issued, this would be 200 OCSP responses. >> >> This is not clear to me? If we, for example, use random 64 bit serial >> numbers (which is good for several reasons). After 100 issued >> certificates I would not for any practical reasons be able to calculate >> any "gaps". >> >> "Gaps" for certificate serial number seems to me to be a non existing thing. >> >> Cheers, >> Tomas >> >>> >>> >>> If a cert is issued within that time interval, the CA creates three >>> additional OCSP responses, one for the new cert and two for the new >>> serial number intervals that have just been created. >>> >>> This approach allows CAs to avoid creating additional timing errors >>> but is still robust if they are introduced by others. >>> >>> >>> On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin wrote: >>>> Piyush: >>>> >>>> One purpose of this is to identify cases where the issuer has >>>> apparently been compromised, and the major purpose of the request >>>> extension (call it "requested certificate body" or "requested certificate >>>> chain") is to allow such a case to be substantiated. Once the request is >>>> substantiated, I would expect the issuer key to be treated as compromised >>>> unless the submitted certificate is a digest duplicate against an actual >>>> issued certificate. That would be an algorithmic issue rather than a key >>>> compromise. >>>> I'd like to adapt part of Phill's suggestion, and redefine the >>>> proposed "never issued" status as "Not issued before" and a time. The >>>> presigned variant, which might be called "no serial number within range", >>>> seems right for issuers with increasing serial numbers but makes less >>>> sense for issuers who assign serial numbers which don't monotonically >>>> increase with time. Phill, is that supposed to be the closed interval >>>> (with the two endpoint serial numbers not issued) or the open one (with >>>> the two endpoint serial numbers issued)? Also, is there an option in >>>> which the upper bound is not specified which means "no serial number above >>>> L had been issued as of time T"? >>>> >>>> >>>> Tom Gindin >>>> >>>> >>>> >>>> >>>> >>>> From: Piyush Jain >>>> To: Tom Gindin/Watson/IBM@IBMUS, "'pkix'", >>>> Date: 03/11/2012 01:17 PM >>>> Subject: RE: [pkix] Possible OCSP Extensions >>>> >>>> >>>> >>>> Is this trying to address the case where CA continues to operate after it >>>> has been compromised? >>>> I'm assuming that in this case EE certificates have been signed using the >>>> CA >>>> key and somehow deleted from the CA's issued certificates repository. >>>> What happens if the attacker issued an OCSP signing certificate (with >>>> OCSP-no-check) as opposed to an EE certificate? >>>> >>>> Many of us would believe that only way to address this breach is to revoke >>>> the CA. >>>> >>>> There could be limited use of this extension for the CA to determine if it >>>> has been compromised. >>>> >>>> -Piyush >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>>>> Tom Gindin >>>>> Sent: Saturday, March 10, 2012 9:50 AM >>>>> To: pkix >>>>> Subject: [pkix] Possible OCSP Extensions >>>>> >>>>> Why isn't there an OCSP response extension containing "never >>>> issued" or >>>>> "outside validity period" which a responder may use if they have the >>>> CA's >>>>> certificate repository available? Getting a request that produces such >>>> an >>>>> error would not be anything which the responder would be expected to >>>>> report. A client who had received a response with such an extension >>>> could >>>>> then demonstrate that an actual compromise had occurred by resending the >>>>> request with a request extension containing the actual certificate, or >>>> perhaps >>>>> the chain, which had provoked that response extension above. Receiving >>>>> such a certificate would allow the OCSP server to verify that the CA had >>>>> actually been cracked and then react. >>>>> I think that such a feature would be useful to responders >>>> operated >>>> by a >>>>> CA with many subordinate CA's, and possibly to others as well. >>>>> >>>>> Tom Gindin >>>>> P.S. - The above suggestion is mine, and not necessarily that of my >>>> employer. >>>>> >>>>> _______________________________________________ >>>>> 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 eabalea@gmail.com Wed Mar 14 06:05:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5E21F8769 for ; Wed, 14 Mar 2012 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOgsZCdNrKrQ for ; Wed, 14 Mar 2012 06:05:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE521F8760 for ; Wed, 14 Mar 2012 06:05:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2035638ghb.31 for ; Wed, 14 Mar 2012 06:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oandh/Te5en6LLTcefbQk5F+x840nFA/8LEXLtPwP5E=; b=nMoB1aNt8zqo5USEbtbOily1ovZBwPRHuyhQk7UbkcArFFyerEUoRvF0CWghE/v4uG +nogxY8RzgjTVNHTKI3teOWv9IlpjPxD0dLYSKeDvyKV54zCoaPLHuYLznlScU47OZa4 IN/yA5ecSTPYwiI53KmG1mwhOKsKRAmTXQlrUa3flp3KTQx4yzdPOjUt9jvctTgRz5H2 dfESbjI817JAj6KIMJ0VPMoDk3SUvTMDhGbX4Gbr/fwBcGkMkbbXLQatNkiUAXFXajP4 vPYclovcLjLa60uO2pCIBQCLHVoao1CilIi2AyXTOrqEKMTrQHZtQYJLAz5Rpe01ErsA brMg== MIME-Version: 1.0 Received: by 10.236.161.72 with SMTP id v48mr2800669yhk.112.1331730311887; Wed, 14 Mar 2012 06:05:11 -0700 (PDT) Received: by 10.236.207.2 with HTTP; Wed, 14 Mar 2012 06:05:11 -0700 (PDT) In-Reply-To: <4F6058D2.1000502@primekey.se> References: <4F5F0148.4020702@primekey.se> <4F6058D2.1000502@primekey.se> Date: Wed, 14 Mar 2012 14:05:11 +0100 Message-ID: From: Erwann Abalea To: Tomas Gustavsson Content-Type: multipart/alternative; boundary=20cf302ef83e2d3c5004bb33a05e Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 13:05:13 -0000 --20cf302ef83e2d3c5004bb33a05e Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/3/14 Tomas Gustavsson > > My problem lies in: > > > > Create OCSP non-existence responses for > > C[0].serial+1 -> C[1].serial-1 > > Since it says "responses". The gap "C[0].serial+1 -> C[1].serial-1" might > very well be 10 billion serials, making that completely infeasible with > modern hardware. > I think noone asked for an OCSP response for all possible serial numbers. Just an OCSP response with the 2 integers for the range bounds. These integers must be optional, to be able to semantically represent -Inf and +Inf. -- Erwann. --20cf302ef83e2d3c5004bb33a05e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

2012/3/14 Tomas Gustavsson <tomas@primekey.se= >

My problem lies in:


> Create OCSP non-existence responses for
> =C2=A0 =C2=A0 =C2=A0C[0].serial+1 -> =C2=A0C[1].serial-1

Since it says "responses". The gap "C[0].serial+1 -> =C2= =A0C[1].serial-1" might very well be 10 billion serials, making that c= ompletely infeasible with modern hardware.

I think= noone asked for an OCSP response for all possible serial numbers.
Just an OCSP response with the 2 integers for the range bounds.
These in= tegers must be optional, to be able to semantically represent -Inf and +Inf= .

--
Erwann.
--20cf302ef83e2d3c5004bb33a05e-- From eabalea@gmail.com Wed Mar 14 06:20:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7BE21F86E5 for ; Wed, 14 Mar 2012 06:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoZ9bt55E0xs for ; Wed, 14 Mar 2012 06:20:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 951B121F86C7 for ; Wed, 14 Mar 2012 06:20:26 -0700 (PDT) Received: by mail-yx0-f172.google.com with SMTP id m5so2057224yen.31 for ; Wed, 14 Mar 2012 06:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l703PCKca6+n5rXg1cPXQ0/mtkM2Q5R+ugmFMUXvVro=; b=gXTvX7jikY+YxYKhcpH6ZfAB4ube8DklBXMJAJDEOYBGxjfbnFzOsUJbIpYT3FQf1f iF66Y1ExsFKCVNJU7X4GdKDnALwcfWCxpm5jiwewRqIFtqwIgW5aQUcJbvXblOonPBd3 UIiYiX25OcYoA71zqvyrgdkS9ogaEwcuaAzqAuA3osTkODMQHlur+lw9AsZjYFUHJDjB cTXIzdoCcRrwwv6jyChG70NYN6unt7x9hhrsZPM/YtWrxyqJ+kIt/gEiD5qj8ZcBVcIW qjFT/jihXNgXk9/vFBiWSjvpCQNPvQBfeW3Wiuns1z0jsPdra0nNfR3kozh0oRgsJwn1 wGag== MIME-Version: 1.0 Received: by 10.236.161.72 with SMTP id v48mr2865059yhk.112.1331731226401; Wed, 14 Mar 2012 06:20:26 -0700 (PDT) Received: by 10.236.207.2 with HTTP; Wed, 14 Mar 2012 06:20:26 -0700 (PDT) In-Reply-To: References: <4F5F0148.4020702@primekey.se> Date: Wed, 14 Mar 2012 14:20:26 +0100 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf302ef83eaf9dd304bb33d6bf Cc: Tomas Gustavsson , pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 13:20:27 -0000 --20cf302ef83eaf9dd304bb33d6bf Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/3/14 Phillip Hallam-Baker > So to work out the gaps: > > Take the set of issued certs C_set > Sort by serial number to produce a list C_list [0..99] > > Create OCSP status responses for > C[0].serial > C[1].serial > ... > C[99].serial > > Create OCSP non-existence responses for > C[0].serial+1 -> C[1].serial-1 > C[1].serial+1 -> C[2].serial-1 > ... > C[98].serial+1 -> C[99].serial-1 > C[99].serial+1 -> C[0].serial-1 > That last "link" has no sense. You need to create an OCSP response from -Inf to C[0].serial-1, and another one from C[99].serial+1 to +Inf. Precisely, for n certificates, you need 2n+1 OCSP responses. Short-lived ones, preferably (1 day, maybe?). Now expand the example to larger numbers. Imagine a deployed PKI for 300 million certificates, renewed every few years (this is not a purely hypothetical example). CRL based validation is not an option (well, it may work for signatures, but not authentication). OCSP is a good tool, as an OCSP response need only be produced when asked. Using the proposed scheme would require the CA to sign 600 million OCSP tokens every day. That's 7000 signatures per second, 7000 OCSP responses produced and stored somewhere per second, every single second, even if the OCSP response is not used. OCSP becomes now a non option. -- Erwann. --20cf302ef83eaf9dd304bb33d6bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

2012/3/14 Phillip Hallam-Baker <= span dir=3D"ltr"><hallam@gmail.com>
So to work out the gaps:

Take the set of issued certs C_set
Sort by serial number to produce a list C_list [0..99]

Create OCSP status responses for
=C2=A0 C[0].serial
=C2=A0 C[1].serial
=C2=A0 ...
=C2=A0 C[99].serial

Create OCSP non-existence responses for
=C2=A0 =C2=A0C[0].serial+1 -> C[1].serial-1
=C2=A0 =C2=A0C[1].serial+1 -> C[2].serial-1
=C2=A0 =C2=A0...
=C2=A0 =C2=A0C[98].serial+1 -> C[99].serial-1
=C2=A0 =C2=A0C[99].serial+1 -> C[0].serial-1

T= hat last "link" has no sense. You need to create an OCSP response= from -Inf to C[0].serial-1, and another one from C[99].serial+1 to +Inf. <= br>
Precisely, for n certificates, you need 2n+1 OCSP responses. Short-lived on= es, preferably (1 day, maybe?).

Now expand the example t= o larger numbers. Imagine a deployed PKI for 300 million certificates, rene= wed every few years (this is not a purely hypothetical example).
CRL based validation is not an option (well, it may work for signatures, bu= t not authentication). OCSP is a good tool, as an OCSP response need only b= e produced when asked.

Using the proposed scheme would require the C= A to sign 600 million OCSP tokens every day. That's 7000 signatures per= second, 7000 OCSP responses produced and stored somewhere per second, ever= y single second, even if the OCSP response is not used. OCSP becomes now a = non option.

--
Erwann.
--20cf302ef83eaf9dd304bb33d6bf-- From denis.pinkas@bull.net Wed Mar 14 06:37:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4633421F879D for ; Wed, 14 Mar 2012 06:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNdtqXNAcFqY for ; Wed, 14 Mar 2012 06:37:27 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24C21F8799 for ; Wed, 14 Mar 2012 06:37:26 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 6F9FE180B7; Wed, 14 Mar 2012 14:37:25 +0100 (CET) In-Reply-To: References: To: Phillip Hallam-Baker MIME-Version: 1.0 X-KeepSent: 948F0895:F3107BD0-C12579C1:0049B2DF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 14 Mar 2012 14:37:24 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 14/03/2012 14:37:25, Serialize complete at 14/03/2012 14:37:25 Content-Type: multipart/alternative; boundary="=_alternative 004AD31CC12579C1_=" Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 13:37:28 -0000 Message en plusieurs parties au format MIME --=_alternative 004AD31CC12579C1_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Phil, You claim that OCSP was originally designed to report archival status at a = specific point in time. The fact is that OCSP is currently unable to report archival status at a=20 specific point in time. OCSP reports the revocation status : a) if the certificate is not expired, at the current time (or close to the = current time when cached responses are supported), b) if both the certificate is expired and the archive cutoff extension is=20 supported, as it was at the end of the certificate's validity period.=20 Denis=20 De : Phillip Hallam-Baker A : denis.pinkas@bull.net Cc : Tom Gindin , pkix@ietf.org Date : 14/03/2012 02:30 Objet : Re: [pkix] Possible OCSP Extensions No, that is untrue, OCSP was originally designed to report archival status at a specific point in time. People can pull out the good stuff out of the specs if they like but they don't get to say that it was never the intention to do it. On Tue, Mar 13, 2012 at 3:49 AM, wrote: > Tom, > > One of your arguments is to say that the proposal "can't distinguish=20 never > issued from outside validity period > if expired certificates are purged from the repository". The question is > whether this is really necessary. > The answer is that it is not necessary, as explained below. > > A key point is that OSCP has only been designed to provide the=20 revocation > status of a certificate at the current time. > > It should be the responsibility of the OCSP client, before making the=20 OCSP > request, to test that the current time > is within the validity period of the certificate. Thus if a certificate > serial number refers to a certificate that has expired, > the OCSP response is not meaningful. > > However, if the proposal is included, explanations should clearly=20 indicate > that the additional status is only meaningful > if the client has locally tested that the the current time is within the > validity period of the certificate. > > Denis > > > > > De : Tom Gindin > A : denis.pinkas@bull.net > Cc : pkix@ietf.org > Date : 12/03/2012 15:21 > Objet : RE: [pkix] Possible OCSP Extensions > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F > > > > Denis: > > "Outside validity period" means, in most cases, that the serial > number requested was indeed issued by the CA but is now expired. It=20 could > also mean that the "NotBefore" time is still in the future, but that=20 would > be much rarer. It would be feasible to distinguish Expired from Not Yet > Valid in the response extension, of course. > Naturally, an OCSP responder must have access to a repository > containing those certificates which are currently valid for a given=20 issuer > to determine any of these statuses. That's your third case, but you=20 can't > distinguish never issued from outside validity period if expired > certificates are purged from the repository. Neither the "revocation > database" case nor the "CRL only" case give the responder any basis to=20 say > whether a given serial number belongs to a currently valid certificate,=20 an > expired certificate which was never revoked, or neither. A full=20 database > of certificates which have ever been issued with a given issuer name > should allow the responder to classify any given certificate serial=20 number > for that issuer as "revoked" (including suspended), "valid", "expired", > "not yet", or "unknown". > If you feel it's desirable for the responder to include which > repository mode it's using in an extension, I personally see no reason=20 to > object to such a proposal. Including the repository mode is not=20 necessary > for the use of these extensions, because two of the modes are=20 inconsistent > with using them. > > Tom Gindin > > > > > From: denis.pinkas@bull.net > To: Tom Gindin/Watson/IBM@IBMUS, > Cc: pkix@ietf.org > Date: 03/12/2012 09:46 AM > Subject: RE: [pkix] Possible OCSP Extensions > > > > Tom, > > Your email is not crystal clear (at least to me) and seems to address at > the same time two different topics: > > - an OCSP response extension containing "never issued" and > - an OCSP response extension containing "outside validity period". > > I can understand "never issued", but I don't know what you mean, in the > context of OCSP, with "outside validity period" > > Your proposal seems allowing an OCSP server "to verify that a CA had > actually been cracked and then react". > The problem is that we cannot do this, until we first specify a way to > return a status like "never issued". > > Simply adding an additional status report like "never issued" would not=20 be > sufficient as explained below. > > The problem is that OSCP was originally designed to work either : > > - with CRLs only, or > - with a revocation status data base for revoked certificates only, or > - with a revocation status data base for all issued certificates managed > directly by the CA which issued that certificate. > > We currently have no way to indicate either in the request or in the > response > which of the three modes is/was requested or used. > > An OCSP server might only indicate "never issued", if it also indicates > that it got this information using > a revocation status data base for all issued certificates managed=20 directly > by the CA which has issued that certificate. > > This means that this extension may only be present if the OCSP responder > is using a revocation status data base > for all issued certificates managed directly by the CA which has issued > that certificate. > > This extension would then contain a boolean to say whether of not the > certificate was issued. > > I remember that we discuss this topic on the PKIX list but I don't > remember any concrete proposal. > > Once we have such a mechanism (or a similar one), then we can build on=20 it > and discuss (and understand better) your proposal. > > Denis > > > > > De : Tom Gindin > A : pkix > Date : 10/03/2012 18:51 > Objet : [pkix] Possible OCSP Extensions > Envoy=E9 par : pkix-bounces@ietf.org > > > > Why isn't there an OCSP response extension containing "never > issued" or "outside validity period" which a responder may use if they > have the CA's certificate repository available? Getting a request that > produces such an error would not be anything which the responder would=20 be > expected to report. A client who had received a response with such an > extension could then demonstrate that an actual compromise had occurred=20 by > > resending the request with a request extension containing the actual > certificate, or perhaps the chain, which had provoked that response > extension above. Receiving such a certificate would allow the OCSP=20 server > > to verify that the CA had actually been cracked and then react. > I think that such a feature would be useful to responders operated > by a CA with many subordinate CA's, and possibly to others as well. > > Tom Gindin > P.S. - The above suggestion is mine, and not necessarily that of my > employer. > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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 Website: http://hallambaker.com/ --=_alternative 004AD31CC12579C1_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Phil,

You claim that OCSP was originally design= ed to report archival status at a specific point in time.
The fact is that OCSP is currently unable to report archival status at a specific point in time.

OCSP reports the revocation status :

a) if the certificate is not expired, at the current time (or close to the current time when cached responses are supported),
b) if both the certificate is expired and the archive cutoff extension is supported, as it was at the end of the certificate's validity period.  

Denis



De :     &= nbsp;  Phillip Hallam-Baker <hallam@gmail.com>
A :     &n= bsp;  denis.pinkas@bull.net
Cc :   &nb= sp;    Tom Gindin <tgind= in@us.ibm.com>, pkix@ietf.org
Date :    =    14/03/2012 02:30
Objet :        Re: [pkix] Possible OCSP Extensions



No, that is untrue, OCSP was originally designed to report archival
status at a specific point in time.

People can pull out the good stuff out of the specs if they like but
they don't get to say that it was never the intention to do it.

On Tue, Mar 13, 2012 at 3:49 AM,  <denis.pinkas@bull.net> wrote:=
> Tom,
>
> One of your arguments is to say that the proposal "can't distingu= ish never
> issued from outside validity period
> if expired certificates are purged from the repository". The question is
> whether this is really necessary.
> The answer is that it is not necessary, as explained below.
>
> A key point is that OSCP has only been designed to provide the revocat= ion
> status of a certificate at the current time.
>
> It should be the responsibility of the OCSP client, before making the OCSP
> request, to test that the current time
> is within the validity period of the certificate. Thus if a certificat= e
> serial number refers to a certificate that has expired,
> the OCSP response is not meaningful.
>
> However, if the proposal is included, explanations should clearly indicate
> that the additional status is only meaningful
> if the client has locally tested that the the current time is within the
> validity period of the certificate.
>
> Denis
>
>
>
>
> De :        Tom Gindin <tgindin@us.ibm.com><= br> > A :        denis.pinkas@bull.net
> Cc :        pkix@ietf.org
> Date :        12/03/2012 15:21
> Objet :        RE: [pkix] Possible OCSP Extensions=
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
>
>
>
>         Denis:
>
>        "Outside validity period" means, in most cases, that the serial
> number requested was indeed issued by the CA but is now expired.  = ;It could
> also mean that the "NotBefore" time is still in the future, but that would
> be much rarer.  It would be feasible to distinguish Expired from Not Yet
> Valid in the response extension, of course.
>        Naturally, an OCSP responder must have access to a repository
> containing those certificates which are currently valid for a given issuer
> to determine any of these statuses.  That's your third case, but you can't
> distinguish never issued from outside validity period if expired
> certificates are purged from the repository.  Neither the "r= evocation
> database" case nor the "CRL only" case give the respond= er any basis to say
> whether a given serial number belongs to a currently valid certificate, an
> expired certificate which was never revoked, or neither.  A full database
> of certificates which have ever been issued with a given issuer name > should allow the responder to classify any given certificate serial number
> for that issuer as "revoked" (including suspended), "va= lid", "expired",
> "not yet", or "unknown".
>        If you feel it's desirable for the responder to include which
> repository mode it's using in an extension, I personally see no reason to
> object to such a proposal.  Including the repository mode is not necessary
> for the use of these extensions, because two of the modes are inconsis= tent
> with using them.
>
> Tom Gindin
>
>
>
>
> From:   denis.pinkas@bull.net
> To:     Tom Gindin/Watson/IBM@IBMUS,
> Cc:     pkix@ietf.org
> Date:   03/12/2012 09:46 AM
> Subject:        RE: [pkix] Possible OCSP Extension= s
>
>
>
> Tom,
>
> Your email is not crystal clear (at least to me) and seems to address at
> the same time two different topics:
>
>   - an OCSP response extension containing "never issued" and
>  - an OCSP response extension containing "outside validity period".
>
> I can understand "never issued", but I don't know what you mean, in the
> context of OCSP, with "outside validity period"
>
> Your proposal seems allowing an OCSP server "to verify that a CA had
> actually been cracked and then react".
> The problem is that we cannot do this, until we first specify a way to
> return a status like "never issued".
>
> Simply adding an additional status report like "never issued" would not be
> sufficient as explained below.
>
> The problem is that OSCP was originally designed to work either :
>
> - with CRLs only, or
> - with a revocation status data base for revoked certificates only, or
> - with a revocation status data base for all issued certificates manag= ed
> directly by the CA which issued that certificate.
>
> We currently have no way to indicate either in the request or in the > response
> which of the three modes is/was requested or used.
>
> An OCSP server might only indicate "never issued", if  = it also indicates
> that it got this information using
> a revocation status data base for all issued certificates managed directly
> by the CA which has issued that certificate.
>
> This means that this extension may only be present if the OCSP respond= er
> is using  a revocation status data base
> for all issued certificates managed directly by the CA which has issue= d
> that certificate.
>
> This extension would then contain a boolean to say whether of not the
> certificate was issued.
>
> I remember that we discuss this topic on the PKIX  list but I don't
> remember any concrete proposal.
>
> Once we have such a mechanism (or a similar one), then we can build on it
> and discuss (and understand better) your proposal.
>
> Denis
>
>
>
>
> De :        Tom Gindin <tgindin@us.ibm.com><= br> > A :        pkix <pkix@ietf.org>
> Date :        10/03/2012 18:51
> Objet :        [pkix] Possible OCSP Extensions
> Envoy=E9 par :        pkix-bounces@ietf.org
>
>
>
>        Why isn't there an OCSP response extension containing "never
> issued" or "outside validity period" which a responder may use if they
> have the CA's certificate repository available?  Getting a request that
> produces such an error would not be anything which the responder would be
> expected to report.  A client who had received a response with such an
> extension could then demonstrate that an actual compromise had occurred by
>
> resending the request with a request extension containing the actual > certificate, or perhaps the chain, which had provoked that response
> extension above.  Receiving such a certificate would allow the OCSP server
>
> to verify that the CA had actually been cracked and then react.
>       I think that such a feature would be useful to responders operated
> by a CA with many subordinate CA's, and possibly to others as well.
>
> Tom Gindin
> P.S. - The above suggestion is mine, and not necessarily that of my
> employer.
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> pkix mailing list
> pkix@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/pkix
>
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> pkix mailing list
> pkix@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/pkix
>



--
Website: h= ttp://hallambaker.com/
--=_alternative 004AD31CC12579C1_=-- From hallam@gmail.com Wed Mar 14 07:08:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B638021F881D for ; Wed, 14 Mar 2012 07:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbmPelgsPOLe for ; Wed, 14 Mar 2012 07:08:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4821F8816 for ; Wed, 14 Mar 2012 07:08:06 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2120339yhp.31 for ; Wed, 14 Mar 2012 07:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q5gXfKLUr8T1ns8A/IYpkpYz8LxDLTUf9G/2mVdKy/k=; b=ibEwTKsOKTpO3m08FOWfVAdaT2DRwUvks9TIT13daimHysoiOy/AljYFjb6DVx3Vvx OnXTGDGcuUYCmbhWzQHOSJwkT0U6xrU+pGlAi3A9IxFCH8GAhNzZMqobNIZ0/9XQSOxv j0Ud5L9y8pGOtnRIhWx38m9dciP01bbswWaiRQLesUyttYMB9Du8BFIFWeaWBzKREW3/ 0AAYE09DrsJ0DA4cOB/PSnbq4L5BFdbfw/u0twT3LJa6J2ou6X2wji3MFmWC1kQWBOoZ Lvt61lt42PWVJ4D8dH8B3fANLbO5xwttCdE0mrzQXHHTEtzmNzUw11lKPfgCV/gyws9R HJYA== MIME-Version: 1.0 Received: by 10.60.22.70 with SMTP id b6mr3526466oef.5.1331734082147; Wed, 14 Mar 2012 07:08:02 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Wed, 14 Mar 2012 07:08:02 -0700 (PDT) In-Reply-To: <4F6058D2.1000502@primekey.se> References: <4F5F0148.4020702@primekey.se> <4F6058D2.1000502@primekey.se> Date: Wed, 14 Mar 2012 10:08:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Tomas Gustavsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 14:08:23 -0000 No, it is one OCSP response that would sign a statement 'no cert exists for serial number X through Y inclusive', not ten billion signed responses. On Wed, Mar 14, 2012 at 4:37 AM, Tomas Gustavsson wrote= : > > My problem lies in: > > >> Create OCSP non-existence responses for >> =A0 =A0 =A0C[0].serial+1 -> =A0C[1].serial-1 > > Since it says "responses". The gap "C[0].serial+1 -> =A0C[1].serial-1" mi= ght > very well be 10 billion serials, making that completely infeasible with > modern hardware. > > From a scalability point of view the use case with 100 issued certificate= s > is not very interesting. The solutions should work with 100 million > certificates, and an issuance frequency of 100 certificates per second, o= r > something like that. > > Or are you targeting a corner case with a relatively static CA that does = not > do much? > > Cheers, > Tomas > > > On 03/14/2012 02:36 AM, Phillip Hallam-Baker wrote: >> >> So to work out the gaps: >> >> Take the set of issued certs C_set >> Sort by serial number to produce a list C_list [0..99] >> >> Create OCSP status responses for >> =A0 =A0C[0].serial >> =A0 =A0C[1].serial >> =A0 =A0... >> =A0 =A0C[99].serial >> >> Create OCSP non-existence responses for >> =A0 =A0 C[0].serial+1 -> =A0C[1].serial-1 >> =A0 =A0 C[1].serial+1 -> =A0C[2].serial-1 >> =A0 =A0 ... >> =A0 =A0 C[98].serial+1 -> =A0C[99].serial-1 >> =A0 =A0 C[99].serial+1 -> =A0C[0].serial-1 >> >> Does that answer the question? >> >> On Tue, Mar 13, 2012 at 4:11 AM, Tomas Gustavsson >> =A0wrote: >>> >>> >>> >>> On 03/12/2012 02:29 PM, Phillip Hallam-Baker wrote: >>>> >>>> Actually, the idea for the serial numbers was not that they would >>>> necessarily be monotonic, rather the idea is just to sign the gaps. If >>>> the CA signs non-monotonic serial numbers then they would have to sort >>>> them into order first. >>>> >>>> So the way a CA would work is that every OCSP signing increment, say 1 >>>> hour, they would create OCSP responses for >>>> >>>> 1) Every known cert issued >>>> 2) The gaps between the serial numbers. >>>> >>>> So with 100 certs issued, this would be 200 OCSP responses. >>> >>> >>> This is not clear to me? If we, for example, use random 64 bit serial >>> numbers (which is good for several reasons). After 100 issued >>> certificates I would not for any practical reasons be able to calculate >>> any "gaps". >>> >>> "Gaps" for certificate serial number seems to me to be a non existing >>> thing. >>> >>> Cheers, >>> Tomas >>> >>>> >>>> >>>> If a cert is issued within that time interval, the CA creates three >>>> additional OCSP responses, one for the new cert and two for the new >>>> serial number intervals that have just been created. >>>> >>>> This approach allows CAs to avoid creating additional timing errors >>>> but is still robust if they are introduced by others. >>>> >>>> >>>> On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin =A0wr= ote: >>>>> >>>>> =A0 =A0 =A0 =A0Piyush: >>>>> >>>>> =A0 =A0 =A0 =A0One purpose of this is to identify cases where the iss= uer has >>>>> apparently been compromised, and the major purpose of the request >>>>> extension (call it "requested certificate body" or "requested >>>>> certificate >>>>> chain") is to allow such a case to be substantiated. =A0Once the requ= est >>>>> is >>>>> substantiated, I would expect the issuer key to be treated as >>>>> compromised >>>>> unless the submitted certificate is a digest duplicate against an >>>>> actual >>>>> issued certificate. =A0That would be an algorithmic issue rather than= a >>>>> key >>>>> compromise. >>>>> =A0 =A0 =A0 =A0I'd like to adapt part of Phill's suggestion, and rede= fine the >>>>> proposed "never issued" status as "Not issued before" and a time. =A0= The >>>>> presigned variant, which might be called "no serial number within >>>>> range", >>>>> seems right for issuers with increasing serial numbers but makes less >>>>> sense for issuers who assign serial numbers which don't monotonically >>>>> increase with time. =A0Phill, is that supposed to be the closed inter= val >>>>> (with the two endpoint serial numbers not issued) or the open one (wi= th >>>>> the two endpoint serial numbers issued)? =A0Also, is there an option = in >>>>> which the upper bound is not specified which means "no serial number >>>>> above >>>>> L had been issued as of time T"? >>>>> >>>>> >>>>> Tom Gindin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: =A0 Piyush Jain >>>>> To: =A0 =A0 Tom Gindin/Watson/IBM@IBMUS, "'pkix'", >>>>> Date: =A0 03/11/2012 01:17 PM >>>>> Subject: =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions >>>>> >>>>> >>>>> >>>>> Is this trying to address the case where CA continues to operate afte= r >>>>> it >>>>> has been compromised? >>>>> I'm assuming that in this case EE certificates have been signed using >>>>> the >>>>> CA >>>>> key and somehow deleted from the CA's issued certificates repository. >>>>> What happens if the attacker issued an OCSP signing certificate (with >>>>> OCSP-no-check) as opposed to an EE certificate? >>>>> >>>>> Many of us would believe that only way to address this breach is to >>>>> revoke >>>>> the CA. >>>>> >>>>> There could be limited use of this extension for the CA to determine = if >>>>> it >>>>> has been compromised. >>>>> >>>>> -Piyush >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>>>>> Of >>>>>> Tom Gindin >>>>>> Sent: Saturday, March 10, 2012 9:50 AM >>>>>> To: pkix >>>>>> Subject: [pkix] Possible OCSP Extensions >>>>>> >>>>>> =A0 =A0 =A0 =A0 Why isn't there an OCSP response extension containin= g "never >>>>> >>>>> issued" or >>>>>> >>>>>> "outside validity period" which a responder may use if they have the >>>>> >>>>> CA's >>>>>> >>>>>> certificate repository available? =A0Getting a request that produces >>>>>> such >>>>> >>>>> an >>>>>> >>>>>> error would not be anything which the responder would be expected to >>>>>> report. =A0A client who had received a response with such an extensi= on >>>>> >>>>> could >>>>>> >>>>>> then demonstrate that an actual compromise had occurred by resending >>>>>> the >>>>>> request with a request extension containing the actual certificate, = or >>>>> >>>>> perhaps >>>>>> >>>>>> the chain, which had provoked that response extension above. >>>>>> =A0Receiving >>>>>> such a certificate would allow the OCSP server to verify that the CA >>>>>> had >>>>>> actually been cracked and then react. >>>>>> =A0 =A0 =A0 =A0 I think that such a feature would be useful to respo= nders >>>>> >>>>> operated >>>>> by a >>>>>> >>>>>> CA with many subordinate CA's, and possibly to others as well. >>>>>> >>>>>> Tom Gindin >>>>>> P.S. - The above suggestion is mine, and not necessarily that of my >>>>> >>>>> employer. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Mar 14 07:24:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63A21F881C for ; Wed, 14 Mar 2012 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03Kcrv8DZE+Q for ; Wed, 14 Mar 2012 07:24:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4474B21F8813 for ; Wed, 14 Mar 2012 07:24:21 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2136268ghb.31 for ; Wed, 14 Mar 2012 07:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/MwU9UqVs8qhhgJFQ5wQylhIbxteb1flqs5dCCf3Cgw=; b=b5njRYvJ5ZeJoC/t4sX2IxcY/sy4buIMKjZTyLdJMF4U+YxHwK419rC6yQplkj4MLU MccIgQY6ftsGzpwpmgv9tBYga+KlYudert8BnPtWg0i1ENp0ZiNpyOEyhlEok5ubZ5Nb F9ZhSiAC5WcYVZm1o1JQFHDqkHnXhSWukk1oARfNctMZCgtutk6tV01NBgfdxFOGK3+0 HMtFQnvObSaLeyoIZmFddUfJcF8n9qYgtO/dtmccfzpTNnpGMLQ8BMHgyKvxpZr3iOHX kxnbNuoLPgBcSA/QMugHXexm7K1dv7ZGvpDmer0NcBX0R2OMPQyIyzrtD7D2/+Py/5S+ NrSQ== MIME-Version: 1.0 Received: by 10.182.155.97 with SMTP id vv1mr3705030obb.5.1331735057577; Wed, 14 Mar 2012 07:24:17 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Wed, 14 Mar 2012 07:24:17 -0700 (PDT) In-Reply-To: References: <4F5F0148.4020702@primekey.se> Date: Wed, 14 Mar 2012 10:24:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Erwann Abalea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tomas Gustavsson , pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 14:24:22 -0000 On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea wrote: > Bonjour, > > 2012/3/14 Phillip Hallam-Baker >> >> So to work out the gaps: >> >> Take the set of issued certs C_set >> Sort by serial number to produce a list C_list [0..99] >> >> Create OCSP status responses for >> =A0 C[0].serial >> =A0 C[1].serial >> =A0 ... >> =A0 C[99].serial >> >> Create OCSP non-existence responses for >> =A0 =A0C[0].serial+1 -> C[1].serial-1 >> =A0 =A0C[1].serial+1 -> C[2].serial-1 >> =A0 =A0... >> =A0 =A0C[98].serial+1 -> C[99].serial-1 >> =A0 =A0C[99].serial+1 -> C[0].serial-1 > > > That last "link" has no sense. You need to create an OCSP response from -= Inf > to C[0].serial-1, and another one from C[99].serial+1 to +Inf. As I said in a previous message, this is following the DNS NSEC practice of having the last interval wrap and if the start of the interval is greater than the end it is equivalent to the two intervals you give. I am not wedded to that approach, its just that sticking to the DNSSEC approach gives maximum anti-troll protection on the patent front. > Precisely, for n certificates, you need 2n+1 OCSP responses. Short-lived > ones, preferably (1 day, maybe?). > > Now expand the example to larger numbers. Imagine a deployed PKI for 300 > million certificates, renewed every few years (this is not a purely > hypothetical example). > CRL based validation is not an option (well, it may work for signatures, = but > not authentication). OCSP is a good tool, as an OCSP response need only b= e > produced when asked. True, and this can be a configuration option. The pre-signed approach definitely makes sense for SSL where the number of certs is low compared to the number of lookups and you very much want to airgap the OCSP signature capability from the Internet which is not possible if there is an on-demand signature creation capability. It would not make sense for S/MIME where the number of lookups per cert is very low, probably less than one a day. The pre-signed issue is not that it be a requirement for operations, people can operate their OCSP any way they like. But OCSP is already deployed in a pre-signed configuration at many CAs and any new proposal has to support that approach. > Using the proposed scheme would require the CA to sign 600 million OCSP > tokens every day. That's 7000 signatures per second, 7000 OCSP responses > produced and stored somewhere per second, every single second, even if th= e > OCSP response is not used. OCSP becomes now a non option. If I could sell 300 million SSL certs I am sure that Melih would be only too delighted to write a check for the necessary signing units. The crypto hardware used in CA infrastructure is capable of cloning keys into other devices under strictly controlled circumstances. So increasing the OCSP signature capability would mean simply buying and racking more units. Adding in the gaps only doubles the number of signatures required and hardware improves much faster than anyone's sales numbers climb. Signing the gaps was a big issue in DNSSEC because adding DNSSEC was an unfunded mandate. Signing every DNS name in .com was a huge deal and would have had a massive operational impact. If people had taken seriously the statements I made in 2001 then DNSSEC would have been deployed for ten years already. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Mar 14 07:25:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08221E8073 for ; Wed, 14 Mar 2012 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+Qn+Nn2aW1h for ; Wed, 14 Mar 2012 07:25:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 847F721E8075 for ; Wed, 14 Mar 2012 07:25:43 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2140540ggm.31 for ; Wed, 14 Mar 2012 07:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yMUhwlB4cxYy7pesT4Ocnl2BIpBKZ/mpTTaJb73C/zk=; b=043FAM1lOudNnd64QTtLs2toNETB62P43IcBztxBJzxFYM4jXKlyTylfUc9z+jy1yO R8PujUzizvu8/vGOirIJblq/HpboOJ0HyF6XNl/BW5O6nlGxk8kcRpmP50BBON7CSgrt a6sWkWHsR3knYOzKlhuxVXRRJbqE3Z0Oztr9GXWyqdahIP4YikSUDVDbcjKJF3OAysCf XKGLuNqC/5uZztuDAbK4wiMzCpC/FPjy/BZkL/mkKlhU+skD5/+13aTzF97zbJg2aTJ/ 6Y2H2/+LuUep+JXeuSAzxfFIsYuWO0chNnyhdoa7w2NJ/B+bHwt6+6KpnAMHZ1S/FOjU p8gQ== MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr3619508obc.35.1331735138161; Wed, 14 Mar 2012 07:25:38 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Wed, 14 Mar 2012 07:25:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 10:25:38 -0400 Message-ID: From: Phillip Hallam-Baker To: denis.pinkas@bull.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 14:25:46 -0000 When I see a broken protocol I try to fix it. What do you do? On Wed, Mar 14, 2012 at 9:37 AM, wrote: > Phil, > > You claim that OCSP was originally designed to report archival status at = a > specific point in time. > The fact is that OCSP is currently unable to report archival status at a > specific point in time. > > OCSP reports the revocation status : > > a) if the certificate is not expired, at the current time (or close to th= e > current time when cached responses are supported), > b) if both the certificate is expired and the archive cutoff extension is > supported, as it was at the end of the certificate's validity period. > > Denis > > > > De : =A0 =A0 =A0 =A0Phillip Hallam-Baker > A : =A0 =A0 =A0 =A0denis.pinkas@bull.net > Cc=A0: =A0 =A0 =A0 =A0Tom Gindin , pkix@ietf.org > Date : =A0 =A0 =A0 =A014/03/2012 02:30 > Objet : =A0 =A0 =A0 =A0Re: [pkix] Possible OCSP Extensions > ________________________________ > > > > No, that is untrue, OCSP was originally designed to report archival > status at a specific point in time. > > People can pull out the good stuff out of the specs if they like but > they don't get to say that it was never the intention to do it. > > On Tue, Mar 13, 2012 at 3:49 AM, =A0 wrote: >> Tom, >> >> One of your arguments is to say that the proposal "can't distinguish nev= er >> issued from outside validity period >> if expired certificates are purged from the repository". The question is >> whether this is really necessary. >> The answer is that it is not necessary, as explained below. >> >> A key point is that OSCP has only been designed to provide the revocatio= n >> status of a certificate at the current time. >> >> It should be the responsibility of the OCSP client, before making the OC= SP >> request, to test that the current time >> is within the validity period of the certificate. Thus if a certificate >> serial number refers to a certificate that has expired, >> the OCSP response is not meaningful. >> >> However, if the proposal is included, explanations should clearly indica= te >> that the additional status is only meaningful >> if the client has locally tested that the the current time is within the >> validity period of the certificate. >> >> Denis >> >> >> >> >> De : =A0 =A0 =A0 =A0Tom Gindin >> A : =A0 =A0 =A0 =A0denis.pinkas@bull.net >> Cc=A0: =A0 =A0 =A0 =A0pkix@ietf.org >> Date : =A0 =A0 =A0 =A012/03/2012 15:21 >> Objet : =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions >> ________________________________ >> >> >> >> =A0 =A0 =A0 =A0 Denis: >> >> =A0 =A0 =A0 =A0"Outside validity period" means, in most cases, that the = serial >> number requested was indeed issued by the CA but is now expired. =A0It c= ould >> also mean that the "NotBefore" time is still in the future, but that wou= ld >> be much rarer. =A0It would be feasible to distinguish Expired from Not Y= et >> Valid in the response extension, of course. >> =A0 =A0 =A0 =A0Naturally, an OCSP responder must have access to a reposi= tory >> containing those certificates which are currently valid for a given issu= er >> to determine any of these statuses. =A0That's your third case, but you c= an't >> distinguish never issued from outside validity period if expired >> certificates are purged from the repository. =A0Neither the "revocation >> database" case nor the "CRL only" case give the responder any basis to s= ay >> whether a given serial number belongs to a currently valid certificate, = an >> expired certificate which was never revoked, or neither. =A0A full datab= ase >> of certificates which have ever been issued with a given issuer name >> should allow the responder to classify any given certificate serial numb= er >> for that issuer as "revoked" (including suspended), "valid", "expired", >> "not yet", or "unknown". >> =A0 =A0 =A0 =A0If you feel it's desirable for the responder to include w= hich >> repository mode it's using in an extension, I personally see no reason t= o >> object to such a proposal. =A0Including the repository mode is not neces= sary >> for the use of these extensions, because two of the modes are inconsiste= nt >> with using them. >> >> Tom Gindin >> >> >> >> >> From: =A0 denis.pinkas@bull.net >> To: =A0 =A0 Tom Gindin/Watson/IBM@IBMUS, >> Cc: =A0 =A0 pkix@ietf.org >> Date: =A0 03/12/2012 09:46 AM >> Subject: =A0 =A0 =A0 =A0RE: [pkix] Possible OCSP Extensions >> >> >> >> Tom, >> >> Your email is not crystal clear (at least to me) and seems to address at >> the same time two different topics: >> >> =A0 - an OCSP response extension containing "never issued" and >> =A0- an OCSP response extension containing "outside validity period". >> >> I can understand "never issued", but I don't know what you mean, in the >> context of OCSP, with "outside validity period" >> >> Your proposal seems allowing an OCSP server "to verify that a CA had >> actually been cracked and then react". >> The problem is that we cannot do this, until we first specify a way to >> return a status like "never issued". >> >> Simply adding an additional status report like "never issued" would not = be >> sufficient as explained below. >> >> The problem is that OSCP was originally designed to work either : >> >> - with CRLs only, or >> - with a revocation status data base for revoked certificates only, or >> - with a revocation status data base for all issued certificates managed >> directly by the CA which issued that certificate. >> >> We currently have no way to indicate either in the request or in the >> response >> which of the three modes is/was requested or used. >> >> An OCSP server might only indicate "never issued", if =A0it also indicat= es >> that it got this information using >> a revocation status data base for all issued certificates managed direct= ly >> by the CA which has issued that certificate. >> >> This means that this extension may only be present if the OCSP responder >> is using =A0a revocation status data base >> for all issued certificates managed directly by the CA which has issued >> that certificate. >> >> This extension would then contain a boolean to say whether of not the >> certificate was issued. >> >> I remember that we discuss this topic on the PKIX =A0list but I don't >> remember any concrete proposal. >> >> Once we have such a mechanism (or a similar one), then we can build on i= t >> and discuss (and understand better) your proposal. >> >> Denis >> >> >> >> >> De : =A0 =A0 =A0 =A0Tom Gindin >> A : =A0 =A0 =A0 =A0pkix >> Date : =A0 =A0 =A0 =A010/03/2012 18:51 >> Objet : =A0 =A0 =A0 =A0[pkix] Possible OCSP Extensions >> Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org >> >> >> >> =A0 =A0 =A0 =A0Why isn't there an OCSP response extension containing "ne= ver >> issued" or "outside validity period" which a responder may use if they >> have the CA's certificate repository available? =A0Getting a request tha= t >> produces such an error would not be anything which the responder would b= e >> expected to report. =A0A client who had received a response with such an >> extension could then demonstrate that an actual compromise had occurred = by >> >> resending the request with a request extension containing the actual >> certificate, or perhaps the chain, which had provoked that response >> extension above. =A0Receiving such a certificate would allow the OCSP se= rver >> >> to verify that the CA had actually been cracked and then react. >> =A0 =A0 =A0 I think that such a feature would be useful to responders op= erated >> by a CA with many subordinate CA's, and possibly to others as well. >> >> Tom Gindin >> P.S. - The above suggestion is mine, and not necessarily that of my >> employer. >> >> _______________________________________________ >> 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 >> > > > > -- > Website: http://hallambaker.com/ > --=20 Website: http://hallambaker.com/ From kent@bbn.com Wed Mar 14 07:59:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87DB21F87A1 for ; Wed, 14 Mar 2012 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkAE32rCP8YV for ; Wed, 14 Mar 2012 07:59:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2728021F879F for ; Wed, 14 Mar 2012 07:59:32 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49164) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7pfd-0003sy-7z; Wed, 14 Mar 2012 10:59:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2012 10:48:35 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 14:59:32 -0000 At 6:53 PM -0700 3/12/12, Henry B. Hotz wrote: >Seems to me that it ought to be possible for OCSP to provide >complete information about the possibly-knowable status of a >certificate. If the OCSP server has complete current and historical >information about what certs a CA has issued, then it should be >possible say if the cert is good, bad, or doesn't (shouldn't) exist. Henry, yes, but that has not been the model underlying OCSP response generation in many contexts. Although I was not an author of OCSP, I have always viewed it as a alternative to CRLs, and I think this model is accurate. CRLs convey info on whether a cert has been revoked, not whether it is expired, not issued, etc. Consistent with this model, an OCSP server can generate responses using only a CRL for the CA in question. In that light, adding additional info about cert status is not consistent with basic OCSP functionality. PKIX developed SCVP to provide more comprehensive cert status info (within a validation context). The WG rejected (narrowly) the idea of making changes to extend OCSP to convey this additional info. So, any proposals for extending OCSP functionality need to be justified relative to the model that has underpinned OCSP, the existence of SCVP, and any changes in the environment that might motivate new OCSP functionality. I agree with PHB's observation that the public CA (TTP) landscape has changed dramatically in the recent past. If there is a credible rationale for extending OCSP because of this change, then fine. However, proposals to extend OCSP to provide additional status info, more like what SCVP offers, are not likely to be viable. OCSP is a "brand" but that does not make it a good choice to solve additional problems that will entail substantiative protocol changes. Steve From mmyers@fastq.com Wed Mar 14 08:15:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1321F87EB for ; Wed, 14 Mar 2012 08:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NZsvB7AidPS for ; Wed, 14 Mar 2012 08:15:06 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 723BB21F87E8 for ; Wed, 14 Mar 2012 08:15:06 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2EFEgcs013948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 08:14:49 -0700 Message-Id: <09F3F082-8370-4015-9E3F-CF9DF54B6D9B@fastq.com> From: Michael Myers To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Mar 2012 08:20:06 -0700 References: X-Mailer: Apple Mail (2.936) Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 15:15:07 -0000 On Mar 14, 2012, at 7:48 AM, Stephen Kent wrote: > an OCSP server can generate responses using only a CRL for the CA in > question. Steve, For the record, what I had in mind back then was authoritative access to the data necessary to the production of a CRL. With CRLs being periodic, the freshest data remained unaccessible. But lacking such access, *then* the CRL. That's where Ambarish and I got into it. And Carlisle too, as I recall. Mike From kent@bbn.com Wed Mar 14 08:39:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90621F863F for ; Wed, 14 Mar 2012 08:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah-7FG9irCw5 for ; Wed, 14 Mar 2012 08:39:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC2121F85A0 for ; Wed, 14 Mar 2012 08:39:47 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49171) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7qIY-0005GV-16; Wed, 14 Mar 2012 11:39:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <09F3F082-8370-4015-9E3F-CF9DF54B6D9B@fastq.com> References: <09F3F082-8370-4015-9E3F-CF9DF54B6D9B@fastq.com> Date: Wed, 14 Mar 2012 11:39:34 -0400 To: Michael Myers From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 15:39:48 -0000 At 8:20 AM -0700 3/14/12, Michael Myers wrote: >On Mar 14, 2012, at 7:48 AM, Stephen Kent wrote: > >>an OCSP server can generate responses using only a CRL for the CA >>in question. > >Steve, > >For the record, what I had in mind back then was authoritative >access to the data necessary to the production of a CRL. With CRLs >being periodic, the freshest data remained unaccessible. But >lacking such access, *then* the CRL. That's where Ambarish and I >got into it. And Carlisle too, as I recall. > >Mike Mike, Thanks for the historical background. I'd suggest that the data needed to produce a CRL is not much different from the CRL itself, in this context, except wrt timeliness. I also observe that RFC 2560 begins with the statement: "This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs." That statement suggests that OCSP responses are to be viewed as an alternative to CRLs (although the term "status" is overly broad here). The protocol overview in Section 2 refines this notion by stating: "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." This text suggests that OCSP response processing can be either a substitute for CRL checking, or that these responses offer a more up to date source of revocation status data. The latter interpretation is consistent with the notion of issuing OCPS responses based on the data used to generate CRLs, perhaps before the next CRL is issued. None of this text suggests that OCSP is a way to determine if a cert has been issued, one of the features being discussed now. Steve From eabalea@gmail.com Wed Mar 14 09:02:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2155821E806D for ; Wed, 14 Mar 2012 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO7CW6erJL5j for ; Wed, 14 Mar 2012 09:02:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59BAA21E8054 for ; Wed, 14 Mar 2012 09:02:27 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2259853ggm.31 for ; Wed, 14 Mar 2012 09:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n9d1g3D/PiY9428aed/MkHXYDjoVCFJufZIeBRzEOtw=; b=AsC6xjJoLrXUjBgiqt5HiCjj27hvsuKht9o8Kb9K/bjQNwyLKy4nqJCOKPn1g+H6q/ gjtVsc5kvGICPJMteq0IWhPjTnkse9m4sQ1bqVMR2kOxQwI7mDeszOxnAX356q5Hg5Zy TOwdqeEvCBTuB7g8ijdFCYyBvbstrUhgUOXBFpDA9epIHiWITa9b1LnO7gdfRrDvpahc y92shGnAMB+BBf44smhtBFp1nezrfj+0pO7QjCievbVTrpMVmI5IpIIYmxok/WmaCvMq BausRry5519/NX6lgAH4RZcCRw9dIy1xoKwrWWlbgS5FEyyxDsdR0BgusuQN3uRf2Ebk Rkrg== MIME-Version: 1.0 Received: by 10.236.161.72 with SMTP id v48mr3540697yhk.112.1331740946852; Wed, 14 Mar 2012 09:02:26 -0700 (PDT) Received: by 10.236.207.2 with HTTP; Wed, 14 Mar 2012 09:02:26 -0700 (PDT) In-Reply-To: References: <4F5F0148.4020702@primekey.se> Date: Wed, 14 Mar 2012 17:02:26 +0100 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf302ef83e11ecd704bb361a17 Cc: Tomas Gustavsson , pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 16:02:28 -0000 --20cf302ef83e11ecd704bb361a17 Content-Type: text/plain; charset=UTF-8 2012/3/14 Phillip Hallam-Baker > On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea wrote: > > > > 2012/3/14 Phillip Hallam-Baker > [...] > >> C[99].serial+1 -> C[0].serial-1 > > > > > > That last "link" has no sense. You need to create an OCSP response from > -Inf > > to C[0].serial-1, and another one from C[99].serial+1 to +Inf. > > As I said in a previous message, this is following the DNS NSEC > practice of having the last interval wrap and if the start of the > interval is greater than the end it is equivalent to the two intervals > you give. > I get it, now. [...] >> Using the proposed scheme would require the CA to sign 600 million OCSP >> tokens every day. That's 7000 signatures per second, 7000 OCSP responses >> produced and stored somewhere per second, every single second, even if the >> OCSP response is not used. OCSP becomes now a non option. If I could sell 300 million SSL certs I am sure that Melih would be > only too delighted to write a check for the necessary signing units. > > The crypto hardware used in CA infrastructure is capable of cloning > keys into other devices under strictly controlled circumstances. So > increasing the OCSP signature capability would mean simply buying and > racking more units. > The example I had in mind is not an hypothetical one. And adding crypto hardware every year is not an option. But I read the thread again and noticed that your proposal doesn't need to impose pre-signing OCSP responses. A "negative gap" OCSP response can be generated and returned when asked for a non existent serial number. Sorry, going back to my cave ;) -- Erwann. --20cf302ef83e11ecd704bb361a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/3/14 Phillip Hallam-Baker <hallam@gmail.com>
On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea <eabalea@gmail.com> wrote:
>
> 2012/3/14 Phillip Hallam-Baker <hallam@gmail.com>
[...]
>> =C2=A0 =C2=A0C[99].serial+1 -> C[0].serial-1
>
>
> That last "link" has no sense. You need to create an OCSP re= sponse from -Inf
> to C[0].serial-1, and another one from C[99].serial+1 to +Inf.

As I said in a previous message, this is following the DNS NSEC
practice of having the last interval wrap and if the start of the
interval is greater than the end it is equivalent to the two intervals
you give.

I get it, now.

[...]

>> Using the proposed scheme would require the CA to sign 600 million= OCSP
>> tokens every day. That's 7000 signatures per second, 7000 OCSP= responses
>> produced and stored somewhere per second, every single second, eve= n if the
>> OCSP response is not used. OCSP becomes now a non option.

If I could sell 300 million SSL certs I am sure that Melih would be
only too delighted to write a check for the necessary signing units.

The crypto hardware used in CA infrastructure is capable of cloning
keys into other devices under strictly controlled circumstances. So
increasing the OCSP signature capability would mean simply buying and
racking more units.

The example I had in mind is = not an hypothetical one. And adding crypto hardware every year is not an op= tion.

But I read the thread again and noticed that your proposal doe= sn't need to impose pre-signing OCSP responses. A "negative gap&qu= ot; OCSP response can be generated and returned when asked for a non existe= nt serial number.

Sorry, going back to my cave ;)

--
Erwann.
--20cf302ef83e11ecd704bb361a17-- From hallam@gmail.com Wed Mar 14 11:13:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30B221E8054 for ; Wed, 14 Mar 2012 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS1Gmbhcp30M for ; Wed, 14 Mar 2012 11:13:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73E21E8034 for ; Wed, 14 Mar 2012 11:13:21 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2418605yhp.31 for ; Wed, 14 Mar 2012 11:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7iYKghk28PNzc+rGG9lO0FgpW63oaC1G6qM4EYZyPug=; b=kmYae3OF29pTnIedEEUhf5TzkIfveC/EzFoKUMFQNk2qpslgecEHGXNhSuuMSba05q XproatmDNOzc5c9dzjhDVzND9kOZ+yQOaHCEDmOcLyiNPQsBx18zag8IfjT5IzLqj8Pv VT0Fy4fK6dKMqPTTRuwVwDqL9oGgP9lcYcLRV4k4BdRX5VpF8AmMDie4fEtvyRF3QC14 zBFNrLqB+ha05mK5zPV4uyJ/sTpIz4GAnSn+sSvqfRDGbh/j4KWWwYX7hcCv66UMwDNi fsrVUobydFTsVzBRYPvCkIaHFkPHlBf0IbrGND6xoTWcTf9pKvRr9i3FA90QOFq9XSAe 7r3A== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr4695704obc.15.1331748801395; Wed, 14 Mar 2012 11:13:21 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Wed, 14 Mar 2012 11:13:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 14:13:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 18:13:23 -0000 Does anyone use SCVP? If there is going to be a choice between maintaining OCSP and maintaining SCVP then OCSP is going to be the one that I choose. Could we have a discussion on this at the next meeting? As I see it, it PKIX is not going to maintain OCSP then it is time to fork the spec and maintain it elsewhere. I do not think that anyone can claim that SCVP is sufficiently deployed to abandon OCSP in its favor. On Wed, Mar 14, 2012 at 10:48 AM, Stephen Kent wrote: > At 6:53 PM -0700 3/12/12, Henry B. Hotz wrote: >> >> Seems to me that it ought to be possible for OCSP to provide complete >> information about the possibly-knowable status of a certificate. =A0If t= he >> OCSP server has complete current and historical information about what c= erts >> a CA has issued, then it should be possible say if the cert is good, bad= , or >> doesn't (shouldn't) exist. > > > Henry, > > yes, but that has not been the model underlying OCSP response generation > in many contexts. > > Although I was not an author of OCSP, I have always viewed it as a > alternative to CRLs, and I think this model is accurate. CRLs convey info= on > whether a cert has been revoked, not whether it is expired, not issued, e= tc. > Consistent with this model, an OCSP server can generate responses using o= nly > a CRL for the CA in question. > > In that light, adding additional info about cert status is not consistent > with basic OCSP functionality. PKIX developed SCVP to provide more > comprehensive cert status info (within a validation context). The WG > rejected (narrowly) the idea of making changes to extend OCSP to convey t= his > additional info. > > So, any proposals for extending OCSP functionality need to be justified > relative to the model that has underpinned OCSP, the existence of SCVP, a= nd > any changes in the environment that might motivate new OCSP functionality= . > > I agree with PHB's observation that the public CA (TTP) landscape has > changed > dramatically in the recent past. If there is a credible rationale for > extending OCSP because of this change, then fine. However, proposals to > extend OCSP to > provide additional status info, more like what SCVP offers, are not likel= y > to be viable. OCSP is a "brand" but that does not make it a good choice t= o > solve additional problems that will entail substantiative protocol change= s. > > Steve > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From piyush@identicate.com Wed Mar 14 13:35:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B480121F87EC for ; Wed, 14 Mar 2012 13:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k9kPb6XBwHc for ; Wed, 14 Mar 2012 13:35:45 -0700 (PDT) Received: from col0-omc4-s17.col0.hotmail.com (col0-omc4-s17.col0.hotmail.com [65.55.34.219]) by ietfa.amsl.com (Postfix) with ESMTP id A92EF21F87EA for ; Wed, 14 Mar 2012 13:35:45 -0700 (PDT) Received: from COL119-W3 ([65.55.34.201]) by col0-omc4-s17.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 13:35:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7478f6a9-f101-473c-b6f6-4fab2a08b9e8_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Wed, 14 Mar 2012 13:35:45 -0700 Importance: Normal In-Reply-To: References: , , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 20:35:45.0557 (UTC) FILETIME=[08556450:01CD0222] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 20:35:46 -0000 --_7478f6a9-f101-473c-b6f6-4fab2a08b9e8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Wed=2C 14 Mar 2012 14:13:21 -0400 > From: hallam@gmail.com > To: kent@bbn.com > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 > Does anyone use SCVP? A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No pub= lic CAs use it. >=20 > If there is going to be a choice between maintaining OCSP and > maintaining SCVP then OCSP is going to be the one that I choose. Does not have to be a choice. Use OCSP for revocation status check=2C use S= CVP to completely offload certificate processing. >=20 > Could we have a discussion on this at the next meeting? As I see it=2C > it PKIX is not going to maintain OCSP then it is time to fork the spec > and maintain it elsewhere. >=20 >=20 > I do not think that anyone can claim that SCVP is sufficiently > deployed to abandon OCSP in its favor. No need to abandon OCSP. Both can co-exist peacefully :). However=2C compar= ing number of deployments seems unfair given that SCVP became an RFC almost= 10 years after OCSP. >=20 >=20 > On Wed=2C Mar 14=2C 2012 at 10:48 AM=2C Stephen Kent wrote= : > > At 6:53 PM -0700 3/12/12=2C Henry B. Hotz wrote: > >> > >> Seems to me that it ought to be possible for OCSP to provide complete > >> information about the possibly-knowable status of a certificate. If t= he > >> OCSP server has complete current and historical information about what= certs > >> a CA has issued=2C then it should be possible say if the cert is good= =2C bad=2C or > >> doesn't (shouldn't) exist. > > > > > > Henry=2C > > > > yes=2C but that has not been the model underlying OCSP response generat= ion > > in many contexts. > > > > Although I was not an author of OCSP=2C I have always viewed it as a > > alternative to CRLs=2C and I think this model is accurate. CRLs convey = info on > > whether a cert has been revoked=2C not whether it is expired=2C not iss= ued=2C etc. > > Consistent with this model=2C an OCSP server can generate responses usi= ng only > > a CRL for the CA in question. > > > > In that light=2C adding additional info about cert status is not consis= tent > > with basic OCSP functionality. PKIX developed SCVP to provide more > > comprehensive cert status info (within a validation context). The WG > > rejected (narrowly) the idea of making changes to extend OCSP to convey= this > > additional info. > > > > So=2C any proposals for extending OCSP functionality need to be justifi= ed > > relative to the model that has underpinned OCSP=2C the existence of SCV= P=2C and > > any changes in the environment that might motivate new OCSP functionali= ty. > > > > I agree with PHB's observation that the public CA (TTP) landscape has > > changed > > dramatically in the recent past. If there is a credible rationale for > > extending OCSP because of this change=2C then fine. However=2C proposal= s to > > extend OCSP to > > provide additional status info=2C more like what SCVP offers=2C are not= likely > > to be viable. OCSP is a "brand" but that does not make it a good choice= to > > solve additional problems that will entail substantiative protocol chan= ges. > > > > Steve > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_7478f6a9-f101-473c-b6f6-4fab2a08b9e8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Wed=2C 14 M= ar 2012 14:13:21 -0400
>=3B From: hallam@gmail.com
>=3B To: kent@= bbn.com
>=3B CC: pkix@ietf.org
>=3B Subject: Re: [pkix] Possible = OCSP Extensions
>=3B
>=3B Does anyone use SCVP?

A bunch of Govt. Agencies in the U.S. Mostly enterprise deployment= s. No public CAs use it.

>=3B
>=3B If there is go= ing to be a choice between maintaining OCSP and
>=3B maintaining SCVP = then OCSP is going to be the one that I choose.

Do= es not have to be a choice. Use OCSP for revocation status check=2C use SCV= P to completely offload certificate =3Bprocessing.

=

>=3B
>=3B Could we have a discussion on this at the next m= eeting? As I see it=2C
>=3B it PKIX is not going to maintain OCSP then= it is time to fork the spec
>=3B and maintain it elsewhere.
>=3B=
>=3B
>=3B I do not think that anyone can claim that SCVP is su= fficiently
>=3B deployed to abandon OCSP in its favor.

<= /div>
No need to abandon OCSP. Both can co-exist peacefully :). =3B=
However=2C comparing number of deployments seems unfair given th= at SCVP became an RFC almost 10 years after OCSP.

= >=3B
>=3B
>=3B On Wed=2C Mar 14=2C 2012 at 10:48 AM=2C Stephe= n Kent <=3Bkent@bbn.com>=3B wrote:
>=3B >=3B At 6:53 PM -0700 3/= 12/12=2C Henry B. Hotz wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B= Seems to me that it ought to be possible for OCSP to provide complete
&= gt=3B >=3B>=3B information about the possibly-knowable status of a cert= ificate.  =3BIf the
>=3B >=3B>=3B OCSP server has complete cur= rent and historical information about what certs
>=3B >=3B>=3B a C= A has issued=2C then it should be possible say if the cert is good=2C bad= =2C or
>=3B >=3B>=3B doesn't (shouldn't) exist.
>=3B >=3B>=3B >=3B
>=3B >=3B Henry=2C
>=3B >=3B
>=3B >=3B= yes=2C but that has not been the model underlying OCSP response generation=
>=3B >=3B in many contexts.
>=3B >=3B
>=3B >=3B Altho= ugh I was not an author of OCSP=2C I have always viewed it as a
>=3B &= gt=3B alternative to CRLs=2C and I think this model is accurate. CRLs conve= y info on
>=3B >=3B whether a cert has been revoked=2C not whether i= t is expired=2C not issued=2C etc.
>=3B >=3B Consistent with this mo= del=2C an OCSP server can generate responses using only
>=3B >=3B a = CRL for the CA in question.
>=3B >=3B
>=3B >=3B In that light= =2C adding additional info about cert status is not consistent
>=3B &g= t=3B with basic OCSP functionality. PKIX developed SCVP to provide more
= >=3B >=3B comprehensive cert status info (within a validation context).= The WG
>=3B >=3B rejected (narrowly) the idea of making changes to = extend OCSP to convey this
>=3B >=3B additional info.
>=3B >= =3B
>=3B >=3B So=2C any proposals for extending OCSP functionality n= eed to be justified
>=3B >=3B relative to the model that has underpi= nned OCSP=2C the existence of SCVP=2C and
>=3B >=3B any changes in t= he environment that might motivate new OCSP functionality.
>=3B >=3B=
>=3B >=3B I agree with PHB's observation that the public CA (TTP) l= andscape has
>=3B >=3B changed
>=3B >=3B dramatically in the = recent past. If there is a credible rationale for
>=3B >=3B extendin= g OCSP because of this change=2C then fine. However=2C proposals to
>= =3B >=3B extend OCSP to
>=3B >=3B provide additional status info= =2C more like what SCVP offers=2C are not likely
>=3B >=3B to be via= ble. OCSP is a "brand" but that does not make it a good choice to
>=3B= >=3B solve additional problems that will entail substantiative protocol = changes.
>=3B >=3B
>=3B >=3B Steve
>=3B >=3B
>=3B= >=3B _______________________________________________
>=3B >=3B pk= ix mailing list
>=3B >=3B pkix@ietf.org
>=3B >=3B https://www= .ietf.org/mailman/listinfo/pkix
>=3B
>=3B
>=3B
>=3B = --
>=3B Website: http://hallambaker.com/
>=3B __________________= _____________________________
>=3B pkix mailing list
>=3B pkix@ie= tf.org
>=3B https://www.ietf.org/mailman/listinfo/pkix
=
= --_7478f6a9-f101-473c-b6f6-4fab2a08b9e8_-- From kent@bbn.com Wed Mar 14 13:51:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90EF21E8034 for ; Wed, 14 Mar 2012 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKLu6scRo34Y for ; Wed, 14 Mar 2012 13:51:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C45EC21E800C for ; Wed, 14 Mar 2012 13:51:49 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49182) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7vAY-000Eo9-HJ; Wed, 14 Mar 2012 16:51:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2012 16:47:15 -0400 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-880364189==_ma============" Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 20:51:52 -0000 --============_-880364189==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >Does anyone use SCVP? I'll let others, who know better than I, respond to this question. >If there is going to be a choice between maintaining OCSP and >maintaining SCVP then OCSP is going to be the one that I choose. If the proposal is to keep the name OCSP and add a lot of functionality that overlaps SCVP, that is not a reasonable course of action. >Could we have a discussion on this at the next meeting? As I see it, >it PKIX is not going to maintain OCSP then it is time to fork the spec >and maintain it elsewhere. "Maintan?" When you and Stefan generated RFC 6277 to try to address the alg agility problem for OCSP, that was maintenance. Changing OCSP to provide an indication of whether a cert was issued, for example, does not seem like maintenance. >I do not think that anyone can claim that SCVP is sufficiently >deployed to abandon OCSP in its favor. I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an alternative (to CRLs) for checking the revocation status of a cert. If we have good reasons to improve on that function, then doing so using OCSP makes sense. If we're looking to address security problems related to cert revocation, and which have become more serious due to browser trust model problems and due to attacks on public CAs, that also may be appropriate for OCSP. But, as I noted above and in my previous message, if the goal is to keep the OCSP name because it is widely known, and to add new functions that extend OCSP functionality and that overlap with SCVP functions, then we have a problem. Steve --============_-880364189==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] Possible OCSP Extensions
At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote:
Does anyone use SCVP?

I'll let others, who know better than I, respond to this question.

If there is going to be a choice between maintaining OCSP and
maintaining SCVP then OCSP is going to be the one that I choose.

If the proposal is to keep the name OCSP and add a lot of functionality
that overlaps SCVP, that is not a reasonable course of action.

Could we have a discussion on this at the next meeting? As I see it,
it PKIX is not going to maintain OCSP then it is time to fork the spec
and maintain it elsewhere.

"Maintan?" When you and Stefan generated RFC 6277 to try to address the alg agility problem for OCSP, that was maintenance. Changing OCSP to provide an indication of whether a cert was issued, for example, does not seem like maintenance.

I do not think that anyone can claim that SCVP is sufficiently
deployed to abandon OCSP in its favor.

I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an alternative (to CRLs) for checking the revocation status of a cert. If we have good reasons
to improve on that function, then doing so using OCSP makes sense.

If we're looking to address security problems related to cert revocation, and
which have become more serious due to browser trust model problems and due
to attacks on public CAs, that also may be appropriate for OCSP.

But, as I noted above and in my previous message, if the goal is to
keep the OCSP name because it is widely known, and to add new functions
that extend OCSP functionality and that overlap with SCVP functions, then
we have a problem.

Steve
--============_-880364189==_ma============-- From kent@bbn.com Wed Mar 14 14:05:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE121F8883 for ; Wed, 14 Mar 2012 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ay0WnlsH8FI for ; Wed, 14 Mar 2012 14:05:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5410F21F887E for ; Wed, 14 Mar 2012 14:05:49 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49183) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7vO6-000FGR-AH; Wed, 14 Mar 2012 17:05:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: , , , , , Date: Wed, 14 Mar 2012 16:55:19 -0400 To: Piyush Jain From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 14 Mar 2012 21:05:51 -0000 At 1:35 PM -0700 3/14/12, Piyush Jain wrote: > > Date: Wed, 14 Mar 2012 14:13:21 -0400 >> From: hallam@gmail.com >> To: kent@bbn.com >> CC: pkix@ietf.org >> Subject: Re: [pkix] Possible OCSP Extensions >> >> Does anyone use SCVP? > >A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. >No public CAs use it. Thanks for the reply. The services provided by SCVP are such that public CAs were not viewed as good candidates to offer SCVP services. So it doesn't make much sense to focus on SCVP use in that context Steve From kent@bbn.com Wed Mar 14 14:05:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9C921F887E for ; Wed, 14 Mar 2012 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwUkPUaQFPzs for ; Wed, 14 Mar 2012 14:05:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0221F8882 for ; Wed, 14 Mar 2012 14:05:51 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49183) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7vO8-000FGR-IJ for pkix@ietf.org; Wed, 14 Mar 2012 17:05:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 14 Mar 2012 17:05:45 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:05:52 -0000 David has published an updated version of this doc. This version includes significant new text in several sections, relative to version 3 of the draft, but both docs are very brief. I am initiating a new WGLC, starting today, and running through Friday, Sunday, March 25, so that the WGLC can be completed before the PKIX WG meeting in Paris. See the changes using the following link: (http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-04). From mrex@sap.com Wed Mar 14 16:38:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF111E808C for ; Wed, 14 Mar 2012 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUDxdiKXSh7E for ; Wed, 14 Mar 2012 16:38:30 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96D11E808A for ; Wed, 14 Mar 2012 16:38:29 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2ENcNtQ003523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 00:38:23 +0100 (MET) From: Martin Rex Message-Id: <201203142338.q2ENcMNC011788@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 15 Mar 2012 00:38:22 +0100 (MET) In-Reply-To: from "Stephen Kent" at Mar 14, 12 05:05:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt 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, 14 Mar 2012 23:38:31 -0000 Stephen Kent wrote: > > David has published an updated version of this doc. This version includes > significant new text in several sections, relative to version 3 > of the draft, but both docs are very brief. I am initiating a new > WGLC, starting today, and running through Friday, Sunday, March 25, > so that the WGLC can be completed before the PKIX WG meeting in Paris. > > See the changes using the following link: > > (http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-04). I can not parse this sentence, based on the grammar rules that I'm familiar with (it is in rfc5280 and -clarifications): The protection afforded private keys is a critical security factor. Admittedly, I'm not a native english speaker. -Martin From mrex@sap.com Wed Mar 14 20:20:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACD21F8698 for ; Wed, 14 Mar 2012 20:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.051 X-Spam-Level: X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0yoKYkKaK3n for ; Wed, 14 Mar 2012 20:20:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3321F8694 for ; Wed, 14 Mar 2012 20:20:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2F3KJjp020696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 04:20:19 +0100 (MET) From: Martin Rex Message-Id: <201203150320.q2F3KI06024615@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 15 Mar 2012 04:20:18 +0100 (MET) In-Reply-To: from "Stephen Kent" at Mar 14, 12 04:47:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 15 Mar 2012 03:20:26 -0000 Stephen Kent wrote: > > Phillip Hallam-Baker wrote: > > > > If there is going to be a choice between maintaining OCSP and > > maintaining SCVP then OCSP is going to be the one that I choose. I agree with PHB. > > If the proposal is to keep the name OCSP and add a lot of functionality > that overlaps SCVP, that is not a reasonable course of action. Just the opposite. If someone is currently running an OCSP server, and wants new functionality, upgrading to an OCSPv2 Server rather than having to setup a second server looks pretty reasonable to me. > > >I do not think that anyone can claim that SCVP is sufficiently > >deployed to abandon OCSP in its favor. > > I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an > alternative (to CRLs) for checking the revocation status of a cert. > If we have good reasons > to improve on that function, then doing so using OCSP makes sense. Steve, I don't understand why you are so obsessed with keeping OCSP locked up in a matchbox. Limiting the initial scope&functionality to that of rfc2560 in order to get an initial version of the protocol finished, shipped and deployed in a reasonable timeframe is a good idea. But insisting that a protocol never grows beyond the original scope of version 1.0 does not seem reasonable to me at all. Had the DNS folks exhibited such an attitude, then we would have to use a different Transport&Protocol to convey authentication and security for DNS records... Or look at the incremental enhancements to the HTTP protocol. > > If we're looking to address security problems related to cert revocation, and > which have become more serious due to browser trust model problems and due > to attacks on public CAs, that also may be appropriate for OCSP. > > But, as I noted above and in my previous message, if the goal is to > keep the OCSP name because it is widely known, and to add new functions > that extend OCSP functionality and that overlap with SCVP functions, then > we have a problem. That name confusion issue can be sufficiently addressed by tagging a version to the end of OCSP, e.g. OCSPv2. Since the extensibility in OCSP uses ASN.1 OID tags rather than IETF assigned code points, extensions can easily be developed outside of the IETF and PKIX and later published as informational, in case that Steve intends to roadblock progress all by himself rather than letting the WG decide. -Martin From okoeroo@nikhef.nl Thu Mar 15 00:31:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62E21F8483 for ; Thu, 15 Mar 2012 00:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDp4ScGSeUbv for ; Thu, 15 Mar 2012 00:31:54 -0700 (PDT) Received: from ambleve.nikhef.nl (ambleve.nikhef.nl [192.16.199.208]) by ietfa.amsl.com (Postfix) with ESMTP id A3EBF21F8677 for ; Thu, 15 Mar 2012 00:31:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ambleve.nikhef.nl (Postfix) with ESMTP id 25FA87815E for ; Thu, 15 Mar 2012 08:31:47 +0100 (CET) X-Virus-Scanned: amavisd-new at nikhef.nl Received: from ambleve.nikhef.nl ([127.0.0.1]) by localhost (ambleve.nikhef.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7BU0RdvD4d4A for ; Thu, 15 Mar 2012 08:31:46 +0100 (CET) Received: from Saab.local (195-241-153-193.ip.telfort.nl [195.241.153.193]) (Authenticated sender: okoeroo) by ambleve.nikhef.nl (Postfix) with ESMTP id B41777815C for ; Thu, 15 Mar 2012 08:31:46 +0100 (CET) Message-ID: <4F619AE2.4070204@nikhef.nl> Date: Thu, 15 Mar 2012 08:31:46 +0100 From: Oscar Koeroo Organization: Nikhef User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040701040508070501050302" Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 07:31:54 -0000 This is a cryptographically signed message in MIME format. --------------ms040701040508070501050302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/3/12 10:05 PM, Stephen Kent wrote: > David has published an updated version of this doc. This version includ= es > significant new text in several sections, relative to version 3 > of the draft, but both docs are very brief. I am initiating a new WGLC,= > starting today, and running through Friday, Sunday, March 25, so that t= he > WGLC can be completed before the PKIX WG meeting in Paris. >=20 > See the changes using the following link: >=20 > (http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc5280-clarifica= tions-04). May I request an addition to the Security Considerations which states something about the implications of having multiple CAs signing certifica= tes for the same entity. This could happen by accident or on purpose. In the latter case the form = of the attack is a lot more subtle then stealing a private key. Oscar --------------ms040701040508070501050302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOVzCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aI n4BBj+dCyDANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBa Fw0yODEyMzEyMzU5NTlaMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNV BAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25hbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXChRgivblCbG3F4lwKFwDX/kBgRZvozORSe pBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGVAyMbsyKYE4NYMF+sPJFF020LLsvR kWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kldEFb5jIq0KdT3NIhjc2Rz3ts 9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJjvfYtMfqVTs02DZnvEbqt SvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0E5nSEnla8P0CAwEA AaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTI iXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB ADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEwTzBN oEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixo dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcw AYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkV a7AZYW+gSON6JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuph dE22xISNR+7KLmVtNpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF +z3fcvYCQnXriIqYV2D1n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEX EzV8FqQlMy9h7s7JUuBA29O+OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7b mzXf/k2/VaHpZMNFfKyPfEfROvFOddmQZ0DosS+eFy9cNTCCBOcwggPPoAMCAQICEQDNIwVI MIr7GpLcTmqRTSPcMA0GCSqGSIb3DQEBBQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZU RVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25hbCBDQTAeFw0xMjAzMTEw MDAwMDBaFw0xMzA0MTAyMzU5NTlaMIGJMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZIm iZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYDdGNzMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGTmlraGVmMScwJQYDVQQDFB5Pc2NhciBLb2Vyb28gb2tvZXJvb0BuaWtoZWYubmww ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC10wFkBXfc9dPvzpjwEfw/tmA/DyTu DE2ceXik4A28qsffUOEMqzyOmljPIdgDHRL7sSEEKoLhjQGmu9Li8R4hdztV0f6/U95+cMHF q14yw8C4IA1WwWRsGi+QPfP/xe8MsLoGVG3IBNM9cW1oXcPLy+IyUzW6xwOWeF4rOH432V++ FJ8LVXFiN0pCWsRgaS5dCQp5iqcV0mukPRpHJEePh2vn1OTmbb/xWVvE6InJEDKQJEyMYoQB rbc2+JHUm3I5tmWfuadc/dZWM2VCCFzKO6Eb66ay7BA4nG7OMhjpzDj/HEg4BMluzeJvbDFv Togh7NPlkErBSDM2mibGseF1AgMBAAGjggGMMIIBiDAfBgNVHSMEGDAWgBTIiXOZp11RFlNF VHyjwjl8y9eqgTAdBgNVHQ4EFgQUuSRbGSTIaesjVuQaxDUdeKALVy8wDgYDVR0PAQH/BAQD AgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMCYGA1Ud IAQfMB0wDQYLKwYBBAGyMQECAh0wDAYKKoZIhvdMBQICBTBHBgNVHR8EQDA+MDygOqA4hjZo dHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQS5jcmww egYIKwYBBQUHAQEEbjBsMEIGCCsGAQUFBzAChjZodHRwOi8vY3J0LnRjcy50ZXJlbmEub3Jn L1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3Nw LnRjcy50ZXJlbmEub3JnMBwGA1UdEQQVMBOBEW9rb2Vyb29AbmlraGVmLm5sMA0GCSqGSIb3 DQEBBQUAA4IBAQCGGw38crfpbwnksG/38+8Z5iBJhjYSnLdeuXy3DfMrVmUkIQKp6CrOot6E 1cFetRCm5AriTK/qBPL7/1j0z4SmeNkGMeLMPazmtaKZaMYh+g169NUTApIUXNVckHouYxBj Mmc3C0A7QJkbgOTZvYuu4NVyP4mHizERUOFIomWMPbn/JUXJP0bN+RWIvkL5braPje9oelV+ cUCJuW7rU+duTd3VDbNmeKEeniI/X/q3G5OD5HoezOXeu8+GFLLgRW+EqfVv7mzFU5uTfGdk JiTNeJ8fQ9qtW+sImDhWtwvhoEGD5EVJZGB5IlDdlZkPK3bQ5jZ6IAs0gzyVWED8TGJYMYID GDCCAxQCAQEwWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMSQwIgYDVQQDExtU RVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQDNIwVIMIr7GpLcTmqRTSPcMAkGBSsOAwIa BQCgggGUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMx NTA3MzE0NlowIwYJKoZIhvcNAQkEMRYEFNK1RNkvyEkkiYxvFad1FjYt3W0cMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBoBgkrBgEEAYI3EAQxWzBZMEQx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQQIRAM0jBUgwivsaktxOapFNI9wwagYLKoZIhvcNAQkQAgsxW6BZMEQx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQQIRAM0jBUgwivsaktxOapFNI9wwDQYJKoZIhvcNAQEBBQAEggEAKkZU 9b+yO6402NVogvqf5nYQT6yAdwy9bu4Sde+/Sq0fjICCKJHHp/jCmmtbC9gg+4L+nJeQUzI6 raI9NLa8vP0Rzi/oom27fjaOwzTk1jJsgRkAVwZRrcJZK/zDz0kbIv2/g3crY/YtczipIUXW B5SgW3dwQoj4ptlxcPPDLkPaMx+ArJQRD2orpP9KLYZ2K7j6hGoiVi/Cwt0yg4zEZQicYdCm tynhL+7ldFu6wT6bEjHsU7OuDCIYSkFq3qwjJM/LhH+xNDL9OZEjjyNxSkyPm44GQP/mJUkW H0hMmrLX8AnaEDmpyc2fwR1JkNGPWJ5VAoDkS1Jjq5FeSbr4ygAAAAAAAA== --------------ms040701040508070501050302-- From tomas@primekey.se Thu Mar 15 02:26:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5080721F861D for ; Thu, 15 Mar 2012 02:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SJJ+qbBTxT for ; Thu, 15 Mar 2012 02:26:41 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6721F8619 for ; Thu, 15 Mar 2012 02:26:41 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 3615CE10A7 for ; Thu, 15 Mar 2012 10:26:47 +0100 (CET) Received: from [192.168.3.193] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 268C3E045C for ; Thu, 15 Mar 2012 10:26:47 +0100 (CET) Message-ID: <4F61B5CF.4050602@primekey.se> Date: Thu, 15 Mar 2012 10:26:39 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120309 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F5F0148.4020702@primekey.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Possible OCSP 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, 15 Mar 2012 09:26:42 -0000 Makes much more sense to me now as well. Cheers, Tomas On 03/14/2012 05:02 PM, Erwann Abalea wrote: > > 2012/3/14 Phillip Hallam-Baker > > > On Wed, Mar 14, 2012 at 9:20 AM, Erwann Abalea > wrote: > > > > 2012/3/14 Phillip Hallam-Baker > > [...] > >> C[99].serial+1 -> C[0].serial-1 > > > > > > That last "link" has no sense. You need to create an OCSP > response from -Inf > > to C[0].serial-1, and another one from C[99].serial+1 to +Inf. > > As I said in a previous message, this is following the DNS NSEC > practice of having the last interval wrap and if the start of the > interval is greater than the end it is equivalent to the two intervals > you give. > > > I get it, now. > > [...] > > >> Using the proposed scheme would require the CA to sign 600 million OCSP > >> tokens every day. That's 7000 signatures per second, 7000 OCSP responses > >> produced and stored somewhere per second, every single second, even > if the > >> OCSP response is not used. OCSP becomes now a non option. > > If I could sell 300 million SSL certs I am sure that Melih would be > only too delighted to write a check for the necessary signing units. > > The crypto hardware used in CA infrastructure is capable of cloning > keys into other devices under strictly controlled circumstances. So > increasing the OCSP signature capability would mean simply buying and > racking more units. > > > The example I had in mind is not an hypothetical one. And adding crypto > hardware every year is not an option. > > But I read the thread again and noticed that your proposal doesn't need > to impose pre-signing OCSP responses. A "negative gap" OCSP response can > be generated and returned when asked for a non existent serial number. > > Sorry, going back to my cave ;) > > -- > Erwann. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From david.ocallaghan@cs.tcd.ie Thu Mar 15 04:12:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956C21F8665 for ; Thu, 15 Mar 2012 04:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSQvn47PcpsF for ; Thu, 15 Mar 2012 04:12:29 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 222C021F8621 for ; Thu, 15 Mar 2012 04:12:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1B71B171C8F for ; Thu, 15 Mar 2012 11:12:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331809947; bh=Utym3P9EmPUZKh PoYzozT8MkD+JwghDzcFpj2aXpSqs=; b=F1P38qpKFmRVD+A/jjAHWOf5D7p9LG J5OCbBoyF3Ob8Ih0q0OneO2POUjUX8sCmVozSTlsKGRfiRCdTkKc3w2iV8NRlMc0 Ar0w5xHeGIfpgBBFMtmRYxZ2ZdyO+MY0uAs98IRVWeiq/LmfWKYGsk5as5lQvZOG oDBXk/NkwX0yOg1d7I8e8iV3cThhTknUKF91767nWA72WhrdoXSIEj4YQEdq1Ijq ely84P1C7HbIAHd1bwDZnHTRP76hS9iduW7AsvEMvvnNfBpvPF9mX8dzIq4nz7X1 76KQi0l0N72wDOGfjuaJpFdopXj+BKtDm+u460sfcN192QumbFp2WPBA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 3nVqvuZSY7YR for ; Thu, 15 Mar 2012 11:12:27 +0000 (GMT) Received: from [IPv6:2001:770:10:200:21e:c9ff:fe5d:632b] (unknown [IPv6:2001:770:10:200:21e:c9ff:fe5d:632b]) by smtp.scss.tcd.ie (Postfix) with ESMTPS id C0B42171C3E for ; Thu, 15 Mar 2012 11:12:27 +0000 (GMT) Message-ID: <4F61CE9B.1020302@cs.tcd.ie> Date: Thu, 15 Mar 2012 11:12:27 +0000 From: David O'Callaghan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <201203142338.q2ENcMNC011788@fs4113.wdf.sap.corp> In-Reply-To: <201203142338.q2ENcMNC011788@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:12:30 -0000 On 14/03/12 23:38, Martin Rex wrote: > I can not parse this sentence, based on the grammar rules that I'm > familiar with (it is in rfc5280 and -clarifications): > > The protection afforded private keys is a critical security factor. > > Admittedly, I'm not a native english speaker. Could I suggest: Protection of private keys is a critical security factor. Or more verbosely: The level of protection that is applied to private keys is a critical security factor. Kind regards, David O'Callaghan -- Ãnra Taighde - Scoil na hEolaíochta Ríomhaireachta ⊠na Staitisticí, Coláiste na Tríonóide, Baile Ãtha Cliath, BÃC 2 Research Fellow - School of Computer Science & Statistics, Trinity College Dublin, Dublin 2 T: +353 1 896 1720 From david.cooper@nist.gov Thu Mar 15 05:57:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51A921F86F4 for ; Thu, 15 Mar 2012 05:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWvVO2jaAHv4 for ; Thu, 15 Mar 2012 05:57:18 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA221F869A for ; Thu, 15 Mar 2012 05:57:17 -0700 (PDT) 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 q2FCv6U8004907 for ; Thu, 15 Mar 2012 08:57:06 -0400 Message-ID: <4F61E722.8090308@nist.gov> Date: Thu, 15 Mar 2012 08:57:06 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: "pkix@ietf.org" References: <201203142338.q2ENcMNC011788@fs4113.wdf.sap.corp> <4F61CE9B.1020302@cs.tcd.ie> In-Reply-To: <4F61CE9B.1020302@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:57:19 -0000 Without commenting on any proposed changes to this sentence, I'll just note that this text dates back to RFC 2459, with very few changes. Dave -------------------------------------------------------------------------------------------------- RFC 2459 (January 1999): The protection afforded private keys is a critical factor in maintaining security. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. RFC 3280 (April 2002): The protection afforded private keys is a critical security factor. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. RFC 5280 (May 2008): The protection afforded private keys is a critical security factor. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. On 03/15/2012 07:12 AM, David O'Callaghan wrote: > On 14/03/12 23:38, Martin Rex wrote: >> I can not parse this sentence, based on the grammar rules that I'm >> familiar with (it is in rfc5280 and -clarifications): >> >> The protection afforded private keys is a critical security factor. >> >> Admittedly, I'm not a native english speaker. > Could I suggest: > > Protection of private keys is a critical security factor. > > Or more verbosely: > > The level of protection that is applied to private keys is a critical > security factor. > > Kind regards, > > David O'Callaghan > From tmiller@mitre.org Thu Mar 15 09:12:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73121F86E4 for ; Thu, 15 Mar 2012 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s1aGFifZchP for ; Thu, 15 Mar 2012 09:12:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3CC21F8554 for ; Thu, 15 Mar 2012 09:12:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A856F21B1829; Thu, 15 Mar 2012 12:12:43 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 98D9221B183C; Thu, 15 Mar 2012 12:12:43 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 12:12:43 -0400 From: "Miller, Timothy J." To: Oscar Koeroo , "pkix@ietf.org" Thread-Topic: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt Thread-Index: AQHNAiZFbmo99dbsuU+5zI5MxRUUrpZrOhsAgAA9tIA= Date: Thu, 15 Mar 2012 16:12:42 +0000 Message-ID: In-Reply-To: <4F619AE2.4070204@nikhef.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.9.131] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:12:45 -0000 On 3/15/12 2:31 AM, "Oscar Koeroo" wrote: >May I request an addition to the Security Considerations which states >something about the implications of having multiple CAs signing >certificates >for the same entity. > >This could happen by accident or on purpose. In the latter case the form >of >the attack is a lot more subtle then stealing a private key. Did I miss a major discussion on the list? What attack? -- T From tmiller@mitre.org Thu Mar 15 09:21:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867521F877A for ; Thu, 15 Mar 2012 09:21:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4bzIS6cbB2B for ; Thu, 15 Mar 2012 09:21:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF16421F8780 for ; Thu, 15 Mar 2012 09:21:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A12621B088B; Thu, 15 Mar 2012 12:21:04 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8FB9F21B0869; Thu, 15 Mar 2012 12:21:04 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 12:21:04 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker , Peter Gutmann Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNAX/1e3S8XWTYQEqfNuOgbNpcQpZre3WA Date: Thu, 15 Mar 2012 16:21:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.9.131] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A704C2F20424F4092FC8B684830E69E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 15 Mar 2012 16:21:05 -0000 On 3/13/12 8:15 PM, "Phillip Hallam-Baker" wrote: >The problem with OCSP has been that the proportion of dangerous certs >in the population from all causes has always been low enough for >ignoring revocation to be an acceptable risk/performance tradeoff for >many users. I would not say it was 99.99% but at least 99.5%. >Now that some of the bad guys are putting effort into getting bad >certs, the percentage is likely to change and the risk probably ceases >to be acceptable. What I think Peter is getting at is this is akin to a base rate bias problem. The probability of a fraudulent cert is significantly lower than the probability of failure to validate from all other causes. As a result, adding "fraudulent" as a response code doesn't change the ability of the relying party to distinguish signal from noise. -- T From tmiller@mitre.org Thu Mar 15 09:29:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3CC21F8630 for ; Thu, 15 Mar 2012 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB6yxlKA9Ju5 for ; Thu, 15 Mar 2012 09:29:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1192921F85FB for ; Thu, 15 Mar 2012 09:29:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A768E21B1367; Thu, 15 Mar 2012 12:29:32 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9071121B08AB; Thu, 15 Mar 2012 12:29:32 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 12:29:32 -0400 From: "Miller, Timothy J." To: Stephen Kent , Michael Myers Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHM/uZZe3S8XWTYQEqfNuOgbNpcQpZlmvgAgAFJnICAANi8AIACawKAgAAIzgCAAAVwAIABTHaA Date: Thu, 15 Mar 2012 16:29:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.9.131] Content-Type: text/plain; charset="us-ascii" Content-ID: <20ABEA90E01DAB42B24BFE47DF7CCB9F@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 15 Mar 2012 16:29:34 -0000 However, it should be obvious that only CA-signed OCSP responses can even pretend to offer a view into whether a cert exists, because only the CA has the data available. CA-designated and Trusted Responder would be a real problem for any deployment, and there are nevertheless real risks associated with the CA-signed model in practice. Further, at high data rates I don't think this is going to be feasible anyway; once the DB query response time climbs beyond a threshold the whole system is going to quickly thrash to a halt. Not that this matters in theory. :) -- T On 3/14/12 10:39 AM, "Stephen Kent" wrote: >At 8:20 AM -0700 3/14/12, Michael Myers wrote: >>On Mar 14, 2012, at 7:48 AM, Stephen Kent wrote: >> >>>an OCSP server can generate responses using only a CRL for the CA >>>in question. >> >>Steve, >> >>For the record, what I had in mind back then was authoritative >>access to the data necessary to the production of a CRL. With CRLs >>being periodic, the freshest data remained unaccessible. But >>lacking such access, *then* the CRL. That's where Ambarish and I >>got into it. And Carlisle too, as I recall. >> >>Mike > >Mike, > >Thanks for the historical background. I'd suggest that the data >needed to produce a CRL is not much different from the CRL itself, in >this context, except wrt timeliness. > >I also observe that RFC 2560 begins with the statement: > >"This document specifies a protocol useful in determining the current >status of a digital certificate without requiring CRLs." > >That statement suggests that OCSP responses are to be viewed as an >alternative >to CRLs (although the term "status" is overly broad here). > >The protocol overview in Section 2 refines this notion by stating: > >"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." > >This text suggests that OCSP response processing can be either a >substitute for CRL checking, or that these responses offer a more up >to date source of revocation status data. The latter interpretation >is consistent with the >notion of issuing OCPS responses based on the data used to generate >CRLs, perhaps before the next CRL is issued. > >None of this text suggests that OCSP is a way to determine if a cert >has been issued, one of the features being discussed now. > >Steve >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From okoeroo@nikhef.nl Thu Mar 15 11:04:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D2D21F87BF for ; Thu, 15 Mar 2012 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOCaOV9n-wJC for ; Thu, 15 Mar 2012 11:04:42 -0700 (PDT) Received: from ambleve.nikhef.nl (ambleve.nikhef.nl [192.16.199.208]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8D21F87B2 for ; Thu, 15 Mar 2012 11:04:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ambleve.nikhef.nl (Postfix) with ESMTP id AA8AB7816B; Thu, 15 Mar 2012 19:04:35 +0100 (CET) X-Virus-Scanned: amavisd-new at nikhef.nl Received: from ambleve.nikhef.nl ([127.0.0.1]) by localhost (ambleve.nikhef.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qwloefz++0-P; Thu, 15 Mar 2012 19:04:35 +0100 (CET) Received: from Saab.local (195-241-153-193.ip.telfort.nl [195.241.153.193]) (Authenticated sender: okoeroo) by ambleve.nikhef.nl (Postfix) with ESMTP id 22ED17815C; Thu, 15 Mar 2012 19:04:35 +0100 (CET) Message-ID: <4F622F32.6050309@nikhef.nl> Date: Thu, 15 Mar 2012 19:04:34 +0100 From: Oscar Koeroo Organization: Nikhef User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060302010000030004070007" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:04:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060302010000030004070007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15/3/12 5:12 PM, Miller, Timothy J. wrote: > On 3/15/12 2:31 AM, "Oscar Koeroo" wrote: >=20 >> May I request an addition to the Security Considerations which states >> something about the implications of having multiple CAs signing >> certificates >> for the same entity. >> >> This could happen by accident or on purpose. In the latter case the fo= rm >> of >> the attack is a lot more subtle then stealing a private key. >=20 > Did I miss a major discussion on the list? What attack? >=20 > -- T Let me rephrase that to "impersonation" for lack of a more proper word. T= he use case is quite simple: somebody could acquire/buy a certificate signed= for a domain that already has a host certificate from another CA. The purpose could be legitimate, e.g. a migration to another CA. The purpose could also be illegitimate. I'm making this note that the Security Considerations section could menti= on this risk too. Oscar --------------ms060302010000030004070007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOVzCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aI n4BBj+dCyDANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBa Fw0yODEyMzEyMzU5NTlaMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNV BAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25hbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXChRgivblCbG3F4lwKFwDX/kBgRZvozORSe pBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGVAyMbsyKYE4NYMF+sPJFF020LLsvR kWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kldEFb5jIq0KdT3NIhjc2Rz3ts 9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJjvfYtMfqVTs02DZnvEbqt SvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0E5nSEnla8P0CAwEA AaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTI iXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB ADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEwTzBN oEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixo dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcw AYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkV a7AZYW+gSON6JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuph dE22xISNR+7KLmVtNpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF +z3fcvYCQnXriIqYV2D1n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEX EzV8FqQlMy9h7s7JUuBA29O+OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7b mzXf/k2/VaHpZMNFfKyPfEfROvFOddmQZ0DosS+eFy9cNTCCBOcwggPPoAMCAQICEQDNIwVI MIr7GpLcTmqRTSPcMA0GCSqGSIb3DQEBBQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZU RVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25hbCBDQTAeFw0xMjAzMTEw MDAwMDBaFw0xMzA0MTAyMzU5NTlaMIGJMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZIm iZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYDdGNzMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGTmlraGVmMScwJQYDVQQDFB5Pc2NhciBLb2Vyb28gb2tvZXJvb0BuaWtoZWYubmww ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC10wFkBXfc9dPvzpjwEfw/tmA/DyTu DE2ceXik4A28qsffUOEMqzyOmljPIdgDHRL7sSEEKoLhjQGmu9Li8R4hdztV0f6/U95+cMHF q14yw8C4IA1WwWRsGi+QPfP/xe8MsLoGVG3IBNM9cW1oXcPLy+IyUzW6xwOWeF4rOH432V++ FJ8LVXFiN0pCWsRgaS5dCQp5iqcV0mukPRpHJEePh2vn1OTmbb/xWVvE6InJEDKQJEyMYoQB rbc2+JHUm3I5tmWfuadc/dZWM2VCCFzKO6Eb66ay7BA4nG7OMhjpzDj/HEg4BMluzeJvbDFv Togh7NPlkErBSDM2mibGseF1AgMBAAGjggGMMIIBiDAfBgNVHSMEGDAWgBTIiXOZp11RFlNF VHyjwjl8y9eqgTAdBgNVHQ4EFgQUuSRbGSTIaesjVuQaxDUdeKALVy8wDgYDVR0PAQH/BAQD AgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMCYGA1Ud IAQfMB0wDQYLKwYBBAGyMQECAh0wDAYKKoZIhvdMBQICBTBHBgNVHR8EQDA+MDygOqA4hjZo dHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQS5jcmww egYIKwYBBQUHAQEEbjBsMEIGCCsGAQUFBzAChjZodHRwOi8vY3J0LnRjcy50ZXJlbmEub3Jn L1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3Nw LnRjcy50ZXJlbmEub3JnMBwGA1UdEQQVMBOBEW9rb2Vyb29AbmlraGVmLm5sMA0GCSqGSIb3 DQEBBQUAA4IBAQCGGw38crfpbwnksG/38+8Z5iBJhjYSnLdeuXy3DfMrVmUkIQKp6CrOot6E 1cFetRCm5AriTK/qBPL7/1j0z4SmeNkGMeLMPazmtaKZaMYh+g169NUTApIUXNVckHouYxBj Mmc3C0A7QJkbgOTZvYuu4NVyP4mHizERUOFIomWMPbn/JUXJP0bN+RWIvkL5braPje9oelV+ cUCJuW7rU+duTd3VDbNmeKEeniI/X/q3G5OD5HoezOXeu8+GFLLgRW+EqfVv7mzFU5uTfGdk JiTNeJ8fQ9qtW+sImDhWtwvhoEGD5EVJZGB5IlDdlZkPK3bQ5jZ6IAs0gzyVWED8TGJYMYID GDCCAxQCAQEwWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMSQwIgYDVQQDExtU RVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQDNIwVIMIr7GpLcTmqRTSPcMAkGBSsOAwIa BQCgggGUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMx NTE4MDQzNFowIwYJKoZIhvcNAQkEMRYEFGPDumX5WZhUk7JyNlq7atS43tKTMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBoBgkrBgEEAYI3EAQxWzBZMEQx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQQIRAM0jBUgwivsaktxOapFNI9wwagYLKoZIhvcNAQkQAgsxW6BZMEQx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQQIRAM0jBUgwivsaktxOapFNI9wwDQYJKoZIhvcNAQEBBQAEggEAZ3bv APQx72ff9bVeLy/15NGVkyVXpnZCD9+KCiOokhX1w6UOqpxAWUgZ3Nx1d8wTd6XGz2igiHc5 aNWS7djS6iTBqknPdvVXAA79gIga1C5nWSp6Qj8j0zEf5oPEnyjH9Dpkypj4uvW4ApySZTG9 6YqDSkRSVKGP1lOY+nuBZ6yjyp4ZRl6CJhNskXaTIFWvhYexC7Ukndj8e2yI/EFRt6qY/NlG vqWGRMGDC/qXMqKUgBD1LcCdCDbPz5DljiteIlX3xymtoi7d/W3tkOkKqiqqYElb3hVgxe/D bkzVcBycLUKp3aqorncMrAg6PsTI9mI22tYEoTSXAw79BFxCWAAAAAAAAA== --------------ms060302010000030004070007-- From tmiller@mitre.org Thu Mar 15 11:39:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3941C21F8649 for ; Thu, 15 Mar 2012 11:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaaMiO6O8wxj for ; Thu, 15 Mar 2012 11:39:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2460B21F86FE for ; Thu, 15 Mar 2012 11:39:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 70A6E21B08C4; Thu, 15 Mar 2012 14:39:16 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6138D21B1676; Thu, 15 Mar 2012 14:39:16 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 14:39:16 -0400 From: "Miller, Timothy J." To: Oscar Koeroo Thread-Topic: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt Thread-Index: AQHNAiZFbmo99dbsuU+5zI5MxRUUrpZrOhsAgAA9tICAAHMZAP//tduA Date: Thu, 15 Mar 2012 18:39:15 +0000 Message-ID: In-Reply-To: <4F622F32.6050309@nikhef.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.34.202] Content-Type: text/plain; charset="us-ascii" Content-ID: <2DE36958B5C81045B04114BCCB77891B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:39:18 -0000 On 3/15/12 1:04 PM, "Oscar Koeroo" wrote: >Let me rephrase that to "impersonation" for lack of a more proper word. >The >use case is quite simple: somebody could acquire/buy a certificate signed >for a domain that already has a host certificate from another CA. The >purpose could be legitimate, e.g. a migration to another CA. The purpose >could also be illegitimate. Since it's always been the case that any party can go to any CA and get a cert in any name they can prove *to the CA's satisfaction* that they're entitled to, I don't see how that warrants a security consideration. That horse was never in the barn in the first place. :) -- T From piyush@identicate.com Thu Mar 15 13:57:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58FC21F86BE for ; Thu, 15 Mar 2012 13:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCKYOMWYSX9L for ; Thu, 15 Mar 2012 13:57:05 -0700 (PDT) Received: from col0-omc2-s12.col0.hotmail.com (col0-omc2-s12.col0.hotmail.com [65.55.34.86]) by ietfa.amsl.com (Postfix) with ESMTP id 071E921F86B4 for ; Thu, 15 Mar 2012 13:57:04 -0700 (PDT) Received: from COL119-W24 ([65.55.34.72]) by col0-omc2-s12.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 13:57:05 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_727ced51-51e3-4b99-b5d9-7b3cc2503e87_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: Date: Thu, 15 Mar 2012 13:57:04 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Mar 2012 20:57:05.0109 (UTC) FILETIME=[2D6B4850:01CD02EE] Subject: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 15 Mar 2012 20:57:05 -0000 --_727ced51-51e3-4b99-b5d9-7b3cc2503e87_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the other OCSP thread=2C PHB proposed range responses in OCSP to repres= ent "not issued" certificates.I'll leave the discussion of possible status = values to that thread. However=2C that idea of returning the status of a list of serial number can= be very useful in existing OCSP deployments that pre-sign the responses. There are few limitations with one status/serial number in OCSP if the resp= onder is getting its information from the CRL.- No way to generate OCSP res= ponses ahead of time for CAs that issue certificates with non-sequential se= rial numbers- Size of collection of pre-signed OCSP responses is much bigge= r when compared to CRLS.- Number of signatures required to create OCSP resp= onses for the population of issued certificates is huge. All of these issues could be addressed if an OCSP response can associate a = status with a range of serial numbers=2C as opposed to a single serial numb= er. Thoughts? -Piyush = --_727ced51-51e3-4b99-b5d9-7b3cc2503e87_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In the other OCSP thread=2C PHB proposed  =3Brange responses in OCSP to= represent "not issued" certificates.
I'll leave the discussion of possible status values to that thread.

However=2C that idea of returning the status of= a list of serial number can be very useful in existing OCSP deployments th= at pre-sign the responses.

There are few limitatio= ns with one status/serial number in OCSP if the responder is getting its in= formation from the CRL.
- No way to generate OCSP responses ahead= of time for CAs that issue certificates with non-sequential serial numbers=
- Size of collection of pre-signed OCSP responses is much bigger= when compared to CRLS.
- Number of signatures required to create= OCSP responses for the population of issued certificates is huge.

All of these issues could be addressed if an OCSP response= can associate a status with a range of serial numbers=2C as opposed to a s= ingle serial number.

Thoughts?

-Piyush



=
= --_727ced51-51e3-4b99-b5d9-7b3cc2503e87_-- From SChokhani@cygnacom.com Thu Mar 15 14:08:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DFE21E8014 for ; Thu, 15 Mar 2012 14:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGbVBKQxrhR7 for ; Thu, 15 Mar 2012 14:08:56 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4F21E8010 for ; Thu, 15 Mar 2012 14:08:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,592,1325480400"; d="scan'208,217";a="4412318" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 15 Mar 2012 17:08:51 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 15 Mar 2012 17:08:51 -0400 From: Santosh Chokhani To: Piyush Jain , "pkix@ietf.org" Date: Thu, 15 Mar 2012 17:08:50 -0400 Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0C7jd9dYfZ/INBS2uuA6RJVgMFoAAATBoA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BA4Cscygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 15 Mar 2012 21:08:57 -0000 --_000_B83745DA469B7847811819C5005244AF0F60BA4Cscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I remain concerned about these added features without a discussion of the n= eed. As I mentioned previously, if the concern is CA compromise, this does not h= elp unless trust in the Responder is established independent of trust in th= e CA that issued the certificate in question. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain Sent: Thursday, March 15, 2012 4:57 PM To: pkix@ietf.org Subject: [pkix] Range responses in OCSP In the other OCSP thread, PHB proposed range responses in OCSP to represen= t "not issued" certificates. I'll leave the discussion of possible status values to that thread. However, that idea of returning the status of a list of serial number can b= e very useful in existing OCSP deployments that pre-sign the responses. There are few limitations with one status/serial number in OCSP if the resp= onder is getting its information from the CRL. - No way to generate OCSP responses ahead of time for CAs that issue certif= icates with non-sequential serial numbers - Size of collection of pre-signed OCSP responses is much bigger when compa= red to CRLS. - Number of signatures required to create OCSP responses for the population= of issued certificates is huge. All of these issues could be addressed if an OCSP response can associate a = status with a range of serial numbers, as opposed to a single serial number= . Thoughts? -Piyush --_000_B83745DA469B7847811819C5005244AF0F60BA4Cscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I remain con= cerned about these added features without a discussion of the need.


As I mentioned previously, if th= e concern is CA compromise, this does not help unless trust in the Responde= r is established independent of trust in the CA that issued the certificate= in question.

 

From: pkix-bounces@ietf.org [= mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain
Sent: Thursday, March 15, 2012 4:57 PM
To: pkix@ietf.org
Subje= ct: [pkix] Range responses in OCSP

 

In the other OCSP = thread, PHB proposed  range responses in OCSP to represent "not i= ssued" certificates.

I'll leave= the discussion of possible status values to that thread.=

 

However, that idea of returning the status of a list of serial number = can be very useful in existing OCSP deployments that pre-sign the responses= .

 

=

There are few limitations with one status/serial nu= mber in OCSP if the responder is getting its information from the CRL.=

- No way to generate OCSP response= s ahead of time for CAs that issue certificates with non-sequential serial = numbers

- Size of collection o= f pre-signed OCSP responses is much bigger when compared to CRLS.

- Number of signatures required to crea= te OCSP responses for the population of issued certificates is huge.

 

All of these issues could be addressed if an OCSP response = can associate a status with a range of serial numbers, as opposed to a sing= le serial number.

 <= /o:p>

Thoughts?

 

-Pi= yush

 <= /p>

 

 

= --_000_B83745DA469B7847811819C5005244AF0F60BA4Cscygexch7cygnac_-- From piyush@identicate.com Thu Mar 15 14:36:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFAA21E802D for ; Thu, 15 Mar 2012 14:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WvVWd13CQgr for ; Thu, 15 Mar 2012 14:36:04 -0700 (PDT) Received: from col0-omc2-s1.col0.hotmail.com (col0-omc2-s1.col0.hotmail.com [65.55.34.75]) by ietfa.amsl.com (Postfix) with ESMTP id AC13321E8029 for ; Thu, 15 Mar 2012 14:36:04 -0700 (PDT) Received: from COL119-W39 ([65.55.34.73]) by col0-omc2-s1.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 14:36:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_27ee2d1a-161b-49e1-b445-3cd52b122815_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Thu, 15 Mar 2012 14:36:04 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 15 Mar 2012 21:36:04.0425 (UTC) FILETIME=[9FC29390:01CD02F3] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 15 Mar 2012 21:36:05 -0000 --_27ee2d1a-161b-49e1-b445-3cd52b122815_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Santosh=2C I understand and agree with you concern about CA compromise that you raised= in the other thread.However=2C this proposal is simply optimizes the repre= sentation of same information that current OCSP protocol supports. Consider the example where you need to represent the status of certificates= with serial number 1 to 10000 and none of those certificate serials are li= sted in the CRL. To comply with current OCSP specification=2C a responder would generate 100= 00 responsed (10000 signatures). If it is bundling multiple serial numbers = in one response=2C lets say 20=2C then it would need to sign 500 responses.= In either case=2C these 10000 serials would need to be explicitly listed i= n one or more OCSP responses. With the range approach=2C the responder can just create one response which= says=2C start serial is 1=2C end serial is 10000 and the status is good. -Piyush From: SChokhani@cygnacom.com To: piyush@identicate.com=3B pkix@ietf.org Date: Thu=2C 15 Mar 2012 17:08:50 -0400 Subject: RE: [pkix] Range responses in OCSP I remain concerned about these added features without a discussion of the n= eed. As I mentioned previously=2C if the concern is CA compromise=2C this does n= ot help unless trust in the Responder is established independent of trust i= n the CA that issued the certificate in question. From: pkix-bounces@ietf.o= rg [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain Sent: Thursday=2C March 15=2C 2012 4:57 PM To: pkix@ietf.org Subject: [pkix] Range responses in OCSP In the other OCSP thread=2C PHB pro= posed range responses in OCSP to represent "not issued" certificates.I'll = leave the discussion of possible status values to that thread. However=2C t= hat idea of returning the status of a list of serial number can be very use= ful in existing OCSP deployments that pre-sign the responses. There are few= limitations with one status/serial number in OCSP if the responder is gett= ing its information from the CRL.- No way to generate OCSP responses ahead = of time for CAs that issue certificates with non-sequential serial numbers-= Size of collection of pre-signed OCSP responses is much bigger when compar= ed to CRLS.- Number of signatures required to create OCSP responses for the= population of issued certificates is huge. All of these issues could be ad= dressed if an OCSP response can associate a status with a range of serial n= umbers=2C as opposed to a single serial number. Thoughts? -Piyush = = --_27ee2d1a-161b-49e1-b445-3cd52b122815_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Santosh=2C

I understand and agree with you concern about= CA compromise that you raised in the other thread.
However=2C th= is proposal is simply optimizes the representation of same information that= current OCSP protocol supports.

Consider the exam= ple where you need to represent the status of certificates with serial numb= er 1 to 10000 and none of those certificate serials are listed in the CRL.<= /div>

To comply with current OCSP specification=2C a res= ponder would generate 10000 responsed (10000 signatures). If it is bundling= multiple serial numbers in one response=2C lets say 20=2C then it would ne= ed to sign 500 responses. In either case=2C these 10000 serials would need = to be explicitly listed in one or more OCSP responses.

With t= he range approach=2C the responder can just create one response which says= =2C start serial is 1=2C end serial is 10000 and the status is good.
<= div>
-Piyush
From: SChokhani@cygnacom.com
To: piyush@identicate= .com=3B pkix@ietf.org
Date: Thu=2C 15 Mar 2012 17:08:50 -0400
Subject= : RE: [pkix] Range responses in OCSP

I remain concerned about these added features w= ithout a discussion of the need.


As I mentioned previously=2C if the con= cern is CA compromise=2C this does not help unless trust in the Responder i= s established independent of trust in the CA that issued the certificate in= question.

 =3B

From: pkix-boun= ces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain=
Sent: Thursday=2C March 15=2C 2012 4:57 PM
To: pkix@ie= tf.org
Subject: [pkix] Range responses in OCSP

 =3B

In the other OCSP thread=2C PHB proposed  =3Bran= ge responses in OCSP to represent "not issued" certificates.

I'll leave the discussio= n of possible status values to that thread.

 =3B

However=2C that idea of ret= urning the status of a list of serial number can be very useful in existing= OCSP deployments that pre-sign the responses.

 =3B

There are few limitations w= ith one status/serial number in OCSP if the responder is getting its inform= ation from the CRL.

- No way to generate OCSP responses ahead of time for CAs t= hat issue certificates with non-sequential serial numbers

<= div>

- Size of collection = of pre-signed OCSP responses is much bigger when compared to CRLS.

- Number of = signatures required to create OCSP responses for the population of issued c= ertificates is huge.

 =3B

All of these issues could be addressed if an OCSP re= sponse can associate a status with a range of serial numbers=2C as opposed = to a single serial number.

<= span style=3D"font-size:10.0pt=3Bfont-family:"=3BTahoma"=3B=2C"= =3Bsans-serif"=3B"> =3B

Thoughts?

 =3B

-Piyush

 =3B

 =3B

 =3B

= --_27ee2d1a-161b-49e1-b445-3cd52b122815_-- From kent@bbn.com Thu Mar 15 15:15:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A987A21E8039 for ; Thu, 15 Mar 2012 15:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULFumdLFQBbz for ; Thu, 15 Mar 2012 15:15:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D91CD21E802C for ; Thu, 15 Mar 2012 15:15:37 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49209) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S8IxD-000Dyf-8X; Thu, 15 Mar 2012 18:15:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201203150320.q2F3KI06024615@fs4113.wdf.sap.corp> References: <201203150320.q2F3KI06024615@fs4113.wdf.sap.corp> Date: Thu, 15 Mar 2012 18:15:35 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 15 Mar 2012 22:15:38 -0000 At 4:20 AM +0100 3/15/12, Martin Rex wrote: >Stephen Kent wrote: >> >> Phillip Hallam-Baker wrote: >> > >> > If there is going to be a choice between maintaining OCSP and >> > maintaining SCVP then OCSP is going to be the one that I choose. > >I agree with PHB. > >> >> If the proposal is to keep the name OCSP and add a lot of functionality >> that overlaps SCVP, that is not a reasonable course of action. > >Just the opposite. > >If someone is currently running an OCSP server, and wants new functionality, >upgrading to an OCSPv2 Server rather than having to setup a second server >looks pretty reasonable to me. That's not at all clear. A new server can be a virtual instance on the same machine, so there is no significant, implied hardware cost. Depending on the complexity of dealing with new options, changes to the state machines in the sever and in clients to KNOW when the other end supports the new options (in a secure fashion) as well as processing them, etc. One cannot reliably say whether the software cost is greater or less for use of a different protocol. >... > > >Steve, I don't understand why you are so obsessed with keeping OCSP >locked up in a matchbox. Limiting the initial scope&functionality to that >of rfc2560 in order to get an initial version of the protocol finished, >shipped and deployed in a reasonable timeframe is a good idea. Actually, the result was a bit messy, as our efforts to deal with alg agility have made clear. >But insisting that a protocol never grows beyond the original scope >of version 1.0 does not seem reasonable to me at all. Your statement is a vast over simplification of the issue. We have expanded the scope of OCSP since it's initial version. The initial version did not anticipate OCSP responders with pre-signed replies. That new capability was added, but the result, again, was not ideal. I'd not like to see another attempt to expand OCSP functionality that yields a messy result, as a side effect of sticking with the base protocol. However, if we have a well-substantiated need, and a clean way to enhance OCSP that does not engender some of the problems we have seen in the past, and that does not overlap with SCVP, we can pursue it. (Note that SCVP was not intended to support public CA services, so, depending on the stated scope of the problem we might address, the SCVP overlap may not be an issue.) >Had the DNS folks exhibited such an attitude, then we would have to >use a different Transport&Protocol to convey authentication and security >for DNS records... First your analogy is seriously flawed. Second, we generally need to use TCP for DNSSEC record transport. Until DNSSEC, UDP was used almost exclusively for DNS record transport, so not such a good example :-). > > If we're looking to address security problems related to cert >revocation, and > > which have become more serious due to browser trust model problems and due > > to attacks on public CAs, that also may be appropriate for OCSP. >> >> But, as I noted above and in my previous message, if the goal is to >> keep the OCSP name because it is widely known, and to add new functions >> that extend OCSP functionality and that overlap with SCVP functions, then >> we have a problem. > >That name confusion issue can be sufficiently addressed by tagging >a version to the end of OCSP, e.g. OCSPv2. I fear you missed my point here. In the discussion that led to SCVP, one of the arguments put forth in favor of extending OCSP was to capitalize on the name, i.e., folks would think an extension of OCSP was intrinsically simpler than any new protocol. The WG rejected that approach. Using the name OCSPv2 is an example of this sort of problem. >Since the extensibility in OCSP uses ASN.1 OID tags rather than >IETF assigned code points, extensions can easily be developed outside >of the IETF and PKIX and later published as informational, in case >that Steve intends to roadblock progress all by himself rather >than letting the WG decide. Three observations: - the OIDs for OCSP are issued under an IETF/PKIX-controlled arc. - docs developed outside of the IETF and which are viewed as attempts to circumvent the IETF process may be blocked from publication as RFCs, even via the independent submission track. - my reading of the list so far does not suggest that there is widespread support for (an an yet undefined) set of OCSP extensions, which I am unilaterally blocking. Steve From paul.hoffman@vpnc.org Thu Mar 15 19:59:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130AA21E8040 for ; Thu, 15 Mar 2012 19:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAxDgaVxCAes for ; Thu, 15 Mar 2012 19:59:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 96F2921E803C for ; Thu, 15 Mar 2012 19:59:10 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2G2x6ve016658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Mar 2012 19:59:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Thu, 15 Mar 2012 19:59:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] draft-ietf-pkix-rfc5280-clarifications-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 02:59:11 -0000 The new text seems fine. However, the new text is not covered in the = Abstract or Introduction. An easier way to do this would be to not try = to introduce everything in the document. I propose: Abstract This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, clarifying some parts and making small but important changes in other parts. 1. Introduction This document updates the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280]. Each section of this document changes a different part of RFC 5280. Then, move the introductory text for certificate policy change ("The = ASN.1 [X.680] syntax for the user notice certificate policy...") into = section 3, and move the introductory test for IDNs ("Section 7.3 of RFC = 5280 specifies rules for converting...") into section 5. The other = sections don't need introductory text. --Paul Hoffman From hotz@jpl.nasa.gov Fri Mar 16 00:44:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41821F86D9 for ; Fri, 16 Mar 2012 00:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQoBE9tSPjLp for ; Fri, 16 Mar 2012 00:44:35 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 8959821F86D7 for ; Fri, 16 Mar 2012 00:44:35 -0700 (PDT) Received: from [192.168.2.107] (adsl-99-146-13-135.dsl.lsan03.sbcglobal.net [99.146.13.135]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2G7iSSI002333 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Mar 2012 00:44:29 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Fri, 16 Mar 2012 00:44:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <881277C7-B17F-42DB-B956-225E61587055@jpl.nasa.gov> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-IP: adsl-99-146-13-135.dsl.lsan03.sbcglobal.net [99.146.13.135] X-Source-Sender: hotz@jpl.nasa.gov X-Spamclassfication-Commtouch: not spam X-SpamRefId: str=0001.0A090207.4F62EF5E.0005,ss=1,fgs=0 Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 07:44:36 -0000 On Mar 14, 2012, at 1:47 PM, Stephen Kent wrote: > At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >> Does anyone use SCVP? >=20 > I'll let others, who know better than I, respond to this question. >=20 >> If there is going to be a choice between maintaining OCSP and >> maintaining SCVP then OCSP is going to be the one that I choose. >=20 > If the proposal is to keep the name OCSP and add a lot of = functionality > that overlaps SCVP, that is not a reasonable course of action. What course of action do you think will most quickly give us an = off-the-shelf web browser that can most usefully verify it's connecting = to the intended destination? Someone complained the real problem was = that browsers don't "fail hard" even when OCSP is turned on. I see it = as a chicken-and-egg problem where a browser shouldn't fail hard unless = OCSP actually tells the browser what it needs to know. I won't argue OCSP+ vs SCVP because I don't actually care. I'm very = surprised that the idea of adding a never-issued response to OCSP is so = controversial however. It appears to me that some people are reading = more into it than was originally intended. >> Could we have a discussion on this at the next meeting? As I see it, >> it PKIX is not going to maintain OCSP then it is time to fork the = spec >> and maintain it elsewhere. >=20 > "Maintan?" When you and Stefan generated RFC 6277 to try to address = the alg agility problem for OCSP, that was maintenance. Changing OCSP to = provide an indication of whether a cert was issued, for example, does = not seem like maintenance. >=20 >> I do not think that anyone can claim that SCVP is sufficiently >> deployed to abandon OCSP in its favor. >=20 > I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an = alternative (to CRLs) for checking the revocation status of a cert. If = we have good reasons > to improve on that function, then doing so using OCSP makes sense. >=20 > If we're looking to address security problems related to cert = revocation, and > which have become more serious due to browser trust model problems and = due > to attacks on public CAs, that also may be appropriate for OCSP. I thought that was the original idea, yes. > But, as I noted above and in my previous message, if the goal is to > keep the OCSP name because it is widely known, and to add new = functions > that extend OCSP functionality and that overlap with SCVP functions, = then > we have a problem. I'll grant you that adding never-issued to OCSP starts a slippery slope = in that direction, but see above. > Steve ------------------------------------------------------ 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 robert@ripe.net Fri Mar 16 00:51:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0957721F871E for ; Fri, 16 Mar 2012 00:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARnxDBrTOVdA for ; Fri, 16 Mar 2012 00:51:47 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 9180721F871C for ; Fri, 16 Mar 2012 00:51:39 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S8Rwn-0000wY-5T; Fri, 16 Mar 2012 08:51:38 +0100 Received: from kitten.ripe.net ([193.0.1.240] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1S8Rwm-0003sM-Vi; Fri, 16 Mar 2012 08:51:37 +0100 Message-ID: <4F62F10A.9040604@ripe.net> Date: Fri, 16 Mar 2012 08:51:38 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Piyush Jain References: , In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274c55dc710d7175fad2f6b45d1d58adc16 Cc: pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 07:51:48 -0000 > With the range approach, the responder can just create one response which > says, start serial is 1, end serial is 10000 and the status is good. But then it only applies if the serial is actually a sequence number; there's zero benefit in case the serial is a hash or semi-random value. Are there CAs out there that still use sequence numbers? Robert From tmiller@mitre.org Fri Mar 16 05:55:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60E421F8680 for ; Fri, 16 Mar 2012 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v4PQLHCnI0Y for ; Fri, 16 Mar 2012 05:55:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD2FC21F8675 for ; Fri, 16 Mar 2012 05:55:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 33C3F21B03DF; Fri, 16 Mar 2012 08:54:59 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 286FF21B0660; Fri, 16 Mar 2012 08:54:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.213]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Fri, 16 Mar 2012 08:54:59 -0400 From: "Miller, Timothy J." To: Robert Kisteleki , Piyush Jain Thread-Topic: [pkix] Range responses in OCSP Thread-Index: AQHNAu4vT1fWDQuPYkmt1zUAjY2mRZZsHNQAgAAHnACAAKv9AIAAAOuA Date: Fri, 16 Mar 2012 12:54:58 +0000 Message-ID: In-Reply-To: <4F62F10A.9040604@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [128.29.115.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <85AC3FBAD001E5478E7C9ADECEA90CFB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 12:55:03 -0000 On 3/16/12 2:51 AM, "Robert Kisteleki" wrote: >> With the range approach, the responder can just create one response >>which >> says, start serial is 1, end serial is 10000 and the status is good. > >But then it only applies if the serial is actually a sequence number; >there's zero benefit in case the serial is a hash or semi-random value. >Are >there CAs out there that still use sequence numbers? Yes. -- T From hallam@gmail.com Fri Mar 16 05:55:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C0E21F8679 for ; Fri, 16 Mar 2012 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y931cmsN1VWU for ; Fri, 16 Mar 2012 05:55:40 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFA9021F8675 for ; Fri, 16 Mar 2012 05:55:39 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1669036yhk.31 for ; Fri, 16 Mar 2012 05:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MmDIv0D5XjzBy/r5TvobFqVjAKxqgRa1y817uvNKIZo=; b=rcGafIfVkEk0BHdkINGgjlDL1hh3EEqk+kacx7ONIlU7kXYIMnIMXzKZgaK9XHlSoc wwIqsUrnUwy2MJpW3/Q3ft5qydxokWcH9r9LOoSeuaAiYFRFOD0XsR/froRnx3tsk6x2 3WbzNOzt/uC9OknPNYRQ39YQJXeONBe6eTj4IHBnMKlnZ3jaoQwkcW98oRcEAC5neJuV iV4brr0kd30GeF3UYe5AfXLXVuycsagwEX416Rma812oahnc/xm86iHar0+MA6g+9joM yh54v0GFqTS2jG+WoSib/SUQORBN3QseRJm4oc/4jcVIcLQVX34w20xvc5hsceJLEZa+ uckw== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr2933516oeg.15.1331902539455; Fri, 16 Mar 2012 05:55:39 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 05:55:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 08:55:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 12:55:40 -0000 On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent wrote: > At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: > > Does anyone use SCVP? > > > I'll let others, who know better than I, respond to this question. > > If there is going to be a choice between maintaining OCSP and > maintaining SCVP then OCSP is going to be the one that I choose. > > > If the proposal is to keep the name OCSP and add a lot of functionality > that overlaps SCVP, that is not a reasonable course of action. OCSP is the Online Certificate Status Protocol. This is Certificate Status. So if we accept your argument that there is overlap with SCVP, the fault is with SCVP. This is a minor incremental development of the protocol to address a functionality that was originally intended. > I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an > alternative (to CRLs) for checking the revocation status of a cert. If we > have good reasons > to improve on that function, then doing so using OCSP makes sense. You suggested that the existence of SCVP means we cannot add new features to OCSP. I said that I don't accept that as virtually nobody uses SCVP. So if you want to push that idea I think it is time to move SCVP to HISTORIC and slim down the stack a little. > If we're looking to address security problems related to cert revocation, > and > which have become more serious due to browser trust model problems and due > to attacks on public CAs, that also may be appropriate for OCSP. > > But, as I noted above and in my previous message, if the goal is to > keep the OCSP name because it is widely known, and to add new functions > that extend OCSP functionality and that overlap with SCVP functions, then > we have a problem. The functionality is certificate status and SCVP is totally irrelevant. SCVP does not address this subject area and no public CA uses it. OCSP has an extension mechanism. It should have been used to implement SCVP in the first place. -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 06:01:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1AC21F865A for ; Fri, 16 Mar 2012 06:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K97sOz2D53rC for ; Fri, 16 Mar 2012 06:01:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C365D21F8639 for ; Fri, 16 Mar 2012 06:01:10 -0700 (PDT) Received: by yenm5 with SMTP id m5so4716758yen.31 for ; Fri, 16 Mar 2012 06:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=US5StXJHXqHttlpEjWbpw32L4Aj+tj21tgj6TVsMDL4=; b=bc5OJk9zD8EJeOfzcXuUoHH0QRdzUthL8dT/lAmoj2BOZ2hTcyyOXQMeBwWuEfL6lG QDyrWNvpetducjU796YQLZVT+fAjCjwDoXs3QEKegTRx/Sun0FbC70tWpcU8TjBVyWHb 6np79iRKpQ56OZQBopcoCWU+lO41nitHLkjNXUlJrjEP/7JgVFczqyVmp7E87qKRquqB xDPwodfhQOuyGJMwGp20nIZxAFBjxCAF9O9ISV0NnKNyLF8BjDEMBMMeuVhpNfyXohy0 KvkHuJBGKvaP6ZZDemft3Lxq4AGkJiYfmbpZSJ6jVfJfUNZCrDrZCs3uRTnWcnw8+BAY GlEw== MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr3046041obc.35.1331902870229; Fri, 16 Mar 2012 06:01:10 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 06:01:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 09:01:10 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 13:01:11 -0000 Oh I agree that the issue Peter raised is a serious problem. It is the type of free rider problem that plagues public immunization programs. I don't need to have the vaccine myself provided that 99% of other people have it. The reason that revocation is in such a bad state is that mis-issued certificates have not been a serious concern in the first decade and a half of public CA operation. I don't expect that application clients will be the early consumers of this information. That is going to be mechanisms such as CertSentry which Comodo is currently beta-testing. On Thu, Mar 15, 2012 at 12:21 PM, Miller, Timothy J. wr= ote: > On 3/13/12 8:15 PM, "Phillip Hallam-Baker" wrote: > >>The problem with OCSP has been that the proportion of dangerous certs >>in the population from all causes has always been low enough for >>ignoring revocation to be an acceptable risk/performance tradeoff for >>many users. I would not say it was 99.99% but at least 99.5%. > >>Now that some of the bad guys are putting effort into getting bad >>certs, the percentage is likely to change and the risk probably ceases >>to be acceptable. > > What I think Peter is getting at is this is akin to a base rate bias > problem. =A0The probability of a fraudulent cert is significantly lower t= han > the probability of failure to validate from all other causes. =A0As a > result, adding "fraudulent" as a response code doesn't change the ability > of the relying party to distinguish signal from noise. > > -- T > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 06:04:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7221F8631 for ; Fri, 16 Mar 2012 06:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwjQ45o+OR95 for ; Fri, 16 Mar 2012 06:04:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B62221F8623 for ; Fri, 16 Mar 2012 06:04:20 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1680079yhk.31 for ; Fri, 16 Mar 2012 06:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nPVG4SlScuGOWzvJPpzt8IDzh/gpZiBJ/o05pgC17Kk=; b=uZp+9OEd7SEYkGTbTWuN/9SgCr+yeXTLldea5I8a2OSoK4xwxBjKjbdLMRjP9ex+1G 0pQolIpAr32hG4XvAkdoPxQJwam6izUK9foY47SGsaOHAC0B2hcBifaZdTCdLTHhPLV8 ivqPbcfkKzjtXMfpcH37f2fcSTzxMzqPvyIDCGVDz+rS9jhMYa1+4GxmcUJk8UufC9Cd SC/1KBuFKHB2fLJwpWNTJSXDL5jkHXDu+nDGFHNHz31RdtUgE+a5ZTUZ717y8NOzbbx3 oxpQeUNHOoec63hTVqEg8yE2OqMKnVxHLtIGtULLUYAVwwMFliFXG9OPwt6P3m3cs6pN SIsA== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr2966199oeg.15.1331903059669; Fri, 16 Mar 2012 06:04:19 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 06:04:19 -0700 (PDT) In-Reply-To: References: <201203150320.q2F3KI06024615@fs4113.wdf.sap.corp> Date: Fri, 16 Mar 2012 09:04:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 13:04:21 -0000 It is clear that two servers means two queries for the same response. This is a silly argument and I can't take your position as serious.Why oh why do you imagine that SCVP has any place in this when you admit that public CAs do not operate SCVP services? On Thu, Mar 15, 2012 at 6:15 PM, Stephen Kent wrote: > At 4:20 AM +0100 3/15/12, Martin Rex wrote: >> >> Stephen Kent wrote: >>> >>> >>> =A0Phillip Hallam-Baker wrote: >>> =A0> >>> =A0> If there is going to be a choice between maintaining OCSP and >>> =A0> maintaining SCVP then OCSP is going to be the one that I choose. >> >> >> I agree with PHB. >> >>> >>> =A0If the proposal is to keep the name OCSP and add a lot of functional= ity >>> =A0that overlaps SCVP, that is not a reasonable course of action. >> >> >> Just the opposite. >> >> If someone is currently running an OCSP server, and wants new >> functionality, >> upgrading to an OCSPv2 Server rather than having to setup a second serve= r >> looks pretty reasonable to me. > > > That's not at all clear. A new server can be a virtual instance on the sa= me > machine, so there is no significant, implied hardware cost. Depending on = the > complexity of dealing with new options, changes to the state machines in = the > sever and in clients to KNOW when the other end supports the new options = (in > a secure fashion) as well as processing them, etc. One cannot reliably sa= y > whether the software cost is greater or less for use of a different > protocol. > >> ... >> >> >> >> Steve, I don't understand why you are so obsessed with keeping OCSP >> locked up in a matchbox. =A0Limiting the initial scope&functionality to = that >> of rfc2560 in order to get an initial version of the protocol finished, >> shipped and deployed in a reasonable timeframe is a good idea. > > > Actually, the result was a bit messy, as our efforts to deal with alg > agility have made clear. > > >> But insisting that a protocol never grows beyond the original scope >> of version 1.0 does not seem reasonable to me at all. > > > Your statement is a vast over simplification of the issue. We have expand= ed > the scope of OCSP since it's initial version. =A0The initial version did = not > anticipate OCSP responders with pre-signed replies. That new capability w= as > added, but the result, again, was not ideal. > > I'd not like to see another attempt to expand OCSP functionality that yie= lds > a messy result, as a side effect of sticking with the base protocol. > However, if we have a well-substantiated need, and a clean way to enhance > OCSP that does not engender some of the problems we have seen in the past= , > and that does not overlap with SCVP, we can pursue it. =A0(Note that SCVP= was > not intended to support public CA services, so, depending on the stated > scope of the problem we might address, the SCVP overlap may not be an > issue.) > > >> Had the DNS folks exhibited such an attitude, then we would have to >> use a different Transport&Protocol to convey authentication and security >> for DNS records... > > > First your analogy is seriously flawed. Second, we generally need to use = TCP > for DNSSEC record transport. Until DNSSEC, UDP was used almost exclusivel= y > for DNS record transport, so not such a good example :-). > > > >> =A0> If we're looking to address security problems related to cert >> revocation, and >> =A0> which have become more serious due to browser trust model problems = and >> due >> =A0> to attacks on public CAs, that also may be appropriate for OCSP. >>> >>> >>> =A0But, as I noted above and in my previous message, if the goal is to >>> =A0keep the OCSP name because it is widely known, and to add new functi= ons >>> =A0that extend OCSP functionality and that overlap with SCVP functions, >>> then >>> =A0we have a problem. >> >> >> That name confusion issue can be sufficiently addressed by tagging >> a version to the end of OCSP, e.g. OCSPv2. > > > I fear you missed my point here. In the discussion that led to SCVP, one = of > the arguments put forth in favor of extending OCSP was to capitalize on t= he > name, > i.e., folks would think an extension of OCSP was intrinsically simpler th= an > any new protocol. The WG rejected that approach. Using the name OCSPv2 is= an > example > of this sort of problem. > > >> Since the extensibility in OCSP uses ASN.1 OID tags rather than >> IETF assigned code points, extensions can easily be developed outside >> of the IETF and PKIX and later published as informational, in case >> that Steve intends to roadblock progress all by himself rather >> than letting the WG decide. > > > Three observations: > > =A0 =A0 =A0 =A0- the OIDs for OCSP are issued under an IETF/PKIX-controll= ed arc. > > =A0 =A0 =A0 =A0- docs developed outside of the IETF and which are viewed = as > =A0 =A0 =A0 =A0 =A0attempts to circumvent the IETF process may be blocked= from > =A0 =A0 =A0 =A0 =A0publication as RFCs, even via the independent submissi= on track. > > =A0 =A0 =A0 =A0- my reading of the list so far does not suggest that ther= e is > =A0 =A0 =A0 =A0 =A0widespread support for (an an yet undefined) set of OC= SP > extensions, > =A0 =A0 =A0 =A0 =A0which I am unilaterally blocking. > > Steve > > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 06:09:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14FD21F856F for ; Fri, 16 Mar 2012 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmHmTOv21oy1 for ; Fri, 16 Mar 2012 06:09:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB80C21F86E3 for ; Fri, 16 Mar 2012 06:09:14 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1686218yhk.31 for ; Fri, 16 Mar 2012 06:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HB/SXYQUX0wlQXlabQcuMYS0ypgtaddE2RaITbw6hOs=; b=QbAEkW72XdJ3HpMrmlECtzrPlnSBl77A/wHR+tBYVTg4J+lrAvxSsodbBHtAv+UF9y SOYfb/kmBEEysUJWhB92AhQlH33wYhcJv5Cc1iEIvDBMsmJt2JwqUzIhABqkuYDA7gHY 0umPMjHgJaR1tDmZmn9gJRSkU5qIlOFGVXUXAumUjtE3QvI6npen7EwdC2P2soiN5bF1 u/Pce2JHnwKhR9RLyOL932JlA2/x7i+X0QVchjFN8KH5JGWmUM255rvmvqdBOSL64qxW 2yXywhGREbBDDiYvNt9Y9wxTnlh865jq8tHfyNjLU5KdztrZDwBtHLgnDCnRBaj0i9xM PTow== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr3061271obc.15.1331903353146; Fri, 16 Mar 2012 06:09:13 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 06:09:13 -0700 (PDT) Date: Fri, 16 Mar 2012 09:09:13 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 13:09:15 -0000 Stephen's comments on the alleged confusion between SCVP and OCSP suggest that the original decision to make SCVP a separate protocol from OCSP was a blunder and that the delegated certificate path processing should have been part of OCSP functionality after all. If every proposal to chance OCSP results in a turf war over which protocol is to implement the functionality then the original division was an error. Therefore I suggest the following course of action: Extend OCSP to support the SCVP functionality as an option Move SCVP to HISTORIC Not only will this avoid future pointless discussions, it will reduce the size and complexity of the PKIX protocol stack considerably. -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 06:10:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7152B21F86E3 for ; Fri, 16 Mar 2012 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aopxbLNqyIt8 for ; Fri, 16 Mar 2012 06:10:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40E21F8584 for ; Fri, 16 Mar 2012 06:10:01 -0700 (PDT) Received: by ggmi1 with SMTP id i1so4736973ggm.31 for ; Fri, 16 Mar 2012 06:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5+oHqj1rzC86Vm+C+0Gd8OL5Z0t1l5PtC7M8KEva4UI=; b=UFLshRHuddIWIJswChSKQhORqV7AdXntXP0Rnz0gdRE4A4FP5ZJ6mC2lc/w+CfO2Xn nVBoCsIgeI4GyqMf/jO/OYpdIuPkXEVD7GvtoHTtYENiSR0sE1poHL51me8bk8lmqlXO jS057AUA7iS5JkCcOZJlA0BrrGwVP0hCA5Tkfnm2mqgczn7jXMBdSqztERVzjzjLlGFV Lwk6/eBndZHe1ygdj1TdukStepsdL8rsVQj4Nd8Y/rd+evfPBnEJf7xbZgGvi+tJbb/y nBU/5kN5S0Ux/vMsbuxDqvDC/MoRmwo6nhFUiML5Ssz9Ph/jamVxgI0o9c90jp1yQ4FA 2s9Q== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr2987979oeg.15.1331903401042; Fri, 16 Mar 2012 06:10:01 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 06:10:01 -0700 (PDT) In-Reply-To: References: <4F62F10A.9040604@ripe.net> Date: Fri, 16 Mar 2012 09:10:01 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Cc: "pkix@ietf.org" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 13:10:02 -0000 I hope they are not doing so with SHA1. On Fri, Mar 16, 2012 at 8:54 AM, Miller, Timothy J. wrote: > On 3/16/12 2:51 AM, "Robert Kisteleki" wrote: > >>> With the range approach, the responder can just create one response >>>which >>> says, start serial is 1, end serial is 10000 and the status is good. >> >>But then it only applies if the serial is actually a sequence number; >>there's zero benefit in case the serial is a hash or semi-random value. >>Are >>there CAs out there that still use sequence numbers? > > Yes. > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From carl@redhoundsoftware.com Fri Mar 16 06:11:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5AF21F86FD for ; Fri, 16 Mar 2012 06:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLjIO0AsIZgn for ; Fri, 16 Mar 2012 06:11:43 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4568121F86F9 for ; Fri, 16 Mar 2012 06:11:43 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so619821wib.13 for ; Fri, 16 Mar 2012 06:11:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=a1S5JDkMmlR7EdaH7GIAdHmE4XqTEbAqwPaI33caTbw=; b=Z1UHjiiVcO5zhekmpem09YrurYD3RRv3926QHZouM41RQWDGApsIadL6A0bnrCUbLd quPKzEYGnqJmG7e5HLKTDPo8merm4Y2aeJlBo2uC7jJdUrf7PQK6DpSOzLtJVtSEJx3k lfnP2nqKH5S+H7YOATOZ7rnwh6PuQpPBlIUe/rtPxEQBf75N67KGdI6iwQrArV/vnFl4 NMgJvwE7KwcyHiWFOSW0yAGu/mwt7H6wuAzbLTshCeqkPXDsDxWdteuZ9hNMr13cZ1L8 QkNs/rcc+fUZVBm9EZ6YK5KSy+kHQBsmUho+T4PEXuQi7joM5aIrTdAn0qBJdHdvsL/Y 8NFA== Received: by 10.224.174.200 with SMTP id u8mr3498009qaz.57.1331903499083; Fri, 16 Mar 2012 06:11:39 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id ef6sm9802193qab.7.2012.03.16.06.11.35 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 06:11:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 09:11:32 -0400 From: Carl Wallace To: Phillip Hallam-Baker , Stephen Kent Message-ID: Thread-Topic: [pkix] Possible OCSP Extensions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnIuI8Op1ai51WCIvCQYBfHEg1PNR1RUWInJTGrOoIVPEQfgo2QblNrlNmnW50peoy6jVk2 Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 13:11:44 -0000 On 3/16/12 8:55 AM, "Phillip Hallam-Baker" wrote: > >The functionality is certificate status and SCVP is totally >irrelevant. SCVP does not address this subject area and no public CA >uses it. > >OCSP has an extension mechanism. It should have been used to implement >SCVP in the first place. Part of the reason SCVP has not been adopted is lack of client side support. Changing the OCSP spec is not going to improve the integration options for providing more than revocation status on the client side. From eabalea@gmail.com Fri Mar 16 08:05:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07821F876F for ; Fri, 16 Mar 2012 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zwCLcfnTvZj for ; Fri, 16 Mar 2012 08:05:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E640D21F86CA for ; Fri, 16 Mar 2012 08:05:10 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1830550yhk.31 for ; Fri, 16 Mar 2012 08:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sge96sNSMPV0xQ2PKBmq/pOFmwN0NOhlRYgWJGoQU/c=; b=G3yKuwUqlAq/HdNegPl5a1xRAph3Tk3QLgE2Q1mvvnQ+FjFbLtxZYVWcHZa7nWMVga sQnLyLeiVFyWLh5ivyIMHP1Y8CjHq5cnS3O38EPh8h0j/tTPy6gXq1RcEkTDQmqdwGgO 2JCobOWmdYHSiHKovOGoxL7MxSVx5e6I8bMUqM3rqMAehRKnn4b8qbikxhuHxhyd02fk zIEJzrY9QB9X7G9ewUOVDGub3HKe3oIY4p+PIXhCetu+/11/9CIGmD6rTrvwG4MlTRZ+ yq6520MnK+unQZVxV+Cio+nMyvNuu+DuuHWxsA/h+3WX3bdNlVHCp/xlCT5sERhgKk2o jMZQ== MIME-Version: 1.0 Received: by 10.236.153.199 with SMTP id f47mr2915137yhk.95.1331910310605; Fri, 16 Mar 2012 08:05:10 -0700 (PDT) Received: by 10.236.207.2 with HTTP; Fri, 16 Mar 2012 08:05:10 -0700 (PDT) In-Reply-To: References: <4F62F10A.9040604@ripe.net> Date: Fri, 16 Mar 2012 16:05:10 +0100 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf302d4c4eefb2d304bb5d88b8 Cc: "pkix@ietf.org" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 15:05:12 -0000 --20cf302d4c4eefb2d304bb5d88b8 Content-Type: text/plain; charset=UTF-8 2012/3/16 Phillip Hallam-Baker > I hope they are not doing so with SHA1. > They probably do. Governmental PKIs used for biometric passports use sequential serial numbers (nearly all of them), some of them still use SHA1, with RSA or ecDSA. One can guess that a government PKI used for MRTD is informed of good practices to use and deduce that a "garage-made" CA has a lot of chances to do more bad things. The first guess is obviously wrong. -- Erwann. --20cf302d4c4eefb2d304bb5d88b8 Content-Type: text/html; charset=UTF-8
2012/3/16 Phillip Hallam-Baker <hallam@gmail.com>
I hope they are not doing so with SHA1.

They probably do. Governmental PKIs used for biometric passports use sequential serial numbers (nearly all of them), some of them still use SHA1, with RSA or ecDSA.

One can guess that a government PKI used for MRTD is informed of good practices to use and deduce that a "garage-made" CA has a lot of chances to do more bad things.

The first guess is obviously wrong.

--
Erwann.
--20cf302d4c4eefb2d304bb5d88b8-- From paul.hoffman@vpnc.org Fri Mar 16 08:27:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8221F8669 for ; Fri, 16 Mar 2012 08:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op9gfJwjqLFA for ; Fri, 16 Mar 2012 08:27:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8021F8620 for ; Fri, 16 Mar 2012 08:27:31 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2GFRTYx042067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2012 08:27:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 16 Mar 2012 08:27:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 15:27:31 -0000 You earlier asked if anyone used SCVP, and there was the answer: > A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. = No public CAs use it. It is irresponsible for a public CA to request a protocol that is known = to be deployed to be moved to Historic simply because companies like = itself do not use it, even if other entities are known to use it. The = PKIX WG makes protocols that are useful to a wide range of entities, not = just public CAs. Having said that, I disagree with Steve Kent's argument that if = something is "better" done in SCVP, it cannot be done in OCSP. I agree = with Phill that any status of a certificate, including that it was not = issues or is expired, is still status and should be able to be = represented in a well-deployed protocol such as OCSP. --Paul Hoffman From piyush@identicate.com Fri Mar 16 08:58:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FC621F8685 for ; Fri, 16 Mar 2012 08:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip4eo1wBxd1t for ; Fri, 16 Mar 2012 08:58:17 -0700 (PDT) Received: from col0-omc1-s10.col0.hotmail.com (col0-omc1-s10.col0.hotmail.com [65.55.34.20]) by ietfa.amsl.com (Postfix) with ESMTP id D102D21F8711 for ; Fri, 16 Mar 2012 08:58:17 -0700 (PDT) Received: from COL119-W27 ([65.55.34.9]) by col0-omc1-s10.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 08:58:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6d08d63f-4534-448e-813f-d0dd6da3c8fa_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Fri, 16 Mar 2012 08:58:17 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2012 15:58:17.0897 (UTC) FILETIME=[9A619190:01CD038D] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 15:58:18 -0000 --_6d08d63f-4534-448e-813f-d0dd6da3c8fa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Fri=2C 16 Mar 2012 09:11:32 -0400 > From: carl@redhoundsoftware.com > To: hallam@gmail.com=3B kent@bbn.com > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 >=20 > On 3/16/12 8:55 AM=2C "Phillip Hallam-Baker" wrote: > > > >The functionality is certificate status and SCVP is totally > >irrelevant. SCVP does not address this subject area and no public CA > >uses it. > > > >OCSP has an extension mechanism. It should have been used to implement > >SCVP in the first place. >=20 > Part of the reason SCVP has not been adopted is lack of client side > support. Changing the OCSP spec is not going to improve the integration > options for providing more than revocation status on the client side. = =20 >=20 Completely agree with this observation. BTW=2C it took good 5-8 years for t= he major browser vendors to add OCSP client support in their products after= OCSP became an RFC. SCVP has just started gaining momentum and the adoptio= n is likely to increase in next few years. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_6d08d63f-4534-448e-813f-d0dd6da3c8fa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Fri=2C 16 M= ar 2012 09:11:32 -0400
>=3B From: carl@redhoundsoftware.com
>=3B = To: hallam@gmail.com=3B kent@bbn.com
>=3B CC: pkix@ietf.org
>=3B = Subject: Re: [pkix] Possible OCSP Extensions
>=3B
>=3B
>= =3B On 3/16/12 8:55 AM=2C "Phillip Hallam-Baker" <=3Bhallam@gmail.com>= =3B wrote:
>=3B >=3B<=3Bsnip>=3B
>=3B >=3BThe functionali= ty is certificate status and SCVP is totally
>=3B >=3Birrelevant. SC= VP does not address this subject area and no public CA
>=3B >=3Buses= it.
>=3B >=3B
>=3B >=3BOCSP has an extension mechanism. It s= hould have been used to implement
>=3B >=3BSCVP in the first place.<= br>>=3B
>=3B Part of the reason SCVP has not been adopted is lack o= f client side
>=3B support. Changing the OCSP spec is not going to im= prove the integration
>=3B options for providing more than revocation = status on the client side.
>=3B =3B

C= ompletely agree with this observation. BTW=2C it took good 5-8 years for th= e major browser vendors to add OCSP client support in their products after = OCSP became an RFC. SCVP has just started gaining momentum and the adoption= is likely to increase in next few years.


>= =3B
>=3B _______________________________________________
>=3B pk= ix mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mail= man/listinfo/pkix
= --_6d08d63f-4534-448e-813f-d0dd6da3c8fa_-- From denis.pinkas@bull.net Fri Mar 16 09:03:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F352A21F8589; Fri, 16 Mar 2012 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTQl+o6DZXmA; Fri, 16 Mar 2012 09:03:42 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id A913A21F8644; Fri, 16 Mar 2012 09:03:35 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id AD530180F2; Fri, 16 Mar 2012 17:03:34 +0100 (CET) In-Reply-To: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: BFE49FBF:F5693646-C12579C3:00581FAA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 16 Mar 2012 17:03:34 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 16/03/2012 17:03:34, Serialize complete at 16/03/2012 17:03:34 Content-Type: multipart/alternative; boundary="=_alternative 00583246C12579C3_=" Cc: pkix@ietf.org, pkix-bounces@ietf.org Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:03:43 -0000 Message en plusieurs parties au format MIME --=_alternative 00583246C12579C3_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Paul, I agrerw ith you that O De : Paul Hoffman A : Phillip Hallam-Baker Cc : pkix@ietf.org Date : 16/03/2012 16:27 Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC Envoy=E9 par : pkix-bounces@ietf.org You earlier asked if anyone used SCVP, and there was the answer: > A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No=20 public CAs use it. It is irresponsible for a public CA to request a protocol that is known to = be deployed to be moved to Historic simply because companies like itself=20 do not use it, even if other entities are known to use it. The PKIX WG=20 makes protocols that are useful to a wide range of entities, not just=20 public CAs. Having said that, I disagree with Steve Kent's argument that if something=20 is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill=20 that any status of a certificate, including that it was not issues or is=20 expired, is still status and should be able to be represented in a=20 well-deployed protocol such as OCSP. --Paul Hoffman =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00583246C12579C3_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Paul,

I agrerw ith you that O



De :     &= nbsp;  Paul Hoffman <paul.hoffm= an@vpnc.org>
A :     &n= bsp;  Phillip Hallam-Baker <hallam@gmail.com>
Cc :   &nb= sp;    pkix@ietf.org
Date :    =    16/03/2012 16:27
Objet :        Re: [pkix] PROPOSAL: SCVP to HISTORIC
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



You earlier asked if anyone used SCVP, and there was the answer:

> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No public CAs use it.

It is irresponsible for a public CA to request a protocol that is known to be deployed to be moved to Historic simply because companies like itself do not use it, even if other entities are known to use it. The PKIX WG makes protocols that are useful to a wide range of entities, not just public CAs.

Having said that, I disagree with Steve Kent's argument that if something is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that any status of a certificate, including that it was not issues or is expired, is still status and should be able to be represented in a well-deployed protocol such as OCSP.

--Paul Hoffman

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00583246C12579C3_=-- From brennansecurity@gmail.com Fri Mar 16 09:05:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28D821F8760 for ; Fri, 16 Mar 2012 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYP86GBhoOU6 for ; Fri, 16 Mar 2012 09:05:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0EDC21F8755 for ; Fri, 16 Mar 2012 09:05:02 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5388242vcb.31 for ; Fri, 16 Mar 2012 09:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LvaHF0K9aZ/fC+nFx10oO7K4DlqQ+PTwP+kRUh6wzD0=; b=SC4sHJGUcNHsv7PXtnV6uX6mNkxb8b+HOuxdaBySdf/3nLbciUSFPNYzvyMlqQhua2 fwBlhb6ZPCM5N6JP7jI2onQdhBrp87bs80HY3BDzepQd4n6pyAXHdVMBQLe2q5gSn942 XuYHgfsZ2kiL4uoB7jnFJ4pJ8zIFGCcbsbedKO1EgtYmSjCkEoNSBF6WBv/wv97HO3xU hQFiFk5tNAZDenMDxgD7k2qh5Lnq023VO1CiAhZfBfGhKGJCsbn8m6KEFfwogZ/Vd/bY nHWYZBysk2sAUMijD513b+U9UD3qjVsMsTHTSMPN3ksh/t3Du0yJ5cOwDPesi6beGm3/ q69A== MIME-Version: 1.0 Received: by 10.52.30.98 with SMTP id r2mr1731228vdh.8.1331913902390; Fri, 16 Mar 2012 09:05:02 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Fri, 16 Mar 2012 09:05:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 12:05:02 -0400 Message-ID: From: brennan security To: pkix@ietf.org Content-Type: multipart/alternative; boundary=20cf3079b89e05fed304bb5e5f49 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:05:04 -0000 --20cf3079b89e05fed304bb5e5f49 Content-Type: text/plain; charset=ISO-8859-1 Piyush, I was thinking of some of the same things, and apparently some other people are too.. http://www.links.org/files/sunlight.html The change I was thinking included Merkle hash trees used with statements, previously called Certificate Good Trees? I don't know if that would be a good solution though. regards, -b On Thu, Mar 15, 2012 at 4:57 PM, Piyush Jain wrote: > In the other OCSP thread, PHB proposed range responses in OCSP to > represent "not issued" certificates. > I'll leave the discussion of possible status values to that thread. > > However, that idea of returning the status of a list of serial number can > be very useful in existing OCSP deployments that pre-sign the responses. > > There are few limitations with one status/serial number in OCSP if the > responder is getting its information from the CRL. > - No way to generate OCSP responses ahead of time for CAs that issue > certificates with non-sequential serial numbers > - Size of collection of pre-signed OCSP responses is much bigger when > compared to CRLS. > - Number of signatures required to create OCSP responses for the > population of issued certificates is huge. > > All of these issues could be addressed if an OCSP response can associate a > status with a range of serial numbers, as opposed to a single serial number. > > Thoughts? > > -Piyush > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > --20cf3079b89e05fed304bb5e5f49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Piyush,

I was thinking of some of the same things, and apparently so= me other people are too.. http://www.links.org/files/sunlight.html

The change I was th= inking included Merkle hash trees used with statements, previously called C= ertificate Good Trees?

I don't know if that would be a good solution though.

regard= s,

-b

On Thu, Mar 15, 2012 at 4:57= PM, Piyush Jain <piyush@identicate.com> wrote:
In the other OCSP thread, PHB proposed =A0range responses in OCSP to repres= ent "not issued" certificates.
I'll leave the discussion of possible status values to that thread.

However, that idea of returning the status of a list of= serial number can be very useful in existing OCSP deployments that pre-sig= n the responses.

There are few limitations with on= e status/serial number in OCSP if the responder is getting its information = from the CRL.
- No way to generate OCSP responses ahead of time for CAs that issue c= ertificates with non-sequential serial numbers
- Size of collecti= on of pre-signed OCSP responses is much bigger when compared to CRLS.
- Number of signatures required to create OCSP responses for the popul= ation of issued certificates is huge.

All of these= issues could be addressed if an OCSP response can associate a status with = a range of serial numbers, as opposed to a single serial number.

Thoughts?

-Piyush


=

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


--20cf3079b89e05fed304bb5e5f49-- From hallam@gmail.com Fri Mar 16 09:07:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0619A21F8767 for ; Fri, 16 Mar 2012 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy3Vlr8brGg6 for ; Fri, 16 Mar 2012 09:07:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF721F85AC for ; Fri, 16 Mar 2012 09:07:21 -0700 (PDT) Received: by obbta4 with SMTP id ta4so290164obb.31 for ; Fri, 16 Mar 2012 09:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lpIPqgOm6BZ4lIGsMmPRt9phhtg6UKWVVuKrvauWjc4=; b=GIjKqPPqO5HN08mrrZonUlXSBClMifJJOGrdnNKwp2ZgVLKpM0kAw0C32eqPEbS8PI gqpHM/yGag+Tbl67DdDg3R6u4a3iwHU/rlc2G5QMuZrABmPwnpjZ5NUBkmWlnwFY6xKo H03R3Tj4IIpkGNuf7Sdl7uay9iTToyNaBMwQ3TPtfk56XfkJFuSD5DlcSxhz7TexspFA cqU2syklYFqA7W5UNDRO2xA7q0kutMgQRshVPTPio4oihsmxrjqCU+6ySX8X8uQRUbYL g5caQ9vbS9emVLECdgxpCNs6nGhXxdoApDYeHbrQcdIcPTLa++wj1X/K7JCEH8Uv8PAv Pdnw== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr3929132obc.15.1331914041296; Fri, 16 Mar 2012 09:07:21 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 09:07:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 12:07:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 16:07:23 -0000 Again, a reason to drop SCVP and concentrate on a single protocol. Lets do this systematically: 1) Is the proposal related to certificate status or to cert path validation= ? A: The feature is directly related to certificate status, stating that the certificate serial number was never issued. Since OCSP is the certificate status protocol, OCSP is the right protocol for implementation 2) Would the service be implemented by a CA or a third party? A: This feature can only be implemented by a CA. Since SCVP is not implemented by CAs and intended to serve as a protocol to support delegated processing of relying party path math it makes no sense to attempt to use SCVP. Only OCSP is suitable. 3) Which protocol is most widely used? A. OCSP by a very long way 4) Which protocol are the proposers of the feature interested in using? A. OCSP Deployment of SCVP is not my problem. If people think that there is a market for that capability then fine. But as things stand we have a group that is very vocal in telling us that they don't want the feature but they are nevertheless determined that it be part of the protocol nobody who is interested in the feature wants to use. I really cannot understand the strategy here unless the objective is to make me really upset in the hope that I will say something that will then be used as a pretext for ignoring my proposal. On Fri, Mar 16, 2012 at 9:11 AM, Carl Wallace w= rote: > > On 3/16/12 8:55 AM, "Phillip Hallam-Baker" wrote: >> >>The functionality is certificate status and SCVP is totally >>irrelevant. SCVP does not address this subject area and no public CA >>uses it. >> >>OCSP has an extension mechanism. It should have been used to implement >>SCVP in the first place. > > Part of the reason SCVP has not been adopted is lack of client side > support. =A0Changing the OCSP spec is not going to improve the integratio= n > options for providing more than revocation status on the client side. > > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 09:20:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8707B21F8729 for ; Fri, 16 Mar 2012 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePF-THg4N0G9 for ; Fri, 16 Mar 2012 09:20:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA0121F8731 for ; Fri, 16 Mar 2012 09:20:09 -0700 (PDT) Received: by yenm5 with SMTP id m5so4966425yen.31 for ; Fri, 16 Mar 2012 09:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hKNIDe4SBLW7ylkMS9JioJomT2monFXNSAnMY/J6EmE=; b=TJM7opHDw9EfBkQASTET+tnGVNFSn7T3sLa1zw7/LPQAG6aGDjNrAKmyBzJD499tRu fHdRbbtuF3iWbT7KlG9GpVEWoFTC4w2m+nQvuPvuRCnQPyf1lnaW5nhFvBjnDIv3Rxar Qnq+Xg7LcNDrhghWp0cHKHtCBYrIObZwVz8qEi3Q64pgSSkgMPMjYpVqiLUsHJwLcV3V 4IVjh3szDJ6l8qMa/oHLtmHft4qDXexnXBvUdzQo1o5DIFB3nCJx8I6U5WDgYgjAHl4M zjqDDe7gW3353mR1mrjWVEaAVVrybUDWJyUlcRtR5Hhjf20KpPRH/0HIL02fw3/2Kyz9 Lh3g== MIME-Version: 1.0 Received: by 10.60.30.66 with SMTP id q2mr3711941oeh.25.1331914809154; Fri, 16 Mar 2012 09:20:09 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 09:20:09 -0700 (PDT) In-Reply-To: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> Date: Fri, 16 Mar 2012 12:20:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:20:13 -0000 Paul, Well I agree with you that this is bad. But the alternative is worse. Here we have the chair of the PKIX group saying that we can't maintain or develop OCSP because he wants to keep new functionality for his favorite protocol that almost nobody is using. I had no problem in continuing to support SCVP when doing so was harmless. But that is no longer the case. If Stephen wants to try to gore my ox then I am going to shoot his, run it over with an armored vehicle a few times and incinerate the remains with thermite. There is clearly a much better case for PKIX to drop SCVP completely than for public CAs to deploy a new protocol to support a feature that is far better suited and easily supported in an existing one. So if Stephen will drop his proposal to tie the functionality I need to a protocol I do not want, SCVP will no longer be causing harm and there will be no need to consider moving SCVP to HISTORIC. If he wants to draw this out into a protracted fight then the cost of continuing to maintain SCVP rises. On Fri, Mar 16, 2012 at 11:27 AM, Paul Hoffman wrot= e: > You earlier asked if anyone used SCVP, and there was the answer: > >> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No = public CAs use it. > > It is irresponsible for a public CA to request a protocol that is known t= o be deployed to be moved to Historic simply because companies like itself = do not use it, even if other entities are known to use it. The PKIX WG make= s protocols that are useful to a wide range of entities, not just public CA= s. > > Having said that, I disagree with Steve Kent's argument that if something= is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill th= at any status of a certificate, including that it was not issues or is expi= red, is still status and should be able to be represented in a well-deploye= d protocol such as OCSP. > > --Paul Hoffman > --=20 Website: http://hallambaker.com/ From stefan@aaa-sec.com Fri Mar 16 09:22:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E498C21F859F for ; Fri, 16 Mar 2012 09:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zovJ9wWdEW14 for ; Fri, 16 Mar 2012 09:22:13 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id AD07421F851A for ; Fri, 16 Mar 2012 09:22:10 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 80D661DE5AEC for ; Fri, 16 Mar 2012 17:19: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 RgAFqxc3PlwD for ; Fri, 16 Mar 2012 17:19:48 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4AD001DE5AE4 for ; Fri, 16 Mar 2012 17:19:48 +0100 (CET) Received: (qmail 94741 invoked from network); 16 Mar 2012 16:19:46 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.212]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Mar 2012 16:19:46 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 17:19:30 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: [pkix] Agenda requests for Paris In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:22:15 -0000 I have posted a preliminary agenda at: http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt I do lack presentations on current ongoing drafts. If you are currently editing a PKIX WG draft, please notify me and Steve if you need an agenda slot or not /Stefan On 12-02-28 11:49 PM, "Stephen Kent" wrote: >Folks, > >I have already sent a message noting our meeting day/time/room. > >Please let Stefan and me know if you want a slot on the agenda. > >Thanks, > >Steve >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Mar 16 09:24:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9F21F85AC for ; Fri, 16 Mar 2012 09:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iLDtRjOb+7t for ; Fri, 16 Mar 2012 09:24:04 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id DDA9221F8550 for ; Fri, 16 Mar 2012 09:23:56 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 43D6118009; Fri, 16 Mar 2012 17:23:56 +0100 (CET) In-Reply-To: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 0D78F61B:91498F58-C12579C3:00584796; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 16 Mar 2012 17:23:55 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 16/03/2012 17:23:56, Serialize complete at 16/03/2012 17:23:56 Content-Type: multipart/alternative; boundary="=_alternative 0059F705C12579C3_=" Cc: pkix@ietf.org Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:24:05 -0000 Message en plusieurs parties au format MIME --=_alternative 0059F705C12579C3_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Paul, I agree with you that it is possible to extend OCSP, as long as additional = status information is related to information=20 available by the CA that has issued the certificate. In particular, since=20 CRL is a "black list" mechanism, OCSP is able to use a "white list" mechanism. This is where "not issued" has a=20 meaning. However, the benefit of using a white list mechanism is only a small=20 advantage in case the CA is compromised. If everything has been compromised in the CA premises, then there is no=20 advantage at all. The only advantage is when the CA compromission is only partial and when=20 the forged certificate=20 has not been able to be included in the log of issued certificates.=20 For example, the HSM has been used directly to create a forged=20 certificate. The danger is that people might think that white list mechanisms are much=20 better than black list mechanisms,=20 whereas this is not as straight. Denis PS. SCVP complexity is about 10 times the complexity of OCSP, hence why it = is and will not be not widely deployed. PS 2. the previous message was sent before my message was finished. De : Paul Hoffman A : Phillip Hallam-Baker Cc : pkix@ietf.org Date : 16/03/2012 16:27 Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC Envoy=E9 par : pkix-bounces@ietf.org You earlier asked if anyone used SCVP, and there was the answer: > A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No=20 public CAs use it. It is irresponsible for a public CA to request a protocol that is known to = be deployed to be moved to Historic simply because companies like itself=20 do not use it, even if other entities are known to use it. The PKIX WG=20 makes protocols that are useful to a wide range of entities, not just=20 public CAs. Having said that, I disagree with Steve Kent's argument that if something=20 is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill=20 that any status of a certificate, including that it was not issues or is=20 expired, is still status and should be able to be represented in a=20 well-deployed protocol such as OCSP. --Paul Hoffman =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0059F705C12579C3_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Paul,

I agree with you that it is possible to extend OCSP, as long as additional status information is related to information
available by the CA that has issued the certificate. In particular, since CRL is a "black list" mechanism, OCSP is able
to use a "white list" mechanism. This is where "not issued&= quot; has a meaning.

However, the benefit of using a white list mechanism is only a small advantage in case the CA is compromised.
If everything has been compromised in the CA premises, then there is no  advantage at all.

The only advantage is when the CA co= mpromission is only partial and when the forged certificate
has not been able to be included in the log of issued certificates.

For example, the HSM has been used directly to create a forged certificate.=

The danger is that people might think that white list mechanisms are much better than black list mechanisms,
whereas this is not as straight.

Denis

PS. SCVP complexity is about 10 times the complexity of OCSP, hence why it is and will not be not widely deployed= .

PS 2. the previous message was sent before my message was finished.




De :     &= nbsp;  Paul Hoffman <paul.hoffm= an@vpnc.org>
A :     &n= bsp;  Phillip Hallam-Baker <hallam@gmail.com>
Cc :   &nb= sp;    pkix@ietf.org
Date :    =    16/03/2012 16:27
Objet :        Re: [pkix] PROPOSAL: SCVP to HISTORIC
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



You earlier asked if anyone used SCVP, and there was the answer:

> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No public CAs use it.

It is irresponsible for a public CA to request a protocol that is known to be deployed to be moved to Historic simply because companies like itself do not use it, even if other entities are known to use it. The PKIX WG makes protocols that are useful to a wide range of entities, not just public CAs.

Having said that, I disagree with Steve Kent's argument that if something is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that any status of a certificate, including that it was not issues or is expired, is still status and should be able to be represented in a well-deployed protocol such as OCSP.

--Paul Hoffman

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0059F705C12579C3_=-- From mmyers@fastq.com Fri Mar 16 09:38:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66121F85DB for ; Fri, 16 Mar 2012 09:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXZNF2GmJTEj for ; Fri, 16 Mar 2012 09:38:31 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 788E121F85B4 for ; Fri, 16 Mar 2012 09:38:31 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2GGcRxM031259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 16 Mar 2012 09:38:28 -0700 Message-Id: <772FC019-0348-4A1B-B82A-CC423AD2B5A5@fastq.com> From: Michael Myers To: pkix In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Mar 2012 09:43:54 -0700 References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> X-Mailer: Apple Mail (2.936) Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:38:32 -0000 I lost track. What was the original need/requirement/observation that led to this discussion? Mike From stefan@aaa-sec.com Fri Mar 16 09:59:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7452921F86E3 for ; Fri, 16 Mar 2012 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnRuQacq2pwo for ; Fri, 16 Mar 2012 09:59:45 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9F40221F86CB for ; Fri, 16 Mar 2012 09:59:45 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 87BEA1D4A470 for ; Fri, 16 Mar 2012 17:59: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 843FkaPjdZ84 for ; Fri, 16 Mar 2012 17:59:44 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4D17E1DE55F3 for ; Fri, 16 Mar 2012 17:59:44 +0100 (CET) Received: (qmail 93944 invoked from network); 16 Mar 2012 16:59:44 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.212]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Mar 2012 16:59:44 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 17:59:14 +0100 From: Stefan Santesson To: Michael Myers , pkix Message-ID: Thread-Topic: [pkix] PROPOSAL: SCVP to HISTORIC In-Reply-To: <772FC019-0348-4A1B-B82A-CC423AD2B5A5@fastq.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 16:59:46 -0000 Mike, It's provided in the "Possible OCSP Extension" thread. Basically, if users of OCSP need to extend the functionality of OCSP in a way where some functionally may come to overlap with functionality provided by SCVP, then should we allow that overlap or force those with such need to implement SCVP? Clearly OCSP is the common dominant protocol for on-line status checking. Any attempts to force the market to use SCVP will most likely be ignored. As will any attempts to make material changes to OCSP unless it has a big use-case for high volume web server certs checking. If there is a clear and well motivated market need to add extensions to OCSP, I think we need to satisfy that need regardless of SCVP. /Stefan On 12-03-16 5:43 PM, "Michael Myers" wrote: >I lost track. What was the original need/requirement/observation that >led to this discussion? > >Mike >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Fri Mar 16 10:21:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12021F86C1 for ; Fri, 16 Mar 2012 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kfLt1LhRFwx for ; Fri, 16 Mar 2012 10:21:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 881FC21F86B7 for ; Fri, 16 Mar 2012 10:21:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D275021B168D; Fri, 16 Mar 2012 13:21:30 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ACBD621B1659; Fri, 16 Mar 2012 13:21:30 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.247]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Fri, 16 Mar 2012 13:21:30 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] Range responses in OCSP Thread-Index: AQHNAu4vT1fWDQuPYkmt1zUAjY2mRZZsHNQAgAAHnACAAKv9AIAAAOuAgABYCoD///JugA== Date: Fri, 16 Mar 2012 17:21:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [128.29.115.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <151A1DB7EDB55F4F803D586347FD798D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 17:21:36 -0000 On 3/16/12 8:10 AM, "Phillip Hallam-Baker" wrote: >I hope they are not doing so with SHA1. I'm familiar with the certificate collision work from Lenstra et.al. and I'm sure that this specific use is currently safe even with MD5. Certificates from the PKI in question are not completely unconstrained; the public keys and other data fields further down in TBSCertificate are checked by the system for reasonableness and receive human review, so there's no place where a significant collision resistance attack could be mounted. -- T From brennansecurity@gmail.com Fri Mar 16 10:35:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334021F8655 for ; Fri, 16 Mar 2012 10:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5waTBb85iD4j for ; Fri, 16 Mar 2012 10:35:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF021F8650 for ; Fri, 16 Mar 2012 10:35:52 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5493975vcb.31 for ; Fri, 16 Mar 2012 10:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WuOSjb0RyZ+HKxISfFYFe/tmO217fdy81oIo1ns/VoE=; b=rJXzvBXf0AZXiy7MmnVggIJ4z2SUVzBNuuj/J0vp5aOTmt9q2Q4pbj40LuOvnDrwxJ ASVFwA4uZy+fBaNkVNyt7RqK6uu34Wxh7oTxxkkmofINcpmqi3ev3lf+o+WZrF7pYcBG i4ls6gzGV7BXA3Liz+6SLkBB5ueycTGjfrW+8RIRh85/DLptmRe5h2JH4hQ5W7EEd6Yl xVYM4BbTdynHXWRj2Kqv7W96Vtgr2HBIXZc/XKX2gw+JoG0IVMchwEueQyBNuKK0NI1n 7ne0Z18IYPmuKxkUrsXwar26T/gtZNcNCZcQ4yo9b9RmbUilc31ceqHU2Fl0W3GwZa+B 333Q== MIME-Version: 1.0 Received: by 10.52.34.200 with SMTP id b8mr1789324vdj.59.1331919349163; Fri, 16 Mar 2012 10:35:49 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Fri, 16 Mar 2012 10:35:49 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> Date: Fri, 16 Mar 2012 13:35:49 -0400 Message-ID: From: brennan security To: pkix@ietf.org Content-Type: multipart/alternative; boundary=20cf30780f3ead261b04bb5fa3aa Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 17:35:53 -0000 --20cf30780f3ead261b04bb5fa3aa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (I might have missed some of the conversation) A CA could produce white lists (certificate good list) in an identical format to CRLs, then OCSP responders would know both good and bad, and could respond accordingly? Ingesting a CGL would be similar to a CRL The only issue I see with that is the time required for a CA to produce the CGL, post it, and then have the OCSP consume it. This could be handled by Not Before from x509. Or am I incorrect on this? -b On Fri, Mar 16, 2012 at 12:23 PM, wrote: > Paul, > > I agree with you that it is possible to extend OCSP, as long as additiona= l > status information is related to information > available by the CA that has issued the certificate. In particular, since > CRL is a "black list" mechanism, OCSP is able > to use a "white list" mechanism. This is where "not issued" has a meaning= . > > However, the benefit of using a white list mechanism is only a small > advantage in case the CA is compromised. > If everything has been compromised in the CA premises, then there is no > advantage at all. > > The only advantage is when the CA compromission is only partial and when > the forged certificate > has not been able to be included in the log of issued certificates. > > For example, the HSM has been used directly to create a forged certificat= e. > > The danger is that people might think that white list mechanisms are much > better than black list mechanisms, > whereas this is not as straight. > > Denis > > PS. SCVP complexity is about 10 times the complexity of OCSP, hence why i= t > is and will not be not widely deployed. > > PS 2. the previous message was sent before my message was finished. > > > > > De : Paul Hoffman > A : Phillip Hallam-Baker > Cc : pkix@ietf.org > Date : 16/03/2012 16:27 > Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC > Envoy=E9 par : pkix-bounces@ietf.org > ------------------------------ > > > > You earlier asked if anyone used SCVP, and there was the answer: > > > A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No > public CAs use it. > > It is irresponsible for a public CA to request a protocol that is known t= o > be deployed to be moved to Historic simply because companies like itself = do > not use it, even if other entities are known to use it. The PKIX WG makes > protocols that are useful to a wide range of entities, not just public CA= s. > > Having said that, I disagree with Steve Kent's argument that if something > is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill > that any status of a certificate, including that it was not issues or is > expired, is still status and should be able to be represented in a > well-deployed protocol such as OCSP. > > --Paul Hoffman > > _______________________________________________ > 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 > > --20cf30780f3ead261b04bb5fa3aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (I might have missed some of the conversation)

A CA could produce wh= ite lists (certificate good list) in an identical format to CRLs, then OCSP= responders would know both good and bad, and could respond accordingly?=A0= Ingesting a CGL would be similar to a CRL

The only issue I see with that is the time required for a CA to produce= the CGL, post it, and then have the OCSP consume it.=A0 This could be hand= led by Not Before from x509.

Or am I incorrect on this?

-b
On Fri, Mar 16, 2012 at 12:23 PM, <den= is.pinkas@bull.net> wrote:
Paul,

I agree with you that it is possible to extend OCSP, as long as additional status information is related to information
available by the CA that has issued the certificate. In particular, since CRL is a "black list" mechanism, OCSP is able
to use a "white list" mechanism. This is where "not issued&= quot; has a meaning.

However, the benefit of using a white list mechanism is only a small advantage in case the CA is compromised.
If everything has been compromised in the CA premises, then there is no =A0advantage at all.

The only advantage is when the CA compromissi= on is only partial and when the forged certificate
has not been able to be included in the log of issued certificates.

For example, the HSM has been used directly to create a forged certificate.=

The danger is that people might think that white list mechanisms are much better than black list mechanisms,
whereas this is not as straight.

Denis

PS. SCVP complexity is about 10 times the complexity of OCSP, hence why it is and will not be not widely deployed= .

PS 2. the previous message was sent before my message was finished.




De : =A0 =A0 =A0 =A0Paul Hoffman <paul.hoffman@vpnc.org&g= t;
A : =A0 =A0 =A0 =A0Phillip Hallam-Baker <hallam@gmail.com<= /a>>
Cc=A0: =A0 =A0 =A0 =A0pkix@ietf.org
Date : =A0 =A0 = =A0 =A016/03/2012 16:27
Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to HISTORIC
Envoy=E9 par : = =A0 =A0 =A0 =A0pkix-bounces@ietf.org



You earlier asked if anyone used SCVP, and th= ere was the answer:

> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No public CAs use it.

It is irresponsible for a public CA to request a protocol that is known to be deployed to be moved to Historic simply because companies like itself do not use it, even if other entities are known to use it. The PKIX WG makes protocols that are useful to a wide range of entities, not just publi= c CAs.

Having said that, I disagree with Steve Kent's argument that if somethi= ng is "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that any status of a certificate, including that it was not issues or is expired, is still status and should be able to be represented in a well-deployed protocol such as OCSP.

--Paul Hoffman

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

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


--20cf30780f3ead261b04bb5fa3aa-- From hallam@gmail.com Fri Mar 16 10:39:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6040F21F85E7 for ; Fri, 16 Mar 2012 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVz4MRbPttRv for ; Fri, 16 Mar 2012 10:38:59 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5BF21F85A8 for ; Fri, 16 Mar 2012 10:38:58 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2015702yhk.31 for ; Fri, 16 Mar 2012 10:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BFkB/LuQOlM4ir48FcwJHP/6hPDZcDM7uHfXsJqTVAs=; b=HcHvnEJig7Wz6nC1SrOdK6Vo2ScdgF05mZx6hocz8n9GtHAfg0UoSqUspC0oQKwAtZ vK8+WArHfx6mNiSyFqQMvxXu4t0+kRdt15Gf4Dkk3rFCCGIVBqalSeV9/7DnLS+C5PFu BmH0mPgCLkVvgMPAZuVjc38WOrWzEcC4dza+BVAAsSolCkhgxC7LGOV6VImnJkONB3aK wzoTdd9R4PZCcOHwn/j/Glg/ri2DX4qReNhVVIYPezH5YrUNlRDEB/oyzVr1ZKJtD8ar eGbnD3fvVAfd9hfeG/8XXEcRiiO8pRaLGMw8wLNXdpQcJHjS1IxVbswFg+cPABRXdErh +U9w== MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr3853216obb.25.1331919538578; Fri, 16 Mar 2012 10:38:58 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 10:38:58 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> Date: Fri, 16 Mar 2012 13:38:58 -0400 Message-ID: From: Phillip Hallam-Baker To: denis.pinkas@bull.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org, Paul Hoffman Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 17:39:00 -0000 Denis, I agree with the points you raise but: 1) The whole purpose of this proposal is to enable a re-engineering of CA architecture so that we eliminate 'single break' systems. At the moment there is only a modest security advantage to separating out the OCSP HSM from the cert signing HSM, but as your analysis shows having a strong response for 'does not exist' changes that. 2) SCVP is complicated because the problem it solves is very complex. The problem of enabling a 'does not exist' certificate status is much simpler and a direct and logical extension of what OCSP already does. On Fri, Mar 16, 2012 at 12:23 PM, wrote: > Paul, > > I agree with you that it is possible to extend OCSP, as long as additiona= l > status information is related to information > available by the CA that has issued the certificate. In particular, since > CRL is a "black list" mechanism, OCSP is able > to use a "white list" mechanism. This is where "not issued" has a meaning= . > > However, the benefit of using a white list mechanism is only a small > advantage in case the CA is compromised. > If everything has been compromised in the CA premises, then there is no > =A0advantage at all. > > The only advantage is when the CA compromission is only partial and when = the > forged certificate > has not been able to be included in the log of issued certificates. > > For example, the HSM has been used directly to create a forged certificat= e. > > The danger is that people might think that white list mechanisms are much > better than black list mechanisms, > whereas this is not as straight. > > Denis > > PS. SCVP complexity is about 10 times the complexity of OCSP, hence why i= t > is and will not be not widely deployed. > > PS 2. the previous message was sent before my message was finished. > > > > > De : =A0 =A0 =A0 =A0Paul Hoffman > A : =A0 =A0 =A0 =A0Phillip Hallam-Baker > Cc=A0: =A0 =A0 =A0 =A0pkix@ietf.org > Date : =A0 =A0 =A0 =A016/03/2012 16:27 > Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to HISTORIC > Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org > ________________________________ > > > > You earlier asked if anyone used SCVP, and there was the answer: > >> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No >> public CAs use it. > > It is irresponsible for a public CA to request a protocol that is known t= o > be deployed to be moved to Historic simply because companies like itself = do > not use it, even if other entities are known to use it. The PKIX WG makes > protocols that are useful to a wide range of entities, not just public CA= s. > > Having said that, I disagree with Steve Kent's argument that if something= is > "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that > any status of a certificate, including that it was not issues or is expir= ed, > is still status and should be able to be represented in a well-deployed > protocol such as OCSP. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Website: http://hallambaker.com/ From denis.pinkas@bull.net Fri Mar 16 10:41:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979DE21E8043 for ; Fri, 16 Mar 2012 10:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi8iixVMXxjq for ; Fri, 16 Mar 2012 10:41:18 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 223A221E8012 for ; Fri, 16 Mar 2012 10:41:18 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 3CB1518107; Fri, 16 Mar 2012 18:41:17 +0100 (CET) In-Reply-To: References: To: "Miller, Timothy J." MIME-Version: 1.0 X-KeepSent: A18A0172:A071D808-C12579C3:00607C8E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 16 Mar 2012 18:41:16 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 16/03/2012 18:41:16, Serialize complete at 16/03/2012 18:41:16 Content-Type: multipart/alternative; boundary="=_alternative 00611AD7C12579C3_=" Cc: pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 17:41:19 -0000 Message en plusieurs parties au format MIME --=_alternative 00611AD7C12579C3_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tim, You said that "there's no place where a significant collision resistance=20 attack could be mounted". Humm! I can include a non critical extension that nobody recognizes and=20 according to RFC 5280 rules,=20 it will be ignored and then the certificate will not be declared invalid=20 because this extension is present. Within this extension, I can place a bit string and then I have all the=20 data I need to compute a match. Denis =20 De : "Miller, Timothy J." A : Phillip Hallam-Baker Cc : "pkix@ietf.org" Date : 16/03/2012 18:21 Objet : Re: [pkix] Range responses in OCSP Envoy=E9 par : pkix-bounces@ietf.org On 3/16/12 8:10 AM, "Phillip Hallam-Baker" wrote: >I hope they are not doing so with SHA1. I'm familiar with the certificate collision work from Lenstra et.al. and I'm sure that this specific use is currently safe even with MD5. Certificates from the PKI in question are not completely unconstrained; the public keys and other data fields further down in TBSCertificate are checked by the system for reasonableness and receive human review, so there's no place where a significant collision resistance attack could be mounted. -- T =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00611AD7C12579C3_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tim,

You said that "there's no place where a significant collision resistance attack could be mounted".

Humm! I can include a non critical extens= ion that nobody recognizes and according to RFC 5280 rules,
it will be ignored and then the certificate will not be declared invalid because this extension is present.

Within this extension, I can place a bit string and then I have all the data I need to compute a match.

Denis
 



De :     &= nbsp;  "Miller, Timothy J." <tmiller@mitre.org>
A :     &n= bsp;  Phillip Hallam-Baker <hallam@gmail.com>
Cc :   &nb= sp;    "pkix@ietf.org&= quot; <pkix@ietf.org>
Date :    =    16/03/2012 18:21
Objet :        Re: [pkix] Range responses in OCSP
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



On 3/16/12 8:10 AM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

>I hope they are not doing so with SHA1.

I'm familiar with the certificate collision work from Lenstra et.al. and
I'm sure that this specific use is currently safe even with MD5.
Certificates from the PKI in question are not completely unconstrained;
the public keys and other data fields further down in TBSCertificate are
checked by the system for reasonableness and receive human review, so
there's no place where a significant collision resistance attack could be
mounted.

-- T

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00611AD7C12579C3_=-- From stefan@aaa-sec.com Fri Mar 16 11:04:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F061E21E805A for ; Fri, 16 Mar 2012 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHdg8U4Fu9eb for ; Fri, 16 Mar 2012 11:04:46 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20821E804E for ; Fri, 16 Mar 2012 11:04:45 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 12F041DE5FC5 for ; Fri, 16 Mar 2012 19:04:45 +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 gl8phV88J1zy for ; Fri, 16 Mar 2012 19:04:44 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A115C1DE5FCB for ; Fri, 16 Mar 2012 19:04:44 +0100 (CET) Received: (qmail 39912 invoked from network); 16 Mar 2012 18:04:44 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.212]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Mar 2012 18:04:44 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 19:04:35 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: Authentication context QC statement In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Authentication context QC statement X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 18:04:48 -0000 This is an issue that I preliminarily set on the agenda. I'll keep it there unless a discussion following this mail proves my need to be unnecessary. The background of the need is certificates issued, using a SAML assertion as means of authenticating the the user in the enrollment process. The specific application is a central signing service offering users the capability to sign by simply authenticating to the signing service and accept to sign some data. The signing service will then generate a key pair on behalf of that user, issue a signing certificate and sign the document using the generated key. This is a signing model that currently is considered as a solution for allowing citizens to sign for example tax declarations in sweden. Now, the signing service will get the user's identity from a SAML assertion and then squeeze it into a subject name. Eventually this will cause some loss of semantics as the flavor of attributes in SAML federations are a lot larger than the set of attributes normally required in PKI standards, such as RFC 3739 (Qualified certs). In a prototype signing service I have created, I needed a way to capture this delta in the certificate, by including information about the SAML assertion used to authenticate the used into the cert itself. I have looked at other solutions to this problems. One proposed way to do this is to include the complete SAML assertion in a certificate extension. I don't like that for several reasons: - First, and most importantly it is an integrity problem. I may not want to give away all information in the SAML assertion in the cert I'm issuing. - Secondly it explodes the size of a regular cert too include a full XML based assertion, for no obvious gain. For our prototype service I simply created a simple QC statement (as this is purely an issue for QC like certs) where I would allow arbitrary base64 encoded data in an IA5String marking identifying the encoded data format with a MIME type and an OID for the internal datastucture. Here is a printout example of this statement from a sample cert, where I stuffed the data in JSON format: QCStatement 6: AuthContextQCStatement eID2SAMLContext (1.2.752.59.54138.2.1.1) Content type: application/json { "authContextInfo": [ { "name": "AuthType", "value": "shibboleth" }, { "name": "Shib-Application-ID", "value": "eid2csig" }, { "name": "Shib-Identity-Provider", "value": "https://eidm.demo.ubisecure.com/uas" }, { "name": "Shib-Authentication-Instant", "value": "2012-03-16T17:42:09.488Z" }, { "name": "Shib-AuthnContext-Decl", "value": "https://eidm.demo.ubisecure.com/uas/saml2/names/ac/password.2" } ], "idAttributes": [ { "name": "displayName", "id": "urn:oid:2.16.840.1.113730.3.1.241", "value": "stefan@aaa-sec.com" }, { "name": "sn", "id": "urn:oid:2.5.4.4", "value": "Santesson" }, { "name": "givenName", "id": "urn:oid:2.5.4.42", "value": "Stefan" }, { "name": "personalIdentityNumber", "id": "urn:oid:1.2.752.29.4.13", "value": "194103219202" }, { "name": "mail", "id": "urn:oid:0.9.2342.19200300.100.1.3", "value": "stefan@aaa-sec.com" }, { "name": "mobileTelephoneNumber", "id": "urn:oid:0.9.2342.19200300.100.1.41", "value": "+46767861337" }, { "name": "persistent-id", "id": "urn:oid:1.3.6.1.4.1.5923.1.1.1.10", "value": "52000fcc4f024c2a99dd8e6989ee319d9af3af3e" } ] } The ASN.1 content of the statement is: SEQUENCE(2 elem) OBJECT IDENTIFIER1.2.752.59.54138.2.1.1 SEQUENCE(2 elem) PrintableString "application/json" IA5String "eyJhdXRoQ29udGV4dEluZm8iOlt7Im... The OID is my private identifier for the data structure hold in the IA5String The IA5String holds base64encoded JSON as described in the example above. This is only supposed to be used within a community that understands this structure. It effectively allows mapping between federated identities communicated in SAML assertions and identities stored in signature certificates based on the same federated identity. QUESTIONS TO THE WG: Is there anything of this that would be suitable for PKIX, mainly to add the QC statement (but not my private JSON structure)? Is there another way to do this that would be better? Or is there a reason why I should not do this at all? /Stefan From david.cooper@nist.gov Fri Mar 16 11:16:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0F721F8636 for ; Fri, 16 Mar 2012 11:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.303 X-Spam-Level: X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgIuBq09RlBQ for ; Fri, 16 Mar 2012 11:16:55 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 89CCC21F8630 for ; Fri, 16 Mar 2012 11:16:55 -0700 (PDT) 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 q2GIGj58006049; Fri, 16 Mar 2012 14:16:45 -0400 Message-ID: <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 14:16:44 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:16:56 -0000 Phil, The supposed advantages of adding a 'does not exist' response continue to elude me. Back in November I explained in detail why I didn't believe that adding this new response would provide much in the way of additional security, and if anything might only create a false sense of security (see http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). I only received two responses to my message, and both were proposing substantial changes to the PKI trust architecture, and neither supported the idea that adding a 'does not exist' status response (without making other significant changes) would provide a significant advantage. So, could you respond to my earlier message and explain why simply adding a 'does not exist' status does more than provide a false sense of added confidence? Dave On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: > Denis, > > I agree with the points you raise but: > > 1) The whole purpose of this proposal is to enable a re-engineering of > CA architecture so that we eliminate 'single break' systems. At the > moment there is only a modest security advantage to separating out the > OCSP HSM from the cert signing HSM, but as your analysis shows having > a strong response for 'does not exist' changes that. > > 2) SCVP is complicated because the problem it solves is very complex. > The problem of enabling a 'does not exist' certificate status is much > simpler and a direct and logical extension of what OCSP already does. > > > On Fri, Mar 16, 2012 at 12:23 PM, wrote: >> Paul, >> >> I agree with you that it is possible to extend OCSP, as long as additional >> status information is related to information >> available by the CA that has issued the certificate. In particular, since >> CRL is a "black list" mechanism, OCSP is able >> to use a "white list" mechanism. This is where "not issued" has a meaning. >> >> However, the benefit of using a white list mechanism is only a small >> advantage in case the CA is compromised. >> If everything has been compromised in the CA premises, then there is no >> advantage at all. >> >> The only advantage is when the CA compromission is only partial and when the >> forged certificate >> has not been able to be included in the log of issued certificates. >> >> For example, the HSM has been used directly to create a forged certificate. >> >> The danger is that people might think that white list mechanisms are much >> better than black list mechanisms, >> whereas this is not as straight. >> >> Denis >> >> PS. SCVP complexity is about 10 times the complexity of OCSP, hence why it >> is and will not be not widely deployed. >> >> PS 2. the previous message was sent before my message was finished. >> >> >> >> >> De : Paul Hoffman >> A : Phillip Hallam-Baker >> Cc : pkix@ietf.org >> Date : 16/03/2012 16:27 >> Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC >> Envoyé par : pkix-bounces@ietf.org >> ________________________________ >> >> >> >> You earlier asked if anyone used SCVP, and there was the answer: >> >>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. No >>> public CAs use it. >> It is irresponsible for a public CA to request a protocol that is known to >> be deployed to be moved to Historic simply because companies like itself do >> not use it, even if other entities are known to use it. The PKIX WG makes >> protocols that are useful to a wide range of entities, not just public CAs. >> >> Having said that, I disagree with Steve Kent's argument that if something is >> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill that >> any status of a certificate, including that it was not issues or is expired, >> is still status and should be able to be represented in a well-deployed >> protocol such as OCSP. >> >> --Paul Hoffman >> >> _______________________________________________ >> 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 mmyers@fastq.com Fri Mar 16 11:37:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED521F873B for ; Fri, 16 Mar 2012 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GgcDar7pzn4 for ; Fri, 16 Mar 2012 11:37:13 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8474121F8738 for ; Fri, 16 Mar 2012 11:37:13 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2GIb1gw001613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2012 11:37:02 -0700 Message-Id: From: Michael Myers To: Stefan Santesson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Mar 2012 11:42:28 -0700 References: X-Mailer: Apple Mail (2.936) Cc: pkix Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 18:37:14 -0000 On Mar 16, 2012, at 9:59 AM, Stefan Santesson wrote: > Basically, if users of OCSP need to extend the functionality of OCSP > in a > way where some functionally may come to overlap with functionality > provided by SCVP, then should we allow that overlap or force those > with > such need to implement SCVP? Okay. Then in that context, as lead author of OCSP and having participated in the genesis of SCVP, here's what I would advise the WG, were I standing at a microphone in Paris. If the emergent need fundamentally involves online, dynamic policy coherence, it goes to SCVP. If the need is simply what's the value of a given field in a database, it goes to OCSP. Recall that SCVP is designed to incorporate OCSP input, so there's no inherent overlap. OCSP could very well be one among several back channels feeding into an SCVP service. For example, I intended the cert status value of 'unknown' to be simply that--the queried OCSP responder has no extant data regarding the subject certificate. Maybe it was issued somewhere, somehow, by somebody, but that particular certID doesn't show up in that particular responder's collection of data regarding certificates for which it claims to be authoritative. However, if someone or some entity sought to delegate a scope of authority to a TTP regarding the authoritative issuance or lack thereof regarding a particular certificate, well, there's very likely a bits-on-the-wire policy component associated with that interaction. The crucial aspect of which would likely be that the TTP takes the hit if they (it) produces a false response the requester nonetheless relies upon before taking a security-relevant action. I make the distinguishing point about policy and delegation because, as some of us may recall, SCVP came about from proposed extensions to OCSP regarding Delegated Path Validation and Delegated Path Discovery. Which led to issues regarding policy coherence between requester and responder. Which led to SCVP. I shall now step away from the virtual microphone. Mike From hotz@jpl.nasa.gov Fri Mar 16 12:02:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37111E8074 for ; Fri, 16 Mar 2012 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HivDHKM29UlO for ; Fri, 16 Mar 2012 12:02:02 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 684CF21E801F for ; Fri, 16 Mar 2012 12:02:02 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2GJ1vnw026934 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Mar 2012 12:01:57 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Fri, 16 Mar 2012 12:01:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker , Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 19:02:03 -0000 Suppose we accept both your arguments below, and Stephen Kent's = arguments that SCVP is the right solution for the real problem faced by = ordinary users. I can imagine a solution being that the browser venders make cert = validation an extra-cost service they provide to random consumers. = Enterprise deployments might configure their browsers to use use the = enterprise SCVP. If someone can convince me that this approach will "take", I'd be all = for it. On Mar 16, 2012, at 9:07 AM, Phillip Hallam-Baker wrote: > Again, a reason to drop SCVP and concentrate on a single protocol. >=20 > Lets do this systematically: >=20 > 1) Is the proposal related to certificate status or to cert path = validation? >=20 > A: The feature is directly related to certificate status, stating that > the certificate serial number was never issued. >=20 > Since OCSP is the certificate status protocol, OCSP is the right > protocol for implementation >=20 >=20 > 2) Would the service be implemented by a CA or a third party? >=20 > A: This feature can only be implemented by a CA. >=20 > Since SCVP is not implemented by CAs and intended to serve as a > protocol to support delegated processing of relying party path math it > makes no sense to attempt to use SCVP. Only OCSP is suitable. >=20 >=20 > 3) Which protocol is most widely used? >=20 > A. OCSP by a very long way >=20 >=20 > 4) Which protocol are the proposers of the feature interested in = using? >=20 > A. OCSP >=20 >=20 > Deployment of SCVP is not my problem. If people think that there is a > market for that capability then fine. But as things stand we have a > group that is very vocal in telling us that they don't want the > feature but they are nevertheless determined that it be part of the > protocol nobody who is interested in the feature wants to use. >=20 > I really cannot understand the strategy here unless the objective is > to make me really upset in the hope that I will say something that > will then be used as a pretext for ignoring my proposal. >=20 >=20 > On Fri, Mar 16, 2012 at 9:11 AM, Carl Wallace = wrote: >>=20 >> On 3/16/12 8:55 AM, "Phillip Hallam-Baker" wrote: >>> >>> The functionality is certificate status and SCVP is totally >>> irrelevant. SCVP does not address this subject area and no public CA >>> uses it. >>>=20 >>> OCSP has an extension mechanism. It should have been used to = implement >>> SCVP in the first place. >>=20 >> Part of the reason SCVP has not been adopted is lack of client side >> support. Changing the OCSP spec is not going to improve the = integration >> options for providing more than revocation status on the client side. >>=20 >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From DPKemp@missi.ncsc.mil Fri Mar 16 12:22:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBD121E806A for ; Fri, 16 Mar 2012 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjxQ+Y+kjrCF for ; Fri, 16 Mar 2012 12:22:36 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5565121E806D for ; Fri, 16 Mar 2012 12:22:33 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2GJMW8M006388 for ; Fri, 16 Mar 2012 15:22:32 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 15:22:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 Mar 2012 15:22:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] PROPOSAL: SCVP to HISTORIC Thread-Index: Ac0Dm7ZWqMFrU7irRESZzamujmrB0AACGHRw References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Mar 2012 19:22:32.0419 (UTC) FILETIME=[22A53B30:01CD03AA] Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 19:22:38 -0000 The proposal to modify OCSP has nothing to do with "enabling a = re-engineering of the CA architecture". If it is possible to misuse the = cert-signing HSM without corrupting the issued-certs database, that = mis-use either is or is not facilitated by using the same HSM for OCSP. Case 1 - common HSM facilitates misuse: re-engineering with separate = HSMs will address that vulnerability regardless of whether OCSP is = modified. Case 2 - common HSM does not facilitate misuse: re-engineering with = separate HSMs will not reduce the vulnerability regardless of whether = OCSP is modified. Having an OCSP 'does not exist' response changes nothing with regard to = the costs and benefits of re-engineering the CA. The existence of a CA = vulnerability motivates the change to OCSP but not vice versa, any more = than a rooster crow motivates the sun to rise. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Phillip Hallam-Baker Sent: Friday, March 16, 2012 1:39 PM To: denis.pinkas@bull.net Cc: pkix@ietf.org; Paul Hoffman Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC Denis, I agree with the points you raise but: 1) The whole purpose of this proposal is to enable a re-engineering of = CA architecture so that we eliminate 'single break' systems. At the = moment there is only a modest security advantage to separating out the = OCSP HSM from the cert signing HSM, but as your analysis shows having a = strong response for 'does not exist' changes that. 2) SCVP is complicated because the problem it solves is very complex. The problem of enabling a 'does not exist' certificate status is much = simpler and a direct and logical extension of what OCSP already does. On Fri, Mar 16, 2012 at 12:23 PM, wrote: > Paul, > > I agree with you that it is possible to extend OCSP, as long as=20 > additional status information is related to information available by=20 > the CA that has issued the certificate. In particular, since CRL is a=20 > "black list" mechanism, OCSP is able to use a "white list" mechanism.=20 > This is where "not issued" has a meaning. > > However, the benefit of using a white list mechanism is only a small=20 > advantage in case the CA is compromised. > If everything has been compromised in the CA premises, then there is=20 > no > =A0advantage at all. > > The only advantage is when the CA compromission is only partial and=20 > when the forged certificate has not been able to be included in the=20 > log of issued certificates. > > For example, the HSM has been used directly to create a forged = certificate. > > The danger is that people might think that white list mechanisms are=20 > much better than black list mechanisms, whereas this is not as=20 > straight. > > Denis > > PS. SCVP complexity is about 10 times the complexity of OCSP, hence=20 > why it is and will not be not widely deployed. > > PS 2. the previous message was sent before my message was finished. > > > > > De : =A0 =A0 =A0 =A0Paul Hoffman A : =A0 =A0 = =A0 =A0Phillip=20 > Hallam-Baker Cc=A0: =A0 =A0 =A0 =A0pkix@ietf.org = Date : =A0 =A0 =A0 =A0 > 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to = HISTORIC=20 > Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org=20 > ________________________________ > > > > You earlier asked if anyone used SCVP, and there was the answer: > >> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments.=20 >> No public CAs use it. > > It is irresponsible for a public CA to request a protocol that is=20 > known to be deployed to be moved to Historic simply because companies=20 > like itself do not use it, even if other entities are known to use it. = > The PKIX WG makes protocols that are useful to a wide range of = entities, not just public CAs. > > Having said that, I disagree with Steve Kent's argument that if=20 > something is "better" done in SCVP, it cannot be done in OCSP. I agree = > with Phill that any status of a certificate, including that it was not = > issues or is expired, is still status and should be able to be=20 > represented in a well-deployed protocol such as OCSP. > > --Paul Hoffman > > _______________________________________________ > 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 > -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hotz@jpl.nasa.gov Fri Mar 16 12:38:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B721F86B3 for ; Fri, 16 Mar 2012 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kJyjeJyRFwy for ; Fri, 16 Mar 2012 12:38:45 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A621F8594 for ; Fri, 16 Mar 2012 12:38:44 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2GJchU9018422 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Mar 2012 12:38:43 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 12:38:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:38:45 -0000 Can I turn the question around and ask why adding a 'does not exist' = response would be bad? To answer your question more directly, I think there are scenarios that = could most easily be addressed if such a response could be provided. = Just because it doesn't solve all the problems doesn't mean it isn't a = useful improvement. Obviously your concerns should be covered by the security considerations = of any description of the extension. On Mar 16, 2012, at 11:16 AM, David A. Cooper wrote: > Phil, >=20 > The supposed advantages of adding a 'does not exist' response continue=20= > to elude me. Back in November I explained in detail why I didn't=20 > believe that adding this new response would provide much in the way of=20= > additional security, and if anything might only create a false sense = of=20 > security (see=20 > http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). I=20= > only received two responses to my message, and both were proposing=20 > substantial changes to the PKI trust architecture, and neither = supported=20 > the idea that adding a 'does not exist' status response (without = making=20 > other significant changes) would provide a significant advantage. ------------------------------------------------------ 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 hallam@gmail.com Fri Mar 16 12:43:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601A21F8542 for ; Fri, 16 Mar 2012 12:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCnufu6nIvel for ; Fri, 16 Mar 2012 12:43:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9F2221F853C for ; Fri, 16 Mar 2012 12:43:53 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2161907yhk.31 for ; Fri, 16 Mar 2012 12:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VEZmzOr3Dyzzz0paTrFvvFr7g1a9GEoSAzFRcCi/eLk=; b=LUR2sGtrPyS7Jr885q2b/DlmHSWDjgsjyw8uk8PAdxDU/us7cQCeNNDhVcvRU2lUFE yavIqy/xFuJcGe8EYY2M+TfX6eHovsSLXYHVqkYCa8OcHqP8gcNvXUstsBh7tatJJbse AklSwdJSzHDRWsMerWj/07WBoot1DLaAQ+PWpo+yH46wGIYVndGVz//Tq/bEUH87JZxs uLwfEmJXaImph7P9AzaWSSTKnChXQ+VITtTq+W5cXr9TP5KbMqj8l//A7kSlWzGtcFXp FHkxpE3niIlqmwTi707x7vJrMzOZ7hwDfmaUtEEuU4/I3/yejo9N1NxebzSOq0nix0Rd UUyQ== MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr4055161obc.35.1331927033202; Fri, 16 Mar 2012 12:43:53 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 12:43:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 15:43:53 -0400 Message-ID: From: Phillip Hallam-Baker To: "Henry B. Hotz" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 19:43:59 -0000 Oh is that what he is worrying about? There is definitely a case for some form of delegated trust processing from the client. But that does nothing to change the need for giving the CA the ability to transmit the right info. Lets look at this in a four corner model: Relying Party --------------------------------- Server | = | | = | Trust Broker --------------------------------- Certificate Authority SSL/PKIX is a mess because the design of OCSP means that the Relying Party has to 'cross the center' and get certificate status from the CA direct. The way the protocol should run is that the communications should run round the edges. The OCSP token should be stapled into SSL just like the certificate is. But one of the reasons I started looking at this issue is that if you take the view that the RP should be channeling their trust decisions through a broker, that pretty clearly means that the CA needs the ability to communicate all the necessary info to the trust broker - including non existence. I see SCVP as one option for a trust broker protocol. I don't think it is a good option but that is where it sits. The non existence proposal is to allow the CA to publish information. OCSP is a CA protocol. Now we can have a separate conversation as to what features should be supported in a trust broker protocol and if SCVP or XKMS or something completely new would be the best choice. Any new development in that area is going to have to support DANE, Convergence and CT type approaches and probably DNSSEC as well. If the real concern here is to get people to use a trust broker protocol, then we are all in agreement as to objectives. If people want to insist on it being SCVP then I think they need to ask themselves if this is something that really matters to them or something that they prefer or imagine will make deployment easier. On Fri, Mar 16, 2012 at 3:01 PM, Henry B. Hotz wrote: > Suppose we accept both your arguments below, and Stephen Kent's arguments= that SCVP is the right solution for the real problem faced by ordinary use= rs. > > I can imagine a solution being that the browser venders make cert validat= ion an extra-cost service they provide to random consumers. =A0Enterprise d= eployments might configure their browsers to use use the enterprise SCVP. > > If someone can convince me that this approach will "take", I'd be all for= it. > > On Mar 16, 2012, at 9:07 AM, Phillip Hallam-Baker wrote: > >> Again, a reason to drop SCVP and concentrate on a single protocol. >> >> Lets do this systematically: >> >> 1) Is the proposal related to certificate status or to cert path validat= ion? >> >> A: The feature is directly related to certificate status, stating that >> the certificate serial number was never issued. >> >> Since OCSP is the certificate status protocol, OCSP is the right >> protocol for implementation >> >> >> 2) Would the service be implemented by a CA or a third party? >> >> A: This feature can only be implemented by a CA. >> >> Since SCVP is not implemented by CAs and intended to serve as a >> protocol to support delegated processing of relying party path math it >> makes no sense to attempt to use SCVP. Only OCSP is suitable. >> >> >> 3) Which protocol is most widely used? >> >> A. OCSP by a very long way >> >> >> 4) Which protocol are the proposers of the feature interested in using? >> >> A. OCSP >> >> >> Deployment of SCVP is not my problem. If people think that there is a >> market for that capability then fine. But as things stand we have a >> group that is very vocal in telling us that they don't want the >> feature but they are nevertheless determined that it be part of the >> protocol nobody who is interested in the feature wants to use. >> >> I really cannot understand the strategy here unless the objective is >> to make me really upset in the hope that I will say something that >> will then be used as a pretext for ignoring my proposal. >> >> >> On Fri, Mar 16, 2012 at 9:11 AM, Carl Wallace wrote: >>> >>> On 3/16/12 8:55 AM, "Phillip Hallam-Baker" wrote: >>>> >>>> The functionality is certificate status and SCVP is totally >>>> irrelevant. SCVP does not address this subject area and no public CA >>>> uses it. >>>> >>>> OCSP has an extension mechanism. It should have been used to implement >>>> SCVP in the first place. >>> >>> Part of the reason SCVP has not been adopted is lack of client side >>> support. =A0Changing the OCSP spec is not going to improve the integrat= ion >>> options for providing more than revocation status on the client side. >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Mar 16 13:18:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEF821F85D9 for ; Fri, 16 Mar 2012 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FggRzFzX7b8y for ; Fri, 16 Mar 2012 13:18:05 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C921F8578 for ; Fri, 16 Mar 2012 13:18:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5256344ghb.31 for ; Fri, 16 Mar 2012 13:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=E6LluJ07N5kyRsK5Qjrqk/rQtuKbK8EdH8k2Zh0ZiB8=; b=c8ZneKOyC8InWEhOqfhxnEYe0YAcWGFOPN7JPL/84599N9x9TDnnIqG4kdsk1XFA/V +t9PMo3yvj0q//m71KLOrHb1ft6qZWcrzSDK79ofkTS09UV9rI9ba1/Y2e71Mwfh7dG+ H9R8/Gg0A7s8hRDceH9YHgCPzcVRSpnzDFcrVsjELNn+B0Yd7yYXxypmIri/ahJ6eyus yUVZmsodZA16p/xDjC8xzFxLmA/uanYjjrjPU5Ais/DGrufKuuR5hSeaqXiJ/S7W3LRl jmV8qJHW/HgpvYyp+XLXieeT28xxIku5jbcjX6L7+44ttW8VRlmuWgYU17PtvZNauTaY yhNg== MIME-Version: 1.0 Received: by 10.60.19.37 with SMTP id b5mr4576875oee.35.1331929084571; Fri, 16 Mar 2012 13:18:04 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 13:18:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Mar 2012 16:18:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Myers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Santesson , pkix Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 16 Mar 2012 20:18:06 -0000 +1 This is a lookup in a database and hence an OCSP feature. On Fri, Mar 16, 2012 at 2:42 PM, Michael Myers wrote: > > On Mar 16, 2012, at 9:59 AM, Stefan Santesson wrote: > >> Basically, if users of OCSP need to extend the functionality of OCSP in = a >> way where some functionally may come to overlap with functionality >> provided by SCVP, then should we allow that overlap or force those with >> such need to implement SCVP? > > > Okay. =A0Then in that context, as lead author of OCSP and having particip= ated > in the genesis of SCVP, here's what I would advise the WG, were I standin= g > at a microphone in Paris. > > If the emergent need fundamentally involves online, dynamic policy > coherence, it goes to SCVP. =A0If the need is simply what's the value of = a > given field in a database, it goes to OCSP. =A0Recall that SCVP is design= ed to > incorporate OCSP input, so there's no inherent overlap. =A0OCSP could ver= y > well be one among several back channels feeding into an SCVP service. > > For example, I intended the cert status value of 'unknown' to be simply > that--the queried OCSP responder has no extant data regarding the subject > certificate. =A0Maybe it was issued somewhere, somehow, by somebody, but = that > particular certID doesn't show up in that particular responder's collecti= on > of data regarding certificates for which it claims to be authoritative. > > However, if someone or some entity sought to delegate a scope of authorit= y > to a TTP regarding the authoritative issuance or lack thereof regarding a > particular certificate, well, there's very likely a bits-on-the-wire poli= cy > component associated with that interaction. =A0The crucial aspect of whic= h > would likely be that the TTP takes the hit if they (it) produces a false > response the requester nonetheless relies upon before taking a > security-relevant action. > > I make the distinguishing point about policy and delegation because, as s= ome > of us may recall, SCVP came about from proposed extensions to OCSP regard= ing > Delegated Path Validation and Delegated Path Discovery. =A0Which led to i= ssues > regarding policy coherence between requester and responder. =A0Which led = to > SCVP. > > I shall now step away from the virtual microphone. > > > Mike > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hotz@jpl.nasa.gov Fri Mar 16 13:21:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CF221E8059 for ; Fri, 16 Mar 2012 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c0rofcFn4fc for ; Fri, 16 Mar 2012 13:21:20 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 34FC221E8048 for ; Fri, 16 Mar 2012 13:21:20 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2GKLEUi010289 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Mar 2012 13:21:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Fri, 16 Mar 2012 13:21:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1676FB50-5C25-438E-B93F-DF5BA0996BA1@jpl.nasa.gov> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 20:21:20 -0000 On Mar 16, 2012, at 12:43 PM, Phillip Hallam-Baker wrote: > Oh is that what he is worrying about? Well, it's what *I*'m worried about. Stephen can speak for himself. I = don't think the practical validation problem is unique to web/TLS = though. ------------------------------------------------------ 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 hallam@gmail.com Fri Mar 16 13:28:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF72721F8581 for ; Fri, 16 Mar 2012 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEYY8MoEEhjZ for ; Fri, 16 Mar 2012 13:28:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5E21F857A for ; Fri, 16 Mar 2012 13:28:53 -0700 (PDT) Received: by ggmi1 with SMTP id i1so5264120ggm.31 for ; Fri, 16 Mar 2012 13:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tXEa2l6/FiEh4Iu9sI++9rV8i73ejHizCV5k298uOJ4=; b=HzMwbi8n8DFrQUVSJCgFh4WQIeaTyY+z5zGxtykX4sZ9Gp4YEsk5JBUJr2klLJvpKV Oj//pbPrGIZjeImXcZNCxR+d3Bb8nZ5ibbTTzrx8U0D1rCwDnfUVmXE/JFB8UIXymPxb cGJOaUJ+Af/yDbk0M8tvhPUTmfkWl5egxxx1z+PQZ+cxTmFyqWZoKZBY2t9zkS/fhIxq SVmd1dI87h40Qt8ed9HjgYKs9/5G9L+sdNSyXGa54/ifs8O0jcXPW3ONZfF1x5bIbGOL bGkFRZXIgVEnOIgG8kiUVq13nxaqmlPYww9BciTxAmsvnJr4N7oColBfhLKv+W15DRUU D0rg== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr4666661oeg.15.1331929733559; Fri, 16 Mar 2012 13:28:53 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 13:28:53 -0700 (PDT) In-Reply-To: <1676FB50-5C25-438E-B93F-DF5BA0996BA1@jpl.nasa.gov> References: <1676FB50-5C25-438E-B93F-DF5BA0996BA1@jpl.nasa.gov> Date: Fri, 16 Mar 2012 16:28:53 -0400 Message-ID: From: Phillip Hallam-Baker To: "Henry B. Hotz" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 20:28:54 -0000 Me too, I just can't see how recent events are going to get engineers excited about implementing a 10 year old protocol that is pretty tightly bound to PKIX and a rather specific view of PKIX at that. If we are going to get a trust broker protocol deployed we are going to have to meet the Google criteria that it improve, not harm response time. So the only deployable approach I can see is to combine the trust resolution request with the name resolution request. Knowing more about the validity of the certificate seems rather superfluous to me when I have no authoritative or reliable means of knowing if the connection should use SSL (other than cached previous interactions). On Fri, Mar 16, 2012 at 4:21 PM, Henry B. Hotz wrote: > On Mar 16, 2012, at 12:43 PM, Phillip Hallam-Baker wrote: > >> Oh is that what he is worrying about? > > Well, it's what *I*'m worried about. =A0Stephen can speak for himself. = =A0I don't think the practical validation problem is unique to web/TLS thou= gh. > ------------------------------------------------------ > 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 Website: http://hallambaker.com/ From piyush@identicate.com Fri Mar 16 13:32:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05721F85AA for ; Fri, 16 Mar 2012 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsYAzn6vdmTj for ; Fri, 16 Mar 2012 13:32:08 -0700 (PDT) Received: from col0-omc4-s14.col0.hotmail.com (col0-omc4-s14.col0.hotmail.com [65.55.34.216]) by ietfa.amsl.com (Postfix) with ESMTP id 731C221F85A8 for ; Fri, 16 Mar 2012 13:32:08 -0700 (PDT) Received: from COL119-W62 ([65.55.34.201]) by col0-omc4-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 13:32:07 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_dfb30bce-1f7b-4809-8ffe-1c4fb8c21d6a_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Fri, 16 Mar 2012 13:32:07 -0700 Importance: Normal In-Reply-To: References: , <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org>, , , <4F63838C.4090408@nist.gov>, MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2012 20:32:07.0826 (UTC) FILETIME=[DB61C720:01CD03B3] Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:32:09 -0000 --_dfb30bce-1f7b-4809-8ffe-1c4fb8c21d6a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: hotz@jpl.nasa.gov > Date: Fri=2C 16 Mar 2012 12:38:42 -0700 > To: david.cooper@nist.gov > CC: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response >=20 > Can I turn the question around and ask why adding a 'does not exist' resp= onse would be bad? >=20 > To answer your question more directly=2C I think there are scenarios that= could most easily be addressed if such a response could be provided. Just= because it doesn't solve all the problems doesn't mean it isn't a useful i= mprovement. It may be useful to describe those scenarios and have a discussion around h= ow 'does not exist' would help.Barring the mention of one case of partial C= A compromise=2C I don't recall that any other use cases that were discussed= .=20 The fundamental problem here is that if the relying party doubts the signat= ure on a cert signed by a CA=2C how can it trust the response from a respon= der delegated by the CA.From an attacker's point of view=2C If i have compr= omised the CA=2C then I won't stop at issuing the EE cert=2C I would issue= myself a responder cert as well. >=20 > Obviously your concerns should be covered by the security considerations = of any description of the extension. >=20 > On Mar 16=2C 2012=2C at 11:16 AM=2C David A. Cooper wrote: >=20 > > Phil=2C > >=20 > > The supposed advantages of adding a 'does not exist' response continue= =20 > > to elude me. Back in November I explained in detail why I didn't=20 > > believe that adding this new response would provide much in the way of= =20 > > additional security=2C and if anything might only create a false sense = of=20 > > security (see=20 > > http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). I=20 > > only received two responses to my message=2C and both were proposing=20 > > substantial changes to the PKI trust architecture=2C and neither suppor= ted=20 > > the idea that adding a 'does not exist' status response (without making= =20 > > other significant changes) would provide a significant advantage. >=20 > ------------------------------------------------------ > The opinions expressed in this message are mine=2C > not those of Caltech=2C JPL=2C NASA=2C or the US Government. > Henry.B.Hotz@jpl.nasa.gov=2C or hbhotz@oxy.edu >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_dfb30bce-1f7b-4809-8ffe-1c4fb8c21d6a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: hotz@jpl.na= sa.gov
>=3B Date: Fri=2C 16 Mar 2012 12:38:42 -0700
>=3B To: davi= d.cooper@nist.gov
>=3B CC: pkix@ietf.org
>=3B Subject: Re: [pkix]= certificate not issued OCSP status response
>=3B
>=3B Can I tur= n the question around and ask why adding a 'does not exist' response would = be bad?
>=3B
>=3B To answer your question more directly=2C I thi= nk there are scenarios that could most easily be addressed if such a respon= se could be provided. Just because it doesn't solve all the problems doesn= 't mean it isn't a useful improvement.

It may be u= seful to describe those scenarios and have a discussion around how 'does no= t exist' would help.
Barring the mention of one case of partial C= A compromise=2C I don't recall that any other use cases that were discussed= . =3B

The fundamental problem here is that if = the relying party doubts the signature on a cert signed by a CA=2C how can = it trust the response from a responder delegated by the CA.
From = an attacker's point of view=2C If i have compromised the  =3BCA=2C then= I won't stop at issuing the EE cert=2C I would issue myself a responder ce= rt as well.

>=3B
>=3B Obviously your concerns should = be covered by the security considerations of any description of the extensi= on.
>=3B
>=3B On Mar 16=2C 2012=2C at 11:16 AM=2C David A. Coope= r wrote:
>=3B
>=3B >=3B Phil=2C
>=3B >=3B
>=3B &g= t=3B The supposed advantages of adding a 'does not exist' response continue=
>=3B >=3B to elude me. Back in November I explained in detail why= I didn't
>=3B >=3B believe that adding this new response would pro= vide much in the way of
>=3B >=3B additional security=2C and if any= thing might only create a false sense of
>=3B >=3B security (see >=3B >=3B http://www.ietf.org/mail-archive/web/pkix/current/msg29983.= html). I
>=3B >=3B only received two responses to my message=2C an= d both were proposing
>=3B >=3B substantial changes to the PKI trus= t architecture=2C and neither supported
>=3B >=3B the idea that add= ing a 'does not exist' status response (without making
>=3B >=3B ot= her significant changes) would provide a significant advantage.
>=3B <= br>>=3B ------------------------------------------------------
>=3B = The opinions expressed in this message are mine=2C
>=3B not those of C= altech=2C JPL=2C NASA=2C or the US Government.
>=3B Henry.B.Hotz@jpl.n= asa.gov=2C or hbhotz@oxy.edu
>=3B
>=3B _________________________= ______________________
>=3B pkix mailing list
>=3B pkix@ietf.org<= br>>=3B https://www.ietf.org/mailman/listinfo/pkix
<= /div> = --_dfb30bce-1f7b-4809-8ffe-1c4fb8c21d6a_-- From hallam@gmail.com Fri Mar 16 13:40:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1121E803E for ; Fri, 16 Mar 2012 13:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2AIfTlxPDnG for ; Fri, 16 Mar 2012 13:40:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9632221E8024 for ; Fri, 16 Mar 2012 13:40:35 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5278763ghb.31 for ; Fri, 16 Mar 2012 13:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JMdtIICbvGighT+t2Q74GroxoEf4lKGWn+gkdSkAUz4=; b=cKOIIuiCLJmSi5mJLeWBkKQRQwC/QxazthyIVtL51ekL9oUHNd7mSEoMxuxleTZeTv Ld/MtFx7f1BHysVDRpnfzl/Cjcku8d3GDXpT3ZBl8UfMCiptL6oXHRYbgeYXRg1oaPfi 3+dL6nOTt2+GiKA9qnYZuf/bDBNFLim03SS1wzOr2N1lI/ouGnswx03rbAJrgJJFUIjx o/AWyFubSppp3ogLaW0CABa8KfG9pNOIqfvvNdD7mOrXoTrnyAjezMw96Zpnx2AzTWre zhqS1ZEMX4W57B8Yzh2vdjMzFjSuV3PhnuWHnW5rVbmthfrhWvATYzqtNDQoErS4/wsl ZSZQ== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr5161389obc.15.1331930435081; Fri, 16 Mar 2012 13:40:35 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 13:40:35 -0700 (PDT) In-Reply-To: <4F63838C.4090408@nist.gov> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 16:40:35 -0400 Message-ID: From: Phillip Hallam-Baker To: "David A. Cooper" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:40:36 -0000 The advantage is that it allows external parties to determine that a total compromise has occurred and defenestrate the root. So in the DigiNotar case there were three separate problems 1) The CA was completely breached and issued false certificates that the CA had no record of 2) A significant time elapsed before the CA was aware that the breach had occurred 3) An even longer time elapsed before the breach was independently discovered and remediation efforts could start. Now with the proposed scheme the attacker can still issue false certificates but any attempt to cover their tracks by deleting the log files will result in the CA issuing the OCSP status 'Does not exist' and cause the breach to be observable externally. Contrawise if they do not delete the logs, the CA will have a record of the bogus certs that were issued. In the past it was considered axiomatic that a CA will never ever be breached. Now we have to address that as a possibility and deploy mechanisms that can detect that eventuality. On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper wr= ote: > Phil, > > The supposed advantages of adding a 'does not exist' response continue to > elude me. =A0Back in November I explained in detail why I didn't believe = that > adding this new response would provide much in the way of additional > security, and if anything might only create a false sense of security (se= e > http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). =A0I on= ly > received two responses to my message, and both were proposing substantial > changes to the PKI trust architecture, and neither supported the idea tha= t > adding a 'does not exist' status response (without making other significa= nt > changes) would provide a significant advantage. > > So, could you respond to my earlier message and explain why simply adding= a > 'does not exist' status does more than provide a false sense of added > confidence? > > Dave > > > On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >> >> Denis, >> >> I agree with the points you raise but: >> >> 1) The whole purpose of this proposal is to enable a re-engineering of >> CA architecture so that we eliminate 'single break' systems. At the >> moment there is only a modest security advantage to separating out the >> OCSP HSM from the cert signing HSM, but as your analysis shows having >> a strong response for 'does not exist' changes that. >> >> 2) SCVP is complicated because the problem it solves is very complex. >> The problem of enabling a 'does not exist' certificate status is much >> simpler and a direct and logical extension of what OCSP already does. >> >> >> On Fri, Mar 16, 2012 at 12:23 PM, =A0wrote: >>> >>> Paul, >>> >>> I agree with you that it is possible to extend OCSP, as long as >>> additional >>> status information is related to information >>> available by the CA that has issued the certificate. In particular, sin= ce >>> CRL is a "black list" mechanism, OCSP is able >>> to use a "white list" mechanism. This is where "not issued" has a >>> meaning. >>> >>> However, the benefit of using a white list mechanism is only a small >>> advantage in case the CA is compromised. >>> If everything has been compromised in the CA premises, then there is no >>> =A0advantage at all. >>> >>> The only advantage is when the CA compromission is only partial and whe= n >>> the >>> forged certificate >>> has not been able to be included in the log of issued certificates. >>> >>> For example, the HSM has been used directly to create a forged >>> certificate. >>> >>> The danger is that people might think that white list mechanisms are mu= ch >>> better than black list mechanisms, >>> whereas this is not as straight. >>> >>> Denis >>> >>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence why >>> it >>> is and will not be not widely deployed. >>> >>> PS 2. the previous message was sent before my message was finished. >>> >>> >>> >>> >>> De : =A0 =A0 =A0 =A0Paul Hoffman >>> A : =A0 =A0 =A0 =A0Phillip Hallam-Baker >>> Cc : =A0 =A0 =A0 =A0pkix@ietf.org >>> Date : =A0 =A0 =A0 =A016/03/2012 16:27 >>> Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to HISTORIC >>> Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org >>> ________________________________ >>> >>> >>> >>> You earlier asked if anyone used SCVP, and there was the answer: >>> >>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. N= o >>>> public CAs use it. >>> >>> It is irresponsible for a public CA to request a protocol that is known >>> to >>> be deployed to be moved to Historic simply because companies like itsel= f >>> do >>> not use it, even if other entities are known to use it. The PKIX WG mak= es >>> protocols that are useful to a wide range of entities, not just public >>> CAs. >>> >>> Having said that, I disagree with Steve Kent's argument that if somethi= ng >>> is >>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill th= at >>> any status of a certificate, including that it was not issues or is >>> expired, >>> is still status and should be able to be represented in a well-deployed >>> protocol such as OCSP. >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> > --=20 Website: http://hallambaker.com/ From SChokhani@cygnacom.com Fri Mar 16 13:50:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BFB21F85F9 for ; Fri, 16 Mar 2012 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeNA-+jW+MAV for ; Fri, 16 Mar 2012 13:50:32 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id A546321F85FB for ; Fri, 16 Mar 2012 13:50:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,599,1325480400"; d="scan'208";a="579311" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 16 Mar 2012 16:50:29 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 16 Mar 2012 16:50:29 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker , "David A. Cooper" Date: Fri, 16 Mar 2012 16:50:27 -0400 Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: Ac0DtRDJhGlUm+cZT5qwtXoVKhx8NQAAR8Tw Message-ID: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:50:46 -0000 PHB never disappoints me in his understanding (or shall I say lack thereof)= when it comes to security. If the CA is compromised, the attacker will issue a delegated OCSP certific= ate and put that pointer in the certificate that the attacker minted. It d= oes not even have to do DNS poisoning to point to a rogue responder. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phi= llip Hallam-Baker Sent: Friday, March 16, 2012 4:41 PM To: David A. Cooper Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response The advantage is that it allows external parties to determine that a total = compromise has occurred and defenestrate the root. So in the DigiNotar case there were three separate problems 1) The CA was completely breached and issued false certificates that the CA= had no record of 2) A significant time elapsed before the CA was aware that the breach had o= ccurred 3) An even longer time elapsed before the breach was independently discover= ed and remediation efforts could start. Now with the proposed scheme the attacker can still issue false certificate= s but any attempt to cover their tracks by deleting the log files will resu= lt in the CA issuing the OCSP status 'Does not exist' and cause the breach to be observable externally. Contrawise if they do not= delete the logs, the CA will have a record of the bogus certs that were is= sued. In the past it was considered axiomatic that a CA will never ever be breach= ed. Now we have to address that as a possibility and deploy mechanisms that= can detect that eventuality. On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper wr= ote: > Phil, > > The supposed advantages of adding a 'does not exist' response continue=20 > to elude me. =A0Back in November I explained in detail why I didn't=20 > believe that adding this new response would provide much in the way of=20 > additional security, and if anything might only create a false sense=20 > of security (see=20 > http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). =A0I=20 > only received two responses to my message, and both were proposing=20 > substantial changes to the PKI trust architecture, and neither=20 > supported the idea that adding a 'does not exist' status response=20 > (without making other significant > changes) would provide a significant advantage. > > So, could you respond to my earlier message and explain why simply=20 > adding a 'does not exist' status does more than provide a false sense=20 > of added confidence? > > Dave > > > On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >> >> Denis, >> >> I agree with the points you raise but: >> >> 1) The whole purpose of this proposal is to enable a re-engineering=20 >> of CA architecture so that we eliminate 'single break' systems. At=20 >> the moment there is only a modest security advantage to separating=20 >> out the OCSP HSM from the cert signing HSM, but as your analysis=20 >> shows having a strong response for 'does not exist' changes that. >> >> 2) SCVP is complicated because the problem it solves is very complex. >> The problem of enabling a 'does not exist' certificate status is much=20 >> simpler and a direct and logical extension of what OCSP already does. >> >> >> On Fri, Mar 16, 2012 at 12:23 PM, =A0wrote: >>> >>> Paul, >>> >>> I agree with you that it is possible to extend OCSP, as long as=20 >>> additional status information is related to information available by=20 >>> the CA that has issued the certificate. In particular, since CRL is=20 >>> a "black list" mechanism, OCSP is able to use a "white list"=20 >>> mechanism. This is where "not issued" has a meaning. >>> >>> However, the benefit of using a white list mechanism is only a small=20 >>> advantage in case the CA is compromised. >>> If everything has been compromised in the CA premises, then there is=20 >>> no >>> =A0advantage at all. >>> >>> The only advantage is when the CA compromission is only partial and=20 >>> when the forged certificate has not been able to be included in the=20 >>> log of issued certificates. >>> >>> For example, the HSM has been used directly to create a forged=20 >>> certificate. >>> >>> The danger is that people might think that white list mechanisms are=20 >>> much better than black list mechanisms, whereas this is not as=20 >>> straight. >>> >>> Denis >>> >>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence=20 >>> why it is and will not be not widely deployed. >>> >>> PS 2. the previous message was sent before my message was finished. >>> >>> >>> >>> >>> De : =A0 =A0 =A0 =A0Paul Hoffman A : =A0 =A0 =A0= =A0Phillip=20 >>> Hallam-Baker Cc : =A0 =A0 =A0 =A0pkix@ietf.org Date := =A0 =A0 =A0 =A0 >>> 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to=20 >>> HISTORIC Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org=20 >>> ________________________________ >>> >>> >>> >>> You earlier asked if anyone used SCVP, and there was the answer: >>> >>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. N= o >>>> public CAs use it. >>> >>> It is irresponsible for a public CA to request a protocol that is known >>> to >>> be deployed to be moved to Historic simply because companies like itsel= f >>> do >>> not use it, even if other entities are known to use it. The PKIX WG mak= es >>> protocols that are useful to a wide range of entities, not just public >>> CAs. >>> >>> Having said that, I disagree with Steve Kent's argument that if somethi= ng >>> is >>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill th= at >>> any status of a certificate, including that it was not issues or is >>> expired, >>> is still status and should be able to be represented in a well-deployed >>> protocol such as OCSP. >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> > --=20 Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Fri Mar 16 14:06:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0421E8084 for ; Fri, 16 Mar 2012 14:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT4+ZJzPcXo5 for ; Fri, 16 Mar 2012 14:06:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19C21E8083 for ; Fri, 16 Mar 2012 14:06:24 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2245674yhk.31 for ; Fri, 16 Mar 2012 14:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=L7ecvwMUxB7Nze8mb+XD04j5YUSY0rIt8tbLAf8lJNs=; b=r0UJGVz1TGgqDE4Tp3SezwadbWPwP4+yjsXRME94f99rbRtNbW4EEwqtZqQoAPjKxT qk2wac3jRfNc8dRCcELCMvbYc60jARI+0KM7A1EL5MoQGVDxqzqDmAMb8aLO3VbqglBQ MnfVdkqU+Kb2BFmz01jycXGGa7Y4NIPUBLqr5p79jR71R4PUyDNOmLasDL28KN8hnvek eQFFQ9H9nL3m6pknaVGc5KDQPBJnfIyAI9fck/xPrSeZ+vAEbf8z1TG7YoXo2CRg2jmS 4AvzvzvwcnaUAaO4hueo5nWog9sJ0bMnGld0mR0+nn4BOom16YA0pdDx163iA21JbaFT Rabg== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr5241602obc.15.1331931983708; Fri, 16 Mar 2012 14:06:23 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 14:06:23 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 17:06:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:06:25 -0000 That might have been a good point if you hadn't started with a personal ins= ult. The mere fact that a feature is in PKIX does not mean we have to allow its use. Clearly any observational feedback system (e.g. EFF Observatory, Convergence) would look for such a certificate and flag it as unusual. But given the circumstances you cite, wouldn't the much easier path be for the attacker to simply issue themselves a cross certificate with cert signing capability? In real life an attacker would be rather unlikely to favor that approach because it would likely trigger secondary controls within the CA that are there to detect certs with the cert signing bit set. Your post tells me that I should consider this particular PKIX feature as another red flag (but my controls tend to describe what is strictly allowed rather than denied in any case). On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani wrote: > PHB never disappoints me in his understanding (or shall I say lack thereo= f) when it comes to security. > > If the CA is compromised, the attacker will issue a delegated OCSP certif= icate and put that pointer in the certificate that the attacker minted. =A0= It does not even have to do DNS poisoning to point to a rogue responder. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of P= hillip Hallam-Baker > Sent: Friday, March 16, 2012 4:41 PM > To: David A. Cooper > Cc: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response > > The advantage is that it allows external parties to determine that a tota= l compromise has occurred and defenestrate the root. > > So in the DigiNotar case there were three separate problems > > 1) The CA was completely breached and issued false certificates that the = CA had no record of > 2) A significant time elapsed before the CA was aware that the breach had= occurred > 3) An even longer time elapsed before the breach was independently discov= ered and remediation efforts could start. > > Now with the proposed scheme the attacker can still issue false certifica= tes but any attempt to cover their tracks by deleting the log files will re= sult in the CA issuing the OCSP status 'Does not exist' > and cause the breach to be observable externally. Contrawise if they do n= ot delete the logs, the CA will have a record of the bogus certs that were = issued. > > In the past it was considered axiomatic that a CA will never ever be brea= ched. Now we have to address that as a possibility and deploy mechanisms th= at can detect that eventuality. > > > On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper = wrote: >> Phil, >> >> The supposed advantages of adding a 'does not exist' response continue >> to elude me. =A0Back in November I explained in detail why I didn't >> believe that adding this new response would provide much in the way of >> additional security, and if anything might only create a false sense >> of security (see >> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). =A0I >> only received two responses to my message, and both were proposing >> substantial changes to the PKI trust architecture, and neither >> supported the idea that adding a 'does not exist' status response >> (without making other significant >> changes) would provide a significant advantage. >> >> So, could you respond to my earlier message and explain why simply >> adding a 'does not exist' status does more than provide a false sense >> of added confidence? >> >> Dave >> >> >> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >>> >>> Denis, >>> >>> I agree with the points you raise but: >>> >>> 1) The whole purpose of this proposal is to enable a re-engineering >>> of CA architecture so that we eliminate 'single break' systems. At >>> the moment there is only a modest security advantage to separating >>> out the OCSP HSM from the cert signing HSM, but as your analysis >>> shows having a strong response for 'does not exist' changes that. >>> >>> 2) SCVP is complicated because the problem it solves is very complex. >>> The problem of enabling a 'does not exist' certificate status is much >>> simpler and a direct and logical extension of what OCSP already does. >>> >>> >>> On Fri, Mar 16, 2012 at 12:23 PM, =A0wrote: >>>> >>>> Paul, >>>> >>>> I agree with you that it is possible to extend OCSP, as long as >>>> additional status information is related to information available by >>>> the CA that has issued the certificate. In particular, since CRL is >>>> a "black list" mechanism, OCSP is able to use a "white list" >>>> mechanism. This is where "not issued" has a meaning. >>>> >>>> However, the benefit of using a white list mechanism is only a small >>>> advantage in case the CA is compromised. >>>> If everything has been compromised in the CA premises, then there is >>>> no >>>> =A0advantage at all. >>>> >>>> The only advantage is when the CA compromission is only partial and >>>> when the forged certificate has not been able to be included in the >>>> log of issued certificates. >>>> >>>> For example, the HSM has been used directly to create a forged >>>> certificate. >>>> >>>> The danger is that people might think that white list mechanisms are >>>> much better than black list mechanisms, whereas this is not as >>>> straight. >>>> >>>> Denis >>>> >>>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence >>>> why it is and will not be not widely deployed. >>>> >>>> PS 2. the previous message was sent before my message was finished. >>>> >>>> >>>> >>>> >>>> De : =A0 =A0 =A0 =A0Paul Hoffman A : =A0 =A0 = =A0 =A0Phillip >>>> Hallam-Baker Cc : =A0 =A0 =A0 =A0pkix@ietf.org Date = : >>>> 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to >>>> HISTORIC Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org >>>> ________________________________ >>>> >>>> >>>> >>>> You earlier asked if anyone used SCVP, and there was the answer: >>>> >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. = No >>>>> public CAs use it. >>>> >>>> It is irresponsible for a public CA to request a protocol that is know= n >>>> to >>>> be deployed to be moved to Historic simply because companies like itse= lf >>>> do >>>> not use it, even if other entities are known to use it. The PKIX WG ma= kes >>>> protocols that are useful to a wide range of entities, not just public >>>> CAs. >>>> >>>> Having said that, I disagree with Steve Kent's argument that if someth= ing >>>> is >>>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill t= hat >>>> any status of a certificate, including that it was not issues or is >>>> expired, >>>> is still status and should be able to be represented in a well-deploye= d >>>> protocol such as OCSP. >>>> >>>> --Paul Hoffman >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From brennansecurity@gmail.com Fri Mar 16 14:18:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9A21E807C for ; Fri, 16 Mar 2012 14:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVUcNdFd-1T3 for ; Fri, 16 Mar 2012 14:18:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D042E21E801A for ; Fri, 16 Mar 2012 14:18:25 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5730860vcb.31 for ; Fri, 16 Mar 2012 14:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c4QxWFj+kuc4E1aHz22qtpTUs6xwhOWKoxzERutzV6o=; b=SeglfYc2nqQvhjHbRexT+brz0CvmFTcFoBVtQl5h+z8+wXqY0DnVhZ9kOXPvKpxdMj DnELePhzMdWrVGOTFJyXOUeSoZRgUi6BJFIMq0Kp5oU60mBb3+qfE4DrwkaWBC6MNgYo hIZytF3hKTwXCRiaqtPOYMj77NTbMqacrJWsq3ub2U60tZRTyXKQeqLrx0825b/GPzDh ULjC7vn6lw7msGEM66vZcD3yukkrc7PSH/5M9yzfGtXL0FIF8lD3I3QYvpV5NmgKt/y8 EJ+zl19CWkFRfIOc5CbeLi56jznhAn0+tl0zNtY37mH2XmeUtbl4slhGK32+e3vG2oQI 07dQ== MIME-Version: 1.0 Received: by 10.52.93.74 with SMTP id cs10mr2056998vdb.42.1331932705251; Fri, 16 Mar 2012 14:18:25 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Fri, 16 Mar 2012 14:18:24 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 17:18:24 -0400 Message-ID: From: brennan security To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=bcaec5016739c2e21604bb62bfcf Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:18:27 -0000 --bcaec5016739c2e21604bb62bfcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Other OCSP modes would be resistant to a CA compromise also (direct trust, CA designated, VA Designated). Many companies and large enterprises are already doing the CA designated/VA designated route. I've also been considering an alternative PKI model as a significant aid - for example a GPG/PGP signature on Root CAs, sub CAs, and signing Certs. -b On Fri, Mar 16, 2012 at 5:06 PM, Phillip Hallam-Baker wro= te: > That might have been a good point if you hadn't started with a personal > insult. > > > The mere fact that a feature is in PKIX does not mean we have to allow > its use. Clearly any observational feedback system (e.g. EFF > Observatory, Convergence) would look for such a certificate and flag > it as unusual. > > But given the circumstances you cite, wouldn't the much easier path be > for the attacker to simply issue themselves a cross certificate with > cert signing capability? > > In real life an attacker would be rather unlikely to favor that > approach because it would likely trigger secondary controls within the > CA that are there to detect certs with the cert signing bit set. Your > post tells me that I should consider this particular PKIX feature as > another red flag (but my controls tend to describe what is strictly > allowed rather than denied in any case). > > > > > On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani > wrote: > > PHB never disappoints me in his understanding (or shall I say lack > thereof) when it comes to security. > > > > If the CA is compromised, the attacker will issue a delegated OCSP > certificate and put that pointer in the certificate that the attacker > minted. It does not even have to do DNS poisoning to point to a rogue > responder. > > > > -----Original Message----- > > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Phillip Hallam-Baker > > Sent: Friday, March 16, 2012 4:41 PM > > To: David A. Cooper > > Cc: pkix@ietf.org > > Subject: Re: [pkix] certificate not issued OCSP status response > > > > The advantage is that it allows external parties to determine that a > total compromise has occurred and defenestrate the root. > > > > So in the DigiNotar case there were three separate problems > > > > 1) The CA was completely breached and issued false certificates that th= e > CA had no record of > > 2) A significant time elapsed before the CA was aware that the breach > had occurred > > 3) An even longer time elapsed before the breach was independently > discovered and remediation efforts could start. > > > > Now with the proposed scheme the attacker can still issue false > certificates but any attempt to cover their tracks by deleting the log > files will result in the CA issuing the OCSP status 'Does not exist' > > and cause the breach to be observable externally. Contrawise if they do > not delete the logs, the CA will have a record of the bogus certs that we= re > issued. > > > > In the past it was considered axiomatic that a CA will never ever be > breached. Now we have to address that as a possibility and deploy > mechanisms that can detect that eventuality. > > > > > > On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper > wrote: > >> Phil, > >> > >> The supposed advantages of adding a 'does not exist' response continue > >> to elude me. Back in November I explained in detail why I didn't > >> believe that adding this new response would provide much in the way of > >> additional security, and if anything might only create a false sense > >> of security (see > >> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). I > >> only received two responses to my message, and both were proposing > >> substantial changes to the PKI trust architecture, and neither > >> supported the idea that adding a 'does not exist' status response > >> (without making other significant > >> changes) would provide a significant advantage. > >> > >> So, could you respond to my earlier message and explain why simply > >> adding a 'does not exist' status does more than provide a false sense > >> of added confidence? > >> > >> Dave > >> > >> > >> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: > >>> > >>> Denis, > >>> > >>> I agree with the points you raise but: > >>> > >>> 1) The whole purpose of this proposal is to enable a re-engineering > >>> of CA architecture so that we eliminate 'single break' systems. At > >>> the moment there is only a modest security advantage to separating > >>> out the OCSP HSM from the cert signing HSM, but as your analysis > >>> shows having a strong response for 'does not exist' changes that. > >>> > >>> 2) SCVP is complicated because the problem it solves is very complex. > >>> The problem of enabling a 'does not exist' certificate status is much > >>> simpler and a direct and logical extension of what OCSP already does. > >>> > >>> > >>> On Fri, Mar 16, 2012 at 12:23 PM, wrote: > >>>> > >>>> Paul, > >>>> > >>>> I agree with you that it is possible to extend OCSP, as long as > >>>> additional status information is related to information available by > >>>> the CA that has issued the certificate. In particular, since CRL is > >>>> a "black list" mechanism, OCSP is able to use a "white list" > >>>> mechanism. This is where "not issued" has a meaning. > >>>> > >>>> However, the benefit of using a white list mechanism is only a small > >>>> advantage in case the CA is compromised. > >>>> If everything has been compromised in the CA premises, then there is > >>>> no > >>>> advantage at all. > >>>> > >>>> The only advantage is when the CA compromission is only partial and > >>>> when the forged certificate has not been able to be included in the > >>>> log of issued certificates. > >>>> > >>>> For example, the HSM has been used directly to create a forged > >>>> certificate. > >>>> > >>>> The danger is that people might think that white list mechanisms are > >>>> much better than black list mechanisms, whereas this is not as > >>>> straight. > >>>> > >>>> Denis > >>>> > >>>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence > >>>> why it is and will not be not widely deployed. > >>>> > >>>> PS 2. the previous message was sent before my message was finished. > >>>> > >>>> > >>>> > >>>> > >>>> De : Paul Hoffman A : Phillip > >>>> Hallam-Baker Cc : pkix@ietf.org Date : > >>>> 16/03/2012 16:27 Objet : Re: [pkix] PROPOSAL: SCVP to > >>>> HISTORIC Envoy=E9 par : pkix-bounces@ietf.org > >>>> ________________________________ > >>>> > >>>> > >>>> > >>>> You earlier asked if anyone used SCVP, and there was the answer: > >>>> > >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments= . > No > >>>>> public CAs use it. > >>>> > >>>> It is irresponsible for a public CA to request a protocol that is > known > >>>> to > >>>> be deployed to be moved to Historic simply because companies like > itself > >>>> do > >>>> not use it, even if other entities are known to use it. The PKIX WG > makes > >>>> protocols that are useful to a wide range of entities, not just publ= ic > >>>> CAs. > >>>> > >>>> Having said that, I disagree with Steve Kent's argument that if > something > >>>> is > >>>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill > that > >>>> any status of a certificate, including that it was not issues or is > >>>> expired, > >>>> is still status and should be able to be represented in a > well-deployed > >>>> protocol such as OCSP. > >>>> > >>>> --Paul Hoffman > >>>> > >>>> _______________________________________________ > >>>> 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 > >>>> > >>> > >>> > >> > > > > > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --bcaec5016739c2e21604bb62bfcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Other OCSP modes would be resistant to a CA compromise also (direct trust, = CA designated, VA Designated).

Many companies and large enterprises = are already doing the CA designated/VA designated route.

I've al= so been considering an alternative PKI model as a significant aid - for exa= mple a GPG/PGP signature on Root CAs, sub CAs, and signing Certs.

-b

On Fri, Mar 16, 2012 at 5:06 PM, P= hillip Hallam-Baker <hallam@gmail.com> wrote:
That might have been a good point if you hadn't started with a personal= insult.


The mere fact that a feature is in PKIX does not mean we have to allow
its use. Clearly any observational feedback system (e.g. EFF
Observatory, Convergence) would look for such a certificate and flag
it as unusual.

But given the circumstances you cite, wouldn't the much easier path be<= br> for the attacker to simply issue themselves a cross certificate with
cert signing capability?

In real life an attacker would be rather unlikely to favor that
approach because it would likely trigger secondary controls within the
CA that are there to detect certs with the cert signing bit set. Your
post tells me that I should consider this particular PKIX feature as
another red flag (but my controls tend to describe what is strictly
allowed rather than denied in any case).




On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani
<SChokhani@cygnacom.com>= ; wrote:
> PHB never disappoints me in his understanding (or shall I say lack the= reof) when it comes to security.
>
> If the CA is compromised, the attacker will issue a delegated OCSP cer= tificate and put that pointer in the certificate that the attacker minted. = =A0It does not even have to do DNS poisoning to point to a rogue responder.=
>
> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
> Sent: Friday, March 16, 2012 4:41 PM
> To: David A. Cooper
> Cc: pkix@ietf.org
> Subject: Re: [pkix] certificate not issued OCSP status response
>
> The advantage is that it allows external parties to determine that a t= otal compromise has occurred and defenestrate the root.
>
> So in the DigiNotar case there were three separate problems
>
> 1) The CA was completely breached and issued false certificates that t= he CA had no record of
> 2) A significant time elapsed before the CA was aware that the breach = had occurred
> 3) An even longer time elapsed before the breach was independently dis= covered and remediation efforts could start.
>
> Now with the proposed scheme the attacker can still issue false certif= icates but any attempt to cover their tracks by deleting the log files will= result in the CA issuing the OCSP status 'Does not exist'
> and cause the breach to be observable externally. Contrawise if they d= o not delete the logs, the CA will have a record of the bogus certs that we= re issued.
>
> In the past it was considered axiomatic that a CA will never ever be b= reached. Now we have to address that as a possibility and deploy mechanisms= that can detect that eventuality.
>
>
> On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper <david.cooper@nist.gov> wrote:
>> Phil,
>>
>> The supposed advantages of adding a 'does not exist' respo= nse continue
>> to elude me. =A0Back in November I explained in detail why I didn&= #39;t
>> believe that adding this new response would provide much in the wa= y of
>> additional security, and if anything might only create a false sen= se
>> of security (see
>> http://www.ietf.org/mail-archive/web/pkix/curre= nt/msg29983.html). =A0I
>> only received two responses to my message, and both were proposing=
>> substantial changes to the PKI trust architecture, and neither
>> supported the idea that adding a 'does not exist' status r= esponse
>> (without making other significant
>> changes) would provide a significant advantage.
>>
>> So, could you respond to my earlier message and explain why simply=
>> adding a 'does not exist' status does more than provide a = false sense
>> of added confidence?
>>
>> Dave
>>
>>
>> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote:
>>>
>>> Denis,
>>>
>>> I agree with the points you raise but:
>>>
>>> 1) The whole purpose of this proposal is to enable a re-engine= ering
>>> of CA architecture so that we eliminate 'single break'= systems. At
>>> the moment there is only a modest security advantage to separa= ting
>>> out the OCSP HSM from the cert signing HSM, but as your analys= is
>>> shows having a strong response for 'does not exist' ch= anges that.
>>>
>>> 2) SCVP is complicated because the problem it solves is very c= omplex.
>>> The problem of enabling a 'does not exist' certificate= status is much
>>> simpler and a direct and logical extension of what OCSP alread= y does.
>>>
>>>
>>> On Fri, Mar 16, 2012 at 12:23 PM,<denis.pinkas@bull.net> =A0wrote:
>>>>
>>>> Paul,
>>>>
>>>> I agree with you that it is possible to extend OCSP, as lo= ng as
>>>> additional status information is related to information av= ailable by
>>>> the CA that has issued the certificate. In particular, sin= ce CRL is
>>>> a "black list" mechanism, OCSP is able to use a = "white list"
>>>> mechanism. This is where "not issued" has a mean= ing.
>>>>
>>>> However, the benefit of using a white list mechanism is on= ly a small
>>>> advantage in case the CA is compromised.
>>>> If everything has been compromised in the CA premises, the= n there is
>>>> no
>>>> =A0advantage at all.
>>>>
>>>> The only advantage is when the CA compromission is only pa= rtial and
>>>> when the forged certificate has not been able to be includ= ed in the
>>>> log of issued certificates.
>>>>
>>>> For example, the HSM has been used directly to create a fo= rged
>>>> certificate.
>>>>
>>>> The danger is that people might think that white list mech= anisms are
>>>> much better than black list mechanisms, whereas this is no= t as
>>>> straight.
>>>>
>>>> Denis
>>>>
>>>> PS. SCVP complexity is about 10 times the complexity of OC= SP, hence
>>>> why it is and will not be not widely deployed.
>>>>
>>>> PS 2. the previous message was sent before my message was = finished.
>>>>
>>>>
>>>>
>>>>
>>>> De : =A0 =A0 =A0 =A0Paul Hoffman<paul.hoffman@vpnc.org> A : =A0 =A0 =A0 =A0Phillip=
>>>> Hallam-Baker<hallam= @gmail.com> Cc : =A0 =A0 =A0 =A0pki= x@ietf.org Date :
>>>> 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSA= L: SCVP to
>>>> HISTORIC Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org
>>>> ________________________________
>>>>
>>>>
>>>>
>>>> You earlier asked if anyone used SCVP, and there was the a= nswer:
>>>>
>>>>> A bunch of Govt. Agencies in the U.S. Mostly enterpris= e deployments. No
>>>>> public CAs use it.
>>>>
>>>> It is irresponsible for a public CA to request a protocol = that is known
>>>> to
>>>> be deployed to be moved to Historic simply because compani= es like itself
>>>> do
>>>> not use it, even if other entities are known to use it. Th= e PKIX WG makes
>>>> protocols that are useful to a wide range of entities, not= just public
>>>> CAs.
>>>>
>>>> Having said that, I disagree with Steve Kent's argumen= t that if something
>>>> is
>>>> "better" done in SCVP, it cannot be done in OCSP= . I agree with Phill that
>>>> any status of a certificate, including that it was not iss= ues or is
>>>> expired,
>>>> is still status and should be able to be represented in a = well-deployed
>>>> protocol such as OCSP.
>>>>
>>>> --Paul Hoffman
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>
>
>
>
> --
> Website: http://= hallambaker.com/
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



--
Website: http://halla= mbaker.com/
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix

--bcaec5016739c2e21604bb62bfcf-- From hallam@gmail.com Fri Mar 16 14:21:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88A21E8082 for ; Fri, 16 Mar 2012 14:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHC5TvIa+jnp for ; Fri, 16 Mar 2012 14:21:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B53B221E8087 for ; Fri, 16 Mar 2012 14:21:18 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2258589yhk.31 for ; Fri, 16 Mar 2012 14:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TLOmTLkBxHSKrfFRcZeo3B/COHaLvnMt3f7JyLbpt70=; b=M4vIz7fAGF47Dcxg/BVfHNFdV2sKaICeti1FF/251hCo691ZdULrEbyj3b16yoS9tT k6OI3SbXz1ZdO2VN5ybPE3NTojWTWJl+myZVRhsiPwvS+V0bqEGSgi3BEKOa60a+RRcO 92JT0RHHpRArX6WDiQcN+pz+V3IpHP0OPd73wg6JpCyrkQyrP2PVWi8hhXpfJkMGP6eI 54kzZDxTEcnBzsdeb+MhSXvyhFCRV1TiLXY+1rqNClRHo00PC5Xmu4VB+JzUl68vKkBG yLp7+/ZOeBFoHX3RDjLqrxYl1D2I5LZeEB0YcDhCSVgtGWXHfedA6IvyKq7LFE1NXOBd 0gCw== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr4825895oeg.15.1331932878183; Fri, 16 Mar 2012 14:21:18 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 16 Mar 2012 14:21:18 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> Date: Fri, 16 Mar 2012 17:21:18 -0400 Message-ID: From: Phillip Hallam-Baker To: brennan security Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:21:20 -0000 There is a lot of current work in this area and that is input I think needs to funnel into the trust broker. On Fri, Mar 16, 2012 at 5:18 PM, brennan security wrote: > Other OCSP modes would be resistant to a CA compromise also (direct trust= , > CA designated, VA Designated). > > Many companies and large enterprises are already doing the CA designated/= VA > designated route. > > I've also been considering an alternative PKI model as a significant aid = - > for example a GPG/PGP signature on Root CAs, sub CAs, and signing Certs. > > -b > > > On Fri, Mar 16, 2012 at 5:06 PM, Phillip Hallam-Baker > wrote: >> >> That might have been a good point if you hadn't started with a personal >> insult. >> >> >> The mere fact that a feature is in PKIX does not mean we have to allow >> its use. Clearly any observational feedback system (e.g. EFF >> Observatory, Convergence) would look for such a certificate and flag >> it as unusual. >> >> But given the circumstances you cite, wouldn't the much easier path be >> for the attacker to simply issue themselves a cross certificate with >> cert signing capability? >> >> In real life an attacker would be rather unlikely to favor that >> approach because it would likely trigger secondary controls within the >> CA that are there to detect certs with the cert signing bit set. Your >> post tells me that I should consider this particular PKIX feature as >> another red flag (but my controls tend to describe what is strictly >> allowed rather than denied in any case). >> >> >> >> >> On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani >> wrote: >> > PHB never disappoints me in his understanding (or shall I say lack >> > thereof) when it comes to security. >> > >> > If the CA is compromised, the attacker will issue a delegated OCSP >> > certificate and put that pointer in the certificate that the attacker >> > minted. =A0It does not even have to do DNS poisoning to point to a rog= ue >> > responder. >> > >> > -----Original Message----- >> > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >> > Phillip Hallam-Baker >> > Sent: Friday, March 16, 2012 4:41 PM >> > To: David A. Cooper >> > Cc: pkix@ietf.org >> > Subject: Re: [pkix] certificate not issued OCSP status response >> > >> > The advantage is that it allows external parties to determine that a >> > total compromise has occurred and defenestrate the root. >> > >> > So in the DigiNotar case there were three separate problems >> > >> > 1) The CA was completely breached and issued false certificates that t= he >> > CA had no record of >> > 2) A significant time elapsed before the CA was aware that the breach >> > had occurred >> > 3) An even longer time elapsed before the breach was independently >> > discovered and remediation efforts could start. >> > >> > Now with the proposed scheme the attacker can still issue false >> > certificates but any attempt to cover their tracks by deleting the log= files >> > will result in the CA issuing the OCSP status 'Does not exist' >> > and cause the breach to be observable externally. Contrawise if they d= o >> > not delete the logs, the CA will have a record of the bogus certs that= were >> > issued. >> > >> > In the past it was considered axiomatic that a CA will never ever be >> > breached. Now we have to address that as a possibility and deploy mech= anisms >> > that can detect that eventuality. >> > >> > >> > On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper >> > wrote: >> >> Phil, >> >> >> >> The supposed advantages of adding a 'does not exist' response continu= e >> >> to elude me. =A0Back in November I explained in detail why I didn't >> >> believe that adding this new response would provide much in the way o= f >> >> additional security, and if anything might only create a false sense >> >> of security (see >> >> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). =A0= I >> >> only received two responses to my message, and both were proposing >> >> substantial changes to the PKI trust architecture, and neither >> >> supported the idea that adding a 'does not exist' status response >> >> (without making other significant >> >> changes) would provide a significant advantage. >> >> >> >> So, could you respond to my earlier message and explain why simply >> >> adding a 'does not exist' status does more than provide a false sense >> >> of added confidence? >> >> >> >> Dave >> >> >> >> >> >> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >> >>> >> >>> Denis, >> >>> >> >>> I agree with the points you raise but: >> >>> >> >>> 1) The whole purpose of this proposal is to enable a re-engineering >> >>> of CA architecture so that we eliminate 'single break' systems. At >> >>> the moment there is only a modest security advantage to separating >> >>> out the OCSP HSM from the cert signing HSM, but as your analysis >> >>> shows having a strong response for 'does not exist' changes that. >> >>> >> >>> 2) SCVP is complicated because the problem it solves is very complex= . >> >>> The problem of enabling a 'does not exist' certificate status is muc= h >> >>> simpler and a direct and logical extension of what OCSP already does= . >> >>> >> >>> >> >>> On Fri, Mar 16, 2012 at 12:23 PM, =A0wrote: >> >>>> >> >>>> Paul, >> >>>> >> >>>> I agree with you that it is possible to extend OCSP, as long as >> >>>> additional status information is related to information available b= y >> >>>> the CA that has issued the certificate. In particular, since CRL is >> >>>> a "black list" mechanism, OCSP is able to use a "white list" >> >>>> mechanism. This is where "not issued" has a meaning. >> >>>> >> >>>> However, the benefit of using a white list mechanism is only a smal= l >> >>>> advantage in case the CA is compromised. >> >>>> If everything has been compromised in the CA premises, then there i= s >> >>>> no >> >>>> =A0advantage at all. >> >>>> >> >>>> The only advantage is when the CA compromission is only partial and >> >>>> when the forged certificate has not been able to be included in the >> >>>> log of issued certificates. >> >>>> >> >>>> For example, the HSM has been used directly to create a forged >> >>>> certificate. >> >>>> >> >>>> The danger is that people might think that white list mechanisms ar= e >> >>>> much better than black list mechanisms, whereas this is not as >> >>>> straight. >> >>>> >> >>>> Denis >> >>>> >> >>>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence >> >>>> why it is and will not be not widely deployed. >> >>>> >> >>>> PS 2. the previous message was sent before my message was finished. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> De : =A0 =A0 =A0 =A0Paul Hoffman A : =A0 =A0= =A0 =A0Phillip >> >>>> Hallam-Baker Cc : =A0 =A0 =A0 =A0pkix@ietf.org Da= te : >> >>>> 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP t= o >> >>>> HISTORIC Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org >> >>>> ________________________________ >> >>>> >> >>>> >> >>>> >> >>>> You earlier asked if anyone used SCVP, and there was the answer: >> >>>> >> >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployment= s. >> >>>>> No >> >>>>> public CAs use it. >> >>>> >> >>>> It is irresponsible for a public CA to request a protocol that is >> >>>> known >> >>>> to >> >>>> be deployed to be moved to Historic simply because companies like >> >>>> itself >> >>>> do >> >>>> not use it, even if other entities are known to use it. The PKIX WG >> >>>> makes >> >>>> protocols that are useful to a wide range of entities, not just >> >>>> public >> >>>> CAs. >> >>>> >> >>>> Having said that, I disagree with Steve Kent's argument that if >> >>>> something >> >>>> is >> >>>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phil= l >> >>>> that >> >>>> any status of a certificate, including that it was not issues or is >> >>>> expired, >> >>>> is still status and should be able to be represented in a >> >>>> well-deployed >> >>>> protocol such as OCSP. >> >>>> >> >>>> --Paul Hoffman >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>>> >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Website: http://hallambaker.com/ >> > _______________________________________________ >> > pkix mailing list >> > pkix@ietf.org >> > https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > --=20 Website: http://hallambaker.com/ From liaquat.khan@ascertia.com Fri Mar 16 14:30:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD2521F8600 for ; Fri, 16 Mar 2012 14:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN8KLHYVCE6O for ; Fri, 16 Mar 2012 14:30:38 -0700 (PDT) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id B766821F85F9 for ; Fri, 16 Mar 2012 14:30:37 -0700 (PDT) Received: from [192.168.0.10] ([2.126.123.60]) by ascertia.com with MailEnable ESMTP; Fri, 16 Mar 2012 21:32:12 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 21:29:30 +0000 From: Liaquat Khan To: Phillip Hallam-Baker , "David A. Cooper" Message-ID: Thread-Topic: [pkix] certificate not issued OCSP status response In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:30:39 -0000 I think of the attack slightly differently, I am not of the opinion that the attacker removes the certificate from the CA's database to hide his/her tracks, since this would only highlight the attack specially if this new "does not exist" status is implemented. IMO the attacker will want to leave the fake certificate in the CA's database specifically so the OCSP responder (assuming it's not been compromised) can be continued to be fooled that it's a legitimate certificate. The attacker may delete other log info which highlights the break-in (e.g. Operator activity log, system event log etc.), but an OCSP responder doesn't look at generic CA log tables, it only looks at the cert table to determine certificate status.=20 IMO the attack scenario is that the attacker manages to get access to the HSM pin, and gets a fake certificate without going through the CA application. In this scenario the CA application doesn't know about the cert and it's not therefore in its cert table. The attacker will now need to somehow put that fake cert into the CA's DB table to fool the OCSP responder which can respond with "does not exist" status. However one could argue that if an attacker can get an HSM pin they can probably break into the CA also and put a fake cert into the database there, and also delete other logs that highlight the break-in and pretty much do what they want. So detection of the attack will not be so simple as just making OCSP responder's capable of returning "does not exist" response.=20 Note you state if the fake cert is left in the CA's DB, the CA will have a record of the bogus cert. However this doesn't help to detect the problem it's just a cert like another cert in the CA DB, how would a CA administrator realise its as bogus cert? With regards to the OCSP/SCVP discussion, we as a company provide both types of servers. I think the certificate "does not exist" check is not currently part of SCVP either unless I am mistaken, e.g. path building for such a certificate will still pass, path validation will also succeed since it was issued by a valid CA private key, and revocation checking will also succeed (assuming OCSP responder follows current RCC2560 and doesn't check the CA's DB). So IMO if this check is to be implemented it makes more sense to implement it in OCSP rather than SCVP. However whether it will actually solve the original problem of detecting such CA attacks is questionable, maybe in some limited cases it will. Regards, LK On 16/03/2012 20:40, "Phillip Hallam-Baker" wrote: >The advantage is that it allows external parties to determine that a >total compromise has occurred and defenestrate the root. > >So in the DigiNotar case there were three separate problems > >1) The CA was completely breached and issued false certificates that >the CA had no record of >2) A significant time elapsed before the CA was aware that the breach >had occurred >3) An even longer time elapsed before the breach was independently >discovered and remediation efforts could start. > >Now with the proposed scheme the attacker can still issue false >certificates but any attempt to cover their tracks by deleting the log >files will result in the CA issuing the OCSP status 'Does not exist' >and cause the breach to be observable externally. Contrawise if they >do not delete the logs, the CA will have a record of the bogus certs >that were issued. > >In the past it was considered axiomatic that a CA will never ever be >breached. Now we have to address that as a possibility and deploy >mechanisms that can detect that eventuality. > > >On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper >wrote: >> Phil, >> >> The supposed advantages of adding a 'does not exist' response continue >>to >> elude me. Back in November I explained in detail why I didn't believe >>that >> adding this new response would provide much in the way of additional >> security, and if anything might only create a false sense of security >>(see >> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). I >>only >> received two responses to my message, and both were proposing >>substantial >> changes to the PKI trust architecture, and neither supported the idea >>that >> adding a 'does not exist' status response (without making other >>significant >> changes) would provide a significant advantage. >> >> So, could you respond to my earlier message and explain why simply >>adding a >> 'does not exist' status does more than provide a false sense of added >> confidence? >> >> Dave >> >> >> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >>> >>> Denis, >>> >>> I agree with the points you raise but: >>> >>> 1) The whole purpose of this proposal is to enable a re-engineering of >>> CA architecture so that we eliminate 'single break' systems. At the >>> moment there is only a modest security advantage to separating out the >>> OCSP HSM from the cert signing HSM, but as your analysis shows having >>> a strong response for 'does not exist' changes that. >>> >>> 2) SCVP is complicated because the problem it solves is very complex. >>> The problem of enabling a 'does not exist' certificate status is much >>> simpler and a direct and logical extension of what OCSP already does. >>> >>> >>> On Fri, Mar 16, 2012 at 12:23 PM, wrote: >>>> >>>> Paul, >>>> >>>> I agree with you that it is possible to extend OCSP, as long as >>>> additional >>>> status information is related to information >>>> available by the CA that has issued the certificate. In particular, >>>>since >>>> CRL is a "black list" mechanism, OCSP is able >>>> to use a "white list" mechanism. This is where "not issued" has a >>>> meaning. >>>> >>>> However, the benefit of using a white list mechanism is only a small >>>> advantage in case the CA is compromised. >>>> If everything has been compromised in the CA premises, then there is >>>>no >>>> advantage at all. >>>> >>>> The only advantage is when the CA compromission is only partial and >>>>when >>>> the >>>> forged certificate >>>> has not been able to be included in the log of issued certificates. >>>> >>>> For example, the HSM has been used directly to create a forged >>>> certificate. >>>> >>>> The danger is that people might think that white list mechanisms are >>>>much >>>> better than black list mechanisms, >>>> whereas this is not as straight. >>>> >>>> Denis >>>> >>>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence >>>>why >>>> it >>>> is and will not be not widely deployed. >>>> >>>> PS 2. the previous message was sent before my message was finished. >>>> >>>> >>>> >>>> >>>> De : Paul Hoffman >>>> A : Phillip Hallam-Baker >>>> Cc : pkix@ietf.org >>>> Date : 16/03/2012 16:27 >>>> Objet : Re: [pkix] PROPOSAL: SCVP to HISTORIC >>>> Envoy=E9 par : pkix-bounces@ietf.org >>>> ________________________________ >>>> >>>> >>>> >>>> You earlier asked if anyone used SCVP, and there was the answer: >>>> >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise deployments. >>>>>No >>>>> public CAs use it. >>>> >>>> It is irresponsible for a public CA to request a protocol that is >>>>known >>>> to >>>> be deployed to be moved to Historic simply because companies like >>>>itself >>>> do >>>> not use it, even if other entities are known to use it. The PKIX WG >>>>makes >>>> protocols that are useful to a wide range of entities, not just public >>>> CAs. >>>> >>>> Having said that, I disagree with Steve Kent's argument that if >>>>something >>>> is >>>> "better" done in SCVP, it cannot be done in OCSP. I agree with Phill >>>>that >>>> any status of a certificate, including that it was not issues or is >>>> expired, >>>> is still status and should be able to be represented in a >>>>well-deployed >>>> protocol such as OCSP. >>>> >>>> --Paul Hoffman >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>> >>> >> > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > From carl@redhoundsoftware.com Fri Mar 16 15:57:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28B521F85D5 for ; Fri, 16 Mar 2012 15:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh+mVXPlWpk3 for ; Fri, 16 Mar 2012 15:57:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BACD021F85B4 for ; Fri, 16 Mar 2012 15:57:29 -0700 (PDT) Received: by qcsq13 with SMTP id q13so355725qcs.31 for ; Fri, 16 Mar 2012 15:57:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=9oeHkNOGlR/TPvBmfSLXKb+gA6NqzKrkPMvWn6zYyN8=; b=J5xXhTCwXyb3DlQDpdZOzE9WoQIaIqsl5pVqqExTE7jPIDKX1QaTHS2LVAJsAUXXRr bge4BLZCzBRIIvGxu1lOtpfde/VVPE9Zj0kQ+PoJxtTTSKgQJq35O2o5Lw2cmtfJb0EK Q6rkncgsYOujDhayGB+aAp6SrGlFgT5HEmLbYUPnemWdhLZINCfnhsF62w3GHr7AbOXf 3YuT/VavqreiL3TlTmD9votqtMb64mav8fw4haPe7uFZupabSS3ITzlf9YDPRnA+f56O vv5prgJUmL2gajJQcfYbC1ifpdkA8VLtfjFSf3sWEeAyCfh7QXQlZnsEiq48RTH7YyPy Arlg== Received: by 10.229.136.138 with SMTP id r10mr1625961qct.130.1331938649230; Fri, 16 Mar 2012 15:57:29 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id eo4sm12332901qab.16.2012.03.16.15.57.19 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 15:57:28 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 16 Mar 2012 18:57:14 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Possible OCSP Extensions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmgkKV96kltxP5LTyJLyXETjvTOqKuCaLLhwoDSEQH4JIGRA5KSJ8enRnmZyBVpeSfmUsAy Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 22:57:31 -0000 You have been suggesting that a delegated path processing protocol be tossed aside, have been pointing out that OCSP should have been used for delegated path processing in the first place and have been implying that the broad support for OCSP for one purpose means it is well suited for another purpose. This has been in service of some proposal about how to deal with certificates that pass basic validation but were not issued intentionally by a CA, presumably due to compromise. Which protocol is more widely used, who implements the proposal, whether the proposal is related to the 's' word or not and what the proposers want to do is all irrelevant to my point, which was that current OCSP clients are used in a way that make them poor integration points for a delegated path validation client. My comment was not part of some strategy to make you upset in hope you will say something that will then be used as a pretext for ignoring your proposal. On 3/16/12 12:07 PM, "Phillip Hallam-Baker" wrote: >Again, a reason to drop SCVP and concentrate on a single protocol. > >Lets do this systematically: > >1) Is the proposal related to certificate status or to cert path >validation? > >A: The feature is directly related to certificate status, stating that >the certificate serial number was never issued. > >Since OCSP is the certificate status protocol, OCSP is the right >protocol for implementation > > >2) Would the service be implemented by a CA or a third party? > >A: This feature can only be implemented by a CA. > >Since SCVP is not implemented by CAs and intended to serve as a >protocol to support delegated processing of relying party path math it >makes no sense to attempt to use SCVP. Only OCSP is suitable. > > >3) Which protocol is most widely used? > >A. OCSP by a very long way > > >4) Which protocol are the proposers of the feature interested in using? > >A. OCSP > > >Deployment of SCVP is not my problem. If people think that there is a >market for that capability then fine. But as things stand we have a >group that is very vocal in telling us that they don't want the >feature but they are nevertheless determined that it be part of the >protocol nobody who is interested in the feature wants to use. > >I really cannot understand the strategy here unless the objective is >to make me really upset in the hope that I will say something that >will then be used as a pretext for ignoring my proposal. > > >On Fri, Mar 16, 2012 at 9:11 AM, Carl Wallace >wrote: >> >> On 3/16/12 8:55 AM, "Phillip Hallam-Baker" wrote: >>> >>>The functionality is certificate status and SCVP is totally >>>irrelevant. SCVP does not address this subject area and no public CA >>>uses it. >>> >>>OCSP has an extension mechanism. It should have been used to implement >>>SCVP in the first place. >> >> Part of the reason SCVP has not been adopted is lack of client side >> support. Changing the OCSP spec is not going to improve the integration >> options for providing more than revocation status on the client side. >> >> > > > >-- >Website: http://hallambaker.com/ From hotz@jpl.nasa.gov Fri Mar 16 16:29:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DEB21E801A for ; Fri, 16 Mar 2012 16:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpvjPN+4ezWH for ; Fri, 16 Mar 2012 16:29:20 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3A68C21E8014 for ; Fri, 16 Mar 2012 16:29:20 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2GNTHUp010560 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Mar 2012 16:29:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Fri, 16 Mar 2012 16:29:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <006AE699-552A-4E7B-9B79-BEDE6B69B18F@jpl.nasa.gov> References: , <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org>, , , <4F63838C.4090408@nist.gov>, To: Piyush Jain X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 23:29:20 -0000 On Mar 16, 2012, at 1:32 PM, Piyush Jain wrote: > > From: hotz@jpl.nasa.gov > > Date: Fri, 16 Mar 2012 12:38:42 -0700 > > To: david.cooper@nist.gov > > CC: pkix@ietf.org > > Subject: Re: [pkix] certificate not issued OCSP status response > >=20 > > Can I turn the question around and ask why adding a 'does not exist' = response would be bad? > >=20 > > To answer your question more directly, I think there are scenarios = that could most easily be addressed if such a response could be = provided. Just because it doesn't solve all the problems doesn't mean it = isn't a useful improvement. >=20 > It may be useful to describe those scenarios and have a discussion = around how 'does not exist' would help. And I still argue that the question of how it would hurt deserves a = response. How can it be a bad thing to have a way to represent = "white-list" as opposed to "black-list" information? > Barring the mention of one case of partial CA compromise, I don't = recall that any other use cases that were discussed.=20 Yes, that's probably the main one. > The fundamental problem here is that if the relying party doubts the = signature on a cert signed by a CA, how can it trust the response from a = responder delegated by the CA. > =46rom an attacker's point of view, If i have compromised the CA, = then I won't stop at issuing the EE cert, I would issue myself a = responder cert as well. 1) The existence of this extension will tend to eliminate hackers who = don't do that, but that doesn't mean there won't be any. 2) The existence of this extension enables other mitigations which would = require other work. I don't want to get into that since I think it's = off-topic for such a simple proposal. > >=20 > > Obviously your concerns should be covered by the security = considerations of any description of the extension. > >=20 > > On Mar 16, 2012, at 11:16 AM, David A. Cooper wrote: > >=20 > > > Phil, > > >=20 > > > The supposed advantages of adding a 'does not exist' response = continue=20 > > > to elude me. Back in November I explained in detail why I didn't=20= > > > believe that adding this new response would provide much in the = way of=20 > > > additional security, and if anything might only create a false = sense of=20 > > > security (see=20 > > > http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). = I=20 > > > only received two responses to my message, and both were proposing=20= > > > substantial changes to the PKI trust architecture, and neither = supported=20 > > > the idea that adding a 'does not exist' status response (without = making=20 > > > other significant changes) would provide a significant advantage. > >=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 ------------------------------------------------------ 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 Fri Mar 16 16:32:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E9421E8032 for ; Fri, 16 Mar 2012 16:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qd+WCxyWf6Y for ; Fri, 16 Mar 2012 16:32:18 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 99E0621E8014 for ; Fri, 16 Mar 2012 16:32:18 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D68991DEA702 for ; Sat, 17 Mar 2012 00:31: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 d0p0nfcQxe05 for ; Sat, 17 Mar 2012 00:31:47 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 87E471DEA6FD for ; Sat, 17 Mar 2012 00:31:47 +0100 (CET) Received: (qmail 83490 invoked from network); 16 Mar 2012 23:31:47 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.11]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Mar 2012 23:31:47 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 17 Mar 2012 00:31:39 +0100 From: Stefan Santesson To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Possible OCSP Extensions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Fri, 16 Mar 2012 23:32:19 -0000 Phil, Giving this some thought my problem is that this proposal feels like a good thing. This is a piece of information known to most OCSP responders, but no way to express it, why not add that feature? But the deeper you go into examining what the real benefits actually would be, it gets harder and harder to see those benefits. We seem to have build the foundation of PKI on the assumption that everything that is signed by a CA, is a valid statement of that CA. And if the key of the CA, or the CA itself, is compromised, then all bets are off. This proposal seems to propose that all bets are not off. That there are ways to prevent a successful exploit of a compromised CA if we add a "never issued" response. I'm in doubt. /Stefan On 12-03-16 9:28 PM, "Phillip Hallam-Baker" wrote: >Me too, I just can't see how recent events are going to get engineers >excited about implementing a 10 year old protocol that is pretty >tightly bound to PKIX and a rather specific view of PKIX at that. > >If we are going to get a trust broker protocol deployed we are going >to have to meet the Google criteria that it improve, not harm response >time. So the only deployable approach I can see is to combine the >trust resolution request with the name resolution request. > >Knowing more about the validity of the certificate seems rather >superfluous to me when I have no authoritative or reliable means of >knowing if the connection should use SSL (other than cached previous >interactions). > > >On Fri, Mar 16, 2012 at 4:21 PM, Henry B. Hotz wrote: >> On Mar 16, 2012, at 12:43 PM, Phillip Hallam-Baker wrote: >> >>> Oh is that what he is worrying about? >> >> Well, it's what *I*'m worried about. Stephen can speak for himself. I >>don't think the practical validation problem is unique to web/TLS though. >> ------------------------------------------------------ >> 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 >> > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From ryan.hurst@globalsign.com Fri Mar 16 20:51:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C79C21E8040 for ; Fri, 16 Mar 2012 20:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRFtuBTQSEqJ for ; Fri, 16 Mar 2012 20:51:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD47821E800F for ; Fri, 16 Mar 2012 20:51:46 -0700 (PDT) Received: by dakl33 with SMTP id l33so7984276dak.31 for ; Fri, 16 Mar 2012 20:51:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:x-mailer :thread-index:content-language:mime-version:content-type :x-gm-message-state; bh=w4xcRYxyH+zEfROmqGExasnRVmSZcLvVcME5YjeXS0A=; b=BO/AxYdi81KxjTFcS4o4F1wTrdtHlhOE8DXTXmsRoDBUG1EjR4YiRFvXJ/4x4TSFq7 Z8Zd386k89TxSm/XEoF9vvA4LvDfcSL5tOzFbSEMAv7sFZOWBwc9VKWmeB0v9zBUsJ2h sL//CpJi4XC1KpyKK4hchY6mYRwKkcgc9/l717GT4hyAAESTWXDbZLkt6+qthvYwFRvj 2OvVphGkXzDU9pndHZyAoOw4E5WmESFcopev+mucNUSUVqZMzBWKFILL4cT/9VTmHDbr 4G4lkl0XABjK/w5DjDcJrefU5gbp9NeWlgPr6s/D8/K4reyCR9FAXvJ7pp/KgzWQFxS3 2/Ng== Received: by 10.68.232.162 with SMTP id tp2mr19908692pbc.165.1331956300182; Fri, 16 Mar 2012 20:51:40 -0700 (PDT) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id z5sm5714215pbn.35.2012.03.16.20.51.38 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 20:51:38 -0700 (PDT) From: "Ryan Hurst" To: "'Piyush Jain'" , , References: , In-Reply-To: Date: Fri, 16 Mar 2012 20:51:33 -0700 Message-ID: <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNsp/XD7PxT56WOrq4dYP3sMZz/4wJkklWGAjmlygCTCZih4A== Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0D6F_01CD03B6.924614D0" X-Gm-Message-State: ALoCoQmcs0a2ERZoxVw8+93a+7lYHb2YfCmBNdG2/O+q+TMbwi8KkTvdMrpbu/WzXrLGCgKybZZj Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 03:51:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D6F_01CD03B6.924614D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0D70_01CD03B6.924614D0" ------=_NextPart_001_0D70_01CD03B6.924614D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As others have pointed out the ability to do ranges is essentially dependent on serial numbers being non-random values, in the context of publicly trusted roots the two largest root programs (MSFT and MOZ) basically require random serial numbers, the Microsoft text is the clearest, you can find it here: http://social.technet.microsoft.com/wiki/contents/articles/1760.aspx Additional Security for Intermediate and End-Entity Certificates (random value) 1. For all intermediate and end-entity certificates issued after December 31, 2010, the CA must include an 8-byte random or pseudo-random value in either the Serial Number certificate field or the first component of the Subject Name certificate field. a. This requirement is for all certificates signed with SHA1, and optional but recommended for certificates signed with SHA2 until SHA2 begins to show weakness to collision attacks. b. By SerialNumber field, Microsoft does not refer to the serial number component of the subject name, identified by OID 2.5.4.5. c. The random number must appear before all other fields in the Subject Name. d. The random or pseudo-random number generator must be provided by an operating system or by a hardware crypto module. e. There is also the possibility of a 3-byte random value in the Hour:Minute:Second part of the Validity Period field. This 3-byte random value is shorter than the 8-byte value for other certificate fields, but if there is no other option to introduce a random value, it will mitigate a potential attack and will be accepted. The Mozilla language is a little more flexible, it is here: http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html We expect CAs to maintain current best practices to prevent algorithm attacks against certificates. As such, the following steps will be taken: . all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number). In both cases the text is pretty bad in my opinion in that one could interpret conformance a few ways but its clear (due to SHA1 collisions) they have adopted a policy that in-net should result in all CAs using random numbers for serial numbers. With that said I like the idea of ranges, in the 90s we (ValiCert - as I am sure Piyush remembers) did this with Certificate Revocation Trees which was a signed Merkel Hash Tree based revocation scheme. Ryan From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain Sent: Thursday, March 15, 2012 2:36 PM To: schokhani@cygnacom.com; pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP Santosh, I understand and agree with you concern about CA compromise that you raised in the other thread. However, this proposal is simply optimizes the representation of same information that current OCSP protocol supports. Consider the example where you need to represent the status of certificates with serial number 1 to 10000 and none of those certificate serials are listed in the CRL. To comply with current OCSP specification, a responder would generate 10000 responsed (10000 signatures). If it is bundling multiple serial numbers in one response, lets say 20, then it would need to sign 500 responses. In either case, these 10000 serials would need to be explicitly listed in one or more OCSP responses. With the range approach, the responder can just create one response which says, start serial is 1, end serial is 10000 and the status is good. -Piyush _____ From: SChokhani@cygnacom.com To: piyush@identicate.com; pkix@ietf.org Date: Thu, 15 Mar 2012 17:08:50 -0400 Subject: RE: [pkix] Range responses in OCSP I remain concerned about these added features without a discussion of the need. As I mentioned previously, if the concern is CA compromise, this does not help unless trust in the Responder is established independent of trust in the CA that issued the certificate in question. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain Sent: Thursday, March 15, 2012 4:57 PM To: pkix@ietf.org Subject: [pkix] Range responses in OCSP In the other OCSP thread, PHB proposed range responses in OCSP to represent "not issued" certificates. I'll leave the discussion of possible status values to that thread. However, that idea of returning the status of a list of serial number can be very useful in existing OCSP deployments that pre-sign the responses. There are few limitations with one status/serial number in OCSP if the responder is getting its information from the CRL. - No way to generate OCSP responses ahead of time for CAs that issue certificates with non-sequential serial numbers - Size of collection of pre-signed OCSP responses is much bigger when compared to CRLS. - Number of signatures required to create OCSP responses for the population of issued certificates is huge. All of these issues could be addressed if an OCSP response can associate a status with a range of serial numbers, as opposed to a single serial number. Thoughts? -Piyush ------=_NextPart_001_0D70_01CD03B6.924614D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As others have pointed out the ability to do ranges is essentially = dependent on serial numbers being non-random values, in the context of = publicly trusted roots the two largest root programs (MSFT and MOZ) = basically require random serial numbers, the Microsoft text is the = clearest, you can find it here: http://social.technet.microsoft.com/wiki/contents/articles/1760.aspx=

Additional Security for Intermediate and = End-Entity Certificates (random value)

1.       = For all intermediate and end-entity = certificates issued after December 31, 2010, the CA must include an = 8-byte random or pseudo-random value in either the Serial Number = certificate field or the first component of the Subject Name certificate = field.
a.      This requirement is for all = certificates signed with SHA1, and optional but recommended for = certificates signed with SHA2 until SHA2 begins to show weakness to = collision attacks.
b.      = By SerialNumber field, Microsoft does not refer to the = serial number component of the subject name, identified by OID = 2.5.4.5.  
c.       The = random number must appear before all other fields in the Subject = Name.
d.      The random or pseudo-random = number generator must be provided by an operating system or by a = hardware crypto module.
e.      There is = also the possibility of a 3-byte random value in the Hour:Minute:Second = part of the Validity Period field.  This 3-byte random value is = shorter than the 8-byte value for other certificate fields, but if there = is no other option to introduce a random value, it will mitigate a = potential attack and will be accepted.

The Mozilla language is a little more flexible, it is here: http://www.mozilla.org/projects/security/certs/policy/Mainte= nancePolicy.html

 

We expect CAs to maintain current best practices to = prevent algorithm attacks against certificates. As such, the following = steps will be taken:

·         = al= l new end-entity certificates must contain at least 20 bits of = unpredictable random data (preferably in the serial = number).

 

 

In both cases the text is pretty bad in my opinion in that one could = interpret conformance a few ways but its clear (due to SHA1 collisions) = they have adopted a policy that in-net should result in all CAs using = random numbers for serial numbers.

 

With that said I like the idea of ranges, in the 90s we (ValiCert = – as I am sure Piyush remembers) did this with Certificate = Revocation Trees which was a signed Merkel Hash Tree based revocation = scheme.

 

Ryan

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain
Sent: Thursday, March 15, 2012 2:36 = PM
To: schokhani@cygnacom.com; = pkix@ietf.org
Subject: Re: [pkix] Range responses in = OCSP

 

Santosh,

 <= /o:p>

I = understand and agree with you concern about CA compromise that you = raised in the other thread.

However, = this proposal is simply optimizes the representation of same information = that current OCSP protocol supports.

 <= /o:p>

Consider = the example where you need to represent the status of certificates with = serial number 1 to 10000 and none of those certificate serials are = listed in the CRL.

 <= /o:p>

To comply = with current OCSP specification, a responder would generate 10000 = responsed (10000 signatures). If it is bundling multiple serial numbers = in one response, lets say 20, then it would need to sign 500 responses. = In either case, these 10000 serials would need to be explicitly listed = in one or more OCSP responses.


With = the range approach, the responder can just create one response which = says, start serial is 1, end serial is 10000 and the status is = good.

 <= /o:p>

-Piyush=

From: SChokhani@cygnacom.com
To: = piyush@identicate.com; pkix@ietf.org
Date: Thu, 15 Mar = 2012 17:08:50 -0400
Subject: RE: [pkix] Range responses in = OCSP

= I remain concerned about these added features without a discussion of = the need.<= /span>

=
As I mentioned previously, if the concern is CA compromise, this = does not help unless trust in the Responder is established independent = of trust in the CA that issued the certificate in question.<= /span>

=  <= /span>

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.= org] On Behalf Of Piyush Jain
Sent: Thursday, March = 15, 2012 4:57 PM
To: pkix@ietf.org
Subject: = [pkix] Range responses in OCSP

 <= /o:p>

In the = other OCSP thread, PHB proposed  range responses in OCSP to = represent "not issued" = certificates.

I'll leave = the discussion of possible status values to that = thread.

 <= /o:p>

However, = that idea of returning the status of a list of serial number can be very = useful in existing OCSP deployments that pre-sign the = responses.

 <= /o:p>

There are = few limitations with one status/serial number in OCSP if the responder = is getting its information from the = CRL.

- No way to = generate OCSP responses ahead of time for CAs that issue certificates = with non-sequential serial numbers

- Size of = collection of pre-signed OCSP responses is much bigger when compared to = CRLS.

- Number of = signatures required to create OCSP responses for the population of = issued certificates is huge.

 <= /o:p>

All of = these issues could be addressed if an OCSP response can associate a = status with a range of serial numbers, as opposed to a single serial = number.

 <= /o:p>

Thoughts?

 <= /o:p>

-Piyush=

 <= /o:p>

 <= /o:p>

 <= /o:p>

------=_NextPart_001_0D70_01CD03B6.924614D0-- ------=_NextPart_000_0D6F_01CD03B6.924614D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMTcwMzUxMzNaMCMGCSqG SIb3DQEJBDEWBBSvxU9/hfSHn2de7+uIsLlxdO5W9DB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBACzdxkRZbEKNuKR0JVzjh+40ksaba/JzeaENVtT4wgGQQP4zwKYSpoXE iHqLdwZrg9IOsjL10dWKHkIeXxMkfE8D7Jq31DYmnwvJiNqbgAcnAm3TXIAHQkFpUPGTjTausjTu jAWcISxBuYbymV422Vpursk49rouD9mZgNpMzcu8xd6HnamIStClKR7MRtJlYJFN50G0+o42TFna WtKwYotEICypKTNCs+lVpRJA6TVr6cZ/QxVqjjQEHwspgX9NENFBuQE3gj1JF/W9V9bSpgAFf3N7 Es2sb+6SNgfIW34gonfZ/cEXYg3JwpTZLlkSNN6bLkxZ5p7bdBoY3eGbfXMAAAAAAAA= ------=_NextPart_000_0D6F_01CD03B6.924614D0-- From piyush@identicate.com Fri Mar 16 22:10:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93421F87C0 for ; Fri, 16 Mar 2012 22:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOkM6eWetVYX for ; Fri, 16 Mar 2012 22:10:14 -0700 (PDT) Received: from col0-omc3-s10.col0.hotmail.com (col0-omc3-s10.col0.hotmail.com [65.55.34.148]) by ietfa.amsl.com (Postfix) with ESMTP id 6608421F87BE for ; Fri, 16 Mar 2012 22:10:14 -0700 (PDT) Received: from COL119-W37 ([65.55.34.135]) by col0-omc3-s10.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 22:10:14 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9440e138-b357-4552-9f30-44f26a5a7e8d_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Fri, 16 Mar 2012 22:10:13 -0700 Importance: Normal In-Reply-To: <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> References: , , <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2012 05:10:14.0478 (UTC) FILETIME=[3C786EE0:01CD03FC] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 05:10:16 -0000 --_9440e138-b357-4552-9f30-44f26a5a7e8d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ryan=2C Ability to do ranges is actually more useful in pre-signing if the serial n= umbers are big random numbers. Without ranges it is computationally infeasible to pre-sign OCSP responses = for large random serials if the responder does not have access to issued se= rial list. -Piyush From: ryan.hurst@globalsign.com To: piyush@identicate.com=3B schokhani@cygnacom.com=3B pkix@ietf.org Subject: RE: [pkix] Range responses in OCSP Date: Fri=2C 16 Mar 2012 20:51:33 -0700 As others have pointed out the ability to do ranges is essentially dependen= t on serial numbers being non-random values=2C in the context of publicly t= rusted roots the two largest root programs (MSFT and MOZ) basically require= random serial numbers=2C the Microsoft text is the clearest=2C you can fin= d it here: http://social.technet.microsoft.com/wiki/contents/articles/1760.= aspxAdditional Security for Intermediate and End-Entity Certificates (rando= m value)1. For all intermediate and end-entity certificates issued af= ter December 31=2C 2010=2C the CA must include an 8-byte random or pseudo-r= andom value in either the Serial Number certificate field or the first comp= onent of the Subject Name certificate field. a. This requirement is for all certificates signed with SHA1=2C and op= tional but recommended for certificates signed with SHA2 until SHA2 begins = to show weakness to collision attacks. b. By SerialNumber field=2C Microsoft does not refer to the serial num= ber component of the subject name=2C identified by OID 2.5.4.5. =20 c. The random number must appear before all other fields in the Subje= ct Name. d. The random or pseudo-random number generator must be provided by an= operating system or by a hardware crypto module. e. There is also the possibility of a 3-byte random value in the Hour:= Minute:Second part of the Validity Period field. This 3-byte random value = is shorter than the 8-byte value for other certificate fields=2C but if the= re is no other option to introduce a random value=2C it will mitigate a pot= ential attack and will be accepted.The Mozilla language is a little more fl= exible=2C it is here: http://www.mozilla.org/projects/security/certs/policy= /MaintenancePolicy.html We expect CAs to maintain current best practices to= prevent algorithm attacks against certificates. As such=2C the following s= teps will be taken:=B7 all new end-entity certificates must contain= at least 20 bits of unpredictable random data (preferably in the serial nu= mber). In both cases the text is pretty bad in my opinion in that one coul= d interpret conformance a few ways but its clear (due to SHA1 collisions) t= hey have adopted a policy that in-net should result in all CAs using random= numbers for serial numbers. With that said I like the idea of ranges=2C in= the 90s we (ValiCert =96 as I am sure Piyush remembers) did this with Cert= ificate Revocation Trees which was a signed Merkel Hash Tree based revocati= on scheme. RyanFrom: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] O= n Behalf Of Piyush Jain Sent: Thursday=2C March 15=2C 2012 2:36 PM To: schokhani@cygnacom.com=3B pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP Santosh=2C I understand and agr= ee with you concern about CA compromise that you raised in the other thread= .However=2C this proposal is simply optimizes the representation of same in= formation that current OCSP protocol supports. Consider the example where y= ou need to represent the status of certificates with serial number 1 to 100= 00 and none of those certificate serials are listed in the CRL. To comply w= ith current OCSP specification=2C a responder would generate 10000 response= d (10000 signatures). If it is bundling multiple serial numbers in one resp= onse=2C lets say 20=2C then it would need to sign 500 responses. In either = case=2C these 10000 serials would need to be explicitly listed in one or mo= re OCSP responses. With the range approach=2C the responder can just create one response which= says=2C start serial is 1=2C end serial is 10000 and the status is good. -= PiyushFrom: SChokhani@cygnacom.com To: piyush@identicate.com=3B pkix@ietf.org Date: Thu=2C 15 Mar 2012 17:08:50 -0400 Subject: RE: [pkix] Range responses in OCSPI remain concerned about these a= dded features without a discussion of the need. As I mentioned previously=2C if the concern is CA compromise=2C this does n= ot help unless trust in the Responder is established independent of trust i= n the CA that issued the certificate in question. From: pkix-bounces@ietf.o= rg [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain Sent: Thursday=2C March 15=2C 2012 4:57 PM To: pkix@ietf.org Subject: [pkix] Range responses in OCSP In the other OCSP thread=2C PHB pro= posed range responses in OCSP to represent "not issued" certificates.I'll = leave the discussion of possible status values to that thread. However=2C t= hat idea of returning the status of a list of serial number can be very use= ful in existing OCSP deployments that pre-sign the responses. There are few= limitations with one status/serial number in OCSP if the responder is gett= ing its information from the CRL.- No way to generate OCSP responses ahead = of time for CAs that issue certificates with non-sequential serial numbers-= Size of collection of pre-signed OCSP responses is much bigger when compar= ed to CRLS.- Number of signatures required to create OCSP responses for the= population of issued certificates is huge. All of these issues could be ad= dressed if an OCSP response can associate a status with a range of serial n= umbers=2C as opposed to a single serial number. Thoughts? -Piyush = = --_9440e138-b357-4552-9f30-44f26a5a7e8d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ryan=2C

Ability to do ranges is actually more useful in pre-signing = if the serial numbers are big random numbers.
Without ranges it is compu= tationally infeasible to pre-sign OCSP responses for large random serials i= f the responder does not have access to issued serial list.

-Piyush<= br>

From: ryan.hurst@globalsign.com
To: piyush@identicate.com=3B schokhan= i@cygnacom.com=3B pkix@ietf.org
Subject: RE: [pkix] Range responses in O= CSP
Date: Fri=2C 16 Mar 2012 20:51:33 -0700

As others have pointed out the ability to do= ranges is essentially dependent on serial numbers being non-random values= =2C in the context of publicly trusted roots the two largest root programs = (MSFT and MOZ) basically require random serial numbers=2C the Microsoft tex= t is the clearest=2C you can find it here: http://s= ocial.technet.microsoft.com/wiki/contents/articles/1760.aspx

=

Additiona= l Security for Intermediate and End-Entity Certificates (random value)

1. = =3B =3B =3B =3B =3B =3B For all intermediate and end-entity certific= ates issued after December 31=2C 2010=2C the CA must include an 8-byte rand= om or pseudo-random value in either the Serial Number certificate field or = the first component of the Subject Name certificate field.
a. =3B&nb= sp=3B =3B =3B =3B This requirement is for all certificates sign= ed with SHA1=2C and optional but recommended for certificates signed with S= HA2 until SHA2 begins to show weakness to collision attacks.
b. =3B&= nbsp=3B =3B =3B =3B By =3BSerialNumber =3Bfield= =2C Microsoft does not refer to the serial number component of the subject = name=2C identified by OID 2.5.4.5. =3B =3B
c. =3B =3B&nb= sp=3B =3B =3B =3B The random number must appear before all othe= r fields in the Subject Name.
d. =3B =3B =3B =3B =3B= The random or pseudo-random number generator must be provided by an operat= ing system or by a hardware crypto module.
e. =3B =3B =3B&nb= sp=3B =3B There is also the possibility of a 3-byte random value in the= Hour:Minute:Second part of the Validity Period field. =3B This 3-byte = random value is shorter than the 8-byte value for other certificate fields= =2C but if there is no other option to introduce a random value=2C it will = mitigate a potential attack and will be accepted.

The Mozilla language is= a little more flexible=2C it is here: http= ://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

 =3B

We expect CAs to = maintain current best practices to prevent algorithm attacks against certif= icates. As such=2C the following steps will be taken:

=B7 =3B =3B =3B =3B =3B =3B =3B =3B = all new end-entity= certificates must contain at least 20 bits of unpredictable random data (p= referably in the serial number).

 =3B

 =3B

In both cases th= e text is pretty bad in my opinion in that one could interpret conformance = a few ways but its clear (due to SHA1 collisions) they have adopted a polic= y that in-net should result in all CAs using random numbers for serial numb= ers.

 =3B

With that said I like the idea of ranges=2C in the 90s we= (ValiCert =96 as I am sure Piyush remembers) did this with Certificate Rev= ocation Trees which was a signed Merkel Hash Tree based revocation scheme.<= /span>

 =3B

Ryan

 =3B

Santosh=2C

 =3B

I understand and a= gree with you concern about CA compromise that you raised in the other thre= ad.

= However=2C this proposal is simply optimizes the representation of same inf= ormation that current OCSP protocol supports.

 =3B

Consider the example where = you need to represent the status of certificates with serial number 1 to 10= 000 and none of those certificate serials are listed in the CRL.

=

 =3B

To comp= ly with current OCSP specification=2C a responder would generate 10000 resp= onsed (10000 signatures). If it is bundling multiple serial numbers in one = response=2C lets say 20=2C then it would need to sign 500 responses. In eit= her case=2C these 10000 serials would need to be explicitly listed in one o= r more OCSP responses.


With the range approach=2C the responder can just cr= eate one response which says=2C start serial is 1=2C end serial is 10000 an= d the status is good.

 =3B

<= span style=3D"font-size:10.0pt=3Bfont-family:"=3BTahoma"=3B=2C"= =3Bsans-serif"=3B">-Piyush

From: SChokhani@cygnacom.= com
To: piyush@identicate.c= om=3B pkix@ietf.org
Date: Thu= =2C 15 Mar 2012 17:08:50 -0400
Subject: RE: [pkix] Range responses in OC= SP

I remain concerned about these added features without a discussion = of the need.


As I mentioned previously=2C= if the concern is CA compromise=2C this does not help unless trust in the = Responder is established independent of trust in the CA that issued the cer= tificate in question.

 =3B

<= span style=3D"font-size:10.0pt=3Bfont-family:"=3BTahoma"=3B=2C"= =3Bsans-serif"=3B">From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Beh= alf Of Piyush Jain
Sent: Thursday=2C March 15=2C 2012 4:57 PM=
To: pkix@ietf.org
Sub= ject: [pkix] Range responses in OCSP

 =3B

In the other OCSP thread=2C PHB propos= ed  =3Brange responses in OCSP to represent "not issued" certificates.<= /span>

I'll leave= the discussion of possible status values to that thread.

<= div>

 =3B

However=2C that = idea of returning the status of a list of serial number can be very useful = in existing OCSP deployments that pre-sign the responses.

<= div>

 =3B

There are few li= mitations with one status/serial number in OCSP if the responder is getting= its information from the CRL.

- No way to generate OCSP responses ahead of tim= e for CAs that issue certificates with non-sequential serial numbers=

- Size of = collection of pre-signed OCSP responses is much bigger when compared to CRL= S.

-= Number of signatures required to create OCSP responses for the population = of issued certificates is huge.

 =3B

All of these issues could be addressed if= an OCSP response can associate a status with a range of serial numbers=2C = as opposed to a single serial number.

 =3B

Thoughts?

 =3B

=

-Piyush

<= div>

 =3B

 =3B<= /p>

 =3B

<= /body> = --_9440e138-b357-4552-9f30-44f26a5a7e8d_-- From anders.rundgren@telia.com Sat Mar 17 01:56:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558E821F86C3 for ; Sat, 17 Mar 2012 01:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tFuRxjkbI+l for ; Sat, 17 Mar 2012 01:56:50 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 290DA21F86EC for ; Sat, 17 Mar 2012 01:56:45 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E0026C261; Sat, 17 Mar 2012 09:56:42 +0100 Message-ID: <4F6451BF.7020104@telia.com> Date: Sat, 17 Mar 2012 09:56:31 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 08:56:51 -0000 Stefan, I will unfortunately not be able to attend. May I suggest that the crowd spends some 10 minutes on discussing how PKIX intends to deal with the fact that mobile devices with embedded credentials will most likely constitute of the bulk of the client-side of PKI? Even the US government have realized (it took some time...) that "Derived Credentials" is probably a better solution than "putting PIV on a string": http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nist-800-63-1_overview_enewton.pdf It is (at least to me) obvious that ambitious efforts such as President Obama's NSTIC program won't go particularly far without having secure, convenient, and interoperable enrollment solutions. However, then we enter the minefield known as "Token Provisioning" which currently only is covered by proprietary solutions like the Google Wallet. Giving in to Google may though be the best for the market since a leading vendor can (as Microsoft did in the past) indirectly enforce the necessary "compliance" on the other parties. The opportunity for a standard addressing 5-10 BILLION of connected devices won't exist 3 years from now, at least if we are talking about a *used* ditto. If you are the daring type you might even perform a straw poll on the topic :-) Anders On 2012-03-16 17:19, Stefan Santesson wrote: > I have posted a preliminary agenda at: > http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt > > I do lack presentations on current ongoing drafts. > If you are currently editing a PKIX WG draft, please notify me and Steve > if you need an agenda slot or not > > > /Stefan > > > On 12-02-28 11:49 PM, "Stephen Kent" wrote: > >> Folks, >> >> I have already sent a message noting our meeting day/time/room. >> >> Please let Stefan and me know if you want a slot on the agenda. >> >> Thanks, >> >> Steve >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From stefan@aaa-sec.com Sat Mar 17 05:32:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2271E21F864F for ; Sat, 17 Mar 2012 05:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW9+7JChW2nw for ; Sat, 17 Mar 2012 05:32:32 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9BD21F863C for ; Sat, 17 Mar 2012 05:32:31 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E410E1DC41D7 for ; Sat, 17 Mar 2012 13:32: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 l79IM8j289t4 for ; Sat, 17 Mar 2012 13:32:29 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8B2911D51F7E for ; Sat, 17 Mar 2012 13:32:29 +0100 (CET) Received: (qmail 2563 invoked from network); 17 Mar 2012 12:32:28 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 17 Mar 2012 12:32:28 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 17 Mar 2012 13:32:13 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Agenda requests for Paris In-Reply-To: <4F6451BF.7020104@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 12:32:33 -0000 Anders, It does not work that way, no matter how interesting your issue might be. If you want to raise an issue at the meeting, then you need to ask for a slot and show up at the meeting. If you can't be bothered, convince someone that will be present to do it for you. If you can't do that even, then discuss it on the list. /Stefan On 12-03-17 9:56 AM, "Anders Rundgren" wrote: >Stefan, >I will unfortunately not be able to attend. > >May I suggest that the crowd spends some 10 minutes on discussing how PKIX >intends to deal with the fact that mobile devices with embedded >credentials >will most likely constitute of the bulk of the client-side of PKI? > >Even the US government have realized (it took some time...) that >"Derived Credentials" is probably a better solution than >"putting PIV on a string": > >http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nist- >800-63-1_overview_enewton.pdf > >It is (at least to me) obvious that ambitious efforts such as President >Obama's NSTIC program won't go particularly far without having secure, >convenient, and interoperable enrollment solutions. > >However, then we enter the minefield known as "Token Provisioning" which >currently only is covered by proprietary solutions like the Google Wallet. > >Giving in to Google may though be the best for the market since a leading >vendor can (as Microsoft did in the past) indirectly enforce the necessary >"compliance" on the other parties. > >The opportunity for a standard addressing 5-10 BILLION of connected >devices >won't exist 3 years from now, at least if we are talking about a *used* >ditto. > >If you are the daring type you might even perform a straw poll on the >topic :-) > >Anders > > > >On 2012-03-16 17:19, Stefan Santesson wrote: >> I have posted a preliminary agenda at: >> http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt >> >> I do lack presentations on current ongoing drafts. >> If you are currently editing a PKIX WG draft, please notify me and Steve >> if you need an agenda slot or not >> >> >> /Stefan >> >> >> On 12-02-28 11:49 PM, "Stephen Kent" wrote: >> >>> Folks, >>> >>> I have already sent a message noting our meeting day/time/room. >>> >>> Please let Stefan and me know if you want a slot on the agenda. >>> >>> Thanks, >>> >>> Steve >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Sat Mar 17 06:10:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D93121F8699 for ; Sat, 17 Mar 2012 06:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfLvrcannGhF for ; Sat, 17 Mar 2012 06:10:05 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3021F85D4 for ; Sat, 17 Mar 2012 06:10:05 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D001C68E4; Sat, 17 Mar 2012 14:10:03 +0100 Message-ID: <4F648D1F.2020306@telia.com> Date: Sat, 17 Mar 2012 14:09:51 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 13:10:06 -0000 On 2012-03-17 13:32, Stefan Santesson wrote: > Anders, > > It does not work that way, no matter how interesting your issue might be. You mean that IETF statutes doesn't permit discussing possible future work-items without a proposer actually being physically present? Anyway, your college in the Swedish EID2-project Leif Johansson, indeed mentioned the very same issue "as highly problematic" in a panel session in the IDTrust/NSTIC event that we both attended this week in Washington DC. Somewhat related: From what I can see the rationale for EST haven't been discussed at all on this list. I don't think even Cisco in the end will support EST since it doesn't add functional improvements. Even the target "Simple PKI client" seems to be left to the reader to guess what it could possibly be. Do YOU know? Anders > > If you want to raise an issue at the meeting, then you need to ask for a > slot and show up at the meeting. > If you can't be bothered, convince someone that will be present to do it > for you. > > If you can't do that even, then discuss it on the list. > > /Stefan > > On 12-03-17 9:56 AM, "Anders Rundgren" wrote: > >> Stefan, >> I will unfortunately not be able to attend. >> >> May I suggest that the crowd spends some 10 minutes on discussing how PKIX >> intends to deal with the fact that mobile devices with embedded >> credentials >> will most likely constitute of the bulk of the client-side of PKI? >> >> Even the US government have realized (it took some time...) that >> "Derived Credentials" is probably a better solution than >> "putting PIV on a string": >> >> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nist- >> 800-63-1_overview_enewton.pdf >> >> It is (at least to me) obvious that ambitious efforts such as President >> Obama's NSTIC program won't go particularly far without having secure, >> convenient, and interoperable enrollment solutions. >> >> However, then we enter the minefield known as "Token Provisioning" which >> currently only is covered by proprietary solutions like the Google Wallet. >> >> Giving in to Google may though be the best for the market since a leading >> vendor can (as Microsoft did in the past) indirectly enforce the necessary >> "compliance" on the other parties. >> >> The opportunity for a standard addressing 5-10 BILLION of connected >> devices >> won't exist 3 years from now, at least if we are talking about a *used* >> ditto. >> >> If you are the daring type you might even perform a straw poll on the >> topic :-) >> >> Anders >> >> >> >> On 2012-03-16 17:19, Stefan Santesson wrote: >>> I have posted a preliminary agenda at: >>> http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt >>> >>> I do lack presentations on current ongoing drafts. >>> If you are currently editing a PKIX WG draft, please notify me and Steve >>> if you need an agenda slot or not >>> >>> >>> /Stefan >>> >>> >>> On 12-02-28 11:49 PM, "Stephen Kent" wrote: >>> >>>> Folks, >>>> >>>> I have already sent a message noting our meeting day/time/room. >>>> >>>> Please let Stefan and me know if you want a slot on the agenda. >>>> >>>> Thanks, >>>> >>>> Steve >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > From paul.hoffman@vpnc.org Sat Mar 17 08:01:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E321F8622 for ; Sat, 17 Mar 2012 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYuiATSzOjnS for ; Sat, 17 Mar 2012 08:01:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C997F21F85CF for ; Sat, 17 Mar 2012 08:01:04 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2HF12j9081200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2012 08:01:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> Date: Sat, 17 Mar 2012 08:01:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0997BB15-B7F6-4ED4-9412-C05F0EA5F85A@vpnc.org> References: , <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> To: Ryan Hurst X-Mailer: Apple Mail (2.1257) Cc: PKIX Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 15:01:05 -0000 My reading of the Microsoft and Mozilla requirements is that the serial = number must have a random component of the given size, but does not have = to be all random. After the Lenstra paper came out, some CAs went to = serial numbers that were sequential (the high-order bits were a counter) = with a random component in the low-order bits. That scheme does seem to = work for the Microsoft and Mozilla rules as long as the serial number is = greater than 64 or 20 bits long, respectively. Of course, it is up to = Microsoft and Mozilla to decide this, not us. --Paul Hoffman From piyush@identicate.com Sat Mar 17 08:01:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FDA21F865D for ; Sat, 17 Mar 2012 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHv8Vw4Ho6uo for ; Sat, 17 Mar 2012 08:01:11 -0700 (PDT) Received: from col0-omc1-s13.col0.hotmail.com (col0-omc1-s13.col0.hotmail.com [65.55.34.23]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1221F8649 for ; Sat, 17 Mar 2012 08:01:11 -0700 (PDT) Received: from COL119-W17 ([65.55.34.7]) by col0-omc1-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 08:01:11 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9455d389-678a-45b1-ac08-e7b085197f61_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: Date: Sat, 17 Mar 2012 08:01:10 -0700 Importance: Normal In-Reply-To: <4F62F10A.9040604@ripe.net> References: , , <4F62F10A.9040604@ripe.net> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2012 15:01:11.0241 (UTC) FILETIME=[CA591B90:01CD044E] Cc: pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 15:01:12 -0000 --_9455d389-678a-45b1-ac08-e7b085197f61_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Fri=2C 16 Mar 2012 08:51:38 +0100 > From: robert@ripe.net > To: piyush@identicate.com > CC: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP >=20 >=20 > > With the range approach=2C the responder can just create one response w= hich > > says=2C start serial is 1=2C end serial is 10000 and the status is good= . >=20 > But then it only applies if the serial is actually a sequence number=3BIt= applies for non sequential serial numbers as well. Actually=2C it is impos= sible (in practice) to pre-sign responses for non sequential CAs if the res= ponder does not have access to the list of issued serial numbers. In most e= nterprise deployments=2C that's the case. Consider this example where CRL has 2 entries00-12.........................= ...................34 andFF-FE.............................................= FD A detached responder cannot presign responses based on this CRL because ran= ge of non revoked certificates is too big. If there is a provision for rang= e responses=2C the responder can pre-sign following 5 entries and capture a= ll the information provided in the CRL.1. -infinity to 00-12...............= .............................34 - 1 (good)2. 00-12........................= ....................34 (revoked)3. 00-12...................................= .........34 to FF-FE.............................................FD (good)4= . FF-FE.............................................FD (revoked)5 FF-FE....= .........................................FD to +infinity (good)=20 > there's zero benefit in case the serial is a hash or semi-random value. A= re > there CAs out there that still use sequence numbers? >=20 > Robert >=20 = --_9455d389-678a-45b1-ac08-e7b085197f61_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Fri=2C 16 M= ar 2012 08:51:38 +0100
>=3B From: robert@ripe.net
>=3B To: piyush= @identicate.com
>=3B CC: pkix@ietf.org
>=3B Subject: Re: [pkix] R= ange responses in OCSP
>=3B
>=3B
>=3B >=3B With the rang= e approach=2C the responder can just create one response which
>=3B &g= t=3B says=2C start serial is 1=2C end serial is 10000 and the status is goo= d.
>=3B
>=3B But then it only applies if the serial is actually = a sequence number=3B
It applies for non sequential serial numbers= as well. Actually=2C it is impossible (in practice) to pre-sign responses = for non sequential CAs if the responder does not have access to the list of= issued serial numbers. In most enterprise deployments=2C that's the case.<= /div>

Consider this example where CRL has 2 entries
00-12............................................34 and
FF-= FE.............................................FD

= A detached responder cannot presign responses based on this CRL because ran= ge of non revoked certificates is too big. If there is a provision for rang= e responses=2C the responder can pre-sign following 5 entries and capture a= ll the information provided in the CRL.
1. -infinity to =3B00-12....................................= ........34 - 1  =3B(good)
2. =3B00-12.........= ...................................34 (revoked)
3. =3B00-12............................................34 to =3B= FF-FE..................................= ...........FD (good)
4= . =3BFF-FE..................= ...........................FD (revoked)
5 =3BFF-FE= .............................................FD to +infinity (good)<= /div>
 =3B

>=3B there's zero benefit in = case the serial is a hash or semi-random value. Are
>=3B there CAs out= there that still use sequence numbers?
>=3B =3B


>=3B Robert
>=3B
= --_9455d389-678a-45b1-ac08-e7b085197f61_-- From SChokhani@cygnacom.com Sat Mar 17 08:15:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D5521F8649 for ; Sat, 17 Mar 2012 08:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3RkMQ4Sd47m for ; Sat, 17 Mar 2012 08:15:35 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA6921F8642 for ; Sat, 17 Mar 2012 08:15:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,602,1325480400"; d="scan'208,217";a="4426605" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 17 Mar 2012 11:15:34 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 17 Mar 2012 11:15:34 -0400 From: Santosh Chokhani To: "pkix@ietf.org" Date: Sat, 17 Mar 2012 11:15:33 -0400 Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0ETuSP1FPTDx+hRjSyJkvNQO1+IgAAFCLA Message-ID: References: , , <4F62F10A.9040604@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BAA7scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 15:15:37 -0000 --_000_B83745DA469B7847811819C5005244AF0F60BAA7scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the hash collision, why not add random skew to the validity period and = leave the serial number alone as sequential. Another option which is really cool, but will screw some or all application= s is to put randomness in the parameters field of signature field since thi= s is supposed to be ignored anyway. I see little benefit from security vie= wpoint to verify that the parameters are "NULL" (e.g.. for RSA). I do not see why MSFT or Mozilla should dictate a solution when better opti= ons can be had to defeat the collision threat. Finally, the number of bits is also an issue in my mind. One should not wo= rry about bit security, but work factor. Given, the time it takes to craft= a collision attack and even if you give the attacker a generous speed of o= ne hour, 20 bits of randomness is more than sufficient since it results in = over one million possibilities and 100 year work factor. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain Sent: Saturday, March 17, 2012 11:01 AM To: robert@ripe.net Cc: pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP > Date: Fri, 16 Mar 2012 08:51:38 +0100 > From: robert@ripe.net > To: piyush@identicate.com > CC: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP > > > > With the range approach, the responder can just create one response whi= ch > > says, start serial is 1, end serial is 10000 and the status is good. > > But then it only applies if the serial is actually a sequence number; It applies for non sequential serial numbers as well. Actually, it is impos= sible (in practice) to pre-sign responses for non sequential CAs if the res= ponder does not have access to the list of issued serial numbers. In most e= nterprise deployments, that's the case. Consider this example where CRL has 2 entries 00-12............................................34 and FF-FE.............................................FD A detached responder cannot presign responses based on this CRL because ran= ge of non revoked certificates is too big. If there is a provision for rang= e responses, the responder can pre-sign following 5 entries and capture all= the information provided in the CRL. 1. -infinity to 00-12............................................34 - 1 (g= ood) 2. 00-12............................................34 (revoked) 3. 00-12............................................34 to FF-FE............= .................................FD (good) 4. FF-FE.............................................FD (revoked) 5 FF-FE.............................................FD to +infinity (good) > there's zero benefit in case the serial is a hash or semi-random value. A= re > there CAs out there that still use sequence numbers? > > Robert > --_000_B83745DA469B7847811819C5005244AF0F60BAA7scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the hash= collision, why not add random skew to the validity period and leave the se= rial number alone as sequential.

=  

Another option whi= ch is really cool, but will screw some or all applications is to put random= ness in the parameters field of signature field since this is supposed to b= e ignored anyway.  I see little benefit from security viewpoint to ver= ify that the parameters are “NULL” (e.g.. for RSA).<= /span>

 

I do not see why MSFT or Mozilla should dictate a solution whe= n better options can be had to defeat the collision threat.

 

Finally, the number of bits is also an issue in my mind.  One= should not worry about bit security, but work factor.  Given, the tim= e it takes to craft a collision attack and even if you give the attacker a = generous speed of one hour, 20 bits of randomness is more than sufficient s= ince it results in over one million possibilities and 100 year work factor.=

 

=

From: pkix-bounces@ietf.org [mailto:pkix-b= ounces@ietf.org] On Behalf Of Piyush Jain
Sent: Saturday, = March 17, 2012 11:01 AM
To: robert@ripe.net
Cc: pkix@ie= tf.org
Subject: Re: [pkix] Range responses in OCSP

 

 

> Date: Fri, 16 Mar 2012 08:51:38 +0100
> From: robert@ripe.net
> To: piyush@identicate.com
> CC: pkix@ietf.org
> Subject: Re: [pkix] Range respo= nses in OCSP
>
>
> > With the range approach, the re= sponder can just create one response which
> > says, start serial = is 1, end serial is 10000 and the status is good.
>
> But then= it only applies if the serial is actually a sequence number;

It applies for non sequential serial number= s as well. Actually, it is impossible (in practice) to pre-sign responses f= or non sequential CAs if the responder does not have access to the list of = issued serial numbers. In most enterprise deployments, that's the case.

 

Consider this example where CRL has 2 entries=

00-12...................................= .........34 and

FF-FE.........= ....................................FD

 

A detached res= ponder cannot presign responses based on this CRL because range of non revo= ked certificates is too big. If there is a provision for range responses, t= he responder can pre-sign following 5 entries and capture all the informati= on provided in the CRL.

1. -in= finity to 00-12............................................34 - 1 &nbs= p;(good)

2. 00-12......= ......................................34 (revoked)

3. 00-12.........................................= ...34 to FF-FE.............................................FD (good)

4. FF-FE..................= ...........................FD (revoked)

5 FF-FE.............................................FD to +i= nfinity (good)

 

 

> there's zero benefit in case the serial is a hash or sem= i-random value. Are
> there CAs out there that still use sequence num= bers?
> 

 = ;


> Robert
>

= --_000_B83745DA469B7847811819C5005244AF0F60BAA7scygexch7cygnac_-- From SChokhani@cygnacom.com Sat Mar 17 08:22:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4034C21F8589 for ; Sat, 17 Mar 2012 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke5DaltlUtxP for ; Sat, 17 Mar 2012 08:22:25 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id A22A821F84F7 for ; Sat, 17 Mar 2012 08:22:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,602,1325480400"; d="scan'208";a="4426622" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 17 Mar 2012 11:22:24 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 17 Mar 2012 11:22:24 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Sat, 17 Mar 2012 11:22:22 -0400 Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: Ac0DuKXIPs7DK1i3TkqV7xoabtJKVwAmGdGQ Message-ID: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 15:22:26 -0000 I did not mean to insult you. May be I am just a harsh critique. I see several folks posting a lot on this forum without thinking security a= spects through.=20 Since PKI's main purpose is security, we need to design features that aid o= r provide security and not false sense of security. BTW, you may want to examine your prior post on parameter inheritance for E= C and cross certified CA carefully and see what was ludicrous about it. Th= at is your homework assignment. Now, do not feel insulted. I am just bein= g tough. It will help sharpen your security analysis skills. Consider all= this as free tutoring. :-) -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Friday, March 16, 2012 5:06 PM To: Santosh Chokhani Cc: David A. Cooper; pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response That might have been a good point if you hadn't started with a personal ins= ult. The mere fact that a feature is in PKIX does not mean we have to allow its = use. Clearly any observational feedback system (e.g. EFF Observatory, Conve= rgence) would look for such a certificate and flag it as unusual. But given the circumstances you cite, wouldn't the much easier path be for = the attacker to simply issue themselves a cross certificate with cert signi= ng capability? In real life an attacker would be rather unlikely to favor that approach be= cause it would likely trigger secondary controls within the CA that are the= re to detect certs with the cert signing bit set. Your post tells me that I= should consider this particular PKIX feature as another red flag (but my c= ontrols tend to describe what is strictly allowed rather than denied in any= case). On Fri, Mar 16, 2012 at 4:50 PM, Santosh Chokhani = wrote: > PHB never disappoints me in his understanding (or shall I say lack thereo= f) when it comes to security. > > If the CA is compromised, the attacker will issue a delegated OCSP certif= icate and put that pointer in the certificate that the attacker minted. =A0= It does not even have to do DNS poisoning to point to a rogue responder. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Phillip Hallam-Baker > Sent: Friday, March 16, 2012 4:41 PM > To: David A. Cooper > Cc: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response > > The advantage is that it allows external parties to determine that a tota= l compromise has occurred and defenestrate the root. > > So in the DigiNotar case there were three separate problems > > 1) The CA was completely breached and issued false certificates that=20 > the CA had no record of > 2) A significant time elapsed before the CA was aware that the breach=20 > had occurred > 3) An even longer time elapsed before the breach was independently discov= ered and remediation efforts could start. > > Now with the proposed scheme the attacker can still issue false certifica= tes but any attempt to cover their tracks by deleting the log files will re= sult in the CA issuing the OCSP status 'Does not exist' > and cause the breach to be observable externally. Contrawise if they do n= ot delete the logs, the CA will have a record of the bogus certs that were = issued. > > In the past it was considered axiomatic that a CA will never ever be brea= ched. Now we have to address that as a possibility and deploy mechanisms th= at can detect that eventuality. > > > On Fri, Mar 16, 2012 at 2:16 PM, David A. Cooper = wrote: >> Phil, >> >> The supposed advantages of adding a 'does not exist' response=20 >> continue to elude me. =A0Back in November I explained in detail why I=20 >> didn't believe that adding this new response would provide much in=20 >> the way of additional security, and if anything might only create a=20 >> false sense of security (see=20 >> http://www.ietf.org/mail-archive/web/pkix/current/msg29983.html). =A0I=20 >> only received two responses to my message, and both were proposing=20 >> substantial changes to the PKI trust architecture, and neither=20 >> supported the idea that adding a 'does not exist' status response=20 >> (without making other significant >> changes) would provide a significant advantage. >> >> So, could you respond to my earlier message and explain why simply=20 >> adding a 'does not exist' status does more than provide a false sense=20 >> of added confidence? >> >> Dave >> >> >> On 03/16/2012 01:38 PM, Phillip Hallam-Baker wrote: >>> >>> Denis, >>> >>> I agree with the points you raise but: >>> >>> 1) The whole purpose of this proposal is to enable a re-engineering=20 >>> of CA architecture so that we eliminate 'single break' systems. At=20 >>> the moment there is only a modest security advantage to separating=20 >>> out the OCSP HSM from the cert signing HSM, but as your analysis=20 >>> shows having a strong response for 'does not exist' changes that. >>> >>> 2) SCVP is complicated because the problem it solves is very complex. >>> The problem of enabling a 'does not exist' certificate status is=20 >>> much simpler and a direct and logical extension of what OCSP already do= es. >>> >>> >>> On Fri, Mar 16, 2012 at 12:23 PM, =A0wrote: >>>> >>>> Paul, >>>> >>>> I agree with you that it is possible to extend OCSP, as long as=20 >>>> additional status information is related to information available=20 >>>> by the CA that has issued the certificate. In particular, since CRL=20 >>>> is a "black list" mechanism, OCSP is able to use a "white list" >>>> mechanism. This is where "not issued" has a meaning. >>>> >>>> However, the benefit of using a white list mechanism is only a=20 >>>> small advantage in case the CA is compromised. >>>> If everything has been compromised in the CA premises, then there=20 >>>> is no >>>> =A0advantage at all. >>>> >>>> The only advantage is when the CA compromission is only partial and=20 >>>> when the forged certificate has not been able to be included in the=20 >>>> log of issued certificates. >>>> >>>> For example, the HSM has been used directly to create a forged=20 >>>> certificate. >>>> >>>> The danger is that people might think that white list mechanisms=20 >>>> are much better than black list mechanisms, whereas this is not as=20 >>>> straight. >>>> >>>> Denis >>>> >>>> PS. SCVP complexity is about 10 times the complexity of OCSP, hence=20 >>>> why it is and will not be not widely deployed. >>>> >>>> PS 2. the previous message was sent before my message was finished. >>>> >>>> >>>> >>>> >>>> De : =A0 =A0 =A0 =A0Paul Hoffman A : =A0 =A0 = =A0 =A0Phillip=20 >>>> Hallam-Baker Cc : =A0 =A0 =A0 =A0pkix@ietf.org Date = : >>>> 16/03/2012 16:27 Objet : =A0 =A0 =A0 =A0Re: [pkix] PROPOSAL: SCVP to=20 >>>> HISTORIC Envoy=E9 par : =A0 =A0 =A0 =A0pkix-bounces@ietf.org=20 >>>> ________________________________ >>>> >>>> >>>> >>>> You earlier asked if anyone used SCVP, and there was the answer: >>>> >>>>> A bunch of Govt. Agencies in the U.S. Mostly enterprise=20 >>>>> deployments. No public CAs use it. >>>> >>>> It is irresponsible for a public CA to request a protocol that is=20 >>>> known to be deployed to be moved to Historic simply because=20 >>>> companies like itself do not use it, even if other entities are=20 >>>> known to use it. The PKIX WG makes protocols that are useful to a=20 >>>> wide range of entities, not just public CAs. >>>> >>>> Having said that, I disagree with Steve Kent's argument that if=20 >>>> something is "better" done in SCVP, it cannot be done in OCSP. I=20 >>>> agree with Phill that any status of a certificate, including that=20 >>>> it was not issues or is expired, is still status and should be able=20 >>>> to be represented in a well-deployed protocol such as OCSP. >>>> >>>> --Paul Hoffman >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From anders.rundgren@telia.com Sat Mar 17 08:26:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6132721F853E for ; Sat, 17 Mar 2012 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRA1Dk6XPKUH for ; Sat, 17 Mar 2012 08:26:01 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id EA12121F852A for ; Sat, 17 Mar 2012 08:26:00 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D001CB69D; Sat, 17 Mar 2012 16:25:59 +0100 Message-ID: <4F64ACFC.9050908@telia.com> Date: Sat, 17 Mar 2012 16:25:48 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Authentication context QC statement X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 15:26:02 -0000 Stefan, I have no objections whatsoever to the proposed extension. What the proposal does however, is *indirectly* pointing to the fact that client-side PKI doesn't work particularly well for consumers. This has nothing to do with the greatly oversold claim that a certificate must be usable everywhere, but due to the fact that there is a bunch of missing standards, serving this specific market and usage. Another plausible explanation is that the Swedish government are doing strange things which calls for unusual solutions. Regardless what the reason(s) may be, something seems pretty wrong here, particularly from a standardization perspective. Anders On 2012-03-16 19:04, Stefan Santesson wrote: > This is an issue that I preliminarily set on the agenda. > > I'll keep it there unless a discussion following this mail proves my need > to be unnecessary. > > > The background of the need is certificates issued, using a SAML assertion > as means of authenticating the the user in the enrollment process. > The specific application is a central signing service offering users the > capability to sign by simply authenticating to the signing service and > accept to sign some data. The signing service will then generate a key > pair on behalf of that user, issue a signing certificate and sign the > document using the generated key. > > This is a signing model that currently is considered as a solution for > allowing citizens to sign for example tax declarations in sweden. > > Now, the signing service will get the user's identity from a SAML > assertion and then squeeze it into a subject name. > Eventually this will cause some loss of semantics as the flavor of > attributes in SAML federations are a lot larger than the set of attributes > normally required in PKI standards, such as RFC 3739 (Qualified certs). > > In a prototype signing service I have created, I needed a way to capture > this delta in the certificate, by including information about the SAML > assertion used to authenticate the used into the cert itself. > > I have looked at other solutions to this problems. > One proposed way to do this is to include the complete SAML assertion in a > certificate extension. > > I don't like that for several reasons: > - First, and most importantly it is an integrity problem. I may not want > to give away all information in the SAML assertion in the cert I'm issuing. > - Secondly it explodes the size of a regular cert too include a full XML > based assertion, for no obvious gain. > > For our prototype service I simply created a simple QC statement (as this > is purely an issue for QC like certs) where I would allow arbitrary base64 > encoded data in an IA5String marking identifying the encoded data format > with a MIME type and an OID for the internal datastucture. > > > Here is a printout example of this statement from a sample cert, where I > stuffed the data in JSON format: > > QCStatement 6: AuthContextQCStatement > eID2SAMLContext (1.2.752.59.54138.2.1.1) > Content type: application/json > { > "authContextInfo": [ > { "name": "AuthType", "value": "shibboleth" }, > { "name": "Shib-Application-ID", "value": "eid2csig" }, > { "name": "Shib-Identity-Provider", "value": > "https://eidm.demo.ubisecure.com/uas" }, > { "name": "Shib-Authentication-Instant", "value": > "2012-03-16T17:42:09.488Z" }, > { "name": "Shib-AuthnContext-Decl", "value": > "https://eidm.demo.ubisecure.com/uas/saml2/names/ac/password.2" } ], > "idAttributes": [ > { "name": "displayName", "id": "urn:oid:2.16.840.1.113730.3.1.241", > "value": "stefan@aaa-sec.com" }, > { "name": "sn", "id": "urn:oid:2.5.4.4", "value": "Santesson" }, > { "name": "givenName", "id": "urn:oid:2.5.4.42", "value": "Stefan" }, > { "name": "personalIdentityNumber", "id": "urn:oid:1.2.752.29.4.13", > "value": "194103219202" }, > { "name": "mail", "id": "urn:oid:0.9.2342.19200300.100.1.3", "value": > "stefan@aaa-sec.com" }, > { "name": "mobileTelephoneNumber", "id": > "urn:oid:0.9.2342.19200300.100.1.41", "value": "+46767861337" }, > { "name": "persistent-id", "id": "urn:oid:1.3.6.1.4.1.5923.1.1.1.10", > "value": "52000fcc4f024c2a99dd8e6989ee319d9af3af3e" } > ] } > > > The ASN.1 content of the statement is: > > SEQUENCE(2 elem) > OBJECT IDENTIFIER1.2.752.59.54138.2.1.1 > SEQUENCE(2 elem) > PrintableString "application/json" > IA5String "eyJhdXRoQ29udGV4dEluZm8iOlt7Im... > > > The OID is my private identifier for the data structure hold in the > IA5String > The IA5String holds base64encoded JSON as described in the example above. > > This is only supposed to be used within a community that understands this > structure. > It effectively allows mapping between federated identities communicated in > SAML assertions and identities stored in signature certificates based on > the same federated identity. > > > QUESTIONS TO THE WG: > > Is there anything of this that would be suitable for PKIX, mainly to add > the QC statement (but not my private JSON structure)? > Is there another way to do this that would be better? > Or is there a reason why I should not do this at all? > > /Stefan > > > > > > > > > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From ryan.hurst@globalsign.com Sat Mar 17 09:19:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496221F85CD for ; Sat, 17 Mar 2012 09:19:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmVFS+GfaHca for ; Sat, 17 Mar 2012 09:19:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36421F85B9 for ; Sat, 17 Mar 2012 09:19:31 -0700 (PDT) Received: by dakl33 with SMTP id l33so8674660dak.31 for ; Sat, 17 Mar 2012 09:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id:x-mailer :thread-index:content-language:mime-version:content-type :x-gm-message-state; bh=PoIWEvDlEIbnwBCQTg79ogjgVrB2m0KEgPALlFKP074=; b=GHzuhVAn23YBw0p0J9MoqzOqrrj7yFEBk89CLVZusfSJult0nL3UCUMdVe6rlyTdi/ GXBcJlv/7V7QewA1oLeIGXPz+vyjrzjdC99xNt+/AF7MljgnuyLv8GvVJlzTaieqJrHi FrCBSgp0j2IzGBGgg8ENP1nLExACoSTaZ23l7Esp7f1u9RrTae/DHByabQJQLODeS1Db FSLfHhO0RgGehSflQDRSW63OK0d/H59dG1I/dP1gpt2Nvu6TgVxRR6rUpr1SCzIBAQQA Xg92KGOqs1lTztACvLp4T+xl4c5vowC5WqKoIV9teCzERnsRvrCxQh64Hs3JPqSXdWh+ jONQ== Received: by 10.68.222.227 with SMTP id qp3mr18825691pbc.137.1332001171333; Sat, 17 Mar 2012 09:19:31 -0700 (PDT) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id d4sm6951071pbe.36.2012.03.17.09.19.29 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 09:19:30 -0700 (PDT) From: "Ryan Hurst" To: "'Paul Hoffman'" References: , <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> <0997BB15-B7F6-4ED4-9412-C05F0EA5F85A@vpnc.org> In-Reply-To: <0997BB15-B7F6-4ED4-9412-C05F0EA5F85A@vpnc.org> Date: Sat, 17 Mar 2012 09:19:25 -0700 Message-ID: <0e5401cd0459$b9371e10$2ba55a30$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNsp/XD7PxT56WOrq4dYP3sMZz/4wJkklWGAjmlygABsu9R7gI2uqinkusXISA= Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0E4F_01CD041F.0C310990" X-Gm-Message-State: ALoCoQn0Y2toD9nwVCMx8Ryt4/cUkhtrvh0ZF74eWsHNGkAKcl2uT3Dm/JpcEZswnpftIvUz9lWH Cc: 'PKIX' Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 16:19:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E4F_01CD041F.0C310990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul, I agree that the text allows for lower order bits containing the minimum necessary random data and keeping the upper bits sequential as well as other fields where the required randomness can be present. With that said it's my belief that many CAs supported pure random serial numbers and as such quite a few simply enabled this capability as their resolution to the issue highlighted by the Lenstra paper. I am not saying this precludes the project, it just limits its applicability. Ryan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Saturday, March 17, 2012 8:01 AM To: Ryan Hurst Cc: PKIX Subject: Re: [pkix] Range responses in OCSP My reading of the Microsoft and Mozilla requirements is that the serial number must have a random component of the given size, but does not have to be all random. After the Lenstra paper came out, some CAs went to serial numbers that were sequential (the high-order bits were a counter) with a random component in the low-order bits. That scheme does seem to work for the Microsoft and Mozilla rules as long as the serial number is greater than 64 or 20 bits long, respectively. Of course, it is up to Microsoft and Mozilla to decide this, not us. --Paul Hoffman ------=_NextPart_000_0E4F_01CD041F.0C310990 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMTcxNjE5MjVaMCMGCSqG SIb3DQEJBDEWBBTjutOly2KChmfttARI2/+ctT3D/DB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAEjhzeMWr5R6h0i2mG0Oh2x4D+kGGmZ79G4v0bsFPjtgYFAmBt7e3wr/ wkd93SOBcTHP9a6iw0VGq8LT4ftmEym4x3qpT1GihSaLxgtSM11rLrIHeTSSUf+5VTJz66qsthtN Ido3SfFJqZpsOywh7owSwmLzcBR1eUADEr3G2TVhBzIHETrbEhv2uf+HHPTDLzoqca+rriMXvCL0 RpXL9p2+NIG4CK8sW1NREFBRmf3n1UTnzJSSd5StZWeoMs7a0BMDPPkAt2CMp52iQF9/S//f0bFK hnAS2xtFhfZNwB92soI4rLzISjTwGaynzx266aRy7xzyJ4IkJp9403Xckp0AAAAAAAA= ------=_NextPart_000_0E4F_01CD041F.0C310990-- From paul.hoffman@vpnc.org Sat Mar 17 09:32:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3621F8629 for ; Sat, 17 Mar 2012 09:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBTpoilOSt0i for ; Sat, 17 Mar 2012 09:32:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9D21F85F8 for ; Sat, 17 Mar 2012 09:32:26 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2HGWLcv083901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2012 09:32:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0e5401cd0459$b9371e10$2ba55a30$@globalsign.com> Date: Sat, 17 Mar 2012 09:32:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org> References: , <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> <0997BB15-B7F6-4ED4-9412-C05F0EA5F85A@vpnc.org> <0e5401cd0459$b9371e10$2ba55a30$@globalsign.com> To: Ryan Hurst X-Mailer: Apple Mail (2.1257) Cc: 'PKIX' Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 17 Mar 2012 16:32:26 -0000 On Mar 17, 2012, at 9:19 AM, Ryan Hurst wrote: > I agree that the text allows for lower order bits containing the = minimum > necessary random data and keeping the upper bits sequential as well as = other > fields where the required randomness can be present. >=20 > With that said it's my belief that many CAs supported pure random = serial > numbers and as such quite a few simply enabled this capability as = their > resolution to the issue highlighted by the Lenstra paper. >=20 > I am not saying this precludes the project, it just limits its > applicability. Is it possible for someone to do a survey? This seems like something = fairly easy for the CA/Browser Forum to answer. --Paul Hoffman From stefan@aaa-sec.com Sat Mar 17 17:47:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7089A21F8624 for ; Sat, 17 Mar 2012 17:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7Nkt+lSOW+H for ; Sat, 17 Mar 2012 17:47:14 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE021F85CF for ; Sat, 17 Mar 2012 17:47:13 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B958E1D547BA for ; Sun, 18 Mar 2012 01:46:03 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ox3UQ_xLbHZo for ; Sun, 18 Mar 2012 01:46:03 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 23A571D54781 for ; Sun, 18 Mar 2012 01:46:03 +0100 (CET) Received: (qmail 97292 invoked from network); 18 Mar 2012 00:46:02 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.214]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Mar 2012 00:46:02 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 18 Mar 2012 01:45:58 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Agenda requests for Paris In-Reply-To: <4F648D1F.2020306@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 00:47:15 -0000 Anders, You are missing the point. You are free to discuss any issues that are related to the charter of this WG. If you want to discuss things with other IETFers, it is a great opportunity to come to the conference and talk to people. Just don't expect people to spend time discussing your issues at the meeting unless you are prepared to come and ask for a timeslot. /Stefan On 12-03-17 2:09 PM, "Anders Rundgren" wrote: >On 2012-03-17 13:32, Stefan Santesson wrote: >> Anders, >> >> It does not work that way, no matter how interesting your issue might >>be. > >You mean that IETF statutes doesn't permit discussing possible future >work-items without a proposer actually being physically present? > >Anyway, your college in the Swedish EID2-project Leif Johansson, >indeed mentioned the very same issue "as highly problematic" in >a panel session in the IDTrust/NSTIC event that we both attended >this week in Washington DC. > >Somewhat related: From what I can see the rationale for EST haven't >been discussed at all on this list. I don't think even Cisco in the >end will support EST since it doesn't add functional improvements. >Even the target "Simple PKI client" seems to be left to the reader >to guess what it could possibly be. Do YOU know? > >Anders > >> >> If you want to raise an issue at the meeting, then you need to ask for a >> slot and show up at the meeting. >> If you can't be bothered, convince someone that will be present to do it >> for you. >> >> If you can't do that even, then discuss it on the list. >> >> /Stefan >> >> On 12-03-17 9:56 AM, "Anders Rundgren" >>wrote: >> >>> Stefan, >>> I will unfortunately not be able to attend. >>> >>> May I suggest that the crowd spends some 10 minutes on discussing how >>>PKIX >>> intends to deal with the fact that mobile devices with embedded >>> credentials >>> will most likely constitute of the bulk of the client-side of PKI? >>> >>> Even the US government have realized (it took some time...) that >>> "Derived Credentials" is probably a better solution than >>> "putting PIV on a string": >>> >>> >>>http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nis >>>t- >>> 800-63-1_overview_enewton.pdf >>> >>> It is (at least to me) obvious that ambitious efforts such as President >>> Obama's NSTIC program won't go particularly far without having secure, >>> convenient, and interoperable enrollment solutions. >>> >>> However, then we enter the minefield known as "Token Provisioning" >>>which >>> currently only is covered by proprietary solutions like the Google >>>Wallet. >>> >>> Giving in to Google may though be the best for the market since a >>>leading >>> vendor can (as Microsoft did in the past) indirectly enforce the >>>necessary >>> "compliance" on the other parties. >>> >>> The opportunity for a standard addressing 5-10 BILLION of connected >>> devices >>> won't exist 3 years from now, at least if we are talking about a *used* >>> ditto. >>> >>> If you are the daring type you might even perform a straw poll on the >>> topic :-) >>> >>> Anders >>> >>> >>> >>> On 2012-03-16 17:19, Stefan Santesson wrote: >>>> I have posted a preliminary agenda at: >>>> http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt >>>> >>>> I do lack presentations on current ongoing drafts. >>>> If you are currently editing a PKIX WG draft, please notify me and >>>>Steve >>>> if you need an agenda slot or not >>>> >>>> >>>> /Stefan >>>> >>>> >>>> On 12-02-28 11:49 PM, "Stephen Kent" wrote: >>>> >>>>> Folks, >>>>> >>>>> I have already sent a message noting our meeting day/time/room. >>>>> >>>>> Please let Stefan and me know if you want a slot on the agenda. >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> > From stefan@aaa-sec.com Sat Mar 17 17:51:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1CB21F8599 for ; Sat, 17 Mar 2012 17:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trWJ8DdDWO3C for ; Sat, 17 Mar 2012 17:51:51 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1D25F21F84CF for ; Sat, 17 Mar 2012 17:51:51 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2278D1D546EC for ; Sun, 18 Mar 2012 01:50:16 +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 7DdN_plEZwVf for ; Sun, 18 Mar 2012 01:50:15 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E17C01D54637 for ; Sun, 18 Mar 2012 01:50:15 +0100 (CET) Received: (qmail 5542 invoked from network); 18 Mar 2012 00:50:15 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.214]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Mar 2012 00:50:15 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 18 Mar 2012 01:50:05 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Authentication context QC statement In-Reply-To: <4F64ACFC.9050908@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Authentication context QC statement X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 00:51:51 -0000 Stefan On 12-03-17 4:25 PM, "Anders Rundgren" wrote: >I have no objections whatsoever to the proposed extension. ... >Regardless what the reason(s) may be, something seems pretty wrong here, >particularly from a standardization perspective. These two statements seems to contradict each other. Or am I missing something? My post is not about the Swedish infrastructure. That is just a use case. Try viewing the proposal from a generic perspective. Is it generally useful. If not, it has no place in a standard. /Stefan From anders.rundgren@telia.com Sun Mar 18 02:37:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5678F21F85C2 for ; Sun, 18 Mar 2012 02:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m+Z69X0-Bl7 for ; Sun, 18 Mar 2012 02:37:53 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 250A721F85B5 for ; Sun, 18 Mar 2012 02:37:53 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D001DFF0E; Sun, 18 Mar 2012 10:37:51 +0100 Message-ID: <4F65ACE3.1050307@telia.com> Date: Sun, 18 Mar 2012 10:37:39 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 09:37:59 -0000 On 2012-03-18 01:45, Stefan Santesson wrote: > Anders, > > You are missing the point. Not really, I'm just looking at things from a different angle. IMHO, "relevance" has become an overarching issue for SDOs due to the fact that the IT-landscape has changed tremendously the last ten years: - Continuously shorter product cycles - Vendors that single-handedly define complete and globally operating ecosystems, from devices to services - Open source as a means to reduce costs and improve interoperability Since "my" issue (affecting billions of other humans) obviously is not of any interest to you or Steve, PKIX's future probably is about managing the PKI core documents (Certificates, CRL and OCSP). Thar said, new efforts in the more application-oriented part of the PKI universe, like the recent EST work-item seems much less likely to pan out since these require alien elements like strategy, marketing, and gap analysis. OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to be a major issue. In my world deployment and relevance are synonymous. Yes, I know this is a minority view :-) Anders > > You are free to discuss any issues that are related to the charter of this > WG. > If you want to discuss things with other IETFers, it is a great > opportunity to come to the conference and talk to people. > > Just don't expect people to spend time discussing your issues at the > meeting unless you are prepared to come and ask for a timeslot. > > /Stefan > > > > On 12-03-17 2:09 PM, "Anders Rundgren" wrote: > >> On 2012-03-17 13:32, Stefan Santesson wrote: >>> Anders, >>> >>> It does not work that way, no matter how interesting your issue might >>> be. >> >> You mean that IETF statutes doesn't permit discussing possible future >> work-items without a proposer actually being physically present? >> >> Anyway, your college in the Swedish EID2-project Leif Johansson, >> indeed mentioned the very same issue "as highly problematic" in >> a panel session in the IDTrust/NSTIC event that we both attended >> this week in Washington DC. >> >> Somewhat related: From what I can see the rationale for EST haven't >> been discussed at all on this list. I don't think even Cisco in the >> end will support EST since it doesn't add functional improvements. >> Even the target "Simple PKI client" seems to be left to the reader >> to guess what it could possibly be. Do YOU know? >> >> Anders >> >>> >>> If you want to raise an issue at the meeting, then you need to ask for a >>> slot and show up at the meeting. >>> If you can't be bothered, convince someone that will be present to do it >>> for you. >>> >>> If you can't do that even, then discuss it on the list. >>> >>> /Stefan >>> >>> On 12-03-17 9:56 AM, "Anders Rundgren" >>> wrote: >>> >>>> Stefan, >>>> I will unfortunately not be able to attend. >>>> >>>> May I suggest that the crowd spends some 10 minutes on discussing how >>>> PKIX >>>> intends to deal with the fact that mobile devices with embedded >>>> credentials >>>> will most likely constitute of the bulk of the client-side of PKI? >>>> >>>> Even the US government have realized (it took some time...) that >>>> "Derived Credentials" is probably a better solution than >>>> "putting PIV on a string": >>>> >>>> >>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nis >>>> t- >>>> 800-63-1_overview_enewton.pdf >>>> >>>> It is (at least to me) obvious that ambitious efforts such as President >>>> Obama's NSTIC program won't go particularly far without having secure, >>>> convenient, and interoperable enrollment solutions. >>>> >>>> However, then we enter the minefield known as "Token Provisioning" >>>> which >>>> currently only is covered by proprietary solutions like the Google >>>> Wallet. >>>> >>>> Giving in to Google may though be the best for the market since a >>>> leading >>>> vendor can (as Microsoft did in the past) indirectly enforce the >>>> necessary >>>> "compliance" on the other parties. >>>> >>>> The opportunity for a standard addressing 5-10 BILLION of connected >>>> devices >>>> won't exist 3 years from now, at least if we are talking about a *used* >>>> ditto. >>>> >>>> If you are the daring type you might even perform a straw poll on the >>>> topic :-) >>>> >>>> Anders >>>> >>>> >>>> >>>> On 2012-03-16 17:19, Stefan Santesson wrote: >>>>> I have posted a preliminary agenda at: >>>>> http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt >>>>> >>>>> I do lack presentations on current ongoing drafts. >>>>> If you are currently editing a PKIX WG draft, please notify me and >>>>> Steve >>>>> if you need an agenda slot or not >>>>> >>>>> >>>>> /Stefan >>>>> >>>>> >>>>> On 12-02-28 11:49 PM, "Stephen Kent" wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> I have already sent a message noting our meeting day/time/room. >>>>>> >>>>>> Please let Stefan and me know if you want a slot on the agenda. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>>> >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> >> > > > From ynir@checkpoint.com Sun Mar 18 04:15:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1893D21F8687 for ; Sun, 18 Mar 2012 04:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPUW5pMmHIQm for ; Sun, 18 Mar 2012 04:15:40 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A06AE21F867C for ; Sun, 18 Mar 2012 04:15:39 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2IBFZ5V007366; Sun, 18 Mar 2012 13:15:35 +0200 X-CheckPoint: {4F65C380-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 18 Mar 2012 13:15:34 +0200 From: Yoav Nir To: "'Anders Rundgren'" , Stefan Santesson Date: Sun, 18 Mar 2012 13:15:34 +0200 Thread-Topic: [pkix] Agenda requests for Paris Thread-Index: Ac0E6tYArCCPq940QMWyfPprkkZ3oAADBDcw Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> References: <4F65ACE3.1050307@telia.com> In-Reply-To: <4F65ACE3.1050307@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 11:15:41 -0000 Anders, IMO "relevant" is whatever the group decides is relevant as long as the IES= G agrees. If you want the working group to do something, such as mobile dev= ices with embedded credentials, you should propose this to the group.=20 A few years ago I had a proposal to IPsecME but couldn't attend. I asked so= meone else who *was* attending to present it for me. I prepared the slides = and everything, and listened to the audio stream. While there is work being= done (see the vmeet list) that may allow people to present remotely, resul= ts so far have been a mixed bag. Surely you can go to https://www.ietf.org/= registration/ietf83/attendance.py , and find one of the 1347 people listed = there (as of right now) who might be interested enough to present slides th= at you would prepare for him or her.=20 I don't think a time slot reserved for "discussion of the fact that mobile = devices with embedded credentials will most likely constitute of the bulk o= f the client-side of PKI" will do much without a draft, a presentation, or = at the very least, someone to lead the discussion. Yoav -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of And= ers Rundgren Sent: 18 March 2012 11:38 To: Stefan Santesson Cc: pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris On 2012-03-18 01:45, Stefan Santesson wrote: > Anders, >=20 > You are missing the point. Not really, I'm just looking at things from a different angle. IMHO, "relevance" has become an overarching issue for SDOs due to the fact = that the IT-landscape has changed tremendously the last ten years: - Continuously shorter product cycles - Vendors that single-handedly define complete and globally operating ecosy= stems, from devices to services - Open source as a means to reduce costs and improve interoperability Since "my" issue (affecting billions of other humans) obviously is not of a= ny interest to you or Steve, PKIX's future probably is about managing the P= KI core documents (Certificates, CRL and OCSP). Thar said, new efforts in the more application-oriented part of the PKI uni= verse, like the recent EST work-item seems much less likely to pan out sinc= e these require alien elements like strategy, marketing, and gap analysis. OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to be= a major issue. In my world deployment and relevance are synonymous. Yes, I know this is a minority view :-) Anders >=20 > You are free to discuss any issues that are related to the charter of=20 > this WG. > If you want to discuss things with other IETFers, it is a great=20 > opportunity to come to the conference and talk to people. >=20 > Just don't expect people to spend time discussing your issues at the=20 > meeting unless you are prepared to come and ask for a timeslot. >=20 > /Stefan >=20 >=20 >=20 > On 12-03-17 2:09 PM, "Anders Rundgren" wrote: >=20 >> On 2012-03-17 13:32, Stefan Santesson wrote: >>> Anders, >>> >>> It does not work that way, no matter how interesting your issue=20 >>> might be. >> >> You mean that IETF statutes doesn't permit discussing possible future=20 >> work-items without a proposer actually being physically present? >> >> Anyway, your college in the Swedish EID2-project Leif Johansson,=20 >> indeed mentioned the very same issue "as highly problematic" in a=20 >> panel session in the IDTrust/NSTIC event that we both attended this=20 >> week in Washington DC. >> >> Somewhat related: From what I can see the rationale for EST haven't=20 >> been discussed at all on this list. I don't think even Cisco in the=20 >> end will support EST since it doesn't add functional improvements. >> Even the target "Simple PKI client" seems to be left to the reader to=20 >> guess what it could possibly be. Do YOU know? >> >> Anders >> >>> >>> If you want to raise an issue at the meeting, then you need to ask=20 >>> for a slot and show up at the meeting. >>> If you can't be bothered, convince someone that will be present to=20 >>> do it for you. >>> >>> If you can't do that even, then discuss it on the list. >>> >>> /Stefan >>> >>> On 12-03-17 9:56 AM, "Anders Rundgren" >>> wrote: >>> >>>> Stefan, >>>> I will unfortunately not be able to attend. >>>> >>>> May I suggest that the crowd spends some 10 minutes on discussing=20 >>>> how PKIX intends to deal with the fact that mobile devices with=20 >>>> embedded credentials will most likely constitute of the bulk of the=20 >>>> client-side of PKI? >>>> >>>> Even the US government have realized (it took some time...) that=20 >>>> "Derived Credentials" is probably a better solution than "putting=20 >>>> PIV on a string": >>>> >>>> >>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb >>>> 1_nis >>>> t- >>>> 800-63-1_overview_enewton.pdf >>>> >>>> It is (at least to me) obvious that ambitious efforts such as=20 >>>> President Obama's NSTIC program won't go particularly far without=20 >>>> having secure, convenient, and interoperable enrollment solutions. >>>> >>>> However, then we enter the minefield known as "Token Provisioning" >>>> which >>>> currently only is covered by proprietary solutions like the Google=20 >>>> Wallet. >>>> >>>> Giving in to Google may though be the best for the market since a=20 >>>> leading vendor can (as Microsoft did in the past) indirectly=20 >>>> enforce the necessary "compliance" on the other parties. >>>> >>>> The opportunity for a standard addressing 5-10 BILLION of connected=20 >>>> devices won't exist 3 years from now, at least if we are talking=20 >>>> about a *used* ditto. >>>> >>>> If you are the daring type you might even perform a straw poll on=20 >>>> the topic :-) >>>> >>>> Anders From anders.rundgren@telia.com Sun Mar 18 08:30:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1961D21F865C for ; Sun, 18 Mar 2012 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGY2Gd62qJvd for ; Sun, 18 Mar 2012 08:30:50 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1399521F8657 for ; Sun, 18 Mar 2012 08:30:30 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E002B18B5; Sun, 18 Mar 2012 16:30:21 +0100 Message-ID: <4F65FF81.7070007@telia.com> Date: Sun, 18 Mar 2012 16:30:09 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoav Nir References: <4F65ACE3.1050307@telia.com> <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 15:30:52 -0000 On 2012-03-18 12:15, Yoav Nir wrote: > Anders, > > IMO "relevant" is whatever the group decides is relevant as long as the > IESG agrees. If you want the working group to do something, such as mobile > devices with embedded credentials, you should propose this to the group. Once upon time there was a single enterprise OS standard; it was called Windows. Each vendor could easily create s.c. "Windows-compatible" solutions by a bunch of proprietary DLLs and EXEs. These days are gone. Now customers are facing a multitude of mobile devices with quite different software distribution and security models. Currently I'm struggling with a mobile PKI + FW using Cisco's ASA + AnyConnect. The absence of useful enrollment/setup standards in this space force you into "rooted" phones, quirky user-interfaces, least common denominator functionality, and extended deployment times. Unless something in the process (and attitude) changes, I remain convinced that PKIX should stick to the PKI core and leave applications like EST aside. Anders > > A few years ago I had a proposal to IPsecME but couldn't attend. I asked someone else who *was* attending to present it for me. I prepared the slides and everything, and listened to the audio stream. While there is work being done (see the vmeet list) that may allow people to present remotely, results so far have been a mixed bag. Surely you can go to https://www.ietf.org/registration/ietf83/attendance.py , and find one of the 1347 people listed there (as of right now) who might be interested enough to present slides that you would prepare for him or her. > > I don't think a time slot reserved for "discussion of the fact that mobile devices with embedded credentials will most likely constitute of the bulk of the client-side of PKI" will do much without a draft, a presentation, or at the very least, someone to lead the discussion. > > Yoav > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: 18 March 2012 11:38 > To: Stefan Santesson > Cc: pkix@ietf.org > Subject: Re: [pkix] Agenda requests for Paris > > On 2012-03-18 01:45, Stefan Santesson wrote: >> Anders, >> >> You are missing the point. > > Not really, I'm just looking at things from a different angle. > > IMHO, "relevance" has become an overarching issue for SDOs due to the fact that the IT-landscape has changed tremendously the last ten years: > > - Continuously shorter product cycles > - Vendors that single-handedly define complete and globally operating ecosystems, from devices to services > - Open source as a means to reduce costs and improve interoperability > > Since "my" issue (affecting billions of other humans) obviously is not of any interest to you or Steve, PKIX's future probably is about managing the PKI core documents (Certificates, CRL and OCSP). > > Thar said, new efforts in the more application-oriented part of the PKI universe, like the recent EST work-item seems much less likely to pan out since these require alien elements like strategy, marketing, and gap analysis. > > OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to be a major issue. In my world deployment and relevance are synonymous. > Yes, I know this is a minority view :-) > > Anders > >> >> You are free to discuss any issues that are related to the charter of >> this WG. >> If you want to discuss things with other IETFers, it is a great >> opportunity to come to the conference and talk to people. >> >> Just don't expect people to spend time discussing your issues at the >> meeting unless you are prepared to come and ask for a timeslot. >> >> /Stefan >> >> >> >> On 12-03-17 2:09 PM, "Anders Rundgren" wrote: >> >>> On 2012-03-17 13:32, Stefan Santesson wrote: >>>> Anders, >>>> >>>> It does not work that way, no matter how interesting your issue >>>> might be. >>> >>> You mean that IETF statutes doesn't permit discussing possible future >>> work-items without a proposer actually being physically present? >>> >>> Anyway, your college in the Swedish EID2-project Leif Johansson, >>> indeed mentioned the very same issue "as highly problematic" in a >>> panel session in the IDTrust/NSTIC event that we both attended this >>> week in Washington DC. >>> >>> Somewhat related: From what I can see the rationale for EST haven't >>> been discussed at all on this list. I don't think even Cisco in the >>> end will support EST since it doesn't add functional improvements. >>> Even the target "Simple PKI client" seems to be left to the reader to >>> guess what it could possibly be. Do YOU know? >>> >>> Anders >>> >>>> >>>> If you want to raise an issue at the meeting, then you need to ask >>>> for a slot and show up at the meeting. >>>> If you can't be bothered, convince someone that will be present to >>>> do it for you. >>>> >>>> If you can't do that even, then discuss it on the list. >>>> >>>> /Stefan >>>> >>>> On 12-03-17 9:56 AM, "Anders Rundgren" >>>> wrote: >>>> >>>>> Stefan, >>>>> I will unfortunately not be able to attend. >>>>> >>>>> May I suggest that the crowd spends some 10 minutes on discussing >>>>> how PKIX intends to deal with the fact that mobile devices with >>>>> embedded credentials will most likely constitute of the bulk of the >>>>> client-side of PKI? >>>>> >>>>> Even the US government have realized (it took some time...) that >>>>> "Derived Credentials" is probably a better solution than "putting >>>>> PIV on a string": >>>>> >>>>> >>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb >>>>> 1_nis >>>>> t- >>>>> 800-63-1_overview_enewton.pdf >>>>> >>>>> It is (at least to me) obvious that ambitious efforts such as >>>>> President Obama's NSTIC program won't go particularly far without >>>>> having secure, convenient, and interoperable enrollment solutions. >>>>> >>>>> However, then we enter the minefield known as "Token Provisioning" >>>>> which >>>>> currently only is covered by proprietary solutions like the Google >>>>> Wallet. >>>>> >>>>> Giving in to Google may though be the best for the market since a >>>>> leading vendor can (as Microsoft did in the past) indirectly >>>>> enforce the necessary "compliance" on the other parties. >>>>> >>>>> The opportunity for a standard addressing 5-10 BILLION of connected >>>>> devices won't exist 3 years from now, at least if we are talking >>>>> about a *used* ditto. >>>>> >>>>> If you are the daring type you might even perform a straw poll on >>>>> the topic :-) >>>>> >>>>> Anders > From stefan@aaa-sec.com Sun Mar 18 08:44:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0F21F84AE for ; Sun, 18 Mar 2012 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALr0HaE5RKts for ; Sun, 18 Mar 2012 08:44:07 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3B51121F849D for ; Sun, 18 Mar 2012 08:43:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 49D841DC6E0D for ; Sun, 18 Mar 2012 16:43:57 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YZWJCSbeCUKy for ; Sun, 18 Mar 2012 16:43:56 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AF9431DC6D88 for ; Sun, 18 Mar 2012 16:43:56 +0100 (CET) Received: (qmail 32118 invoked from network); 18 Mar 2012 15:43:56 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Mar 2012 15:43:56 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 18 Mar 2012 16:43:36 +0100 From: Stefan Santesson To: Anders Rundgren , Yoav Nir Message-ID: Thread-Topic: [pkix] Agenda requests for Paris In-Reply-To: <4F65FF81.7070007@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 15:44:09 -0000 Anders, Do you have an A shaped teflon non-stick desk at your office? I think it would suit your quite well. /Stefan On 12-03-18 4:30 PM, "Anders Rundgren" wrote: >On 2012-03-18 12:15, Yoav Nir wrote: >> Anders, >> >> IMO "relevant" is whatever the group decides is relevant as long as the >> IESG agrees. If you want the working group to do something, such as >>mobile >> devices with embedded credentials, you should propose this to the group. > >Once upon time there was a single enterprise OS standard; it was called >Windows. >Each vendor could easily create s.c. "Windows-compatible" solutions by a >bunch >of proprietary DLLs and EXEs. > >These days are gone. Now customers are facing a multitude of mobile >devices >with quite different software distribution and security models. > >Currently I'm struggling with a mobile PKI + FW using Cisco's ASA + >AnyConnect. >The absence of useful enrollment/setup standards in this space force you >into >"rooted" phones, quirky user-interfaces, least common denominator >functionality, >and extended deployment times. > >Unless something in the process (and attitude) changes, I remain >convinced that >PKIX should stick to the PKI core and leave applications like EST aside. > >Anders > >> >> A few years ago I had a proposal to IPsecME but couldn't attend. I >>asked someone else who *was* attending to present it for me. I prepared >>the slides and everything, and listened to the audio stream. While there >>is work being done (see the vmeet list) that may allow people to present >>remotely, results so far have been a mixed bag. Surely you can go to >>https://www.ietf.org/registration/ietf83/attendance.py , and find one of >>the 1347 people listed there (as of right now) who might be interested >>enough to present slides that you would prepare for him or her. >> >> I don't think a time slot reserved for "discussion of the fact that >>mobile devices with embedded credentials will most likely constitute of >>the bulk of the client-side of PKI" will do much without a draft, a >>presentation, or at the very least, someone to lead the discussion. >> >> Yoav >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>Anders Rundgren >> Sent: 18 March 2012 11:38 >> To: Stefan Santesson >> Cc: pkix@ietf.org >> Subject: Re: [pkix] Agenda requests for Paris >> >> On 2012-03-18 01:45, Stefan Santesson wrote: >>> Anders, >>> >>> You are missing the point. >> >> Not really, I'm just looking at things from a different angle. >> >> IMHO, "relevance" has become an overarching issue for SDOs due to the >>fact that the IT-landscape has changed tremendously the last ten years: >> >> - Continuously shorter product cycles >> - Vendors that single-handedly define complete and globally operating >>ecosystems, from devices to services >> - Open source as a means to reduce costs and improve interoperability >> >> Since "my" issue (affecting billions of other humans) obviously is not >>of any interest to you or Steve, PKIX's future probably is about >>managing the PKI core documents (Certificates, CRL and OCSP). >> >> Thar said, new efforts in the more application-oriented part of the PKI >>universe, like the recent EST work-item seems much less likely to pan >>out since these require alien elements like strategy, marketing, and gap >>analysis. >> >> OTOH, deployment given the current SCVP/OCSP discussions doesn't seem >>to be a major issue. In my world deployment and relevance are >>synonymous. >> Yes, I know this is a minority view :-) >> >> Anders >> >>> >>> You are free to discuss any issues that are related to the charter of >>> this WG. >>> If you want to discuss things with other IETFers, it is a great >>> opportunity to come to the conference and talk to people. >>> >>> Just don't expect people to spend time discussing your issues at the >>> meeting unless you are prepared to come and ask for a timeslot. >>> >>> /Stefan >>> >>> >>> >>> On 12-03-17 2:09 PM, "Anders Rundgren" >>>wrote: >>> >>>> On 2012-03-17 13:32, Stefan Santesson wrote: >>>>> Anders, >>>>> >>>>> It does not work that way, no matter how interesting your issue >>>>> might be. >>>> >>>> You mean that IETF statutes doesn't permit discussing possible future >>>> work-items without a proposer actually being physically present? >>>> >>>> Anyway, your college in the Swedish EID2-project Leif Johansson, >>>> indeed mentioned the very same issue "as highly problematic" in a >>>> panel session in the IDTrust/NSTIC event that we both attended this >>>> week in Washington DC. >>>> >>>> Somewhat related: From what I can see the rationale for EST haven't >>>> been discussed at all on this list. I don't think even Cisco in the >>>> end will support EST since it doesn't add functional improvements. >>>> Even the target "Simple PKI client" seems to be left to the reader to >>>> guess what it could possibly be. Do YOU know? >>>> >>>> Anders >>>> >>>>> >>>>> If you want to raise an issue at the meeting, then you need to ask >>>>> for a slot and show up at the meeting. >>>>> If you can't be bothered, convince someone that will be present to >>>>> do it for you. >>>>> >>>>> If you can't do that even, then discuss it on the list. >>>>> >>>>> /Stefan >>>>> >>>>> On 12-03-17 9:56 AM, "Anders Rundgren" >>>>> wrote: >>>>> >>>>>> Stefan, >>>>>> I will unfortunately not be able to attend. >>>>>> >>>>>> May I suggest that the crowd spends some 10 minutes on discussing >>>>>> how PKIX intends to deal with the fact that mobile devices with >>>>>> embedded credentials will most likely constitute of the bulk of the >>>>>> client-side of PKI? >>>>>> >>>>>> Even the US government have realized (it took some time...) that >>>>>> "Derived Credentials" is probably a better solution than "putting >>>>>> PIV on a string": >>>>>> >>>>>> >>>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb >>>>>> 1_nis >>>>>> t- >>>>>> 800-63-1_overview_enewton.pdf >>>>>> >>>>>> It is (at least to me) obvious that ambitious efforts such as >>>>>> President Obama's NSTIC program won't go particularly far without >>>>>> having secure, convenient, and interoperable enrollment solutions. >>>>>> >>>>>> However, then we enter the minefield known as "Token Provisioning" >>>>>> which >>>>>> currently only is covered by proprietary solutions like the Google >>>>>> Wallet. >>>>>> >>>>>> Giving in to Google may though be the best for the market since a >>>>>> leading vendor can (as Microsoft did in the past) indirectly >>>>>> enforce the necessary "compliance" on the other parties. >>>>>> >>>>>> The opportunity for a standard addressing 5-10 BILLION of connected >>>>>> devices won't exist 3 years from now, at least if we are talking >>>>>> about a *used* ditto. >>>>>> >>>>>> If you are the daring type you might even perform a straw poll on >>>>>> the topic :-) >>>>>> >>>>>> Anders >> > From ynir@checkpoint.com Sun Mar 18 13:01:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2421F84E1 for ; Sun, 18 Mar 2012 13:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+HmElsQ2fSv for ; Sun, 18 Mar 2012 13:01:24 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5E021F84B4 for ; Sun, 18 Mar 2012 13:01:23 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2IK1JJs019752; Sun, 18 Mar 2012 22:01:19 +0200 X-CheckPoint: {4F663EB3-2-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 18 Mar 2012 22:01:19 +0200 From: Yoav Nir To: Anders Rundgren Date: Sun, 18 Mar 2012 22:01:17 +0200 Thread-Topic: [pkix] Agenda requests for Paris Thread-Index: Ac0FQeGAJuugj7NwRReQrbEvTN5MKQ== Message-ID: <1BC28887-4F62-437A-A117-C833A0968E05@checkpoint.com> References: <4F65ACE3.1050307@telia.com> <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> <4F65FF81.7070007@telia.com> In-Reply-To: <4F65FF81.7070007@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 20:01:25 -0000 Well, PKIX standardized CMC and CMP, and Cisco made SCEP, and none of these= seems particularly tied to Windows as opposed to Mac OS, Linux, phones run= ning iOS, or parallel sysplexes of mainframes running z/OS. It's true that iOS and other operating system (not necessarily "mobile") te= nd to decrease the amount of control given to application writers, so you c= an't just write some application that performs enrollment and store the res= ulting certificate in the operating system store for use by other applicati= ons. Are you proposing some new API or URI scheme where the application can= ask the operating system to perform enrollment using one of the above or a= new protocol? If all these protocols are lacking something, then PKIX woul= d be the right place to discuss it. If you want to standardize "enroll://CN= =3Dsomebody@theCA.example.com" it's probably in PKIX too.=20 If it's just about Apple not letting us use our favorite enrollment protoco= ls, there's not much PKIX can do about it.=20 I find this complaint about attitude strange. This list gets frequent criti= cism from some people (Prof. Gutmann springs to mind) about PKIX being will= ing to standardize anything that looks like ASN.1. This is a group that has= standardized two protocols for enrollment and two protocols for certificat= e status validation. I also haven't seen anything in Stefan's responses tha= t amounts to a rejection of your idea. It's just not clear what that idea i= s. Yes, there are more mobiles out there. Maybe some of them come with embe= dded credentials (that can be used by applications). That this will be the = bulk of client-side PKI is debatable. I'm still missing what we are suppose= d to discuss. What do *you* propose that PKIX do about it? Yoav -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com]=20 Sent: 18 March 2012 17:30 To: Yoav Nir Cc: Stefan Santesson; pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris On 2012-03-18 12:15, Yoav Nir wrote: > Anders, >=20 > IMO "relevant" is whatever the group decides is relevant as long as=20 > the IESG agrees. If you want the working group to do something, such=20 > as mobile devices with embedded credentials, you should propose this to t= he group. Once upon time there was a single enterprise OS standard; it was called Win= dows. Each vendor could easily create s.c. "Windows-compatible" solutions by a bu= nch of proprietary DLLs and EXEs. These days are gone. Now customers are facing a multitude of mobile device= s with quite different software distribution and security models. Currently I'm struggling with a mobile PKI + FW using Cisco's ASA + AnyConn= ect. The absence of useful enrollment/setup standards in this space force you in= to "rooted" phones, quirky user-interfaces, least common denominator functi= onality, and extended deployment times. Unless something in the process (and attitude) changes, I remain convinced = that PKIX should stick to the PKI core and leave applications like EST asid= e. Anders >=20 > A few years ago I had a proposal to IPsecME but couldn't attend. I asked = someone else who *was* attending to present it for me. I prepared the slide= s and everything, and listened to the audio stream. While there is work bei= ng done (see the vmeet list) that may allow people to present remotely, res= ults so far have been a mixed bag. Surely you can go to https://www.ietf.or= g/registration/ietf83/attendance.py , and find one of the 1347 people liste= d there (as of right now) who might be interested enough to present slides = that you would prepare for him or her.=20 >=20 > I don't think a time slot reserved for "discussion of the fact that mobil= e devices with embedded credentials will most likely constitute of the bulk= of the client-side of PKI" will do much without a draft, a presentation, o= r at the very least, someone to lead the discussion. >=20 > Yoav >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Anders Rundgren > Sent: 18 March 2012 11:38 > To: Stefan Santesson > Cc: pkix@ietf.org > Subject: Re: [pkix] Agenda requests for Paris >=20 > On 2012-03-18 01:45, Stefan Santesson wrote: >> Anders, >>=20 >> You are missing the point. >=20 > Not really, I'm just looking at things from a different angle. >=20 > IMHO, "relevance" has become an overarching issue for SDOs due to the fac= t that the IT-landscape has changed tremendously the last ten years: >=20 > - Continuously shorter product cycles > - Vendors that single-handedly define complete and globally operating=20 > ecosystems, from devices to services > - Open source as a means to reduce costs and improve interoperability >=20 > Since "my" issue (affecting billions of other humans) obviously is not of= any interest to you or Steve, PKIX's future probably is about managing the= PKI core documents (Certificates, CRL and OCSP). >=20 > Thar said, new efforts in the more application-oriented part of the PKI u= niverse, like the recent EST work-item seems much less likely to pan out si= nce these require alien elements like strategy, marketing, and gap analysis= . >=20 > OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to = be a major issue. In my world deployment and relevance are synonymous. > Yes, I know this is a minority view :-) >=20 > Anders >=20 >>=20 >> You are free to discuss any issues that are related to the charter of=20 >> this WG. >> If you want to discuss things with other IETFers, it is a great=20 >> opportunity to come to the conference and talk to people. >>=20 >> Just don't expect people to spend time discussing your issues at the=20 >> meeting unless you are prepared to come and ask for a timeslot. >>=20 >> /Stefan >>=20 >>=20 >>=20 >> On 12-03-17 2:09 PM, "Anders Rundgren" wrote= : >>=20 >>> On 2012-03-17 13:32, Stefan Santesson wrote: >>>> Anders, >>>>=20 >>>> It does not work that way, no matter how interesting your issue=20 >>>> might be. >>>=20 >>> You mean that IETF statutes doesn't permit discussing possible=20 >>> future work-items without a proposer actually being physically present? >>>=20 >>> Anyway, your college in the Swedish EID2-project Leif Johansson,=20 >>> indeed mentioned the very same issue "as highly problematic" in a=20 >>> panel session in the IDTrust/NSTIC event that we both attended this=20 >>> week in Washington DC. >>>=20 >>> Somewhat related: From what I can see the rationale for EST haven't=20 >>> been discussed at all on this list. I don't think even Cisco in the=20 >>> end will support EST since it doesn't add functional improvements. >>> Even the target "Simple PKI client" seems to be left to the reader=20 >>> to guess what it could possibly be. Do YOU know? >>>=20 >>> Anders >>>=20 >>>>=20 >>>> If you want to raise an issue at the meeting, then you need to ask=20 >>>> for a slot and show up at the meeting. >>>> If you can't be bothered, convince someone that will be present to=20 >>>> do it for you. >>>>=20 >>>> If you can't do that even, then discuss it on the list. >>>>=20 >>>> /Stefan >>>>=20 >>>> On 12-03-17 9:56 AM, "Anders Rundgren" >>>> wrote: >>>>=20 >>>>> Stefan, >>>>> I will unfortunately not be able to attend. >>>>>=20 >>>>> May I suggest that the crowd spends some 10 minutes on discussing=20 >>>>> how PKIX intends to deal with the fact that mobile devices with=20 >>>>> embedded credentials will most likely constitute of the bulk of=20 >>>>> the client-side of PKI? >>>>>=20 >>>>> Even the US government have realized (it took some time...) that=20 >>>>> "Derived Credentials" is probably a better solution than "putting=20 >>>>> PIV on a string": >>>>>=20 >>>>>=20 >>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/fe >>>>> b >>>>> 1_nis >>>>> t- >>>>> 800-63-1_overview_enewton.pdf >>>>>=20 >>>>> It is (at least to me) obvious that ambitious efforts such as=20 >>>>> President Obama's NSTIC program won't go particularly far without=20 >>>>> having secure, convenient, and interoperable enrollment solutions. >>>>>=20 >>>>> However, then we enter the minefield known as "Token Provisioning" >>>>> which >>>>> currently only is covered by proprietary solutions like the Google=20 >>>>> Wallet. >>>>>=20 >>>>> Giving in to Google may though be the best for the market since a=20 >>>>> leading vendor can (as Microsoft did in the past) indirectly=20 >>>>> enforce the necessary "compliance" on the other parties. >>>>>=20 >>>>> The opportunity for a standard addressing 5-10 BILLION of=20 >>>>> connected devices won't exist 3 years from now, at least if we are=20 >>>>> talking about a *used* ditto. >>>>>=20 >>>>> If you are the daring type you might even perform a straw poll on=20 >>>>> the topic :-) >>>>>=20 >>>>> Anders >=20 Scanned by Check Point Total Security Gateway. From stefan@aaa-sec.com Sun Mar 18 15:49:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05C321F848B for ; Sun, 18 Mar 2012 15:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7OdK-9srsaP for ; Sun, 18 Mar 2012 15:49:00 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 611EB21F847C for ; Sun, 18 Mar 2012 15:48:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DF7461D6BBF8 for ; Sun, 18 Mar 2012 23:48:57 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4Q3Vf-BjTP30 for ; Sun, 18 Mar 2012 23:48:57 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7F5901D693B0 for ; Sun, 18 Mar 2012 23:48:57 +0100 (CET) Received: (qmail 81417 invoked from network); 18 Mar 2012 22:48:57 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Mar 2012 22:48:57 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 18 Mar 2012 23:48:52 +0100 From: Stefan Santesson To: 'PKIX' Message-ID: Thread-Topic: [pkix] Range responses in OCSP In-Reply-To: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 22:49:01 -0000 Trying to return to the actual question I would like to take up in Santosh's question. What problem is this trying to solve? Why would it not be enough to just craft one standard response saying "I have no record of the certificate you are asking for"? Yes, it would not be a signed proof that this is not a replay sent by Eve in order to fool you to reject a perfectly valid cert. But it would be an indication that something is fishy here and should be investigated. Either you have a MitM swapping the OCSP responses, or you have a bad OCSP responder, or you have a compromised CA. Time to push the alarm and figure out what's wrong. What more would you get from prefabricating all these OCSP range responses? /Stefan From anders.rundgren@telia.com Sun Mar 18 16:34:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368C721F85A5 for ; Sun, 18 Mar 2012 16:34:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYiMyH8rTrEd for ; Sun, 18 Mar 2012 16:34:45 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0A16221F85AD for ; Sun, 18 Mar 2012 16:34:45 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E002D2183; Mon, 19 Mar 2012 00:34:28 +0100 Message-ID: <4F6670F8.6000205@telia.com> Date: Mon, 19 Mar 2012 00:34:16 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoav Nir References: <4F65ACE3.1050307@telia.com> <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> <4F65FF81.7070007@telia.com> <1BC28887-4F62-437A-A117-C833A0968E05@checkpoint.com> In-Reply-To: <1BC28887-4F62-437A-A117-C833A0968E05@checkpoint.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Stefan Santesson Subject: [pkix] Mobile Enrollment. Was: Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 18 Mar 2012 23:34:47 -0000 On 2012-03-18 21:01, Yoav Nir wrote: > Well, PKIX standardized CMC and CMP, and Cisco made SCEP, and none of these > seems particularly tied to Windows as opposed to Mac OS, Linux, phones running iOS, > or parallel sysplexes of mainframes running z/OS. Agreed. > It's true that iOS and other operating system (not necessarily "mobile") > tend to decrease the amount of control given to application writers, so > you can't just write some application that performs enrollment and store > the resulting certificate in the operating system store for use by other > applications. Exactly. And that puts us in a new situation. But it doesn't stop there. These systems will among many things emulate smart cards (already showcased by Microsoft: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T ) which is a much better idea than "putting PIV on a string" like: http://us.blackberry.com/ataglance/security/products/smartcardreader > Are you proposing some new API or URI scheme where the > application can ask the operating system to perform enrollment using one > of the above or a new protocol? If all these protocols are lacking something, > then PKIX would be the right place to discuss it. I have probably the last 12 months or so posted some 50 mails on the subject (including numerous links to various documents and presentations) so it has indeed been "discussed". However, the responders generally dismissed the gap analysis in spite of the fact that Google's Wallet builds on similar principles. At the core of such systems you find end-2-end security which means that it is the cryptographic module and the issuer that are talking, or to be more correct; it is the issuer that does the talking, the cryptographic module is only a responder. In addition, most (if not all), end-2-end security systems that perform multiple operations build on the creation of an initial session key which is subsequently used for securing the rest. This concept also allow a set of operations to be performed as a transaction which is important from a robustness perspective. These principles have little or nothing in common with CMC, CMP, SCEP, or EST since the latter were not designed for user self-enrollment of the kind that mobile devices with embedded security hardware [IMO] mandate. Then we had this pretty confusing debate about PIN-codes versus enrollment. At the end it felt mainly as an "Ad Hominem" thing unless the PKIX WG is actually unaware of two-factor authentication tokens which I find hard to believe. After those experiences I don't think PKIX is the right place for creating enrollment standards for the virtual army of consumers or enterprise users with mobile devices, but I leave that topic to the chairs and others to think about in Paris or elsewhere. Since you wondered what I had in mind you may take a peek in the following: http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf Note: It is a browser-based solution and also uses XML so it falls way outside of PKIX domains. However, since Apple also use XML in their excellent VPN/SCEP bootstrap scheme and permits browser-invocation I feel pretty comfortable regarding choice of core technologies. AFAICT there is no need to have specific enrollment standards for payment credentials; "a key is a key" so any new scheme should also serve as the foundation for virtual credit cards. I don't expect credit-cards to exist 10 years from now. Cash will though never [completely] go away! Here there should some 100 pages of more stuff but that wouldn't pass the mailing-list limit... Anders If you want to standardize "enroll://CN=somebody@theCA.example.com" it's probably in PKIX too. > > If it's just about Apple not letting us use our favorite enrollment protocols, there's not much PKIX can do about it. > > I find this complaint about attitude strange. This list gets frequent criticism from some people (Prof. Gutmann springs to mind) about PKIX being willing to standardize anything that looks like ASN.1. This is a group that has standardized two protocols for enrollment and two protocols for certificate status validation. I also haven't seen anything in Stefan's responses that amounts to a rejection of your idea. It's just not clear what that idea is. Yes, there are more mobiles out there. Maybe some of them come with embedded credentials (that can be used by applications). That this will be the bulk of client-side PKI is debatable. I'm still missing what we are supposed to discuss. What do *you* propose that PKIX do about it? > > Yoav > > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: 18 March 2012 17:30 > To: Yoav Nir > Cc: Stefan Santesson; pkix@ietf.org > Subject: Re: [pkix] Agenda requests for Paris > > On 2012-03-18 12:15, Yoav Nir wrote: >> Anders, >> >> IMO "relevant" is whatever the group decides is relevant as long as >> the IESG agrees. If you want the working group to do something, such >> as mobile devices with embedded credentials, you should propose this to the group. > > Once upon time there was a single enterprise OS standard; it was called Windows. > Each vendor could easily create s.c. "Windows-compatible" solutions by a bunch of proprietary DLLs and EXEs. > > These days are gone. Now customers are facing a multitude of mobile devices with quite different software distribution and security models. > > Currently I'm struggling with a mobile PKI + FW using Cisco's ASA + AnyConnect. > The absence of useful enrollment/setup standards in this space force you into "rooted" phones, quirky user-interfaces, least common denominator functionality, and extended deployment times. > > Unless something in the process (and attitude) changes, I remain convinced that PKIX should stick to the PKI core and leave applications like EST aside. > > Anders > >> >> A few years ago I had a proposal to IPsecME but couldn't attend. I asked someone else who *was* attending to present it for me. I prepared the slides and everything, and listened to the audio stream. While there is work being done (see the vmeet list) that may allow people to present remotely, results so far have been a mixed bag. Surely you can go to https://www.ietf.org/registration/ietf83/attendance.py , and find one of the 1347 people listed there (as of right now) who might be interested enough to present slides that you would prepare for him or her. >> >> I don't think a time slot reserved for "discussion of the fact that mobile devices with embedded credentials will most likely constitute of the bulk of the client-side of PKI" will do much without a draft, a presentation, or at the very least, someone to lead the discussion. >> >> Yoav >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >> Of Anders Rundgren >> Sent: 18 March 2012 11:38 >> To: Stefan Santesson >> Cc: pkix@ietf.org >> Subject: Re: [pkix] Agenda requests for Paris >> >> On 2012-03-18 01:45, Stefan Santesson wrote: >>> Anders, >>> >>> You are missing the point. >> >> Not really, I'm just looking at things from a different angle. >> >> IMHO, "relevance" has become an overarching issue for SDOs due to the fact that the IT-landscape has changed tremendously the last ten years: >> >> - Continuously shorter product cycles >> - Vendors that single-handedly define complete and globally operating >> ecosystems, from devices to services >> - Open source as a means to reduce costs and improve interoperability >> >> Since "my" issue (affecting billions of other humans) obviously is not of any interest to you or Steve, PKIX's future probably is about managing the PKI core documents (Certificates, CRL and OCSP). >> >> Thar said, new efforts in the more application-oriented part of the PKI universe, like the recent EST work-item seems much less likely to pan out since these require alien elements like strategy, marketing, and gap analysis. >> >> OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to be a major issue. In my world deployment and relevance are synonymous. >> Yes, I know this is a minority view :-) >> >> Anders >> >>> >>> You are free to discuss any issues that are related to the charter of >>> this WG. >>> If you want to discuss things with other IETFers, it is a great >>> opportunity to come to the conference and talk to people. >>> >>> Just don't expect people to spend time discussing your issues at the >>> meeting unless you are prepared to come and ask for a timeslot. >>> >>> /Stefan >>> >>> >>> >>> On 12-03-17 2:09 PM, "Anders Rundgren" wrote: >>> >>>> On 2012-03-17 13:32, Stefan Santesson wrote: >>>>> Anders, >>>>> >>>>> It does not work that way, no matter how interesting your issue >>>>> might be. >>>> >>>> You mean that IETF statutes doesn't permit discussing possible >>>> future work-items without a proposer actually being physically present? >>>> >>>> Anyway, your college in the Swedish EID2-project Leif Johansson, >>>> indeed mentioned the very same issue "as highly problematic" in a >>>> panel session in the IDTrust/NSTIC event that we both attended this >>>> week in Washington DC. >>>> >>>> Somewhat related: From what I can see the rationale for EST haven't >>>> been discussed at all on this list. I don't think even Cisco in the >>>> end will support EST since it doesn't add functional improvements. >>>> Even the target "Simple PKI client" seems to be left to the reader >>>> to guess what it could possibly be. Do YOU know? >>>> >>>> Anders >>>> >>>>> >>>>> If you want to raise an issue at the meeting, then you need to ask >>>>> for a slot and show up at the meeting. >>>>> If you can't be bothered, convince someone that will be present to >>>>> do it for you. >>>>> >>>>> If you can't do that even, then discuss it on the list. >>>>> >>>>> /Stefan >>>>> >>>>> On 12-03-17 9:56 AM, "Anders Rundgren" >>>>> wrote: >>>>> >>>>>> Stefan, >>>>>> I will unfortunately not be able to attend. >>>>>> >>>>>> May I suggest that the crowd spends some 10 minutes on discussing >>>>>> how PKIX intends to deal with the fact that mobile devices with >>>>>> embedded credentials will most likely constitute of the bulk of >>>>>> the client-side of PKI? >>>>>> >>>>>> Even the US government have realized (it took some time...) that >>>>>> "Derived Credentials" is probably a better solution than "putting >>>>>> PIV on a string": >>>>>> >>>>>> >>>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/fe >>>>>> b >>>>>> 1_nis >>>>>> t- >>>>>> 800-63-1_overview_enewton.pdf >>>>>> >>>>>> It is (at least to me) obvious that ambitious efforts such as >>>>>> President Obama's NSTIC program won't go particularly far without >>>>>> having secure, convenient, and interoperable enrollment solutions. >>>>>> >>>>>> However, then we enter the minefield known as "Token Provisioning" >>>>>> which >>>>>> currently only is covered by proprietary solutions like the Google >>>>>> Wallet. >>>>>> >>>>>> Giving in to Google may though be the best for the market since a >>>>>> leading vendor can (as Microsoft did in the past) indirectly >>>>>> enforce the necessary "compliance" on the other parties. >>>>>> >>>>>> The opportunity for a standard addressing 5-10 BILLION of >>>>>> connected devices won't exist 3 years from now, at least if we are >>>>>> talking about a *used* ditto. >>>>>> >>>>>> If you are the daring type you might even perform a straw poll on >>>>>> the topic :-) >>>>>> >>>>>> Anders >> > > > Scanned by Check Point Total Security Gateway. > From SChokhani@cygnacom.com Sun Mar 18 18:18:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E3F21F85DA for ; Sun, 18 Mar 2012 18:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O6lP+o0EWAV for ; Sun, 18 Mar 2012 18:18:32 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33621F85D0 for ; Sun, 18 Mar 2012 18:18:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,609,1325480400"; d="scan'208";a="584586" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 18 Mar 2012 21:18:31 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 18 Mar 2012 21:18:31 -0400 From: Santosh Chokhani To: Stefan Santesson , 'PKIX' Date: Sun, 18 Mar 2012 21:18:29 -0400 Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0FWVLeN1co6G8jS2KwZXngsfdKvAAFFeuw Message-ID: References: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 01:18:32 -0000 Stefan, I have no objection to adding a response type (If you think unknown is not = sufficient). This will require a change to the standard, and the two classes of COTS: Re= sponders and Clients.=20 This group has also rejected my advice for a need for client side processin= g rules for 2560. It would be good to identify what the clients are suppos= ed to do with this. Finally, we do not want this to be the mechanism advertised as the way to d= etect the possible CA compromise. It simply gives us false sense of securi= ty. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Sunday, March 18, 2012 6:49 PM To: 'PKIX' Subject: Re: [pkix] Range responses in OCSP Trying to return to the actual question I would like to take up in Santosh'= s question. What problem is this trying to solve? Why would it not be enough to just craft one standard response saying "I ha= ve no record of the certificate you are asking for"? Yes, it would not be a signed proof that this is not a replay sent by Eve i= n order to fool you to reject a perfectly valid cert. But it would be an indication that something is fishy here and should be in= vestigated. Either you have a MitM swapping the OCSP responses, or you have a bad OCSP = responder, or you have a compromised CA. Time to push the alarm and figure out what's wrong. What more would you get from prefabricating all these OCSP range responses? /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ryan.hurst@globalsign.com Sun Mar 18 19:09:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0F21F8501 for ; Sun, 18 Mar 2012 19:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAsGeBgUgTwD for ; Sun, 18 Mar 2012 19:09:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80C21F84F8 for ; Sun, 18 Mar 2012 19:09:25 -0700 (PDT) Received: by dakl33 with SMTP id l33so10188160dak.31 for ; Sun, 18 Mar 2012 19:09:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id:x-mailer :thread-index:content-language:mime-version:content-type :x-gm-message-state; bh=BG/BvBFPY1a33mlGCRiiDQNbtjIx8cBYbRzrKAkAmdM=; b=jH0qnmIEvMdzdous/B5aJ7tgINa8IGkfaMcQlZZGx8fhRVrKViMvyBScdG+Fs0tFSr cPHuqb0LEUOd5Dnp8jjjIhHdRg1hOx5MQ0V1TCCpqSElhFgy8yVJQNvsvzSQUzS7Rw5O i/8ptnpEq+o0s8Y2SdhWhDPosF/pAnxvfcdTtuMAW/ZObzg+u/YjHktOsEP1Pn7c0po0 NgnDCTJEcbKGEWWSesSqLfRgNQZwRrnk3u0oIu1d5EDC3NG7mtrx/g5C8K1P3ZoCzlIZ tzlGxvM414i5LRxhGmBcrSXVctIZxCt6A3+dqGFR5kkSNmifjfePk5fmrlF9JEOaGV55 KbYg== Received: by 10.68.202.170 with SMTP id kj10mr15247489pbc.11.1332122964953; Sun, 18 Mar 2012 19:09:24 -0700 (PDT) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id o9sm7624652pbe.60.2012.03.18.19.09.22 (version=SSLv3 cipher=OTHER); Sun, 18 Mar 2012 19:09:24 -0700 (PDT) From: "Ryan Hurst" To: "'Paul Hoffman'" References: , <0d7701cd03f1$3f838d00$be8aa700$@globalsign.com> <0997BB15-B7F6-4ED4-9412-C05F0EA5F85A@vpnc.org> <0e5401cd0459$b9371e10$2ba55a30$@globalsign.com> <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org> In-Reply-To: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org> Date: Sun, 18 Mar 2012 19:09:18 -0700 Message-ID: <0fb101cd0575$4ba17f40$e2e47dc0$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNsp/XD7PxT56WOrq4dYP3sMZz/4wJkklWGAjmlygABsu9R7gI2uqinAYzQ/+sB+zRXg5LRG0rA Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0FAC_01CD053A.9E33F660" X-Gm-Message-State: ALoCoQnK09rd0iIVKMcu+2qvaGWpfnl4+TzESeWkH1ywHKyoh3YqU3HFBCljEAV6A3dz8QfZ6fy4 Cc: 'PKIX' Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 02:09:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0FAC_01CD053A.9E33F660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is, if its work the WG decides to take on Phil or I can take this up in CA/Browser forum. Ryan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Saturday, March 17, 2012 9:32 AM To: Ryan Hurst Cc: 'PKIX' Subject: Re: [pkix] Range responses in OCSP On Mar 17, 2012, at 9:19 AM, Ryan Hurst wrote: > I agree that the text allows for lower order bits containing the > minimum necessary random data and keeping the upper bits sequential as > well as other fields where the required randomness can be present. > > With that said it's my belief that many CAs supported pure random > serial numbers and as such quite a few simply enabled this capability > as their resolution to the issue highlighted by the Lenstra paper. > > I am not saying this precludes the project, it just limits its > applicability. Is it possible for someone to do a survey? This seems like something fairly easy for the CA/Browser Forum to answer. --Paul Hoffman ------=_NextPart_000_0FAC_01CD053A.9E33F660 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMTkwMjA5MThaMCMGCSqG SIb3DQEJBDEWBBR0pFkrjnAGkLw+eIV9icusn/rv2TB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAE+BKyT8yrpapgTsd9olN8K6Oxnk2lYiYbendPx0k5o2J6wgYz+nVuao u8K/0xXYff/4U3AAD823agy8caxepWGnMbKiAvzUpnm+yHxs8xcOgfgm33qnQng+B0j4lyDEse0i rGoeq0wbNZuOrsB60pa3PaL5dOK7hoHY1Msm91b30F4HO5DAcgU43KCpVL6HJhznrE9dJwUDdHoZ NMRmeL+tWYdL1djTMRJhkdPoj1PARnGenWx3hTV8hocjGJcGjVUjLOalbTzD87aS1gDRK2bAdBgh Ajn99i3tHluAI0orOnxoFswI3t5g74+3JUHJe1yZDfNivFO7Lp0n54cR/4MAAAAAAAA= ------=_NextPart_000_0FAC_01CD053A.9E33F660-- From stefan@aaa-sec.com Sun Mar 18 19:24:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC921F852B for ; Sun, 18 Mar 2012 19:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUq+VdwzyrG7 for ; Sun, 18 Mar 2012 19:24:36 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 493D421F849B for ; Sun, 18 Mar 2012 19:24:31 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 17EB21DCAAA1 for ; Mon, 19 Mar 2012 03:18:58 +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 N1ZTpFMdNVTa for ; Mon, 19 Mar 2012 03:18:57 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BE28F1DCAA96 for ; Mon, 19 Mar 2012 03:18:57 +0100 (CET) Received: (qmail 91527 invoked from network); 19 Mar 2012 02:18:57 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.215]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Mar 2012 02:18:57 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 19 Mar 2012 03:18:53 +0100 From: Stefan Santesson To: Santosh Chokhani , 'PKIX' Message-ID: Thread-Topic: [pkix] Range responses in OCSP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 02:24:37 -0000 OK, Just to be clear, I did not propose to add any response type. The question was meant to be hypothetical. That is, if the solution which is asked for might as well be solved by a simpler solution, then there is no point in discussing a more complex solution. It still remains to be determined that there is a problem worth solving. /Stefan On 12-03-19 2:18 AM, "Santosh Chokhani" wrote: >Stefan, > >I have no objection to adding a response type (If you think unknown is >not sufficient). > >This will require a change to the standard, and the two classes of COTS: >Responders and Clients. > >This group has also rejected my advice for a need for client side >processing rules for 2560. It would be good to identify what the clients >are supposed to do with this. > >Finally, we do not want this to be the mechanism advertised as the way to >detect the possible CA compromise. It simply gives us false sense of >security. > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stefan Santesson >Sent: Sunday, March 18, 2012 6:49 PM >To: 'PKIX' >Subject: Re: [pkix] Range responses in OCSP > >Trying to return to the actual question I would like to take up in >Santosh's question. > >What problem is this trying to solve? > >Why would it not be enough to just craft one standard response saying "I >have no record of the certificate you are asking for"? >Yes, it would not be a signed proof that this is not a replay sent by Eve >in order to fool you to reject a perfectly valid cert. > >But it would be an indication that something is fishy here and should be >investigated. > >Either you have a MitM swapping the OCSP responses, or you have a bad >OCSP responder, or you have a compromised CA. >Time to push the alarm and figure out what's wrong. > >What more would you get from prefabricating all these OCSP range >responses? > >/Stefan > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Sun Mar 18 20:57:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E0021F8547 for ; Sun, 18 Mar 2012 20:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4-OQDS7oQJF for ; Sun, 18 Mar 2012 20:57:27 -0700 (PDT) Received: from col0-omc3-s18.col0.hotmail.com (col0-omc3-s18.col0.hotmail.com [65.55.34.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4002D21F8501 for ; Sun, 18 Mar 2012 20:57:27 -0700 (PDT) Received: from COL119-W45 ([65.55.34.136]) by col0-omc3-s18.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Mar 2012 20:57:26 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a004b3f4-e6b5-4514-8d69-967d0cdad163_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Sun, 18 Mar 2012 20:57:26 -0700 Importance: Normal In-Reply-To: References: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 19 Mar 2012 03:57:26.0655 (UTC) FILETIME=[65DF08F0:01CD0584] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 03:57:28 -0000 --_a004b3f4-e6b5-4514-8d69-967d0cdad163_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response. Range response is just an optimal way of packing a large number of single r= esponses in one OCSP response. This is how pre-signing of OCSP is done today.One (or more) more keyed resp= onders create a list of OCSP responses which is then mirrored to multiple k= eyless responders. Relying parties use these keyless responders to check th= e status of certificates. One OCSP response is usually packed with status o= f muliple certificates to minimize the number of signings. However=2C the t= rade off is that the OCSP response gets bloated. Problem:1) The current representation of OCSP response is inefficient. Let'= s say that the range of issued certificates by a CA is 'M' and the number o= f revoked certificates in the CRL is 'N'. We know that typically M is much = bigger than N. Using the current OCSP response representation =2C you need = to create M responses to account for every serial number that the CA issue= d. Using ranges you could achieve the same thing using at most 2*N + 1 res= ponses ( Think of it as an efficient representation of a sparse array).=20 2)For CAs that issue certificates using random serial numbers=2C M is so bi= g that it becomes computationally impossible to pre-sign responses for tho= se CAs unless the responder has access to the CA database.=20 Range response will facilitate pre-signing of OCSP responses for CAs that i= ssue certificates with non sequential serial numbers and reduce the computa= tion and bandwidth requirements even for CAs who issue certificates with se= quential serial numbers. -Piyush > Date: Sun=2C 18 Mar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP >=20 > Trying to return to the actual question I would like to take up in > Santosh's question. >=20 > What problem is this trying to solve? >=20 > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes=2C it would not be a signed proof that this is not a replay sent by E= ve > in order to fool you to reject a perfectly valid cert. >=20 > But it would be an indication that something is fishy here and should be > investigated. >=20 > Either you have a MitM swapping the OCSP responses=2C or you have a bad O= CSP > responder=2C or you have a compromised CA. > Time to push the alarm and figure out what's wrong. >=20 > What more would you get from prefabricating all these OCSP range response= s? >=20 > /Stefan >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_a004b3f4-e6b5-4514-8d69-967d0cdad163_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think the proposal to have OCSP support range responses should be discuss= ed =3Bseparately =3Bfrom the proposal to add "does not exist" respo= nse.

Range response is just an optimal way of packing a = large number of single responses in one OCSP response.

=
This is how pre-signing of OCSP is done today.
One (or more)= more keyed responders create a list of OCSP responses which is then mirror= ed to multiple keyless responders. Relying parties use these keyless respon= ders to check the status of certificates. =3BOne OCSP response is usually packed with status of muliple certif= icates to minimize the number of signings. =3BHowever=2C the trade off is that the OCSP response gets b= loated.

Problem:
1) The current r= epresentation of OCSP response is inefficient. Let's say that the range of = issued certificates by a CA is 'M' and the number of revoked certificates i= n the CRL is 'N'. We know that typically M is much bigger than N. Using the= current OCSP response representation =2C you need to create M  =3Bresp= onses to account for every serial number that the CA issued. Using ranges y= ou could  =3B
achieve the same thing using at most 2*N + 1 re= sponses ( Think of it as an efficient representation of a sparse array).&nb= sp=3B

2)For CAs that issue certificates using rand= om serial numbers=2C M is so big that it becomes computationally  =3Bim= possible to pre-sign responses for those CAs unless the responder has acces= s to the CA database. =3B

Range response will = facilitate pre-signing of OCSP responses for CAs that issue certificates wi= th non sequential serial numbers and reduce the =3Bcomputation =3Ba= nd bandwidth requirements even for CAs who issue certificates with sequenti= al serial numbers.

-Piyush

>=3B Date: Sun=2C 18 Mar 2012 23:48:52 = +0100
>=3B From: stefan@aaa-sec.com
>=3B To: pkix@ietf.org
>= =3B Subject: Re: [pkix] Range responses in OCSP
>=3B
>=3B Trying= to return to the actual question I would like to take up in
>=3B Sant= osh's question.
>=3B
>=3B What problem is this trying to solve?<= br>>=3B
>=3B Why would it not be enough to just craft one standard = response saying "I
>=3B have no record of the certificate you are aski= ng for"?
>=3B Yes=2C it would not be a signed proof that this is not a= replay sent by Eve
>=3B in order to fool you to reject a perfectly va= lid cert.
>=3B
>=3B But it would be an indication that something= is fishy here and should be
>=3B investigated.
>=3B
>=3B E= ither you have a MitM swapping the OCSP responses=2C or you have a bad OCSP=
>=3B responder=2C or you have a compromised CA.
>=3B Time to pus= h the alarm and figure out what's wrong.
>=3B
>=3B What more wou= ld you get from prefabricating all these OCSP range responses?
>=3B >=3B /Stefan
>=3B
>=3B
>=3B __________________________= _____________________
>=3B pkix mailing list
>=3B pkix@ietf.org>=3B https://www.ietf.org/mailman/listinfo/pkix
=
= --_a004b3f4-e6b5-4514-8d69-967d0cdad163_-- From stefan@aaa-sec.com Mon Mar 19 03:37:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D8321F8674 for ; Mon, 19 Mar 2012 03:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6HzXJuCXRZf for ; Mon, 19 Mar 2012 03:37:22 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7821F8673 for ; Mon, 19 Mar 2012 03:37:15 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B96B31DD0981 for ; Mon, 19 Mar 2012 11:35: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 8LqkihK5UAnt for ; Mon, 19 Mar 2012 11:35:26 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 247961DD073B for ; Mon, 19 Mar 2012 11:35:26 +0100 (CET) Received: (qmail 32439 invoked from network); 19 Mar 2012 10:35:25 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.215]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Mar 2012 10:35:25 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 19 Mar 2012 11:35:14 +0100 From: Stefan Santesson To: Piyush Jain , Message-ID: Thread-Topic: [pkix] Range responses in OCSP In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415001725_21340845" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 10:37:22 -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_3415001725_21340845 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit My fear is that this will glue CAs to sequential serial numbers and prevent them from moving to non sequential serial numbers when needed. /Stefan From: Piyush Jain Date: Sun, 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson , Subject: Re: [pkix] Range responses in OCSP > I think the proposal to have OCSP support range responses should be discussed > separately from the proposal to add "does not exist" response. > > Range response is just an optimal way of packing a large number of single > responses in one OCSP response. > > This is how pre-signing of OCSP is done today. > One (or more) more keyed responders create a list of OCSP responses which is > then mirrored to multiple keyless responders. Relying parties use these > keyless responders to check the status of certificates. One OCSP response is > usually packed with status of muliple certificates to minimize the number of > signings. However, the trade off is that the OCSP response gets bloated. > > Problem: > 1) The current representation of OCSP response is inefficient. Let's say that > the range of issued certificates by a CA is 'M' and the number of revoked > certificates in the CRL is 'N'. We know that typically M is much bigger than > N. Using the current OCSP response representation , you need to create M > responses to account for every serial number that the CA issued. Using ranges > you could > achieve the same thing using at most 2*N + 1 responses ( Think of it as an > efficient representation of a sparse array). > > 2)For CAs that issue certificates using random serial numbers, M is so big > that it becomes computationally impossible to pre-sign responses for those > CAs unless the responder has access to the CA database. > > Range response will facilitate pre-signing of OCSP responses for CAs that > issue certificates with non sequential serial numbers and reduce the > computation and bandwidth requirements even for CAs who issue certificates > with sequential serial numbers. > > -Piyush > >> > Date: Sun, 18 Mar 2012 23:48:52 +0100 >> > From: stefan@aaa-sec.com >> > To: pkix@ietf.org >> > Subject: Re: [pkix] Range responses in OCSP >> > >> > Trying to return to the actual question I would like to take up in >> > Santosh's question. >> > >> > What problem is this trying to solve? >> > >> > Why would it not be enough to just craft one standard response saying "I >> > have no record of the certificate you are asking for"? >> > Yes, it would not be a signed proof that this is not a replay sent by Eve >> > in order to fool you to reject a perfectly valid cert. >> > >> > But it would be an indication that something is fishy here and should be >> > investigated. >> > >> > Either you have a MitM swapping the OCSP responses, or you have a bad OCSP >> > responder, or you have a compromised CA. >> > Time to push the alarm and figure out what's wrong. >> > >> > What more would you get from prefabricating all these OCSP range responses? >> > >> > /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 --B_3415001725_21340845 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
My fear is that this will gl= ue CAs to sequential serial numbers and prevent them from moving to non sequ= ential serial numbers when needed.

/Stefan

From: Piyush Jain <piyush@identicate.com>
Date: Sun, 18 Mar 2012 20:57:26 -0700
To: Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: Re: [pkix] Range responses in OCSP

I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response.<= div>
Range response is just an optimal way of packing a large = number of single responses in one OCSP response.

Th= is is how pre-signing of OCSP is done today.
One (or more) more ke= yed responders create a list of OCSP responses which is then mirrored to mul= tiple keyless responders. Relying parties use these keyless responders to ch= eck the status of certificates. One OCS= P response is usually packed with status of muliple certificates to minimize= the number of signings. However= , the trade off is that the OCSP response gets bloated.
Problem:
1) The current representation of OCSP respons= e is inefficient. Let's say that the range of issued certificates by a CA is= 'M' and the number of revoked certificates in the CRL is 'N'. We know that = typically M is much bigger than N. Using the current OCSP response represent= ation , you need to create M  responses to account for every serial num= ber that the CA issued. Using ranges you could  
achieve the = same thing using at most 2*N + 1 responses ( Think of it as an efficient rep= resentation of a sparse array). 

2)For CAs tha= t issue certificates using random serial numbers, M is so big that it become= s computationally  impossible to pre-sign responses for those CAs unles= s the responder has access to the CA database. 

Range response will facilitate pre-signing of OCSP responses for CAs that = issue certificates with non sequential serial numbers and reduce the co= mputation and bandwidth requirements even for CAs who issue certificate= s with sequential serial numbers.

-Piyush

> Date: Sun, 18 Mar 2012 23= :48:52 +0100
> From: stefan@aaa-se= c.com
> To: pkix@ietf.org
&g= t; Subject: Re: [pkix] Range responses in OCSP
>
> Trying to re= turn to the actual question I would like to take up in
> Santosh's que= stion.
>
> What problem is this trying to solve?
>
&g= t; Why would it not be enough to just craft one standard response saying "I<= br>> have no record of the certificate you are asking for"?
> Yes, = it would not be a signed proof that this is not a replay sent by Eve
>= in order to fool you to reject a perfectly valid cert.
>
> But= it would be an indication that something is fishy here and should be
>= ; investigated.
>
> Either you have a MitM swapping the OCSP re= sponses, or you have a bad OCSP
> responder, or you have a compromised= CA.
> Time to push the alarm and figure out what's wrong.
> > What more would you get from prefabricating all these OCSP range respo= nses?
>
> /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_3415001725_21340845-- From tmiller@mitre.org Mon Mar 19 04:59:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB721F8602 for ; Mon, 19 Mar 2012 04:59:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe5IbM+T2L+e for ; Mon, 19 Mar 2012 04:59:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1E021F85F8 for ; Mon, 19 Mar 2012 04:59:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 250A621B01DF; Mon, 19 Mar 2012 07:59:10 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 15E3821B017B; Mon, 19 Mar 2012 07:59:10 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 07:59:09 -0400 From: "Miller, Timothy J." To: Stefan Santesson Thread-Topic: [pkix] PROPOSAL: SCVP to HISTORIC Thread-Index: AQHNA3X/tjm8XEMqbUS9MIH4AhVT+JZtTrqAgAAPxYCAAAWVAIAABEkAgARjJIA= Date: Mon, 19 Mar 2012 11:59:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 11:59:12 -0000 On Mar 16, 2012, at 11:59 AM, Stefan Santesson wrote: > Basically, if users of OCSP need to extend the functionality of OCSP in a > way where some functionally may come to overlap with functionality > provided by SCVP, then should we allow that overlap or force those with > such need to implement SCVP? Then again, any OCSP service can implement virtually any processing change = without modification of the protocol or the clients. E.g., if an OCSP serv= ice has access to the CA history and the queried cert isn't present at all,= "UNKNOWN" and "REVOKED" are valid answers. Why does the client need a new= return code (e.g., "NEVERISSUED") in this case? Case in point: DigiNotar runs their terminal OCSP service this way under t= he current standard. Did anyone have a problem with that? -- T From tmiller@mitre.org Mon Mar 19 05:04:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9F021F864D for ; Mon, 19 Mar 2012 05:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNb8iCyMsuz3 for ; Mon, 19 Mar 2012 05:04:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CDDC721F864A for ; Mon, 19 Mar 2012 05:04:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E87A521B020C; Mon, 19 Mar 2012 08:04:36 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CAFBD21B0262; Mon, 19 Mar 2012 08:04:36 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:04:36 -0400 From: "Miller, Timothy J." To: Stefan Santesson Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAAC7iAgAAKcACAAAIjgIAAMxCAgAP3BwA= Date: Mon, 19 Mar 2012 12:04:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <256B14EFD904014B8ADFDD7964603600@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 12:04:39 -0000 On Mar 16, 2012, at 6:31 PM, Stefan Santesson wrote: > This proposal seems to propose that all bets are not off. That there are > ways to prevent a successful exploit of a compromised CA if we add a > "never issued" response. >=20 > I'm in doubt. You have data points (DigiNotar & Comodo). Phil does not. :) Just sayin'. -- T From tmiller@mitre.org Mon Mar 19 05:07:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3621F868A for ; Mon, 19 Mar 2012 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alsYBM7MlVpr for ; Mon, 19 Mar 2012 05:07:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0828221F8663 for ; Mon, 19 Mar 2012 05:07:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A3D5321B01C3; Mon, 19 Mar 2012 08:07:29 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 99CBE21B01EF; Mon, 19 Mar 2012 08:07:29 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:07:29 -0400 From: "Miller, Timothy J." To: "Henry B. Hotz" Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtlJUAgAQ47AA= Date: Mon, 19 Mar 2012 12:07:28 +0000 Message-ID: <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E3D7751AB541546B77BC198EE0DD0F0@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 12:07:30 -0000 On Mar 16, 2012, at 2:38 PM, Henry B. Hotz wrote: > Can I turn the question around and ask why adding a 'does not exist' resp= onse would be bad? It's a subset of UNKNOWN? It's incompatible with the installed base? > To answer your question more directly, I think there are scenarios that c= ould most easily be addressed if such a response could be provided. =20 Examples, please? -- T From tmiller@mitre.org Mon Mar 19 05:10:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC221F858A for ; Mon, 19 Mar 2012 05:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX6awwqKUGl1 for ; Mon, 19 Mar 2012 05:10:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9919121F864D for ; Mon, 19 Mar 2012 05:10:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1746A21B020C; Mon, 19 Mar 2012 08:10:18 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EC31021B01C3; Mon, 19 Mar 2012 08:10:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:10:17 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtpd+AgAQoagA= Date: Mon, 19 Mar 2012 12:10:17 +0000 Message-ID: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 12:10:19 -0000 On Mar 16, 2012, at 3:40 PM, Phillip Hallam-Baker wrote: > Now with the proposed scheme the attacker can still issue false > certificates but any attempt to cover their tracks by deleting the log > files will result in the CA issuing the OCSP status 'Does not exist' > and cause the breach to be observable externally. Contrawise if they > do not delete the logs, the CA will have a record of the bogus certs > that were issued. DigiNotar does this *today* by responding REVOKED in that case, and they di= dn't modify the protocol. So this scenario is covered by current practice. =20 Try again. > In the past it was considered axiomatic that a CA will never ever be > breached. That's a hell of a claim. Prove it. =20 -- T From tmiller@mitre.org Mon Mar 19 05:35:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D630221F8653 for ; Mon, 19 Mar 2012 05:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nF52kjsiYuE for ; Mon, 19 Mar 2012 05:35:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4935A21F841C for ; Mon, 19 Mar 2012 05:35:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9D48621B145D; Mon, 19 Mar 2012 08:35:39 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 196AE21B1445; Mon, 19 Mar 2012 08:35:39 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:35:38 -0400 From: "Miller, Timothy J." To: Santosh Chokhani Thread-Topic: [pkix] Range responses in OCSP Thread-Index: AQHNAu4vT1fWDQuPYkmt1zUAjY2mRZZsHNQAgAAHnACAAKv9AIACClcAgAAEBYCAAvf7gA== Date: Mon, 19 Mar 2012 12:35:37 +0000 Message-ID: References: , , <4F62F10A.9040604@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 12:35:41 -0000 On Mar 17, 2012, at 10:15 AM, Santosh Chokhani wrote: > For the hash collision, why not add random skew to the validity period an= d leave the serial number alone as sequential. I've always preferred this method. A random wiggle to the low-order time b= its would have essentially no observable impact. :) -- T From tmiller@mitre.org Mon Mar 19 05:42:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D592121F86B2 for ; Mon, 19 Mar 2012 05:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvVqQhZaC8Dx for ; Mon, 19 Mar 2012 05:42:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 49AA021F86A5 for ; Mon, 19 Mar 2012 05:42:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E398E21B021B; Mon, 19 Mar 2012 08:42:35 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CF2AF21B021E; Mon, 19 Mar 2012 08:42:35 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:42:35 -0400 From: "Miller, Timothy J." To: Piyush Jain Thread-Topic: [pkix] Range responses in OCSP Thread-Index: AQHNAu4vT1fWDQuPYkmt1zUAjY2mRZZsHNQAgAAHnACAAfs+gIAAuw6AgAAV5YCAAAOdgIAB+4gAgABWNgCAAJK5AA== Date: Mon, 19 Mar 2012 12:42:34 +0000 Message-ID: References: <586B146F-A5F5-41C0-991A-9B14AB4B2D96@vpnc.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F4C43CF7BDF87489F82B7514F262D91@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 12:42:36 -0000 On Mar 18, 2012, at 10:57 PM, Piyush Jain wrote: > I think the proposal to have OCSP support range responses should be discu= ssed separately from the proposal to add "does not exist" response. >=20 > Range response is just an optimal way of packing a large number of single= responses in one OCSP response. I concur. I could use OCSP response ranges to significantly reduce pre-sig= ning workload in a deployed enterprise PKI.=20 Of course, I'd still have the installed base to worry about, but in the ent= erprise environment this is more approachable. I can redirect non-enterpri= se requests to a keyed responder. We only use keyless responders internall= y. -- T From tmiller@mitre.org Mon Mar 19 05:45:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FFE21F8597 for ; Mon, 19 Mar 2012 05:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk-2w0okaSDi for ; Mon, 19 Mar 2012 05:45:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2321F8585 for ; Mon, 19 Mar 2012 05:45:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 23EA521B0275; Mon, 19 Mar 2012 08:45:05 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D434D21B021B; Mon, 19 Mar 2012 08:45:04 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 08:45:04 -0400 From: "Miller, Timothy J." To: " " Thread-Topic: [pkix] Range responses in OCSP Thread-Index: AQHNAu4vT1fWDQuPYkmt1zUAjY2mRZZsHNQAgAAHnACAAKv9AIAAAOuAgABYCoD///JugIAAWVsAgARkO4A= Date: Mon, 19 Mar 2012 12:45:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.102] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <42C32E3C7A1A2244B0E0CC39BD95B6C7@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 12:45:06 -0000 On Mar 16, 2012, at 12:41 PM, wrote: > You said that "there's no place where a significant collision resistance = attack could be mounted".=20 > Humm! I can include a non critical extension that nobody recognizes and a= ccording to RFC 5280 rules,=20 > it will be ignored and then the certificate will not be declared invalid = because this extension is present.=20 > Within this extension, I can place a bit string and then I have all the d= ata I need to compute a match.=20 A fair point. Caught me thinking sloppily again. I forgot the case where= the collision candidates are only computed in the cert the CA will never s= ee. :) However, for SHA1 it's still computationally infeasible. For now. =20 -- T= From tom@ritter.vg Mon Mar 19 06:19:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6221F866C for ; Mon, 19 Mar 2012 06:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtgEswNORRQ4 for ; Mon, 19 Mar 2012 06:19:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E336A21F8582 for ; Mon, 19 Mar 2012 06:19:20 -0700 (PDT) Received: by yenm5 with SMTP id m5so6122922yen.31 for ; Mon, 19 Mar 2012 06:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=4wHULwb56zVLSwDh/6+7lmkok7ktQxqXPq06CxMLfxM=; b=Gg87m1DLqRMH4mPr1unykgS87CczHmNup3kghStucpuliU9kMHVLEYe4SUgVy8bW0L p7UhrkRV1Nlx3dXEwR4dJhYbJda+ijvjNdwO4g/VqaJzgd0cbuqGZ+OU/PNZmBk1RSHl 2z02qbiuJiyCSpribwdHQIDl3Sbe0QUs6b+2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=4wHULwb56zVLSwDh/6+7lmkok7ktQxqXPq06CxMLfxM=; b=dOYCtNdY6YoU7L3MLMknY0S1yZM7xZ50ARLzupc8OyxWYVh64ts03UBopbSrEJw+rU 9QkDMENUJT/5Et6WVErHGwkZTN+DwnOEf9meENroCv09NkxQbMnsi1ThpBJPDpJuYEXA 38Hkb1Zx3B7KOsnWCLZDxOcQAhqEFaeAA45bDhB3OPEJx+SemDVqw3OsuEn6XjO6Kgw9 IDngMESmRGqkigEfqWM749kkWtoBeOy00T/Xz72uL5qTa5enypXQ8Opn28I4FX6upNYb oP7/70yEwqFMWsd/e1Hb1b5zM9uNTqndveSyGba7SU35ezA0xfB75l7qGMcElSEKR8ZP dadw== Received: by 10.60.14.101 with SMTP id o5mr14566287oec.20.1332163160001; Mon, 19 Mar 2012 06:19:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.105 with HTTP; Mon, 19 Mar 2012 06:18:59 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> From: Tom Ritter Date: Mon, 19 Mar 2012 09:18:59 -0400 Message-ID: To: "pkix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnRfidq3EcKeVpSxECEy8us6MWY+oKN3msV3BkJ4IUt09+Cl+yGS0FlyD7zwEAtQbAhYhC Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:19:22 -0000 This discussion has gone round and round several times. If a CA takes the steps to wire their OCSP responder to their cert database so they can make positive assertions about certificates ("Yes, this certificate is known and good." vs "This cert is not in my revoked list.") the response to a query "Is this certificate good?" that is logically "No, that certificate is not good, I don't remember ever issuing it!" must be translated to an OCSP status message that causes a failure on the client. On 19 March 2012 08:10, Miller, Timothy J. wrote: > On Mar 16, 2012, at 3:40 PM, Phillip Hallam-Baker wrote: > >> Now with the proposed scheme the attacker can still issue false >> certificates but any attempt to cover their tracks by deleting the log >> files will result in the CA issuing the OCSP status 'Does not exist' >> and cause the breach to be observable externally. Contrawise if they >> do not delete the logs, the CA will have a record of the bogus certs >> that were issued. > > DigiNotar does this *today* by responding REVOKED in that case, and they didn't modify the protocol. > > So this scenario is covered by current practice. This is really good. But unless I'm really missing something, there is no standard or consensus to do this. Since it's covered by current practice - maybe a technical note of some sort could be circulated referencing this? However, it would still be very nice to tell the client "Things are really, *really* weird! You should perhaps do something" which the client could then alert the user, save diagnostic information, prompt an error-reporting mechanism that's built into several browsers, save to a log, or ignore (perhaps with or without an extension - any FF extension like NoScript, Cert Patrol, etc would be very interested in this info.) I think it's really good for CA's to wire the OCSP responder up to the cert database instead of a CRL, and I think it's really good to convey the information back to the client that there's this weird thing going on - although I concede that this is a corner case that would not be applicable in all CA compromises, and in some would just be another fraudulent response provided by a CA. -tom From tmiller@mitre.org Mon Mar 19 07:03:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F821F8484 for ; Mon, 19 Mar 2012 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ6JTRpr3fqe for ; Mon, 19 Mar 2012 07:03:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07621F8476 for ; Mon, 19 Mar 2012 07:03:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A13021B14D4; Mon, 19 Mar 2012 10:03:44 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 56C2821B145D; Mon, 19 Mar 2012 10:03:44 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 19 Mar 2012 10:03:44 -0400 From: "Miller, Timothy J." To: Tom Ritter Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtpd+AgAQoagCAABMzgIAADH+A Date: Mon, 19 Mar 2012 14:03:44 +0000 Message-ID: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.172] Content-Type: text/plain; charset="us-ascii" Content-ID: <82A306C69EE53C48BDAFB451AD716FA6@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:03:46 -0000 On Mar 19, 2012, at 8:18 AM, Tom Ritter wrote: > This discussion has gone round and round several times. If a CA takes > the steps to wire their OCSP responder to their cert database so they > can make positive assertions about certificates ("Yes, this > certificate is known and good." vs "This cert is not in my revoked > list.") the response to a query "Is this certificate good?" that is > logically "No, that certificate is not good, I don't remember ever > issuing it!" must be translated to an OCSP status message that causes > a failure on the client. The effect sought is to cause a the client to reject the certificate. Resp= onding REVOKED does that. If you respond NOTISSUED, does the client reject= the certificate *more* than if you respond REVOKED? :) > This is really good. But unless I'm really missing something, there > is no standard or consensus to do this. =20 So what? Why should there be? > Since it's covered by current > practice - maybe a technical note of some sort could be circulated > referencing this? I said the last time around (November?) that a Security Note would be appro= priate but changing the protocol is kinda pointless. > However, it would still be very nice to tell the client "Things are > really, *really* weird! You should perhaps do something" which the > client could then alert the user, save diagnostic information, prompt > an error-reporting mechanism that's built into several browsers, save > to a log, or ignore (perhaps with or without an extension - any FF > extension like NoScript, Cert Patrol, etc would be very interested in > this info.) The idea that you'd use NOTISSUED to cause the client to somehow mark the C= A as untrusted is flawed because it presumes trust in the responder is sepa= rate from trust in the issuer, which is neither guaranteed, appropriate, or= even actionable at the client. If you want to control trust anchors, we have TAMP for that. -- T From kent@bbn.com Mon Mar 19 07:22:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E23021F8739 for ; Mon, 19 Mar 2012 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZWmFp4iyE4p for ; Mon, 19 Mar 2012 07:22:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C269E21F8735 for ; Mon, 19 Mar 2012 07:22:15 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49170) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9dTF-000BU0-NR; Mon, 19 Mar 2012 10:22:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Mar 2012 10:21:55 -0400 To: Liaquat Khan From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:22:16 -0000 Liaquat, Thanks for providing an example of an attack scenario and its implications re various countermeasures. Here's an "easy to imagine" alternative scenario: - attacker gains access to HSM and causes a cert to be issued, with the same serial number as a extant, legitimate cert. - no record of cert issuance appears in any CA log. - an OCSP response for the cert serial number will not yield a "revoked" or "not issued" because the legitimate cert in question is valid and not revoked. until the CA is made aware of the bogus cert, it cannot revoke it, and at that time a CRL or the current OCSP mechanism will work as well as any proposed enhancements to OCSP. Thsi is why a thorough, well-written analysis of the problems to be solved is needed before we pursue changes of the sort being proposed. Steve From kent@bbn.com Mon Mar 19 07:22:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3921F8735 for ; Mon, 19 Mar 2012 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFvgiyplBzaV for ; Mon, 19 Mar 2012 07:22:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C236421F8741 for ; Mon, 19 Mar 2012 07:22:15 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49170) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9dTE-000BU0-Nc; Mon, 19 Mar 2012 10:22:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F65ACE3.1050307@telia.com> References: <4F65ACE3.1050307@telia.com> Date: Mon, 19 Mar 2012 10:12:29 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 14:22:16 -0000 Anders, You send a fair number of messages to this list, but you rarely seem to contribute in a positive sense. For example, you don't take the time to write an I-D addressing a PKI standards topic, post it as an individual submission, and then ask of the WG to consider it for adoption. Instead, you complain about how the WG is not addressing the right topics and tell us about your ideas in a general sense. That's not very helpful. Your most recent request illustrates this point, i.e., you want Stefan to devote a slot to a topic where you will not be present, have not persuaded someone to brief your slides, etc. Steve From piyush@identicate.com Mon Mar 19 07:53:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111C221F8860 for ; Mon, 19 Mar 2012 07:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9enBW6fE17Y for ; Mon, 19 Mar 2012 07:53:27 -0700 (PDT) Received: from col0-omc3-s14.col0.hotmail.com (col0-omc3-s14.col0.hotmail.com [65.55.34.152]) by ietfa.amsl.com (Postfix) with ESMTP id A1EBB21F885F for ; Mon, 19 Mar 2012 07:53:27 -0700 (PDT) Received: from COL119-W16 ([65.55.34.137]) by col0-omc3-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 07:53:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0b46b557-848f-41da-9437-26d9cbf7fe45_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Mon, 19 Mar 2012 07:53:26 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 19 Mar 2012 14:53:27.0604 (UTC) FILETIME=[0AD33740:01CD05E0] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 14:53:29 -0000 --_0b46b557-848f-41da-9437-26d9cbf7fe45_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the contrary=2C it'll address the objections to move to non sequential n= umbers. There are installations today that are using the unadvertised feature in Mi= crosoft CA to generate sequential serial numbers=2C just because the curren= t OCSP spec makes pre-signing for certificates with random serial numbers i= mpossible. -Piyush Date: Mon=2C 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com=3B pkix@ietf.org My fear is that this will glue CAs to sequential serial numbers and prevent= them from moving to non sequential serial numbers when needed. /Stefan From: Piyush Jain Date: Sun=2C 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson =2C Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response. Range response is just an optimal way of packing a large number of single r= esponses in one OCSP response. This is how pre-signing of OCSP is done today.One (or more) more keyed resp= onders create a list of OCSP responses which is then mirrored to multiple k= eyless responders. Relying parties use these keyless responders to check th= e status of certificates. One OCSP response is usually packed with status o= f muliple certificates to minimize the number of signings. However=2C the t= rade off is that the OCSP response gets bloated. Problem:1) The current representation of OCSP response is inefficient. Let'= s say that the range of issued certificates by a CA is 'M' and the number o= f revoked certificates in the CRL is 'N'. We know that typically M is much = bigger than N. Using the current OCSP response representation =2C you need = to create M responses to account for every serial number that the CA issue= d. Using ranges you could achieve the same thing using at most 2*N + 1 res= ponses ( Think of it as an efficient representation of a sparse array).=20 2)For CAs that issue certificates using random serial numbers=2C M is so bi= g that it becomes computationally impossible to pre-sign responses for tho= se CAs unless the responder has access to the CA database.=20 Range response will facilitate pre-signing of OCSP responses for CAs that i= ssue certificates with non sequential serial numbers and reduce the computa= tion and bandwidth requirements even for CAs who issue certificates with se= quential serial numbers. -Piyush > Date: Sun=2C 18 Mar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP >=20 > Trying to return to the actual question I would like to take up in > Santosh's question. >=20 > What problem is this trying to solve? >=20 > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes=2C it would not be a signed proof that this is not a replay sent by E= ve > in order to fool you to reject a perfectly valid cert. >=20 > But it would be an indication that something is fishy here and should be > investigated. >=20 > Either you have a MitM swapping the OCSP responses=2C or you have a bad O= CSP > responder=2C or you have a compromised CA. > Time to push the alarm and figure out what's wrong. >=20 > What more would you get from prefabricating all these OCSP range response= s? >=20 > /Stefan >=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 = --_0b46b557-848f-41da-9437-26d9cbf7fe45_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On the contrary=2C it'll address the objections to move to non sequential n= umbers.

There are installations today that are using the= unadvertised feature in Microsoft CA to generate sequential serial numbers= =2C just because the current OCSP spec makes pre-signing for certificates w= ith random serial numbers impossible.

-Piyush
<= div>
Date: Mon= =2C 19 Mar 2012 11:35:14 +0100
Subject: Re: [pkix] Range responses in OC= SP
From: stefan@aaa-sec.com
To: piyush@identicate.com=3B pkix@ietf.or= g

My fear is tha= t this will glue CAs to sequential serial numbers and prevent them from mov= ing to non sequential serial numbers when needed.

= /Stefan

Fro= m: Piyush Jain <=3Bpiyus= h@identicate.com>=3B
Date: Sun=2C 18 Mar 2012 20:57:26 -0700
To:= Stefan Santesson <=3Bstefa= n@aaa-sec.com>=3B=2C <=3Bpkix@ietf= .org>=3B
Subject: Re: [pk= ix] Range responses in OCSP

I think the proposal to have OCSP support range responses should be discuss= ed =3Bseparately =3Bfrom the proposal to add "does not exist" respo= nse.

Range response is just an optimal way of packing a = large number of single responses in one OCSP response.

=
This is how pre-signing of OCSP is done today.
One (or more)= more keyed responders create a list of OCSP responses which is then mirror= ed to multiple keyless responders. Relying parties use these keyless respon= ders to check the status of certificates. =3BOne OCSP response is usually packed with status of muliple certificate= s to minimize the number of signings.=  =3BHowever=2C the trade off is that the OCSP response gets bloated.

Problem:
1) The current representat= ion of OCSP response is inefficient. Let's say that the range of issued cer= tificates by a CA is 'M' and the number of revoked certificates in the CRL = is 'N'. We know that typically M is much bigger than N. Using the current O= CSP response representation =2C you need to create M  =3Bresponses to a= ccount for every serial number that the CA issued. Using ranges you could &= nbsp=3B
achieve the same thing using at most 2*N + 1 responses ( = Think of it as an efficient representation of a sparse array). =3B

2)For CAs that issue certificates using random serial = numbers=2C M is so big that it becomes computationally  =3Bimpossible t= o pre-sign responses for those CAs unless the responder has access to the C= A database. =3B

Range response will facilitate= pre-signing of OCSP responses for CAs that issue certificates with non seq= uential serial numbers and reduce the =3Bcomputation =3Band bandwid= th requirements even for CAs who issue certificates with sequential serial = numbers.

-Piyush

>=3B Date: Sun=2C 18 Mar 2012 23:48:52 +0100>=3B From: stefan@aaa-sec.com=
>=3B To: pkix@ietf.org
>=3B= Subject: Re: [pkix] Range responses in OCSP
>=3B
>=3B Trying to= return to the actual question I would like to take up in
>=3B Santosh= 's question.
>=3B
>=3B What problem is this trying to solve?
= >=3B
>=3B Why would it not be enough to just craft one standard res= ponse saying "I
>=3B have no record of the certificate you are asking = for"?
>=3B Yes=2C it would not be a signed proof that this is not a re= play sent by Eve
>=3B in order to fool you to reject a perfectly valid= cert.
>=3B
>=3B But it would be an indication that something is= fishy here and should be
>=3B investigated.
>=3B
>=3B Eith= er you have a MitM swapping the OCSP responses=2C or you have a bad OCSP>=3B responder=2C or you have a compromised CA.
>=3B Time to push t= he alarm and figure out what's wrong.
>=3B
>=3B What more would = you get from prefabricating all these OCSP range responses?
>=3B
&= gt=3B /Stefan
>=3B
>=3B
>=3B _____________________________= __________________
>=3B pkix mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/listi= nfo/pkix
_________________= ______________________________ pkix mailing list pkix@ietf.org ht= tps://www.ietf.org/mailman/listinfo/pkix
= --_0b46b557-848f-41da-9437-26d9cbf7fe45_-- From SChokhani@cygnacom.com Mon Mar 19 08:06:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2BF21F872F for ; Mon, 19 Mar 2012 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIy8e1Ib17j0 for ; Mon, 19 Mar 2012 08:06:23 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id C982A21F858D for ; Mon, 19 Mar 2012 08:06:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,611,1325480400"; d="scan'208,217";a="588512" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 19 Mar 2012 11:06:19 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 19 Mar 2012 11:06:19 -0400 From: Santosh Chokhani To: Piyush Jain , "stefan@aaa-sec.com" , "pkix@ietf.org" Date: Mon, 19 Mar 2012 11:06:17 -0400 Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0F4COMrIosmP7gTe+rDzTDDOcdOwAAPPzA Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 15:06:24 -0000 --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Piyush, If the serial numbers truly random, how would you do this without declaring= unissued certificates as valid? I suspect you are saying that if the CA is compromised, all of this does no= t matter and if the CA is not compromised, declaring unissued as legitimate= hurts nothing. Is this what you are saying. If so, this is yet another reason not to incl= ude never issued. BTW, the most folks deal with pre-signing today by having multiple response= s in a pre-signed bundle. The bundle is generally configurable and I have = seen bundle size as high as 20, reducing the signing workload by a factor o= f 20. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain Sent: Monday, March 19, 2012 10:53 AM To: stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP On the contrary, it'll address the objections to move to non sequential num= bers. There are installations today that are using the unadvertised feature in Mi= crosoft CA to generate sequential serial numbers, just because the current = OCSP spec makes pre-signing for certificates with random serial numbers imp= ossible. -Piyush ________________________________ Date: Mon, 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com; pkix@ietf.org My fear is that this will glue CAs to sequential serial numbers and prevent= them from moving to non sequential serial numbers when needed. /Stefan From: Piyush Jain > Date: Sun, 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson >, > Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response. Range response is just an optimal way of packing a large number of single r= esponses in one OCSP response. This is how pre-signing of OCSP is done today. One (or more) more keyed responders create a list of OCSP responses which i= s then mirrored to multiple keyless responders. Relying parties use these k= eyless responders to check the status of certificates. One OCSP response is= usually packed with status of muliple certificates to minimize the number = of signings. However, the trade off is that the OCSP response gets bloated. Problem: 1) The current representation of OCSP response is inefficient. Let's say th= at the range of issued certificates by a CA is 'M' and the number of revoke= d certificates in the CRL is 'N'. We know that typically M is much bigger t= han N. Using the current OCSP response representation , you need to create = M responses to account for every serial number that the CA issued. Using r= anges you could achieve the same thing using at most 2*N + 1 responses ( Think of it as an = efficient representation of a sparse array). 2)For CAs that issue certificates using random serial numbers, M is so big = that it becomes computationally impossible to pre-sign responses for those= CAs unless the responder has access to the CA database. Range response will facilitate pre-signing of OCSP responses for CAs that i= ssue certificates with non sequential serial numbers and reduce the computa= tion and bandwidth requirements even for CAs who issue certificates with se= quential serial numbers. -Piyush > Date: Sun, 18 Mar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP > > Trying to return to the actual question I would like to take up in > Santosh's question. > > What problem is this trying to solve? > > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes, it would not be a signed proof that this is not a replay sent by Eve > in order to fool you to reject a perfectly valid cert. > > But it would be an indication that something is fishy here and should be > investigated. > > Either you have a MitM swapping the OCSP responses, or you have a bad OCS= P > responder, or you have a compromised CA. > Time to push the alarm and figure out what's wrong. > > What more would you get from prefabricating all these OCSP range response= s? > > /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 --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Piyush,=

 

If the serial numbers truly random, how would you do th= is without declaring unissued certificates as valid?

<= p class=3DMsoNormal> 

I suspect you are saying that if the CA is compromised, all of this does = not matter and if the CA is not compromised, declaring unissued as legitima= te hurts nothing.

 =

Is this what you are saying. = ; If so, this is yet another reason not to include never issued.=

 

BTW, the most folks deal with pre-signing today by having mul= tiple responses in a pre-signed bundle.  The bundle is generally confi= gurable and I have seen bundle size as high as 20, reducing the signing wor= kload by a factor of 20.

 

From: pkix-bounc= es@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain<= br>Sent: Monday, March 19, 2012 10:53 AM
To: stefan@aaa-se= c.com; pkix@ietf.org
Subject: Re: [pkix] Range responses in OCSP<= o:p>

 

=

On the contrary, it'll address the objections to move to = non sequential numbers.

 <= /o:p>

There are installations today that = are using the unadvertised feature in Microsoft CA to generate sequential s= erial numbers, just because the current OCSP spec makes pre-signing for cer= tificates with random serial numbers impossible.

 

-Piy= ush

Date: Mon, 19 Mar= 2012 11:35:14 +0100
Subject: Re: [pkix] Range responses in OCSP
From= : stefan@aaa-sec.com
To: piyush@identicate.com; pkix@ietf.org

My fear is that this will glue CAs to sequential serial numbers and pr= event them from moving to non sequential serial numbers when needed.

 

/Stefan

&= nbsp;

From: Piyush Jain <piyus= h@identicate.com>
Date: Sun, 18 Mar 2012 20:57:26 -0700To: Stefan Santesson <stef= an@aaa-sec.com>, <pkix@ietf.org<= /a>>
Subject: Re: [pkix] Range responses in OCSP

I think the proposal to have OCS= P support range responses should be discussed separately from the= proposal to add "does not exist" response.

=

 

Range= response is just an optimal way of packing a large number of single respon= ses in one OCSP response.

 

This is how pre-signing of = OCSP is done today.

One (or mo= re) more keyed responders create a list of OCSP responses which is then mir= rored to multiple keyless responders. Relying parties use these keyless res= ponders to check the status of certificates. One OCSP response is usua= lly packed with status of muliple certificates to minimize the number of si= gnings. However, the trade off is that the OCSP response gets bloated.=

 

<= /div>

Problem:

1) The current representation of OCSP response is inefficient. Let's say = that the range of issued certificates by a CA is 'M' and the number of revo= ked certificates in the CRL is 'N'. We know that typically M is much bigger= than N. Using the current OCSP response representation , you need to creat= e M  responses to account for every serial number that the CA issued. = Using ranges you could  

= achieve the same thing using at most 2*N + 1 responses ( Think of it as an = efficient representation of a sparse array). 

 

2)= For CAs that issue certificates using random serial numbers, M is so big th= at it becomes computationally  impossible to pre-sign responses for th= ose CAs unless the responder has access to the CA database. 

 

=

Range response will facilitate pre-signing of OCSP responses f= or CAs that issue certificates with non sequential serial numbers and reduc= e the computation and bandwidth requirements even for CAs who iss= ue certificates with sequential serial numbers.

=

 

-Piyu= sh

 

> Date: Sun, 18 Mar 2012 23:48:52 +0100
> From:= stefan@aaa-sec.com
> To: <= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org
> Subject: Re: [pki= x] Range responses in OCSP
>
> Trying to return to the actual = question I would like to take up in
> Santosh's question.
> > What problem is this trying to solve?
>
> Why would it n= ot be enough to just craft one standard response saying "I
> hav= e no record of the certificate you are asking for"?
> Yes, it wo= uld not be a signed proof that this is not a replay sent by Eve
> in = order to fool you to reject a perfectly valid cert.
>
> But it= would be an indication that something is fishy here and should be
> = investigated.
>
> Either you have a MitM swapping the OCSP res= ponses, or you have a bad OCSP
> responder, or you have a compromised= CA.
> Time to push the alarm and figure out what's wrong.
> > What more would you get from prefabricating all these OCSP range res= ponses?
>
> /Stefan
>
>
> ________________= _______________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mail= man/listinfo/pkix

_______________________________________________ pkix mailing lis= t pkix@ietf.org https://www.ietf.org/mai= lman/listinfo/pkix

= --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_-- From anders.rundgren@telia.com Mon Mar 19 08:16:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAED621F87C9 for ; Mon, 19 Mar 2012 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQwgHmFukXDr for ; Mon, 19 Mar 2012 08:16:20 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id A758C21F87C0 for ; Mon, 19 Mar 2012 08:16:19 -0700 (PDT) Received: from [192.168.3.131] (193.12.106.2) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E00323DA0; Mon, 19 Mar 2012 16:16:13 +0100 Message-ID: <4F674DAF.4020005@telia.com> Date: Mon, 19 Mar 2012 16:15:59 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Stephen Kent References: <4F65ACE3.1050307@telia.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 15:16:21 -0000 On 2012-03-19 15:12, Stephen Kent wrote: > Anders, > > You send a fair number of messages to this list, but you rarely seem > to contribute in a positive sense. For example, you don't take the > time to write an I-D addressing a PKI standards topic, post it as an > individual submission, and then ask of the WG to consider it for > adoption. Instead, you complain about how the WG is not addressing > the right topics and tell us about your ideas in a general sense. > That's not very helpful. Your most recent request illustrates this > point, i.e., you want Stefan to devote a slot to a topic where you > will not be present, have not persuaded someone to brief your slides, > etc. Steve, Since a standard of the kind I have been elaborating on (including links to detailed specifications and as well as to somewhat lighter presentations), would probably exceed 200 pages, writing an I-D is hardly an option unless there is a genuine interest for the topic in question. But I guess we now have indirectly performed this poll so you may very well stick to the agenda as written. Anders From kent@bbn.com Mon Mar 19 09:03:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813D721F8600 for ; Mon, 19 Mar 2012 09:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2ElQjaTE-jn for ; Mon, 19 Mar 2012 09:03:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ABB6A21F8616 for ; Mon, 19 Mar 2012 09:03:44 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9f3T-000EpQ-1e; Mon, 19 Mar 2012 12:03:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <006AE699-552A-4E7B-9B79-BEDE6B69B18F@jpl.nasa.gov> References: , <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org>, , , <4F63838C.4090408@nist.gov>, <006AE699-552A-4E7B-9B79-BEDE6B69B18F@jpl.nasa.gov> Date: Mon, 19 Mar 2012 11:55:17 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:03:45 -0000 Henry, a "does not exist" reply represents a deviation from the stated scope of OCSP, and thus if we're going to pursue it we need a thorough explanation of what problems it solves, and how it interacts with various implementation models, e.g., OCSP servers that generate responses based only on access to CRLs. Steve From kent@bbn.com Mon Mar 19 09:03:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5A21F87E1 for ; Mon, 19 Mar 2012 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt0ERg9hnnaf for ; Mon, 19 Mar 2012 09:03:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 724C521F87DF for ; Mon, 19 Mar 2012 09:03:52 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9f3d-000EpQ-1W; Mon, 19 Mar 2012 12:03:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <881277C7-B17F-42DB-B956-225E61587055@jpl.nasa.gov> References: <881277C7-B17F-42DB-B956-225E61587055@jpl.nasa.gov> Date: Mon, 19 Mar 2012 11:39:39 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 16:03:53 -0000 At 12:44 AM -0700 3/16/12, Henry B. Hotz wrote: >On Mar 14, 2012, at 1:47 PM, Stephen Kent wrote: > >> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >>> Does anyone use SCVP? >> >> I'll let others, who know better than I, respond to this question. >> >>> If there is going to be a choice between maintaining OCSP and >>> maintaining SCVP then OCSP is going to be the one that I choose. >> >> If the proposal is to keep the name OCSP and add a lot of functionality >> that overlaps SCVP, that is not a reasonable course of action. > >What course of action do you think will most quickly give us an >off-the-shelf web browser that can most usefully verify it's >connecting to the intended destination? Someone complained the real >problem was that browsers don't "fail hard" even when OCSP is turned >on. I see it as a chicken-and-egg problem where a browser shouldn't >fail hard unless OCSP actually tells the browser what it needs to >know. Henry, Your statement focuses on a broad topic, one that seems to be beyond what PHB suggested when he started this thread. For that broad topic, look at what the DANE WG is doing. >I won't argue OCSP+ vs SCVP because I don't actually care. I'm very >surprised that the idea of adding a never-issued response to OCSP is >so controversial however. It appears to me that some people are >reading more into it than was originally intended. A change to OCSP to solve a problem needs to be justified by a well-written statement of the problem to be solved, and an argument about why the proposed solution is the nest way to solve the problem. Both of those are missing here. >... > > If we're looking to address security problems related to cert >revocation, and >> which have become more serious due to browser trust model problems and due >> to attacks on public CAs, that also may be appropriate for OCSP. > >I thought that was the original idea, yes. Several (other) folks have argued that the suggested change does not do a great job of addressing this bigger problem, relative to the costs it imposes, and others have noted that we lack a clear description of the problem. > >> But, as I noted above and in my previous message, if the goal is to >> keep the OCSP name because it is widely known, and to add new functions >> that extend OCSP functionality and that overlap with SCVP functions, then >> we have a problem. > >I'll grant you that adding never-issued to OCSP starts a slippery >slope in that direction, but see above. Well, at least we agree on this point :-). Steve From kent@bbn.com Mon Mar 19 09:39:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03D421F87A3 for ; Mon, 19 Mar 2012 09:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76DnWjdQP0Nz for ; Mon, 19 Mar 2012 09:39:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9021F87CD for ; Mon, 19 Mar 2012 09:39:06 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9f3h-000EpQ-Al; Mon, 19 Mar 2012 12:03:46 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Mar 2012 11:42:51 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 16:39:06 -0000 At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >Suppose we accept both your arguments below, and Stephen Kent's >arguments that SCVP is the right solution for the real problem faced >by ordinary users. Steve Kent didn't say that. He said that PKIX decided to develop SCVP instead of extending OCSP, when we lasted visited this sort of topic. In later messages I noted that folks did not except public CAs to operate SCVP servers; SCVP is best suited for enterprise environments. Steve From kent@bbn.com Mon Mar 19 09:39:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168F621F87A3 for ; Mon, 19 Mar 2012 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xItIUPxiWqYm for ; Mon, 19 Mar 2012 09:39:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4986F21F87C9 for ; Mon, 19 Mar 2012 09:39:04 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9f3k-000EpQ-KC; Mon, 19 Mar 2012 12:03:48 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Mar 2012 12:03:37 -0400 To: hallam@gmail.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879949458==_ma============" Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 16:39:07 -0000 --============_-879949458==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote: >On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent wrote: >> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >> >> Does anyone use SCVP? >> >> >> I'll let others, who know better than I, respond to this question. >> >> If there is going to be a choice between maintaining OCSP and >> maintaining SCVP then OCSP is going to be the one that I choose. >> >> >> If the proposal is to keep the name OCSP and add a lot of functionality >> that overlaps SCVP, that is not a reasonable course of action. > >OCSP is the Online Certificate Status Protocol. This is Certificate >Status. So if we accept your argument that there is overlap with SCVP, >the fault is with SCVP. Not true. OCSP is a sloppy shorthand name or a protocol that reports the revocation status of a cert, as noted in RFC 2560: 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. [RFC2459], Section 3.3). >This is a minor incremental development of the protocol to address a >functionality that was originally intended. > > >> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an >> alternative (to CRLs) for checking the revocation status of a cert. If we >> have good reasons >> to improve on that function, then doing so using OCSP makes sense. > >You suggested that the existence of SCVP means we cannot add new >features to OCSP. I suggested that if a new OCSP feature is already present in SCVP, then we ought not add that feature to OCSP. That statement should be interpreted by the context in which each protocol is intended to operate. So, if the (not well articulated) problem space being addressed is public CAs, vs. enterprise CAs, then SCVP is not an appropriate alternative. >I said that I don't accept that as virtually nobody uses SCVP. So if >you want to push that idea I think it is time to move SCVP to HISTORIC >and slim down the stack a little. I'll interpret this statement as a rhetorical gimmick on your part, as it does not merit being treated as a serious proposal. >... > >The functionality is certificate status and SCVP is totally >irrelevant. SCVP does not address this subject area and no public CA >uses it. I agree that SCVP is not an appropriate protocol for public CA cert status checking. But, since you've not provided a good description of the problem that you want to solve with a change to OCSP, you didn't rule out SCVP. Subsequent list traffic shows that some folks are interpreting your proposal in an enterprise context, which is where there is a direct conflict with an extant PKIX standard. >OCSP has an extension mechanism. It should have been used to implement >SCVP in the first place. You are entitled to that belief, but the WG did not agree. We went through a long, fair process to decide how to proceed, and SCVP was the winner. The fact that your pick didn't win then is not a basis for trying to reclassify SCVP as historic. In subsequent messages directed to other folks you said that a goal is "... enable a re-engineering of CA architecture so that we eliminate 'single break' systems." That's a noble goal, but if it is also a big topic, not one that we address with a change to OCSP. Agsin, we lack an adequate description of the problem to be solved. Steve --============_-879949458==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] Possible OCSP Extensions

At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote:
On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent <kent@bbn.com> wrote:
> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote:
>
> Does anyone use SCVP?
>
>
> I'll let others, who know better than I, respond to this question.
>
> If there is going to be a choice between maintaining OCSP and
> maintaining SCVP then OCSP is going to be the one that I choose.
>
>
> If the proposal is to keep the name OCSP and add a lot of functionality
> that overlaps SCVP, that is not a reasonable course of action.

OCSP is the Online Certificate Status Protocol. This is Certificate
Status. So if we accept your argument that there is overlap with SCVP,
the fault is with SCVP.

Not true. OCSP is a sloppy shorthand name or a protocol that reports the
revocation status of a cert, as noted in RFC 2560:

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. [RFC2459], Section 3.3).

This is a minor incremental development of the protocol to address a
functionality that was originally intended.


> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an
> alternative (to CRLs) for checking the revocation status of a cert. If we
> have good reasons
> to improve on that function, then doing so using OCSP makes sense.

You suggested that the existence of SCVP means we cannot add new
features to OCSP.

I suggested that if a new OCSP feature is already present in SCVP, then
we ought not add that feature to OCSP. That statement should be interpreted
by the context in which each protocol is intended to operate. So, if the
(not well articulated) problem space being addressed is public CAs, vs.
enterprise CAs, then SCVP is not an appropriate alternative.

I said that I don't accept that as virtually nobody uses SCVP. So if
you want to push that idea I think it is time to move SCVP to HISTORIC
and slim down the stack a little.

I'll interpret this statement as a rhetorical gimmick on your part, as it does not merit being treated as a serious proposal.

...

The functionality is certificate status and SCVP is totally
irrelevant. SCVP does not address this subject area and no public CA
uses it.

I agree that SCVP is not an appropriate protocol for public CA cert status checking. But, since you've not provided a good description of the problem
that you want to solve with a change to OCSP, you didn't rule out SCVP.
Subsequent list traffic shows that some folks are interpreting your proposal in an enterprise context, which is where there is a direct conflict with an
extant PKIX standard.

OCSP has an extension mechanism. It should have been used to implement
SCVP in the first place.

You are entitled to that belief, but the WG did not agree. We went through
a long, fair process to decide how to proceed, and SCVP was the winner.  The fact that your pick didn't win then is not a basis for trying to reclassify
SCVP as historic.

In subsequent messages directed to other folks you said that a goal is "... enable a re-engineering of CA architecture so that we eliminate 'single break' systems."  That's a noble goal, but if it is also a big topic, not one that we address with a change to OCSP. Agsin, we lack an adequate description of the problem to be solved.



Steve
--============_-879949458==_ma============-- From stefan@aaa-sec.com Mon Mar 19 09:40:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B292D21F888D for ; Mon, 19 Mar 2012 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHq9UN+XRYkq for ; Mon, 19 Mar 2012 09:40:44 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id DF1AA21F8887 for ; Mon, 19 Mar 2012 09:40:43 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 26A621DCAA90 for ; Mon, 19 Mar 2012 17:39:58 +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 4oJWyEWpQEnt for ; Mon, 19 Mar 2012 17:39:57 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E1E291DCAA61 for ; Mon, 19 Mar 2012 17:39:57 +0100 (CET) Received: (qmail 56340 invoked from network); 19 Mar 2012 16:39:57 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.215]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Mar 2012 16:39:57 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 19 Mar 2012 17:39:46 +0100 From: Stefan Santesson To: Stephen Kent , Liaquat Khan Message-ID: Thread-Topic: [pkix] certificate not issued OCSP status response In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:40:44 -0000 Steve, I think I lost you here. On 12-03-19 3:21 PM, "Stephen Kent" wrote: >- no record of cert issuance appears in any CA log. > >- an OCSP response for the cert serial number will not yield >a "revoked" or "not issued" because the legitimate cert in question is >valid and not revoked. If the CA has no record of it, why would it not yield a "not issued" response? I'm not saying that we should go there. Just couldn't follow your logic. /Stefan From mmyers@fastq.com Mon Mar 19 09:51:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C5321F886C for ; Mon, 19 Mar 2012 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRRaXf+EFxSG for ; Mon, 19 Mar 2012 09:51:56 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1921F886F for ; Mon, 19 Mar 2012 09:51:56 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2JGpUY9017701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 09:51:31 -0700 Message-Id: From: Michael Myers To: Stefan Santesson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Mar 2012 09:56:59 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:51:56 -0000 On Mar 19, 2012, at 9:39 AM, Stefan Santesson wrote: > If the CA has no record of it, why would it not yield a "not issued" > response? Because one cannot prove a negative. Use 'unknown.' From kent@bbn.com Mon Mar 19 10:00:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010C921F887D for ; Mon, 19 Mar 2012 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4+NUnnSooeR for ; Mon, 19 Mar 2012 10:00:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5296F21F8820 for ; Mon, 19 Mar 2012 10:00:52 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49175) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9fwm-000Gc9-SZ for pkix@ietf.org; Mon, 19 Mar 2012 13:00:41 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Mar 2012 12:58:39 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879946045==_ma============" Subject: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 17:00:54 -0000 --============_-879946045==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" David, I have three suggestions for text for the 5280 clarifications doc: In your latest rev there is added text that addresses one of the issues that arose in DANE re self-signed EE cert use in the TLS context. I find that text confusing. I suggest the following text, which focuses on a different aspect of SS-EE cert use. We need to ask the Security ADs if they feel the following text, or some combination of it and what you already wrote, addresses the DANE issues. Section 3.2: insert this new paragraph after the (current) last paragraph The PKI model defined in X.509 requires that an entity that signs a (public key) certificate be a CA. The notion of a self-signed end entity certificate deviates from the X.59 model. A self-signed, end entity certificate generally is not compatible with the certificate path validation mechanism described in Section 6. However, as noted in Sections 6.1 and 6.1.1, a self-signed certificate may be used convey a trust anchor. In practice, if this trust anchor certificate fails to include the BasicConstraints extension, which is used to mark a certificate as a CA certificate, this does not adversely affect certificate path processing. Thus the preceding text discussing certificate types should be interpreted as follows: A self-signed certificate used exclusively to convey trust anchor data need not be marked as a CA certificate, although such marking is RECOMMENDED. All other self-signed certificates MUST be marked as CA certificates. Sean Turner also suggested that we make an explicit reference to RFC 5937, when we discuss path processing. So, I suggest the following text change for 6.1.1: Add the following text in 6.1.1, at the end of the section. OLD: Conforming implementations are not required to support the setting of all of these inputs. For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit. NEW: Conforming implementations are not required to support the setting of all of these inputs. For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit. Implementers are encouraged to make use of the capabilities defined in RFC 5937, which describes how to make use of trust anchor constraints during path processing, including certificate policies, name constraints, and path length. Finally, based on the discussions in SIDR and the docs that have been issued as RFCs, I suggest the following changes to text in the Secruity Considerations section: Replace the following text with the new text below, in the security considerations section (Section 8) OLD: While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. As a means of reducing problems and security issues related to issuer name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor. NEW: While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. This could occur accidentally or it might be part of an attack. In the latter case, a CA might issue certificates to CAs, inserting subject names that intentionally conflict with subject names in other, legitimate certificates. A CA behaving in this fashion might also assign certificate serial numbers to collide with entities being targeted in the attack. To address the possibility of accidental name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Examples of such techniques appear in Section 8 of [RFC 6487]. To address both accidental and malicious scenarios, implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name (and possibly the same serial number). At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor. --============_-879946045==_ma============ Content-Type: text/html; charset="us-ascii" 5280 clarifications
David,

I have three suggestions for text for the 5280 clarifications doc:

In your latest rev there is added text that addresses one of the issues that arose in DANE re self-signed EE cert use in the TLS context.  I find that text confusing. I suggest the following text, which focuses on a different aspect
of SS-EE cert use. We need to ask the Security ADs if they feel the following text, or some combination of it and what you already wrote, addresses the
DANE issues.

Section 3.2: insert this new paragraph after the (current) last paragraph
The PKI model defined in X.509 requires that an entity that signs a (public key) certificate be a CA. The notion of a self-signed end entity certificate deviates from the X.59 model. A self-signed, end entity certificate generally is not compatible with the certificate path validation mechanism described in Section 6. However, as noted in Sections 6.1 and 6.1.1, a self-signed certificate may be used convey a trust anchor. In practice, if this trust anchor certificate fails to include the BasicConstraints extension, which is used to mark a certificate as a CA certificate, this does not adversely affect certificate path processing. Thus the preceding text discussing certificate types should be interpreted as follows: A self-signed certificate used exclusively to convey trust anchor data need not be marked as a CA certificate, although such marking is RECOMMENDED. All other self-signed certificates MUST be marked as CA certificates.

Sean Turner also suggested that we make an explicit reference to RFC 5937, when we discuss path processing.  So, I suggest the following text change for 6.1.1:

Add the following text in 6.1.1, at the end of the section.

OLD:
Conforming implementations are not required to support the setting of all of these inputs.  For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit.

NEW:
Conforming implementations are not required to support the setting of all of these inputs.  For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit.
Implementers are encouraged to make use of the capabilities defined in RFC 5937, which describes how to make use of trust anchor constraints during path processing, including certificate policies, name constraints, and path length.

Finally, based on the discussions in SIDR and the docs that have been issued as RFCs, I suggest the following changes to text in the Secruity Considerations section:

Replace the following text with the new text below, in the security considerations section (Section 8)
 
OLD:
While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. As a means of reducing problems and security issues related to issuer name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions.  Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name.  At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.


NEW:
While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. This could occur accidentally or it might be part of an attack. In the latter case, a CA might issue certificates to CAs, inserting subject names that intentionally conflict with subject names in other, legitimate certificates. A CA behaving in this fashion might also assign certificate serial numbers to collide with entities being targeted in the attack.

To address the possibility of accidental name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Examples of such techniques appear in Section 8 of [RFC 6487]. To address both accidental and malicious scenarios, implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name (and possibly the same serial number).  At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.
 
--============_-879946045==_ma============-- From brennansecurity@gmail.com Mon Mar 19 10:01:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B993A21F8879 for ; Mon, 19 Mar 2012 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY8Ef+d95pDz for ; Mon, 19 Mar 2012 10:01:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D621F87A7 for ; Mon, 19 Mar 2012 10:01:30 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so7881959vcb.31 for ; Mon, 19 Mar 2012 10:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jrOJUIQgBvo3UdO+iLWamtPmNpDPl0dG1mCnqClkTSI=; b=KMAiRga8fSqvmhwaAFrUY8FVTeJQ8sb0KWNWlLLvRmF1uUAXRrw79dEA33OkPrk0gW wR7xFFZb7V/3uBO5+cXf8LeTgjaFqwuKil36A60y3HCGuzGAI78KHM+muj8OqTDc49BP h4iAPZKkjK/H9i3zBTa+CaKoaPlPkdEYH99+IXJcAG9aB19/K7xRicttHtsPj7df4EPN A2XCMMoYNrBE6sz3Dz2fImCG+ULDzE/42JtYboid47EPGRCsuVg5wvd1hdosST6IPFpI yQL7qpJi053vqFUPs4VBBvoyvdSod+bnC/MEuHrVl0LBcpoFtbVL96GxhfHzzhBPdg8P 2nvQ== MIME-Version: 1.0 Received: by 10.220.141.139 with SMTP id m11mr5047227vcu.56.1332176490318; Mon, 19 Mar 2012 10:01:30 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Mon, 19 Mar 2012 10:01:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 13:01:30 -0400 Message-ID: From: brennan security To: Stephen Kent Content-Type: multipart/alternative; boundary=f46d042f9dca7bcc0d04bb9b8295 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:01:31 -0000 --f46d042f9dca7bcc0d04bb9b8295 Content-Type: text/plain; charset=ISO-8859-1 Steve, Your words, "Th[is] is why a thorough, well-written analysis of the problems to be solved is needed before we pursue changes of the sort being proposed" is exactly what I was thinking. As you suggested, I propose we perform some risk analysis on PKI as it relates to OCSP: Assets: CAs, Validation infrastructure, operating system & application trust stores, transactions, HSMs, etc. Asset vulnerabilities & weaknesses: intrinsic gaps in asset functionality or implementations Threats: exploitations of vulnerabilities and weaknesses current attack/threat scenarios: , both historical and potential (comodo, digitotar/PKIoverheid, RapidSSL, Globalsign, others) and potential remediations for the same. Countermeasures: protective mechanisms, alterations that address vulnerabilities & weaknesses. Then, to conclude, some data on current implementations in industry so any proposed solutions best considers industry impacts and resourcing. To that end I volunteer to work on this effort with others, as it coincides with my present work (high security CA and OCSP infrastructure) Brennan On Mon, Mar 19, 2012 at 10:21 AM, Stephen Kent wrote: > Liaquat, > > Thanks for providing an example of an attack scenario and its implications > re various countermeasures. > > Here's an "easy to imagine" alternative scenario: > > - attacker gains access to HSM and causes a cert to be issued, with the > same serial number as a extant, legitimate cert. > > - no record of cert issuance appears in any CA log. > > - an OCSP response for the cert serial number will not yield > a "revoked" or "not issued" because the legitimate cert in question is > valid and not revoked. > > until the CA is made aware of the bogus cert, it cannot revoke it, > and at that time a CRL or the current OCSP mechanism will work as well > as any proposed enhancements to OCSP. > > Thsi is why a thorough, well-written analysis of the problems to be > solved is needed before we pursue changes of the sort being proposed. > > Steve > > > > ______________________________**_________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/**listinfo/pkix > --f46d042f9dca7bcc0d04bb9b8295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Steve,

Your words, "Th[is] is why a thorough, well-written anal= ysis of the problems to be solved is needed before we pursue changes of the= sort being proposed" is exactly what I was thinking.

As you su= ggested, I propose we perform some risk analysis on PKI as it relates to OC= SP:
Assets: CAs, Validation infrastructure, operating system & application = trust stores, transactions, HSMs, etc.
Asset vulnerabilities & weakn= esses: intrinsic gaps in asset functionality or implementations
Threats:= exploitations of vulnerabilities and weaknesses
current attack/threat scenarios: , both historical and potential (comodo, d= igitotar/PKIoverheid, RapidSSL, Globalsign, others) and potential remediati= ons for the same.
Countermeasures: protective mechanisms, alterations th= at address vulnerabilities & weaknesses.

Then, to conclude, some data on current implementations in industry so = any proposed solutions best considers industry impacts and resourcing.

To that end I volunteer to work on this effort with others, as it coinc= ides with my present work (high security CA and OCSP infrastructure)
Brennan

On Mon, Mar 19, 2012 at 10:21 AM= , Stephen Kent <kent@bbn.com> wrote:
Liaquat,

Thanks for providing an example of an attack scenario and its implications = re various countermeasures.

Here's an "easy to imagine" alternative scenario:

=A0- attacker gains access to HSM and causes a cert to be issued, with the<= br> same serial number as a extant, legitimate cert.

- no record of cert issuance appears in any CA log.

- an OCSP response for the cert serial number will not yield
a "revoked" or "not issued" because the legitimate cert= in question is
valid and not revoked.

until the CA is made aware of the bogus cert, it cannot revoke it,
and at that time a CRL or the current OCSP mechanism will work as well
as any proposed enhancements to OCSP.

Thsi is why a thorough, well-written analysis of the problems to be
solved is needed before we pursue changes of the sort being proposed.

Steve



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

--f46d042f9dca7bcc0d04bb9b8295-- From DPKemp@missi.ncsc.mil Mon Mar 19 10:07:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF51F21F888C for ; Mon, 19 Mar 2012 10:07:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CORuOeKOyCi for ; Mon, 19 Mar 2012 10:07:34 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7721F8869 for ; Mon, 19 Mar 2012 10:07:33 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2JH7Xbj033673 for ; Mon, 19 Mar 2012 13:07:33 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 13:07:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 19 Mar 2012 13:07:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: Ac0F7zifm8ttckktSByBIzOUUF3PQQAAwy8w References: From: "Kemp, David P." To: X-OriginalArrivalTime: 19 Mar 2012 17:07:33.0098 (UTC) FILETIME=[C6502CA0:01CD05F2] Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:07:35 -0000 In Steve's example, the attacker-generated cert (for which there is no record) has the same serial number as a legitimately-issued cert. The CA's database shows the serial number as existing and not revoked, and nothing has come to the CA's attention to indicate that two certs with the same serial number have been signed. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, March 19, 2012 12:40 PM To: Stephen Kent; Liaquat Khan Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response Steve, I think I lost you here. On 12-03-19 3:21 PM, "Stephen Kent" wrote: >- no record of cert issuance appears in any CA log. > >- an OCSP response for the cert serial number will not yield a=20 >"revoked" or "not issued" because the legitimate cert in question is=20 >valid and not revoked. If the CA has no record of it, why would it not yield a "not issued" response? I'm not saying that we should go there. Just couldn't follow your logic. /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Mon Mar 19 10:10:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2921F8782 for ; Mon, 19 Mar 2012 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUcFXf0Sxh8a for ; Mon, 19 Mar 2012 10:10:38 -0700 (PDT) Received: from col0-omc3-s17.col0.hotmail.com (col0-omc3-s17.col0.hotmail.com [65.55.34.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6CC21F8755 for ; Mon, 19 Mar 2012 10:10:38 -0700 (PDT) Received: from COL119-W56 ([65.55.34.137]) by col0-omc3-s17.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 10:10:35 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a7ea35d2-fa73-48e1-bfea-04e1c0082425_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Mon, 19 Mar 2012 10:10:30 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 19 Mar 2012 17:10:35.0644 (UTC) FILETIME=[331E7BC0:01CD05F3] Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:10:39 -0000 --_a7ea35d2-fa73-48e1-bfea-04e1c0082425_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Mon=2C 19 Mar 2012 17:39:46 +0100 > From: stefan@aaa-sec.com > To: kent@bbn.com=3B liaquat.khan@ascertia.com > CC: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response >=20 > Steve=2C >=20 > I think I lost you here. >=20 > On 12-03-19 3:21 PM=2C "Stephen Kent" wrote: >=20 > >- no record of cert issuance appears in any CA log. > > > >- an OCSP response for the cert serial number will not yield > >a "revoked" or "not issued" because the legitimate cert in question is > >valid and not revoked. >=20 > If the CA has no record of it=2C why would it not yield a "not issued" > response? because a valid certificate with the same serial exists in CA database. Sin= ce the responder only gets the serial number in the OCSP request=2C it cann= ot differentiate between a fake and a good certificate. > I'm not saying that we should go there. Just couldn't follow your logic. >=20 > /Stefan >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_a7ea35d2-fa73-48e1-bfea-04e1c0082425_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Mon=2C 19 M= ar 2012 17:39:46 +0100
>=3B From: stefan@aaa-sec.com
>=3B To: ken= t@bbn.com=3B liaquat.khan@ascertia.com
>=3B CC: pkix@ietf.org
>= =3B Subject: Re: [pkix] certificate not issued OCSP status response
>= =3B
>=3B Steve=2C
>=3B
>=3B I think I lost you here.
&g= t=3B
>=3B On 12-03-19 3:21 PM=2C "Stephen Kent" <=3Bkent@bbn.com>= =3B wrote:
>=3B
>=3B >=3B- no record of cert issuance appears = in any CA log.
>=3B >=3B
>=3B >=3B- an OCSP response for the = cert serial number will not yield
>=3B >=3Ba "revoked" or "not issue= d" because the legitimate cert in question is
>=3B >=3Bvalid and not= revoked.
>=3B
>=3B If the CA has no record of it=2C why would i= t not yield a "not issued"
>=3B response?

because a valid certificate with the same serial exists in CA database. Si= nce the responder only gets the serial number in the OCSP request=2C it can= not =3Bdifferentiate =3Bbetween a fake and a good certificate.

>=3B I'm not saying that we should go there. Just co= uldn't follow your logic.
>=3B
>=3B /Stefan
>=3B
>=3B=
>=3B _______________________________________________
>=3B pkix = mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman= /listinfo/pkix
= --_a7ea35d2-fa73-48e1-bfea-04e1c0082425_-- From brennansecurity@gmail.com Mon Mar 19 10:14:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B85421F8894 for ; Mon, 19 Mar 2012 10:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3NYdZ+SkTNs for ; Mon, 19 Mar 2012 10:14:48 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1FA21F887D for ; Mon, 19 Mar 2012 10:14:48 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so7897579vcb.31 for ; Mon, 19 Mar 2012 10:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hEy6fUNkGPbUTIlbM58eKRloLEgQMQrdqMWQpbrfoJY=; b=UTqOfixQcpS430BsPEZbujEA5pHv5QBJ/3zpO+TQimDbepBf4iE/AZyoYk2uwQvXao 2iPnquWkQ+0bBTVTvJA0Vs7DA47Ox6/v0JC4BgfxtgNAv3A0Usca5Dr9neQTKHW92GjW SWwMWyduMWjmYYzqtdJJeoYnd1gMJ8sHHQGk8seXF5r0DFgrHtwcz5PDwTE8JloZjT85 jWZ/GyxPo47n9cTwh9iHzjRjJO7KDjl3DEfVyJZZ71CDKHt7+lUZooO5+aPHmbYE/MRs QxqwnAim2z7SWkbE+bUzUFEunbrewGKXPJ+Hi0qAQTClgZqiCRcy2RiXSAZpFq8SZc82 1QCw== MIME-Version: 1.0 Received: by 10.220.141.201 with SMTP id n9mr5062206vcu.66.1332177287490; Mon, 19 Mar 2012 10:14:47 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Mon, 19 Mar 2012 10:14:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 13:14:47 -0400 Message-ID: From: brennan security To: Stefan Santesson , Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:14:49 -0000 Steve, the text from RFC 2560 reads, "The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval." My conclusions from that are: OCSP as a blacklist, didn't anticipate white-list type of functionality A good response is within specs for a response to a query about an unknown and potentially compromised certificate An unknown might be more appropriate for enterprise type of responder implementations and should be more strictly defined. Not issued - as an indicator of a potential CA/RA compromise, should be treated much differently from good / bad / unknown (more daily type of items depending on the implementation). Consequently I concur in the need for a "not issued" response. -b On Mon, Mar 19, 2012 at 12:39 PM, Stefan Santesson wrote: > > Steve, > > I think I lost you here. > > On 12-03-19 3:21 PM, "Stephen Kent" wrote: > > >- no record of cert issuance appears in any CA log. > > > >- an OCSP response for the cert serial number will not yield > >a "revoked" or "not issued" because the legitimate cert in question is > >valid and not revoked. > > If the CA has no record of it, why would it not yield a "not issued" > response? > > I'm not saying that we should go there. Just couldn't follow your logic. > > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From brennansecurity@gmail.com Mon Mar 19 10:18:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3121F88B5 for ; Mon, 19 Mar 2012 10:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cVH207M3L1N for ; Mon, 19 Mar 2012 10:18:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEFDA21F88B2 for ; Mon, 19 Mar 2012 10:18:35 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so7902897vcb.31 for ; Mon, 19 Mar 2012 10:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LAmgWiSi+tsNCGWON9fGD22EN850oiiBY1n/BrjmHS8=; b=V41COz02fsUZxLgkoDbhsBDoxaZ9yFwlPnKEQoE1UTlvCfcn/6/nUQgtRhVMHVlK9T DqXMYXMTnAFpIdRuWhyAizaH1fhS2udKNDxtNjD4D7K1djUR5VafuKo4Itw8xLJbisB8 WQzpeendHFoeD25B5x0werk+TZtl/h6tyEKc4lUEu9MJoULGhiV4ce894J+17+fYinde k5FiK8cshl/k8hdfqWDza8YaRVLM9H5mMOiC4KVOZt+c6r752G1Qyt1J19MXQesU5e79 Ah5iRML4NK9H68wCGjeeZdHitYoqZke/qkVodQlUwjPU/MNPONOV7WRgACuOvV+iPiV6 QSrw== MIME-Version: 1.0 Received: by 10.52.34.200 with SMTP id b8mr5452313vdj.59.1332177515270; Mon, 19 Mar 2012 10:18:35 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Mon, 19 Mar 2012 10:18:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 13:18:35 -0400 Message-ID: From: brennan security To: Piyush Jain Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stefan@aaa-sec.com, pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:18:36 -0000 Piyush, in looking over the RFCs I was wondering the same exact thing, and was curious why CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } didn't look more like CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key certNameHash OCTET STRING, -- Hash of Certificate's DN certKeyHash OCTET STRING, -- Hash of Certificate public key serialNumber CertificateSerialNumber } (is that sufficient?) Perhaps someone in the know could respond on that? -b On Mon, Mar 19, 2012 at 1:10 PM, Piyush Jain wrote: > > >> Date: Mon, 19 Mar 2012 17:39:46 +0100 >> From: stefan@aaa-sec.com >> To: kent@bbn.com; liaquat.khan@ascertia.com >> CC: pkix@ietf.org > >> Subject: Re: [pkix] certificate not issued OCSP status response >> >> Steve, >> >> I think I lost you here. >> >> On 12-03-19 3:21 PM, "Stephen Kent" wrote: >> >> >- no record of cert issuance appears in any CA log. >> > >> >- an OCSP response for the cert serial number will not yield >> >a "revoked" or "not issued" because the legitimate cert in question is >> >valid and not revoked. >> >> If the CA has no record of it, why would it not yield a "not issued" >> response? > > because a valid certificate with the same serial exists in CA database. > Since the responder only gets the serial number in the OCSP request, it > cannot=A0differentiate=A0between a fake and a good certificate. > >> I'm not saying that we should go there. Just couldn't follow your logic. >> >> /Stefan >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From mmyers@fastq.com Mon Mar 19 10:19:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3072121F87BE for ; Mon, 19 Mar 2012 10:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTJySDgjCRel for ; Mon, 19 Mar 2012 10:19:15 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC021F86E3 for ; Mon, 19 Mar 2012 10:19:15 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2JHJ3fS018324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 10:19:04 -0700 Message-Id: <84C2DB3F-6E64-4D8A-B01A-06730EA7247A@fastq.com> From: Michael Myers To: brennan security In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Mar 2012 10:24:32 -0700 References: X-Mailer: Apple Mail (2.936) Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:19:16 -0000 On Mar 19, 2012, at 10:14 AM, brennan security wrote: > Consequently I concur in the need for a "not issued" response I disagree. From hallam@gmail.com Mon Mar 19 10:43:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3D21F878E for ; Mon, 19 Mar 2012 10:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSQicNhDd1sx for ; Mon, 19 Mar 2012 10:43:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 942CE21F8787 for ; Mon, 19 Mar 2012 10:43:57 -0700 (PDT) Received: by yhkk25 with SMTP id k25so3397488yhk.31 for ; Mon, 19 Mar 2012 10:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ynat/ZXZPK7dVAyObnYk0iGMWx4sxl8tdUnZJCAG+m4=; b=H54mCJfz2ECJOhydfUgfYECr+ykxoxSDwNbQgrx/rl3jnSFuUOmpgcko9mMyNb45dg Id/5rgfx6lCEl+eU9LuGoEy0k4FfdSHgAJJrOpd3IJRSydbRW6INMdLkAAnes05psf3l QHMeAY58V+7lUQUzArF6/LqObBpdIslpJhs0Z0/YBHWr5mNM2j3awzREvY71qBi9sKJq N2nyBQW6iqVeZWs/Af73DY6h4EqFrIcUJvB4UyvB9YWIM+30W88Dvl6BrtZU3sR9BId3 0Fstrs1dxC0vbIoo9grxE7uyfrGTknhqKlGjlHKzs/gP1FXMv18MJnH7enHrSUMvZYzM ey4g== MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr15173253obc.15.1332179037114; Mon, 19 Mar 2012 10:43:57 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 19 Mar 2012 10:43:57 -0700 (PDT) In-Reply-To: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> Date: Mon, 19 Mar 2012 13:43:57 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:43:58 -0000 People insist on looking at these interactions on the level of individual client-server interactions which is a mistake. What was most important in the DigiNotar case was not that the cert was revoked or not it was that Google had the means to discover certificates that were not consistent with the issue policy for google.com. In this case a NOTISSUED response for an actual cert would sound alarm bells at the meta-level and an industry level response. Contrawise responding to a request for a non-existent cert with any other status would be a cause for concern. For accountability to work at the CA level, the ability to distinguish these responses is essential. On Mon, Mar 19, 2012 at 10:03 AM, Miller, Timothy J. wr= ote: > On Mar 19, 2012, at 8:18 AM, Tom Ritter wrote: > >> This discussion has gone round and round several times. =A0If a CA takes >> the steps to wire their OCSP responder to their cert database so they >> can make positive assertions about certificates ("Yes, this >> certificate is known and good." vs "This cert is not in my revoked >> list.") the response to a query "Is this certificate good?" that is >> logically "No, that certificate is not good, I don't remember ever >> issuing it!" must be translated to an OCSP status message that causes >> a failure on the client. > > The effect sought is to cause a the client to reject the certificate. =A0= Responding REVOKED does that. =A0If you respond NOTISSUED, does the client = reject the certificate *more* than if you respond REVOKED? =A0:) > >> This is really good. =A0But unless I'm really missing something, there >> is no standard or consensus to do this. > > So what? =A0Why should there be? > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Since i= t's covered by current >> practice - maybe a technical note of some sort could be circulated >> referencing this? > > I said the last time around (November?) that a Security Note would be app= ropriate but changing the protocol is kinda pointless. > >> However, it would still be very nice to tell the client "Things are >> really, *really* weird! You should perhaps do something" which the >> client could then alert the user, save diagnostic information, prompt >> an error-reporting mechanism that's built into several browsers, save >> to a log, or ignore (perhaps with or without an extension - any FF >> extension like NoScript, Cert Patrol, etc would be very interested in >> this info.) > > The idea that you'd use NOTISSUED to cause the client to somehow mark the= CA as untrusted is flawed because it presumes trust in the responder is se= parate from trust in the issuer, which is neither guaranteed, appropriate, = or even actionable at the client. > > If you want to control trust anchors, we have TAMP for that. > > -- T > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From DPKemp@missi.ncsc.mil Mon Mar 19 10:51:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2714821F88A4 for ; Mon, 19 Mar 2012 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmeAgKbfiLXr for ; Mon, 19 Mar 2012 10:51:14 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49421F889A for ; Mon, 19 Mar 2012 10:51:14 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2JHpD2e034507 for ; Mon, 19 Mar 2012 13:51:13 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 13:51:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 19 Mar 2012 13:51:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: Ac0F9+WAi4KuNQswShuCGuEEFPt/WgAAFsAQ References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org><4F63838C.4090408@nist.gov><8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 19 Mar 2012 17:51:13.0567 (UTC) FILETIME=[E03C02F0:01CD05F8] Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:51:15 -0000 Assuming that a NOTISSUED response is universally implemented, why would = a rational attacker choose to generate a cert that would sound alarm = bells and lead to an industry-level response, as opposed to generating a = cert that would pass undetected by piggybacking on a valid cert? -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Phillip Hallam-Baker Sent: Monday, March 19, 2012 1:44 PM To: Miller, Timothy J. Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response People insist on looking at these interactions on the level of = individual client-server interactions which is a mistake. What was most important in the DigiNotar case was not that the cert was = revoked or not it was that Google had the means to discover certificates = that were not consistent with the issue policy for google.com. In this case a NOTISSUED response for an actual cert would sound alarm = bells at the meta-level and an industry level response. Contrawise = responding to a request for a non-existent cert with any other status = would be a cause for concern. For accountability to work at the CA level, the ability to distinguish = these responses is essential. On Mon, Mar 19, 2012 at 10:03 AM, Miller, Timothy J. = wrote: > On Mar 19, 2012, at 8:18 AM, Tom Ritter wrote: > >> This discussion has gone round and round several times. =A0If a CA=20 >> takes the steps to wire their OCSP responder to their cert database=20 >> so they can make positive assertions about certificates ("Yes, this=20 >> certificate is known and good." vs "This cert is not in my revoked >> list.") the response to a query "Is this certificate good?" that is=20 >> logically "No, that certificate is not good, I don't remember ever=20 >> issuing it!" must be translated to an OCSP status message that causes = >> a failure on the client. > > The effect sought is to cause a the client to reject the certificate. = =A0 > Responding REVOKED does that. =A0If you respond NOTISSUED, does the=20 > client reject the certificate *more* than if you respond REVOKED? = =A0:) > >> This is really good. =A0But unless I'm really missing something, = there=20 >> is no standard or consensus to do this. > > So what? =A0Why should there be? > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 >> Since it's covered by current practice - maybe a technical note of=20 >> some sort could be circulated referencing this? > > I said the last time around (November?) that a Security Note would be = appropriate but changing the protocol is kinda pointless. > >> However, it would still be very nice to tell the client "Things are=20 >> really, *really* weird! You should perhaps do something" which the=20 >> client could then alert the user, save diagnostic information, prompt = >> an error-reporting mechanism that's built into several browsers, save = >> to a log, or ignore (perhaps with or without an extension - any FF=20 >> extension like NoScript, Cert Patrol, etc would be very interested in = >> this info.) > > The idea that you'd use NOTISSUED to cause the client to somehow mark = the CA as untrusted is flawed because it presumes trust in the responder = is separate from trust in the issuer, which is neither guaranteed, = appropriate, or even actionable at the client. > > If you want to control trust anchors, we have TAMP for that. > > -- T > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Mon Mar 19 10:52:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3121F889F for ; Mon, 19 Mar 2012 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uAO9PHrr8iU for ; Mon, 19 Mar 2012 10:52:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D41BF21F889A for ; Mon, 19 Mar 2012 10:52:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so3407361yhk.31 for ; Mon, 19 Mar 2012 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oJSLCfI1d/L8w0Jh9Jx+U4hDXjo32Fq/Dt0WGEin88A=; b=WLS06j2AxFtSHVI3XF3e9i0Eo+OOwt88yd/XbdfOlvnQ2sWKxCEFT0/68U3UksvVEE +4gQHXXc2Ct5H5HZVNg9Y98LsVrVBTvvB0BCOZpzpecs7xp3Am9HFTQXf7Z4bPQi/Ec2 ExLFAkoRKQ+dw3DJFn2bvzZCO/OFm77m4JSWIKV8eNRWtzpAy/0bKsadpPlqnYujEOnT 54vogGuz5E42HwpkEb1ojWlsvgfgSjBVNRR7r2fsp5MVwojkDWIuS0ckAiyJ+jdM3Naj Kl9tYfdjCOX/v4AalT4LxW8hZQPrReRyo4122+Av9BOjnyI6OTsLgNPsoo7HnfeymjcR Fguw== MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr14523840obb.25.1332179533149; Mon, 19 Mar 2012 10:52:13 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 19 Mar 2012 10:52:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 13:52:13 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Santesson , pkix Subject: Re: [pkix] PROPOSAL: SCVP to HISTORIC X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 19 Mar 2012 17:52:15 -0000 I have no problem with the activity of any CA that is no longer in the root trust store. If it was a current CA I would want to know if they knew the difference between a cert they never issued and one that they did so that I can interdependently audit their acitivities. On Mon, Mar 19, 2012 at 7:59 AM, Miller, Timothy J. wro= te: > On Mar 16, 2012, at 11:59 AM, Stefan Santesson wrote: > >> Basically, if users of OCSP need to extend the functionality of OCSP in = a >> way where some functionally may come to overlap with functionality >> provided by SCVP, then should we allow that overlap or force those with >> such need to implement SCVP? > > Then again, any OCSP service can implement virtually any processing chang= e without modification of the protocol or the clients. =A0E.g., if an OCSP = service has access to the CA history and the queried cert isn't present at = all, "UNKNOWN" and "REVOKED" are valid answers. =A0Why does the client need= a new return code (e.g., =A0"NEVERISSUED") in this case? > > Case in point: =A0DigiNotar runs their terminal OCSP service this way und= er the current standard. =A0Did anyone have a problem with that? > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From mmyers@fastq.com Mon Mar 19 10:53:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9721F889A for ; Mon, 19 Mar 2012 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LLnAXj4JqN9 for ; Mon, 19 Mar 2012 10:53:05 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15021F88BC for ; Mon, 19 Mar 2012 10:53:05 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2JHqseb019043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 10:52:55 -0700 Message-Id: From: Michael Myers To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Mar 2012 10:58:23 -0700 References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> X-Mailer: Apple Mail (2.936) Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:53:06 -0000 On Mar 19, 2012, at 10:43 AM, Phillip Hallam-Baker wrote: > In this case a NOTISSUED response for an actual cert would sound alarm > bells at the meta-level and an industry level response. Who did NOT issue the cert? From hallam@gmail.com Mon Mar 19 10:57:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0021F87D0 for ; Mon, 19 Mar 2012 10:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1QCdtk+1hbm for ; Mon, 19 Mar 2012 10:57:46 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8786221F87BE for ; Mon, 19 Mar 2012 10:57:46 -0700 (PDT) Received: by ggmi1 with SMTP id i1so6471329ggm.31 for ; Mon, 19 Mar 2012 10:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gSPWK9XGURSdqBrpKV2uU7yZERrn/m2WeAy8Qv1dAf8=; b=TtHK7gDgZZFUejrBfUXUIIO+gYyPjjxR/5culOLgC0z34uTYjs+EJju6kv5niJudDz 085pgdfiY7rIlkmlscz+L62CztYEWvUrG3foKNXNqnjbBfDUOrGMdt1cKJuinOrZ4S0G jww4eeL5AAKQcevwo8lmzjj1Alr6495+fPu3Kdm0bWsqNbHK6wKlKyuVUz4ZBatZ+q+8 XU+iHRdarwvox2F58E2ClOT74TCYEWy7tYWji178Erdka4SMrFo1qNf6CpVnDBFmEoUB u9ocphpniCR66+BzzWOx5Rt2jwbJyyG4AhCtER8eNeKhCS6JjRSlKFy3D0eYVdQJob3Z gocA== MIME-Version: 1.0 Received: by 10.60.26.8 with SMTP id h8mr14663212oeg.15.1332179866016; Mon, 19 Mar 2012 10:57:46 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 19 Mar 2012 10:57:45 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> Date: Mon, 19 Mar 2012 13:57:45 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:57:47 -0000 I think that what we need here is to have a standard for revocation where 1) Positive status reports bind to the certificate by means of a digest and not merely the serial number 2) Negative reports distinguish issued but revoked / expired from not issue= d The lack of a cryptographic binding from the OCSP response to the cert is also a defect in the protocol that should be fixed. On Mon, Mar 19, 2012 at 1:51 PM, Kemp, David P. wro= te: > Assuming that a NOTISSUED response is universally implemented, why would = a rational attacker choose to generate a cert that would sound alarm bells = and lead to an industry-level response, as opposed to generating a cert tha= t would pass undetected by piggybacking on a valid cert? > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of P= hillip Hallam-Baker > Sent: Monday, March 19, 2012 1:44 PM > To: Miller, Timothy J. > Cc: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response > > People insist on looking at these interactions on the level of individual= client-server interactions which is a mistake. > > What was most important in the DigiNotar case was not that the cert was r= evoked or not it was that Google had the means to discover certificates tha= t were not consistent with the issue policy for google.com. > > > In this case a NOTISSUED response for an actual cert would sound alarm be= lls at the meta-level and an industry level response. Contrawise responding= to a request for a non-existent cert with any other status would be a caus= e for concern. > > For accountability to work at the CA level, the ability to distinguish th= ese responses is essential. > > On Mon, Mar 19, 2012 at 10:03 AM, Miller, Timothy J. = wrote: >> On Mar 19, 2012, at 8:18 AM, Tom Ritter wrote: >> >>> This discussion has gone round and round several times. =A0If a CA >>> takes the steps to wire their OCSP responder to their cert database >>> so they can make positive assertions about certificates ("Yes, this >>> certificate is known and good." vs "This cert is not in my revoked >>> list.") the response to a query "Is this certificate good?" that is >>> logically "No, that certificate is not good, I don't remember ever >>> issuing it!" must be translated to an OCSP status message that causes >>> a failure on the client. >> >> The effect sought is to cause a the client to reject the certificate. >> Responding REVOKED does that. =A0If you respond NOTISSUED, does the >> client reject the certificate *more* than if you respond REVOKED? =A0:) >> >>> This is really good. =A0But unless I'm really missing something, there >>> is no standard or consensus to do this. >> >> So what? =A0Why should there be? >> >>> >>> Since it's covered by current practice - maybe a technical note of >>> some sort could be circulated referencing this? >> >> I said the last time around (November?) that a Security Note would be ap= propriate but changing the protocol is kinda pointless. >> >>> However, it would still be very nice to tell the client "Things are >>> really, *really* weird! You should perhaps do something" which the >>> client could then alert the user, save diagnostic information, prompt >>> an error-reporting mechanism that's built into several browsers, save >>> to a log, or ignore (perhaps with or without an extension - any FF >>> extension like NoScript, Cert Patrol, etc would be very interested in >>> this info.) >> >> The idea that you'd use NOTISSUED to cause the client to somehow mark th= e CA as untrusted is flawed because it presumes trust in the responder is s= eparate from trust in the issuer, which is neither guaranteed, appropriate,= or even actionable at the client. >> >> If you want to control trust anchors, we have TAMP for that. >> >> -- T >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From brennansecurity@gmail.com Mon Mar 19 11:06:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B83F21F885D for ; Mon, 19 Mar 2012 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvNCUAlGaBCX for ; Mon, 19 Mar 2012 11:06:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2E21F884F for ; Mon, 19 Mar 2012 11:06:43 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so7961782vcb.31 for ; Mon, 19 Mar 2012 11:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=owI8cfIMmEHojsOfUynRCNrR0rO7TslV1kRPGQdiaxs=; b=fakSm2qFOWlT7QvdiRkMFTlGIVDFSObWIwqLvri2w5uk5ppSlYvyj69pa9dBH+5Z53 7veISxX5hT3/YR+qKI0tPJ/JLtSFWYMyUrLJI/IZ3sDShiJ73IPDlfzO4GI7tAwf3GaV 7OHrav2S58b41a+iCPSIkQ18evTrwkWEtBRKIoqethuKbYyRB9SvZzRY9iHjUF7NWKqF UrFXL3ouUTxyn6VOwRFE+jMt7dz5lsY4qg8KGnsJvLmGqjym7nGbgf9XCuO2AzNm7M9p /HjvIbEEaYx/9JZlyMQCKNGkpE7jEJaJ8xnVV56gCZQg1BrvdtfmReDUsCkxYz8QF6Ho 6VCA== MIME-Version: 1.0 Received: by 10.52.180.7 with SMTP id dk7mr5638325vdc.25.1332180403231; Mon, 19 Mar 2012 11:06:43 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Mon, 19 Mar 2012 11:06:42 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> Date: Mon, 19 Mar 2012 14:06:42 -0400 Message-ID: From: brennan security To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:06:46 -0000 David, one of the problems* with validation status currently, is that an attacker with a CA/HSM compromise, may issue a certificate with an identical serial number to an existing certificate. An OCSP response is based on certificate serials and has no link to the actual public key, so a rogue certificate impersonating a good one via a shared serial, would have a good status. This wouldn't generate alarm bells unless some specific tools are being used to perform certificate identification (observatory/convergence/cert patrol/others) Not issued is fundamentally not enough to fix the issue, as PHB and myself have mentioned. There has to be a relationship to the public key. * There are many other issues, some of which are already being addressed. -b On Mon, Mar 19, 2012 at 1:51 PM, Kemp, David P. wro= te: > Assuming that a NOTISSUED response is universally implemented, why would = a rational attacker choose to generate a cert that would sound alarm bells = and lead to an industry-level response, as opposed to generating a cert tha= t would pass undetected by piggybacking on a valid cert? > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of P= hillip Hallam-Baker > Sent: Monday, March 19, 2012 1:44 PM > To: Miller, Timothy J. > Cc: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response > > People insist on looking at these interactions on the level of individual= client-server interactions which is a mistake. > > What was most important in the DigiNotar case was not that the cert was r= evoked or not it was that Google had the means to discover certificates tha= t were not consistent with the issue policy for google.com. > > > In this case a NOTISSUED response for an actual cert would sound alarm be= lls at the meta-level and an industry level response. Contrawise responding= to a request for a non-existent cert with any other status would be a caus= e for concern. > > For accountability to work at the CA level, the ability to distinguish th= ese responses is essential. > > On Mon, Mar 19, 2012 at 10:03 AM, Miller, Timothy J. = wrote: >> On Mar 19, 2012, at 8:18 AM, Tom Ritter wrote: >> >>> This discussion has gone round and round several times. =A0If a CA >>> takes the steps to wire their OCSP responder to their cert database >>> so they can make positive assertions about certificates ("Yes, this >>> certificate is known and good." vs "This cert is not in my revoked >>> list.") the response to a query "Is this certificate good?" that is >>> logically "No, that certificate is not good, I don't remember ever >>> issuing it!" must be translated to an OCSP status message that causes >>> a failure on the client. >> >> The effect sought is to cause a the client to reject the certificate. >> Responding REVOKED does that. =A0If you respond NOTISSUED, does the >> client reject the certificate *more* than if you respond REVOKED? =A0:) >> >>> This is really good. =A0But unless I'm really missing something, there >>> is no standard or consensus to do this. >> >> So what? =A0Why should there be? >> >>> >>> Since it's covered by current practice - maybe a technical note of >>> some sort could be circulated referencing this? >> >> I said the last time around (November?) that a Security Note would be ap= propriate but changing the protocol is kinda pointless. >> >>> However, it would still be very nice to tell the client "Things are >>> really, *really* weird! You should perhaps do something" which the >>> client could then alert the user, save diagnostic information, prompt >>> an error-reporting mechanism that's built into several browsers, save >>> to a log, or ignore (perhaps with or without an extension - any FF >>> extension like NoScript, Cert Patrol, etc would be very interested in >>> this info.) >> >> The idea that you'd use NOTISSUED to cause the client to somehow mark th= e CA as untrusted is flawed because it presumes trust in the responder is s= eparate from trust in the issuer, which is neither guaranteed, appropriate,= or even actionable at the client. >> >> If you want to control trust anchors, we have TAMP for that. >> >> -- T >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > 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 liaquat.khan@ascertia.com Mon Mar 19 11:07:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4D21F888B for ; Mon, 19 Mar 2012 11:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oZEaxTijCpx for ; Mon, 19 Mar 2012 11:07:41 -0700 (PDT) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id 00FD721F8882 for ; Mon, 19 Mar 2012 11:07:40 -0700 (PDT) Received: from [192.168.0.10] ([2.126.123.60]) by ascertia.com with MailEnable ESMTP; Mon, 19 Mar 2012 18:09:02 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 19 Mar 2012 18:06:25 +0000 From: Liaquat Khan To: Stephen Kent Message-ID: Thread-Topic: [pkix] certificate not issued OCSP status response In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:07:43 -0000 It's a valid attack scenario Steve, again assuming attacker has got access to CA's HSM, which is obviously a major problem for CA. Your scenario shows clearly that the OCSP responder cannot protect against this even with "not issued" response. Interestingly this means SCVP is a better protocol for implementing this check since at least it gets the full cert from the client and can really determine if that particular cert was every issued or not. Note this doesn't mean that I am advocating supporting this in SCVP! So I think we are still at square one, what is the attack scenario this feature is trying to prevent or at least detect? From what I can see its only for the detection that a fake certificate was issue by an attacker by accessing the CA's HSM and the attacker chose not to re-use an existing serial number and also chose not to use a compromised OCSP responder cert to respond for that cert, and also chose to delete the cert from the CA's database in case the HSM was accessed through the CA etc. etc. IMO this shows its not really worth changing the protocol for such a very narrow attack scenario. The attacker is not going to be so na=EFve, especially if they have the skills to break into the CA. Regards LK On 19/03/2012 14:21, "Stephen Kent" wrote: >Liaquat, > >Thanks for providing an example of an attack scenario and its >implications re various countermeasures. > >Here's an "easy to imagine" alternative scenario: > > - attacker gains access to HSM and causes a cert to be issued, with the >same serial number as a extant, legitimate cert. > >- no record of cert issuance appears in any CA log. > >- an OCSP response for the cert serial number will not yield >a "revoked" or "not issued" because the legitimate cert in question is >valid and not revoked. > >until the CA is made aware of the bogus cert, it cannot revoke it, >and at that time a CRL or the current OCSP mechanism will work as well >as any proposed enhancements to OCSP. > >Thsi is why a thorough, well-written analysis of the problems to be >solved is needed before we pursue changes of the sort being proposed. > >Steve > > > From kent@bbn.com Mon Mar 19 11:32:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315FC21F88C7 for ; Mon, 19 Mar 2012 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTU+yq+rYV6B for ; Mon, 19 Mar 2012 11:32:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1A21F88A3 for ; Mon, 19 Mar 2012 11:32:52 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49179) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9hNo-000Jnp-MA; Mon, 19 Mar 2012 14:32:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Mar 2012 14:20:33 -0400 To: brennan security From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:32:54 -0000 At 1:01 PM -0400 3/19/12, brennan security wrote: >Steve, > >Your words, "Th[is] is why a thorough, well-written analysis of the >problems to be solved is needed before we pursue changes of the sort >being proposed" is exactly what I was thinking. > >As you suggested, I propose we perform some risk analysis on PKI as >it relates to OCSP: >Assets: CAs, Validation infrastructure, operating system & >application trust stores, transactions, HSMs, etc. >Asset vulnerabilities & weaknesses: intrinsic gaps in asset >functionality or implementations >Threats: exploitations of vulnerabilities and weaknesses >current attack/threat scenarios: , both historical and potential >(comodo, digitotar/PKIoverheid, RapidSSL, Globalsign, others) and >potential remediations for the same. >Countermeasures: protective mechanisms, alterations that address >vulnerabilities & weaknesses. > >Then, to conclude, some data on current implementations in industry >so any proposed solutions best considers industry impacts and >resourcing. > >To that end I volunteer to work on this effort with others, as it >coincides with my present work (high security CA and OCSP >infrastructure) > >Brennan Thanks for volunteering. Steve From kent@bbn.com Mon Mar 19 11:32:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48221F88A3 for ; Mon, 19 Mar 2012 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6VOZHhoO1Xy for ; Mon, 19 Mar 2012 11:32:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C66D421F88AA for ; Mon, 19 Mar 2012 11:32:53 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49179) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9hNq-000Jnp-K6; Mon, 19 Mar 2012 14:32:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Mar 2012 14:26:57 -0400 To: Liaquat Khan From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:32:54 -0000 At 6:06 PM +0000 3/19/12, Liaquat Khan wrote: >It's a valid attack scenario Steve, again assuming attacker has got access >to CA's HSM, which is obviously a major problem for CA. > >Your scenario shows clearly that the OCSP responder cannot protect against >this even with "not issued" response. > >Interestingly this means SCVP is a better protocol for implementing this >check since at least it gets the full cert from the client and can really >determine if that particular cert was every issued or not. Note this >doesn't mean that I am advocating supporting this in SCVP! understood. and, if the primary problem to be addressed is in the public CA space, SCVP is not applicable anyway. >So I think we are still at square one, what is the attack scenario this >feature is trying to prevent or at least detect? I want to know that too :-). I think we need to see what folks generate as a problem statement and then we can debate what is the best way to solve the problem(s). Steve From hallam@gmail.com Mon Mar 19 12:04:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8521F884C for ; Mon, 19 Mar 2012 12:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJYa-Mjt3YrQ for ; Mon, 19 Mar 2012 12:04:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 803A021F87E1 for ; Mon, 19 Mar 2012 12:04:34 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6554802ghb.31 for ; Mon, 19 Mar 2012 12:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qv4g4pduk9VKc9Q9XZfYP1Z3VlF7Bh4kN2a27E1lV24=; b=I/8Ox3zbkl29O8DApYyRFjMZDPUQ4w/Hu6fB5tUw24TqPc8kOh1A9iVRI/FiT6yGdB 8nHHSJhmX4Oh5RUqjilACe5aTHSOMZzBdXclvyihwqf4f1JT693trJshu3OetTdB212I kpYs4I/59eYgvUY0nw3OmsM+Oobk3gn6kbPMHAmBwVeQp9qxOWOqiTpqr25bDfu78fS4 bg2euv6iEI/3u7gp9NilQ0x/hJ1bAXJneEXL4D3gk8UfJglmD7XoRY0oOcwHnzR8HUnJ REnh2RxOPPzv+axt3kDZnl7RHSLJuLVbW5c3FPb7jCgJ+AjCJJPqaeoHKJZTBUH1zsAI KnlA== MIME-Version: 1.0 Received: by 10.60.30.66 with SMTP id q2mr14839499oeh.25.1332183874057; Mon, 19 Mar 2012 12:04:34 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Mon, 19 Mar 2012 12:04:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 15:04:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:04:35 -0000 I have been working on a paper, the real question here is scope. Google proposed some pretty extensive changes to the way the system worked in their Certificate Transparency proposal. Then there is the EFF Observatory and the Perspectives/Convergence approach. I think we will need to look at the name and trust infrastructure together and from the point of view of 'how do we stop bad things happening to the end user' rather than looking at fixing things piecemeal. One reason for that is that most of the new PKI proposals to date have been focused only on replacing DV certs which are the lowest grade cert and not very interesting from a security point of view. The main point of the SSL CA system for me is to introduce accountability controls. When people are talking about the objective being to make sure that DNS names resolve to the owners, this seems to be wrong to me. I do not want users going to sites that are controlled by the criminals regardless of whether they have paid their $6 to ICANN for a domain name or their $whatever to a CA. The notary scheme proposed in CT may or may not have value, but before introducing another party into the system, I would like to do what we can with the existing system. I also note that one of the reasons for the success of SSL is that the server admins had a big incentive to deploy crypto and there was an infrastructure there with call centers etc. to hand hold them through the process. We never had that for S/MIME or for any of the identity proposals. And that hurt in two ways, first it meant that users had to work out how to do crypto by themselves and second there was no constituency saying 'hey we need simpler crypto admin, the cost of call center people is eating our margins'. So the model I am currently looking at is to introduce a client side broker that would be the proxy for all name and certificate queries, capable of fast response via a UDP based protocol or longer responses layered over https. Such a protocol would be a hybrid of SCVP and DNS recursive resolver and would provide the same two basic choices, delegated path discovery or delegated path validation. I would expect it would be a part of an AV type suite and eventually be hooked into the O/S like AV solutions are. Combining both functions in a single service gives the proxy a lot more information to work with and many more tools. So for example, a client attempts to connect to a DNS name that was only registered 8 hours ago is suspicious but could have a legitimate explanation, same for attempting to connect to an IP address in a block allocated to domestic use or even an IP address associated with possible botnet activity. But if all three yellow flags are present they add up to a big red flag and the client really does not want to connect. So the consumer I am envisioning for this information is not the endpoint client, that does not have enough context to make useful decisions. We had the same problem with spam filtering. Put the spam filter on the email client and all it can do is content analysis which is a pretty low quality spam filter. Put the filter on the email server and you can do more because you can apply timing analysis. Put the filter on an email server servicing millions of messages an hour and it is much easier to spot the spammy signal in all the noise. The rule for such a service should be that it can veto name/trust decisions but not create them. So the browser is only going to show the DV (padlock) or EV (green bar) chrome if it sees a certificate that chains to one of the roots it trusts and if it is checking DNSSEC, it is only going to accept RRs consistent with its chosen DNSSEC roots. The proxy should not be able to create certs or DNS names out of thin air but it should be able to block them. I think we need to have a conversation on this but it is going to be a rather longer one than we can manage in Paris, or at an IETF meeting come to that. It is more the sort of thing that we need a two day workshop or the like for. On Mon, Mar 19, 2012 at 2:20 PM, Stephen Kent wrote: > At 1:01 PM -0400 3/19/12, brennan security wrote: >> >> Steve, >> >> Your words, "Th[is] is why a thorough, well-written analysis of the >> problems to be solved is needed before we pursue changes of the sort being >> proposed" is exactly what I was thinking. >> >> As you suggested, I propose we perform some risk analysis on PKI as it >> relates to OCSP: >> Assets: CAs, Validation infrastructure, operating system & application >> trust stores, transactions, HSMs, etc. >> Asset vulnerabilities & weaknesses: intrinsic gaps in asset functionality >> or implementations >> Threats: exploitations of vulnerabilities and weaknesses >> current attack/threat scenarios: , both historical and potential (comodo, >> digitotar/PKIoverheid, RapidSSL, Globalsign, others) and potential >> remediations for the same. >> Countermeasures: protective mechanisms, alterations that address >> vulnerabilities & weaknesses. >> >> Then, to conclude, some data on current implementations in industry so any >> proposed solutions best considers industry impacts and resourcing. >> >> To that end I volunteer to work on this effort with others, as it >> coincides with my present work (high security CA and OCSP infrastructure) >> >> Brennan > > > Thanks for volunteering. > > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From hotz@jpl.nasa.gov Mon Mar 19 13:18:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6544021E802D for ; Mon, 19 Mar 2012 13:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egmqJvrZoqvD for ; Mon, 19 Mar 2012 13:18:12 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id E64D821E800C for ; Mon, 19 Mar 2012 13:18:12 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2JKIAR1011028 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 19 Mar 2012 13:18:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> Date: Mon, 19 Mar 2012 13:18:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> To: "Miller, Timothy J." X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:18:13 -0000 On Mar 19, 2012, at 5:07 AM, Miller, Timothy J. wrote: > On Mar 16, 2012, at 2:38 PM, Henry B. Hotz wrote: >=20 >> Can I turn the question around and ask why adding a 'does not exist' = response would be bad? >=20 > It's a subset of UNKNOWN? To me UNKNOWN means "my knowledge is incomplete (and therefore not = authoritative)" and does not mean "this is clearly bogus". Looking at 2560, it's actually worse because "never issued" is = explicitly a subset of "good" (Section 2.2, paragraph 6). > It's incompatible with the installed base? Well, yes. Less incompatible than switching to SCVP though. >> To answer your question more directly, I think there are scenarios = that could most easily be addressed if such a response could be = provided. =20 >=20 > Examples, please? Suppose the trust models are updated so a CA compromise does not = compromise the OCSP responder. We *still* need a way to tell the = clients that a cert is bogus. In a lot of ways I think I prefer your suggestion that we redefine the = existing codes to require the responders to provide the needed = information. It should be less incompatible than creating a new = extension, I hope. ------------------------------------------------------ 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 hotz@jpl.nasa.gov Mon Mar 19 13:25:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8521F8812 for ; Mon, 19 Mar 2012 13:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkdIpXjCeZ6H for ; Mon, 19 Mar 2012 13:25:27 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id D5D7E21F87E1 for ; Mon, 19 Mar 2012 13:25:27 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2JKPMng014019 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 19 Mar 2012 13:25:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 19 Mar 2012 13:25:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 20:25:28 -0000 On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: > At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >> Suppose we accept both your arguments below, and Stephen Kent's = arguments that SCVP is the right solution for the real problem faced by = ordinary users. >=20 > Steve Kent didn't say that. OK, OK. I admit I'm stretching a point to try to find common ground. I'm kind of disappointed by how acrimonious the discussions of this = feature (and on this list in general) have been. I'm guessing that is = why we haven't heard from Tom Gundin, the guy who started this thread, = in a while. > He said that PKIX decided to develop SCVP instead of extending OCSP, = when we lasted visited this sort of topic. In later messages I noted = that folks did not except public CAs to operate SCVP servers; SCVP is = best suited for enterprise environments. >=20 > Steve ------------------------------------------------------ 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 hallam@gmail.com Mon Mar 19 13:35:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD64921E8017 for ; Mon, 19 Mar 2012 13:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk+HLSW12YZx for ; Mon, 19 Mar 2012 13:35:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2E21F86A1 for ; Mon, 19 Mar 2012 13:35:01 -0700 (PDT) Received: by ggmi1 with SMTP id i1so6643769ggm.31 for ; Mon, 19 Mar 2012 13:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tfDOvtDPvJPUgTaDdItzI3HndbDM3MYSfCKAVMFvZBg=; b=HOHft2TAfyG6QYaWVPR3uHVc8486zxOzWe7oSPRHzps4kuRL5arHpAuuk8324ctiK7 gXcnaZtbHu80DfBxAW4ZuCDFUL4Mq2kINsfIzW4DNGF3DQiOn6gqsLbLlO25eCEGjcpr 3hsh+fmRC/9vBwrX9DgQ1YKfteRRrRP0ZpOJqeYwCeQI2XJlj3i0sqA9CZczzlJ0QfYG LyLF5hFiA4lGtUI9BaCtwFgGc7115+Y/eSM7Ak4HlXAuC1B81SfxwUgkjO+kf7yDUgfF J7BYox4XU8kwCEeIoEFMtxVipD4iOhzsgNwQA+/GC3sKSzetbnJgOJ9X4Ef79rlml/QS kbqQ== MIME-Version: 1.0 Received: by 10.236.152.73 with SMTP id c49mr4311531yhk.91.1332189300595; Mon, 19 Mar 2012 13:35:00 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Mon, 19 Mar 2012 13:35:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 16:35:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 20:35:02 -0000 There are two separate questions, first which protocol to change, second how to implement the change. I look at protocols as being carriers for information interchanges between sets of parties rather than being conduits for a specific type of information. So if we have a protocol that is being used for communications between client application set X and the set of service parties Y, I think it should be capable of covering all such communications. Now one outcome from this particular discussion is that for the first time we appear to have arrived at a distinction between OCSP and SCVP in terms of the services that they involve and thus an actual reason for having two separate protocols. Namely a given client application is going to make use of one SCVP service for all certificates but checking revocation status means a logical connection to multiple OCSP services (one per CA). The only exception to that rule would be if a client used a local OCSP service as a proxy fanning out queries to the various backend services in which case OCSP starts to look very much like SCVP. SCVP is intrinsically a protocol for delegating PKI related work and to perform its function needs to have a superset of OCSP capabilities. It is a different protocol from OCSP and the consumer is always a client that has a specific trust relationship with the specific service. The only connection between the two is that an SCVP service is going to need to make OCSP lookups to perform its function. There is no way for the SCVP service to return NOT-ISSUED unless the authoritative service can return NOT-ISSUED. So: OCSP is a protocol for publishing authoritative information SCVP is a protocol for delegating PKI processing tasks NOT-ISSUED is a new type of authoritative information and so extending OCSP is appropriate. On the question of how to implement, OCSP or CRL whitelists (CWLs?), I think the answer probably needs to be 'both'. There are so many parts of PKI processing that assume interchangeability, it might not be a good idea to do one without the other anyway. And expressing positive trust rather than negative trust is of course going to mean that we can't rely on the certificate serial number alone as identification in either case. We are going to need a digest or the like. So my current proposals are: To support issuer transparency (aka not-issued) 1a) Extension into OCSP for NOT-ISSUED using serial # ranges 1b) Extension into OCSP to specify certificate by digest 1c) Extension to CRLs to specify 'this is a complete whitelist for serial range X thru Y' and cert by digest Together with a requirement to return NOT-ISSUED for non existent certs rather than REVOKED or UNKNOWN, these extensions permit an external party to determine if a CA is in compliance (by making queries for random serials, hashes and checking response) or has lost control of their HSM (returns NOT-ISSUED for an observed cert). Separately I have proposals for: 2) Publish security policy 'SSL always offered' (via DNS, HTTP) 3) Publish security policy 'OCSP always stapled' (via the cert) 4) Combine all the client side flows of type 'client to trusted service' into efficient calls to a single broker, this would subsume DNS, SCVP and Kerberos into one simple UDP call. On Mon, Mar 19, 2012 at 12:03 PM, Stephen Kent wrote: > > At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote: > > On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent wrote: >> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >> >> Does anyone use SCVP? >> >> >> I'll let others, who know better than I, respond to this question. >> >> If there is going to be a choice between maintaining OCSP and >> maintaining SCVP then OCSP is going to be the one that I choose. >> >> >> If the proposal is to keep the name OCSP and add a lot of functionality >> that overlaps SCVP, that is not a reasonable course of action. > > OCSP is the Online Certificate Status Protocol. This is Certificate > Status. So if we accept your argument that there is overlap with SCVP, > the fault is with SCVP. > > > Not true. OCSP is a sloppy shorthand name or a protocol that reports the > revocation status of a cert, as noted in RFC 2560: > > 2.=A0 Protocol Overview > =A0=A0 In lieu of or as a supplement to checking against a periodic CRL, = it > =A0=A0 may be necessary to obtain timely information regarding the > =A0=A0 revocation status of a certificate (cf. [RFC2459], Section 3.3). > > This is a minor incremental development of the protocol to address a > functionality that was originally intended. > > >> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an >> alternative (to CRLs) for checking the revocation status of a cert. If w= e >> have good reasons >> to improve on that function, then doing so using OCSP makes sense. > > You suggested that the existence of SCVP means we cannot add new > features to OCSP. > > > I suggested that if a new OCSP feature is already present in SCVP, then > we ought not add that feature to OCSP. That statement should be interpret= ed > by the context in which each protocol is intended to operate. So, if the > (not well articulated) problem space being addressed is public CAs, vs. > enterprise CAs, then SCVP is not an appropriate alternative. > > I said that I don't accept that as virtually nobody uses SCVP. So if > you want to push that idea I think it is time to move SCVP to HISTORIC > > and slim down the stack a little. > > > I'll interpret this statement as a rhetorical gimmick on your part, as it > does not merit being treated as a serious proposal. > > ... > > > The functionality is certificate status and SCVP is totally > irrelevant. SCVP does not address this subject area and no public CA > > uses it. > > > I agree that SCVP is not an appropriate protocol for public CA cert statu= s > checking. But, since you've not provided a good description of the proble= m > that you want to solve with a change to OCSP, you didn't rule out SCVP. > Subsequent list traffic shows that some folks are interpreting your propo= sal > in an enterprise context, which is where there is a direct conflict with = an > extant PKIX standard. > > OCSP has an extension mechanism. It should have been used to implement > > SCVP in the first place. > > > You are entitled to that belief, but the WG did not agree. We went throug= h > a long, fair process to decide how to proceed, and SCVP was the winner.= =A0 The > fact that your pick didn't win then is not a basis for trying to reclassi= fy > SCVP as historic. > > In subsequent messages directed to other folks you said that a goal is ".= .. > enable a re-engineering of CA architecture so that we eliminate 'single > break' systems."=A0 That's a noble goal, but if it is also a big topic, n= ot > one that we address with a change to OCSP. Agsin, we lack an adequate > description of the problem to be solved. > > > > Steve --=20 Website: http://hallambaker.com/ From mmyers@fastq.com Mon Mar 19 14:14:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C8821F8645 for ; Mon, 19 Mar 2012 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHfXa1v7Eeil for ; Mon, 19 Mar 2012 14:14:54 -0700 (PDT) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF421F8630 for ; Mon, 19 Mar 2012 14:14:53 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2JLEnNf023578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 14:14:50 -0700 Message-Id: <4F4BE96C-933C-4A90-A9C3-84651E3FAFE7@fastq.com> From: Michael Myers To: "Henry B. Hotz" In-Reply-To: <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Mar 2012 14:20:19 -0700 References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> X-Mailer: Apple Mail (2.936) Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:14:55 -0000 On Mar 19, 2012, at 1:18 PM, Henry B. Hotz wrote: > To me UNKNOWN means "my knowledge is incomplete (and therefore not > authoritative)" and does not mean "this is clearly bogus". It was intended that the responder's knowledge is complete with respect to its scope of authority. From brennansecurity@gmail.com Mon Mar 19 14:29:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB021E8034 for ; Mon, 19 Mar 2012 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VxlYjCM49Yr for ; Mon, 19 Mar 2012 14:29:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7C21E801C for ; Mon, 19 Mar 2012 14:29:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so932761vbb.31 for ; Mon, 19 Mar 2012 14:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eU0AaEWOFF00CunPRFW4EvEIFlCfDhSAXnFEAP7TZHM=; b=jYvsIVUl99iyPEQzddLELA0sKdWXHQddxUvC6tJ10heuax47rMh20ZTogcYAme3BOc oNqpRrVUCUJxR2DTKhJYpB77HUZZprt48pNglCLhOWzb9dWEVAljYJDW2vgn9eGVO8Gm Sf2H73oObpnbKBBigzwLjkoe/v/6WoWu8aNnggBSfI0vzCnylSxGY1Z77JDA9bttMSGm vyLVYX5gL9ATscKM86c84KQfh5fVfk/83S10k7hp7KFbj8KOEr+GxTJLgEhsXgEx4Uc4 li1WGznTzqUPeq0uN717b2LUuRU4CjnhQ92mby+qhlgt9rTt38Ddo/2ys5AJvwxjzt0b Ztcg== MIME-Version: 1.0 Received: by 10.220.141.139 with SMTP id m11mr5435281vcu.56.1332192569048; Mon, 19 Mar 2012 14:29:29 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Mon, 19 Mar 2012 14:29:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 17:29:28 -0400 Message-ID: From: brennan security To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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: Mon, 19 Mar 2012 21:29:30 -0000 PHB, Rereading SCVP, while keeping in mind Steve Kent's discussion of applicability of enterprise vs public validation response capabilities and your previous comments on the relative impacts of a "not issued" vice "unknown", I see SCVP as just as vulnerable. SCVP appears to be slightly more resilient to a "CA/hsm compromise and certificates with duplicate serial production" (RFC 5055 4.9.1 & 4.9.2), but it seems just as vulnerable to "CA/HSM compromise and novel certs". If anyone can point out in the RFC how this is wrong, I'm all ears. However, due to the inapplicability of SCVP to public implementations, I don't see it as a viable solution, instead, I see interdependence. Consequently, I second your current proposals of 1a, 1b, 1c. Furthermore, I propose: 1d: Extension to SCVP to cover 1a, 1b & 1c (RFC 5055) - any updates to OCSP should likewise benefit SCVP. -b On Mon, Mar 19, 2012 at 4:35 PM, Phillip Hallam-Baker wr= ote: > There are two separate questions, first which protocol to change, > second how to implement the change. > > > I look at protocols as being carriers for information interchanges > between sets of parties rather than being conduits for a specific type > of information. So if we have a protocol that is being used for > communications between client application set X and the set of service > parties Y, I think it should be capable of covering all such > communications. > > Now one outcome from this particular discussion is that for the first > time we appear to have arrived at a distinction between OCSP and SCVP > in terms of the services that they involve and thus an actual reason > for having two separate protocols. > > Namely a given client application is going to make use of one SCVP > service for all certificates but checking revocation status means a > logical connection to multiple OCSP services (one per CA). > > The only exception to that rule would be if a client used a local OCSP > service as a proxy fanning out queries to the various backend services > in which case OCSP starts to look very much like SCVP. > > SCVP is intrinsically a protocol for delegating PKI related work and > to perform its function needs to have a superset of OCSP capabilities. > It is a different protocol from OCSP and the consumer is always a > client that has a specific trust relationship with the specific > service. > > The only connection between the two is that an SCVP service is going > to need to make OCSP lookups to perform its function. There is no way > for the SCVP service to return NOT-ISSUED unless the authoritative > service can return NOT-ISSUED. > > > So: > > OCSP is a protocol for publishing authoritative information > SCVP is a protocol for delegating PKI processing tasks > > > NOT-ISSUED is a new type of authoritative information and so extending > OCSP is appropriate. > > > On the question of how to implement, OCSP or CRL whitelists (CWLs?), I > think the answer probably needs to be 'both'. There are so many parts > of PKI processing that assume interchangeability, it might not be a > good idea to do one without the other anyway. > > And expressing positive trust rather than negative trust is of course > going to mean that we can't rely on the certificate serial number > alone as identification in either case. We are going to need a digest > or the like. > > > So my current proposals are: > > To support issuer transparency (aka not-issued) > 1a) Extension into OCSP for NOT-ISSUED using serial # ranges > 1b) Extension into OCSP to specify certificate by digest > 1c) Extension to CRLs to specify 'this is a complete whitelist for > serial range X thru Y' and cert by digest > > Together with a requirement to return NOT-ISSUED for non existent > certs rather than REVOKED or UNKNOWN, these extensions permit an > external party to determine if a CA is in compliance (by making > queries for random serials, hashes and checking response) or has lost > control of their HSM (returns NOT-ISSUED for an observed cert). > > > Separately I have proposals for: > > 2) Publish security policy 'SSL always offered' (via DNS, HTTP) > 3) Publish security policy 'OCSP always stapled' (via the cert) > 4) Combine all the client side flows of type 'client to trusted > service' into efficient calls to a single broker, this would subsume > DNS, SCVP and Kerberos into one simple UDP call. > > On Mon, Mar 19, 2012 at 12:03 PM, Stephen Kent wrote: >> >> At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote: >> >> On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent wrote: >>> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote: >>> >>> Does anyone use SCVP? >>> >>> >>> I'll let others, who know better than I, respond to this question. >>> >>> If there is going to be a choice between maintaining OCSP and >>> maintaining SCVP then OCSP is going to be the one that I choose. >>> >>> >>> If the proposal is to keep the name OCSP and add a lot of functionality >>> that overlaps SCVP, that is not a reasonable course of action. >> >> OCSP is the Online Certificate Status Protocol. This is Certificate >> Status. So if we accept your argument that there is overlap with SCVP, >> the fault is with SCVP. >> >> >> Not true. OCSP is a sloppy shorthand name or a protocol that reports the >> revocation status of a cert, as noted in RFC 2560: >> >> 2.=A0 Protocol Overview >> =A0=A0 In lieu of or as a supplement to checking against a periodic CRL,= it >> =A0=A0 may be necessary to obtain timely information regarding the >> =A0=A0 revocation status of a certificate (cf. [RFC2459], Section 3.3). >> >> This is a minor incremental development of the protocol to address a >> functionality that was originally intended. >> >> >>> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an >>> alternative (to CRLs) for checking the revocation status of a cert. If = we >>> have good reasons >>> to improve on that function, then doing so using OCSP makes sense. >> >> You suggested that the existence of SCVP means we cannot add new >> features to OCSP. >> >> >> I suggested that if a new OCSP feature is already present in SCVP, then >> we ought not add that feature to OCSP. That statement should be interpre= ted >> by the context in which each protocol is intended to operate. So, if the >> (not well articulated) problem space being addressed is public CAs, vs. >> enterprise CAs, then SCVP is not an appropriate alternative. >> >> I said that I don't accept that as virtually nobody uses SCVP. So if >> you want to push that idea I think it is time to move SCVP to HISTORIC >> >> and slim down the stack a little. >> >> >> I'll interpret this statement as a rhetorical gimmick on your part, as i= t >> does not merit being treated as a serious proposal. >> >> ... >> >> >> The functionality is certificate status and SCVP is totally >> irrelevant. SCVP does not address this subject area and no public CA >> >> uses it. >> >> >> I agree that SCVP is not an appropriate protocol for public CA cert stat= us >> checking. But, since you've not provided a good description of the probl= em >> that you want to solve with a change to OCSP, you didn't rule out SCVP. >> Subsequent list traffic shows that some folks are interpreting your prop= osal >> in an enterprise context, which is where there is a direct conflict with= an >> extant PKIX standard. >> >> OCSP has an extension mechanism. It should have been used to implement >> >> SCVP in the first place. >> >> >> You are entitled to that belief, but the WG did not agree. We went throu= gh >> a long, fair process to decide how to proceed, and SCVP was the winner.= =A0 The >> fact that your pick didn't win then is not a basis for trying to reclass= ify >> SCVP as historic. >> >> In subsequent messages directed to other folks you said that a goal is "= ... >> enable a re-engineering of CA architecture so that we eliminate 'single >> break' systems."=A0 That's a noble goal, but if it is also a big topic, = not >> one that we address with a change to OCSP. Agsin, we lack an adequate >> description of the problem to be solved. >> >> >> >> Steve > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Mar 19 16:15:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49E721F8811 for ; Mon, 19 Mar 2012 16:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.76 X-Spam-Level: X-Spam-Status: No, score=-9.76 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt47jnjfCDdR for ; Mon, 19 Mar 2012 16:15:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0211E21F8691 for ; Mon, 19 Mar 2012 16:15:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2JNFcG4019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 00:15:38 +0100 (MET) From: Martin Rex Message-Id: <201203192315.q2JNFbh5003644@fs4113.wdf.sap.corp> To: tmiller@mitre.org (Miller Timothy J.) Date: Tue, 20 Mar 2012 00:15:37 +0100 (MET) In-Reply-To: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> from "Miller, Timothy J." at Mar 19, 12 02:03:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 23:15:40 -0000 Miller, Timothy J. wrote: > > The effect sought is to cause a the client to reject the certificate. > Responding REVOKED does that. If you respond NOTISSUED, does the > client reject the certificate *more* than if you respond REVOKED? :) Maybe you want the client to reject it "less" than if you respond REVOKED, because it might cause newly issued certs to be rejected for a few days if those responses are cached. The value I see in white-listing of certs (and OCSP responses reflecting this) is not about throughly compromise CAs, but for disaster recovery and damage control for the CA. As I previously complained, X.509 was invented with no apparent plan for disaster recovery. If there is any suspicion, the only solution is to immediately and completely nuke the entire PKI, and re-personalize every PKI credential holder, and not perform any operations based on the old PKI. While one should really move to a new PKI after a verified thorough compromise, that strategy is much less sensible for "suspicious activity". One of the functions of disaster recovery is the ability to perform an audit, and then continue operation based on the audited information. That is only possible if you have a data base (and issuing log) that can be audited, and which is used for checking certs. What if you do find malware on one of the machines that the CA software runs on? What if it is "just" a remote-root vulnerability that is found and patch (like that one on March patch-tuesday?). That you did not hear the alarm bells ring, does not mean that there was no break-in. Worst-case scenario is that you loose your HSM hardware through some hardware defect or natural disaster. How do you know it was purely accidental, and not a security-breach trying to cover tracks? Being able to audit a database&log of issued certs, that may have been partially restored from backup as part of a disaster recovery procedure, and offering validation against that audited database, seems like a good idea and sensible risk management. You probably do not want to nuke a 1+ Mio PKI purely on the possibility of a breach. With the possibility of cert whitelisting (and OCSP responses reflecting that) you may not only ensure that you do not miss the well-funded attacker that can exploit vulnerabilities without leaving easily visible traces through one of the still undiscloses ubiquituous remote-root vulnerabilities in every COTS software, or can make your HSM die. And you may use the same facility to audit high-value transactions performed during a time when the CA had to perform a desaster recovery for whatever reason. -Martin From mrex@sap.com Mon Mar 19 16:28:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C321F8777 for ; Mon, 19 Mar 2012 16:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhQZtjhaj7yM for ; Mon, 19 Mar 2012 16:28:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 897A321F8776 for ; Mon, 19 Mar 2012 16:28:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2JNSU85021330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 00:28:35 +0100 (MET) From: Martin Rex Message-Id: <201203192328.q2JNSUtM004133@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Tue, 20 Mar 2012 00:28:30 +0100 (MET) In-Reply-To: from "Kemp, David P." at Mar 19, 12 01:07:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 23:28:37 -0000 Kemp, David P. wrote: > > In Steve's example, the attacker-generated cert (for which there is no > record) has the same serial number as a legitimately-issued cert. The > CA's database shows the serial number as existing and not revoked, and > nothing has come to the CA's attention to indicate that two certs with > the same serial number have been signed. Whitelisting of certficates should probably use a cryptographically strong means of authenticating the certificate for which the status is requested/inquired, like a certificate hash. And presence of a certificate hash in the OCSP request could be used to determine whether the client will understand a "not_issued" rather than an unknown or revoked(-for-safety) response. -Martin From paul.hoffman@vpnc.org Mon Mar 19 17:47:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53C21F88EA for ; Mon, 19 Mar 2012 17:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERhMg6UNhWoa for ; Mon, 19 Mar 2012 17:47:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10221F88E9 for ; Mon, 19 Mar 2012 17:47:47 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2K0lkoT085669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Mar 2012 17:47:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Mon, 19 Mar 2012 17:47:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> References: To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 00:47:48 -0000 On Mar 19, 2012, at 9:58 AM, Stephen Kent wrote: > In your latest rev there is added text that addresses one of the = issues that arose in DANE re self-signed EE cert use in the TLS context. = I find that text confusing. I suggest the following text, which focuses = on a different aspect > of SS-EE cert use. We need to ask the Security ADs if they feel the = following text, or some combination of it and what you already wrote, = addresses the > DANE issues. >=20 > Section 3.2: insert this new paragraph after the (current) last = paragraph > The PKI model defined in X.509 requires that an entity that signs a = (public key) certificate be a CA. The notion of a self-signed end entity = certificate deviates from the X.59 model. A self-signed, end entity = certificate generally is not compatible with the certificate path = validation mechanism described in Section 6. However, as noted in = Sections 6.1 and 6.1.1, a self-signed certificate may be used convey a = trust anchor. In practice, if this trust anchor certificate fails to = include the BasicConstraints extension, which is used to mark a = certificate as a CA certificate, this does not adversely affect = certificate path processing. Thus the preceding text discussing = certificate types should be interpreted as follows: A self-signed = certificate used exclusively to convey trust anchor data need not be = marked as a CA certificate, although such marking is RECOMMENDED. All = other self-signed certificates MUST be marked as CA certificates. I prefer the paragraph currently in the document. The first two sentence = above are an unattributed assertion, one that others have disagreed = with. I do not think that putting them into a standards-track update = document is warranted unless they are the consensus of both this WG and = of the maintainers of X.509. Given the unlikelihood of that, the current = text is better. Further, the last two sentences above go against current = practice, and they replace sentences in the current draft that seem more = in line with current practice. > Sean Turner also suggested that we make an explicit reference to RFC = 5937, when we discuss path processing. So, I suggest the following text = change for 6.1.1: >=20 > Add the following text in 6.1.1, at the end of the section. >=20 > OLD: > Conforming implementations are not required to support the setting of = all of these inputs. For example, a conforming implementation may be = designed to validate all certification paths using a value of FALSE for = initial-any-policy-inhibit. >=20 > NEW: > Conforming implementations are not required to support the setting of = all of these inputs. For example, a conforming implementation may be = designed to validate all certification paths using a value of FALSE for = initial-any-policy-inhibit. > Implementers are encouraged to make use of the capabilities defined in = RFC 5937, which describes how to make use of trust anchor constraints = during path processing, including certificate policies, name = constraints, and path length. That seems fine, and the appropriate level of emphasis given that RFC = 5937 is informational, not standards track. > Finally, based on the discussions in SIDR and the docs that have been = issued as RFCs, I suggest the following changes to text in the Secruity = Considerations section: >=20 > Replace the following text with the new text below, in the security = considerations section (Section 8) > =20 > OLD: > While X.509 mandates that names be unambiguous, there is a risk that = two unrelated authorities will issue certificates and/or CRLs under the = same issuer name. As a means of reducing problems and security issues = related to issuer name collisions, CA and CRL issuer names SHOULD be = formed in a way that reduces the likelihood of name collisions. = Implementers should take into account the possible existence of multiple = unrelated CAs and CRL issuers with the same name. At a minimum, = implementations validating CRLs MUST ensure that the certification path = of a certificate and the CRL issuer certification path used to validate = the certificate terminate at the same trust anchor. >=20 >=20 > NEW: > While X.509 mandates that names be unambiguous, there is a risk that = two unrelated authorities will issue certificates and/or CRLs under the = same issuer name. This could occur accidentally or it might be part of = an attack. In the latter case, a CA might issue certificates to CAs, = inserting subject names that intentionally conflict with subject names = in other, legitimate certificates. A CA behaving in this fashion might = also assign certificate serial numbers to collide with entities being = targeted in the attack. >=20 > To address the possibility of accidental name collisions, CA and CRL = issuer names SHOULD be formed in a way that reduces the likelihood of = name collisions. Examples of such techniques appear in Section 8 of [RFC = 6487]. To address both accidental and malicious scenarios, implementers = should take into account the possible existence of multiple unrelated = CAs and CRL issuers with the same name (and possibly the same serial = number). At a minimum, implementations validating CRLs MUST ensure that = the certification path of a certificate and the CRL issuer certification = path used to validate the certificate terminate at the same trust = anchor. Good addition, yes. --Paul Hoffman From paul.hoffman@vpnc.org Mon Mar 19 17:54:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06321F8664 for ; Mon, 19 Mar 2012 17:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haXiKI1Cd3Mu for ; Mon, 19 Mar 2012 17:54:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 967EA21F862B for ; Mon, 19 Mar 2012 17:54:50 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2K0sn9x085962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Mar 2012 17:54:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Mon, 19 Mar 2012 17:54:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7777A290-2928-44CE-9722-FBA9BE6FA773@vpnc.org> References: To: PKIX X-Mailer: Apple Mail (2.1257) Subject: [pkix] Where to discuss fixing the PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:54:51 -0000 On Mar 19, 2012, at 12:04 PM, Phillip Hallam-Baker wrote: > I have been working on a paper, the real question here is scope. >=20 > Google proposed some pretty extensive changes to the way the system > worked in their Certificate Transparency proposal. Then there is the > EFF Observatory and the Perspectives/Convergence approach. >=20 > I think we will need to look at the name and trust infrastructure > together and from the point of view of 'how do we stop bad things > happening to the end user' rather than looking at fixing things > piecemeal. This feels like the discussion on the "therightkey" mailing list stopped = and, after a few weeks, came over to the PKIX WG. Is that intentional? If the purpose of moving it over to PKIX is to get a discussion slot in = Paris because there is no therightkey BoF, that's fine, but some = coordination with the ADs is in order. Hallway conversation about the = topics will happen regardless, of course. --Paul Hoffman From piyush@identicate.com Mon Mar 19 17:57:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A263221F8690 for ; Mon, 19 Mar 2012 17:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_HEADER_CTYPE_ONLY=0.56] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY4JLA1KkdeO for ; Mon, 19 Mar 2012 17:57:51 -0700 (PDT) Received: from col0-omc3-s15.col0.hotmail.com (col0-omc3-s15.col0.hotmail.com [65.55.34.153]) by ietfa.amsl.com (Postfix) with ESMTP id B040221F8684 for ; Mon, 19 Mar 2012 17:57:51 -0700 (PDT) Received: from COL119-W27 ([65.55.34.137]) by col0-omc3-s15.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 17:57:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9d59ec7f-dc09-4929-8c35-9af1cbb37091_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Mon, 19 Mar 2012 17:57:50 -0700 Importance: Normal In-Reply-To: <201203192315.q2JNFbh5003644@fs4113.wdf.sap.corp> References: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> from "Miller, X-OriginalArrivalTime: 20 Mar 2012 00:57:51.0774 (UTC) FILETIME=[79F46BE0:01CD0634] Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:57:52 -0000 Timothy J." at Mar 19, 12 02:03:44 pm,<201203192315.q2JNFbh5003644@fs4113.wdf.sap.corp> MIME-Version: 1.0 --_9d59ec7f-dc09-4929-8c35-9af1cbb37091_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: mrex@sap.com > To: tmiller@mitre.org > Date: Tue=2C 20 Mar 2012 00:15:37 +0100 > CC: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response >=20 > Miller=2C Timothy J. wrote: > >=20 > > The effect sought is to cause a the client to reject the certificate. > > Responding REVOKED does that. If you respond NOTISSUED=2C does the > > client reject the certificate *more* than if you respond REVOKED? :) >=20 > Maybe you want the client to reject it "less" than if you respond REVOKED= =2C > because it might cause newly issued certs to be rejected for a few days > if those responses are cached. >=20 >=20 > The value I see in white-listing of certs (and OCSP responses reflecting = this) > is not about throughly compromise CAs=2C but for disaster recovery and da= mage > control for the CA. As I previously complained=2C X.509 was invented wit= h > no apparent plan for disaster recovery. If there is any suspicion=2C > the only solution is to immediately and completely nuke the entire PKI=2C > and re-personalize every PKI credential holder=2C and not perform any > operations based on the old PKI. I think the right solution is to confirm the suspicion=2C and if CA comprom= ise is confirmed=2C nuke the whole PKI.=20 >=20 > While one should really move to a new PKI after a verified thorough > compromise=2C that strategy is much less sensible for "suspicious activit= y". >=20 > One of the functions of disaster recovery is the ability to perform an > audit=2C and then continue operation based on the audited information. > That is only possible if you have a data base (and issuing log) that > can be audited=2C and which is used for checking certs. > agreed. >=20 > What if you do find malware on one of the machines that the CA software > runs on? What if it is "just" a remote-root vulnerability that is found > and patch (like that one on March patch-tuesday?). That you did not hear > the alarm bells ring=2C does not mean that there was no break-in. > Confirm if the CA was compromised. Evaluate the risk and decide to contin= ue with the same key or to mark it as compromised. > Worst-case scenario is that you loose your HSM hardware through some > hardware defect or natural disaster. How do you know it was purely > accidental=2C and not a security-breach trying to cover tracks? Confirm if the CA was compromised. Evaluate the risk and decide to continue= with the same key (if you have a bakup) or to mark it as compromised.>=20 > Being able to audit a database&log of issued certs=2C that may have been > partially restored from backup as part of a disaster recovery procedure= =2C > and offering validation against that audited database=2C seems like a > good idea and sensible risk management. And it can be done even today. Issue a revoked/suspended response for any s= erial number that is not part of the audited database. >=20 > You probably do not want to nuke a 1+ Mio PKI purely on the possibility > of a breach. With the possibility of cert whitelisting (and OCSP respons= es > reflecting that) you may not only ensure that you do not miss the > well-funded attacker that can exploit vulnerabilities without leaving > easily visible traces through one of the still undiscloses ubiquituous > remote-root vulnerabilities in every COTS software=2C or can make your HS= M die. Only two scenarios are possible here. Either the CA key was compromised or = it was not. If the key was not compromised=2C whitelists and 'not-issued' s= tatus do not serve any purpose. If the key was compromised=2C you cannot be= sure of what CA says in the future. Attacker could've backed up the CA key= =2C issued a responder key=2C issued a whitlist signing key=2C issued white= lists valid for next 20 years=2C messed with the audit log=2C messed with = the CA database. Not sure if there is a way to recover from such a scenario= .=20 A CA can very well make a conscious decision to continue operating using th= e compromised key=2C after assessing that the cost of replacing the whole P= KI is fare more than the damage caused by a few (or quite a few) fraudulent= certificates that were issued using the compromised key. However=2C this i= s a business cost that should be absorbed by the CA as opposed to making ev= ery relying party pay for it in form of upgrade costs=2C bloated requests a= nd responses=2C higher bandwidths=2C storage and computational costs for fe= tching=2C storing and processing white lists. >=20 > And you may use the same facility to audit high-value transactions > performed during a time when the CA had to perform a desaster recovery > for whatever reason. =20 >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_9d59ec7f-dc09-4929-8c35-9af1cbb37091_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: mrex@sap.co= m
>=3B To: tmiller@mitre.org
>=3B Date: Tue=2C 20 Mar 2012 00:15:= 37 +0100
>=3B CC: pkix@ietf.org
>=3B Subject: Re: [pkix] certific= ate not issued OCSP status response
>=3B
>=3B Miller=2C Timothy = J. wrote:
>=3B >=3B
>=3B >=3B The effect sought is to cause = a the client to reject the certificate.
>=3B >=3B Responding REVOKED= does that. If you respond NOTISSUED=2C does the
>=3B >=3B client r= eject the certificate *more* than if you respond REVOKED? :)
>=3B >=3B Maybe you want the client to reject it "less" than if you respond R= EVOKED=2C
>=3B because it might cause newly issued certs to be rejecte= d for a few days
>=3B if those responses are cached.
>=3B
>= =3B
>=3B The value I see in white-listing of certs (and OCSP response= s reflecting this)
>=3B is not about throughly compromise CAs=2C but f= or disaster recovery and damage
>=3B control for the CA. As I previou= sly complained=2C X.509 was invented with
>=3B no apparent plan for di= saster recovery. If there is any suspicion=2C
>=3B the only solution = is to immediately and completely nuke the entire PKI=2C
>=3B and re-pe= rsonalize every PKI credential holder=2C and not perform any
>=3B oper= ations based on the old PKI.

I think the right solution i= s to confirm the suspicion=2C and if CA compromise is confirmed=2C nuke the= whole PKI.
 =3B

>=3B
>=3B While one sh= ould really move to a new PKI after a verified thorough
>=3B compromis= e=2C that strategy is much less sensible for "suspicious activity".
>= =3B
>=3B One of the functions of disaster recovery is the ability to = perform an
>=3B audit=2C and then continue operation based on the audi= ted information.
>=3B That is only possible if you have a data base (a= nd issuing log) that
>=3B can be audited=2C and which is used for chec= king certs.
>=3B =3B
agreed.
>=3B
>=3B What i= f you do find malware on one of the machines that the CA software
>=3B= runs on? What if it is "just" a remote-root vulnerability that is found>=3B and patch (like that one on March patch-tuesday?). That you did n= ot hear
>=3B the alarm bells ring=2C does not mean that there was no b= reak-in.
>=3B =3B
Confirm if the CA was compromised. Eva= luate the risk and decide to continue with the same key or to mark it as co= mpromised.

>=3B Worst-case scenario is that you loose your = HSM hardware through some
>=3B hardware defect or natural disaster. H= ow do you know it was purely
>=3B accidental=2C and not a security-bre= ach trying to cover tracks?

Confirm if the CA= was compromised. Evaluate the risk and decide to continue with the same ke= y (if you have a bakup) or to mark it as compromised.

>=3B
>=3B Being able to audit a database&am= p=3Blog of issued certs=2C that may have been
>=3B partially restored = from backup as part of a disaster recovery procedure=2C
>=3B and offer= ing validation against that audited database=2C seems like a
>=3B good= idea and sensible risk management.

And it can be = done even today. Issue a revoked/suspended response for any serial number t= hat is not part of the audited database.


>= =3B
>=3B You probably do not want to nuke a 1+ Mio PKI purely on the = possibility
>=3B of a breach. With the possibility of cert whitelisti= ng (and OCSP responses
>=3B reflecting that) you may not only ensure t= hat you do not miss the
>=3B well-funded attacker that can exploit vul= nerabilities without leaving
>=3B easily visible traces through one of= the still undiscloses ubiquituous
>=3B remote-root vulnerabilities in= every COTS software=2C or can make your HSM die.

= Only two scenarios are possible here. Either the CA key was compromised or = it was not. If the key was not compromised=2C whitelists and 'not-issued' s= tatus do not serve any purpose. If the key was compromised=2C you cannot be= sure of what CA says in the future. Attacker could've backed up the CA key= =2C issued a responder key=2C issued a whitlist signing key=2C issued white= lists valid for next 20 years=2C messed with the audit log=2C messed with = the CA database. Not sure if there is a way to recover from such a scenario= . =3B

A CA can very well make a =3Bconscio= us =3Bdecision to continue operating using the compromised key=2C after= assessing that the cost of replacing the whole PKI is fare more than the d= amage caused by a few (or quite a few) fraudulent certificates that were is= sued using the compromised key. However=2C this is a business cost that sho= uld be absorbed by the CA as opposed to making every relying party pay for = it in form of upgrade costs=2C bloated requests and responses=2C higher ban= dwidths=2C storage and computational costs for fetching=2C storing and proc= essing white lists.



=
>=3B
>=3B And you may use the same facility to audit= high-value transactions
>=3B performed during a time when the CA had = to perform a desaster recovery
>=3B for whatever reason.

=

 =3B
>=3B
>=3B -Martin
>=3B ______= _________________________________________
>=3B pkix mailing list
&g= t=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/pkix
=
= --_9d59ec7f-dc09-4929-8c35-9af1cbb37091_-- From hallam@gmail.com Mon Mar 19 18:23:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA3021F8843 for ; Mon, 19 Mar 2012 18:23:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv+e5EiZ6g+b for ; Mon, 19 Mar 2012 18:23:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2595121F8842 for ; Mon, 19 Mar 2012 18:23:27 -0700 (PDT) Received: by yenm5 with SMTP id m5so6787794yen.31 for ; Mon, 19 Mar 2012 18:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qOX+ZlaEot6NZ/j9YmmQJa/oksSijZLjr+1LXgXxLx8=; b=CUz3preKB5XJxq/Vbju+WjjD7nUVMk5YLZ9SsY0LUrJnRkPJhHwEm2Sm5IzdaisJaZ 6giSbjSy7Lf8iobjgXQib4cR53ikNR9Z3Q17kh3DdCNJzwpCvIuAp74jr4Er4jo9wgo/ 1JE6i7wtXl8ewRr1skySr5swm/tJYvEORYf+1+/Y+ZlfERNdPW/Iz8Y4joDj6Bjvwr8P iyFWcgqVgDBHphay7HyCThFRSiCCXg4z2iiRQxzDpDf3GlVIfHVXXUnc/orOmUd7bXXC 1WJbbWLjrAHDJ9YtEX1yimax2lfvGL82PBIeiVlW2STGvolDTFQ0Qj/bbXfhgp2IKTjP +0OA== MIME-Version: 1.0 Received: by 10.236.174.1 with SMTP id w1mr8824133yhl.125.1332206606041; Mon, 19 Mar 2012 18:23:26 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Mon, 19 Mar 2012 18:23:26 -0700 (PDT) In-Reply-To: <7777A290-2928-44CE-9722-FBA9BE6FA773@vpnc.org> References: <7777A290-2928-44CE-9722-FBA9BE6FA773@vpnc.org> Date: Mon, 19 Mar 2012 21:23:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: PKIX Subject: Re: [pkix] Where to discuss fixing the PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:23:28 -0000 No, what happened on my end was that I talked to some folk who had made proposals during RSA and none was intending to go to Paris, hence making a bar BOF there maybe not so useful :-( On Mon, Mar 19, 2012 at 8:54 PM, Paul Hoffman wrote: > On Mar 19, 2012, at 12:04 PM, Phillip Hallam-Baker wrote: > >> I have been working on a paper, the real question here is scope. >> >> Google proposed some pretty extensive changes to the way the system >> worked in their Certificate Transparency proposal. Then there is the >> EFF Observatory and the Perspectives/Convergence approach. >> >> I think we will need to look at the name and trust infrastructure >> together and from the point of view of 'how do we stop bad things >> happening to the end user' rather than looking at fixing things >> piecemeal. > > This feels like the discussion on the "therightkey" mailing list stopped and, after a few weeks, came over to the PKIX WG. Is that intentional? > > If the purpose of moving it over to PKIX is to get a discussion slot in Paris because there is no therightkey BoF, that's fine, but some coordination with the ADs is in order. Hallway conversation about the topics will happen regardless, of course. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From tmiller@mitre.org Tue Mar 20 05:13:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A722A21F85E6 for ; Tue, 20 Mar 2012 05:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23fupfwWwYYx for ; Tue, 20 Mar 2012 05:13:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2390121F85D8 for ; Tue, 20 Mar 2012 05:13:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C040921B06E7; Tue, 20 Mar 2012 08:13:17 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B0E8121B06C4; Tue, 20 Mar 2012 08:13:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 08:13:17 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNBg/Be3S8XWTYQEqfNuOgbNpcQpZzXJcA Date: Tue, 20 Mar 2012 12:13:16 +0000 Message-ID: <79FABC1F-20E0-4937-BDF9-098BA52BF538@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.22] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <466BDA19F0230E4C91ED5B45B772FE78@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 12:13:18 -0000 On Mar 19, 2012, at 3:35 PM, Phillip Hallam-Baker wrote: > There are two separate questions, first which protocol to change, > second how to implement the change. Three. First is "Is a protocol change needed?" -- T From tmiller@mitre.org Tue Mar 20 05:24:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B31121F8643 for ; Tue, 20 Mar 2012 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GJUh5OnB1XP for ; Tue, 20 Mar 2012 05:24:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 86BA621F8619 for ; Tue, 20 Mar 2012 05:24:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB82421B071E; Tue, 20 Mar 2012 08:24:11 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C566B21B06EE; Tue, 20 Mar 2012 08:24:11 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 08:24:11 -0400 From: "Miller, Timothy J." To: "Kemp, David P." Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtpd+AgAANqwCABD+HgIAAJoQAgAAHwgCAAUMpAA== Date: Tue, 20 Mar 2012 12:24:10 +0000 Message-ID: <95303974-CD39-42AE-A4AA-F430DD5D47BA@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:24:13 -0000 Steve's scenario tells me Issuer+Serial is an insufficiently unique CertID.= =20 -- T On Mar 19, 2012, at 12:07 PM, Kemp, David P. wrote: > In Steve's example, the attacker-generated cert (for which there is no > record) has the same serial number as a legitimately-issued cert. The > CA's database shows the serial number as existing and not revoked, and > nothing has come to the CA's attention to indicate that two certs with > the same serial number have been signed. >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Monday, March 19, 2012 12:40 PM > To: Stephen Kent; Liaquat Khan > Cc: pkix@ietf.org > Subject: Re: [pkix] certificate not issued OCSP status response >=20 > Steve, >=20 > I think I lost you here. >=20 > On 12-03-19 3:21 PM, "Stephen Kent" wrote: >=20 >> - no record of cert issuance appears in any CA log. >>=20 >> - an OCSP response for the cert serial number will not yield a=20 >> "revoked" or "not issued" because the legitimate cert in question is=20 >> valid and not revoked. >=20 > If the CA has no record of it, why would it not yield a "not issued" > response? >=20 > I'm not saying that we should go there. Just couldn't follow your logic. >=20 > /Stefan >=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 From tgindin@us.ibm.com Tue Mar 20 05:24:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA98121F8675 for ; Tue, 20 Mar 2012 05:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.847 X-Spam-Level: X-Spam-Status: No, score=-9.847 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tY2CNxboKon for ; Tue, 20 Mar 2012 05:24:41 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0B71221F8671 for ; Tue, 20 Mar 2012 05:24:41 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 20 Mar 2012 06:24:40 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 20 Mar 2012 06:24:37 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 3A024C90062 for ; Tue, 20 Mar 2012 08:24:36 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2KCOaeX333508 for ; Tue, 20 Mar 2012 08:24:36 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2KCOZFN008709 for ; Tue, 20 Mar 2012 08:24:36 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2KCOZ5T008661; Tue, 20 Mar 2012 08:24:35 -0400 In-Reply-To: References: To: "Henry B. Hotz" MIME-Version: 1.0 X-KeepSent: 4826C5AD:40943C8E-852579C6:0082EB22; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 20 Mar 2012 08:24:42 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/20/2012 08:24:34, Serialize complete at 03/20/2012 08:24:34 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032012-3270-0000-0000-000004EC14DF Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 12:24:42 -0000 Actually, my lack of participation was more physical exhaustion than a result of the emotional temperature of the discussions. There are probably others who are more bothered than me by that level, and if I typically sent out my initial draft responses I would probably contribute to the problem. Given my limited practical experience with OCSP, I'm going to make some naive comments below, after starting with a statement of what I at least think needs to be resolved. One outstanding problem is that a client often cannot distinguish "good" from merely "unrevoked", or even be aware that the responder is not making such a distinction. The other is for a client to provide evidence that a certificate is in circulation which is not expected to be by the responder. My other suggestion below about using the issuer's SIA for id-ad-ocsp is unrelated to these, and is intended to reduce the chances of an attacker diverting the revocation check to a server under his own controls. I do wonder what the point is to having OCSP support an "unknown" status code if it's appropriate for a responder to return "good" on a serial number that was never issued. The natural meaning of the words would suggest to me that a CRL-only OCSP responder should call its two status values "revoked" and "unknown" rather than "revoked" and "good". One could probably argue that never using "good" is consistent with the literal wording of RFC 2560 section 2.2, but it certainly isn't the common practice. Thus I consider that the current "good" status would mean more to high-reliance RP's if it were accompanied by an extension telling the client whether "good" includes "unknown" or not. That's not exactly Denis' position, but it's close to it. Next, I am surprised that the reporting extension in which a client can provide evidence of a certificate's actual existence has drawn little comment. I would think that, in conjunction with either "unknown" or "neverIssued", that extension allows a client to report a possible issuer breach inside the protocol. In particular, I think that it answers Dave Cooper's objection of Friday, because a major point to this set of proposed changes is to permit a client to test his suspicion of a compromise. It's perfectly true that a client who's inside a DNS masquerade environment will gain little from unsigned OCSP responses of any type. While using an OCSP URL with an IP address would avoid the DNS masquerade, no attacker's subject certificate will create such a value (although RA compromises would probably not change the AIA extension in most CA's). Last, I am not sure why it's a good thing that id-ad-ocsp is recommended to be placed into the subject certificate's AIA extension rather than into the issuer's SIA. I realize that this provides greater flexibility for an issuer to change its practices over time, but letting an attacker redirect OCSP URL's is a bad thing (and Santosh is right that it's far too easy, although not about Phill's analytic skills). CRLDP partitioning is a reason for that revocation mechanism to be in the subject certificate rather than the issuer one, but why should that precedent govern OCSP? A migration path to change this would start by recommending that an SIA value in the issuer certificate SHOULD take precedence over an AIA value in the subject one if both values are present. Tom Gindin From: "Henry B. Hotz" To: Stephen Kent , Cc: pkix Date: 03/19/2012 04:26 PM Subject: Re: [pkix] Possible OCSP Extensions Sent by: pkix-bounces@ietf.org On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: > At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >> Suppose we accept both your arguments below, and Stephen Kent's arguments that SCVP is the right solution for the real problem faced by ordinary users. > > Steve Kent didn't say that. OK, OK. I admit I'm stretching a point to try to find common ground. I'm kind of disappointed by how acrimonious the discussions of this feature (and on this list in general) have been. I'm guessing that is why we haven't heard from Tom Gundin, the guy who started this thread, in a while. > He said that PKIX decided to develop SCVP instead of extending OCSP, when we lasted visited this sort of topic. In later messages I noted that folks did not except public CAs to operate SCVP servers; SCVP is best suited for enterprise environments. > > Steve ------------------------------------------------------ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Tue Mar 20 05:28:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB91C21F85E1 for ; Tue, 20 Mar 2012 05:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Wr8EESaw43 for ; Tue, 20 Mar 2012 05:28:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7821F85E0 for ; Tue, 20 Mar 2012 05:28:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EBD4C21B0758; Tue, 20 Mar 2012 08:28:58 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C262321B074C; Tue, 20 Mar 2012 08:28:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 08:28:58 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtpd+AgAQoagCAABMzgIAADH+AgAA9iYCAATpSgA== Date: Tue, 20 Mar 2012 12:28:58 +0000 Message-ID: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.175] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:29:00 -0000 On Mar 19, 2012, at 12:43 PM, Phillip Hallam-Baker wrote: > In this case a NOTISSUED response for an actual cert would sound alarm > bells at the meta-level and an industry level response. Contrawise > responding to a request for a non-existent cert with any other status > would be a cause for concern. Really? You think that's a good idea? I can't *wait* for the ability Verisign down simply by sending false OCSP q= ueries. Then my Evil Plan can commence! MWahahhahhahaa! =20 Seriously, if you expect a CA operator to take action based on *unauthentic= ated, untrusted input* it receives at the OCSP interface, you've got anothe= r thing coming. Existence of an OCSP request *does not* imply existence of= a fraudulent cert. -- T From tmiller@mitre.org Tue Mar 20 05:31:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A521F85E5 for ; Tue, 20 Mar 2012 05:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxuaZ72OLbVA for ; Tue, 20 Mar 2012 05:31:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1763C21F85E1 for ; Tue, 20 Mar 2012 05:31:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ACF2621B0739; Tue, 20 Mar 2012 08:31:10 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8DECC21B073C; Tue, 20 Mar 2012 08:31:10 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 08:31:10 -0400 From: "Miller, Timothy J." To: "Henry B. Hotz" Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: AQHNA6D7vbmpFh8r1k6Bb6d7D6WloZZtlJUAgAQ47ACAAIkZAIABD9gA Date: Tue, 20 Mar 2012 12:31:09 +0000 Message-ID: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> In-Reply-To: <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:31:12 -0000 On Mar 19, 2012, at 3:18 PM, Henry B. Hotz wrote: > To me UNKNOWN means "my knowledge is incomplete (and therefore not author= itative)" and does not mean "this is clearly bogus". I can form bogus Issuer/Serial combinations all day long. What does it mea= n to the CA operator if I do? -- T From carl@redhoundsoftware.com Tue Mar 20 05:35:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095921F85EE for ; Tue, 20 Mar 2012 05:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2gAooOZxYNp for ; Tue, 20 Mar 2012 05:35:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2025521F86F6 for ; Tue, 20 Mar 2012 05:35:40 -0700 (PDT) Received: by yenm5 with SMTP id m5so7020117yen.31 for ; Tue, 20 Mar 2012 05:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=TVrX/uDJ0fM9VuIw4VM3+LTGdMXuTsfCiGxClSN9kvc=; b=HlxPJew2OvSQnju4pFyQUw0kEVETykul21iryTVssTIsWXjxuFR2Iuksza+VZJDseC Ad+cGsY8Lx7DQ2ZWj4BfKap/JDOF2sg4utFQUtJZoxa3tox/X5y0QizadS9MhW5wuK8L ir4WL1/j8lejFR6tEKlignTjBWL7melqEYOXhryrGWJyikZiTiolZMG/sICDDWiyC5QP yFQU1e83LqF3dKm7wADRz1sbPA82ZlbrMYpfKNmYQUKUkUlk9CGzB2M0Avidcx2qttuU gIOb+R4HSdJC3UizxVgNUhBp04YZMrK2zHdcPsqE4f9sQisSul26vA7SdNdWWaOlLNcn Yl6Q== Received: by 10.224.207.70 with SMTP id fx6mr331784qab.79.1332246937176; Tue, 20 Mar 2012 05:35:37 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id cw5sm2426402qab.20.2012.03.20.05.35.35 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 05:35:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 20 Mar 2012 08:35:23 -0400 From: Carl Wallace To: Liaquat Khan , Stephen Kent Message-ID: Thread-Topic: [pkix] certificate not issued OCSP status response In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQlNHfd9IzTnZrKZ/OYfQ2oXPHvalUp0yUPLvUyKjTkEpDcVE4tsdbWmjERDtC1963VIXPEq Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:35:51 -0000 On 3/19/12 2:06 PM, "Liaquat Khan" wrote: >It's a valid attack scenario Steve, again assuming attacker has got access >to CA's HSM, which is obviously a major problem for CA. > >Your scenario shows clearly that the OCSP responder cannot protect against >this even with "not issued" response. > >Interestingly this means SCVP is a better protocol for implementing this >check since at least it gets the full cert from the client and can really >determine if that particular cert was every issued or not. Note this >doesn't mean that I am advocating supporting this in SCVP! Using the id-swb-ers-pkc-cert wantBack defined in RFC 5276, SCVP can essentially provide a whitelist feature now. Of course, few shops use SCVP and none use SCVP/ERS. It could be worth a look though if whitelist notion is explored. ERS provides a hash tree structure that could represent issued certs and SCVP/ERS defines a request/response to obtain the proof for a given certificate. >So I think we are still at square one, what is the attack scenario this >feature is trying to prevent or at least detect? From what I can see its >only for the detection that a fake certificate was issue by an attacker by >accessing the CA's HSM and the attacker chose not to re-use an existing >serial number and also chose not to use a compromised OCSP responder cert >to respond for that cert, and also chose to delete the cert from the CA's >database in case the HSM was accessed through the CA etc. etc. IMO this >shows its not really worth changing the protocol for such a very narrow >attack scenario. The attacker is not going to be so na=EFve, especially if >they have the skills to break into the CA. > >Regards >LK > > > > >On 19/03/2012 14:21, "Stephen Kent" wrote: > >>Liaquat, >> >>Thanks for providing an example of an attack scenario and its >>implications re various countermeasures. >> >>Here's an "easy to imagine" alternative scenario: >> >> - attacker gains access to HSM and causes a cert to be issued, with the >>same serial number as a extant, legitimate cert. >> >>- no record of cert issuance appears in any CA log. >> >>- an OCSP response for the cert serial number will not yield >>a "revoked" or "not issued" because the legitimate cert in question is >>valid and not revoked. >> >>until the CA is made aware of the bogus cert, it cannot revoke it, >>and at that time a CRL or the current OCSP mechanism will work as well >>as any proposed enhancements to OCSP. >> >>Thsi is why a thorough, well-written analysis of the problems to be >>solved is needed before we pursue changes of the sort being proposed. >> >>Steve >> >> >> > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Tue Mar 20 06:34:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6997421F8683 for ; Tue, 20 Mar 2012 06:34:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5f56kfgtyuR for ; Tue, 20 Mar 2012 06:34:52 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 698EC21F8671 for ; Tue, 20 Mar 2012 06:34:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2KDYpwc045881 for ; Tue, 20 Mar 2012 09:34:51 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 09:34:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Mar 2012 09:34:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] certificate not issued OCSP status response Thread-Index: Ac0GNIAa7FiBdHsNSEi5CKhp5tdnmgAZSJRg References: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> from "Miller, From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Mar 2012 13:34:51.0211 (UTC) FILETIME=[3A0C81B0:01CD069E] Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:34:53 -0000 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain > From: mrex@sap.com >>=20 >> One of the functions of disaster recovery is the ability to perform an=20 >> audit, and then continue operation based on the audited information. >> That is only possible if you have a data base (and issuing log) that=20 >> can be audited, and which is used for checking certs. >>=20 > agreed. Agreed. >> Worst-case scenario is that you loose your HSM hardware through some=20 >> hardware defect or natural disaster. How do you know it was purely=20 >> accidental, and not a security-breach trying to cover tracks? > > Confirm if the CA was compromised. Evaluate the risk and decide > to continue with the same key (if you have a bakup) or to mark it as compromised. The premise is that you cannot confirm if the CA was compromised, as the hardware root of trust has been destroyed. Which raises the question: assuming the HSM is still operating, do typical HSMs include tamper-resistant audit features, such as signed records and a hardware-stored operation counter to detect missing records? PKIX is being asked to design multi-party protocol workarounds to fix poor CA operations. While layered security is a good idea, it's incumbent on each element of a system to do its part, and the CA has the bulk of that responsibility. HSMs that guarantee a secure audit trail (as long as the HSM itself has not been compromised) would make this entire discussion moot. From tmiller@mitre.org Tue Mar 20 06:39:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B3A21F8656 for ; Tue, 20 Mar 2012 06:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA7OcVdyuYSW for ; Tue, 20 Mar 2012 06:39:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB521F85BD for ; Tue, 20 Mar 2012 06:39:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CA4B21B071B; Tue, 20 Mar 2012 09:39:34 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 72DA421B0561; Tue, 20 Mar 2012 09:39:34 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 09:39:34 -0400 From: "Miller, Timothy J." To: Tom Gindin Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgA Date: Tue, 20 Mar 2012 13:39:33 +0000 Message-ID: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 13:39:37 -0000 So would this be a fair summary of the range of possible responses? 1) A Responder with no access to the CA history has only two possible respo= nses: REVOKED - Certificate identified by the Request is on a CRL. UNKNOWN - All other queries. 2) A Responder with access to the CA history, if and only if certificate ev= idence is provided in the Request, may also respond: GOOD - An exact match for the certificate in the Request is found in the C= A history, and that certificate is not on a CRL. 3) A Responder with access to the CA history, if and only if certificate *a= nd chain* evidence is provided in the Request, may also respond: NOTISSUED - The certificate in the Request chains to the cognizant CA but = no exact match for the certificate is found in the CA history. "Certificate evidence" must be a sufficiently unique CertID. I'd want a ce= rt thumbprint at the least; a copy of the cert itself at most. If the Resp= onder is operating as a Trusted Responder, the relying party won't be able = to detect name collisions if only Issuer/Serial is used. CA-signed and CA-= Designated can detect name collisions because the queried cert won't chain = to the same trust anchor as the OCSP Response signature, but they have to b= e specifically directed to make this check. "Certificate and chain evidence" will probably have to be the certificate i= tself, though if anyone has alternative ideas I'm all ears. IMHO this is r= equired for NOTISSUED because it's the only way to prevent a malicious quer= ent from messing up your day with falsified certificate evidence. A query = that doesn't match anything in the CA history is *not* enough evidence of c= ompromise unless it can be shown to be a cert that actually chains to the c= ognizant CA. I think the above is close to full coverage, but it's also a complete overh= aul of OCSP. I'd call it a new protocol, though I don't know enough about = SCVP to say whether or not this functions can be replicated with that proto= col. -- T On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote: > Actually, my lack of participation was more physical exhaustion=20 > than a result of the emotional temperature of the discussions. There are= =20 > probably others who are more bothered than me by that level, and if I=20 > typically sent out my initial draft responses I would probably contribute= =20 > to the problem. Given my limited practical experience with OCSP, I'm=20 > going to make some naive comments below, after starting with a statement= =20 > of what I at least think needs to be resolved. > One outstanding problem is that a client often cannot distinguish= =20 > "good" from merely "unrevoked", or even be aware that the responder is no= t=20 > making such a distinction. The other is for a client to provide evidence= =20 > that a certificate is in circulation which is not expected to be by the=20 > responder. My other suggestion below about using the issuer's SIA for=20 > id-ad-ocsp is unrelated to these, and is intended to reduce the chances o= f=20 > an attacker diverting the revocation check to a server under his own=20 > controls.=20 > I do wonder what the point is to having OCSP support an "unknown"= =20 > status code if it's appropriate for a responder to return "good" on a=20 > serial number that was never issued. The natural meaning of the words=20 > would suggest to me that a CRL-only OCSP responder should call its two=20 > status values "revoked" and "unknown" rather than "revoked" and "good".=20 > One could probably argue that never using "good" is consistent with the=20 > literal wording of RFC 2560 section 2.2, but it certainly isn't the commo= n=20 > practice. Thus I consider that the current "good" status would mean more= =20 > to high-reliance RP's if it were accompanied by an extension telling the= =20 > client whether "good" includes "unknown" or not. That's not exactly=20 > Denis' position, but it's close to it. > Next, I am surprised that the reporting extension in which a=20 > client can provide evidence of a certificate's actual existence has drawn= =20 > little comment. I would think that, in conjunction with either "unknown"= =20 > or "neverIssued", that extension allows a client to report a possible=20 > issuer breach inside the protocol. In particular, I think that it answer= s=20 > Dave Cooper's objection of Friday, because a major point to this set of=20 > proposed changes is to permit a client to test his suspicion of a=20 > compromise. It's perfectly true that a client who's inside a DNS=20 > masquerade environment will gain little from unsigned OCSP responses of=20 > any type. While using an OCSP URL with an IP address would avoid the DNS= =20 > masquerade, no attacker's subject certificate will create such a value=20 > (although RA compromises would probably not change the AIA extension in=20 > most CA's). > Last, I am not sure why it's a good thing that id-ad-ocsp is=20 > recommended to be placed into the subject certificate's AIA extension=20 > rather than into the issuer's SIA. I realize that this provides greater= =20 > flexibility for an issuer to change its practices over time, but letting= =20 > an attacker redirect OCSP URL's is a bad thing (and Santosh is right that= =20 > it's far too easy, although not about Phill's analytic skills). CRLDP=20 > partitioning is a reason for that revocation mechanism to be in the=20 > subject certificate rather than the issuer one, but why should that=20 > precedent govern OCSP? A migration path to change this would start by=20 > recommending that an SIA value in the issuer certificate SHOULD take=20 > precedence over an AIA value in the subject one if both values are=20 > present. >=20 >=20 > Tom Gindin >=20 >=20 >=20 >=20 > From: "Henry B. Hotz" > To: Stephen Kent ,=20 > Cc: pkix > Date: 03/19/2012 04:26 PM > Subject: Re: [pkix] Possible OCSP Extensions > Sent by: pkix-bounces@ietf.org >=20 >=20 >=20 >=20 > On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: >=20 >> At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >>> Suppose we accept both your arguments below, and Stephen Kent's=20 > arguments that SCVP is the right solution for the real problem faced by=20 > ordinary users. >>=20 >> Steve Kent didn't say that. >=20 > OK, OK. I admit I'm stretching a point to try to find common ground. >=20 > I'm kind of disappointed by how acrimonious the discussions of this=20 > feature (and on this list in general) have been. I'm guessing that is wh= y=20 > we haven't heard from Tom Gundin, the guy who started this thread, in a=20 > while. >=20 >> He said that PKIX decided to develop SCVP instead of extending OCSP,=20 > when we lasted visited this sort of topic. In later messages I noted tha= t=20 > folks did not except public CAs to operate SCVP servers; SCVP is best=20 > suited for enterprise environments. >>=20 >> Steve >=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 >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Tue Mar 20 07:33:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9F21F86D9 for ; Tue, 20 Mar 2012 07:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtg2WbR6yabr for ; Tue, 20 Mar 2012 07:33:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAC421F8694 for ; Tue, 20 Mar 2012 07:33:18 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49212) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA07V-000Be1-Lk; Tue, 20 Mar 2012 10:33:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <79FABC1F-20E0-4937-BDF9-098BA52BF538@mitre.org> References: <79FABC1F-20E0-4937-BDF9-098BA52BF538@mitre.org> Date: Tue, 20 Mar 2012 10:31:09 -0400 To: "Miller, Timothy J." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 14:33:19 -0000 At 12:13 PM +0000 3/20/12, Miller, Timothy J. wrote: >On Mar 19, 2012, at 3:35 PM, Phillip Hallam-Baker wrote: > >> There are two separate questions, first which protocol to change, >> second how to implement the change. > >Three. First is "Is a protocol change needed?" > >-- T Thanks, Tim. The first question we need to address is the one you noted, based on a written description of the problem to be solved. Steve From brennansecurity@gmail.com Tue Mar 20 07:58:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930F721F8501 for ; Tue, 20 Mar 2012 07:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGEr6CR0UDYb for ; Tue, 20 Mar 2012 07:58:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5B21F8510 for ; Tue, 20 Mar 2012 07:58:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so54971vbb.31 for ; Tue, 20 Mar 2012 07:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y/+jAbAkLCWg4H4bPMD+J6nHyDXdcEQNqkeDoYnz5sc=; b=LSoJTA/9CdPjrZwkeKt2juxhzqiuxR1nXZ/r5wpghj7Lh2Iq80RpU6E70U5rYyqoU2 uC+L9xPIc0epzG7Qi+/SCTp1204CKqKVXs7rv2DnjsbUuebwi+JVQ5x8ZuU05NVOFGfg wrlOdFKz2jJ6v4MtDiB66fz5kh+smCZZ04koZlJtfunNQ8ZYLbL7A1EYijl5/tl69w81 EHy+Yse3HMmw0UB+gK4fsQbH4Ulm5hxN/phIwu3hgHl3FhSI4oHlQnTxCU1WVrNRiB56 Cgs8WqP2AfbeQWmwOqNGlDlyWvq0OpJOSEIP24nQ4xoeiDJOlGZcOP4x0j/qd28HNTZW xcVA== MIME-Version: 1.0 Received: by 10.52.34.200 with SMTP id b8mr63520vdj.59.1332255508758; Tue, 20 Mar 2012 07:58:28 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 07:58:28 -0700 (PDT) In-Reply-To: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> Date: Tue, 20 Mar 2012 10:58:28 -0400 Message-ID: From: brennan security To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 14:58:30 -0000 Tim, There is some ambiguity in the flow-down results of what we are discussing. Current CRLs content is serial based, rather than actual certificate or dig= est. If we are going to fix OCSP, it may mean a requirement to update CRLs also, as CRLs are often used as an information source for OCSP production. -b On Tue, Mar 20, 2012 at 9:39 AM, Miller, Timothy J. wro= te: > So would this be a fair summary of the range of possible responses? > > 1) A Responder with no access to the CA history has only two possible res= ponses: > > =A0 =A0 =A0 =A0REVOKED - Certificate identified by the Request is on a CR= L. > =A0 =A0 =A0 =A0UNKNOWN - All other queries. > > 2) A Responder with access to the CA history, if and only if certificate = evidence is provided in the Request, may also respond: > > =A0 =A0 =A0 =A0GOOD - An exact match for the certificate in the Request i= s found in the CA history, and that certificate is not on a CRL. > > 3) A Responder with access to the CA history, if and only if certificate = *and chain* evidence is provided in the Request, may also respond: > > =A0 =A0 =A0 =A0NOTISSUED - The certificate in the Request chains to the c= ognizant CA but no exact match for the certificate is found in the CA histo= ry. > > "Certificate evidence" must be a sufficiently unique CertID. =A0I'd want = a cert thumbprint at the least; a copy of the cert itself at most. =A0If th= e Responder is operating as a Trusted Responder, the relying party won't be= able to detect name collisions if only Issuer/Serial is used. =A0CA-signed= and CA-Designated can detect name collisions because the queried cert won'= t chain to the same trust anchor as the OCSP Response signature, but they h= ave to be specifically directed to make this check. > > "Certificate and chain evidence" will probably have to be the certificate= itself, though if anyone has alternative ideas I'm all ears. =A0IMHO this = is required for NOTISSUED because it's the only way to prevent a malicious = querent from messing up your day with falsified certificate evidence. =A0A = query that doesn't match anything in the CA history is *not* enough evidenc= e of compromise unless it can be shown to be a cert that actually chains to= the cognizant CA. > > I think the above is close to full coverage, but it's also a complete ove= rhaul of OCSP. =A0I'd call it a new protocol, though I don't know enough ab= out SCVP to say whether or not this functions can be replicated with that p= rotocol. > > -- T > > > > > On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote: > >> =A0 =A0 =A0 =A0Actually, my lack of participation was more physical exha= ustion >> than a result of the emotional temperature of the discussions. =A0There = are >> probably others who are more bothered than me by that level, and if I >> typically sent out my initial draft responses I would probably contribut= e >> to the problem. =A0Given my limited practical experience with OCSP, I'm >> going to make some naive comments below, after starting with a statement >> of what I at least think needs to be resolved. >> =A0 =A0 =A0 =A0One outstanding problem is that a client often cannot dis= tinguish >> "good" from merely "unrevoked", or even be aware that the responder is n= ot >> making such a distinction. =A0The other is for a client to provide evide= nce >> that a certificate is in circulation which is not expected to be by the >> responder. =A0My other suggestion below about using the issuer's SIA for >> id-ad-ocsp is unrelated to these, and is intended to reduce the chances = of >> an attacker diverting the revocation check to a server under his own >> controls. >> =A0 =A0 =A0 =A0I do wonder what the point is to having OCSP support an "= unknown" >> status code if it's appropriate for a responder to return "good" on a >> serial number that was never issued. =A0The natural meaning of the words >> would suggest to me that a CRL-only OCSP responder should call its two >> status values "revoked" and "unknown" rather than "revoked" and "good". >> One could probably argue that never using "good" is consistent with the >> literal wording of RFC 2560 section 2.2, but it certainly isn't the comm= on >> practice. =A0Thus I consider that the current "good" status would mean m= ore >> to high-reliance RP's if it were accompanied by an extension telling the >> client whether "good" includes "unknown" or not. =A0That's not exactly >> Denis' position, but it's close to it. >> =A0 =A0 =A0 =A0Next, I am surprised that the reporting extension in whic= h a >> client can provide evidence of a certificate's actual existence has draw= n >> little comment. =A0I would think that, in conjunction with either "unkno= wn" >> or "neverIssued", that extension allows a client to report a possible >> issuer breach inside the protocol. =A0In particular, I think that it ans= wers >> Dave Cooper's objection of Friday, because a major point to this set of >> proposed changes is to permit a client to test his suspicion of a >> compromise. =A0It's perfectly true that a client who's inside a DNS >> masquerade environment will gain little from unsigned OCSP responses of >> any type. =A0While using an OCSP URL with an IP address would avoid the = DNS >> masquerade, no attacker's subject certificate will create such a value >> (although RA compromises would probably not change the AIA extension in >> most CA's). >> =A0 =A0 =A0 =A0Last, I am not sure why it's a good thing that id-ad-ocsp= is >> recommended to be placed into the subject certificate's AIA extension >> rather than into the issuer's SIA. =A0I realize that this provides great= er >> flexibility for an issuer to change its practices over time, but letting >> an attacker redirect OCSP URL's is a bad thing (and Santosh is right tha= t >> it's far too easy, although not about Phill's analytic skills). =A0CRLDP >> partitioning is a reason for that revocation mechanism to be in the >> subject certificate rather than the issuer one, but why should that >> precedent govern OCSP? =A0A migration path to change this would start by >> recommending that an SIA value in the issuer certificate SHOULD take >> precedence over an AIA value in the subject one if both values are >> present. >> >> >> Tom Gindin >> >> >> >> >> From: =A0 "Henry B. Hotz" >> To: =A0 =A0 Stephen Kent , >> Cc: =A0 =A0 pkix >> Date: =A0 03/19/2012 04:26 PM >> Subject: =A0 =A0 =A0 =A0Re: [pkix] Possible OCSP Extensions >> Sent by: =A0 =A0 =A0 =A0pkix-bounces@ietf.org >> >> >> >> >> On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: >> >>> At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >>>> Suppose we accept both your arguments below, and Stephen Kent's >> arguments that SCVP is the right solution for the real problem faced by >> ordinary users. >>> >>> Steve Kent didn't say that. >> >> OK, OK. =A0I admit I'm stretching a point to try to find common ground. >> >> I'm kind of disappointed by how acrimonious the discussions of this >> feature (and on this list in general) have been. =A0I'm guessing that is= why >> we haven't heard from Tom Gundin, the guy who started this thread, in a >> while. >> >>> He said that PKIX decided to develop SCVP instead of extending OCSP, >> when we lasted visited this sort of topic. In =A0later messages I noted = that >> folks did not except public CAs to operate SCVP servers; SCVP is best >> suited for enterprise environments. >>> >>> Steve >> >> ------------------------------------------------------ >> 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 >> >> _______________________________________________ >> 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 piyush@identicate.com Tue Mar 20 08:01:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8F221F8533 for ; Tue, 20 Mar 2012 08:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb4+E+4ocPB8 for ; Tue, 20 Mar 2012 08:01:18 -0700 (PDT) Received: from col0-omc4-s14.col0.hotmail.com (col0-omc4-s14.col0.hotmail.com [65.55.34.216]) by ietfa.amsl.com (Postfix) with ESMTP id 490A021F85AE for ; Tue, 20 Mar 2012 08:01:18 -0700 (PDT) Received: from COL119-W64 ([65.55.34.199]) by col0-omc4-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 08:01:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_aa186c01-72c6-4038-8a55-6542fad7188a_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Tue, 20 Mar 2012 08:01:17 -0700 Importance: Normal In-Reply-To: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> References: , , , , , , , <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2012 15:01:17.0845 (UTC) FILETIME=[4D860C50:01CD06AA] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 15:01:19 -0000 --_aa186c01-72c6-4038-8a55-6542fad7188a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: tmiller@mitre.org > To: tgindin@us.ibm.com > Date: Tue=2C 20 Mar 2012 13:39:33 +0000 > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 > So would this be a fair summary of the range of possible responses? >=20 > 1) A Responder with no access to the CA history has only two possible res= ponses: >=20 > REVOKED - Certificate identified by the Request is on a CRL. > UNKNOWN - All other queries. >=20 > 2) A Responder with access to the CA history=2C if and only if certificat= e evidence is provided in the Request=2C may also respond: >=20 > GOOD - An exact match for the certificate in the Request is found in the= CA history=2C and that certificate is not on a CRL. >=20 > 3) A Responder with access to the CA history=2C if and only if certificat= e *and chain* evidence is provided in the Request=2C may also respond: >=20 > NOTISSUED - The certificate in the Request chains to the cognizant CA bu= t no exact match for the certificate is found in the CA history. >=20 > "Certificate evidence" must be a sufficiently unique CertID. I'd want a = cert thumbprint at the least=3B a copy of the cert itself at most. If the = Responder is operating as a Trusted Responder=2C the relying party won't be= able to detect name collisions if only Issuer/Serial is used. CA-signed a= nd CA-Designated can detect name collisions because the queried cert won't = chain to the same trust anchor as the OCSP Response signature=2C but they h= ave to be specifically directed to make this check. >=20 > "Certificate and chain evidence" will probably have to be the certificate= itself=2C though if anyone has alternative ideas I'm all ears. IMHO this = is required for NOTISSUED because it's the only way to prevent a malicious = querent from messing up your day with falsified certificate evidence. A qu= ery that doesn't match anything in the CA history is *not* enough evidence = of compromise unless it can be shown to be a cert that actually chains to t= he cognizant CA. > Thanks for the comprehensive coverage Tim. i don't think that you missed = anything Here are additional implications of blessing this concept in any p= rotocol- CRLs and signature checking won't be enough to accept a certificat= e. RFC 5280 would need to be changed- CAs would be required to publish a wh= ite list (for RPs who do not do OCSP or this new protocol) and CRLs would = become useless. This probably requires change in X.509.- Since the primary= reason for deploying OCSP is the pain associated with downloading and proc= essing big CRLs=2C adoption of OCSP (or the new protocol) would increase ev= en more because now we would have even bigger white lists.- While we are at= it=2C we can also recommend getting rid of signatures from x.509 certifica= tes because they won't be needed anymore. RPs just send the certificate wit= hout signature(or its hash) to the CA=2C or look up the white list and figu= re out if it was really blessed by the CA. > I think the above is close to full coverage=2C but it's also a complete o= verhaul of OCSP. I'd call it a new protocol=2C though I don't know enough = about SCVP to say whether or not this functions can be replicated with that= protocol. >=20 > -- T >=20 >=20 >=20 >=20 > On Mar 20=2C 2012=2C at 7:24 AM=2C Tom Gindin wrote: >=20 > > Actually=2C my lack of participation was more physical exhaustio= n=20 > > than a result of the emotional temperature of the discussions. There a= re=20 > > probably others who are more bothered than me by that level=2C and if I= =20 > > typically sent out my initial draft responses I would probably contribu= te=20 > > to the problem. Given my limited practical experience with OCSP=2C I'm= =20 > > going to make some naive comments below=2C after starting with a statem= ent=20 > > of what I at least think needs to be resolved. > > One outstanding problem is that a client often cannot distinguis= h=20 > > "good" from merely "unrevoked"=2C or even be aware that the responder i= s not=20 > > making such a distinction. The other is for a client to provide eviden= ce=20 > > that a certificate is in circulation which is not expected to be by the= =20 > > responder. My other suggestion below about using the issuer's SIA for= =20 > > id-ad-ocsp is unrelated to these=2C and is intended to reduce the chanc= es of=20 > > an attacker diverting the revocation check to a server under his own=20 > > controls.=20 > > I do wonder what the point is to having OCSP support an "unknown= "=20 > > status code if it's appropriate for a responder to return "good" on a=20 > > serial number that was never issued. The natural meaning of the words= =20 > > would suggest to me that a CRL-only OCSP responder should call its two= =20 > > status values "revoked" and "unknown" rather than "revoked" and "good".= =20 > > One could probably argue that never using "good" is consistent with the= =20 > > literal wording of RFC 2560 section 2.2=2C but it certainly isn't the c= ommon=20 > > practice. Thus I consider that the current "good" status would mean mo= re=20 > > to high-reliance RP's if it were accompanied by an extension telling th= e=20 > > client whether "good" includes "unknown" or not. That's not exactly=20 > > Denis' position=2C but it's close to it. > > Next=2C I am surprised that the reporting extension in which a=20 > > client can provide evidence of a certificate's actual existence has dra= wn=20 > > little comment. I would think that=2C in conjunction with either "unkn= own"=20 > > or "neverIssued"=2C that extension allows a client to report a possible= =20 > > issuer breach inside the protocol. In particular=2C I think that it an= swers=20 > > Dave Cooper's objection of Friday=2C because a major point to this set = of=20 > > proposed changes is to permit a client to test his suspicion of a=20 > > compromise. It's perfectly true that a client who's inside a DNS=20 > > masquerade environment will gain little from unsigned OCSP responses of= =20 > > any type. While using an OCSP URL with an IP address would avoid the D= NS=20 > > masquerade=2C no attacker's subject certificate will create such a valu= e=20 > > (although RA compromises would probably not change the AIA extension in= =20 > > most CA's). > > Last=2C I am not sure why it's a good thing that id-ad-ocsp is=20 > > recommended to be placed into the subject certificate's AIA extension=20 > > rather than into the issuer's SIA. I realize that this provides greate= r=20 > > flexibility for an issuer to change its practices over time=2C but lett= ing=20 > > an attacker redirect OCSP URL's is a bad thing (and Santosh is right th= at=20 > > it's far too easy=2C although not about Phill's analytic skills). CRLD= P=20 > > partitioning is a reason for that revocation mechanism to be in the=20 > > subject certificate rather than the issuer one=2C but why should that=20 > > precedent govern OCSP? A migration path to change this would start by= =20 > > recommending that an SIA value in the issuer certificate SHOULD take=20 > > precedence over an AIA value in the subject one if both values are=20 > > present. > >=20 > >=20 > > Tom Gindin > >=20 > >=20 > >=20 > >=20 > > From: "Henry B. Hotz" > > To: Stephen Kent =2C=20 > > Cc: pkix > > Date: 03/19/2012 04:26 PM > > Subject: Re: [pkix] Possible OCSP Extensions > > Sent by: pkix-bounces@ietf.org > >=20 > >=20 > >=20 > >=20 > > On Mar 19=2C 2012=2C at 8:42 AM=2C Stephen Kent wrote: > >=20 > >> At 12:01 PM -0700 3/16/12=2C Henry B. Hotz wrote: > >>> Suppose we accept both your arguments below=2C and Stephen Kent's=20 > > arguments that SCVP is the right solution for the real problem faced by= =20 > > ordinary users. > >>=20 > >> Steve Kent didn't say that. > >=20 > > OK=2C OK. I admit I'm stretching a point to try to find common ground. > >=20 > > I'm kind of disappointed by how acrimonious the discussions of this=20 > > feature (and on this list in general) have been. I'm guessing that is = why=20 > > we haven't heard from Tom Gundin=2C the guy who started this thread=2C = in a=20 > > while. > >=20 > >> He said that PKIX decided to develop SCVP instead of extending OCSP=2C= =20 > > when we lasted visited this sort of topic. In later messages I noted t= hat=20 > > folks did not except public CAs to operate SCVP servers=3B SCVP is best= =20 > > suited for enterprise environments. > >>=20 > >> Steve > >=20 > > ------------------------------------------------------ > > The opinions expressed in this message are mine=2C > > not those of Caltech=2C JPL=2C NASA=2C or the US Government. > > Henry.B.Hotz@jpl.nasa.gov=2C or hbhotz@oxy.edu > >=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 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_aa186c01-72c6-4038-8a55-6542fad7188a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: tmiller@mit= re.org
>=3B To: tgindin@us.ibm.com
>=3B Date: Tue=2C 20 Mar 2012 = 13:39:33 +0000
>=3B CC: pkix@ietf.org
>=3B Subject: Re: [pkix] Po= ssible OCSP Extensions
>=3B
>=3B So would this be a fair summary= of the range of possible responses?
>=3B
>=3B 1) A Responder wi= th no access to the CA history has only two possible responses:
>=3B <= br>>=3B REVOKED - Certificate identified by the Request is on a CRL.
= >=3B UNKNOWN - All other queries.
>=3B
>=3B 2) A Responder wi= th access to the CA history=2C if and only if certificate evidence is provi= ded in the Request=2C may also respond:
>=3B
>=3B GOOD - An exa= ct match for the certificate in the Request is found in the CA history=2C a= nd that certificate is not on a CRL.
>=3B
>=3B 3) A Responder wi= th access to the CA history=2C if and only if certificate *and chain* evide= nce is provided in the Request=2C may also respond:
>=3B
>=3B N= OTISSUED - The certificate in the Request chains to the cognizant CA but no= exact match for the certificate is found in the CA history.
>=3B
= >=3B "Certificate evidence" must be a sufficiently unique CertID. I'd wa= nt a cert thumbprint at the least=3B a copy of the cert itself at most. If= the Responder is operating as a Trusted Responder=2C the relying party won= 't be able to detect name collisions if only Issuer/Serial is used. CA-sig= ned and CA-Designated can detect name collisions because the queried cert w= on't chain to the same trust anchor as the OCSP Response signature=2C but t= hey have to be specifically directed to make this check.
>=3B
>= =3B "Certificate and chain evidence" will probably have to be the certifica= te itself=2C though if anyone has alternative ideas I'm all ears. IMHO thi= s is required for NOTISSUED because it's the only way to prevent a maliciou= s querent from messing up your day with falsified certificate evidence. A = query that doesn't match anything in the CA history is *not* enough evidenc= e of compromise unless it can be shown to be a cert that actually chains to= the cognizant CA.
>=3B =3B
Thanks for the comprehe= nsive coverage Tim. i don't think that you missed anything
 = =3B
Here are additional implications of blessing this concept in = any protocol
- CRLs and signature checking won't be enough to acc= ept a certificate. RFC 5280 would need to be changed
- CAs would = be required to publish a white list (for RPs who do not do OCSP or this new= protocol) and  =3BCRLs would become useless.  =3BThis probably req= uires change in X.509.
- Since the primary reason for deploying O= CSP is the pain associated with downloading and processing big CRLs=2C adop= tion of OCSP (or the new protocol) would increase even more because now we = would have even bigger white lists.
- While we are at it=2C we ca= n also recommend getting rid of signatures from x.509 certificates because = they won't be needed anymore. RPs just send the certificate without signatu= re(or its hash) to the CA=2C or look up the white list and figure out if it= was really blessed by the CA.

>=3B I think the above= is close to full coverage=2C but it's also a complete overhaul of OCSP. I= 'd call it a new protocol=2C though I don't know enough about SCVP to say w= hether or not this functions can be replicated with that protocol.
>= =3B
>=3B -- T
>=3B
>=3B
>=3B
>=3B
>=3B O= n Mar 20=2C 2012=2C at 7:24 AM=2C Tom Gindin wrote:
>=3B
>=3B &g= t=3B Actually=2C my lack of participation was more physical exhausti= on
>=3B >=3B than a result of the emotional temperature of the disc= ussions. There are
>=3B >=3B probably others who are more bothered= than me by that level=2C and if I
>=3B >=3B typically sent out my = initial draft responses I would probably contribute
>=3B >=3B to th= e problem. Given my limited practical experience with OCSP=2C I'm
>= =3B >=3B going to make some naive comments below=2C after starting with a= statement
>=3B >=3B of what I at least think needs to be resolved.=
>=3B >=3B One outstanding problem is that a client often can= not distinguish
>=3B >=3B "good" from merely "unrevoked"=2C or even= be aware that the responder is not
>=3B >=3B making such a distinc= tion. The other is for a client to provide evidence
>=3B >=3B that= a certificate is in circulation which is not expected to be by the
>= =3B >=3B responder. My other suggestion below about using the issuer's S= IA for
>=3B >=3B id-ad-ocsp is unrelated to these=2C and is intende= d to reduce the chances of
>=3B >=3B an attacker diverting the revo= cation check to a server under his own
>=3B >=3B controls.
>= =3B >=3B I do wonder what the point is to having OCSP support an "= unknown"
>=3B >=3B status code if it's appropriate for a responder = to return "good" on a
>=3B >=3B serial number that was never issued= . The natural meaning of the words
>=3B >=3B would suggest to me t= hat a CRL-only OCSP responder should call its two
>=3B >=3B status = values "revoked" and "unknown" rather than "revoked" and "good".
>=3B= >=3B One could probably argue that never using "good" is consistent with= the
>=3B >=3B literal wording of RFC 2560 section 2.2=2C but it ce= rtainly isn't the common
>=3B >=3B practice. Thus I consider that = the current "good" status would mean more
>=3B >=3B to high-relianc= e RP's if it were accompanied by an extension telling the
>=3B >=3B= client whether "good" includes "unknown" or not. That's not exactly
&= gt=3B >=3B Denis' position=2C but it's close to it.
>=3B >=3B = Next=2C I am surprised that the reporting extension in which a
>= =3B >=3B client can provide evidence of a certificate's actual existence = has drawn
>=3B >=3B little comment. I would think that=2C in conju= nction with either "unknown"
>=3B >=3B or "neverIssued"=2C that ext= ension allows a client to report a possible
>=3B >=3B issuer breach= inside the protocol. In particular=2C I think that it answers
>=3B = >=3B Dave Cooper's objection of Friday=2C because a major point to this s= et of
>=3B >=3B proposed changes is to permit a client to test his = suspicion of a
>=3B >=3B compromise. It's perfectly true that a cl= ient who's inside a DNS
>=3B >=3B masquerade environment will gain = little from unsigned OCSP responses of
>=3B >=3B any type. While u= sing an OCSP URL with an IP address would avoid the DNS
>=3B >=3B m= asquerade=2C no attacker's subject certificate will create such a value >=3B >=3B (although RA compromises would probably not change the AIA e= xtension in
>=3B >=3B most CA's).
>=3B >=3B Last=2C I= am not sure why it's a good thing that id-ad-ocsp is
>=3B >=3B rec= ommended to be placed into the subject certificate's AIA extension
>= =3B >=3B rather than into the issuer's SIA. I realize that this provides= greater
>=3B >=3B flexibility for an issuer to change its practice= s over time=2C but letting
>=3B >=3B an attacker redirect OCSP URL'= s is a bad thing (and Santosh is right that
>=3B >=3B it's far too = easy=2C although not about Phill's analytic skills). CRLDP
>=3B >= =3B partitioning is a reason for that revocation mechanism to be in the >=3B >=3B subject certificate rather than the issuer one=2C but why sh= ould that
>=3B >=3B precedent govern OCSP? A migration path to cha= nge this would start by
>=3B >=3B recommending that an SIA value in= the issuer certificate SHOULD take
>=3B >=3B precedence over an AI= A value in the subject one if both values are
>=3B >=3B present.>=3B >=3B
>=3B >=3B
>=3B >=3B Tom Gindin
>=3B >= =3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B= From: "Henry B. Hotz" <=3Bhotz@jpl.nasa.gov>=3B
>=3B >=3B To:= Stephen Kent <=3Bkent@bbn.com>=3B=2C
>=3B >=3B Cc: pki= x <=3Bpkix@ietf.org>=3B
>=3B >=3B Date: 03/19/2012 04:26 PM>=3B >=3B Subject: Re: [pkix] Possible OCSP Extensions
>= =3B >=3B Sent by: pkix-bounces@ietf.org
>=3B >=3B
>= =3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B On Mar 19= =2C 2012=2C at 8:42 AM=2C Stephen Kent wrote:
>=3B >=3B
>=3B &= gt=3B>=3B At 12:01 PM -0700 3/16/12=2C Henry B. Hotz wrote:
>=3B >= =3B>=3B>=3B Suppose we accept both your arguments below=2C and Stephen = Kent's
>=3B >=3B arguments that SCVP is the right solution for the = real problem faced by
>=3B >=3B ordinary users.
>=3B >=3B>= =3B
>=3B >=3B>=3B Steve Kent didn't say that.
>=3B >=3B >=3B >=3B OK=2C OK. I admit I'm stretching a point to try to find co= mmon ground.
>=3B >=3B
>=3B >=3B I'm kind of disappointed by= how acrimonious the discussions of this
>=3B >=3B feature (and on = this list in general) have been. I'm guessing that is why
>=3B >= =3B we haven't heard from Tom Gundin=2C the guy who started this thread=2C = in a
>=3B >=3B while.
>=3B >=3B
>=3B >=3B>=3B He s= aid that PKIX decided to develop SCVP instead of extending OCSP=2C
>= =3B >=3B when we lasted visited this sort of topic. In later messages I = noted that
>=3B >=3B folks did not except public CAs to operate SCV= P servers=3B SCVP is best
>=3B >=3B suited for enterprise environme= nts.
>=3B >=3B>=3B
>=3B >=3B>=3B Steve
>=3B >=3B =
>=3B >=3B ------------------------------------------------------>=3B >=3B The opinions expressed in this message are mine=2C
>=3B= >=3B not those of Caltech=2C JPL=2C NASA=2C or the US Government.
>= =3B >=3B Henry.B.Hotz@jpl.nasa.gov=2C or hbhotz@oxy.edu
>=3B >=3B =
>=3B >=3B _______________________________________________
>=3B= >=3B pkix mailing list
>=3B >=3B pkix@ietf.org
>=3B >=3B h= ttps://www.ietf.org/mailman/listinfo/pkix
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B >=3B ___________________________________= ____________
>=3B >=3B pkix mailing list
>=3B >=3B pkix@ietf.= org
>=3B >=3B https://www.ietf.org/mailman/listinfo/pkix
>=3B <= br>>=3B _______________________________________________
>=3B pkix ma= iling list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/l= istinfo/pkix
= --_aa186c01-72c6-4038-8a55-6542fad7188a_-- From tmiller@mitre.org Tue Mar 20 08:47:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F379121F8514 for ; Tue, 20 Mar 2012 08:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC7kYNuWik0j for ; Tue, 20 Mar 2012 08:47:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A48E21F84C5 for ; Tue, 20 Mar 2012 08:47:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E007821B079E; Tue, 20 Mar 2012 11:47:04 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C255121B077A; Tue, 20 Mar 2012 11:47:04 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 11:47:04 -0400 From: "Miller, Timothy J." To: Piyush Jain Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgA== Date: Tue, 20 Mar 2012 15:47:04 +0000 Message-ID: <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> References: , , , , , , , <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 15:47:07 -0000 Brennan's reply got me thinking, and I think this is a better way of attack= ing the issue from the ground up: We assume: -- The Responder MUST have a copy of the certificate. -- The Responder MUST have access to the CA history. There are three binary states of interest: -- Cert was signed (or not) by the cognizant CA (S, or notS) -- Cert was recorded (or not) by the cognizant CA (H, or notH) (H for histo= ry) -- Cert was revoked (or not) by the cognizant CA (R, or notR) This yields 8 distinct cases (2^3). I can reduce this to four response cas= es like so: -- Any case of (notS) is always a response of UNKNOWN. =20 -- Any case of (S && notH) is NOTISSUED. =20 -- (S && H && R) is REVOKED. -- (S && H && notR) is GOOD.=20 Thus, UNKNOWN means "not signed by the cognizant CA," NOTISSUED means "sign= ed but not recorded by the cognizant CA, may be fraudulent," and GOOD means= "signed, recorded and not revoked by the cognizant CA." REVOKED means wha= t it always meant, but is now stronger because name collisions are eliminat= ed. =20 Implementations should be guided to treat both REVOKED and NOTISSUED as a h= ard failure, and to seek additional sources for UNKNOWNs. Working backward from the above definition to the current OCSP: If the Responder does not have access to the CA history, then GOOD and NOTI= SSUED cannot be sent as a response to a query. Therefore the meaning of UN= KNOWN changes to mean "not issued or not recorded by the cognizant CA". Th= e Responder MUST signal this state to the client, and the client implementa= tion MUST be cautioned not to treat this response as a hard failure. If the Responder does not have access to the query certificate, then the Re= sponder MUST assume that the S is true, but this means that UNKNOWN now mea= ns "not revoked by the cognizant CA". The Responder MUST signal this state= to the client, and implementations MUST be cautioned not to treat this res= ponse as a hard failure. -- T On Mar 20, 2012, at 10:01 AM, Piyush Jain wrote: >=20 >=20 > > From: tmiller@mitre.org > > To: tgindin@us.ibm.com > > Date: Tue, 20 Mar 2012 13:39:33 +0000 > > CC: pkix@ietf.org > > Subject: Re: [pkix] Possible OCSP Extensions > >=20 > > So would this be a fair summary of the range of possible responses? > >=20 > > 1) A Responder with no access to the CA history has only two possible r= esponses: > >=20 > > REVOKED - Certificate identified by the Request is on a CRL. > > UNKNOWN - All other queries. > >=20 > > 2) A Responder with access to the CA history, if and only if certificat= e evidence is provided in the Request, may also respond: > >=20 > > GOOD - An exact match for the certificate in the Request is found in th= e CA history, and that certificate is not on a CRL. > >=20 > > 3) A Responder with access to the CA history, if and only if certificat= e *and chain* evidence is provided in the Request, may also respond: > >=20 > > NOTISSUED - The certificate in the Request chains to the cognizant CA b= ut no exact match for the certificate is found in the CA history. > >=20 > > "Certificate evidence" must be a sufficiently unique CertID. I'd want a= cert thumbprint at the least; a copy of the cert itself at most. If the Re= sponder is operating as a Trusted Responder, the relying party won't be abl= e to detect name collisions if only Issuer/Serial is used. CA-signed and CA= -Designated can detect name collisions because the queried cert won't chain= to the same trust anchor as the OCSP Response signature, but they have to = be specifically directed to make this check. > >=20 > > "Certificate and chain evidence" will probably have to be the certifica= te itself, though if anyone has alternative ideas I'm all ears. IMHO this i= s required for NOTISSUED because it's the only way to prevent a malicious q= uerent from messing up your day with falsified certificate evidence. A quer= y that doesn't match anything in the CA history is *not* enough evidence of= compromise unless it can be shown to be a cert that actually chains to the= cognizant CA. > >=20 > Thanks for the comprehensive coverage Tim. i don't think that you missed = anything > =20 > Here are additional implications of blessing this concept in any protocol > - CRLs and signature checking won't be enough to accept a certificate. RF= C 5280 would need to be changed > - CAs would be required to publish a white list (for RPs who do not do OC= SP or this new protocol) and CRLs would become useless. This probably req= uires change in X.509. > - Since the primary reason for deploying OCSP is the pain associated with= downloading and processing big CRLs, adoption of OCSP (or the new protocol= ) would increase even more because now we would have even bigger white list= s. > - While we are at it, we can also recommend getting rid of signatures fro= m x.509 certificates because they won't be needed anymore. RPs just send th= e certificate without signature(or its hash) to the CA, or look up the whit= e list and figure out if it was really blessed by the CA. >=20 > > I think the above is close to full coverage, but it's also a complete o= verhaul of OCSP. I'd call it a new protocol, though I don't know enough abo= ut SCVP to say whether or not this functions can be replicated with that pr= otocol. > >=20 > > -- T > >=20 > >=20 > >=20 > >=20 > > On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote: > >=20 > > > Actually, my lack of participation was more physical exhaustion=20 > > > than a result of the emotional temperature of the discussions. There = are=20 > > > probably others who are more bothered than me by that level, and if I= =20 > > > typically sent out my initial draft responses I would probably contri= bute=20 > > > to the problem. Given my limited practical experience with OCSP, I'm= =20 > > > going to make some naive comments below, after starting with a statem= ent=20 > > > of what I at least think needs to be resolved. > > > One outstanding problem is that a client often cannot distinguish=20 > > > "good" from merely "unrevoked", or even be aware that the responder i= s not=20 > > > making such a distinction. The other is for a client to provide evide= nce=20 > > > that a certificate is in circulation which is not expected to be by t= he=20 > > > responder. My other suggestion below about using the issuer's SIA for= =20 > > > id-ad-ocsp is unrelated to these, and is intended to reduce the chanc= es of=20 > > > an attacker diverting the revocation check to a server under his own= =20 > > > controls.=20 > > > I do wonder what the point is to having OCSP support an "unknown"=20 > > > status code if it's appropriate for a responder to return "good" on a= =20 > > > serial number that was never issued. The natural meaning of the words= =20 > > > would suggest to me that a CRL-only OCSP responder should call its tw= o=20 > > > status values "revoked" and "unknown" rather than "revoked" and "good= ".=20 > > > One could probably argue that never using "good" is consistent with t= he=20 > > > literal wording of RFC 2560 section 2.2, but it certainly isn't the c= ommon=20 > > > practice. Thus I consider that the current "good" status would mean m= ore=20 > > > to high-reliance RP's if it were accompanied by an extension telling = the=20 > > > client whether "good" includes "unknown" or not. That's not exactly=20 > > > Denis' position, but it's close to it. > > > Next, I am surprised that the reporting extension in which a=20 > > > client can provide evidence of a certificate's actual existence has d= rawn=20 > > > little comment. I would think that, in conjunction with either "unkno= wn"=20 > > > or "neverIssued", that extension allows a client to report a possible= =20 > > > issuer breach inside the protocol. In particular, I think that it ans= wers=20 > > > Dave Cooper's objection of Friday, because a major point to this set = of=20 > > > proposed changes is to permit a client to test his suspicion of a=20 > > > compromise. It's perfectly true that a client who's inside a DNS=20 > > > masquerade environment will gain little from unsigned OCSP responses = of=20 > > > any type. While using an OCSP URL with an IP address would avoid the = DNS=20 > > > masquerade, no attacker's subject certificate will create such a valu= e=20 > > > (although RA compromises would probably not change the AIA extension = in=20 > > > most CA's). > > > Last, I am not sure why it's a good thing that id-ad-ocsp is=20 > > > recommended to be placed into the subject certificate's AIA extension= =20 > > > rather than into the issuer's SIA. I realize that this provides great= er=20 > > > flexibility for an issuer to change its practices over time, but lett= ing=20 > > > an attacker redirect OCSP URL's is a bad thing (and Santosh is right = that=20 > > > it's far too easy, although not about Phill's analytic skills). CRLDP= =20 > > > partitioning is a reason for that revocation mechanism to be in the=20 > > > subject certificate rather than the issuer one, but why should that=20 > > > precedent govern OCSP? A migration path to change this would start by= =20 > > > recommending that an SIA value in the issuer certificate SHOULD take= =20 > > > precedence over an AIA value in the subject one if both values are=20 > > > present. > > >=20 > > >=20 > > > Tom Gindin > > >=20 > > >=20 > > >=20 > > >=20 > > > From: "Henry B. Hotz" > > > To: Stephen Kent ,=20 > > > Cc: pkix > > > Date: 03/19/2012 04:26 PM > > > Subject: Re: [pkix] Possible OCSP Extensions > > > Sent by: pkix-bounces@ietf.org > > >=20 > > >=20 > > >=20 > > >=20 > > > On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: > > >=20 > > >> At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: > > >>> Suppose we accept both your arguments below, and Stephen Kent's=20 > > > arguments that SCVP is the right solution for the real problem faced = by=20 > > > ordinary users. > > >>=20 > > >> Steve Kent didn't say that. > > >=20 > > > OK, OK. I admit I'm stretching a point to try to find common ground. > > >=20 > > > I'm kind of disappointed by how acrimonious the discussions of this=20 > > > feature (and on this list in general) have been. I'm guessing that is= why=20 > > > we haven't heard from Tom Gundin, the guy who started this thread, in= a=20 > > > while. > > >=20 > > >> He said that PKIX decided to develop SCVP instead of extending OCSP,= =20 > > > when we lasted visited this sort of topic. In later messages I noted = that=20 > > > folks did not except public CAs to operate SCVP servers; SCVP is best= =20 > > > suited for enterprise environments. > > >>=20 > > >> Steve > > >=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 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > pkix mailing list > > > pkix@ietf.org > > > https://www.ietf.org/mailman/listinfo/pkix > >=20 > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix From brennansecurity@gmail.com Tue Mar 20 09:10:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E552121F85DD for ; Tue, 20 Mar 2012 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65MsR1io-dPQ for ; Tue, 20 Mar 2012 09:10:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1787A21F85D5 for ; Tue, 20 Mar 2012 09:10:34 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so220783vcb.31 for ; Tue, 20 Mar 2012 09:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OvfA1aDUDyaYQLf1hVA3USyhRr6Ma8eGl0bKgBb5pTA=; b=1GFl+n428f4fGdkDFM++0mZCV6lesIkInSuxyYLMPUBJFEoaG3Rwck7YER1//7KFL8 qkJ5CJLLcWH8G8ie9COZ2i71vdZ8PMG9whSwassutAor3eRc2WriGa+PnumNxu04Hm5H 5AESx0qxIWPC5Ojoe2V9sksnd0tWgdWxPQiWRfiUN5AvvDxc9drDyMAvW43ffKRx0TeX uislP34fUGC/HiOxHs5gPMLwhDUThM3BE7umi1i5urh/YyWQTxbW/bgeqgs5bf1zKlFT GYz/844AJHxPv18aL+qM4SD8ZyI6e736elh0uDE5Vsi6OaHDV9p2LNEorhETY/58DGhD ovFA== MIME-Version: 1.0 Received: by 10.52.93.74 with SMTP id cs10mr175250vdb.42.1332259833142; Tue, 20 Mar 2012 09:10:33 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 09:10:32 -0700 (PDT) In-Reply-To: <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> Date: Tue, 20 Mar 2012 12:10:32 -0400 Message-ID: From: brennan security To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=bcaec50167391a5d3504bbaeea03 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 16:10:37 -0000 --bcaec50167391a5d3504bbaeea03 Content-Type: text/plain; charset=ISO-8859-1 Some questions Actual certificates on the responder, or just an information source (certificate, digest, other) ? CA history, or just an information source for good & bad (certificate, digest, other) ? Have you considered how resilient this is in the advent of CA/HSM compromise? How would this work in Direct Trust, CA designated and VA delegated trust relationships? Are you saying that NOTISSUED would trigger a security alarm? -b On Tue, Mar 20, 2012 at 11:47 AM, Miller, Timothy J. wrote: > Brennan's reply got me thinking, and I think this is a better way of attacking the issue from the ground up: > > We assume: > > -- The Responder MUST have a copy of the certificate. > -- The Responder MUST have access to the CA history. > > There are three binary states of interest: > > -- Cert was signed (or not) by the cognizant CA (S, or notS) > -- Cert was recorded (or not) by the cognizant CA (H, or notH) (H for history) > -- Cert was revoked (or not) by the cognizant CA (R, or notR) > > This yields 8 distinct cases (2^3). I can reduce this to four response cases like so: > > -- Any case of (notS) is always a response of UNKNOWN. > -- Any case of (S && notH) is NOTISSUED. > -- (S && H && R) is REVOKED. > -- (S && H && notR) is GOOD. > > Thus, UNKNOWN means "not signed by the cognizant CA," NOTISSUED means "signed but not recorded by the cognizant CA, may be fraudulent," and GOOD means "signed, recorded and not revoked by the cognizant CA." REVOKED means what it always meant, but is now stronger because name collisions are eliminated. > > Implementations should be guided to treat both REVOKED and NOTISSUED as a hard failure, and to seek additional sources for UNKNOWNs. > > Working backward from the above definition to the current OCSP: > > If the Responder does not have access to the CA history, then GOOD and NOTISSUED cannot be sent as a response to a query. Therefore the meaning of UNKNOWN changes to mean "not issued or not recorded by the cognizant CA". The Responder MUST signal this state to the client, and the client implementation MUST be cautioned not to treat this response as a hard failure. > > If the Responder does not have access to the query certificate, then the Responder MUST assume that the S is true, but this means that UNKNOWN now means "not revoked by the cognizant CA". The Responder MUST signal this state to the client, and implementations MUST be cautioned not to treat this response as a hard failure. > > -- T > > > On Mar 20, 2012, at 10:01 AM, Piyush Jain wrote: > >> >> >> > From: tmiller@mitre.org >> > To: tgindin@us.ibm.com >> > Date: Tue, 20 Mar 2012 13:39:33 +0000 >> > CC: pkix@ietf.org >> > Subject: Re: [pkix] Possible OCSP Extensions >> > >> > So would this be a fair summary of the range of possible responses? >> > >> > 1) A Responder with no access to the CA history has only two possible responses: >> > >> > REVOKED - Certificate identified by the Request is on a CRL. >> > UNKNOWN - All other queries. >> > >> > 2) A Responder with access to the CA history, if and only if certificate evidence is provided in the Request, may also respond: >> > >> > GOOD - An exact match for the certificate in the Request is found in the CA history, and that certificate is not on a CRL. >> > >> > 3) A Responder with access to the CA history, if and only if certificate *and chain* evidence is provided in the Request, may also respond: >> > >> > NOTISSUED - The certificate in the Request chains to the cognizant CA but no exact match for the certificate is found in the CA history. >> > >> > "Certificate evidence" must be a sufficiently unique CertID. I'd want a cert thumbprint at the least; a copy of the cert itself at most. If the Responder is operating as a Trusted Responder, the relying party won't be able to detect name collisions if only Issuer/Serial is used. CA-signed and CA-Designated can detect name collisions because the queried cert won't chain to the same trust anchor as the OCSP Response signature, but they have to be specifically directed to make this check. >> > >> > "Certificate and chain evidence" will probably have to be the certificate itself, though if anyone has alternative ideas I'm all ears. IMHO this is required for NOTISSUED because it's the only way to prevent a malicious querent from messing up your day with falsified certificate evidence. A query that doesn't match anything in the CA history is *not* enough evidence of compromise unless it can be shown to be a cert that actually chains to the cognizant CA. >> > >> Thanks for the comprehensive coverage Tim. i don't think that you missed anything >> >> Here are additional implications of blessing this concept in any protocol >> - CRLs and signature checking won't be enough to accept a certificate. RFC 5280 would need to be changed >> - CAs would be required to publish a white list (for RPs who do not do OCSP or this new protocol) and CRLs would become useless. This probably requires change in X.509. >> - Since the primary reason for deploying OCSP is the pain associated with downloading and processing big CRLs, adoption of OCSP (or the new protocol) would increase even more because now we would have even bigger white lists. >> - While we are at it, we can also recommend getting rid of signatures from x.509 certificates because they won't be needed anymore. RPs just send the certificate without signature(or its hash) to the CA, or look up the white list and figure out if it was really blessed by the CA. >> >> > I think the above is close to full coverage, but it's also a complete overhaul of OCSP. I'd call it a new protocol, though I don't know enough about SCVP to say whether or not this functions can be replicated with that protocol. >> > >> > -- T >> > >> > >> > >> > >> > On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote: >> > >> > > Actually, my lack of participation was more physical exhaustion >> > > than a result of the emotional temperature of the discussions. There are >> > > probably others who are more bothered than me by that level, and if I >> > > typically sent out my initial draft responses I would probably contribute >> > > to the problem. Given my limited practical experience with OCSP, I'm >> > > going to make some naive comments below, after starting with a statement >> > > of what I at least think needs to be resolved. >> > > One outstanding problem is that a client often cannot distinguish >> > > "good" from merely "unrevoked", or even be aware that the responder is not >> > > making such a distinction. The other is for a client to provide evidence >> > > that a certificate is in circulation which is not expected to be by the >> > > responder. My other suggestion below about using the issuer's SIA for >> > > id-ad-ocsp is unrelated to these, and is intended to reduce the chances of >> > > an attacker diverting the revocation check to a server under his own >> > > controls. >> > > I do wonder what the point is to having OCSP support an "unknown" >> > > status code if it's appropriate for a responder to return "good" on a >> > > serial number that was never issued. The natural meaning of the words >> > > would suggest to me that a CRL-only OCSP responder should call its two >> > > status values "revoked" and "unknown" rather than "revoked" and "good". >> > > One could probably argue that never using "good" is consistent with the >> > > literal wording of RFC 2560 section 2.2, but it certainly isn't the common >> > > practice. Thus I consider that the current "good" status would mean more >> > > to high-reliance RP's if it were accompanied by an extension telling the >> > > client whether "good" includes "unknown" or not. That's not exactly >> > > Denis' position, but it's close to it. >> > > Next, I am surprised that the reporting extension in which a >> > > client can provide evidence of a certificate's actual existence has drawn >> > > little comment. I would think that, in conjunction with either "unknown" >> > > or "neverIssued", that extension allows a client to report a possible >> > > issuer breach inside the protocol. In particular, I think that it answers >> > > Dave Cooper's objection of Friday, because a major point to this set of >> > > proposed changes is to permit a client to test his suspicion of a >> > > compromise. It's perfectly true that a client who's inside a DNS >> > > masquerade environment will gain little from unsigned OCSP responses of >> > > any type. While using an OCSP URL with an IP address would avoid the DNS >> > > masquerade, no attacker's subject certificate will create such a value >> > > (although RA compromises would probably not change the AIA extension in >> > > most CA's). >> > > Last, I am not sure why it's a good thing that id-ad-ocsp is >> > > recommended to be placed into the subject certificate's AIA extension >> > > rather than into the issuer's SIA. I realize that this provides greater >> > > flexibility for an issuer to change its practices over time, but letting >> > > an attacker redirect OCSP URL's is a bad thing (and Santosh is right that >> > > it's far too easy, although not about Phill's analytic skills). CRLDP >> > > partitioning is a reason for that revocation mechanism to be in the >> > > subject certificate rather than the issuer one, but why should that >> > > precedent govern OCSP? A migration path to change this would start by >> > > recommending that an SIA value in the issuer certificate SHOULD take >> > > precedence over an AIA value in the subject one if both values are >> > > present. >> > > >> > > >> > > Tom Gindin >> > > >> > > >> > > >> > > >> > > From: "Henry B. Hotz" >> > > To: Stephen Kent , >> > > Cc: pkix >> > > Date: 03/19/2012 04:26 PM >> > > Subject: Re: [pkix] Possible OCSP Extensions >> > > Sent by: pkix-bounces@ietf.org >> > > >> > > >> > > >> > > >> > > On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: >> > > >> > >> At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >> > >>> Suppose we accept both your arguments below, and Stephen Kent's >> > > arguments that SCVP is the right solution for the real problem faced by >> > > ordinary users. >> > >> >> > >> Steve Kent didn't say that. >> > > >> > > OK, OK. I admit I'm stretching a point to try to find common ground. >> > > >> > > I'm kind of disappointed by how acrimonious the discussions of this >> > > feature (and on this list in general) have been. I'm guessing that is why >> > > we haven't heard from Tom Gundin, the guy who started this thread, in a >> > > while. >> > > >> > >> He said that PKIX decided to develop SCVP instead of extending OCSP, >> > > when we lasted visited this sort of topic. In later messages I noted that >> > > folks did not except public CAs to operate SCVP servers; SCVP is best >> > > suited for enterprise environments. >> > >> >> > >> Steve >> > > >> > > ------------------------------------------------------ >> > > 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 >> > > >> > > _______________________________________________ >> > > 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 --bcaec50167391a5d3504bbaeea03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some questions

Actual certificates on the res= ponder, or just an information source (certificate, digest, other) ?
<= div>
CA history, or just an information source for good &= bad=A0 (certificate, digest, other) ?

Have you considered how resilient this is in the = advent of CA/HSM compromise?

How would this work i= n Direct Trust, CA designated and VA delegated trust relationships?

Are you saying that NOTISSUED would trigger a security = alarm?

-b

On Tue, Mar 20,= 2012 at 11:47 AM, Miller, Timothy J. <tmiller@mitre.org> wrote:
> Brennan's reply got me thinking, and I think this is a better= way of attacking the issue from the ground up:
>
&g= t; We assume:
>
> -- The Responder MUST have a co= py of the certificate.
> -- The Responder MUST have access to the CA history.
&g= t;
> There are three binary states of interest:
>=
> -- Cert was signed (or not) by the cognizant CA (S, or notS= )
> -- Cert was recorded (or not) by the cognizant CA (H, or notH) (H= for history)
> -- Cert was revoked (or not) by the cognizant = CA (R, or notR)
>
> This yields 8 distinct cases = (2^3). =A0I can reduce this to four response cases like so:
>
> -- Any case of (notS) is always a response of UNKN= OWN.
> -- Any case of (S && notH) is NOTISSUED.
<= div>> -- (S && H && R) is REVOKED.
> -- (S = && H && notR) is GOOD.
>
> Thus, UNKNOWN means "not signed by the cogniz= ant CA," NOTISSUED means "signed but not recorded by the cognizan= t CA, may be fraudulent," and GOOD means "signed, recorded and no= t revoked by the cognizant CA." =A0REVOKED means what it always meant,= but is now stronger because name collisions are eliminated.
>
> Implementations should be guided to treat both REV= OKED and NOTISSUED as a hard failure, and to seek additional sources for UN= KNOWNs.
>
> Working backward from the above defin= ition to the current OCSP:
>
> If the Responder does not have access to the CA hi= story, then GOOD and NOTISSUED cannot be sent as a response to a query. =A0= Therefore the meaning of UNKNOWN changes to mean "not issued or not re= corded by the cognizant CA". =A0The Responder MUST signal this state t= o the client, and the client implementation MUST be cautioned not to treat = this response as a hard failure.
>
> If the Responder does not have access to the query= certificate, then the Responder MUST assume that the S is true, but this m= eans that UNKNOWN now means "not revoked by the cognizant CA". = =A0The Responder MUST signal this state to the client, and implementations = MUST be cautioned not to treat this response as a hard failure.
>
> -- T
>
>
> = On Mar 20, 2012, at 10:01 AM, Piyush Jain wrote:
>
&= gt;>
>>
>> > Date: Tue, 20 Mar 2012 13:39:33 +0000
>> > CC: pkix@ietf.org<= /div>
>> > Subject: Re: [pkix] Possible OCSP Extensions
&= gt;> >
>> > So would this be a fair summary of the= range of possible responses?
>> >
>> &g= t; 1) A Responder with no access to the CA history has only two possible re= sponses:
>> >
>> > REVOKED - Certificate identified= by the Request is on a CRL.
>> > UNKNOWN - All other qu= eries.
>> >
>> > 2) A Responder with = access to the CA history, if and only if certificate evidence is provided i= n the Request, may also respond:
>> >
>> > GOOD - An exact match for the ce= rtificate in the Request is found in the CA history, and that certificate i= s not on a CRL.
>> >
>> > 3) A Respon= der with access to the CA history, if and only if certificate *and chain* e= vidence is provided in the Request, may also respond:
>> >
>> > NOTISSUED - The certificate in t= he Request chains to the cognizant CA but no exact match for the certificat= e is found in the CA history.
>> >
>> &g= t; "Certificate evidence" must be a sufficiently unique CertID. I= 'd want a cert thumbprint at the least; a copy of the cert itself at mo= st. If the Responder is operating as a Trusted Responder, the relying party= won't be able to detect name collisions if only Issuer/Serial is used.= CA-signed and CA-Designated can detect name collisions because the queried= cert won't chain to the same trust anchor as the OCSP Response signatu= re, but they have to be specifically directed to make this check.
>> >
>> > "Certificate and chain evid= ence" will probably have to be the certificate itself, though if anyon= e has alternative ideas I'm all ears. IMHO this is required for NOTISSU= ED because it's the only way to prevent a malicious querent from messin= g up your day with falsified certificate evidence. A query that doesn't= match anything in the CA history is *not* enough evidence of compromise un= less it can be shown to be a cert that actually chains to the cognizant CA.=
>> >
>> Thanks for the comprehensive coverage= Tim. i don't think that you missed anything
>>
>> Here are additional implications of blessing this concept in an= y protocol
>> - CRLs and signature checking won't be enough to accept a= certificate. RFC 5280 would need to be changed
>> - CAs wo= uld be required to publish a white list (for RPs who do not do OCSP or this= new protocol) and =A0CRLs would become useless. =A0This probably requires = change in X.509.
>> - Since the primary reason for deploying OCSP is the pain ass= ociated with downloading and processing big CRLs, adoption of OCSP (or the = new protocol) would increase even more because now we would have even bigge= r white lists.
>> - While we are at it, we can also recommend getting rid of si= gnatures from x.509 certificates because they won't be needed anymore. = RPs just send the certificate without signature(or its hash) to the CA, or = look up the white list and figure out if it was really blessed by the CA.
>>
>> > I think the above is close to full co= verage, but it's also a complete overhaul of OCSP. I'd call it a ne= w protocol, though I don't know enough about SCVP to say whether or not= this functions can be replicated with that protocol.
>> >
>> > -- T
>> >
>> >
>> >
>> >
<= div>>> > On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote:
>> >
>> > > Actually, my lack of participati= on was more physical exhaustion
>> > > than a result = of the emotional temperature of the discussions. There are
>&g= t; > > probably others who are more bothered than me by that level, a= nd if I
>> > > typically sent out my initial draft responses I wou= ld probably contribute
>> > > to the problem. Given m= y limited practical experience with OCSP, I'm
>> > &= gt; going to make some naive comments below, after starting with a statemen= t
>> > > of what I at least think needs to be resolved.
>> > > One outstanding problem is that a client often can= not distinguish
>> > > "good" from merely &= quot;unrevoked", or even be aware that the responder is not
>> > > making such a distinction. The other is for a clien= t to provide evidence
>> > > that a certificate is in= circulation which is not expected to be by the
>> > >= ; responder. My other suggestion below about using the issuer's SIA for=
>> > > id-ad-ocsp is unrelated to these, and is intended t= o reduce the chances of
>> > > an attacker diverting = the revocation check to a server under his own
>> > >= controls.
>> > > I do wonder what the point is to having OCSP suppor= t an "unknown"
>> > > status code if it'= ;s appropriate for a responder to return "good" on a
>> > > serial number that was never issued. The natural meaning= of the words
>> > > would suggest to me that a CRL-o= nly OCSP responder should call its two
>> > > status = values "revoked" and "unknown" rather than "revoke= d" and "good".
>> > > One could probably argue that never using "goo= d" is consistent with the
>> > > literal wording= of RFC 2560 section 2.2, but it certainly isn't the common
>> > > practice. Thus I consider that the current "good&qu= ot; status would mean more
>> > > to high-reliance RP= 's if it were accompanied by an extension telling the
>>= ; > > client whether "good" includes "unknown" or= not. That's not exactly
>> > > Denis' position, but it's close to it.
>> > > Next, I am surprised that the reporting extension = in which a
>> > > client can provide evidence of a ce= rtificate's actual existence has drawn
>> > > little comment. I would think that, in conjunction = with either "unknown"
>> > > or "never= Issued", that extension allows a client to report a possible
>> > > issuer breach inside the protocol. In particular, I= think that it answers
>> > > Dave Cooper's objec= tion of Friday, because a major point to this set of
>> >= ; > proposed changes is to permit a client to test his suspicion of a
>> > > compromise. It's perfectly true that a client w= ho's inside a DNS
>> > > masquerade environment w= ill gain little from unsigned OCSP responses of
>> > >= ; any type. While using an OCSP URL with an IP address would avoid the DNS<= /div>
>> > > masquerade, no attacker's subject certificate w= ill create such a value
>> > > (although RA compromis= es would probably not change the AIA extension in
>> > &= gt; most CA's).
>> > > Last, I am not sure why it's a good thing that = id-ad-ocsp is
>> > > recommended to be placed into th= e subject certificate's AIA extension
>> > > rath= er than into the issuer's SIA. I realize that this provides greater
>> > > flexibility for an issuer to change its practices o= ver time, but letting
>> > > an attacker redirect OCS= P URL's is a bad thing (and Santosh is right that
>> &g= t; > it's far too easy, although not about Phill's analytic skil= ls). CRLDP
>> > > partitioning is a reason for that revocation mechan= ism to be in the
>> > > subject certificate rather th= an the issuer one, but why should that
>> > > precede= nt govern OCSP? A migration path to change this would start by
>> > > recommending that an SIA value in the issuer certif= icate SHOULD take
>> > > precedence over an AIA value= in the subject one if both values are
>> > > present= .
>> > >
>> > >
>> >= ; > Tom Gindin
>> > >
>> > >=
>> > >
>> > >
>&g= t; > > From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
>> > > To: Stephen Kent <kent@bbn.com>,
>> > > Cc: pkix <pkix@ietf.org>
>> > >= ; Date: 03/19/2012 04:26 PM
>> > > Subject: Re: [pkix] Possible OCSP Extensions
<= div>>> > > Sent by: pk= ix-bounces@ietf.org
>> > >
>> >= ; >
>> > >
>> > >
>> >= ; > On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote:
>> = > >
>> > >> At 12:01 PM -0700 3/16/12, Henry= B. Hotz wrote:
>> > >>> Suppose we accept both your arguments below= , and Stephen Kent's
>> > > arguments that SCVP i= s the right solution for the real problem faced by
>> > = > ordinary users.
>> > >>
>> > >> Steve Kent did= n't say that.
>> > >
>> > >= OK, OK. I admit I'm stretching a point to try to find common ground.
>> > >
>> > > I'm kind of disapp= ointed by how acrimonious the discussions of this
>> > &= gt; feature (and on this list in general) have been. I'm guessing that = is why
>> > > we haven't heard from Tom Gundin, the guy who s= tarted this thread, in a
>> > > while.
>= > > >
>> > >> He said that PKIX decided t= o develop SCVP instead of extending OCSP,
>> > > when we lasted visited this sort of topic. In later= messages I noted that
>> > > folks did not except pu= blic CAs to operate SCVP servers; SCVP is best
>> > >= suited for enterprise environments.
>> > >>
>> > >> Steve
>> > >
>> > > -------------------------= -----------------------------
>> > > The opinions exp= ressed in this message are mine,
>> > > not those of Caltech, JPL, NASA, or the US Governme= nt.
>> > >
>> > > ______________________= _________________________
>> > > pkix mailing list
>> > = >
>> > >
>> > >
>> > > _______________________________________________
>> > > pkix mailing list
>> > > https://www.ietf.org/m= ailman/listinfo/pkix
>> >
>> > ________________________________= _______________
>> > pkix mailing list
>
> _______________________________________________
> pkix mailing list


--bcaec50167391a5d3504bbaeea03-- From tmiller@mitre.org Tue Mar 20 09:31:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359C621F86B5 for ; Tue, 20 Mar 2012 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJbXfjVVgDgH for ; Tue, 20 Mar 2012 09:31:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B121F86DA for ; Tue, 20 Mar 2012 09:31:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F1DA21B07F1; Tue, 20 Mar 2012 12:31:21 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3EB0621B0857; Tue, 20 Mar 2012 12:31:21 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 12:31:21 -0400 From: "Miller, Timothy J." To: brennan security Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAFzwA= Date: Tue, 20 Mar 2012 16:31:20 +0000 Message-ID: <5B01681C-296A-4D6D-B4F6-DD4418902524@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8669536FB2FB024DADD6882E4851106D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 16:31:23 -0000 On Mar 20, 2012, at 11:10 AM, brennan security wrote: > Actual certificates on the responder, or just an information source (cert= ificate, digest, other) ? I think it needs to be actual certificates in the request to work in the co= mplete case. Less than the full cert means the Responder can't eliminate n= amespace collisions, or can't guarantee the cert belongs to the cognizant C= A. E.g., if client is asking the Responder for CA A about a cert from CA B= ; given only the hash, the Responder can't tell the cert was issued by B. = NOTISSUED would not be a proper response because the Responder can't actual= ly make the decision; only UNKNOWN is appropriate here. =20 The reduced cases with changed response code semantics cover the case where= the client doesn't provide the cert. > CA history, or just an information source for good & bad (certificate, d= igest, other) ? Irrelevant. If a CA Designated Responder has direct access to the CA datab= ase or simply a query mechanism doesn't matter to the client. "CA" in this= case should be taken to mean the complete trusted infrastructure that comp= oses the CA and it's constituent services and personnel, not the just the b= ox that creates signatures. :) > Have you considered how resilient this is in the advent of CA/HSM comprom= ise? I'm working on the fly here, so don't take my work so far as a fully worked= proposal. But given what Philip has been asking for this is the only way= I see to deliver even a portion of what he wants. =20 That said, if the CA is compromised such that the *history* is invalid, NOT= ISSUED loses all meaning. Similarly, compromise of the CA signing key mean= s GOOD and REVOKED lose all meaning. Compromise of the Responder signing = key means *all* responses lose their meaning, but you'd never know it. :) There is a corner case where the CA history is trusted, the Responder signi= ng key is trusted, but the CA signing key is not. In this case, NOTISSUED = can signal a compromise. This is the corner case I think Philip is after. > How would this work in Direct Trust, CA designated and VA delegated trust= relationships? I think OCSP trust model is orthogonal to the concept I give, if my assumpt= ions are preserved. =20 > Are you saying that NOTISSUED would trigger a security alarm? In the corner case above, yes. I'm personally not convinced this would happen in practice. -- T From tmiller@mitre.org Tue Mar 20 09:44:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4890221F85CF for ; Tue, 20 Mar 2012 09:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHGNPFqAdzcH for ; Tue, 20 Mar 2012 09:44:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4121F85D5 for ; Tue, 20 Mar 2012 09:44:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F48821B13DC; Tue, 20 Mar 2012 12:44:51 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8462221B082A; Tue, 20 Mar 2012 12:44:51 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 12:44:51 -0400 From: "Miller, Timothy J." To: brennan security Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQA= Date: Tue, 20 Mar 2012 16:44:50 +0000 Message-ID: <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <163194BACD62B34291BDA636975BC27A@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 16:44:53 -0000 On Mar 20, 2012, at 11:10 AM, brennan security wrote: > Actual certificates on the responder, or just an information source (cert= ificate, digest, other) ? To reflection, the current 2560 CertID is not enough to determine whether t= he cert was recorded or not. Recall: CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } In the case where a fraudulent certificate is issued under an valid certifi= cate serial number, this CertID would result in an incorrect match, and GOO= D would be sent as the response. In contrast, if we have the subject key-= -or a more specific subject key identifier--then the cert would *not* match= , and NOTISSUED would result. Adding subjectKeyHash OCTET STRING, -- Hash of Subject public key to CertID would probably suffice. =20 So I'll retract the "I want to see the whole cert" part. Chalk it up to ex= cessive paranoia. My gut feels better if the OCSP service actually validat= es the certificate signature, but if we assume a halfway competent client t= his is redundant (and if the client is less than halfway competent, the OCS= P response probably doesn't matter anyway :). -- T From SChokhani@cygnacom.com Tue Mar 20 09:51:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40E21F86FC for ; Tue, 20 Mar 2012 09:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FYWxsIWaukh for ; Tue, 20 Mar 2012 09:51:51 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id E441D21F8721 for ; Tue, 20 Mar 2012 09:51:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,619,1325480400"; d="scan'208";a="4449901" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 20 Mar 2012 12:51:42 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 20 Mar 2012 12:51:42 -0400 From: Santosh Chokhani To: "Miller, Timothy J." , brennan security Date: Tue, 20 Mar 2012 12:51:40 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQD//75OkA== Message-ID: References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org> In-Reply-To: <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 16:51:52 -0000 If you are talking about certificates, it is always better to have a certif= icate hash as opposed to public key hash. This comment should not be construed to mean my support for any of this. I= continue to be skeptical of the need for not issued in general and of rang= es when serial numbers are random or pseudo random. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J. Sent: Tuesday, March 20, 2012 12:45 PM To: brennan security Cc: Subject: Re: [pkix] Possible OCSP Extensions On Mar 20, 2012, at 11:10 AM, brennan security wrote: > Actual certificates on the responder, or just an information source (cert= ificate, digest, other) ? To reflection, the current 2560 CertID is not enough to determine whether t= he cert was recorded or not. Recall: CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } In the case where a fraudulent certificate is issued under an valid certifi= cate serial number, this CertID would result in an incorrect match, and GOO= D would be sent as the response. In contrast, if we have the subject key-= -or a more specific subject key identifier--then the cert would *not* match= , and NOTISSUED would result. Adding subjectKeyHash OCTET STRING, -- Hash of Subject public key to CertID would probably suffice. =20 So I'll retract the "I want to see the whole cert" part. Chalk it up to ex= cessive paranoia. My gut feels better if the OCSP service actually validat= es the certificate signature, but if we assume a halfway competent client t= his is redundant (and if the client is less than halfway competent, the OCS= P response probably doesn't matter anyway :). -- T _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From brennansecurity@gmail.com Tue Mar 20 09:56:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E07021F85CD for ; Tue, 20 Mar 2012 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElcoTc9dnfy3 for ; Tue, 20 Mar 2012 09:56:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D47B221F85A1 for ; Tue, 20 Mar 2012 09:56:34 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so274845vcb.31 for ; Tue, 20 Mar 2012 09:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DgHAN8k++IHhaN914XmSG+BFLm1UMBhAFbwehW1Yiuw=; b=furgg77JCanuaIw6OgT01JVgYZPsG20YjyZh4vai7dpc3281FinT3TTv0jnbimzkDl vKuevp1LLeoBjSeAmEkGGp8jBJRL703R/d7do81OaWHDGHFZkHuRAP3PoVIO0OWMFGKj omU0e5R0Z06bi0fT3ZkWotpbJSr3EOyqo/58bAhFfZglrZvensB26bgSuAz4ro5KtuF2 aGqwa9pQdH9Y/oQb0vY49JfEHDRGaD6SP10h52UUxjraLns/lK7C4dp0hdWC+u9yz9q1 QuoLqC3SgbEJYK9U1E/81R+y20XRyY+e9B55vyOA9xFZNmutNhagsuB/FzyxjMxvKwFU x1sQ== MIME-Version: 1.0 Received: by 10.220.108.10 with SMTP id d10mr287725vcp.16.1332262592429; Tue, 20 Mar 2012 09:56:32 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 09:56:32 -0700 (PDT) In-Reply-To: <5B01681C-296A-4D6D-B4F6-DD4418902524@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> <5B01681C-296A-4D6D-B4F6-DD4418902524@mitre.org> Date: Tue, 20 Mar 2012 12:56:32 -0400 Message-ID: From: brennan security To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=f46d043d645791bf7b04bbaf8e83 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 16:56:36 -0000 --f46d043d645791bf7b04bbaf8e83 Content-Type: text/plain; charset=ISO-8859-1 Tim, I'm not sure I concur on the actual certificate and I think it is a good subject for more analysis. For example http://tools.ietf.org/html/rfc5914might be a candidate and I am sure our team can come up with a comprehensive list of alternatives with respective pros and cons. For mobile RPs, this may be significant. CA delegated modes of VA are compromised with a CA compromised; CA Designated, VA delegated and direct trust are resistant to CA compromises, namely, they can revoke CA trust. (Preventing a CA from being a single point of failure, but adding complexity). -b On Tue, Mar 20, 2012 at 12:31 PM, Miller, Timothy J. wrote: > On Mar 20, 2012, at 11:10 AM, brennan security wrote: > > > Actual certificates on the responder, or just an information source > (certificate, digest, other) ? > > I think it needs to be actual certificates in the request to work in the > complete case. Less than the full cert means the Responder can't eliminate > namespace collisions, or can't guarantee the cert belongs to the cognizant > CA. E.g., if client is asking the Responder for CA A about a cert from CA > B; given only the hash, the Responder can't tell the cert was issued by B. > NOTISSUED would not be a proper response because the Responder can't > actually make the decision; only UNKNOWN is appropriate here. > > The reduced cases with changed response code semantics cover the case > where the client doesn't provide the cert. > > > CA history, or just an information source for good & bad (certificate, > digest, other) ? > > Irrelevant. If a CA Designated Responder has direct access to the CA > database or simply a query mechanism doesn't matter to the client. "CA" in > this case should be taken to mean the complete trusted infrastructure that > composes the CA and it's constituent services and personnel, not the just > the box that creates signatures. :) > > > Have you considered how resilient this is in the advent of CA/HSM > compromise? > > I'm working on the fly here, so don't take my work so far as a fully > worked proposal. But given what Philip has been asking for this is the > only way I see to deliver even a portion of what he wants. > > That said, if the CA is compromised such that the *history* is invalid, > NOTISSUED loses all meaning. Similarly, compromise of the CA signing key > means GOOD and REVOKED lose all meaning. Compromise of the Responder > signing key means *all* responses lose their meaning, but you'd never know > it. :) > > There is a corner case where the CA history is trusted, the Responder > signing key is trusted, but the CA signing key is not. In this case, > NOTISSUED can signal a compromise. This is the corner case I think Philip > is after. > > > How would this work in Direct Trust, CA designated and VA delegated > trust relationships? > > I think OCSP trust model is orthogonal to the concept I give, if my > assumptions are preserved. > > > Are you saying that NOTISSUED would trigger a security alarm? > > In the corner case above, yes. > > I'm personally not convinced this would happen in practice. > > -- T > > --f46d043d645791bf7b04bbaf8e83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tim,

I'm not sure I concur on the act= ual certificate and I think it is a good subject for more analysis. =A0For = example=A0 http://tools.ietf.org/html/r= fc5914 might be a candidate and I am sure our team can come up with a c= omprehensive list of alternatives with respective pros and cons. =A0For mob= ile RPs, this may be significant.

CA delegated modes of VA are compromised with a C= A compromised; CA Designated, VA delegated and direct trust are resistant t= o CA compromises, namely, they can revoke CA trust. (Preventing a CA from b= eing a single point of failure, but adding complexity).

-b



On Tue, Mar 20, 2012 at 12:31 PM, Miller, Timothy J. <tmiller@mitre.org>= ; wrote:
On Mar 20, 2012, at 11:10 = AM, brennan security wrote:

> Actual certificates on the responder, or just an information source (c= ertificate, digest, other) ?

I think it needs to be actual certificates in the request to work in = the complete case. =A0Less than the full cert means the Responder can't= eliminate namespace collisions, or can't guarantee the cert belongs to= the cognizant CA. =A0E.g., if client is asking the Responder for CA A abou= t a cert from CA B; given only the hash, the Responder can't tell the c= ert was issued by B. =A0NOTISSUED would not be a proper response because th= e Responder can't actually make the decision; only UNKNOWN is appropria= te here.

The reduced cases with changed response code semantics cover the case where= the client doesn't provide the cert.

> CA history, or just an information source for good & bad =A0(certi= ficate, digest, other) ?

Irrelevant. =A0If a CA Designated Responder has direct access to the = CA database or simply a query mechanism doesn't matter to the client. = =A0"CA" in this case should be taken to mean the complete trusted= infrastructure that composes the CA and it's constituent services and = personnel, not the just the box that creates signatures. =A0:)

> Have you considered how resilient this is in the advent of CA/HSM comp= romise?

I'm working on the fly here, so don't take my work so far as = a fully worked proposal. =A0 But given what Philip has been asking for this= is the only way I see to deliver even a portion of what he wants.

That said, if the CA is compromised such that the *history* is invalid, NOT= ISSUED loses all meaning. =A0Similarly, compromise of the CA signing key me= ans GOOD and REVOKED lose all meaning. =A0 Compromise of the Responder sign= ing key means *all* responses lose their meaning, but you'd never know = it. =A0:)

There is a corner case where the CA history is trusted, the Responder signi= ng key is trusted, but the CA signing key is not. =A0In this case, NOTISSUE= D can signal a compromise. =A0This is the corner case I think Philip is aft= er.

> How would this work in Direct Trust, CA designated and VA delegated tr= ust relationships?

I think OCSP trust model is orthogonal to the concept I give, if my a= ssumptions are preserved.

> Are you saying that NOTISSUED would trigger a security alarm?

In the corner case above, yes.

I'm personally not convinced this would happen in practice.

-- T


--f46d043d645791bf7b04bbaf8e83-- From piyush@identicate.com Tue Mar 20 10:00:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08521F85E0 for ; Tue, 20 Mar 2012 10:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5+SE5vC3WI2 for ; Tue, 20 Mar 2012 10:00:46 -0700 (PDT) Received: from col0-omc2-s6.col0.hotmail.com (col0-omc2-s6.col0.hotmail.com [65.55.34.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5CA621F85D8 for ; Tue, 20 Mar 2012 10:00:46 -0700 (PDT) Received: from COL119-W60 ([65.55.34.71]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 10:00:46 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f299781b-df03-45b0-add8-44961490afed_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Tue, 20 Mar 2012 10:00:46 -0700 Importance: Normal In-Reply-To: References: , , , , , , , <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org>, , <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org>, , <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2012 17:00:46.0494 (UTC) FILETIME=[FE5F13E0:01CD06BA] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 17:00:47 -0000 --_f299781b-df03-45b0-add8-44961490afed_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: SChokhani@cygnacom.com > To: tmiller@mitre.org=3B brennansecurity@gmail.com > Date: Tue=2C 20 Mar 2012 12:51:40 -0400 > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 > If you are talking about certificates=2C it is always better to have a ce= rtificate hash as opposed to public key hash.> > This comment should not be= construed to mean my support for any of this. I continue to be skeptical = of the need for not issued in general and of ranges when serial numbers are= random or pseudo random. I'm in agreement with your stand on not issued.However=2C I would apprecia= te your opinions on the options available to a responder for presigning fo= r CAs that use random or pseudo random serials=2C and your thoughts on why = ranges won't solve this problem. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= iller=2C Timothy J. > Sent: Tuesday=2C March 20=2C 2012 12:45 PM > To: brennan security > Cc: > Subject: Re: [pkix] Possible OCSP Extensions >=20 > On Mar 20=2C 2012=2C at 11:10 AM=2C brennan security wrote: >=20 > > Actual certificates on the responder=2C or just an information source (= certificate=2C digest=2C other) ? >=20 > To reflection=2C the current 2560 CertID is not enough to determine wheth= er the cert was recorded or not. Recall: >=20 > CertID ::=3D SEQUENCE { > hashAlgorithm AlgorithmIdentifier=2C > issuerNameHash OCTET STRING=2C -- Hash of Issuer's DN > issuerKeyHash OCTET STRING=2C -- Hash of Issuers public ke= y > serialNumber CertificateSerialNumber } >=20 > In the case where a fraudulent certificate is issued under an valid certi= ficate serial number=2C this CertID would result in an incorrect match=2C a= nd GOOD would be sent as the response. In contrast=2C if we have the subj= ect key--or a more specific subject key identifier--then the cert would *no= t* match=2C and NOTISSUED would result. >=20 > Adding >=20 > subjectKeyHash OCTET STRING=2C -- Hash of Subject public key >=20 > to CertID would probably suffice. =20 >=20 > So I'll retract the "I want to see the whole cert" part. Chalk it up to = excessive paranoia. My gut feels better if the OCSP service actually valid= ates the certificate signature=2C but if we assume a halfway competent clie= nt this is redundant (and if the client is less than halfway competent=2C t= he OCSP response probably doesn't matter anyway :). >=20 > -- T >=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 = --_f299781b-df03-45b0-add8-44961490afed_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: SChokhani@c= ygnacom.com
>=3B To: tmiller@mitre.org=3B brennansecurity@gmail.com>=3B Date: Tue=2C 20 Mar 2012 12:51:40 -0400
>=3B CC: pkix@ietf.org=
>=3B Subject: Re: [pkix] Possible OCSP Extensions
>=3B
>= =3B If you are talking about certificates=2C it is always better to have a = certificate hash as opposed to public key hash.
>=3B =3B
>=3B This comment shou= ld not be construed to mean my support for any of this. I continue to be s= keptical of the need for not issued in general and of ranges when serial nu= mbers are random or pseudo random.

I'm in  =3B= agreement with your stand on not issued.
However=2C I would appre= ciate your opinions on the options available to a  =3Bresponder for pre= signing for CAs that use random or pseudo random serials=2C and your though= ts on why ranges won't solve this problem.

>=3B
>=3B = -----Original Message-----
>=3B From: pkix-bounces@ietf.org [mailto:pk= ix-bounces@ietf.org] On Behalf Of Miller=2C Timothy J.
>=3B Sent: Tues= day=2C March 20=2C 2012 12:45 PM
>=3B To: brennan security
>=3B C= c: <=3Bpkix@ietf.org>=3B
>=3B Subject: Re: [pkix] Possible OCSP Ex= tensions
>=3B
>=3B On Mar 20=2C 2012=2C at 11:10 AM=2C brennan s= ecurity wrote:
>=3B
>=3B >=3B Actual certificates on the respo= nder=2C or just an information source (certificate=2C digest=2C other) ?>=3B
>=3B To reflection=2C the current 2560 CertID is not enough t= o determine whether the cert was recorded or not. Recall:
>=3B
&g= t=3B CertID ::=3D SEQUENCE {
>=3B hashAlgorithm= AlgorithmIdentifier=2C
>=3B issuerNameHash OCTET = STRING=2C -- Hash of Issuer's DN
>=3B issuerKeyHash OCT= ET STRING=2C -- Hash of Issuers public key
>=3B serialNumber = CertificateSerialNumber }
>=3B
>=3B In the case where a fraudul= ent certificate is issued under an valid certificate serial number=2C this = CertID would result in an incorrect match=2C and GOOD would be sent as the = response. In contrast=2C if we have the subject key--or a more specific s= ubject key identifier--then the cert would *not* match=2C and NOTISSUED wou= ld result.
>=3B
>=3B Adding
>=3B
>=3B subjectKeyHas= h OCTET STRING=2C -- Hash of Subject public key
>=3B
>=3B to Cer= tID would probably suffice.
>=3B
>=3B So I'll retract the "I w= ant to see the whole cert" part. Chalk it up to excessive paranoia. My gu= t feels better if the OCSP service actually validates the certificate signa= ture=2C but if we assume a halfway competent client this is redundant (and = if the client is less than halfway competent=2C the OCSP response probably = doesn't matter anyway :).
>=3B
>=3B -- T
>=3B
>=3B >=3B _______________________________________________
>=3B pkix mai= ling list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/li= stinfo/pkix
>=3B _______________________________________________
&g= t=3B pkix mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.o= rg/mailman/listinfo/pkix
= --_f299781b-df03-45b0-add8-44961490afed_-- From SChokhani@cygnacom.com Tue Mar 20 10:05:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B0021F867B for ; Tue, 20 Mar 2012 10:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgCqv46iTNmM for ; Tue, 20 Mar 2012 10:04:58 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id F16C721F8592 for ; Tue, 20 Mar 2012 10:04:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,619,1325480400"; d="txt'?scan'208,217";a="597125" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 20 Mar 2012 13:04:57 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 20 Mar 2012 13:04:57 -0400 From: Santosh Chokhani To: Piyush Jain , "tmiller@mitre.org" , "brennansecurity@gmail.com" Date: Tue, 20 Mar 2012 13:04:55 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0GuwmXvVYDrc6GTd+vQa4nDSM4iwAAC7bg Message-ID: References: , , , , , , , <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org>, , <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org>, , <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 17:05:00 -0000 --_004_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_ Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_" --_000_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Piyush, You never responded to my e-mail addressing this issue and asking some ques= tions yesterday. That e-mail is attached assuming list serve does not strip it off. If it i= s stripped off, go back to your or PKIX archives to look at it. From: Piyush Jain [mailto:piyush@identicate.com] Sent: Tuesday, March 20, 2012 1:01 PM To: Santosh Chokhani; tmiller@mitre.org; brennansecurity@gmail.com Cc: pkix@ietf.org Subject: RE: [pkix] Possible OCSP Extensions > From: SChokhani@cygnacom.com > To: tmiller@mitre.org; brennansecurity@gmail.co= m > Date: Tue, 20 Mar 2012 12:51:40 -0400 > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions > > If you are talking about certificates, it is always better to have a cert= ificate hash as opposed to public key hash. > > This comment should not be construed to mean my support for any of this. = I continue to be skeptical of the need for not issued in general and of ran= ges when serial numbers are random or pseudo random. I'm in agreement with your stand on not issued. However, I would appreciate your opinions on the options available to a re= sponder for presigning for CAs that use random or pseudo random serials, an= d your thoughts on why ranges won't solve this problem. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bo= unces@ietf.org] On Behalf Of Miller,= Timothy J. > Sent: Tuesday, March 20, 2012 12:45 PM > To: brennan security > Cc: > > Subject: Re: [pkix] Possible OCSP Extensions > > On Mar 20, 2012, at 11:10 AM, brennan security wrote: > > > Actual certificates on the responder, or just an information source (ce= rtificate, digest, other) ? > > To reflection, the current 2560 CertID is not enough to determine whether= the cert was recorded or not. Recall: > > CertID ::=3D SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > issuerNameHash OCTET STRING, -- Hash of Issuer's DN > issuerKeyHash OCTET STRING, -- Hash of Issuers public key > serialNumber CertificateSerialNumber } > > In the case where a fraudulent certificate is issued under an valid certi= ficate serial number, this CertID would result in an incorrect match, and G= OOD would be sent as the response. In contrast, if we have the subject key-= -or a more specific subject key identifier--then the cert would *not* match= , and NOTISSUED would result. > > Adding > > subjectKeyHash OCTET STRING, -- Hash of Subject public key > > to CertID would probably suffice. > > So I'll retract the "I want to see the whole cert" part. Chalk it up to e= xcessive paranoia. My gut feels better if the OCSP service actually validat= es the certificate signature, but if we assume a halfway competent client t= his is redundant (and if the client is less than halfway competent, the OCS= P response probably doesn't matter anyway :). > > -- 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 --_000_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Piyush,=

 

You never responded to my e-mail addressing this issue = and asking some questions yesterday.

 

That e-mail is= attached assuming list serve does not strip it off.  If it is strippe= d off, go back to your or PKIX archives to look at it.

 

From: Piyush Jain [mailto:piyush@identicate.com]
Sent: Tuesday, March 20, 2012 1:01 PM
To: Santosh Chokhani; tmiller@= mitre.org; brennansecurity@gmail.com
Cc: pkix@ietf.org
Subj= ect: RE: [pkix] Possible OCSP Extensions

 

 

> From:= SChokhani@cygnacom.com
&g= t; To: tmiller@mitre.org; brennansecurity@gmail.com
>= Date: Tue, 20 Mar 2012 12:51:40 -0400
> CC: pkix@ietf.org
> Subject: Re: [pkix] Possible OCSP Extens= ions
>
> If you are talking about certificates, it is always b= etter to have a certificate hash as opposed to public key hash.<= /span>

> 

> This comment should not be construed to mean my support= for any of this. I continue to be skeptical of the need for not issued in = general and of ranges when serial numbers are random or pseudo random.=

 

=

I'm in  agreement with your stand on not issued.

However, I would appreciate your = opinions on the options available to a  responder for presigning for C= As that use random or pseudo random serials, and your thoughts on why range= s won't solve this problem.

>
> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J.
> Sent: Tuesday, March 20, 2012 12:45 PM
> To: = brennan security
> Cc: <pkix@ietf= .org>
> Subject: Re: [pkix] Possible OCSP Extensions
> <= br>> On Mar 20, 2012, at 11:10 AM, brennan security wrote:
>
&= gt; > Actual certificates on the responder, or just an information sourc= e (certificate, digest, other) ?
>
> To reflection, the curren= t 2560 CertID is not enough to determine whether the cert was recorded or n= ot. Recall:
>
> CertID ::=3D SEQUENCE {
> hashAlgorithm = AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer= 's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
= > serialNumber CertificateSerialNumber }
>
> In the case wh= ere a fraudulent certificate is issued under an valid certificate serial nu= mber, this CertID would result in an incorrect match, and GOOD would be sen= t as the response. In contrast, if we have the subject key--or a more speci= fic subject key identifier--then the cert would *not* match, and NOTISSUED = would result.
>
> Adding
>
> subjectKeyHash OCTET= STRING, -- Hash of Subject public key
>
> to CertID would pro= bably suffice.
>
> So I'll retract the "I want to see th= e whole cert" part. Chalk it up to excessive paranoia. My gut feels be= tter if the OCSP service actually validates the certificate signature, but = if we assume a halfway competent client this is redundant (and if the clien= t is less than halfway competent, the OCSP response probably doesn't matter= anyway :).
>
> -- T
>
>
> _______________= ________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix<= /a>
> _______________________________________________
> pkix ma= iling list
> pkix@ietf.org
&g= t; https://www.ietf.= org/mailman/listinfo/pkix

= --_000_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_-- --_004_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_ Content-Type: message/rfc822 Received: from ipedge1.entrust.com (216.191.252.10) by scygexch7.cygnacom.com (10.4.60.22) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Mar 2012 11:06:35 -0400 Received: from mail.ietf.org ([12.22.58.30]) by ipedge1.cygnacom.com with ESMTP; 19 Mar 2012 11:06:34 -0400 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF4921F8734; Mon, 19 Mar 2012 08:06:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2BF21F872F for ; Mon, 19 Mar 2012 08:06:24 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIy8e1Ib17j0 for ; Mon, 19 Mar 2012 08:06:23 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id C982A21F858D for ; Mon, 19 Mar 2012 08:06:22 -0700 (PDT) Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 19 Mar 2012 11:06:19 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 19 Mar 2012 11:06:19 -0400 From: Santosh Chokhani To: Piyush Jain , "stefan@aaa-sec.com" , "pkix@ietf.org" Sender: "pkix-bounces@ietf.org" Date: Mon, 19 Mar 2012 11:06:17 -0400 Subject: Re: [pkix] Range responses in OCSP Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0F4COMrIosmP7gTe+rDzTDDOcdOwAAPPzA Message-ID: References: , List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: scygexch7.cygnacom.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en-US dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332169593; bh=9svPUlwhZOSaBJyof2+CWHzugS4G8ZnSv+fo2ml2JSA=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=P483+vKF/q8ZT1Ezcmjq+7mQen9Wmjhoz0KM2N/IMsYglIQnCAlri3j1ufIU7VtkU x9LD6BLhcwN3Tv0+QBvPOQBvJAmNbO+uR9fmpM1IdDgbr0ZahFGmkc3hgaHRe5WeNE Hpd5lL4WYgREvkEVU1HjCdpfJOq2TLLUp1OCPQYk= x-ironport-av: E=Sophos;i="4.73,611,1325480400"; d="scan'208,217";a="588512" x-ironport-anti-spam-result: AtQBAJJKZ08MFjoemWdsb2JhbABCgkazB34iAQEBAQEICwsHFCeCCQEBAQECAQEBASoTAQEECh4MAgIBAQIGAQEBAQgRAwEBAQsLEQEHAwEjCxQJCAEBBAESBQOGCYF0BQECCKdShCwBjiICBI1Ogktjm3uLT4FMgTgIDQ x-ironport-anti-spam-filtered: true errors-to: pkix-bounces@ietf.org x-beenthere: pkix@ietf.org x-mailman-version: 2.1.12 x-spam-flag: NO x-virus-scanned: amavisd-new at amsl.com x-spam-status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001] x-spam-score: -2.462 x-spam-level: x-original-to: pkix@ietfa.amsl.com delivered-to: pkix@ietfa.amsl.com list-id: PKIX Working Group list-post: list-archive: Content-Type: multipart/mixed; boundary="_004_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_" MIME-Version: 1.0 --_004_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_" --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Piyush, If the serial numbers truly random, how would you do this without declaring= unissued certificates as valid? I suspect you are saying that if the CA is compromised, all of this does no= t matter and if the CA is not compromised, declaring unissued as legitimate= hurts nothing. Is this what you are saying. If so, this is yet another reason not to incl= ude never issued. BTW, the most folks deal with pre-signing today by having multiple response= s in a pre-signed bundle. The bundle is generally configurable and I have = seen bundle size as high as 20, reducing the signing workload by a factor o= f 20. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain Sent: Monday, March 19, 2012 10:53 AM To: stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP On the contrary, it'll address the objections to move to non sequential num= bers. There are installations today that are using the unadvertised feature in Mi= crosoft CA to generate sequential serial numbers, just because the current = OCSP spec makes pre-signing for certificates with random serial numbers imp= ossible. -Piyush ________________________________ Date: Mon, 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com; pkix@ietf.org My fear is that this will glue CAs to sequential serial numbers and prevent= them from moving to non sequential serial numbers when needed. /Stefan From: Piyush Jain > Date: Sun, 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson >, > Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response. Range response is just an optimal way of packing a large number of single r= esponses in one OCSP response. This is how pre-signing of OCSP is done today. One (or more) more keyed responders create a list of OCSP responses which i= s then mirrored to multiple keyless responders. Relying parties use these k= eyless responders to check the status of certificates. One OCSP response is= usually packed with status of muliple certificates to minimize the number = of signings. However, the trade off is that the OCSP response gets bloated. Problem: 1) The current representation of OCSP response is inefficient. Let's say th= at the range of issued certificates by a CA is 'M' and the number of revoke= d certificates in the CRL is 'N'. We know that typically M is much bigger t= han N. Using the current OCSP response representation , you need to create = M responses to account for every serial number that the CA issued. Using r= anges you could achieve the same thing using at most 2*N + 1 responses ( Think of it as an = efficient representation of a sparse array). 2)For CAs that issue certificates using random serial numbers, M is so big = that it becomes computationally impossible to pre-sign responses for those= CAs unless the responder has access to the CA database. Range response will facilitate pre-signing of OCSP responses for CAs that i= ssue certificates with non sequential serial numbers and reduce the computa= tion and bandwidth requirements even for CAs who issue certificates with se= quential serial numbers. -Piyush > Date: Sun, 18 Mar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP > > Trying to return to the actual question I would like to take up in > Santosh's question. > > What problem is this trying to solve? > > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes, it would not be a signed proof that this is not a replay sent by Eve > in order to fool you to reject a perfectly valid cert. > > But it would be an indication that something is fishy here and should be > investigated. > > Either you have a MitM swapping the OCSP responses, or you have a bad OCS= P > responder, or you have a compromised CA. > Time to push the alarm and figure out what's wrong. > > What more would you get from prefabricating all these OCSP range response= s? > > /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 --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Piyush,=

 

If the serial numbers truly random, how would you do th= is without declaring unissued certificates as valid?

<= p class=3DMsoNormal> 

I suspect you are saying that if the CA is compromised, all of this does = not matter and if the CA is not compromised, declaring unissued as legitima= te hurts nothing.

 =

Is this what you are saying. = ; If so, this is yet another reason not to include never issued.=

 

BTW, the most folks deal with pre-signing today by having mul= tiple responses in a pre-signed bundle.  The bundle is generally confi= gurable and I have seen bundle size as high as 20, reducing the signing wor= kload by a factor of 20.

 

From: pkix-bounc= es@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain<= br>Sent: Monday, March 19, 2012 10:53 AM
To: stefan@aaa-se= c.com; pkix@ietf.org
Subject: Re: [pkix] Range responses in OCSP<= o:p>

 

=

On the contrary, it'll address the objections to move to = non sequential numbers.

 <= /o:p>

There are installations today that = are using the unadvertised feature in Microsoft CA to generate sequential s= erial numbers, just because the current OCSP spec makes pre-signing for cer= tificates with random serial numbers impossible.

 

-Piy= ush

Date: Mon, 19 Mar= 2012 11:35:14 +0100
Subject: Re: [pkix] Range responses in OCSP
From= : stefan@aaa-sec.com
To: piyush@identicate.com; pkix@ietf.org

My fear is that this will glue CAs to sequential serial numbers and pr= event them from moving to non sequential serial numbers when needed.

 

/Stefan

&= nbsp;

From: Piyush Jain <piyus= h@identicate.com>
Date: Sun, 18 Mar 2012 20:57:26 -0700To: Stefan Santesson <stef= an@aaa-sec.com>, <pkix@ietf.org<= /a>>
Subject: Re: [pkix] Range responses in OCSP

I think the proposal to have OCS= P support range responses should be discussed separately from the= proposal to add "does not exist" response.

=

 

Range= response is just an optimal way of packing a large number of single respon= ses in one OCSP response.

 

This is how pre-signing of = OCSP is done today.

One (or mo= re) more keyed responders create a list of OCSP responses which is then mir= rored to multiple keyless responders. Relying parties use these keyless res= ponders to check the status of certificates. One OCSP response is usua= lly packed with status of muliple certificates to minimize the number of si= gnings. However, the trade off is that the OCSP response gets bloated.=

 

<= /div>

Problem:

1) The current representation of OCSP response is inefficient. Let's say = that the range of issued certificates by a CA is 'M' and the number of revo= ked certificates in the CRL is 'N'. We know that typically M is much bigger= than N. Using the current OCSP response representation , you need to creat= e M  responses to account for every serial number that the CA issued. = Using ranges you could  

= achieve the same thing using at most 2*N + 1 responses ( Think of it as an = efficient representation of a sparse array). 

 

2)= For CAs that issue certificates using random serial numbers, M is so big th= at it becomes computationally  impossible to pre-sign responses for th= ose CAs unless the responder has access to the CA database. 

 

=

Range response will facilitate pre-signing of OCSP responses f= or CAs that issue certificates with non sequential serial numbers and reduc= e the computation and bandwidth requirements even for CAs who iss= ue certificates with sequential serial numbers.

=

 

-Piyu= sh

 

> Date: Sun, 18 Mar 2012 23:48:52 +0100
> From:= stefan@aaa-sec.com
> To: <= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org
> Subject: Re: [pki= x] Range responses in OCSP
>
> Trying to return to the actual = question I would like to take up in
> Santosh's question.
> > What problem is this trying to solve?
>
> Why would it n= ot be enough to just craft one standard response saying "I
> hav= e no record of the certificate you are asking for"?
> Yes, it wo= uld not be a signed proof that this is not a replay sent by Eve
> in = order to fool you to reject a perfectly valid cert.
>
> But it= would be an indication that something is fishy here and should be
> = investigated.
>
> Either you have a MitM swapping the OCSP res= ponses, or you have a bad OCSP
> responder, or you have a compromised= CA.
> Time to push the alarm and figure out what's wrong.
> > What more would you get from prefabricating all these OCSP range res= ponses?
>
> /Stefan
>
>
> ________________= _______________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mail= man/listinfo/pkix

_______________________________________________ pkix mailing lis= t pkix@ietf.org https://www.ietf.org/mai= lman/listinfo/pkix

= --_000_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_-- --_004_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Mon, 19 Mar 2012 15:06:36 GMT"; modification-date="Mon, 19 Mar 2012 15:06:36 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBraXggbWFp bGluZyBsaXN0DQpwa2l4QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BraXgNCg== --_004_B83745DA469B7847811819C5005244AF0F60BAD7scygexch7cygnac_-- --_004_B83745DA469B7847811819C5005244AF0F60BB5Ascygexch7cygnac_-- From hotz@jpl.nasa.gov Tue Mar 20 10:13:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3221F84DD for ; Tue, 20 Mar 2012 10:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6bEHHIeUbdy for ; Tue, 20 Mar 2012 10:13:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 441F121F84D8 for ; Tue, 20 Mar 2012 10:13:51 -0700 (PDT) Received: from [192.168.2.107] (adsl-99-50-56-133.dsl.lsan03.sbcglobal.net [99.50.56.133]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2KHDmVY016703 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 20 Mar 2012 10:13:50 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Tue, 20 Mar 2012 10:13:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> To: "Miller, Timothy J." X-Mailer: Apple Mail (2.1084) X-Source-IP: adsl-99-50-56-133.dsl.lsan03.sbcglobal.net [99.50.56.133] X-Source-Sender: hotz@jpl.nasa.gov X-Spamclassfication-Commtouch: not spam X-SpamRefId: str=0001.0A090209.4F68BACE.00DB,ss=1,fgs=0 Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:13:52 -0000 On Mar 20, 2012, at 5:31 AM, Miller, Timothy J. wrote: > On Mar 19, 2012, at 3:18 PM, Henry B. Hotz wrote: >=20 >> To me UNKNOWN means "my knowledge is incomplete (and therefore not = authoritative)" and does not mean "this is clearly bogus". >=20 > I can form bogus Issuer/Serial combinations all day long. What does = it mean to the CA operator if I do? >=20 > -- T As you ourself pointed out, it means someone's generating bogus queries, = maybe to make the CA shut down for an audit. In the real world it most = likely means someone's got a buggy client. I think the real knowledge of whether a "not issued" response is = meaningful is mostly on the client side, which raises questions of how a = CA can know whether action is needed or not, and whether the client/user = will know what to do with it. (I don't run a CA.) ------------------------------------------------------ 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 brennansecurity@gmail.com Tue Mar 20 10:21:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306321F8684 for ; Tue, 20 Mar 2012 10:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39aiibMN7pUD for ; Tue, 20 Mar 2012 10:21:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B906621F8602 for ; Tue, 20 Mar 2012 10:21:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so126271vbb.31 for ; Tue, 20 Mar 2012 10:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ucvg7QE0JDaEMfxYdHZzmTLEOeIvXkOhcduy0xWoTLY=; b=kIAxgRzQ08Zwtcj2pa/olpz4vzcHZqJb2EIH6pwNJskPq8cLS64dvC0s/j2VcjXaes 4uKJiRb+aZMp41pTnY4jCL4E6K1bCQsYeb0dhbNfQjyeynU6C4WgcQcS9dO6sgUBTz9R pJIiynYYG84mJup4+TYlbVwpbf4BAK7IX8DVznZtru4y4AlTJINbA+nJJGKjjMArJtCu 0+LJfYQgywCgd/7XxE2A4ZUHMqDM2Lf44DTEsp4i6c8zo0Vj4cR6oqW0HUNb3fNBKIXI ei5d1Ayam412/tF9zDgDyWzbi2foaqPv65xHk3fa+UxAFXO1kCuwT5yjF1dDRNXQbP+7 gmUw== MIME-Version: 1.0 Received: by 10.220.149.4 with SMTP id r4mr290230vcv.46.1332264098136; Tue, 20 Mar 2012 10:21:38 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 10:21:38 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> Date: Tue, 20 Mar 2012 13:21:38 -0400 Message-ID: From: brennan security To: "Henry B. Hotz" Content-Type: multipart/alternative; boundary=f46d043be1d651025104bbafe85a Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:21:40 -0000 --f46d043be1d651025104bbafe85a Content-Type: text/plain; charset=ISO-8859-1 Henry, this is a good point you are making. A not issued can be indicative of one of a few things: CA compromise HSM compromise Attempted denial of service Security testing / Auditing bad performance testing buggy client bad data -b On Tue, Mar 20, 2012 at 1:13 PM, Henry B. Hotz wrote: > > On Mar 20, 2012, at 5:31 AM, Miller, Timothy J. wrote: > > > On Mar 19, 2012, at 3:18 PM, Henry B. Hotz wrote: > > > >> To me UNKNOWN means "my knowledge is incomplete (and therefore not > authoritative)" and does not mean "this is clearly bogus". > > > > I can form bogus Issuer/Serial combinations all day long. What does it > mean to the CA operator if I do? > > > > -- T > > As you ourself pointed out, it means someone's generating bogus queries, > maybe to make the CA shut down for an audit. In the real world it most > likely means someone's got a buggy client. > > I think the real knowledge of whether a "not issued" response is > meaningful is mostly on the client side, which raises questions of how a CA > can know whether action is needed or not, and whether the client/user will > know what to do with it. > > (I don't run a CA.) > > ------------------------------------------------------ > 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --f46d043be1d651025104bbafe85a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Henry, this is a good point you are making.

A not issued can be indicative of one of a few things:
CA comp= romise
HSM compromise
Attempted denial of service
Security testing / Auditing
bad performance testing
buggy client
bad data

-b

On Tue, Mar 20, 2012 at 1:13 PM, Henry B. Hotz <hotz@jpl.nasa.gov= > wrote:

On Mar 20, 2012, at 5:31 AM, Miller, Timothy J. wrote:

> On Mar 19, 2012, at 3:18 PM, Henry B. Hotz wrote:
>
>> To me UNKNOWN means "my knowledge is incomplete (and therefor= e not authoritative)" and does not mean "this is clearly bogus&qu= ot;.
>
> I can form bogus Issuer/Serial combinations all day long. =A0What does= it mean to the CA operator if I do?
>
> -- T

As you ourself pointed out, it means someone's generating bogus q= ueries, maybe to make the CA shut down for an audit. =A0In the real world i= t most likely means someone's got a buggy client.

I think the real knowledge of whether a "not issued" response is = meaningful is mostly on the client side, which raises questions of how a CA= can know whether action is needed or not, and whether the client/user will= know what to do with it.

(I don't run a CA.)

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

_____________________________= __________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix

--f46d043be1d651025104bbafe85a-- From hallam@gmail.com Tue Mar 20 10:27:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDE21F8704 for ; Tue, 20 Mar 2012 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b9MhHJ4MGvk for ; Tue, 20 Mar 2012 10:27:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19CDC21F8714 for ; Tue, 20 Mar 2012 10:27:27 -0700 (PDT) Received: by yenm5 with SMTP id m5so323431yen.31 for ; Tue, 20 Mar 2012 10:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C7Bgd1HKcZR7ahr8jfupEXHfEKNEGzK+paMX6UUqnUI=; b=BmyfJwF0kwJEh27CN/e/2iXQnKMP6aD9mGFcWi7MLJgaxgfX87bYawc1edRr5wTkwt DxmIZqjvY4Pm/r+g9JfIOLRQpEhTPLIm14z7fxo/WlMxDV+S1Y3LnMxC4VFSaPCFBOa4 HIdR1jLezKojaOTkGzbxzeLQwALc0DawG0XC38kXOcsMZmtxYiwPNFk3cschZKUNSpS0 Ac+h+BSIUSEagtuqq5Ayr05wnYbLM+MJNIBfeLWZlbWaWeMEATQwbhz7ot5iyAZhBrgH R5kVBMs/r76vy0JCq+E/tYA0EH2g+6bX3H8Pcng5UNqUcdgYWt7MLsZvvRKFSCZrrwzj +7Jw== MIME-Version: 1.0 Received: by 10.100.236.38 with SMTP id j38mr207426anh.74.1332264446744; Tue, 20 Mar 2012 10:27:26 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Tue, 20 Mar 2012 10:27:26 -0700 (PDT) In-Reply-To: References: <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> Date: Tue, 20 Mar 2012 13:27:26 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:27:28 -0000 I do like this approach from an abstract point of view and would certainly propose something of the sort if we were designing the whole system de novo. There are two problems though. The first is that there are 40 odd CAs in operation and I have no way to know the capabilities of all the HSMs in use. Unless this is a FIPS-140 requirement it is unlikely to be ubiquitously supported. Any retrofit that touches the online crypto services ends up being very expensive due to the need for testing. A second problem is knowing where to stop. Ideally the HSM would be capable of performing local enforcement of issue constraints (path and name constraints for example). This sounds good but requires a more complex HSM and that is bad. If the constraints are complex, they are likely to be misconfigured. So while these are certainly controls I would want to deploy if possible (and cost effective) at the level of my CAs I don't see them as a viable industry level proposal unless we are prepared to wait a long time for introduction. I don't see them as a substitute for protocol based constraints, nor do I see them as likely to be more secure in practice. On Tue, Mar 20, 2012 at 9:34 AM, Kemp, David P. wro= te: > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Piyush Jain >> From: mrex@sap.com >>> >>> One of the functions of disaster recovery is the ability to perform > an >>> audit, and then continue operation based on the audited information. >>> That is only possible if you have a data base (and issuing log) that >>> can be audited, and which is used for checking certs. >>> >> agreed. > > Agreed. > >>> Worst-case scenario is that you loose your HSM hardware through some >>> hardware defect or natural disaster. How do you know it was purely >>> accidental, and not a security-breach trying to cover tracks? >> >> Confirm if the CA was compromised. Evaluate the risk and decide >> to continue with the same key (if you have a bakup) or to mark it as > compromised. > > The premise is that you cannot confirm if the CA was compromised, as the > hardware root of trust has been destroyed. > > Which raises the question: assuming the HSM is still operating, do > typical HSMs include tamper-resistant audit features, such as signed > records and a hardware-stored operation counter to detect missing > records? =A0PKIX is being asked to design multi-party protocol workaround= s > to fix poor CA operations. =A0While layered security is a good idea, it's > incumbent on each element of a system to do its part, and the CA has the > bulk of that responsibility. =A0HSMs that guarantee a secure audit trail > (as long as the HSM itself has not been compromised) would make this > entire discussion moot. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Mar 20 10:30:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E4721F870F for ; Tue, 20 Mar 2012 10:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCBrUuO6jXGT for ; Tue, 20 Mar 2012 10:30:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41E0D21F870A for ; Tue, 20 Mar 2012 10:30:56 -0700 (PDT) Received: by yhkk25 with SMTP id k25so326836yhk.31 for ; Tue, 20 Mar 2012 10:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=f3Q4Y2EG3Qs5SQBq0IhCPA2pX7I4gdPl9O0h6icSRoE=; b=l9JCEbOS5ppCClYM9ZfoBgPpuCwOav6bwRdSkbxDL+yk5clB8f4pbE489nrAhN/Ya4 BYY1y2WfhMSnBPaHu69M7zuv+VFmW9bhaRNt8CnC+uP+9EbHA/Eg/VnVVa0IhKN72Puy oFwdcZ/x79Fr/DgLVguTe7oId8+SXqyQfhl03ZsDdVnENu3b18KFS94jNjgAkB5iLw5V On2RBQGsFfZOwfP6cMAEXuPoOvM8weLHXqqA/AF93mpI2rg6z33MoeG3pN4OBs4HKetl pW83RleiAbF3zolLykx9HaG+8X2JZSIUT3TW1nYq4tFXEjNBKxP6Ol4SM5hwjH3gUlLK zm3w== MIME-Version: 1.0 Received: by 10.236.174.1 with SMTP id w1mr660329yhl.125.1332264655767; Tue, 20 Mar 2012 10:30:55 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Tue, 20 Mar 2012 10:30:55 -0700 (PDT) In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <8577D1A0-0439-4EEC-A45F-271E0FEDAA71@mitre.org> Date: Tue, 20 Mar 2012 13:30:55 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:30:57 -0000 This proposal provides much of the same capability as Google's Certificate Transparency proposal with considerably less deployment pain for the CAs. Thus I see it as being a preferable variation of a proposal that is already being considered seriously. On Tue, Mar 20, 2012 at 8:28 AM, Miller, Timothy J. wro= te: > On Mar 19, 2012, at 12:43 PM, Phillip Hallam-Baker wrote: > >> In this case a NOTISSUED response for an actual cert would sound alarm >> bells at the meta-level and an industry level response. Contrawise >> responding to a request for a non-existent cert with any other status >> would be a cause for concern. > > Really? =A0 You think that's a good idea? > > I can't *wait* for the ability Verisign down simply by sending false OCSP= queries. =A0 Then my Evil Plan can commence! =A0MWahahhahhahaa! > > Seriously, if you expect a CA operator to take action based on *unauthent= icated, untrusted input* it receives at the OCSP interface, you've got anot= her thing coming. =A0Existence of an OCSP request *does not* imply existenc= e of a fraudulent cert. > > -- T > --=20 Website: http://hallambaker.com/ From kent@bbn.com Tue Mar 20 11:16:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE40021F858A for ; Tue, 20 Mar 2012 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or8VuV6Cdfa2 for ; Tue, 20 Mar 2012 11:16:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6542F21F8589 for ; Tue, 20 Mar 2012 11:16:18 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49157) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA3bK-000J22-Dl for pkix@ietf.org; Tue, 20 Mar 2012 14:16:06 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 20 Mar 2012 13:58:51 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 18:16:19 -0000 Folks, The discussion about how OCSP responses could be better, CRLs could be more secure, etc. may be enlightening, but it is putting the cart before the horse. Until we have an doc that describes the set of problems that we agree need to be addressed, no solution is better than any other, or better that the status quo. Steve From brennansecurity@gmail.com Tue Mar 20 11:17:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311D821F858A for ; Tue, 20 Mar 2012 11:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EbmBDYjeycF for ; Tue, 20 Mar 2012 11:17:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7023521F8589 for ; Tue, 20 Mar 2012 11:17:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so153083vbb.31 for ; Tue, 20 Mar 2012 11:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OJ+Tl3ThTfGCRwO/O1bb6p4ZCwVhWHPW9HiPL+Vfzck=; b=vzV/lK7op1T6/gU2famU2VdjjBDrNqid1zIk8k25tQZVtuOhJk9aBjOqYN/aziS+ua WKC3GE6P1+gh5tuWgrq0QzvNou4Iuc6WLRm1niqqy2Sbgc8ljopBShVAhzymmf880XlF 4qDWszFGlVRE1kn52B1m10cS7Q/UK8w1EOQwDKwZW4q+55y25dSW4K3MrpX4lVrTm+uw K2kcWKJlxr1y8t8P6+/PeGOM3JbOmDKU5rVTs9HlLBrodSzZPu4yLA/30jQvVsQeKCY9 uktPONeT5wehOqG+K4ea2xUC/gBcuEtIBFwnBZUn3YPqGI+x+0xQnOD/MpQOl9FXoRt0 UBew== MIME-Version: 1.0 Received: by 10.52.30.98 with SMTP id r2mr362437vdh.8.1332267461811; Tue, 20 Mar 2012 11:17:41 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 11:17:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 14:17:41 -0400 Message-ID: From: brennan security To: Stephen Kent Content-Type: multipart/alternative; boundary=20cf3079b89ece9ce104bbb0b09f Cc: pkix@ietf.org Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 18:17:43 -0000 --20cf3079b89ece9ce104bbb0b09f Content-Type: text/plain; charset=ISO-8859-1 Stephen, I volunteered to write up something on this, and am working on it now. -b On Tue, Mar 20, 2012 at 1:58 PM, Stephen Kent wrote: > Folks, > > The discussion about how OCSP responses could be better, CRLs could > be more secure, etc. may be enlightening, but it is putting the cart > before the horse. > > Until we have an doc that describes the set of problems that we agree need > to be addressed, no solution is better than any other, or better that the > status quo. > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --20cf3079b89ece9ce104bbb0b09f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stephen,

I volunteered to write up someth= ing on this, and am working on it now.

-b
On Tue, Mar 20, 2012 at 1:58 PM, Stephen Kent <= span dir=3D"ltr"><kent@bbn.com> wrote:
Folks,

The discussion =A0about how OCSP responses could be better, CRLs could
be more secure, etc. may be enlightening, but it is putting the cart before= the horse.

Until we have an doc that describes the set of problems that we agree need = to be addressed, no solution is better than any other, or better that the s= tatus quo.

Steve
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix

--20cf3079b89ece9ce104bbb0b09f-- From hallam@gmail.com Tue Mar 20 11:36:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF4D21F8613 for ; Tue, 20 Mar 2012 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6T-CcUbiWP2 for ; Tue, 20 Mar 2012 11:36:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53D21F8608 for ; Tue, 20 Mar 2012 11:35:58 -0700 (PDT) Received: by ggmi1 with SMTP id i1so410108ggm.31 for ; Tue, 20 Mar 2012 11:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bn1O7cm4GqLQ3DsPY48L4GdAUqkwVvQkiId8jCyz2bU=; b=o66flM5bmN9jpCkZXrY7EMNUaBZLvkKL6rqI2plc9RhQ5MiR3d2oPd9Ot/VQVO8+Rw osrBmM/WV0fg+kQ//07+iJt7CmAruO+4WMu5lBoqLX8HnSABHA4wQEUvYTdogj7TzM4X jqFTV/0x94VSUTggaUPIZI9dPVFKpSYHjDCdMKmHkVJESjzWlii33Ur2xXsQGIc4hJAp 3dlnglU5rraw6XNTtuBjuTjwDw9wpM8XRiYdp51AEIsgjH+7CE3iCygAFTbBPGiJ1JO2 3wvQ3zd5hv8Tj0+PF1w9fdqS0pcsW+Nt/CTJ5/GNuPb5yyCf+bDVk4vJyTxp9EsuKC6u HjAg== MIME-Version: 1.0 Received: by 10.236.153.104 with SMTP id e68mr971171yhk.74.1332268557657; Tue, 20 Mar 2012 11:35:57 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Tue, 20 Mar 2012 11:35:57 -0700 (PDT) Date: Tue, 20 Mar 2012 14:35:57 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] Certificate Issuer Transparency Proposal X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 18:36:03 -0000 In response to Stephen's request for a statement of the goals: Objective: Improve confidence in the system of public CAs by making certain aspects of CA operations transparent. We define 'transparent' to mean 'can be audited by any external party without access to privileged information. Our concern in this particular proposal is limited to the operation of online HSM devices used to sign certificates and OCSP responses. In particular the proposal must address a particular failure discovered during the DigiNotar case in which a CA lost control of their HSM and their log files and this state of affairs remained undetected by the CA for a considerable period of time and was not known to the general public for a longer period of time. Proposal: The following technical proposals would be part of a set of requirements that all public CAs would be obliged to conform to in order for their certificates to be recognized. 1) Technical restriction on operation of a CA to ensure an effective isolation of online and offline certificate signing keys such that: * Only an Online key may sign EE certificates (other than OCSP certs) or OCSP responses * Only an Offline key may sign certificates for online keys (cert signing certs and OCSP certs) The first is achieved by mandating use of Basic Constraints and a path length of 0 for the certificate corresponding to the key used to sign an EE certificate. The second constraint illustrates an area where I think we have a big mess. It is pretty much common sense that the authoritative signer of a Comodo certificate should be Comodo and no other CA. It is also pretty clear that there are good reasons why a party other than the authoritative party might be signing. But neither RFC 5280 nor 2560 makes that distinction and so there are no clear rules for determining what is an authoritative response. These create a set of audit checks, e.g.: * Fail if there any online Cert signing key that does not have a path length of 0 These also create transparency checks, e.g. : * Fail if there is an OCSP cert that is issued off a cert with a path length of 0 2) Technical requirement that the CA maintain a complete log of all certificates issued and that this condition be transparent to external observers (but not necessarily the actual contents of the log). This is achieved by requiring the CA to * Respond to all OCSP queries with a signed response * Issue distinct and different responses for the cases 'certificate not issued' and 'status is not known' * Issue responses that bind to a specific certificate and not merely a certificate serial number. This is to be achieved as follows: * New OCSP response 'NOT-ISSUED' that allows a range of serial numbers to be specified (and thus meets the requirement that responses be capable of being pre-signed if desired) * New OCSP extension that allows an issued certificate to be specified by means of a digest (e.g. SHA256) in addition to the serial number * Limit the time period for which the notBefore date in a cert may be predated. These create a series of transparency checks: * Fail if a certificate is discovered for which an inconsistent NOT-ISSUED OCSP response is returned [Note that predating of notBefore creates issues here] * Fail if a request for a random certificate results in any response other than NOT-ISSUED Note that mere failure of a transparency check does not mean the automatic end of a CA root. It is a signal that something MAY be wrong and that further investigation is required. -- Website: http://hallambaker.com/ From tmiller@mitre.org Tue Mar 20 11:58:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B224C21F8501 for ; Tue, 20 Mar 2012 11:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPsJOZchhZK7 for ; Tue, 20 Mar 2012 11:58:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C34A21F84F5 for ; Tue, 20 Mar 2012 11:58:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F337421B1648; Tue, 20 Mar 2012 14:58:53 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D52BC21B14FE; Tue, 20 Mar 2012 14:58:53 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 14:58:53 -0400 From: "Miller, Timothy J." To: Santosh Chokhani Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQD//75OkIAAZyaA Date: Tue, 20 Mar 2012 18:58:53 +0000 Message-ID: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> <59DC7A8A-11DF-4459-A74E-95F179CFEB14@mitre.org> <88767648-9EA6-4F32-9030-9D2F50196C5F@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CFE59D4856A82459647A6D498226C37@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 18:58:55 -0000 On Mar 20, 2012, at 11:51 AM, Santosh Chokhani wrote: > This comment should not be construed to mean my support for any of this. = I continue to be skeptical of the need for not issued in general and of ra= nges when serial numbers are random or pseudo random. I'm also skeptical about whether the extension is worth it, I'm just trying= to figure out the cases and requirements necessary to make it work at all.= Based on what I've laid out, I've only reinforced my opinion that NOTISSU= ED is meaningful only in narrow circumstances that won't occur in the wild.= =20 I've also come to think that GOOD should be struck from the list of possibl= e responses unless qualified by an extension (mandatory for GOOD responses)= that tells the client that the CA history was checked for a match. As cur= rently written, allowing GOOD without qualifier leads to incorrect interpre= tation of the protocol. I.e., for most OCSP Responders only REVOKED or UNK= NOWN should be sent. =20 Response ranges is a separate thread, I thought. =20 -- T From eabalea@gmail.com Tue Mar 20 12:16:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8D21F8643 for ; Tue, 20 Mar 2012 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vot-BhT+V1o for ; Tue, 20 Mar 2012 12:16:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC5E21F8623 for ; Tue, 20 Mar 2012 12:16:15 -0700 (PDT) Received: by ggmi1 with SMTP id i1so454678ggm.31 for ; Tue, 20 Mar 2012 12:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wsSZuif/6WDR63nbKVr+0tZ1YGXEcusv8xuq3gpRDF8=; b=LQLUAR5FpYyoIKixMKyKTlyzAkqYYCHsxZ1hiVD7BU2ql2B+46jai31zWgrLrYmct3 3GEmpdbDyjqAcZHUQmhCIUHyZuG23a/YD7Q6X61a/azibRImvk7J1CSA47PXoJwFgrpD 2YEx81QVza8El+u9Vh1n/k99VofRibm8uHBin5UWgZUyN+AiYsqjYAuCRwtdkQ4rCSUe 70yG+IAXs2w7L7sJPt2HctDKit2UObB7HfrE1PsmIGVcR+I6L5DytFwqLwVt4hc9Bzta AoWJij0vVewnaUH6AH08hMiWvDZAiX545kpOPPMlnomWj1lFdXOoz2BS1DJwtH1iZ7d9 /Vrg== MIME-Version: 1.0 Received: by 10.236.80.39 with SMTP id j27mr1084443yhe.92.1332270975092; Tue, 20 Mar 2012 12:16:15 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Tue, 20 Mar 2012 12:16:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 20:16:15 +0100 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf30050be23707c304bbb18200 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Issuer Transparency Proposal X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 19:16:16 -0000 --20cf30050be23707c304bbb18200 Content-Type: text/plain; charset=UTF-8 Bonsoir, 2012/3/20 Phillip Hallam-Baker [...] > 1) Technical restriction on operation of a CA to ensure an effective > isolation of online and offline certificate signing keys such that: > > * Only an Online key may sign EE certificates (other than OCSP certs) > or OCSP responses > * Only an Offline key may sign certificates for online keys (cert > signing certs and OCSP certs) > > The first is achieved by mandating use of Basic Constraints and a path > length of 0 for the certificate corresponding to the key used to sign > an EE certificate. > Not exactly. This condition (basicConstraints:pathLen=0) only disallows a CA with a pathLen different than 0 to sign an EE cert. There's no "online" vs "offline" here. But as implied by the phrasing, let's consider "online" for "pathLen=0 CA certs", and "offline" for "pathLen != 0 CA certs" from now. Are you proposing that CAs can only sign other CAs *or* EEs, but not both? (exclusive or) Are you proposing that a CA used to issue EE certs cannot sign an OCSP responder certificate? (see below) These create a set of audit checks, e.g.: > > * Fail if there any online Cert signing key that does not have a path > length of 0 > > These also create transparency checks, e.g. : > > * Fail if there is an OCSP cert that is issued off a cert with a path > length of 0 > This rule forbids the creation of a designated OCSP responder for an "online" CA. You're therefore reserving OCSP designated responders to "offline" CAs, where CRLs are sufficient. [thinking further] Are you proposing that an OCSP responder can only be the CA itself (i.e. same name), with a dedicated certificate, signed by the parent CA (an offline one), as opposed to a self-issued certificate? I wanted to test that case with different toolkits/products, but it takes time. 2) Technical requirement that the CA maintain a complete log of all > certificates issued and that this condition be transparent to external > observers (but not necessarily the actual contents of the log). > > This is achieved by requiring the CA to > > * Respond to all OCSP queries with a signed response > This is already the case as per RFC2560, for definitive responses (good, revoked, unknown). This cannot be enforced for *all* responses (i.e. malformedRequest, internalError, tryLater, sigRequired, unauthorized) unless you want to expose the OCSP responder to DOS. [...] The whole threads need to be read again, but right now my opinion is that all this is either not necessary or counter productive (could slow OCSP adoption). My opinion may be biased (I'm a CA, and host several CAs). -- Erwann. --20cf30050be23707c304bbb18200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonsoir,

2012/3/20 Phillip Hallam-Baker <= span dir=3D"ltr"><hallam@gmail.com>
[...]
1) Technical restriction on operation of a CA to ensure an effective
isolation of online and offline certificate signing keys such that:

* Only an Online key may sign EE certificates (other than OCSP certs)
or OCSP responses
* Only an Offline key may sign certificates for online keys (cert
signing certs and OCSP certs)
=C2=A0
The first is achieved by mandating use of Basic Constraints and a path
length of 0 for the certificate corresponding to the key used to sign
an EE certificate.

Not exactly. This condition (ba= sicConstraints:pathLen=3D0) only disallows a CA with a pathLen different th= an 0 to sign an EE cert. There's no "online" vs "offline= " here. But as implied by the phrasing, let's consider "onlin= e" for "pathLen=3D0 CA certs", and "offline" for &= quot;pathLen !=3D 0 CA certs" from now.

Are you proposing that CAs can only sign other CAs *or* EEs, but not bo= th? (exclusive or)

Are you proposing that a CA used to issue EE cert= s cannot sign an OCSP responder certificate? (see below)


These create a set of audit checks, e.g.:

* Fail if there any online Cert signing key that does not have a path
length of 0

These also create transparency checks, e.g. :

* Fail if there is an OCSP cert that is issued off a cert with a path
length of 0
=C2=A0
This rule forbids the creation o= f a designated OCSP responder for an "online" CA. You're ther= efore reserving OCSP designated responders to "offline" CAs, wher= e CRLs are sufficient.

[thinking further] Are you proposing that an OCSP responder can only be= the CA itself (i.e. same name), with a dedicated certificate, signed by th= e parent CA (an offline one), as opposed to a self-issued certificate? I wa= nted to test that case with different toolkits/products, but it takes time.=

2) Technical requirement that the CA maintain a complete log of all
certificates issued and that this condition be transparent to external
observers (but not necessarily the actual contents of the log).

This is achieved by requiring the CA to

* Respond to all OCSP queries with a signed response
<= br>This is already the case as per RFC2560, for definitive responses (good,= revoked, unknown). This cannot be enforced for *all* responses (i.e. malfo= rmedRequest, internalError, tryLater, sigRequired, unauthorized) unless you= want to expose the OCSP responder to DOS.

[...]
The whole threads need to be read again, but right now my opin= ion is that all this is either not necessary or counter productive (could s= low OCSP adoption). My opinion may be biased (I'm a CA, and host severa= l CAs).

--
Erwann.
--20cf30050be23707c304bbb18200-- From carl@redhoundsoftware.com Tue Mar 20 12:18:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FEE21F8652 for ; Tue, 20 Mar 2012 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j05wr+b6ZZFk for ; Tue, 20 Mar 2012 12:18:34 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4761921F864F for ; Tue, 20 Mar 2012 12:18:34 -0700 (PDT) Received: by qaea16 with SMTP id a16so226793qae.10 for ; Tue, 20 Mar 2012 12:18:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=pjnQLig7aolMG3s4Q/pEuxwwLluDQqetN3Ot8ZiNRjs=; b=CfTRyl4R3ZRAiyq3mJJg/zcRhjjeevh7pFmpjOIoe69DU2FHUVJYK043D3Ui6mzQJH vWg9S0DpkcGckitq4aEIFGd/WF2HNyJtnyayba5E6ezYuBVOtuNvRBB3z+nic26srvkn RrzJpWz4XSA9n3VttSjmfu8jVgyM2ijvgeoyzeLx204WdRJU0UBeo7CUL9y9vvLuBHp+ /0FerPjoRMR1yokHl3p6v3GAuBv03P0q8Rz8x4bkIW8uhg98LeHHG18NE616/hitIJQE +SJxLQY3CCS8pHa9zqiht3miVhmyqNVF8vQIc57hokuR05liWsbnM5MiGiPChCNiyrXs FU1A== Received: by 10.224.195.201 with SMTP id ed9mr2457083qab.65.1332271113729; Tue, 20 Mar 2012 12:18:33 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id ha10sm4111308qab.14.2012.03.20.12.18.30 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 12:18:32 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 20 Mar 2012 15:18:18 -0400 From: Carl Wallace To: "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] Possible OCSP Extensions In-Reply-To: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmp/i+Fqa1RTXANWXjeqtaWUFNIeh6waWGUdf3oFvs+Cfwf8vLklCssbY0tBdih5bRwjJ0m Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 19:18:35 -0000 On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: > >On Mar 20, 2012, at 11:51 AM, Santosh Chokhani wrote: > >> This comment should not be construed to mean my support for any of >>this. I continue to be skeptical of the need for not issued in general >>and of ranges when serial numbers are random or pseudo random. > >I'm also skeptical about whether the extension is worth it, I'm just >trying to figure out the cases and requirements necessary to make it work >at all. Based on what I've laid out, I've only reinforced my opinion >that NOTISSUED is meaningful only in narrow circumstances that won't >occur in the wild. > >I've also come to think that GOOD should be struck from the list of >possible responses unless qualified by an extension (mandatory for GOOD >responses) that tells the client that the CA history was checked for a >match. As currently written, allowing GOOD without qualifier leads to >incorrect interpretation of the protocol. I.e., for most OCSP Responders >only REVOKED or UNKNOWN should be sent. As currently written where? RFC2560 states the following: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. Adding an extension to return proof of existence would be easy enough and would not break backwards compatibility. Adding additional status values or changing the meaning of existing status values would. Clients that want to fail without the extra proof could do so. >Response ranges is a separate thread, I thought. > >-- T > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Tue Mar 20 12:59:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BB421F84FE for ; Tue, 20 Mar 2012 12:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwQrOy04HAsi for ; Tue, 20 Mar 2012 12:59:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3B021F8623 for ; Tue, 20 Mar 2012 12:59:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94A2E21B0914; Tue, 20 Mar 2012 15:59:48 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7EEED21B08A0; Tue, 20 Mar 2012 15:59:48 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.211]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 15:59:48 -0400 From: "Miller, Timothy J." To: Carl Wallace Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQD//75OkIAAZyaAgAAFbQCAAAuWAA== Date: Tue, 20 Mar 2012 19:59:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4797F84937FA884187F4548A1E611F37@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 19:59:49 -0000 On Mar 20, 2012, at 2:18 PM, Carl Wallace wrote: > As currently written where? =20 The response code says it's "good" and *everyone* knows what that means, ri= ght?=20 The sarcasm should be obvious. =20 The clarifying text even calls out the problem with this response code! =20 Here's a rule of thumb: Any specification that includes the phrase "=85doe= s not necessarily mean=85" should immediately be rewritten. :) > Adding an extension to return proof of existence would be easy enough and > would not break backwards compatibility. Adding additional status values > or changing the meaning of existing status values would. Clients that > want to fail without the extra proof could do so. IMHO, OCSP only needs two response codes: REVOKED and OTHER, where OTHER m= eans the cert does *not* match records on the CRL. This doesn't mean the c= ert is good, bad, or someone else's, it just means the revocation status co= uld not be determined. REVOKED should induce a hard failure, and OTHER sho= uld not. Three codes *in the base case* introduced ambiguity because the o= nly additional information the third code (GOOD) tells you is "the cert *ap= pears to be* one of mine," and "appears to be" isn't actually conveying any= actual information. [1] -- T [1] If you want more than this, OTHER could be qualified by extensions; e.g= ., NOTMINE (certificate wasn't issued by the cognizant CA), BOGUS (certific= ate appears to belong to the cognizant CA but doesn't match the cognizant C= A's list of things that should exist), or EXCELLENT (certificate does match= the cognizant CA's list of things that should exist). From piyush@identicate.com Tue Mar 20 12:59:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6E821F8643 for ; Tue, 20 Mar 2012 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-0evtx+uhQe for ; Tue, 20 Mar 2012 12:59:56 -0700 (PDT) Received: from col0-omc2-s11.col0.hotmail.com (col0-omc2-s11.col0.hotmail.com [65.55.34.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4129421F8637 for ; Tue, 20 Mar 2012 12:59:56 -0700 (PDT) Received: from COL119-W2 ([65.55.34.73]) by col0-omc2-s11.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 12:59:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8438acd7-8498-41a4-8b24-1413acd31cbd_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Tue, 20 Mar 2012 12:59:55 -0700 Importance: Normal In-Reply-To: References: , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2012 19:59:56.0075 (UTC) FILETIME=[059EF7B0:01CD06D4] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 19:59:57 -0000 --_8438acd7-8498-41a4-8b24-1413acd31cbd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I thought that I had responded to this but Santosh pointed out that I did n= ot.So here we go. From: SChokhani@cygnacom.com To: piyush@identicate.com=3B stefan@aaa-sec.com=3B pkix@ietf.org Date: Mon=2C 19 Mar 2012 11:06:17 -0400 Subject: RE: [pkix] Range responses in OCSP Piyush=2C If the serial numbers truly random=2C how would you do this witho= ut declaring unissued certificates as valid?[Piyush] Since the RP does the = signature verification before sending the OCSP request=2C responder returni= ng 'good' for unissued certificates is a non issue. i I suspect you are saying that if the CA is compromised=2C all of this does = not matter and if the CA is not compromised=2C declaring unissued as legiti= mate hurts nothing.[Piyush] Right on Target Is this what you are saying. = If so=2C this is yet another reason not to include never issued.[Piyush] Ev= en if not issued is included=2C the responder can use ranges to pre-sign no= t issued status. Not that i believe that 'not issued' serves a purpose big = enough to be made part of the standard. BTW=2C the most folks deal with pr= e-signing today by having multiple responses in a pre-signed bundle. The b= undle is generally configurable and I have seen bundle size as high as 20= =2C reducing the signing workload by a factor of 20.[Piyush] That's true. = Very familiar with this model. However=2C this does not help with pre-signi= ng for CAs that issue certs with non sequential certificates. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pi= yush Jain Sent: Monday=2C March 19=2C 2012 10:53 AM To: stefan@aaa-sec.com=3B pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP On the contrary=2C it'll addres= s the objections to move to non sequential numbers. There are installations= today that are using the unadvertised feature in Microsoft CA to generate = sequential serial numbers=2C just because the current OCSP spec makes pre-s= igning for certificates with random serial numbers impossible. -PiyushDate:= Mon=2C 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com=3B pkix@ietf.orgMy fear is that this will glue CA= s to sequential serial numbers and prevent them from moving to non sequenti= al serial numbers when needed. /Stefan From: Piyush Jain Date: Sun=2C 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson =2C Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OC= SP support range responses should be discussed separately from the proposal= to add "does not exist" response. Range response is just an optimal way of= packing a large number of single responses in one OCSP response. This is h= ow pre-signing of OCSP is done today.One (or more) more keyed responders cr= eate a list of OCSP responses which is then mirrored to multiple keyless re= sponders. Relying parties use these keyless responders to check the status = of certificates. One OCSP response is usually packed with status of muliple= certificates to minimize the number of signings. However=2C the trade off = is that the OCSP response gets bloated. Problem:1) The current representati= on of OCSP response is inefficient. Let's say that the range of issued cert= ificates by a CA is 'M' and the number of revoked certificates in the CRL i= s 'N'. We know that typically M is much bigger than N. Using the current OC= SP response representation =2C you need to create M responses to account f= or every serial number that the CA issued. Using ranges you could achieve = the same thing using at most 2*N + 1 responses ( Think of it as an efficien= t representation of a sparse array). 2)For CAs that issue certificates usi= ng random serial numbers=2C M is so big that it becomes computationally im= possible to pre-sign responses for those CAs unless the responder has acces= s to the CA database. Range response will facilitate pre-signing of OCSP r= esponses for CAs that issue certificates with non sequential serial numbers= and reduce the computation and bandwidth requirements even for CAs who iss= ue certificates with sequential serial numbers. -Piyush > Date: Sun=2C 18 M= ar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP >=20 > Trying to return to the actual question I would like to take up in > Santosh's question. >=20 > What problem is this trying to solve? >=20 > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes=2C it would not be a signed proof that this is not a replay sent by E= ve > in order to fool you to reject a perfectly valid cert. >=20 > But it would be an indication that something is fishy here and should be > investigated. >=20 > Either you have a MitM swapping the OCSP responses=2C or you have a bad O= CSP > responder=2C or you have a compromised CA. > Time to push the alarm and figure out what's wrong. >=20 > What more would you get from prefabricating all these OCSP range response= s? >=20 > /Stefan >=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/mailm= an/listinfo/pkix = --_8438acd7-8498-41a4-8b24-1413acd31cbd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I thought that I had responded to this but Santosh pointed out that I did n= ot.
So here we go.

From: SChokhani@cygnacom.com
To: piyu= sh@identicate.com=3B stefan@aaa-sec.com=3B pkix@ietf.org
Date: Mon=2C 19= Mar 2012 11:06:17 -0400
Subject: RE: [pkix] Range responses in OCSP
=

Piyush=2C

<= span style=3D"font-size:9.0pt=3Bfont-family:"=3BArial"=3B=2C"= =3Bsans-serif"=3B=3Bcolor:#1F497D"> =3B

If the serial numbers truly = random=2C how would you do this without declaring unissued certificates as = valid?

[Piyush] Since the RP does the signature verification befo= re sending the OCSP request=2C responder returning 'good' for unissued = =3Bcertificates =3Bis a non issue. i

I suspect you are saying = that if the CA is compromised=2C all of this does not matter and if the CA = is not compromised=2C declaring unissued as legitimate hurts nothing.

[Piyus= h]  =3BRight on Target

 =3B

Is this what you are saying. =3B If = so=2C this is yet another reason not to include never issued.

[Piyush] Eve= n if not issued is included=2C the responder can use ranges to pre-sign not= issued status. Not that i believe that 'not issued' serves a purpose big e= nough  =3Bto be made part of the standard.

 =3B

BTW=2C the most fol= ks deal with pre-signing today by having multiple responses in a pre-signed= bundle. =3B The bundle is generally configurable and I have seen bundl= e size as high as 20=2C reducing the signing workload by a factor of 20.

[Piyush]  =3BThat's true= . Very familiar with this model. However=2C this does not help with pre-sig= ning for CAs that issue certs with non sequential certificates.


 =3B

=

From= : pkix-bounces@ietf.org [mailto:pkix-bou= nces@ietf.org] On Behalf Of Piyush Jain
Sent: Monday=2C Ma= rch 19=2C 2012 10:53 AM
To: stefan@aaa-sec.com=3B pkix@ietf.orgSubject: Re: [pkix] Range responses in OCSP

=

 =3B

On the contrary=2C it'll address the objections to move t= o non sequential numbers.

 =3B

There are installations today that are using the una= dvertised feature in Microsoft CA to generate sequential serial numbers=2C = just because the current OCSP spec makes pre-signing for certificates with = random serial numbers impossible.

 =3B

-Piyush

Date: Mon=2C 19 Mar 2012 11:35:14 +0100
Subject: Re:= [pkix] Range responses in OCSP
From: stefan@aaa-sec.com
To: = piyush@identicate.com=3B pkix@ietf.org=

My fe= ar is that this will glue CAs to sequential serial numbers and prevent them= from moving to non sequential serial numbers when needed.

=

 =3B

<= /div>

/Stefan<= /p>

 =3B

From: Piyush Jain <=3Bpiyush@identica= te.com>=3B
Date: Sun=2C 18 Mar 2012 20:57:26 -0700
To= : Stefan Santesson <=3Bstefan@a= aa-sec.com>=3B=2C <=3Bpkix@ietf.or= g>=3B
Subject: Re: [pkix] Range responses in OCSP

 =3B

I think the proposal to have OCSP support range responses sh= ould be discussed =3Bseparately =3Bfrom the proposal to add "does n= ot exist" response.

 =3B

Range response is just an optimal way of packing a large num= ber of single responses in one OCSP response.

 =3B

This is how pre-signing of = OCSP is done today.

One (or more) more keyed responders create a list of OCSP r= esponses which is then mirrored to multiple keyless responders. Relying par= ties use these keyless responders to check the status of certificates. = =3BOne OCSP response is usually packed with status of muliple certificates = to minimize the number of signings. =3BHowever=2C the trade off is that= the OCSP response gets bloated.

 =3B

Problem:

1) The current representation of = OCSP response is inefficient. Let's say that the range of issued certificat= es by a CA is 'M' and the number of revoked certificates in the CRL is 'N'.= We know that typically M is much bigger than N. Using the current OCSP res= ponse representation =2C you need to create M  =3Bresponses to account = for every serial number that the CA issued. Using ranges you could  =3B=

ach= ieve the same thing using at most 2*N + 1 responses ( Think of it as an eff= icient representation of a sparse array). =3B

 =3B

2)For CAs that issue c= ertificates using random serial numbers=2C M is so big that it becomes comp= utationally  =3Bimpossible to pre-sign responses for those CAs unless t= he responder has access to the CA database. =3B

 =3B

Range response will fa= cilitate pre-signing of OCSP responses for CAs that issue certificates with= non sequential serial numbers and reduce the =3Bcomputation =3Band= bandwidth requirements even for CAs who issue certificates with sequential= serial numbers.

 =3B

-Piyush

 =3B

>=3B Date: Sun=2C 18 Mar 2012 23:48:52 +0100
&g= t=3B From: stefan@aaa-sec.com
= >=3B To: pkix@ietf.org
>=3B Sub= ject: Re: [pkix] Range responses in OCSP
>=3B
>=3B Trying to ret= urn to the actual question I would like to take up in
>=3B Santosh's q= uestion.
>=3B
>=3B What problem is this trying to solve?
>= =3B
>=3B Why would it not be enough to just craft one standard respon= se saying "I
>=3B have no record of the certificate you are asking for= "?
>=3B Yes=2C it would not be a signed proof that this is not a repla= y sent by Eve
>=3B in order to fool you to reject a perfectly valid ce= rt.
>=3B
>=3B But it would be an indication that something is fi= shy here and should be
>=3B investigated.
>=3B
>=3B Either = you have a MitM swapping the OCSP responses=2C or you have a bad OCSP
&g= t=3B responder=2C or you have a compromised CA.
>=3B Time to push the = alarm and figure out what's wrong.
>=3B
>=3B What more would you= get from prefabricating all these OCSP range responses?
>=3B
>= =3B /Stefan
>=3B
>=3B
>=3B _______________________________= ________________
>=3B pkix mailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/listinf= o/pkix

_______________________________________________ p= kix mailing list pkix@ietf.org https://w= ww.ietf.org/mailman/listinfo/pkix

<= /div>
= --_8438acd7-8498-41a4-8b24-1413acd31cbd_-- From SChokhani@cygnacom.com Tue Mar 20 13:09:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14F321F8598 for ; Tue, 20 Mar 2012 13:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSIq50-9Cg5J for ; Tue, 20 Mar 2012 13:09:19 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0504021F858F for ; Tue, 20 Mar 2012 13:09:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,619,1325480400"; d="scan'208";a="598707" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 20 Mar 2012 16:09:16 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 20 Mar 2012 16:09:16 -0400 From: Santosh Chokhani To: "Miller, Timothy J." , Carl Wallace Date: Tue, 20 Mar 2012 16:09:14 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQD//75OkIAAZyaAgAAFbQCAAAuWAP//v3jw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 20:09:19 -0000 Why not just go with the terms CRL and not on CRL since CRL is the primary = source. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J. Sent: Tuesday, March 20, 2012 4:00 PM To: Carl Wallace Cc: Subject: Re: [pkix] Possible OCSP Extensions On Mar 20, 2012, at 2:18 PM, Carl Wallace wrote: > As currently written where? =20 The response code says it's "good" and *everyone* knows what that means, ri= ght?=20 The sarcasm should be obvious. =20 The clarifying text even calls out the problem with this response code! =20 Here's a rule of thumb: Any specification that includes the phrase "...doe= s not necessarily mean..." should immediately be rewritten. :) > Adding an extension to return proof of existence would be easy enough=20 > and would not break backwards compatibility. Adding additional status=20 > values or changing the meaning of existing status values would. =20 > Clients that want to fail without the extra proof could do so. IMHO, OCSP only needs two response codes: REVOKED and OTHER, where OTHER m= eans the cert does *not* match records on the CRL. This doesn't mean the c= ert is good, bad, or someone else's, it just means the revocation status co= uld not be determined. REVOKED should induce a hard failure, and OTHER sho= uld not. Three codes *in the base case* introduced ambiguity because the o= nly additional information the third code (GOOD) tells you is "the cert *ap= pears to be* one of mine," and "appears to be" isn't actually conveying any= actual information. [1] -- T [1] If you want more than this, OTHER could be qualified by extensions; e.g= ., NOTMINE (certificate wasn't issued by the cognizant CA), BOGUS (certific= ate appears to belong to the cognizant CA but doesn't match the cognizant C= A's list of things that should exist), or EXCELLENT (certificate does match= the cognizant CA's list of things that should exist). _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Tue Mar 20 13:25:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C673C21F84F0 for ; Tue, 20 Mar 2012 13:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBcVMFPe0VVH for ; Tue, 20 Mar 2012 13:25:05 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4321F85EA for ; Tue, 20 Mar 2012 13:25:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,619,1325480400"; d="scan'208,217";a="4452621" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 20 Mar 2012 16:25:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 20 Mar 2012 16:25:04 -0400 From: Santosh Chokhani To: Piyush Jain , "stefan@aaa-sec.com" , "pkix@ietf.org" Date: Tue, 20 Mar 2012 16:25:02 -0400 Thread-Topic: [pkix] Range responses in OCSP Thread-Index: Ac0G1AciZGR61oPqQm21XcqnIETSmAAAXBCw Message-ID: References: , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BB6Cscygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 20:25:06 -0000 --_000_B83745DA469B7847811819C5005244AF0F60BB6Cscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Piyush, Random serial numbers do not necessarily mean you need range capability for= pre-signing. An alternative is Responder accessing the CA database to cre= ate the responses. Note that the range response does not fix the problem with the pre-signed r= esponse for the certificates issued during the time window since the previo= us pre-signing. This will also require access to CA database or accepting = the newly issued certificates without the status information. To my knowle= dge there are no standards or product capabilities in this area. From: Piyush Jain [mailto:piyush@identicate.com] Sent: Tuesday, March 20, 2012 4:00 PM To: Santosh Chokhani; stefan@aaa-sec.com; pkix@ietf.org Subject: RE: [pkix] Range responses in OCSP I thought that I had responded to this but Santosh pointed out that I did n= ot. So here we go. From: SChokhani@cygnacom.com To: piyush@identicate.com; stefan@aaa-sec.com= ; pkix@ietf.org Date: Mon, 19 Mar 2012 11:06:17 -0400 Subject: RE: [pkix] Range responses in OCSP Piyush, If the serial numbers truly random, how would you do this without declaring= unissued certificates as valid? [Piyush] Since the RP does the signature verification before sending the OC= SP request, responder returning 'good' for unissued certificates is a non i= ssue. i I suspect you are saying that if the CA is compromised, all of this does no= t matter and if the CA is not compromised, declaring unissued as legitimate= hurts nothing. [Piyush] Right on Target Is this what you are saying. If so, this is yet another reason not to incl= ude never issued. [Piyush] Even if not issued is included, the responder can use ranges to pr= e-sign not issued status. Not that i believe that 'not issued' serves a pur= pose big enough to be made part of the standard. BTW, the most folks deal with pre-signing today by having multiple response= s in a pre-signed bundle. The bundle is generally configurable and I have = seen bundle size as high as 20, reducing the signing workload by a factor o= f 20. [Piyush] That's true. Very familiar with this model. However, this does no= t help with pre-signing for CAs that issue certs with non sequential certif= icates. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Piyush Ja= in Sent: Monday, March 19, 2012 10:53 AM To: stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP On the contrary, it'll address the objections to move to non sequential num= bers. There are installations today that are using the unadvertised feature in Mi= crosoft CA to generate sequential serial numbers, just because the current = OCSP spec makes pre-signing for certificates with random serial numbers imp= ossible. -Piyush ________________________________ Date: Mon, 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com; pkix@ietf.org My fear is that this will glue CAs to sequential serial numbers and prevent= them from moving to non sequential serial numbers when needed. /Stefan From: Piyush Jain > Date: Sun, 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson >, > Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OCSP support range responses should be discuss= ed separately from the proposal to add "does not exist" response. Range response is just an optimal way of packing a large number of single r= esponses in one OCSP response. This is how pre-signing of OCSP is done today. One (or more) more keyed responders create a list of OCSP responses which i= s then mirrored to multiple keyless responders. Relying parties use these k= eyless responders to check the status of certificates. One OCSP response is= usually packed with status of muliple certificates to minimize the number = of signings. However, the trade off is that the OCSP response gets bloated. Problem: 1) The current representation of OCSP response is inefficient. Let's say th= at the range of issued certificates by a CA is 'M' and the number of revoke= d certificates in the CRL is 'N'. We know that typically M is much bigger t= han N. Using the current OCSP response representation , you need to create = M responses to account for every serial number that the CA issued. Using r= anges you could achieve the same thing using at most 2*N + 1 responses ( Think of it as an = efficient representation of a sparse array). 2)For CAs that issue certificates using random serial numbers, M is so big = that it becomes computationally impossible to pre-sign responses for those= CAs unless the responder has access to the CA database. Range response will facilitate pre-signing of OCSP responses for CAs that i= ssue certificates with non sequential serial numbers and reduce the computa= tion and bandwidth requirements even for CAs who issue certificates with se= quential serial numbers. -Piyush > Date: Sun, 18 Mar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP > > Trying to return to the actual question I would like to take up in > Santosh's question. > > What problem is this trying to solve? > > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes, it would not be a signed proof that this is not a replay sent by Eve > in order to fool you to reject a perfectly valid cert. > > But it would be an indication that something is fishy here and should be > investigated. > > Either you have a MitM swapping the OCSP responses, or you have a bad OCS= P > responder, or you have a compromised CA. > Time to push the alarm and figure out what's wrong. > > What more would you get from prefabricating all these OCSP range response= s? > > /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 --_000_B83745DA469B7847811819C5005244AF0F60BB6Cscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Piyush,=

 

Random serial numbers do not necessarily mean you need = range capability for pre-signing.  An alternative is Responder accessi= ng the CA database to create the responses.

 

Note = that the range response does not fix the problem with the pre-signed respon= se for the certificates issued during the time window since the previous pr= e-signing.  This will also require access to CA database or accepting = the newly issued certificates without the status information.  To my k= nowledge there are no standards or product capabilities in this area.<= /o:p>

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: Piyush Jain [mailto:piyush@identicate.com]=
Sent: Tuesday, March 20, 2012 4:00 PM
To: Santosh Cho= khani; stefan@aaa-sec.com; pkix@ietf.org
Subject: RE: [pkix] Rang= e responses in OCSP

<= o:p> 

I thought that I had responded to thi= s but Santosh pointed out that I did not.

So here we go.

From: SChokhani@cygnacom.com
To: piyush@identicate.com; stefan@aaa-sec.com; pkix@iet= f.org
Date: Mon, 19 Mar 2012 11:06:17 -0400
Subject: RE: [pkix] R= ange responses in OCSP

P= iyush,

 =

If the serial numbers truly random, how would = you do this without declaring unissued certificates as valid?

[Piyush] Since the RP does the signature verification b= efore sending the OCSP request, responder returning 'good' for unissued&nbs= p;certificates is a non issue. i

 

I suspect you = are saying that if the CA is compromised, all of this does not matter and i= f the CA is not compromised, declaring unissued as legitimate hurts nothing= .=

[Piyush]  Right on Targ= et

 

=

Is this what you are saying.  If so, this is = yet another reason not to include never issued.

[Piyush] Even if not issued is included, the responder ca= n use ranges to pre-sign not issued status. Not that i believe that 'not is= sued' serves a purpose big enough  to be made part of the standard.

 

BTW, the most folks deal with pre-signing today by havi= ng multiple responses in a pre-signed bundle.  The bundle is generally= configurable and I have seen bundle size as high as 20, reducing the signi= ng workload by a factor of 20.

[Piyush]  That's true. Very familiar with this model. However, this d= oes not help with pre-signing for CAs that issue certs with non sequential = certificates.

 

=

 

From: pkix-bounces@ietf= .org [mailto:pkix-bou= nces@ietf.org] On Behalf Of Piyush Jain
Sent: Monday, = March 19, 2012 10:53 AM
To: stefan@aaa-sec.com; pkix@ietf.org=
Subject: Re: [pkix] Range responses in OCSP

 

On = the contrary, it'll address the objections to move to non sequential number= s.

 

There are installations today that are using the unadver= tised feature in Microsoft CA to generate sequential serial numbers, just b= ecause the current OCSP spec makes pre-signing for certificates with random= serial numbers impossible.

&n= bsp;

-Piyush=

=

Date: Mon, 19 Mar 2012 11:35:14 +0100
Subject: Re: [pk= ix] Range responses in OCSP
From: = stefan@aaa-sec.com
To: piyu= sh@identicate.com; pkix@ietf.org

My fear is that this will glue CAs to= sequential serial numbers and prevent them from moving to non sequential s= erial numbers when needed.

&nb= sp;

/Stefan<= /p>

 

From: Piyush Jain <piyush@identicate.com>
Date: S= un, 18 Mar 2012 20:57:26 -0700
To: Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: Re: [pkix] Ra= nge responses in OCSP

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> 

I think the proposal to have OCSP support range responses should be discu= ssed separately from the proposal to add "does not exist&quo= t; response.

 

Range response is just an optimal way of packi= ng a large number of single responses in one OCSP response.

 

This is how pre-signing of OCSP is done today.

=

One (or more) more keyed responders create a list o= f OCSP responses which is then mirrored to multiple keyless responders. Rel= ying parties use these keyless responders to check the status of certificat= es. One OCSP response is usually packed with status of muliple certifi= cates to minimize the number of signings. However, the trade off is th= at the OCSP response gets bloated.

 

Problem:

1) The current representation of OCSP r= esponse is inefficient. Let's say that the range of issued certificates by = a CA is 'M' and the number of revoked certificates in the CRL is 'N'. We kn= ow that typically M is much bigger than N. Using the current OCSP response = representation , you need to create M  responses to account for every = serial number that the CA issued. Using ranges you could  <= /span>

achieve the same thing using at most 2*N = + 1 responses ( Think of it as an efficient representation of a sparse arra= y). 

 

2)For CAs that issue certificates using ra= ndom serial numbers, M is so big that it becomes computationally  impo= ssible to pre-sign responses for those CAs unless the responder has access = to the CA database. 

&nbs= p;

Range response will facilit= ate pre-signing of OCSP responses for CAs that issue certificates with non = sequential serial numbers and reduce the computation and bandwidt= h requirements even for CAs who issue certificates with sequential serial n= umbers.

 

-Piyush

 

> Date: Sun, 18 = Mar 2012 23:48:52 +0100
> From: stefan@aaa-sec.com
> To: pkix@i= etf.org
> Subject: Re: [pkix] Range responses in OCSP
> > Trying to return to the actual question I would like to take up in> Santosh's question.
>
> What problem is this trying to s= olve?
>
> Why would it not be enough to just craft one standar= d response saying "I
> have no record of the certificate you are= asking for"?
> Yes, it would not be a signed proof that this is= not a replay sent by Eve
> in order to fool you to reject a perfectl= y valid cert.
>
> But it would be an indication that something= is fishy here and should be
> investigated.
>
> Either = you have a MitM swapping the OCSP responses, or you have a bad OCSP
>= responder, or you have a compromised CA.
> Time to push the alarm an= d figure out what's wrong.
>
> What more would you get from pr= efabricating all these OCSP range responses?
>
> /Stefan
&g= t;
>
> _______________________________________________
>= ; pkix mailing list
> pkix@ietf.org<= /a>
> https://www.ietf.org/mailman/listinfo/pkix

___________________________= ____________________ pkix mailing list pki= x@ietf.org https://www.ietf.org/mailman/listinfo/pkix

= = --_000_B83745DA469B7847811819C5005244AF0F60BB6Cscygexch7cygnac_-- From DPKemp@missi.ncsc.mil Tue Mar 20 13:33:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC3921F864E for ; Tue, 20 Mar 2012 13:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfcJqd3wb0oK for ; Tue, 20 Mar 2012 13:33:05 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 33A6421F8639 for ; Tue, 20 Mar 2012 13:33:05 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2KKX44V060226 for ; Tue, 20 Mar 2012 16:33:04 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 16:33:04 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Mar 2012 16:33:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0GzkOs7OgffyjvRrmTTCC2QM9kZwABDe8Q References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Mar 2012 20:33:04.0495 (UTC) FILETIME=[A6CFC7F0:01CD06D8] Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 20:33:06 -0000 The word GOOD directly contradicts the RFC 2560 paragraph describing it. A certificate that was never issued or is outside its validity period cannot, under any reasonable English language interpretation, be considered "good". Whereas UNKNOWN is a reasonable word to use for a certificate that may or may not exist, but is definitely not revoked. Modifying OCSP responders to never send a deprecated GOOD response does not change the meaning of that response. And unless the default client behavior is to fail on UNKNOWN, changing responders to use it for all non-revoked certificates does not affect client behavior. Excellent point regarding proof of existence. There is no need to change the OCSP request in any way. The extension can be sent at the discretion of the responder, the client can validate the proof since it already has a copy of the certificate being checked, and the client can follow its own policy for handling responses without the extension or responses with proofs that don't match the certificate. That is backwards compatibility at its best, and although I'm skeptical of using OCSP to address PHB's NOT-ISSUED requirement, the proof-of-issuance extension seems quite straightforward. Dave -----Original Message----- From: Carl Wallace On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: > As currently written, allowing GOOD without qualifier leads to=20 > incorrect interpretation of the protocol. I.e., for most OCSP=20 > Responders only REVOKED or UNKNOWN should be sent. As currently written where? RFC2560 states the following: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. Adding an extension to return proof of existence would be easy enough and would not break backwards compatibility. Adding additional status values or changing the meaning of existing status values would. Clients that want to fail without the extra proof could do so. From piyush@identicate.com Tue Mar 20 13:35:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E8E21F8584 for ; Tue, 20 Mar 2012 13:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IZTxw2pdiUE for ; Tue, 20 Mar 2012 13:35:53 -0700 (PDT) Received: from col0-omc2-s4.col0.hotmail.com (col0-omc2-s4.col0.hotmail.com [65.55.34.78]) by ietfa.amsl.com (Postfix) with ESMTP id EB0FF21F8582 for ; Tue, 20 Mar 2012 13:35:48 -0700 (PDT) Received: from COL119-W9 ([65.55.34.73]) by col0-omc2-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 13:35:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a2c0d98d-0a4e-4c0b-a10e-a1d98d2f6e5d_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Tue, 20 Mar 2012 13:35:48 -0700 Importance: Normal In-Reply-To: References: , , , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2012 20:35:48.0863 (UTC) FILETIME=[08C858F0:01CD06D9] Subject: Re: [pkix] Range responses in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 20:35:56 -0000 --_a2c0d98d-0a4e-4c0b-a10e-a1d98d2f6e5d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Santosh=2C That's why I said that it is needed for responders who do not have access t= o CA database.You of most people=2C with you experience with some of the l= argest PKIs would know that in most large scale enterprise OCSP deployments= responders are detached from the CA and pre-sign responses based on CRLs a= lone. I'm aware of at least one product that uses the approach that you stated be= low and its all based on custom protocol/mechanisms that are used to share = the list of issued serials between the CA and the responder. From: SChokhani@cygnacom.com To: piyush@identicate.com=3B stefan@aaa-sec.com=3B pkix@ietf.org Date: Tue=2C 20 Mar 2012 16:25:02 -0400 Subject: RE: [pkix] Range responses in OCSP Piyush=2C Random serial numbers do not necessarily mean you need range capa= bility for pre-signing. An alternative is Responder accessing the CA datab= ase to create the responses. Note that the range response does not fix the = problem with the pre-signed response for the certificates issued during the= time window since the previous pre-signing. This will also require access= to CA database or accepting the newly issued certificates without the stat= us information. To my knowledge there are no standards or product capabili= ties in this area. From: Piyush Jain [mailto:piyush@identicate.com]=20 Sent: Tuesday=2C March 20=2C 2012 4:00 PM To: Santosh Chokhani=3B stefan@aaa-sec.com=3B pkix@ietf.org Subject: RE: [pkix] Range responses in OCSP I thought that I had responded = to this but Santosh pointed out that I did not.So here we go.From: SChokhan= i@cygnacom.com To: piyush@identicate.com=3B stefan@aaa-sec.com=3B pkix@ietf.org Date: Mon=2C 19 Mar 2012 11:06:17 -0400 Subject: RE: [pkix] Range responses in OCSPPiyush=2C If the serial numbers = truly random=2C how would you do this without declaring unissued certificat= es as valid?[Piyush] Since the RP does the signature verification before se= nding the OCSP request=2C responder returning 'good' for unissued certifica= tes is a non issue. i I suspect you are saying that if the CA is compromise= d=2C all of this does not matter and if the CA is not compromised=2C declar= ing unissued as legitimate hurts nothing.[Piyush] Right on Target Is this = what you are saying. If so=2C this is yet another reason not to include ne= ver issued.[Piyush] Even if not issued is included=2C the responder can use= ranges to pre-sign not issued status. Not that i believe that 'not issued'= serves a purpose big enough to be made part of the standard. BTW=2C the m= ost folks deal with pre-signing today by having multiple responses in a pre= -signed bundle. The bundle is generally configurable and I have seen bundl= e size as high as 20=2C reducing the signing workload by a factor of 20.[Pi= yush] That's true. Very familiar with this model. However=2C this does not= help with pre-signing for CAs that issue certs with non sequential certifi= cates. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behal= f Of Piyush Jain Sent: Monday=2C March 19=2C 2012 10:53 AM To: stefan@aaa-sec.com=3B pkix@ietf.org Subject: Re: [pkix] Range responses in OCSP On the contrary=2C it'll addres= s the objections to move to non sequential numbers. There are installations= today that are using the unadvertised feature in Microsoft CA to generate = sequential serial numbers=2C just because the current OCSP spec makes pre-s= igning for certificates with random serial numbers impossible. -PiyushDate:= Mon=2C 19 Mar 2012 11:35:14 +0100 Subject: Re: [pkix] Range responses in OCSP From: stefan@aaa-sec.com To: piyush@identicate.com=3B pkix@ietf.orgMy fear is that this will glue CA= s to sequential serial numbers and prevent them from moving to non sequenti= al serial numbers when needed. /Stefan From: Piyush Jain Date: Sun=2C 18 Mar 2012 20:57:26 -0700 To: Stefan Santesson =2C Subject: Re: [pkix] Range responses in OCSP I think the proposal to have OC= SP support range responses should be discussed separately from the proposal= to add "does not exist" response. Range response is just an optimal way of= packing a large number of single responses in one OCSP response. This is h= ow pre-signing of OCSP is done today.One (or more) more keyed responders cr= eate a list of OCSP responses which is then mirrored to multiple keyless re= sponders. Relying parties use these keyless responders to check the status = of certificates. One OCSP response is usually packed with status of muliple= certificates to minimize the number of signings. However=2C the trade off = is that the OCSP response gets bloated. Problem:1) The current representati= on of OCSP response is inefficient. Let's say that the range of issued cert= ificates by a CA is 'M' and the number of revoked certificates in the CRL i= s 'N'. We know that typically M is much bigger than N. Using the current OC= SP response representation =2C you need to create M responses to account f= or every serial number that the CA issued. Using ranges you could achieve = the same thing using at most 2*N + 1 responses ( Think of it as an efficien= t representation of a sparse array). 2)For CAs that issue certificates usi= ng random serial numbers=2C M is so big that it becomes computationally im= possible to pre-sign responses for those CAs unless the responder has acces= s to the CA database. Range response will facilitate pre-signing of OCSP r= esponses for CAs that issue certificates with non sequential serial numbers= and reduce the computation and bandwidth requirements even for CAs who iss= ue certificates with sequential serial numbers. -Piyush > Date: Sun=2C 18 M= ar 2012 23:48:52 +0100 > From: stefan@aaa-sec.com > To: pkix@ietf.org > Subject: Re: [pkix] Range responses in OCSP >=20 > Trying to return to the actual question I would like to take up in > Santosh's question. >=20 > What problem is this trying to solve? >=20 > Why would it not be enough to just craft one standard response saying "I > have no record of the certificate you are asking for"? > Yes=2C it would not be a signed proof that this is not a replay sent by E= ve > in order to fool you to reject a perfectly valid cert. >=20 > But it would be an indication that something is fishy here and should be > investigated. >=20 > Either you have a MitM swapping the OCSP responses=2C or you have a bad O= CSP > responder=2C or you have a compromised CA. > Time to push the alarm and figure out what's wrong. >=20 > What more would you get from prefabricating all these OCSP range response= s? >=20 > /Stefan >=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/mailm= an/listinfo/pkix = --_a2c0d98d-0a4e-4c0b-a10e-a1d98d2f6e5d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Santosh=2C

That's why I said that it is needed for respo= nders who do not have access to CA database.
You  =3Bof most = people=2C with you experience with some of the largest PKIs would know that= in most large scale enterprise OCSP deployments responders are detached fr= om the CA and pre-sign responses based on CRLs alone.

<= div>I'm aware of at least one product that uses the approach that you state= d below and its all based on custom protocol/mechanisms that are used to sh= are the list of issued serials between the CA and the responder.

From: SChok= hani@cygnacom.com
To: piyush@identicate.com=3B stefan@aaa-sec.com=3B pki= x@ietf.org
Date: Tue=2C 20 Mar 2012 16:25:02 -0400
Subject: RE: [pkix= ] Range responses in OCSP

Piyush=2C

<= span style=3D"font-size:9.0pt=3Bfont-family:"=3BArial"=3B=2C"= =3Bsans-serif"=3B=3Bcolor:#1F497D"> =3B

Random serial numbers do not= necessarily mean you need range capability for pre-signing. =3B An alt= ernative is Responder accessing the CA database to create the responses.

&nb= sp=3B

Note that the range response does not fix the problem with the pre-sig= ned response for the certificates issued during the time window since the p= revious pre-signing. =3B This will also require access to CA database o= r accepting the newly issued certificates without the status information.&n= bsp=3B To my knowledge there are no standards or product capabilities in th= is area.

 =3B

<= span style=3D"font-size:10.0pt=3Bfont-family:"=3BTahoma"=3B=2C"= =3Bsans-serif"=3B">From: Piyush Jain= [mailto:piyush@identicate.com]
Sent: Tuesday=2C March 20=2C 201= 2 4:00 PM
To: Santosh Chokhani=3B stefan@aaa-sec.com=3B pkix@ietf= .org
Subject: RE: [pkix] Range responses in OCSP

=

 =3B

= I thought that I had responded to this but Santosh = pointed out that I did not.

So here we go.

=

From: SChokhani@cygn= acom.com
To: piyush@identic= ate.com=3B stefan@aaa-sec.com= =3B pkix@ietf.org
Date: Mon=2C 19 M= ar 2012 11:06:17 -0400
Subject: RE: [pkix] Range responses in OCSP

P= iyush=2C

 =3B

If the serial numbers truly random=2C how would you do this without de= claring unissued certificates as valid?

[Piyush] Since the = RP does the signature verification before sending the OCSP request=2C respo= nder returning 'good' for unissued =3Bcertificates =3Bis a non issu= e. i

 = =3B

I suspect you are saying that if the CA is compromised=2C all of t= his does not matter and if the CA is not compromised=2C declaring unissued = as legitimate hurts nothing.

[Piyush]  = =3BRight on Target

 =3B

Is this what you are saying. =3B If so=2C this is yet ano= ther reason not to include never issued.

[Piy= ush] Even if not issued is included=2C the responder can use ranges to pre-= sign not issued status. Not that i believe that 'not issued' serves a purpo= se big enough  =3Bto be made part of the standard.

 =3B

BTW=2C the most folks dea= l with pre-signing today by having multiple responses in a pre-signed bundl= e. =3B The bundle is generally configurable and I have seen bundle size= as high as 20=2C reducing the signing workload by a factor of 20.

[Piyush]  =3BThat's true. Very familiar with thi= s model. However=2C this does not help with pre-signing for CAs that issue = certs with non sequential certificates.

 =3B

=

 =3B

 =3B

On the contrary=2C it'll address = the objections to move to non sequential numbers.

 =3B

There are installations tod= ay that are using the unadvertised feature in Microsoft CA to generate sequ= ential serial numbers=2C just because the current OCSP spec makes pre-signi= ng for certificates with random serial numbers impossible.

=

 =3B

<= /div>

-Piyush<= /p>

Date: Mon=2C 19 Mar 2012 11:35:14 +0100
Subject: = Re: [pkix] Range responses in OCSP
From: stefan@aaa-sec.com
To: piyush@identicate.com=3B pkix@ietf.= org

My= fear is that this will glue CAs to sequential serial numbers and prevent t= hem from moving to non sequential serial numbers when needed.

 =3B

/Stefan

 = =3B

From: Piyush Jain <=3Bpiyush@= identicate.com>=3B
Date: Sun=2C 18 Mar 2012 20:57:26 -0700<= br>To: Stefan Santesson <=3B= stefan@aaa-sec.com>=3B=2C <=3Bpkix= @ietf.org>=3B
Subject: Re: [pkix] Range responses in OCSP

 =3B

I think the proposa= l to have OCSP support range responses should be discussed =3Bseparatel= y =3Bfrom the proposal to add "does not exist" response.

 =3B

Range response is j= ust an optimal way of packing a large number of single responses in one OCS= P response.

 =3B

This is how pre-signing of OCSP is done today.

One (or more) more = keyed responders create a list of OCSP responses which is then mirrored to = multiple keyless responders. Relying parties use these keyless responders t= o check the status of certificates. =3BOne OCSP response is usually pac= ked with status of muliple certificates to minimize the number of signings.=  =3BHowever=2C the trade off is that the OCSP response gets bloated.

 = =3B

= Problem:

1) The current representation of OCSP response is inefficient. Let's s= ay that the range of issued certificates by a CA is 'M' and the number of r= evoked certificates in the CRL is 'N'. We know that typically M is much big= ger than N. Using the current OCSP response representation =2C you need to = create M  =3Bresponses to account for every serial number that the CA i= ssued. Using ranges you could  =3B

achieve the same thing using at most 2*N= + 1 responses ( Think of it as an efficient representation of a sparse arr= ay). =3B

 =3B

2)For CAs that issue certificates using random serial numbers= =2C M is so big that it becomes computationally  =3Bimpossible to pre-s= ign responses for those CAs unless the responder has access to the CA datab= ase. =3B

 =3B

Range response will facilitate pre-signing of OCSP responses = for CAs that issue certificates with non sequential serial numbers and redu= ce the =3Bcomputation =3Band bandwidth requirements even for CAs wh= o issue certificates with sequential serial numbers.

<= p class=3D"ecxMsoNormal"> =3B

<= div>

-Piyush

 =3B

>=3B Date: Sun= =2C 18 Mar 2012 23:48:52 +0100
>=3B From: stefan@aaa-sec.com
>=3B To: pkix@ietf.org
>=3B Subject: Re: [pkix] Range responses in OCS= P
>=3B
>=3B Trying to return to the actual question I would like= to take up in
>=3B Santosh's question.
>=3B
>=3B What prob= lem is this trying to solve?
>=3B
>=3B Why would it not be enoug= h to just craft one standard response saying "I
>=3B have no record of= the certificate you are asking for"?
>=3B Yes=2C it would not be a si= gned proof that this is not a replay sent by Eve
>=3B in order to fool= you to reject a perfectly valid cert.
>=3B
>=3B But it would be= an indication that something is fishy here and should be
>=3B investi= gated.
>=3B
>=3B Either you have a MitM swapping the OCSP respon= ses=2C or you have a bad OCSP
>=3B responder=2C or you have a compromi= sed CA.
>=3B Time to push the alarm and figure out what's wrong.
&g= t=3B
>=3B What more would you get from prefabricating all these OCSP = range responses?
>=3B
>=3B /Stefan
>=3B
>=3B
>= =3B _______________________________________________
>=3B pkix mailing = list
>=3B pkix@ietf.org
>=3B= h= ttps://www.ietf.org/mailman/listinfo/pkix

<= /div>

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

= --_a2c0d98d-0a4e-4c0b-a10e-a1d98d2f6e5d_-- From kent@bbn.com Tue Mar 20 13:36:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CCC21F865A for ; Tue, 20 Mar 2012 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OYnvXIXunYg for ; Tue, 20 Mar 2012 13:36:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0F21F8637 for ; Tue, 20 Mar 2012 13:36:51 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49159) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA5nB-000NT5-Gp; Tue, 20 Mar 2012 16:36:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 20 Mar 2012 14:38:32 -0400 To: brennan security From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 20:36:52 -0000 At 2:17 PM -0400 3/20/12, brennan security wrote: >Stephen, > > >I volunteered to write up something on this, and am working on it now. > >-b > I remember, and I am not trying to push you to publish that doc faster. I just don't want folks to spend a lot of time haggling over solution details at this stage. Steve From brennansecurity@gmail.com Tue Mar 20 13:40:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793FF21F8637 for ; Tue, 20 Mar 2012 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yplhrc4kLBlz for ; Tue, 20 Mar 2012 13:40:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1F21F84F0 for ; Tue, 20 Mar 2012 13:40:33 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so527884vcb.31 for ; Tue, 20 Mar 2012 13:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BYbH5gSENcd0FJJbMpPVGB/jcRwpfkJEgHe8EfyE8nY=; b=bKv12U6wiUfKETGYjKpzWoDWL4p4uLizHDjWa7mOLVfSz1IUonpWqS2oYIjvoZ8NCx 04zo0/JFg8jOH0QFkMVWJEH2gSwh5zUonDm/K1KNWkv8DsCzDNQe7a4danUuz+9Z8jpy YbIcKSKd8w7JGnk6cqfRXRA8e6qXazinl3mwh2RZIqbYJDfrgxG3s0teiUM/qz54XHZW QOhideJRLDKQgaMVZxMpLI/6MVZBNfFKDI5xBbF6PyRsjVU6FYP8vj5qiJSXh9MxZZCu g5L0k4/mGUv0qWLLGPqSINnKFOwA+lLhQIgGdJi9Ifz8kNaE7uoXNHXvT6hyHqXgnSdP SBOg== MIME-Version: 1.0 Received: by 10.220.141.139 with SMTP id m11mr570852vcu.56.1332276033345; Tue, 20 Mar 2012 13:40:33 -0700 (PDT) Received: by 10.220.106.200 with HTTP; Tue, 20 Mar 2012 13:40:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 16:40:33 -0400 Message-ID: From: brennan security To: Stephen Kent Content-Type: multipart/alternative; boundary=f46d042f9dcab5d66a04bbb2af01 Cc: pkix@ietf.org Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 20:40:34 -0000 --f46d042f9dcab5d66a04bbb2af01 Content-Type: text/plain; charset=ISO-8859-1 Does the PKIX prefer text, or slides? I'm new and inclined to break some cardinal rules. -b On Tue, Mar 20, 2012 at 2:38 PM, Stephen Kent wrote: > At 2:17 PM -0400 3/20/12, brennan security wrote: > >> Stephen, >> >> >> I volunteered to write up something on this, and am working on it now. >> >> -b >> >> > I remember, and I am not trying to push you to publish that doc > faster. I just don't want folks to spend a lot of time haggling over > solution details at this stage. > > Steve > --f46d042f9dcab5d66a04bbb2af01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does the PKIX prefer text, or slides? I'm new and inclined to brea= k some cardinal rules.

-b

=
On Tue, Mar 20, 2012 at 2:38 PM, Stephen Kent <kent@bbn.com> wrote:
At 2:17 PM -0400 3/20/12, = brennan security wrote:
Stephen,


I volunteered to write up something on this, and am working on it now.

-b


I remember, and I am not trying to push you to publish that doc
faster. =A0I just don't want folks to spend a lot of time haggling over=
solution details at this stage.

Steve

--f46d042f9dcab5d66a04bbb2af01-- From paul.hoffman@vpnc.org Tue Mar 20 13:54:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C749621F8637 for ; Tue, 20 Mar 2012 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhHYgHnZLuJA for ; Tue, 20 Mar 2012 13:54:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C160421F85AD for ; Tue, 20 Mar 2012 13:54:22 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KKsIwi029806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 13:54:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Tue, 20 Mar 2012 13:54:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1582F872-D6D6-4E1F-82A3-134AF80D4CAE@vpnc.org> References: To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 20:54:25 -0000 On Mar 20, 2012, at 1:40 PM, brennan security wrote: > Does the PKIX prefer text, or slides? I'm new and inclined to break = some cardinal rules. Speaking only for myself: an Internet Draft is strongly preferred. It = can be pointed to, diffs between versions are easy to find, and = discussions of drafts tend to stay more focused than discussions about a = long email message. If preparing a -00 draft is daunting to you, I'm happy to help, even for = a draft I don't agree with. :-) --Paul Hoffman From hallam@gmail.com Tue Mar 20 13:54:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3DE21F860B for ; Tue, 20 Mar 2012 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHg64+0tuusE for ; Tue, 20 Mar 2012 13:54:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33CA021F85AC for ; Tue, 20 Mar 2012 13:54:21 -0700 (PDT) Received: by yhkk25 with SMTP id k25so543536yhk.31 for ; Tue, 20 Mar 2012 13:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QLcMoQ+/5UcfQBlBDgcA/FCc9Jq3qkxubx2ySs6EId8=; b=Ns4n5mPX1TsT85DLYO2MJ950rqsdE7tbymD5UPDTt9i9IPJCx8R1RYLmx/ESbk4jwg GGjVYnv76HY+uPcPekmDLyAkixoiBIj6vlpXyY1e4piD5QBA36mGpyx7Lq7eGjqGRI3i kBsRqnla0zS9ZYqcsJW1rMCuKq1iJFcQVJz2L2E+mQA/ahLVPsxDT4iE76YdoEz4UUSG j9wPW3+xH7/RS6ojJ8kRru3SPb4H/NGteaBHaAk7yyAV/HKg7r2KL+KLIF4B9hZvFSbp ROwV6JHA3Kf67fx06V/eqyskfb/ScsXVPiaFmfEcjWlhO6Fjimqh6Or+80BGzcUM6q3F SlEg== MIME-Version: 1.0 Received: by 10.60.20.100 with SMTP id m4mr1958385oee.10.1332276861390; Tue, 20 Mar 2012 13:54:21 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 20 Mar 2012 13:54:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 16:54:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 20:54:25 -0000 Wrong. I suggest that if you are going to attack other people's competence in this field you take the time to learn about it first. OCSP was not intended to be limited to responding from a CRL. The CRL is not the authoritative source even today. A CA can meet the PKIX requirement to issue a CRL at much longer intervals than the OCSP response updates. On Tue, Mar 20, 2012 at 4:09 PM, Santosh Chokhani wrote: > Why not just go with the terms CRL and not on CRL since CRL is the primar= y source. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= iller, Timothy J. > Sent: Tuesday, March 20, 2012 4:00 PM > To: Carl Wallace > Cc: > Subject: Re: [pkix] Possible OCSP Extensions > > On Mar 20, 2012, at 2:18 PM, Carl Wallace wrote: > >> As currently written where? > > The response code says it's "good" and *everyone* knows what that means, = right? > > The sarcasm should be obvious. > > The clarifying text even calls out the problem with this response code! > > Here's a rule of thumb: =A0Any specification that includes the phrase "..= .does not necessarily mean..." should immediately be rewritten. =A0:) > >> Adding an extension to return proof of existence would be easy enough >> and would not break backwards compatibility. =A0Adding additional status >> values or changing the meaning of existing status values would. >> Clients that want to fail without the extra proof could do so. > > IMHO, OCSP only needs two response codes: =A0REVOKED and OTHER, where OTH= ER means the cert does *not* match records on the CRL. =A0This doesn't mean= the cert is good, bad, or someone else's, it just means the revocation sta= tus could not be determined. =A0REVOKED should induce a hard failure, and O= THER should not. =A0Three codes *in the base case* introduced ambiguity bec= ause the only additional information the third code (GOOD) tells you is "th= e cert *appears to be* one of mine," and "appears to be" isn't actually con= veying any actual information. [1] > > -- T > [1] If you want more than this, OTHER could be qualified by extensions; e= .g., NOTMINE (certificate wasn't issued by the cognizant CA), BOGUS (certif= icate appears to belong to the cognizant CA but doesn't match the cognizant= CA's list of things that should exist), or EXCELLENT (certificate does mat= ch the cognizant CA's list of things that should exist). > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Mar 20 14:04:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BD21F85A3 for ; Tue, 20 Mar 2012 14:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wlnCzPX9MlO for ; Tue, 20 Mar 2012 14:04:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7381E21F85A2 for ; Tue, 20 Mar 2012 14:04:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so556751yen.31 for ; Tue, 20 Mar 2012 14:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QzopvNc540vDVWvPRQ0AgWM8OPJxPqo7NFjeW5IK808=; b=SAl7g/P8M5Rhp0dJDR4L4Pm9PUUDG8rqbWUXXtEUT2v7QtnmDu16bpNtpLaTfyx2pc JcC5xLKWaap//LPoKhmiqbn5NrMKdgXc1PbKd6xdyJuHzX6HIvwdn+mph0wNY1XlXcTE f1SGtOA7TH0VKFwqLqcknEmXzpEuvH1dAuUGF7UMbd/P4WvLrBQqphiqGWhrQ+dNAF2d 5M5YrrwovAP9y93s8a9xjgN8Qwwg7ixuH41P39NcDotMKvl+PkJEwS+i83a3rY6ycqj/ nMnyuixfXEmxjpzWEUn8Hf5YrNzb27LLzGz51+swyZQ4enyWnwGwCO5HyzgNC2LoKTlt 07aQ== MIME-Version: 1.0 Received: by 10.60.25.162 with SMTP id d2mr1916048oeg.30.1332277463787; Tue, 20 Mar 2012 14:04:23 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 20 Mar 2012 14:04:23 -0700 (PDT) In-Reply-To: References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> Date: Tue, 20 Mar 2012 17:04:23 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 21:04:25 -0000 We have a hard constraint that it be possible to pre-sign all signed OCSP responses. That is an operational necessity. If the OCSP responder is going to be required to always return a signed response we need to have the ability to do range responses. This will be a new requirement but essential for transparency. Since a range response is only going to make sense for not-issued it is going to be interpreted as such anyway. I really fail to see why this proposal results in the responses it does. Particularly given the number of boondoggles and curlicues that the DoD faction has required of the spec: Policy constraints, attribute certs, SCVP. All I am looking to do here is to make the public CA system work effectively. If the DoD faction can't live with that then I'll take the proposal elsewhere and if it gets deployed we will end up in the spec being spread across three standards orgs instead of the two it is split across at present. On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. wro= te: > The word GOOD directly contradicts the RFC 2560 paragraph describing it. > A certificate that was never issued or is outside its validity period > cannot, under any reasonable English language interpretation, be > considered "good". =A0 Whereas UNKNOWN is a reasonable word to use for a > certificate that may or may not exist, but is definitely not revoked. > Modifying OCSP responders to never send a deprecated GOOD response does > not change the meaning of that response. =A0And unless the default client > behavior is to fail on UNKNOWN, changing responders to use it for all > non-revoked certificates does not affect client behavior. > > Excellent point regarding proof of existence. =A0There is no need to > change the OCSP request in any way. =A0The extension can be sent at the > discretion of the responder, the client can validate the proof since it > already has a copy of the certificate being checked, and the client can > follow its own policy for handling responses without the extension or > responses with proofs that don't match the certificate. =A0That is > backwards compatibility at its best, and although I'm skeptical of using > OCSP to address PHB's NOT-ISSUED requirement, the proof-of-issuance > extension seems quite straightforward. > > Dave > > > -----Original Message----- > From: Carl Wallace > > On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >> As currently written, allowing GOOD without qualifier leads to >> incorrect interpretation of the protocol. =A0I.e., for most OCSP >> Responders only REVOKED or UNKNOWN should be sent. > > As currently written where? =A0RFC2560 states the following: > > =A0 The "good" state indicates a positive response to the status inquiry. > =A0 At a minimum, this positive response indicates that the certificate > =A0 is not revoked, but does not necessarily mean that the certificate > =A0 was ever issued or that the time at which the response was produced > =A0 is within the certificate's validity interval. Response extensions > =A0 may be used to convey additional information on assertions made by > =A0 the responder regarding the status of the certificate such as > =A0 positive statement about issuance, validity, etc. > > > Adding an extension to return proof of existence would be easy enough > and would not break backwards compatibility. =A0Adding additional status > values or changing the meaning of existing status values would. =A0Client= s > that want to fail without the extra proof could do so. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From turners@ieca.com Tue Mar 20 14:13:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7421F867A for ; Tue, 20 Mar 2012 14:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMCt-wgJf-Fg for ; Tue, 20 Mar 2012 14:13:09 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.248.83]) by ietfa.amsl.com (Postfix) with ESMTP id A00DB21F8678 for ; Tue, 20 Mar 2012 14:13:09 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 67B2414586D9E; Tue, 20 Mar 2012 16:13:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 5D0F714586D65 for ; Tue, 20 Mar 2012 16:13:08 -0500 (CDT) Received: from [96.231.117.46] (port=36248 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SA6Md-0005S5-Qo for pkix@ietf.org; Tue, 20 Mar 2012 16:13:07 -0500 Message-ID: <4F68F2E4.4010309@ieca.com> Date: Tue, 20 Mar 2012 17:13:08 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: PKIX References: <1582F872-D6D6-4E1F-82A3-134AF80D4CAE@vpnc.org> In-Reply-To: <1582F872-D6D6-4E1F-82A3-134AF80D4CAE@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-117-46.washdc.east.verizon.net (thunderfish.local) [96.231.117.46]:36248 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 21:13:10 -0000 On 3/20/12 4:54 PM, Paul Hoffman wrote: > On Mar 20, 2012, at 1:40 PM, brennan security wrote: > >> Does the PKIX prefer text, or slides? I'm new and inclined to break some cardinal rules. > > Speaking only for myself: an Internet Draft is strongly preferred. It can be pointed to, diffs between versions are easy to find, and discussions of drafts tend to stay more focused than discussions about a long email message. +1 to the I-D > If preparing a -00 draft is daunting to you, I'm happy to help, even for a draft I don't agree with. :-) > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Tue Mar 20 14:22:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A25521F8664 for ; Tue, 20 Mar 2012 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DQ3EhRoOeg0 for ; Tue, 20 Mar 2012 14:22:37 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E32D21F865A for ; Tue, 20 Mar 2012 14:22:36 -0700 (PDT) Received: by ggmi1 with SMTP id i1so578579ggm.31 for ; Tue, 20 Mar 2012 14:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lx2tQjvM0cZQUnVxAqQGbSnKFu3jAkJA3tjtPS7sW6U=; b=j/CMqNzGkWIAD9AqfTXsGnr/MBycTGFbWndV53j+z9t0gP3KkqbTEAGjCRNJORuBmg VrMtPR51+6KlWl83bOe+FRBib/7axwQHkcV57ZQIgUyDVBAD23tWP4tAuDbPrAd2zDRo HvYVlocR+AlxhqZOoZuD2aFmun0NydGiLA37jzOfyEkbB4aoitvqBhyHd75M0SR6omA8 Xj6S0WAnuUfDEFasMXSnX92UrtujCD7UoyboHv/5qjirgoNXFbPumCnUpl0CN97FicAx mTqeRiQd1UVhhuIsN2yOJjexn18FMfLuBq8jOT0VcByGZFSNmQI8F1e0qmZLseTJoapw P7fA== MIME-Version: 1.0 Received: by 10.182.114.70 with SMTP id je6mr1971215obb.30.1332278555377; Tue, 20 Mar 2012 14:22:35 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Tue, 20 Mar 2012 14:22:35 -0700 (PDT) In-Reply-To: <4F68F2E4.4010309@ieca.com> References: <1582F872-D6D6-4E1F-82A3-134AF80D4CAE@vpnc.org> <4F68F2E4.4010309@ieca.com> Date: Tue, 20 Mar 2012 17:22:35 -0400 Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: PKIX Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 21:22:38 -0000 I will convert the post I sent in earlier today into an ID and send it in as soon as the queue opens. On Tue, Mar 20, 2012 at 5:13 PM, Sean Turner wrote: > On 3/20/12 4:54 PM, Paul Hoffman wrote: >> >> On Mar 20, 2012, at 1:40 PM, brennan security wrote: >> >>> Does the PKIX prefer text, or slides? I'm new and inclined to break some >>> cardinal rules. >> >> >> Speaking only for myself: an Internet Draft is strongly preferred. It can >> be pointed to, diffs between versions are easy to find, and discussions of >> drafts tend to stay more focused than discussions about a long email >> message. > > > +1 to the I-D > > >> If preparing a -00 draft is daunting to you, I'm happy to help, even for a >> draft I don't agree with. :-) >> >> --Paul Hoffman >> >> _______________________________________________ >> 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 -- Website: http://hallambaker.com/ From kent@bbn.com Tue Mar 20 14:47:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8321E8029 for ; Tue, 20 Mar 2012 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWnUjJZsaXRN for ; Tue, 20 Mar 2012 14:47:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD6C21E8015 for ; Tue, 20 Mar 2012 14:47:31 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49163) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA6tj-000P85-BS; Tue, 20 Mar 2012 17:47:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 20 Mar 2012 17:40:27 -0400 To: brennan security From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] discussion drifting ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 20 Mar 2012 21:47:31 -0000 At 4:40 PM -0400 3/20/12, brennan security wrote: >Does the PKIX prefer text, or slides? I'm new and inclined to break >some cardinal rules. > thanks for asking: text is required, see http://www.ietf.org/id-info/guidelines.html Steve From carl@redhoundsoftware.com Tue Mar 20 15:24:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EC321F8514 for ; Tue, 20 Mar 2012 15:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdMGZTO0DxFf for ; Tue, 20 Mar 2012 15:24:22 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00C21F8513 for ; Tue, 20 Mar 2012 15:24:21 -0700 (PDT) Received: by qcsq13 with SMTP id q13so305658qcs.31 for ; Tue, 20 Mar 2012 15:24:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=C1iHA7L2QDMHp9qc1oNdSV20Fn1xNRza7XNWOFWQzXA=; b=W4QWIkWSYfzpjdx8OS5yLxN1/JPr0mUXd9VMedMIOMOsTEzWXR+5nDTIW8WTTXJpRy x7THLdQzNJVGNeBbKy0VKnY7SJS0H4sYoioGG6jFPXylmrrTHVcNfMF/w3pfwyFBrSwx l0Zv42J49mWyyrThPNs7T3ExdlcZaupAiXZKjWaPeYbJZbne7/L4RJQvmSYhcX6UboqX 26aZFhrVAMK1zaoGq4aIdgyil8uZVtCY+rLcPkRs/X9pIAMDcnAvizRGsulEVOAbqTRA Z2pQEvVUBwomxAlRWsk+3KqCiWO3f2HlKJ+8zel0gIqEdUy64Mw66uvi85EzuqwbeZG3 s0IA== Received: by 10.224.173.141 with SMTP id p13mr3082154qaz.82.1332282261498; Tue, 20 Mar 2012 15:24:21 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id f12sm4940774qan.1.2012.03.20.15.24.18 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 15:24:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 20 Mar 2012 18:24:09 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Possible OCSP Extensions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQn2jZLjio9ER4fdy20d4ntojGYxecYOiLWnlen7ezqNTvDEjUjOP4/6XwDLmh3xJzKeN55X Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 20 Mar 2012 22:24:23 -0000 On 3/20/12 5:04 PM, "Phillip Hallam-Baker" wrote: >We have a hard constraint that it be possible to pre-sign all signed >OCSP responses. That is an operational necessity. A proof of existence extension would not break the ability to pre-sign responses. As with any extension, it would make responses larger though. > >If the OCSP responder is going to be required to always return a >signed response we need to have the ability to do range responses. >This will be a new requirement but essential for transparency. > > >Since a range response is only going to make sense for not-issued it >is going to be interpreted as such anyway. A range response extension could be a form of proof of (non-)existence (at least at the time the pre-signing was done). The extension could also include a pointer for where to send the offending certificate so corrective actions can be taken if necessary. However, there are still unanswered questions on the list regarding how to square range signing with on-going certificate issuance with random serial numbers. > >I really fail to see why this proposal results in the responses it >does. Perhaps because it needs more work. For example, it requires CAs to maintain a complete log. This seems like an odd requirement in a proposal that is addressing a problem in which the CA lost control of their log. It also leaves some important things unaddressed. For example, is there any operational necessity for backwards compatibility? It seems odd to want to use an existing protocol but break backwards compatibility. If you are collecting requirements for transparency work, you should add publication of all CA certificates. A proof of existence-based approach might be a good thing for transparency. It would ensure the CA is not up to no good if a bad certificate is found since the check that determines the certificate is no good is performed on the client side. Of course, to mention another unaddressed point from the list, any extra check is moot depending on the nature of the compromise and whether bad certificates can be distinguished from good ones. >Particularly given the number of boondoggles and curlicues that >the DoD faction has required of the spec: Policy constraints, >attribute certs, SCVP. > >All I am looking to do here is to make the public CA system work >effectively. OK. >If the DoD faction can't live with that then I'll take >the proposal elsewhere and if it gets deployed we will end up in the >spec being spread across three standards orgs instead of the two it is >split across at present. > > >On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. >wrote: >> The word GOOD directly contradicts the RFC 2560 paragraph describing it. >> A certificate that was never issued or is outside its validity period >> cannot, under any reasonable English language interpretation, be >> considered "good". Whereas UNKNOWN is a reasonable word to use for a >> certificate that may or may not exist, but is definitely not revoked. >> Modifying OCSP responders to never send a deprecated GOOD response does >> not change the meaning of that response. And unless the default client >> behavior is to fail on UNKNOWN, changing responders to use it for all >> non-revoked certificates does not affect client behavior. >> >> Excellent point regarding proof of existence. There is no need to >> change the OCSP request in any way. The extension can be sent at the >> discretion of the responder, the client can validate the proof since it >> already has a copy of the certificate being checked, and the client can >> follow its own policy for handling responses without the extension or >> responses with proofs that don't match the certificate. That is >> backwards compatibility at its best, and although I'm skeptical of using >> OCSP to address PHB's NOT-ISSUED requirement, the proof-of-issuance >> extension seems quite straightforward. >> >> Dave >> >> >> -----Original Message----- >> From: Carl Wallace >> >> On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >>> As currently written, allowing GOOD without qualifier leads to >>> incorrect interpretation of the protocol. I.e., for most OCSP >>> Responders only REVOKED or UNKNOWN should be sent. >> >> As currently written where? RFC2560 states the following: >> >> The "good" state indicates a positive response to the status inquiry. >> At a minimum, this positive response indicates that the certificate >> is not revoked, but does not necessarily mean that the certificate >> was ever issued or that the time at which the response was produced >> is within the certificate's validity interval. Response extensions >> may be used to convey additional information on assertions made by >> the responder regarding the status of the certificate such as >> positive statement about issuance, validity, etc. >> >> >> Adding an extension to return proof of existence would be easy enough >> and would not break backwards compatibility. Adding additional status >> values or changing the meaning of existing status values would. Clients >> that want to fail without the extra proof could do so. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Tue Mar 20 17:04:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCB21E801A for ; Tue, 20 Mar 2012 17:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.941 X-Spam-Level: X-Spam-Status: No, score=-9.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5fOGIdFlf5V for ; Tue, 20 Mar 2012 17:04:17 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id B231721E800C for ; Tue, 20 Mar 2012 17:04:17 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 20 Mar 2012 18:04:17 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 20 Mar 2012 18:04:16 -0600 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 809CCC90062 for ; Tue, 20 Mar 2012 20:04:15 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2L04FMr3448910 for ; Tue, 20 Mar 2012 20:04:15 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2L04FML002230 for ; Tue, 20 Mar 2012 20:04:15 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2L04F2o002221; Tue, 20 Mar 2012 20:04:15 -0400 In-Reply-To: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> References: <85831FD1-AC90-4020-8404-BC006100A26C@mitre.org> To: "Miller, Timothy J." MIME-Version: 1.0 X-KeepSent: 01A56E0A:7272D7A6-852579C7:0054BC44; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 20 Mar 2012 20:04:13 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/20/2012 20:04:15, Serialize complete at 03/20/2012 20:04:15 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032100-6148-0000-0000-00000469C8F5 Cc: pkix Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 00:04:19 -0000 I wish OCSP v1 had looked like #1 for CRL-only responders, but I think it's unrealistic to go there from RFC 2560. That change is so far from backwards compatibility that it demands a new protocol, and a large class of clients are really just looking for "revoked" vs. "not known to be revoked" and would have no reason to migrate from v1 to this model. Thus, I propose an extension (obviously optional and non-critical) to be used with GOOD giving the operating model. I agree with #2 except for the statement about certificate evidence. It's perfectly legitimate to choose "unknown", "good", or "revoked" based solely on the serial number in v1, and I see little reason to change that feature of the protocol. For #3, although I'm the one who started the discussion over NOTISSUED, NOTISSUED will work perfectly well as an extension to "unknown" (as will "expired"). I'm trying to extend the protocol rather than to break it. This is especially true since "unknown", "within validity period", and "old enough to have been published" implies NOTISSUED. For anyone who wants to see a strawman, the extension I mentioned in #1 might have the following syntax, as a singleExtension used only with GOOD: ResponseBasis ::= SEQUENCE { certIdentified BOOLEAN DEFAULT FALSE -- TRUE if it's in a full repository } This is an extension partly to avoid changing the current definition of CertStatus' good element as IMPLICIT NULL, and making it contain IMPLICIT BOOLEAN DEFAULT FALSE instead would break existing clients. As a responseExtension, the boolean's name changes to "fullRepository" but its basic meaning stays the same. An alternative form for the response extension would be a three-valued enum called operatingModel { CRL, fullRepository, revokedRepository }. Since I think that there's little difference which matters to the client between the "revoked certificate status DB" and a "CRL-fed" model which has just gotten a CRL, I prefer the boolean form. Tom Gindin From: "Miller, Timothy J." To: Tom Gindin/Watson/IBM@IBMUS, Cc: "Henry B. Hotz" , pkix Date: 03/20/2012 09:42 AM Subject: Re: [pkix] Possible OCSP Extensions So would this be a fair summary of the range of possible responses? 1) A Responder with no access to the CA history has only two possible responses: REVOKED - Certificate identified by the Request is on a CRL. UNKNOWN - All other queries. 2) A Responder with access to the CA history, if and only if certificate evidence is provided in the Request, may also respond: GOOD - An exact match for the certificate in the Request is found in the CA history, and that certificate is not on a CRL. 3) A Responder with access to the CA history, if and only if certificate *and chain* evidence is provided in the Request, may also respond: NOTISSUED - The certificate in the Request chains to the cognizant CA but no exact match for the certificate is found in the CA history. "Certificate evidence" must be a sufficiently unique CertID. I'd want a cert thumbprint at the least; a copy of the cert itself at most. If the Responder is operating as a Trusted Responder, the relying party won't be able to detect name collisions if only Issuer/Serial is used. CA-signed and CA-Designated can detect name collisions because the queried cert won't chain to the same trust anchor as the OCSP Response signature, but they have to be specifically directed to make this check. "Certificate and chain evidence" will probably have to be the certificate itself, though if anyone has alternative ideas I'm all ears. IMHO this is required for NOTISSUED because it's the only way to prevent a malicious querent from messing up your day with falsified certificate evidence. A query that doesn't match anything in the CA history is *not* enough evidence of compromise unless it can be shown to be a cert that actually chains to the cognizant CA. I think the above is close to full coverage, but it's also a complete overhaul of OCSP. I'd call it a new protocol, though I don't know enough about SCVP to say whether or not this functions can be replicated with that protocol. -- T On Mar 20, 2012, at 7:24 AM, Tom Gindin wrote: > Actually, my lack of participation was more physical exhaustion > than a result of the emotional temperature of the discussions. There are > probably others who are more bothered than me by that level, and if I > typically sent out my initial draft responses I would probably contribute > to the problem. Given my limited practical experience with OCSP, I'm > going to make some naive comments below, after starting with a statement > of what I at least think needs to be resolved. > One outstanding problem is that a client often cannot distinguish > "good" from merely "unrevoked", or even be aware that the responder is not > making such a distinction. The other is for a client to provide evidence > that a certificate is in circulation which is not expected to be by the > responder. My other suggestion below about using the issuer's SIA for > id-ad-ocsp is unrelated to these, and is intended to reduce the chances of > an attacker diverting the revocation check to a server under his own > controls. > I do wonder what the point is to having OCSP support an "unknown" > status code if it's appropriate for a responder to return "good" on a > serial number that was never issued. The natural meaning of the words > would suggest to me that a CRL-only OCSP responder should call its two > status values "revoked" and "unknown" rather than "revoked" and "good". > One could probably argue that never using "good" is consistent with the > literal wording of RFC 2560 section 2.2, but it certainly isn't the common > practice. Thus I consider that the current "good" status would mean more > to high-reliance RP's if it were accompanied by an extension telling the > client whether "good" includes "unknown" or not. That's not exactly > Denis' position, but it's close to it. > Next, I am surprised that the reporting extension in which a > client can provide evidence of a certificate's actual existence has drawn > little comment. I would think that, in conjunction with either "unknown" > or "neverIssued", that extension allows a client to report a possible > issuer breach inside the protocol. In particular, I think that it answers > Dave Cooper's objection of Friday, because a major point to this set of > proposed changes is to permit a client to test his suspicion of a > compromise. It's perfectly true that a client who's inside a DNS > masquerade environment will gain little from unsigned OCSP responses of > any type. While using an OCSP URL with an IP address would avoid the DNS > masquerade, no attacker's subject certificate will create such a value > (although RA compromises would probably not change the AIA extension in > most CA's). > Last, I am not sure why it's a good thing that id-ad-ocsp is > recommended to be placed into the subject certificate's AIA extension > rather than into the issuer's SIA. I realize that this provides greater > flexibility for an issuer to change its practices over time, but letting > an attacker redirect OCSP URL's is a bad thing (and Santosh is right that > it's far too easy, although not about Phill's analytic skills). CRLDP > partitioning is a reason for that revocation mechanism to be in the > subject certificate rather than the issuer one, but why should that > precedent govern OCSP? A migration path to change this would start by > recommending that an SIA value in the issuer certificate SHOULD take > precedence over an AIA value in the subject one if both values are > present. > > > Tom Gindin > > > > > From: "Henry B. Hotz" > To: Stephen Kent , > Cc: pkix > Date: 03/19/2012 04:26 PM > Subject: Re: [pkix] Possible OCSP Extensions > Sent by: pkix-bounces@ietf.org > > > > > On Mar 19, 2012, at 8:42 AM, Stephen Kent wrote: > >> At 12:01 PM -0700 3/16/12, Henry B. Hotz wrote: >>> Suppose we accept both your arguments below, and Stephen Kent's > arguments that SCVP is the right solution for the real problem faced by > ordinary users. >> >> Steve Kent didn't say that. > > OK, OK. I admit I'm stretching a point to try to find common ground. > > I'm kind of disappointed by how acrimonious the discussions of this > feature (and on this list in general) have been. I'm guessing that is why > we haven't heard from Tom Gundin, the guy who started this thread, in a > while. > >> He said that PKIX decided to develop SCVP instead of extending OCSP, > when we lasted visited this sort of topic. In later messages I noted that > folks did not except public CAs to operate SCVP servers; SCVP is best > suited for enterprise environments. >> >> Steve > > ------------------------------------------------------ > 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 > > _______________________________________________ > 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 SChokhani@cygnacom.com Wed Mar 21 06:50:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95CD21F8668 for ; Wed, 21 Mar 2012 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z86yZsLPU42d for ; Wed, 21 Mar 2012 06:50:24 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 813F621F865B for ; Wed, 21 Mar 2012 06:50:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,623,1325480400"; d="scan'208";a="4459029" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 21 Mar 2012 09:50:23 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 21 Mar 2012 09:50:23 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Wed, 21 Mar 2012 09:49:43 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0G26Cb8lnpAQ7DS2G/DFwK2ZXo1wAjcR5Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 13:50:26 -0000 PHB, All a pre-signer can do is say revoked/on CRL or not revoked/not on CRL. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Tuesday, March 20, 2012 4:54 PM To: Santosh Chokhani Cc: Miller, Timothy J.; Carl Wallace; Subject: Re: [pkix] Possible OCSP Extensions Wrong. I suggest that if you are going to attack other people's competence in this= field you take the time to learn about it first. OCSP was not intended to be limited to responding from a CRL. The CRL is no= t the authoritative source even today. A CA can meet the PKIX requirement t= o issue a CRL at much longer intervals than the OCSP response updates. On Tue, Mar 20, 2012 at 4:09 PM, Santosh Chokhani = wrote: > Why not just go with the terms CRL and not on CRL since CRL is the primar= y source. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= iller, Timothy J. > Sent: Tuesday, March 20, 2012 4:00 PM > To: Carl Wallace > Cc: > Subject: Re: [pkix] Possible OCSP Extensions > > On Mar 20, 2012, at 2:18 PM, Carl Wallace wrote: > >> As currently written where? > > The response code says it's "good" and *everyone* knows what that means, = right? > > The sarcasm should be obvious. > > The clarifying text even calls out the problem with this response code! > > Here's a rule of thumb: =A0Any specification that includes the phrase=20 > "...does not necessarily mean..." should immediately be rewritten. =A0:) > >> Adding an extension to return proof of existence would be easy enough=20 >> and would not break backwards compatibility. =A0Adding additional=20 >> status values or changing the meaning of existing status values would. >> Clients that want to fail without the extra proof could do so. > > IMHO, OCSP only needs two response codes: =A0REVOKED and OTHER, where=20 > OTHER means the cert does *not* match records on the CRL. =A0This=20 > doesn't mean the cert is good, bad, or someone else's, it just means=20 > the revocation status could not be determined. =A0REVOKED should induce=20 > a hard failure, and OTHER should not. =A0Three codes *in the base case*=20 > introduced ambiguity because the only additional information the third=20 > code (GOOD) tells you is "the cert *appears to be* one of mine," and=20 > "appears to be" isn't actually conveying any actual information. [1] > > -- T > [1] If you want more than this, OTHER could be qualified by extensions; e= .g., NOTMINE (certificate wasn't issued by the cognizant CA), BOGUS (certif= icate appears to belong to the cognizant CA but doesn't match the cognizant= CA's list of things that should exist), or EXCELLENT (certificate does mat= ch the cognizant CA's list of things that should exist). > > _______________________________________________ > 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 -- Website: http://hallambaker.com/ From SChokhani@cygnacom.com Wed Mar 21 06:55:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB5F21F8648 for ; Wed, 21 Mar 2012 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0rkh4PBBhOr for ; Wed, 21 Mar 2012 06:55:02 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5121F8634 for ; Wed, 21 Mar 2012 06:55:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,623,1325480400"; d="scan'208";a="603234" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 21 Mar 2012 09:55:01 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 21 Mar 2012 09:55:01 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker , "Kemp, David P." Date: Wed, 21 Mar 2012 09:54:12 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0G3Qpv9KsM+YBdT0yZrG6G3MNy3QAjO4vg Message-ID: References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 13:55:03 -0000 PHB, As Steve said, let us identify the requirements first, then see how valid t= hey are and then we can debate the solutions. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phi= llip Hallam-Baker Sent: Tuesday, March 20, 2012 5:04 PM To: Kemp, David P. Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions We have a hard constraint that it be possible to pre-sign all signed OCSP r= esponses. That is an operational necessity. If the OCSP responder is going to be required to always return a signed res= ponse we need to have the ability to do range responses. This will be a new requirement but essential for transparency. Since a range response is only going to make sense for not-issued it is goi= ng to be interpreted as such anyway. I really fail to see why this proposal results in the responses it does. Pa= rticularly given the number of boondoggles and curlicues that the DoD facti= on has required of the spec: Policy constraints, attribute certs, SCVP. All I am looking to do here is to make the public CA system work effectivel= y. If the DoD faction can't live with that then I'll take the proposal else= where and if it gets deployed we will end up in the spec being spread acros= s three standards orgs instead of the two it is split across at present. On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. wro= te: > The word GOOD directly contradicts the RFC 2560 paragraph describing it. > A certificate that was never issued or is outside its validity period=20 > cannot, under any reasonable English language interpretation, be=20 > considered "good". =A0 Whereas UNKNOWN is a reasonable word to use for a= =20 > certificate that may or may not exist, but is definitely not revoked. > Modifying OCSP responders to never send a deprecated GOOD response=20 > does not change the meaning of that response. =A0And unless the default=20 > client behavior is to fail on UNKNOWN, changing responders to use it=20 > for all non-revoked certificates does not affect client behavior. > > Excellent point regarding proof of existence. =A0There is no need to=20 > change the OCSP request in any way. =A0The extension can be sent at the=20 > discretion of the responder, the client can validate the proof since=20 > it already has a copy of the certificate being checked, and the client=20 > can follow its own policy for handling responses without the extension=20 > or responses with proofs that don't match the certificate. =A0That is=20 > backwards compatibility at its best, and although I'm skeptical of=20 > using OCSP to address PHB's NOT-ISSUED requirement, the=20 > proof-of-issuance extension seems quite straightforward. > > Dave > > > -----Original Message----- > From: Carl Wallace > > On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >> As currently written, allowing GOOD without qualifier leads to=20 >> incorrect interpretation of the protocol. =A0I.e., for most OCSP=20 >> Responders only REVOKED or UNKNOWN should be sent. > > As currently written where? =A0RFC2560 states the following: > > =A0 The "good" state indicates a positive response to the status inquiry. > =A0 At a minimum, this positive response indicates that the certificate > =A0 is not revoked, but does not necessarily mean that the certificate > =A0 was ever issued or that the time at which the response was produced > =A0 is within the certificate's validity interval. Response extensions > =A0 may be used to convey additional information on assertions made by > =A0 the responder regarding the status of the certificate such as > =A0 positive statement about issuance, validity, etc. > > > Adding an extension to return proof of existence would be easy enough=20 > and would not break backwards compatibility. =A0Adding additional status= =20 > values or changing the meaning of existing status values would. =A0 > Clients that want to fail without the extra proof could do so. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Wed Mar 21 07:00:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE28221F86E1 for ; Wed, 21 Mar 2012 07:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eLbFOdypNHy for ; Wed, 21 Mar 2012 07:00:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB4721F86E0 for ; Wed, 21 Mar 2012 07:00:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 00D0F21B056D; Wed, 21 Mar 2012 10:00:33 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D624421B0B44; Wed, 21 Mar 2012 10:00:32 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.44]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Wed, 21 Mar 2012 10:00:32 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNA3QWe3S8XWTYQEqfNuOgbNpcQpZtKMIAgAAxIICAADDHAIAEf1+AgABO7wCAAQwJAIAAFOgAgAAW2ICAAAzJgIAABpAAgAAJlQD//75OkIAAZyaAgAAFbQCAABTjAIAACMCAgAEb6IA= Date: Wed, 21 Mar 2012 14:00:32 +0000 Message-ID: <38907793-66BD-49DD-9C49-D658165C69CB@mitre.org> References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.240] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5587A6384F33E343AE2298D3166D287E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 14:00:34 -0000 On Mar 20, 2012, at 4:04 PM, Phillip Hallam-Baker wrote: > We have a hard constraint that it be possible to pre-sign all signed > OCSP responses. That is an operational necessity. >=20 > If the OCSP responder is going to be required to always return a > signed response we need to have the ability to do range responses. > This will be a new requirement but essential for transparency. While response ranges would help with pre signing, I don't see how to do th= is and retain backward compatibility. Still thinking about that one. That said, CRL-fed pre-signers for PKIs with sequential serials currently c= ope with the gap between highest-revoked and highest-issued. I know one im= plementation takes the highest-revoked serial, adds a skew, and signs a "go= od" response for everything in between. This is probably less than ideal, = but as long as proof sets are generated at least as often as CRLs it doesn'= t create a problem. If not-issued is added to the specification, this approach doesn't have to = change. Alternatively, a Responder with only pre-signed proofs can refer a= ny request for status for a cert in the "gap" to another Responder with the= necessary information where a live response can be generated. The DoD cur= rently does this for requests for certs that aren't in the pre-signed set.= =20 Again, less than ideal, but as long as proof sets follow CRLs closely enoug= h it's a problem that can be managed operationally. > Since a range response is only going to make sense for not-issued it > is going to be interpreted as such anyway. Actually, I see utility for response ranges regardless of disposition of no= t-issued as a concept. The PKI I support would definitely benefit if only = because the generation workload and resulting proof set size could be drama= tically reduced. > I really fail to see why this proposal results in the responses it > does. I'll speak only for myself, but for me it's because you're worrying about a= corner case with a vanishingly small probability of actually occurring in = the field. Specifically, not-issued conveys actionable information only wh= en the OCSP Responder key is provably secure, the CA history has provable i= ntegrity, but the CA signing key has been compromised. Yes, that's one pos= sible set of circumstances, but it's just not worth bothering about; a posi= tion I feel is bolstered by the most recent commercial CA compromises that = show that CA signing key security and CA history integrity go hand-in-glove= . =20 Throw in the fact that the scheme is only implementable by Responders with = access to the CA history, which anecdotally appears to be a minority of dep= loyed Responders anyway, and the scheme's utility is even further reduced. I'm far more interested in response ranges because of potential performance= gains for deployed systems, and in improving OCSP overall by addressing th= e ambiguity of the current set of responses. -- T From SChokhani@cygnacom.com Wed Mar 21 07:07:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2470A21F862A for ; Wed, 21 Mar 2012 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLJ35Tft+Y2h for ; Wed, 21 Mar 2012 07:07:49 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9E32621F864A for ; Wed, 21 Mar 2012 07:07:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,623,1325480400"; d="scan'208";a="4459286" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 21 Mar 2012 10:07:48 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 21 Mar 2012 10:07:48 -0400 From: Santosh Chokhani To: Carl Wallace , Phillip Hallam-Baker Date: Wed, 21 Mar 2012 10:07:47 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0G6DtlBffPk0rvTPuieWtU+4WP4wAg5uqg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 14:07:53 -0000 I like the ideas Carl has with respect to once we have agreed on the requir= ements, problem to solve, looking at extensions at response and single resp= onse levels to see how extensions can solve the problem before we try to bu= st the protocol. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Car= l Wallace Sent: Tuesday, March 20, 2012 6:24 PM To: Phillip Hallam-Baker Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions On 3/20/12 5:04 PM, "Phillip Hallam-Baker" wrote: >We have a hard constraint that it be possible to pre-sign all signed=20 >OCSP responses. That is an operational necessity. A proof of existence extension would not break the ability to pre-sign resp= onses. As with any extension, it would make responses larger though. > >If the OCSP responder is going to be required to always return a signed=20 >response we need to have the ability to do range responses. >This will be a new requirement but essential for transparency. > > >Since a range response is only going to make sense for not-issued it is=20 >going to be interpreted as such anyway. A range response extension could be a form of proof of (non-)existence (at = least at the time the pre-signing was done). The extension could also incl= ude a pointer for where to send the offending certificate so corrective act= ions can be taken if necessary. However, there are still unanswered questi= ons on the list regarding how to square range signing with on-going certifi= cate issuance with random serial numbers. > >I really fail to see why this proposal results in the responses it=20 >does. Perhaps because it needs more work. For example, it requires CAs to mainta= in a complete log. This seems like an odd requirement in a proposal that i= s addressing a problem in which the CA lost control of their log. It also leaves some important things unaddressed. For example, is there an= y operational necessity for backwards compatibility? It seems odd to want = to use an existing protocol but break backwards compatibility. If you are collecting requirements for transparency work, you should add pu= blication of all CA certificates. A proof of existence-based approach might be a good thing for transparency.= It would ensure the CA is not up to no good if a bad certificate is found= since the check that determines the certificate is no good is performed on= the client side. Of course, to mention another unaddressed point from the list, any extra ch= eck is moot depending on the nature of the compromise and whether bad certi= ficates can be distinguished from good ones. >Particularly given the number of boondoggles and curlicues that the DoD=20 >faction has required of the spec: Policy constraints, attribute certs,=20 >SCVP. > >All I am looking to do here is to make the public CA system work=20 >effectively. OK. >If the DoD faction can't live with that then I'll take the proposal=20 >elsewhere and if it gets deployed we will end up in the spec being=20 >spread across three standards orgs instead of the two it is split=20 >across at present. > > >On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. >wrote: >> The word GOOD directly contradicts the RFC 2560 paragraph describing it. >> A certificate that was never issued or is outside its validity period=20 >> cannot, under any reasonable English language interpretation, be >> considered "good". Whereas UNKNOWN is a reasonable word to use for a >> certificate that may or may not exist, but is definitely not revoked. >> Modifying OCSP responders to never send a deprecated GOOD response=20 >> does not change the meaning of that response. And unless the default=20 >> client behavior is to fail on UNKNOWN, changing responders to use it=20 >> for all non-revoked certificates does not affect client behavior. >> >> Excellent point regarding proof of existence. There is no need to=20 >> change the OCSP request in any way. The extension can be sent at the=20 >> discretion of the responder, the client can validate the proof since=20 >> it already has a copy of the certificate being checked, and the=20 >> client can follow its own policy for handling responses without the=20 >> extension or responses with proofs that don't match the certificate. =20 >> That is backwards compatibility at its best, and although I'm=20 >> skeptical of using OCSP to address PHB's NOT-ISSUED requirement, the=20 >> proof-of-issuance extension seems quite straightforward. >> >> Dave >> >> >> -----Original Message----- >> From: Carl Wallace >> >> On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >>> As currently written, allowing GOOD without qualifier leads to=20 >>> incorrect interpretation of the protocol. I.e., for most OCSP=20 >>> Responders only REVOKED or UNKNOWN should be sent. >> >> As currently written where? RFC2560 states the following: >> >> The "good" state indicates a positive response to the status inquiry. >> At a minimum, this positive response indicates that the certificate >> is not revoked, but does not necessarily mean that the certificate >> was ever issued or that the time at which the response was produced >> is within the certificate's validity interval. Response extensions >> may be used to convey additional information on assertions made by >> the responder regarding the status of the certificate such as >> positive statement about issuance, validity, etc. >> >> >> Adding an extension to return proof of existence would be easy enough=20 >> and would not break backwards compatibility. Adding additional=20 >> status values or changing the meaning of existing status values=20 >> would. Clients that want to fail without the extra proof could do so. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >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 hallam@gmail.com Wed Mar 21 10:59:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140221E808C for ; Wed, 21 Mar 2012 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIYH3NA5exTp for ; Wed, 21 Mar 2012 10:59:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73021F84D2 for ; Wed, 21 Mar 2012 10:59:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1321482ghb.31 for ; Wed, 21 Mar 2012 10:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LmehV0MPsj4edvW/mHH2uBU9j12BXqhG5dSOdIYE06k=; b=Dr6lYctW4DEexAZTDxxikL8878X6jLmqLYH4DT4ex9mA3EbWmeRFKMfwUkwySJUXlq /sR69n/ZMrXAwHGCRMLZhJa4zvUc0ww/lSntyUkvXi2GMCmlm8CQEbq1y1rxcKPluC3J rXOa3S3bYVw3hrZADRglVMNOT6BtjcESIl414YIIM+cwojyS7W6GioeyStnJ1F2W8GGZ GDypH3USRNnDtyylklpvkMphBSREoLQsXmDWM//4nMQCy/MNpi2Qv7GftasmCuwC9RPQ o45CYELvDvHJndUaeG6qDZNJl5pmzp62i+oQi5y/N5XlYG5lZDiUWuy+7CnJhVeEbJeY lcbA== MIME-Version: 1.0 Received: by 10.60.20.100 with SMTP id m4mr6233259oee.10.1332352763589; Wed, 21 Mar 2012 10:59:23 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Wed, 21 Mar 2012 10:59:22 -0700 (PDT) In-Reply-To: References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> Date: Wed, 21 Mar 2012 13:59:22 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 17:59:25 -0000 On Wed, Mar 21, 2012 at 9:49 AM, Santosh Chokhani wrote: > PHB, > > All a pre-signer can do is say revoked/on CRL or not revoked/not on CRL. Not true, there is an extensions field. On Wed, Mar 21, 2012 at 9:54 AM, Santosh Chokhani wrote: > PHB, > > As Steve said, let us identify the requirements first, then see how valid= they are and then we can debate the solutions. I have raised requirements here but you don't seem interested in them. As for the IETF being the judge of the 'validity' of my requirements, never. I have requirements and I will deploy whatever technology I require to meet those requirements. If nobody else agrees with my requirements they are unlikely to need my technology and there is no requirement for a standard. There seems to be a demand for greater transparency in the operation of public CAs. There is a clear advantage to both the CAs and our customers in meeting that demand. So I expect that the industry will take whatever measures are necessary to achieve that. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of P= hillip Hallam-Baker > Sent: Tuesday, March 20, 2012 5:04 PM > To: Kemp, David P. > Cc: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions > > We have a hard constraint that it be possible to pre-sign all signed OCSP= responses. That is an operational necessity. > > If the OCSP responder is going to be required to always return a signed r= esponse we need to have the ability to do range responses. > This will be a new requirement but essential for transparency. > > > Since a range response is only going to make sense for not-issued it is g= oing to be interpreted as such anyway. > > > I really fail to see why this proposal results in the responses it does. = Particularly given the number of boondoggles and curlicues that the DoD fac= tion has required of the spec: Policy constraints, attribute certs, SCVP. > > All I am looking to do here is to make the public CA system work effectiv= ely. If the DoD faction can't live with that then I'll take the proposal el= sewhere and if it gets deployed we will end up in the spec being spread acr= oss three standards orgs instead of the two it is split across at present. > > > On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. w= rote: >> The word GOOD directly contradicts the RFC 2560 paragraph describing it. >> A certificate that was never issued or is outside its validity period >> cannot, under any reasonable English language interpretation, be >> considered "good". =A0 Whereas UNKNOWN is a reasonable word to use for a >> certificate that may or may not exist, but is definitely not revoked. >> Modifying OCSP responders to never send a deprecated GOOD response >> does not change the meaning of that response. =A0And unless the default >> client behavior is to fail on UNKNOWN, changing responders to use it >> for all non-revoked certificates does not affect client behavior. >> >> Excellent point regarding proof of existence. =A0There is no need to >> change the OCSP request in any way. =A0The extension can be sent at the >> discretion of the responder, the client can validate the proof since >> it already has a copy of the certificate being checked, and the client >> can follow its own policy for handling responses without the extension >> or responses with proofs that don't match the certificate. =A0That is >> backwards compatibility at its best, and although I'm skeptical of >> using OCSP to address PHB's NOT-ISSUED requirement, the >> proof-of-issuance extension seems quite straightforward. >> >> Dave >> >> >> -----Original Message----- >> From: Carl Wallace >> >> On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >>> As currently written, allowing GOOD without qualifier leads to >>> incorrect interpretation of the protocol. =A0I.e., for most OCSP >>> Responders only REVOKED or UNKNOWN should be sent. >> >> As currently written where? =A0RFC2560 states the following: >> >> =A0 The "good" state indicates a positive response to the status inquiry= . >> =A0 At a minimum, this positive response indicates that the certificate >> =A0 is not revoked, but does not necessarily mean that the certificate >> =A0 was ever issued or that the time at which the response was produced >> =A0 is within the certificate's validity interval. Response extensions >> =A0 may be used to convey additional information on assertions made by >> =A0 the responder regarding the status of the certificate such as >> =A0 positive statement about issuance, validity, etc. >> >> >> Adding an extension to return proof of existence would be easy enough >> and would not break backwards compatibility. =A0Adding additional status >> values or changing the meaning of existing status values would. >> Clients that want to fail without the extra proof could do so. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From SChokhani@cygnacom.com Wed Mar 21 11:09:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4183421F844A for ; Wed, 21 Mar 2012 11:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mzbynQiieGw for ; Wed, 21 Mar 2012 11:09:10 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1521F8427 for ; Wed, 21 Mar 2012 11:09:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,623,1325480400"; d="scan'208";a="4462555" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 21 Mar 2012 14:09:07 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 21 Mar 2012 14:09:07 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Wed, 21 Mar 2012 14:09:06 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0HjGX12P4E7SE8QwyFIa6kO49N1wAATM7Q Message-ID: References: <983939AA-D0EE-4BFC-BCF3-526734752EC3@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 21 Mar 2012 18:09:12 -0000 So, what would pre-signer figure out about unissued certificates and put in= extensions field. Pre-signer can only speak for issued certificates. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Wednesday, March 21, 2012 1:59 PM To: Santosh Chokhani Cc: Kemp, David P.; pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions On Wed, Mar 21, 2012 at 9:49 AM, Santosh Chokhani = wrote: > PHB, > > All a pre-signer can do is say revoked/on CRL or not revoked/not on CRL. Not true, there is an extensions field. On Wed, Mar 21, 2012 at 9:54 AM, Santosh Chokhani = wrote: > PHB, > > As Steve said, let us identify the requirements first, then see how valid= they are and then we can debate the solutions. I have raised requirements here but you don't seem interested in them. As for the IETF being the judge of the 'validity' of my requirements, never= . I have requirements and I will deploy whatever technology I require to me= et those requirements. If nobody else agrees with my requirements they are = unlikely to need my technology and there is no requirement for a standard. There seems to be a demand for greater transparency in the operation of pub= lic CAs. There is a clear advantage to both the CAs and our customers in me= eting that demand. So I expect that the industry will take whatever measure= s are necessary to achieve that. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Phillip Hallam-Baker > Sent: Tuesday, March 20, 2012 5:04 PM > To: Kemp, David P. > Cc: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions > > We have a hard constraint that it be possible to pre-sign all signed OCSP= responses. That is an operational necessity. > > If the OCSP responder is going to be required to always return a signed r= esponse we need to have the ability to do range responses. > This will be a new requirement but essential for transparency. > > > Since a range response is only going to make sense for not-issued it is g= oing to be interpreted as such anyway. > > > I really fail to see why this proposal results in the responses it does. = Particularly given the number of boondoggles and curlicues that the DoD fac= tion has required of the spec: Policy constraints, attribute certs, SCVP. > > All I am looking to do here is to make the public CA system work effectiv= ely. If the DoD faction can't live with that then I'll take the proposal el= sewhere and if it gets deployed we will end up in the spec being spread acr= oss three standards orgs instead of the two it is split across at present. > > > On Tue, Mar 20, 2012 at 4:33 PM, Kemp, David P. w= rote: >> The word GOOD directly contradicts the RFC 2560 paragraph describing it. >> A certificate that was never issued or is outside its validity period=20 >> cannot, under any reasonable English language interpretation, be=20 >> considered "good". =A0 Whereas UNKNOWN is a reasonable word to use for=20 >> a certificate that may or may not exist, but is definitely not revoked. >> Modifying OCSP responders to never send a deprecated GOOD response=20 >> does not change the meaning of that response. =A0And unless the default= =20 >> client behavior is to fail on UNKNOWN, changing responders to use it=20 >> for all non-revoked certificates does not affect client behavior. >> >> Excellent point regarding proof of existence. =A0There is no need to=20 >> change the OCSP request in any way. =A0The extension can be sent at the= =20 >> discretion of the responder, the client can validate the proof since=20 >> it already has a copy of the certificate being checked, and the=20 >> client can follow its own policy for handling responses without the=20 >> extension or responses with proofs that don't match the certificate. =A0 >> That is backwards compatibility at its best, and although I'm=20 >> skeptical of using OCSP to address PHB's NOT-ISSUED requirement, the=20 >> proof-of-issuance extension seems quite straightforward. >> >> Dave >> >> >> -----Original Message----- >> From: Carl Wallace >> >> On 3/20/12 2:58 PM, "Miller, Timothy J." wrote: >>> As currently written, allowing GOOD without qualifier leads to=20 >>> incorrect interpretation of the protocol. =A0I.e., for most OCSP=20 >>> Responders only REVOKED or UNKNOWN should be sent. >> >> As currently written where? =A0RFC2560 states the following: >> >> =A0 The "good" state indicates a positive response to the status inquiry= . >> =A0 At a minimum, this positive response indicates that the certificate >> =A0 is not revoked, but does not necessarily mean that the certificate >> =A0 was ever issued or that the time at which the response was produced >> =A0 is within the certificate's validity interval. Response extensions >> =A0 may be used to convey additional information on assertions made by >> =A0 the responder regarding the status of the certificate such as >> =A0 positive statement about issuance, validity, etc. >> >> >> Adding an extension to return proof of existence would be easy enough=20 >> and would not break backwards compatibility. =A0Adding additional=20 >> status values or changing the meaning of existing status values would. >> Clients that want to fail without the extra proof could do so. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From kent@bbn.com Wed Mar 21 13:54:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB821F8638 for ; Wed, 21 Mar 2012 13:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eshruij+65V6 for ; Wed, 21 Mar 2012 13:54:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 200EC21F855D for ; Wed, 21 Mar 2012 13:54:02 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49179) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SASXU-000NcO-SF; Wed, 21 Mar 2012 16:53:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 21 Mar 2012 16:49:13 -0400 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Issuer Transparency Proposal X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 21 Mar 2012 20:54:02 -0000 At 2:35 PM -0400 3/20/12, Phillip Hallam-Baker wrote: >In response to Stephen's request for a statement of the goals: > > >Objective: Improve confidence in the system of public CAs by making >certain aspects of CA operations transparent. > >We define 'transparent' to mean 'can be audited by any external party >without access to privileged information. Our concern in this >particular proposal is limited to the operation of online HSM devices >used to sign certificates and OCSP responses. > >In particular the proposal must address a particular failure >discovered during the DigiNotar case in which a CA lost control of >their HSM and their log files and this state of affairs remained >undetected by the CA for a considerable period of time and was not >known to the general public for a longer period of time. > PHB, I removed the rest of your message in my reply, because it begins to describe a solution, not refine the problem statement. This is not an endorsement or criticism of what you state above, just an observation about what is appropriate for the requirements doc. The doc also needs to describe perceived constraints on the solution space, and explain why the author believes these constrains apply. Looking at the stated objective above, I am not convinced that it is an ideal start for a problem statement, although one could re-word it to be so, e.g., saying that users have lost (are loosing?) confidence in the current public CA system and we need to address that problem. Then, you talk of the need for greater transparency, which means you're already heading down the solution path, after just a single sentence problem spec. I think that needs more thought too. Then you bring in operation of HSMs as an area of particular interest. That seems awfully narrow. Bringing up the DigiNotar case as an example is fine, as it's good to explain a general problem characterization with specific examples. Just a few thoughts for you, and for Brennan as you start work on problem statement docs. Steve From sharon.boeyen@entrust.com Thu Mar 22 06:16:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981721F858D for ; Thu, 22 Mar 2012 06:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbd+AsmhM4sL for ; Thu, 22 Mar 2012 06:16:07 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id E2D0021F856F for ; Thu, 22 Mar 2012 06:16:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="610714" Received: from unknown (HELO sottexch8.corp.ad.entrust.com) ([10.4.51.89]) by ipedge2.entrust.com with ESMTP; 22 Mar 2012 09:15:53 -0400 Received: from sottexch7.corp.ad.entrust.com ([::1]) by sottexch8.corp.ad.entrust.com ([fe80::3d93:b474:b43c:76fe%10]) with mapi; Thu, 22 Mar 2012 09:15:53 -0400 From: Sharon Boeyen To: Paul Hoffman , PKIX Date: Thu, 22 Mar 2012 09:15:56 -0400 Thread-Topic: [pkix] 5280 clarifications Thread-Index: Ac0GMytITxt1PkBxRompLnP1pURYzgB+gFOA Message-ID: References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> In-Reply-To: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 13:16:08 -0000 As the past editor of X.509 and someone whose history participating in the = X.509 standards group goes back 25 years to 1987, I'd like to confirm that = the X.509 model (going back all the way to the first edition published in 1= 988) is one where public key certificate signers/issuers are exclusively CA= s. Therefore the first two sentences in the new proposed text below are a c= orrect interpretation of X.509.=20 Cheers, Sharon Boeyen -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pau= l Hoffman Sent: Monday, March 19, 2012 8:48 PM To: PKIX Subject: Re: [pkix] 5280 clarifications On Mar 19, 2012, at 9:58 AM, Stephen Kent wrote: > In your latest rev there is added text that addresses one of the=20 > issues that arose in DANE re self-signed EE cert use in the TLS=20 > context. I find that text confusing. I suggest the following text, which= focuses on a different aspect of SS-EE cert use. We need to ask the Securi= ty ADs if they feel the following text, or some combination of it and what = you already wrote, addresses the DANE issues. >=20 > Section 3.2: insert this new paragraph after the (current) last=20 > paragraph The PKI model defined in X.509 requires that an entity that sig= ns a (public key) certificate be a CA. The notion of a self-signed end enti= ty certificate deviates from the X.59 model. A self-signed, end entity cert= ificate generally is not compatible with the certificate path validation me= chanism described in Section 6. However, as noted in Sections 6.1 and 6.1.1= , a self-signed certificate may be used convey a trust anchor. In practice,= if this trust anchor certificate fails to include the BasicConstraints ext= ension, which is used to mark a certificate as a CA certificate, this does = not adversely affect certificate path processing. Thus the preceding text d= iscussing certificate types should be interpreted as follows: A self-signed= certificate used exclusively to convey trust anchor data need not be marke= d as a CA certificate, although such marking is RECOMMENDED. All other self= -signed certificates MUST be marked as CA certificates. I prefer the paragraph currently in the document. The first two sentence ab= ove are an unattributed assertion, one that others have disagreed with. I d= o not think that putting them into a standards-track update document is war= ranted unless they are the consensus of both this WG and of the maintainers= of X.509. Given the unlikelihood of that, the current text is better. Furt= her, the last two sentences above go against current practice, and they rep= lace sentences in the current draft that seem more in line with current pra= ctice. > Sean Turner also suggested that we make an explicit reference to RFC 5937= , when we discuss path processing. So, I suggest the following text change= for 6.1.1: >=20 > Add the following text in 6.1.1, at the end of the section. >=20 > OLD: > Conforming implementations are not required to support the setting of all= of these inputs. For example, a conforming implementation may be designed= to validate all certification paths using a value of FALSE for initial-any= -policy-inhibit. >=20 > NEW: > Conforming implementations are not required to support the setting of all= of these inputs. For example, a conforming implementation may be designed= to validate all certification paths using a value of FALSE for initial-any= -policy-inhibit. > Implementers are encouraged to make use of the capabilities defined in RF= C 5937, which describes how to make use of trust anchor constraints during = path processing, including certificate policies, name constraints, and path= length. That seems fine, and the appropriate level of emphasis given that RFC 5937 = is informational, not standards track. > Finally, based on the discussions in SIDR and the docs that have been iss= ued as RFCs, I suggest the following changes to text in the Secruity Consid= erations section: >=20 > Replace the following text with the new text below, in the security=20 > considerations section (Section 8) > =20 > OLD: > While X.509 mandates that names be unambiguous, there is a risk that two = unrelated authorities will issue certificates and/or CRLs under the same is= suer name. As a means of reducing problems and security issues related to i= ssuer name collisions, CA and CRL issuer names SHOULD be formed in a way th= at reduces the likelihood of name collisions. Implementers should take int= o account the possible existence of multiple unrelated CAs and CRL issuers = with the same name. At a minimum, implementations validating CRLs MUST ens= ure that the certification path of a certificate and the CRL issuer certifi= cation path used to validate the certificate terminate at the same trust an= chor. >=20 >=20 > NEW: > While X.509 mandates that names be unambiguous, there is a risk that two = unrelated authorities will issue certificates and/or CRLs under the same is= suer name. This could occur accidentally or it might be part of an attack. = In the latter case, a CA might issue certificates to CAs, inserting subject= names that intentionally conflict with subject names in other, legitimate = certificates. A CA behaving in this fashion might also assign certificate s= erial numbers to collide with entities being targeted in the attack. >=20 > To address the possibility of accidental name collisions, CA and CRL issu= er names SHOULD be formed in a way that reduces the likelihood of name coll= isions. Examples of such techniques appear in Section 8 of [RFC 6487]. To a= ddress both accidental and malicious scenarios, implementers should take in= to account the possible existence of multiple unrelated CAs and CRL issuers= with the same name (and possibly the same serial number). At a minimum, i= mplementations validating CRLs MUST ensure that the certification path of a= certificate and the CRL issuer certification path used to validate the cer= tificate terminate at the same trust anchor. Good addition, yes. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Thu Mar 22 06:24:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2221521F85FB for ; Thu, 22 Mar 2012 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9Cyasiv6FGH for ; Thu, 22 Mar 2012 06:24:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5221F85F8 for ; Thu, 22 Mar 2012 06:24:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 59FD821B0B09; Thu, 22 Mar 2012 09:24:26 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 48F9D21B06F2; Thu, 22 Mar 2012 09:24:26 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.44]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Thu, 22 Mar 2012 09:24:26 -0400 From: "Miller, Timothy J." To: "" Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: AQHNB6uIe3S8XWTYQEqfNuOgbNpcQpZ2kfAA Date: Thu, 22 Mar 2012 13:24:25 +0000 Message-ID: References: <201203212142.q2LLgbEC008342@fs4113.wdf.sap.corp> In-Reply-To: <201203212142.q2LLgbEC008342@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.11] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "<\" " <" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 13:24:28 -0000 On Mar 21, 2012, at 4:42 PM, Martin Rex wrote: > Miller, Timothy J. wrote: >> There is a corner case where the CA history is trusted, the Responder >> signing key is trusted, but the CA signing key is not. >> In this case, NOTISSUED can signal a compromise. >> This is the corner case I think Philip is after. >=20 > I do not think that this is a "corner case"; I believe it will be the > most probable case that the CA key compromise is a temporary loss of > control over certificate issuance, and may be accompanied by the loss > of records what got signed (e.g. physical damage inflicted by the > attacker). =20 I think you missed the point. The corner is the loss of CA key control whi= le *keeping* CA history integrity. In both recent cases we have before us,= loss of CA key control was temporary, but the CA history couldn't be trust= ed. NOTISSUED critically depends on *both*. =20 The point of NOTISSUED is to *aid* in detecting compromise so recovery can = be attempted. Once you're *in* recovery, NOTISSUED is irrelevant because y= ou can just as easily respond REVOKED for those certs--as we see from recen= t cases. -- T= From paul.hoffman@vpnc.org Thu Mar 22 07:37:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5AC21F85F6 for ; Thu, 22 Mar 2012 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 298eMOlPSMLL for ; Thu, 22 Mar 2012 07:37:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07821F85F3 for ; Thu, 22 Mar 2012 07:37:15 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2MEbBe1016200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2012 07:37:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 22 Mar 2012 07:37:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> To: Sharon Boeyen X-Mailer: Apple Mail (2.1257) Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 14:37:15 -0000 On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > As the past editor of X.509 and someone whose history participating in = the X.509 standards group goes back 25 years to 1987, I'd like to = confirm that the X.509 model (going back all the way to the first = edition published in 1988) is one where public key certificate = signers/issuers are exclusively CAs. Therefore the first two sentences = in the new proposed text below are a correct interpretation of X.509.=20 This in interesting to hear. It is relevant to X.509, although it would = be more so if it was actually written in the spec. There is the second issue of whether PKIX, the IETF's profile, is = allowed to change that model. We have changed a lot of the X.509 model, = and there is a huge amount of software that does so today under the = assumption that PKIX (not X.509) allows this. I'm not convinced that the PKIX document (in this case, the update to = the PKIX document) needs to call out what the X.509 document intended = here. --Paul Hoffman From mrex@sap.com Thu Mar 22 07:41:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B721F8550 for ; Thu, 22 Mar 2012 07:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.063 X-Spam-Level: X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoWdTp689ihG for ; Thu, 22 Mar 2012 07:41:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B99F921F8517 for ; Thu, 22 Mar 2012 07:41:55 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2MEfq52021570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 15:41:53 +0100 (MET) From: Martin Rex Message-Id: <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> To: tmiller@mitre.org (Miller Timothy J.) Date: Thu, 22 Mar 2012 15:41:52 +0100 (MET) In-Reply-To: from "Miller, Timothy J." at Mar 22, 12 01:24:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 14:41:56 -0000 Miller, Timothy J. wrote: > > Martin Rex wrote: > > > Miller, Timothy J. wrote: > > > >> There is a corner case where the CA history is trusted, the Responder > >> signing key is trusted, but the CA signing key is not. > >> In this case, NOTISSUED can signal a compromise. > >> This is the corner case I think Philip is after. > > > > I do not think that this is a "corner case"; I believe it will be the > > most probable case that the CA key compromise is a temporary loss of > > control over certificate issuance, and may be accompanied by the loss > > of records what got signed (e.g. physical damage inflicted by the > > attacker). > > I think you missed the point. The corner is the loss of CA key control > while *keeping* CA history integrity. In both recent cases we have > before us, loss of CA key control was temporary, but the CA history > couldn't be trusted. NOTISSUED critically depends on *both*. Just the opposite. In the DigiNotar case, the history integrity was retained (that is the purpose of any desaster recovery plan). And the means that they used for their own OCSP server to recognize misissued certs was to check OCSP requests against their database of past issued certs and declare all other certs not in that database as REVOKED. But unless the OCSP requests include a certificate hash, that check is not reliable, because depending on how much control the attacker had over the creation of serial numbers, he could have tried to reuse serials of correctly issued certs for the misissued certs. That's why OCSP requests should be updated to include a certificate hash besides the issuer and serial. > > The point of NOTISSUED is to *aid* in detecting compromise so recovery > can be attempted. Once you're *in* recovery, NOTISSUED is irrelevant > because you can just as easily respond REVOKED for those certs--as we > see from recent cases. Just the opposite. NOTISSUED is only relevant in case of suspicion and recovery. Only those that continue claiming that potential compromise of a CA is a non-event which they do not have to account for do not care about "NOTISSUED" status. -Martin From SChokhani@cygnacom.com Thu Mar 22 07:48:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8B21F85E3 for ; Thu, 22 Mar 2012 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW4I32Oj6xRb for ; Thu, 22 Mar 2012 07:48:29 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6721F85C6 for ; Thu, 22 Mar 2012 07:48:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="4471499" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 22 Mar 2012 10:48:26 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 22 Mar 2012 10:48:26 -0400 From: Santosh Chokhani To: "mrex@sap.com" , Miller Timothy J. Date: Thu, 22 Mar 2012 10:48:25 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0IOfBvCW0GIoB2RaaJxTwQk/8GMQAAJlAQ Message-ID: References: from "Miller, Timothy J." at Mar 22, 12 01:24:25 pm <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> In-Reply-To: <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 14:48:29 -0000 Using OCSP to figure out mis-issued certificates is an incomplete security = mechanism. Attacker can issue itself a delegated OCSP certificate and point to that OC= SP in mis-issued certificates. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Thursday, March 22, 2012 10:42 AM To: Miller Timothy J. Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions Miller, Timothy J. wrote: >=20 > Martin Rex wrote: >=20 > > Miller, Timothy J. wrote: > > > >> There is a corner case where the CA history is trusted, the=20 > >> Responder signing key is trusted, but the CA signing key is not. > >> In this case, NOTISSUED can signal a compromise. > >> This is the corner case I think Philip is after. > >=20 > > I do not think that this is a "corner case"; I believe it will be=20 > > the most probable case that the CA key compromise is a temporary=20 > > loss of control over certificate issuance, and may be accompanied by=20 > > the loss of records what got signed (e.g. physical damage inflicted=20 > > by the attacker). >=20 > I think you missed the point. The corner is the loss of CA key=20 > control while *keeping* CA history integrity. In both recent cases we=20 > have before us, loss of CA key control was temporary, but the CA=20 > history couldn't be trusted. NOTISSUED critically depends on *both*. Just the opposite. In the DigiNotar case, the history integrity was retain= ed (that is the purpose of any desaster recovery plan). And the means that they used for their own OCSP server to recognize misissu= ed certs was to check OCSP requests against their database of past issued c= erts and declare all other certs not in that database as REVOKED. But unless the OCSP requests include a certificate hash, that check is not = reliable, because depending on how much control the attacker had over the c= reation of serial numbers, he could have tried to reuse serials of correctl= y issued certs for the misissued certs. That's why OCSP requests should be updated to include a certificate hash be= sides the issuer and serial. >=20 > The point of NOTISSUED is to *aid* in detecting compromise so recovery=20 > can be attempted. Once you're *in* recovery, NOTISSUED is irrelevant=20 > because you can just as easily respond REVOKED for those certs--as we=20 > see from recent cases. Just the opposite. NOTISSUED is only relevant in case of suspicion and rec= overy. Only those that continue claiming that potential compromise of a CA= is a non-event which they do not have to account for do not care about "NO= TISSUED" status. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Thu Mar 22 07:57:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E221F8673 for ; Thu, 22 Mar 2012 07:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2WPWJn453-G for ; Thu, 22 Mar 2012 07:57:36 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF321F8671 for ; Thu, 22 Mar 2012 07:57:36 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2MEvZrT088864 for ; Thu, 22 Mar 2012 10:57:35 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 10:57:35 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Mar 2012 10:57:35 -0400 Message-ID: In-Reply-To: <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] 5280 clarifications Thread-Index: Ac0IOU8WGQxeTuL8TA+sYhFwcESemgAAXrBg References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> From: "Kemp, David P." To: "PKIX" X-OriginalArrivalTime: 22 Mar 2012 14:57:35.0536 (UTC) FILETIME=[1DD7E300:01CD083C] Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 14:57:37 -0000 PKIX is about public key infrastructure. Self-signed EE certs are unrelated to PKI. The question is "should a PKIX document acknowledge the existence of any non-PKI usage of data structures defined by X.509"? I believe it should do so, in particular to recommend formatting such certificates so that they cannot be confused with PKI certificates. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Thursday, March 22, 2012 10:37 AM To: Sharon Boeyen Cc: PKIX Subject: Re: [pkix] 5280 clarifications On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > As the past editor of X.509 and someone whose history participating in the X.509 standards group goes back 25 years to 1987, I'd like to confirm that the X.509 model (going back all the way to the first edition published in 1988) is one where public key certificate signers/issuers are exclusively CAs. Therefore the first two sentences in the new proposed text below are a correct interpretation of X.509.=20 This in interesting to hear. It is relevant to X.509, although it would be more so if it was actually written in the spec. There is the second issue of whether PKIX, the IETF's profile, is allowed to change that model. We have changed a lot of the X.509 model, and there is a huge amount of software that does so today under the assumption that PKIX (not X.509) allows this. I'm not convinced that the PKIX document (in this case, the update to the PKIX document) needs to call out what the X.509 document intended here. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Thu Mar 22 09:19:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714B21F85D3 for ; Thu, 22 Mar 2012 09:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BzVW65MuArs for ; Thu, 22 Mar 2012 09:19:44 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B649921F85C9 for ; Thu, 22 Mar 2012 09:19:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2MGJdI6022636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 17:19:40 +0100 (MET) From: Martin Rex Message-Id: <201203221619.q2MGJdXq008505@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Thu, 22 Mar 2012 17:19:39 +0100 (MET) In-Reply-To: from "Santosh Chokhani" at Mar 22, 12 10:48:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 16:19:44 -0000 Santosh Chokhani wrote: > > Using OCSP to figure out mis-issued certificates is an incomplete > security mechanism. > > Attacker can issue itself a delegated OCSP certificate and point > to that OCSP in mis-issued certificates. Which indicates a design flaw in the scheme to authorize OCSP responders through attributes in the certificate. As I said, PKI was not designed with the concept of desaster recovery from a CA key compromise in mind. A compromised CA could accept existing PKI credentials to authenticate requests for new credentials when it knows to ignore that information. -Martin From tom@ritter.vg Thu Mar 22 09:20:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27621F85D3 for ; Thu, 22 Mar 2012 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtxaPRrLuVuE for ; Thu, 22 Mar 2012 09:20:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66B21F85BD for ; Thu, 22 Mar 2012 09:20:22 -0700 (PDT) Received: by yenm5 with SMTP id m5so2126301yen.31 for ; Thu, 22 Mar 2012 09:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G+wX/RhJ2bdIQiV2jUNWzhPjM9W/iPvnjAyUA6o6NFA=; b=KAUjrW7D6cj3dcEfdO1wrq+iXKfmPa3wKx7IHkWBu5IRY+fquxGNCmP3fqooBzgMB6 v96UPHVLwn+4kQhSZVEGOjGzYZdc8p2poYub3JITKWvUm9i8nbw4+6UWAtGftmEVBy6d aNJIDU/esg2FpL4DKSwwztAe/QE1BrTbeAgVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=G+wX/RhJ2bdIQiV2jUNWzhPjM9W/iPvnjAyUA6o6NFA=; b=DOEVe4PpQj9Eo25JlRdWtw3oHd+Dr6umVzZ6upTQAgnZsf0aemU94Phqpu7VS8VXJT M982X6cIkV79cyAMfFn544+wq1iTaTJ2oYMIPTogsfw5H1g8rmMVeEn7nA9pJ6zdQCrz 2hbYQsZGLCi6kRUGFXsaltjFLj+2VrBeia8/hm7V6gDP69UAmnn1xB3VEOj9f8u/PZB4 4o6aT8RKRhiffDqyWABqVVtTm0maqHWCsZiq791zHo3zoOaqUbRYibRKqzbafZE7EcEw kRbBTHnBDxNcEWF3uYJaIcNmoTMesCgGa5SL54dmuX5U+ehYkT/sO86jWBkeF8MoXiq7 XDgA== Received: by 10.60.25.162 with SMTP id d2mr11125209oeg.30.1332433221648; Thu, 22 Mar 2012 09:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.105 with HTTP; Thu, 22 Mar 2012 09:20:00 -0700 (PDT) In-Reply-To: References: <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> From: Tom Ritter Date: Thu, 22 Mar 2012 12:20:00 -0400 Message-ID: To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnqZiFoIedepnB0jAMCyy2v8v7otKSfzmTABGpV1DIAqObIOU88RtRohj6cF1K2RmvvnT8 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 16:20:23 -0000 On 22 March 2012 10:48, Santosh Chokhani wrote: > Using OCSP to figure out mis-issued certificates is an incomplete security mechanism. > > Attacker can issue itself a delegated OCSP certificate and point to that OCSP in mis-issued certificates. Only if the attacker has *complete* control of the CA's signing key. If the attack actually has access to a signing *function* that includes logic to look for 'strange things' and block them (like basicConstraints, delegated OCSP, etc) or a whitelist of attributes to be allowed through (alternate names) - then the attacker can't do such a thing. Exploitation in the real world has to deal with issues like these: you don't always get a 'complete' SQL injection, sometime you're not allowed to submit commas. You don't always get a XSS bug that lets you include angle brackets, sometime you only get an attribute-based one. You don't always get to drop your shellcode on the stack and execute, sometimes you have to ROP first to bypass DEP. You don't always get full access to the CA's HSM, sometimes you only bypass their authorization checks. I agree that in some cases this security mechanism can be bypassed. But in some cases so can basicConstraints (as we've seen time and time again). It's unknowable for us to say whether this protection mechanism would or wouldn't *actually* be useful - because it comes down to nitty-gritty of CA implementation of signing operations, and they're not going to say anything. It's likely that it would be a useful security mechanism for some CAs and would be automatically bypassed by others. If I were a betting man, I say it's more likely to be automatically bypassed than useful *today* - but in the future I hope it eventually would become a useful mechanism for CAs - it's in their interest to keep the integrity of their certificate history and to whitelist the parameters specified in CSR's. -tom From sharon.boeyen@entrust.com Thu Mar 22 09:24:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07321F85C0 for ; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuVBCYr0RBfw for ; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id D577A21F8573 for ; Thu, 22 Mar 2012 09:24:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="612480" Received: from unknown (HELO sottexch8.corp.ad.entrust.com) ([10.4.51.89]) by ipedge2.entrust.com with ESMTP; 22 Mar 2012 12:24:52 -0400 Received: from sottexch7.corp.ad.entrust.com ([::1]) by sottexch8.corp.ad.entrust.com ([fe80::3d93:b474:b43c:76fe%10]) with mapi; Thu, 22 Mar 2012 12:24:51 -0400 From: Sharon Boeyen To: Paul Hoffman Date: Thu, 22 Mar 2012 12:25:07 -0400 Thread-Topic: [pkix] 5280 clarifications Thread-Index: Ac0IOVfcnfd+gc89QHK2g7b737bJ6QADi80Q Message-ID: References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> In-Reply-To: <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 16:24:53 -0000 It IS written in the spec. You can download the 2009 edition of X.509 free = of charge from http://www.x500standard.com/index.php?n=3DIg.LatestAvail (o= r pay for the current version). In the 2009 edition, in the definitions sec= tion you will find the following: 3.4.17 certification authority (CA ): An authority trusted by one or more u= sers to create and assign public-key certificates. Optionally the certifica= tion authority may create the users' keys . And 3.4.27 end entity : Either a public key certificate subject that uses its p= rivate key for purposes other than signing certificates, or an attribute ce= rtificate holder that uses its attributes to gain access to a resource, or = an entity that is a relying party . As well as: 3.4.57 self-issued certificate : A public-key certificate where the issuer = and the subject are the same CA. A CA might use self-issued certificates, f= or example, during a key rollover operation to provide trust from the old k= ey to the new key . -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Thursday, March 22, 2012 10:37 AM To: Sharon Boeyen Cc: PKIX Subject: Re: [pkix] 5280 clarifications On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > As the past editor of X.509 and someone whose history participating in th= e X.509 standards group goes back 25 years to 1987, I'd like to confirm tha= t the X.509 model (going back all the way to the first edition published in= 1988) is one where public key certificate signers/issuers are exclusively = CAs. Therefore the first two sentences in the new proposed text below are a= correct interpretation of X.509.=20 This in interesting to hear. It is relevant to X.509, although it would be = more so if it was actually written in the spec. There is the second issue of whether PKIX, the IETF's profile, is allowed t= o change that model. We have changed a lot of the X.509 model, and there is= a huge amount of software that does so today under the assumption that PKI= X (not X.509) allows this. I'm not convinced that the PKIX document (in this case, the update to the P= KIX document) needs to call out what the X.509 document intended here. --Paul Hoffman From SChokhani@cygnacom.com Thu Mar 22 09:26:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531E21F862A for ; Thu, 22 Mar 2012 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMcGwPclDHNF for ; Thu, 22 Mar 2012 09:26:57 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8136221F861E for ; Thu, 22 Mar 2012 09:26:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="612493" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 22 Mar 2012 12:26:57 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 22 Mar 2012 12:26:56 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 22 Mar 2012 12:26:55 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0IR5aobHri2qqSSK6YQvKPsGBzVwAAOS7w Message-ID: References: from "Santosh Chokhani" at Mar 22, 12 10:48:25 am <201203221619.q2MGJdXq008505@fs4113.wdf.sap.corp> In-Reply-To: <201203221619.q2MGJdXq008505@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 16:26:58 -0000 It is what it is. Unless that is changed, your suggestion of disaster recovery in light of 52= 80 and 2560 is a disaster. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, March 22, 2012 12:20 PM To: Santosh Chokhani Cc: mrex@sap.com; tmiller@mitre.org; pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions Santosh Chokhani wrote: >=20 > Using OCSP to figure out mis-issued certificates is an incomplete=20 > security mechanism. > > Attacker can issue itself a delegated OCSP certificate and point to=20 > that OCSP in mis-issued certificates. Which indicates a design flaw in the scheme to authorize OCSP responders th= rough attributes in the certificate. As I said, PKI was not designed with = the concept of desaster recovery from a CA key compromise in mind. A compromised CA could accept existing PKI credentials to authenticate requ= ests for new credentials when it knows to ignore that information. -Martin From SChokhani@cygnacom.com Thu Mar 22 09:29:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640FC21F8582 for ; Thu, 22 Mar 2012 09:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B1lL5xJnL6s for ; Thu, 22 Mar 2012 09:29:34 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9302921F857F for ; Thu, 22 Mar 2012 09:29:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="4472761" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 22 Mar 2012 12:29:34 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 22 Mar 2012 12:29:33 -0400 From: Santosh Chokhani To: Tom Ritter Date: Thu, 22 Mar 2012 12:29:32 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0IR66JnUF4bqTtQ56Wt6fZavj5rQAAP74w Message-ID: References: <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 16:29:35 -0000 In three cases I am aware of including Diginotar, the attacker could get th= e CA to sign any type of certificate it desired. That would mean creating its own delegated OCSP certificate and putting the= OCSP field of its choice in the AIA. -----Original Message----- From: Tom Ritter [mailto:tom@ritter.vg]=20 Sent: Thursday, March 22, 2012 12:20 PM To: Santosh Chokhani Cc: mrex@sap.com; Miller Timothy J.; pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions On 22 March 2012 10:48, Santosh Chokhani wrote: > Using OCSP to figure out mis-issued certificates is an incomplete securit= y mechanism. > > Attacker can issue itself a delegated OCSP certificate and point to that = OCSP in mis-issued certificates. Only if the attacker has *complete* control of the CA's signing key. If the attack actually has access to a signing *function* that includes log= ic to look for 'strange things' and block them (like basicConstraints, dele= gated OCSP, etc) or a whitelist of attributes to be allowed through (altern= ate names) - then the attacker can't do such a thing. Exploitation in the = real world has to deal with issues like these: you don't always get a 'complete' SQL injection, sometime you're not= allowed to submit commas. You don't always get a XSS bug that lets you in= clude angle brackets, sometime you only get an attribute-based one. You do= n't always get to drop your shellcode on the stack and execute, sometimes y= ou have to ROP first to bypass DEP. You don't always get full access to the CA's HSM, sometimes you only bypass= their authorization checks. I agree that in some cases this security mechanism can be bypassed. But in some cases so can basicConstraints (as we've seen time and time agai= n). It's unknowable for us to say whether this protection mechanism would = or wouldn't *actually* be useful - because it comes down to nitty-gritty of= CA implementation of signing operations, and they're not going to say anyt= hing. It's likely that it would be a useful security mechanism for some CAs and w= ould be automatically bypassed by others. If I were a betting man, I say i= t's more likely to be automatically bypassed than useful *today* - but in the future I hope it eventually would become a useful mech= anism for CAs - it's in their interest to keep the integrity of their certi= ficate history and to whitelist the parameters specified in CSR's. -tom From mstjohns@comcast.net Thu Mar 22 09:52:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239AD21F8607 for ; Thu, 22 Mar 2012 09:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8p5QSludAQG for ; Thu, 22 Mar 2012 09:52:40 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3528121F8602 for ; Thu, 22 Mar 2012 09:52:40 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id ogpM1i0060QuhwU59gsgGv; Thu, 22 Mar 2012 16:52:40 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta02.westchester.pa.mail.comcast.net with comcast id ogsf1i01357vnMg3Ngsf2B; Thu, 22 Mar 2012 16:52:40 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 12:52:38 -0400 To: Sharon Boeyen , Paul Hoffman From: Michael StJohns In-Reply-To: References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120322165240.3528121F8602@ietfa.amsl.com> Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 16:52:41 -0000 At 12:25 PM 3/22/2012, Sharon Boeyen wrote: >It IS written in the spec. You can download the 2009 edition of X.509 free of charge from http://www.x500standard.com/index.php?n=Ig.LatestAvail (or pay for the current version). In the 2009 edition, in the definitions section you will find the following: > >3.4.17 certification authority (CA ): An authority trusted by one or more users to create and assign public-key certificates. Optionally the certification authority may create the users' keys . > >And > >3.4.27 end entity : Either a public key certificate subject that uses its private key for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a resource, or an entity that is a relying party . > >As well as: > >3.4.57 self-issued certificate : A public-key certificate where the issuer and the subject are the same CA. A CA might use self-issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key . > Hi Sharon - I don't actually read it that way - I'm sure you know what you intended, but that's not what it says. What you probably meant to say was: >end entity : Either a public key certificate subject that uses its private key [ONLY] for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a resource, or an entity that is a relying party . AIRC a CA certificate doesn't even need a basicConstraints extension - if it doesn't contain such extension, its imputed to be a CA certificate if it signs certificates. But nothing in X.509 seems to prevent a CA certificate from signing end-entity types of things. So a self-signed certificate without a basicConstraints extension that also signs things other than certificates is both a CA certificate and an end-entity certificate? I think I'm with Paul here.... Mike >-----Original Message----- >From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >Sent: Thursday, March 22, 2012 10:37 AM >To: Sharon Boeyen >Cc: PKIX >Subject: Re: [pkix] 5280 clarifications > >On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > >> As the past editor of X.509 and someone whose history participating in the X.509 standards group goes back 25 years to 1987, I'd like to confirm that the X.509 model (going back all the way to the first edition published in 1988) is one where public key certificate signers/issuers are exclusively CAs. Therefore the first two sentences in the new proposed text below are a correct interpretation of X.509. > > >This in interesting to hear. It is relevant to X.509, although it would be more so if it was actually written in the spec. > >There is the second issue of whether PKIX, the IETF's profile, is allowed to change that model. We have changed a lot of the X.509 model, and there is a huge amount of software that does so today under the assumption that PKIX (not X.509) allows this. > >I'm not convinced that the PKIX document (in this case, the update to the PKIX document) needs to call out what the X.509 document intended here. > >--Paul Hoffman > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From era@x500.eu Thu Mar 22 10:17:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6CC21F8604 for ; Thu, 22 Mar 2012 10:17:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khgIrcnAYhjd for ; Thu, 22 Mar 2012 10:17:46 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8603B21F8607 for ; Thu, 22 Mar 2012 10:17:45 -0700 (PDT) Received: from Morten ([79.138.249.128]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id GUN61442; Thu, 22 Mar 2012 18:17:42 +0100 From: "Erik Andersen" To: "'Michael StJohns'" , "'Sharon Boeyen'" , "'Paul Hoffman'" References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> <20120322165240.3528121F8602@ietfa.amsl.com> In-Reply-To: <20120322165240.3528121F8602@ietfa.amsl.com> Date: Thu, 22 Mar 2012 18:17:35 +0100 Message-ID: <003e01cd084f$b23c7e80$16b57b80$@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: Ac0ITD5WECmLlFwCRyqkEjuG7juMvwAAj90A Content-Language: da Cc: 'PKIX' Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 17:17:47 -0000 In 8.4.2.1 (basicConstraints) has a NOTE 1 saying:" If this extension is = not present, or is flagged non-critical and is not recognized by a certificate-using system, then the certificate is to be considered an end-entity certificate and cannot be used to verify certificate = signatures." I read this to say that in a version 3 public-key certificate this = extension shall be present if the subject is acting as a CA signing public-key certificates. As this note seems normative, it will in the next edition be changed to normal text. Erik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af Michael StJohns Sendt: 22. marts 2012 17:53 Til: Sharon Boeyen; Paul Hoffman Cc: PKIX Emne: Re: [pkix] 5280 clarifications At 12:25 PM 3/22/2012, Sharon Boeyen wrote: >It IS written in the spec. You can download the 2009 edition of X.509 = free of charge from http://www.x500standard.com/index.php?n=3DIg.LatestAvail = (or pay for the current version). In the 2009 edition, in the definitions section you will find the following: > >3.4.17 certification authority (CA ): An authority trusted by one or = more users to create and assign public-key certificates. Optionally the certification authority may create the users' keys . > >And > >3.4.27 end entity : Either a public key certificate subject that uses = its private key for purposes other than signing certificates, or an = attribute certificate holder that uses its attributes to gain access to a = resource, or an entity that is a relying party . > >As well as: > >3.4.57 self-issued certificate : A public-key certificate where the = issuer and the subject are the same CA. A CA might use self-issued = certificates, for example, during a key rollover operation to provide trust from the = old key to the new key . > Hi Sharon -=20 I don't actually read it that way - I'm sure you know what you intended, = but that's not what it says. =20 What you probably meant to say was: >end entity : Either a public key certificate subject that uses its = private key [ONLY] for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a = resource, or an entity that is a relying party . AIRC a CA certificate doesn't even need a basicConstraints extension - = if it doesn't contain such extension, its imputed to be a CA certificate if it signs certificates. =20 But nothing in X.509 seems to prevent a CA certificate from signing end-entity types of things. So a self-signed certificate without a basicConstraints extension that = also signs things other than certificates is both a CA certificate and an end-entity certificate? I think I'm with Paul here.... Mike >-----Original Message----- >From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 >Sent: Thursday, March 22, 2012 10:37 AM >To: Sharon Boeyen >Cc: PKIX >Subject: Re: [pkix] 5280 clarifications > >On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > >> As the past editor of X.509 and someone whose history participating = in the X.509 standards group goes back 25 years to 1987, I'd like to = confirm that the X.509 model (going back all the way to the first edition = published in 1988) is one where public key certificate signers/issuers are = exclusively CAs. Therefore the first two sentences in the new proposed text below = are a correct interpretation of X.509.=20 > > >This in interesting to hear. It is relevant to X.509, although it would = be more so if it was actually written in the spec. > >There is the second issue of whether PKIX, the IETF's profile, is = allowed to change that model. We have changed a lot of the X.509 model, and = there is a huge amount of software that does so today under the assumption that = PKIX (not X.509) allows this. > >I'm not convinced that the PKIX document (in this case, the update to = the PKIX document) needs to call out what the X.509 document intended here. > >--Paul Hoffman > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Thu Mar 22 10:31:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBA21F85B6 for ; Thu, 22 Mar 2012 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8CFpRTdwvU5 for ; Thu, 22 Mar 2012 10:31:19 -0700 (PDT) Received: from col0-omc3-s12.col0.hotmail.com (col0-omc3-s12.col0.hotmail.com [65.55.34.150]) by ietfa.amsl.com (Postfix) with ESMTP id BB6CC21F8546 for ; Thu, 22 Mar 2012 10:31:19 -0700 (PDT) Received: from COL119-W11 ([65.55.34.136]) by col0-omc3-s12.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 10:31:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d9748d9b-f49f-429e-b263-930459be7c9e_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Thu, 22 Mar 2012 10:31:18 -0700 Importance: Normal In-Reply-To: References: , <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp>, , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2012 17:31:19.0148 (UTC) FILETIME=[978B62C0:01CD0851] Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 17:31:20 -0000 --_d9748d9b-f49f-429e-b263-930459be7c9e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So=2C based on what you are saying below the problem boils down to this- CA= knows that is has been compromised and fraudulent user certificates have b= een issued using its keys. There is now way for the CA to know what these c= ertificates because all the traces of this activity has been wiped off from= the audit logs.- CA knows that no OCSP or certificate signing certificate = has been issued off its keys because it has some fool proof mechanism to de= tect issuance of such certificates. (May be different=2Cmore secure audit = logs or controls that detect this kind of activity) Here are the solutions that are available to the CA to address the breach.-= Continue operation and allow use of fraudulent certificate=2C until some o= ne reports them and then revoke them. Accept the liability=2C payoff the vi= ctims and classify it as cost of doing business- Revoke the CA. Own up=2C R= eissue all the good certificate off a new key and classify the cost associa= ted with doing this as cost of doing business.- Propose a standard which fu= ndamentally changes how RPs do certificate processing (based on CRLs and OC= SP)=2C have them comply with this new standard and pass on all these costs = to the RPs. Remember that the costs include not only those associated with = major upgrade of their certificate processing software but also those assoc= iate with increased bandwidth and storage costs (size of CRLs vs whitelists= =2C bloated OCSP requests and responses).=20 Which solution is preferable to you - if you are a CA=2C if you are a RP?Wh= at is you preference if you are a CA whose security practices are so good t= hat you are not among those who get compromised once in 15 years? > From: tom@ritter.vg > Date: Thu=2C 22 Mar 2012 12:20:00 -0400 > To: SChokhani@cygnacom.com > CC: pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions >=20 > On 22 March 2012 10:48=2C Santosh Chokhani wrote= : > > Using OCSP to figure out mis-issued certificates is an incomplete secur= ity mechanism. > > > > Attacker can issue itself a delegated OCSP certificate and point to tha= t OCSP in mis-issued certificates. >=20 > Only if the attacker has *complete* control of the CA's signing key. > If the attack actually has access to a signing *function* that > includes logic to look for 'strange things' and block them (like > basicConstraints=2C delegated OCSP=2C etc) or a whitelist of attributes t= o > be allowed through (alternate names) - then the attacker can't do such > a thing. Exploitation in the real world has to deal with issues like > these: you don't always get a 'complete' SQL injection=2C sometime > you're not allowed to submit commas. You don't always get a XSS bug > that lets you include angle brackets=2C sometime you only get an > attribute-based one. You don't always get to drop your shellcode on > the stack and execute=2C sometimes you have to ROP first to bypass DEP. > You don't always get full access to the CA's HSM=2C sometimes you only > bypass their authorization checks. >=20 > I agree that in some cases this security mechanism can be bypassed. > But in some cases so can basicConstraints (as we've seen time and time > again). It's unknowable for us to say whether this protection > mechanism would or wouldn't *actually* be useful - because it comes > down to nitty-gritty of CA implementation of signing operations=2C and > they're not going to say anything. >=20 > It's likely that it would be a useful security mechanism for some CAs > and would be automatically bypassed by others. If I were a betting > man=2C I say it's more likely to be automatically bypassed than useful > *today* - but in the future I hope it eventually would become a useful > mechanism for CAs - it's in their interest to keep the integrity of > their certificate history and to whitelist the parameters specified in > CSR's. >=20 > -tom > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_d9748d9b-f49f-429e-b263-930459be7c9e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So=2C based on what you are saying below the problem boils down to this- CA knows that is has been compromised and =3Bfraudulent =3Buser = certificates have been issued using its keys. There is now way for the CA t= o know what these certificates because all the traces of this activity has = been wiped off from the audit logs.
- CA knows that no OCSP or ce= rtificate signing certificate has been issued off its keys because it has s= ome fool proof mechanism to detect issuance of such certificates. (May be d= ifferent=2Cmore secure  =3Baudit logs or controls that detect this kind= of activity)

Here are the solutions that are = =3Bavailable =3Bto the CA to address the breach.
- Continue o= peration and allow use of fraudulent certificate=2C until some one reports = them and then revoke them. Accept the liability=2C payoff the victims and c= lassify it as cost of doing business
- Revoke the CA. Own up=2C R= eissue all the good certificate off a new key and classify the cost associa= ted with doing this as cost of doing business.
- Propose a standa= rd which fundamentally changes how RPs do certificate processing (based on = CRLs and OCSP)=2C have them comply with this new standard and pass on all t= hese costs to the RPs. Remember that the costs include not only those assoc= iated with major upgrade of their certificate processing software but also = those associate with increased bandwidth and storage costs (size of CRLs vs= whitelists=2C bloated OCSP requests and responses). =3B

=
Which solution is preferable to you - if you are a CA=2C if you = are a RP?
What is you preference if you are a CA whose security p= ractices are so good that you are not among those who get compromised once = in 15 years?


>=3B From: tom@ritter.vg
>=3B Date: Thu=2C 22 Mar 2012 12:= 20:00 -0400
>=3B To: SChokhani@cygnacom.com
>=3B CC: pkix@ietf.or= g
>=3B Subject: Re: [pkix] Possible OCSP Extensions
>=3B
>= =3B On 22 March 2012 10:48=2C Santosh Chokhani <=3BSChokhani@cygnacom.com= >=3B wrote:
>=3B >=3B Using OCSP to figure out mis-issued certific= ates is an incomplete security mechanism.
>=3B >=3B
>=3B >=3B= Attacker can issue itself a delegated OCSP certificate and point to that O= CSP in mis-issued certificates.
>=3B
>=3B Only if the attacker h= as *complete* control of the CA's signing key.
>=3B If the attack actu= ally has access to a signing *function* that
>=3B includes logic to lo= ok for 'strange things' and block them (like
>=3B basicConstraints=2C = delegated OCSP=2C etc) or a whitelist of attributes to
>=3B be allowed= through (alternate names) - then the attacker can't do such
>=3B a th= ing. Exploitation in the real world has to deal with issues like
>=3B= these: you don't always get a 'complete' SQL injection=2C sometime
>= =3B you're not allowed to submit commas. You don't always get a XSS bug>=3B that lets you include angle brackets=2C sometime you only get an>=3B attribute-based one. You don't always get to drop your shellcode o= n
>=3B the stack and execute=2C sometimes you have to ROP first to byp= ass DEP.
>=3B You don't always get full access to the CA's HSM=2C some= times you only
>=3B bypass their authorization checks.
>=3B
&= gt=3B I agree that in some cases this security mechanism can be bypassed.>=3B But in some cases so can basicConstraints (as we've seen time and = time
>=3B again). It's unknowable for us to say whether this protecti= on
>=3B mechanism would or wouldn't *actually* be useful - because it = comes
>=3B down to nitty-gritty of CA implementation of signing operat= ions=2C and
>=3B they're not going to say anything.
>=3B
>= =3B It's likely that it would be a useful security mechanism for some CAs>=3B and would be automatically bypassed by others. If I were a bettin= g
>=3B man=2C I say it's more likely to be automatically bypassed than= useful
>=3B *today* - but in the future I hope it eventually would be= come a useful
>=3B mechanism for CAs - it's in their interest to keep = the integrity of
>=3B their certificate history and to whitelist the p= arameters specified in
>=3B CSR's.
>=3B
>=3B -tom
>=3B= _______________________________________________
>=3B pkix mailing lis= t
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/p= kix
= --_d9748d9b-f49f-429e-b263-930459be7c9e_-- From stephen.farrell@cs.tcd.ie Thu Mar 22 10:45:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6E721F8596 for ; Thu, 22 Mar 2012 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gEt9S+MJbnk for ; Thu, 22 Mar 2012 10:45:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5F521F85AA for ; Thu, 22 Mar 2012 10:45:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 688FD153B61; Thu, 22 Mar 2012 17:45:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332438301; bh=m7LrTTyv2BIzd9 x0Mt3Sep2zoQPcPWoEvT8kCEWlnxw=; b=R/mVTgybCeySJbix64eBweJFF14cRp BBZJ451BResX+0sOB+0TbofMik23e7PXQJVC38TPkcyNDMGYh+Vz4y0ViFjkbdJo vqLmoWm/k9uaHIyeIX2Ie2mbT2nE0RChoiV3OaNC0bp/0QUrmWVZuY31weK1B0PX NriRhxR0Yp1Af7Gmq95SOmk8ZlGqh5kkoOaQixAqQE4GP8e+jTRPlAaeDdAhUWNT NXObiQG7QvyU4eWRFE6cA3VyDs3h768mXjpCAM63BxsCixL/NQG6K9GwY6ycT+NU 2iywjqmr1WDh5lLlKP718YWxoaLrb4XvGGDcBy3hp6XKGqZSDB/YyrhQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Jaxdzd+jIECz; Thu, 22 Mar 2012 17:45:01 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.45.51.117]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0FEFB153B57; Thu, 22 Mar 2012 17:45:00 +0000 (GMT) Message-ID: <4F6B651B.2070507@cs.tcd.ie> Date: Thu, 22 Mar 2012 17:44:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sharon Boeyen References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PKIX , Paul Hoffman Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 17:45:05 -0000 Hi Sharon, Two things on this. a) I agree with others that whatever the intent, the text is not clear either way and to me doesn't preclude self-signed cert-like things not generated by CAs. I'm pretty confident of that for 5280, since I checked, but haven't read x.509 for quite a while. (And anyway, how could those documents preclude them? I can show you one anytime you like.) But *much* more importantly: b) There is no way in the world that self-signed certs that are not from CAs are going to disappear and attempting to specify them out of existence would just be dumb. That's not only due to installed base, nor only due to the fact that regardless of X.509 or 5280 other IETF protocols (TLS, notably) allow for and see deployments of these, but is also because sometimes these things are useful and easier than setting up a pseudo or personal CA. If someone cares enough to invent some new/better terminology, that might of course be useful, but I'm not sure it'd be worth what'd be bound to be a gigantic and (I predict;-) mostly pointless debate. If someone else wanted to release some OSS that did the make a pesudo-CA thing in an easy to use way that'd be great too and who knows might reduce the need for self-signed certs (not generated by a CA). My personal take fwiw, no hats and all that, S. On 03/22/2012 04:25 PM, Sharon Boeyen wrote: > It IS written in the spec. You can download the 2009 edition of X.509 free of charge from http://www.x500standard.com/index.php?n=Ig.LatestAvail (or pay for the current version). In the 2009 edition, in the definitions section you will find the following: > > 3.4.17 certification authority (CA ): An authority trusted by one or more users to create and assign public-key certificates. Optionally the certification authority may create the users' keys . > > And > > 3.4.27 end entity : Either a public key certificate subject that uses its private key for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a resource, or an entity that is a relying party . > > As well as: > > 3.4.57 self-issued certificate : A public-key certificate where the issuer and the subject are the same CA. A CA might use self-issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key . > > > > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, March 22, 2012 10:37 AM > To: Sharon Boeyen > Cc: PKIX > Subject: Re: [pkix] 5280 clarifications > > On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote: > >> As the past editor of X.509 and someone whose history participating in the X.509 standards group goes back 25 years to 1987, I'd like to confirm that the X.509 model (going back all the way to the first edition published in 1988) is one where public key certificate signers/issuers are exclusively CAs. Therefore the first two sentences in the new proposed text below are a correct interpretation of X.509. > > > This in interesting to hear. It is relevant to X.509, although it would be more so if it was actually written in the spec. > > There is the second issue of whether PKIX, the IETF's profile, is allowed to change that model. We have changed a lot of the X.509 model, and there is a huge amount of software that does so today under the assumption that PKIX (not X.509) allows this. > > I'm not convinced that the PKIX document (in this case, the update to the PKIX document) needs to call out what the X.509 document intended here. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From alan.sill@ttu.edu Thu Mar 22 11:11:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10B321F8550 for ; Thu, 22 Mar 2012 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3eYP4E+stXQ for ; Thu, 22 Mar 2012 11:11:36 -0700 (PDT) Received: from eurynomus.ttu.edu (eurynomus.ttu.edu [129.118.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 535A521F850D for ; Thu, 22 Mar 2012 11:11:36 -0700 (PDT) Received: from hyperbius.net.ttu.edu (129.118.1.214) by mxout3.ttu.edu (129.118.1.201) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 13:11:35 -0500 Received: from dr124.dhcp.ttu.edu (129.118.90.225) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 13:11:34 -0500 Message-ID: <1777D550-177D-4C11-97E8-EE7D009208FC@ttu.edu> From: Alan Sill To: PKIX In-Reply-To: <4F6B651B.2070507@cs.tcd.ie> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Mar 2012 13:11:31 -0500 References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> <4F6B651B.2070507@cs.tcd.ie> X-Mailer: Apple Mail (2.936) Received-SPF: Pass (eurynomus.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.214 as permitted sender) receiver=eurynomus.ttu.edu; client-ip=129.118.1.214; helo=hyperbius.net.ttu.edu; X-TechMail-Edge-Route: TTU Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 18:11:40 -0000 I also agree that this is likely to be a pointless argument, as it is technically possible to generate self-signed certificates, and unambiguously trivial to identify them. In practice, any set of CP and/or CPS statements for a CA will include statements describing the route of trust. The matter of trust in a particular PKI will be driven by a profile. It is not necessary for the base specification (X.509 and/or 5280) to specify statements as to whether self-signed certificates are allowed or not, as this will be necessarily covered in the profile. An example I can hold out that has real application in large-scale PKi implementations is the Grid Certificate Profile, GFD.125 from OGF, which covers the conditions for accreditation used by the International Grid Trust Federation for large-scale grids. (Significant work is going on to extend the use of tools based on these into cloud architectures as well). This document is currently in informational status, but has started the process to become a proposed recommendation from OGF. http://ogf.org/documents/GFD.125.pdf This profile (properly named) gives the conditions for application of X.509 and RFC3280 -- the document in progress as a proposed recommendation will update this to 5280. It then serves as input to a trust federation (the IGTF), that enforces this and other conditions on the accreditation of certification authorities to be used in its distribution, http://www.igtf.net Since the decisions on whether or not to trust CAs will in principle be made either by a trust federation of tis nature, or by processes with equivalent constraints such as those used for browser inclusion, and since the consumer not part of such federations and using such CAs is warned of the existence of a self-signed cert, is this really a problem that PKIX needs to solve? I argue no, as this is essentially always extended by a profile. Alan On Mar 22, 2012, at 12:44 PM, Stephen Farrell wrote: > There is no way in the world that self-signed certs that are not from > CAs are going to disappear and attempting to specify them out of > existence would just be dumb. That's not only due to installed base, > nor only due to the fact that regardless of X.509 or 5280 other IETF > protocols (TLS, notably) allow for and see deployments of these, but > is also because sometimes these things are useful and easier than > setting up a pseudo or personal CA. > > If someone cares enough to invent some new/better terminology, that > might of course be useful, but I'm not sure it'd be worth what'd be > bound to be a gigantic and (I predict;-) mostly pointless debate. From JAY.S.MCGUERTY@saic.com Thu Mar 22 11:13:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8A21E8029 for ; Thu, 22 Mar 2012 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mp-C5CvlF+M for ; Thu, 22 Mar 2012 11:13:30 -0700 (PDT) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id E03A821E8028 for ; Thu, 22 Mar 2012 11:13:29 -0700 (PDT) Received: from 0599-its-sbg01.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-1154576 for pkix@ietf.org; Thu, 22 Mar 2012 11:13:20 -0700 X-AuditID: 8b791438-b7c96ae000000c8c-39-4f6b6bc0a562 Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg01.saic.com (Symantec Brightmail Gateway) with SMTP id 7C.97.03212.0CB6B6F4; Thu, 22 Mar 2012 11:13:20 -0700 (PDT) Received: from 0461-its-exmb03.us.saic.com ([10.8.67.26]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 11:13:19 -0700 Received: from 10.31.250.248 ([10.31.250.248]) by 0461-its-exmb03.us.saic.com ([10.8.67.26]) via Exchange Front-End Server cpmail.saic.com ([139.121.17.195]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Mar 2012 18:13:19 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 22 Mar 2012 11:13:19 -0700 From: Jay McGuerty To: "pkix@ietf.org" Message-Id: Thread-Topic: [pkix] 5280 clarifications Thread-Index: Ac0IV3V+lXUH4rGmhEyJaK3cDh7L5g== In-Reply-To: <1777D550-177D-4C11-97E8-EE7D009208FC@ttu.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2012 18:13:19.0817 (UTC) FILETIME=[75FAF390:01CD0857] X-Brightmail-Tracker: AAAAAA== Subject: [pkix] FW: 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 18:13:30 -0000 Please remove me from this email list -- Jay McGuerty CISSP, GCIH, GPEN, GWAPT Principal Security Engineer SAIC/IISBU 10260 Campus Point Drive Jay McGuerty Principal Security Engineer Science Application International Corporation 10260 Campus Point Drive San Diego, CA 92121 858.826.7309 w 858.663.5209 c This communication may contain information that is legally privileged, confidential or exempt from disclosure. If you are not the intended recipient, please do not read, disseminate, distribute or copy this communication. Anyone who receives this message in error should notify the sender immediately by telephone or by return e-mail and delete it from his or her computer. ------ Forwarded Message From: Alan Sill Date: Thu, 22 Mar 2012 13:11:31 -0500 To: PKIX Subject: Re: [pkix] 5280 clarifications pkix@ietf.org ------ End of Forwarded Message From mrex@sap.com Thu Mar 22 11:23:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA31F21F858E for ; Thu, 22 Mar 2012 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo07x0JaNgoD for ; Thu, 22 Mar 2012 11:23:03 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4321F854F for ; Thu, 22 Mar 2012 11:22:55 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2MIMpGa000801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 19:22:51 +0100 (MET) From: Martin Rex Message-Id: <201203221822.q2MIMpjD015640@fs4113.wdf.sap.corp> To: sharon.boeyen@entrust.com (Sharon Boeyen) Date: Thu, 22 Mar 2012 19:22:51 +0100 (MET) In-Reply-To: from "Sharon Boeyen" at Mar 22, 12 09:15:56 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] 5280 clarifications 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, 22 Mar 2012 18:23:03 -0000 Sharon Boeyen wrote: > > As the past editor of X.509 and someone whose history participating > in the X.509 standards group goes back 25 years to 1987, I'd like > to confirm that the X.509 model (going back all the way to the first > edition published in 1988) is one where public key certificate > signers/issuers are exclusively CAs. Therefore the first two sentences > in the new proposed text below are a correct interpretation of X.509. I think we all know *that* limitation of X.509, which is IMHO hard to misunderstand (once found) in X.509 11/2008, section 3.4.61: 3.4.61 self-signed certificate: [...] NOTE Use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this Recommendation | International Standard. The interesting question is really what should PKIX say instead so that a pretty common practice in the installed base can migrate from being "implementation defined" to a more coherent/consistent behaviour in the future. -Martin From paul.hoffman@vpnc.org Thu Mar 22 11:46:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BDB21F8526 for ; Thu, 22 Mar 2012 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUhSm8X5Ztri for ; Thu, 22 Mar 2012 11:46:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E436E21F8531 for ; Thu, 22 Mar 2012 11:46:45 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2MIkiTw026141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Mar 2012 11:46:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201203221822.q2MIMpjD015640@fs4113.wdf.sap.corp> Date: Thu, 22 Mar 2012 11:46:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <14F158A5-E0DB-4873-987A-C21FAE14169F@vpnc.org> References: <201203221822.q2MIMpjD015640@fs4113.wdf.sap.corp> To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 18:46:46 -0000 On Mar 22, 2012, at 11:22 AM, Martin Rex wrote: > 3.4.61 self-signed certificate: [...] >=20 > NOTE Use of self-issued certificates and self-signed certificates > issued by other than CAs are outside the scope of this > Recommendation | International Standard. This sentence was the one that made the most sense to me when we = discussed the topic of self-issued certs last year in the DANE WG. If = X.509 puts them out of scope, PKIX can say whatever it wants, and PKIX = should reflect the real world. --Paul Hoffman From peter.sylvester@edelweb.fr Thu Mar 22 12:06:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7121F8531 for ; Thu, 22 Mar 2012 12:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjcld3T3IDzi for ; Thu, 22 Mar 2012 12:06:04 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D621F8503 for ; Thu, 22 Mar 2012 12:06:04 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 84FE87F08; Thu, 22 Mar 2012 20:05:57 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 713FF7AB1D4; Thu, 22 Mar 2012 19:28:50 +0100 (CET) Received: from [192.168.0.48] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 44839236368; Thu, 22 Mar 2012 15:03:08 -0400 (EDT) Message-ID: <4F6B7814.40800@edelweb.fr> Date: Thu, 22 Mar 2012 20:05:56 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Sharon Boeyen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Mar 2012 19:06:04 -0000 Sharon Boeyen wrote: > > As the past editor of X.509 and someone whose history participating > in the X.509 standards group goes back 25 years to 1987, I'd like > to confirm that the X.509 model (going back all the way to the first > edition published in 1988) is one where public key certificate > signers/issuers are exclusively CAs. Therefore the first two sentences > in the new proposed text below are a correct interpretation of X.509. "public key certificate signers/issuers are exclusively CAs" has at least two interpretations? : 1 - only a CA can sign certs (if you have some other, maybe nontechnical, definition of CA) 2 - Any entity that appears as issuer, is a CA (a technical definition of a CA). I tend to think that the way to read x509 88 version is pretty close to the second interpretation. From hallam@gmail.com Thu Mar 22 16:16:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6560E21F84DA for ; Thu, 22 Mar 2012 16:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe3jl35pvYzR for ; Thu, 22 Mar 2012 16:16:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9F21F84DC for ; Thu, 22 Mar 2012 16:16:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2566050ghb.31 for ; Thu, 22 Mar 2012 16:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jRZD33sD/njx6WeNOkKYjyiX0NC63YbOW/cpWx6RqKg=; b=mQTqhxXBZq9VWpToV+ozLJkUElNzuzwWdK/iHoshr8veGAjEWitOVpH8zJBSDO0yKl cnZRhE/W6LbJREQSwvke30YxV3AiiYQO8elBEB1RqVaAW7/E/C0me6Cz3tk76qpMeBMS 2pxJPw6wy8kWlVtgOuWFI3Bw7BP76QNMZ2NU0pPae5E8yC9Y6QBur4267vPWI/V5pgje ykjNBEk/9vw7AbjRCdOWVcX3x0ZguYlqUXWkLnGGSX5osrz8FysIvaYQyEkP5xyiY8ro SM4JuK0e/OYeEDoRt1sp2wemhB/K1scMYhH3aqJSB4auA7V8en5ydCmTjBbL+z2d+NSO 7obg== MIME-Version: 1.0 Received: by 10.60.14.101 with SMTP id o5mr12861793oec.20.1332458184168; Thu, 22 Mar 2012 16:16:24 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Thu, 22 Mar 2012 16:16:24 -0700 (PDT) In-Reply-To: References: <201203221619.q2MGJdXq008505@fs4113.wdf.sap.corp> Date: Thu, 22 Mar 2012 19:16:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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, 22 Mar 2012 23:16:25 -0000 The issue here was what it is going to be. That is now the issue in another place. Thanks for playing. On Thu, Mar 22, 2012 at 12:26 PM, Santosh Chokhani wrote: > It is what it is. > > Unless that is changed, your suggestion of disaster recovery in light of = 5280 and 2560 is a disaster. > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, March 22, 2012 12:20 PM > To: Santosh Chokhani > Cc: mrex@sap.com; tmiller@mitre.org; pkix@ietf.org > Subject: Re: [pkix] Possible OCSP Extensions > > Santosh Chokhani wrote: >> >> Using OCSP to figure out mis-issued certificates is an incomplete >> security mechanism. >> >> Attacker can issue itself a delegated OCSP certificate and point to >> that OCSP in mis-issued certificates. > > Which indicates a design flaw in the scheme to authorize OCSP responders = through attributes in the certificate. =A0As I said, PKI was not designed w= ith the concept of desaster recovery from a CA key compromise in mind. > > A compromised CA could accept existing PKI credentials to authenticate re= quests for new credentials when it knows to ignore that information. > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From tgindin@us.ibm.com Thu Mar 22 17:44:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCFB21F843F for ; Thu, 22 Mar 2012 17:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.014 X-Spam-Level: X-Spam-Status: No, score=-10.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+d2qjx4I52h for ; Thu, 22 Mar 2012 17:44:11 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1F76E21F843E for ; Thu, 22 Mar 2012 17:44:11 -0700 (PDT) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Mar 2012 20:44:09 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 22 Mar 2012 20:44:00 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 642AF38C8052 for ; Thu, 22 Mar 2012 20:43:59 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2N0hxAf328876 for ; Thu, 22 Mar 2012 20:43:59 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2N6EpdT010894 for ; Fri, 23 Mar 2012 02:14:51 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2N6EpLB010891; Fri, 23 Mar 2012 02:14:51 -0400 In-Reply-To: References: from "Miller, Timothy J." at Mar 22, 12 01:24:25 pm <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> To: Santosh Chokhani MIME-Version: 1.0 X-KeepSent: 8D58968C:224CE69C-852579C9:00574121; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 22 Mar 2012 20:43:57 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/22/2012 20:43:58, Serialize complete at 03/22/2012 20:43:58 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032300-1976-0000-0000-00000BB1A49C Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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: Fri, 23 Mar 2012 00:44:12 -0000 Santosh: That's why one of my suggestions Tuesday was "I am not sure why it's a good thing that id-ad-ocsp is recommended to be placed into the subject certificate's AIA extension rather than into the issuer's SIA", followed by "A migration path to change this would start by recommending that an SIA value in the issuer certificate SHOULD take precedence over an AIA value in the subject one if both values are present". Anything with revocation information in the subject certificate is potentially vulnerable to this, but unsigned OCSP is probably somewhat more so. Tom Gindin From: Santosh Chokhani To: "mrex@sap.com" , "Miller Timothy J." , Cc: "pkix@ietf.org" Date: 03/22/2012 10:49 AM Subject: Re: [pkix] Possible OCSP Extensions Sent by: pkix-bounces@ietf.org Using OCSP to figure out mis-issued certificates is an incomplete security mechanism. Attacker can issue itself a delegated OCSP certificate and point to that OCSP in mis-issued certificates. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Martin Rex Sent: Thursday, March 22, 2012 10:42 AM To: Miller Timothy J. Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions Miller, Timothy J. wrote: > > Martin Rex wrote: > > > Miller, Timothy J. wrote: > > > >> There is a corner case where the CA history is trusted, the > >> Responder signing key is trusted, but the CA signing key is not. > >> In this case, NOTISSUED can signal a compromise. > >> This is the corner case I think Philip is after. > > > > I do not think that this is a "corner case"; I believe it will be > > the most probable case that the CA key compromise is a temporary > > loss of control over certificate issuance, and may be accompanied by > > the loss of records what got signed (e.g. physical damage inflicted > > by the attacker). > > I think you missed the point. The corner is the loss of CA key > control while *keeping* CA history integrity. In both recent cases we > have before us, loss of CA key control was temporary, but the CA > history couldn't be trusted. NOTISSUED critically depends on *both*. Just the opposite. In the DigiNotar case, the history integrity was retained (that is the purpose of any desaster recovery plan). And the means that they used for their own OCSP server to recognize misissued certs was to check OCSP requests against their database of past issued certs and declare all other certs not in that database as REVOKED. But unless the OCSP requests include a certificate hash, that check is not reliable, because depending on how much control the attacker had over the creation of serial numbers, he could have tried to reuse serials of correctly issued certs for the misissued certs. That's why OCSP requests should be updated to include a certificate hash besides the issuer and serial. > > The point of NOTISSUED is to *aid* in detecting compromise so recovery > can be attempted. Once you're *in* recovery, NOTISSUED is irrelevant > because you can just as easily respond REVOKED for those certs--as we > see from recent cases. Just the opposite. NOTISSUED is only relevant in case of suspicion and recovery. Only those that continue claiming that potential compromise of a CA is a non-event which they do not have to account for do not care about "NOTISSUED" status. -Martin _______________________________________________ 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 tgindin@us.ibm.com Thu Mar 22 17:44:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7C21E801B for ; Thu, 22 Mar 2012 17:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8y4gQhyv3Ko for ; Thu, 22 Mar 2012 17:44:25 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id D670D21E8024 for ; Thu, 22 Mar 2012 17:44:24 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Mar 2012 20:44:20 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 22 Mar 2012 20:44:18 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id F17D338C8054 for ; Thu, 22 Mar 2012 20:44:17 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2N0iH5d162656 for ; Thu, 22 Mar 2012 20:44:18 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2N0iG06004600 for ; Thu, 22 Mar 2012 20:44:16 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2N0iCmh004125; Thu, 22 Mar 2012 20:44:13 -0400 In-Reply-To: References: <1168D8B4-B74F-4B31-86F4-CE293AD79DAB@vpnc.org> <4F63838C.4090408@nist.gov> <2501EF57-3E1B-448D-914A-E1846191FD19@mitre.org> <03CE4B03-AD6E-4B2A-9E84-36D322F4951F@jpl.nasa.gov> To: brennan security MIME-Version: 1.0 X-KeepSent: 19F9D27D:36AF68A9-852579C9:0003D28A; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 22 Mar 2012 20:44:10 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/22/2012 20:44:12, Serialize complete at 03/22/2012 20:44:12 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032300-9360-0000-0000-000004C8A6A6 Cc: pkix@ietf.org Subject: Re: [pkix] certificate not issued OCSP status response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 00:44:25 -0000 The point of the "requested certificate" request extension is to permit the responder to distinguish between the conditions among those which indicate that an unrecorded but properly signed certificate is in circulation and the ones which don't. If the certificate has a valid signature but is missing from the repository, the CA has some obligation to take action. An attempted DoS or a buggy client does not create any such obligation, nor does security testing. My own draft of requirements has three entries, and one of them is just "To maintain backwards compatibility of both client and responder code with RFC 2560-compliant implementations in the complementary role". The first substantive requirement is "To permit the client to distinguish between those certificate serial numbers which the responder claims to belong to valid certificates and those which the responder is simply stating have not been revoked, in those cases where the responder chooses to implement this feature". This is only important as a way of making decisions if it's considered plausible that a validly signed certificate can be created without the CA standing behind it, whether by digest collision, key compromise, or an attacker gaining sufficient control of the CA to issue certificates and then remove the internal record of them. The other is "To permit a client to present a certificate to a responder supporting the unknown status (or the not issued status) for determination of whether that certificate is known to the responder", which is a way of communicating a certificate which is a candidate to be "unrevoked, with a valid signature, but never valid". Tom Gindin From: brennan security To: "Henry B. Hotz" , Cc: "pkix@ietf.org PKIX" Date: 03/20/2012 02:21 PM Subject: Re: [pkix] certificate not issued OCSP status response Sent by: pkix-bounces@ietf.org Henry, this is a good point you are making. A not issued can be indicative of one of a few things: CA compromise HSM compromise Attempted denial of service Security testing / Auditing bad performance testing buggy client bad data -b On Tue, Mar 20, 2012 at 1:13 PM, Henry B. Hotz wrote: On Mar 20, 2012, at 5:31 AM, Miller, Timothy J. wrote: > On Mar 19, 2012, at 3:18 PM, Henry B. Hotz wrote: > >> To me UNKNOWN means "my knowledge is incomplete (and therefore not authoritative)" and does not mean "this is clearly bogus". > > I can form bogus Issuer/Serial combinations all day long. What does it mean to the CA operator if I do? > > -- T As you ourself pointed out, it means someone's generating bogus queries, maybe to make the CA shut down for an audit. In the real world it most likely means someone's got a buggy client. I think the real knowledge of whether a "not issued" response is meaningful is mostly on the client side, which raises questions of how a CA can know whether action is needed or not, and whether the client/user will know what to do with it. (I don't run a CA.) ------------------------------------------------------ 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 _______________________________________________ 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 era@x500.eu Fri Mar 23 02:48:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12621F8557 for ; Fri, 23 Mar 2012 02:48:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPsjC6IlV46c for ; Fri, 23 Mar 2012 02:48:09 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 997F521F84BF for ; Fri, 23 Mar 2012 02:48:08 -0700 (PDT) Received: from Morten ([212.27.29.135]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id HMT53306 for ; Fri, 23 Mar 2012 10:48:06 +0100 From: "Erik Andersen" To: "'PKIX'" References: <201203221822.q2MIMpjD015640@fs4113.wdf.sap.corp> <14F158A5-E0DB-4873-987A-C21FAE14169F@vpnc.org> In-Reply-To: <14F158A5-E0DB-4873-987A-C21FAE14169F@vpnc.org> Date: Fri, 23 Mar 2012 10:48:04 +0100 Message-ID: <003201cd08da$0dd30b80$29792280$@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: Ac0IXCvkSjPqOivwSjK5XIhjmUzDFQAfVKvw Content-Language: da Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 09:48:13 -0000 What that note say is that if you outside the standard, you are on your = own and Good bless you. Standards are not laws. You follow them for interoperability reasons. If you want to cut corners, nobody can stop = you. Erik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Paul Hoffman Sendt: 22. marts 2012 19:47 Til: PKIX Emne: Re: [pkix] 5280 clarifications On Mar 22, 2012, at 11:22 AM, Martin Rex wrote: > 3.4.61 self-signed certificate: [...] >=20 > NOTE Use of self-issued certificates and self-signed certificates > issued by other than CAs are outside the scope of this > Recommendation | International Standard. This sentence was the one that made the most sense to me when we = discussed the topic of self-issued certs last year in the DANE WG. If X.509 puts = them out of scope, PKIX can say whatever it wants, and PKIX should reflect = the real world. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Fri Mar 23 08:07:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF621F8599 for ; Fri, 23 Mar 2012 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf68Py7-pZtc for ; Fri, 23 Mar 2012 08:07:51 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84921F8584 for ; Fri, 23 Mar 2012 08:07:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,636,1325480400"; d="scan'208";a="619240" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 23 Mar 2012 11:07:50 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 23 Mar 2012 11:07:50 -0400 From: Santosh Chokhani To: Tom Gindin Date: Fri, 23 Mar 2012 11:07:48 -0400 Thread-Topic: [pkix] Possible OCSP Extensions Thread-Index: Ac0IjhWJq5cYTXmiSJSRKyL+j3KuBQAeHLZg Message-ID: References: from "Miller, Timothy J." at Mar 22, 12 01:24:25 pm <201203221441.q2MEfqTO002584@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Possible OCSP 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: Fri, 23 Mar 2012 15:07:55 -0000 Tom, If SIA simply has OCSP pointer in it, it does not fix the problem. It requ= ires the attacker to poison the DNS for the relying parties so that the OCS= P requests come to it. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Thursday, March 22, 2012 8:44 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org; Miller Timothy J. Subject: Re: [pkix] Possible OCSP Extensions Santosh: That's why one of my suggestions Tuesday was "I am not sure why it'= s a good thing that id-ad-ocsp is recommended to be placed into the subject= certificate's AIA extension rather than into the issuer's SIA", followed b= y "A migration path to change this would start by recommending that an SIA = value in the issuer certificate SHOULD take precedence over an AIA value in= the subject one if both values are present". Anything with revocation inf= ormation in the subject certificate is potentially vulnerable to this, but = unsigned OCSP is probably somewhat more so. Tom Gindin From: Santosh Chokhani To: "mrex@sap.com" , "Miller Timothy J."=20 ,=20 Cc: "pkix@ietf.org" Date: 03/22/2012 10:49 AM Subject: Re: [pkix] Possible OCSP Extensions Sent by: pkix-bounces@ietf.org Using OCSP to figure out mis-issued certificates is an incomplete security = mechanism. Attacker can issue itself a delegated OCSP certificate and point to that OC= SP in mis-issued certificates. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Thursday, March 22, 2012 10:42 AM To: Miller Timothy J. Cc: pkix@ietf.org Subject: Re: [pkix] Possible OCSP Extensions Miller, Timothy J. wrote: >=20 > Martin Rex wrote: >=20 > > Miller, Timothy J. wrote: > > > >> There is a corner case where the CA history is trusted, the=20 > >> Responder signing key is trusted, but the CA signing key is not. > >> In this case, NOTISSUED can signal a compromise. > >> This is the corner case I think Philip is after. > >=20 > > I do not think that this is a "corner case"; I believe it will be=20 > > the most probable case that the CA key compromise is a temporary=20 > > loss of control over certificate issuance, and may be accompanied by=20 > > the loss of records what got signed (e.g. physical damage inflicted=20 > > by the attacker). >=20 > I think you missed the point. The corner is the loss of CA key=20 > control while *keeping* CA history integrity. In both recent cases we=20 > have before us, loss of CA key control was temporary, but the CA=20 > history couldn't be trusted. NOTISSUED critically depends on *both*. Just the opposite. In the DigiNotar case, the history integrity was retain= ed (that is the purpose of any desaster recovery plan). And the means that they used for their own OCSP server to recognize misissu= ed certs was to check OCSP requests against their database of past issued c= erts and declare all other certs not in that database as REVOKED. But unless the OCSP requests include a certificate hash, that check is not = reliable, because depending on how much control the attacker had over the c= reation of serial numbers, he could have tried to reuse serials of correctl= y issued certs for the misissued certs. That's why OCSP requests should be updated to include a certificate hash be= sides the issuer and serial. >=20 > The point of NOTISSUED is to *aid* in detecting compromise so recovery=20 > can be attempted. Once you're *in* recovery, NOTISSUED is irrelevant=20 > because you can just as easily respond REVOKED for those certs--as we=20 > see from recent cases. Just the opposite. NOTISSUED is only relevant in case of suspicion and rec= overy. Only those that continue claiming that potential compromise of a CA= is a non-event which they do not have to account for do not care about "NO= TISSUED" status. -Martin _______________________________________________ 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 Fri Mar 23 10:13:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B86B21F85D9 for ; Fri, 23 Mar 2012 10:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPm4s4qoRYPB for ; Fri, 23 Mar 2012 10:13:30 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id C765521F857F for ; Fri, 23 Mar 2012 10:13:29 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 549281D5F7EC for ; Fri, 23 Mar 2012 18:13:28 +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 VDzOU6ZJPCxx for ; Fri, 23 Mar 2012 18:13:28 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 14E461D617F2 for ; Fri, 23 Mar 2012 18:13:28 +0100 (CET) Received: (qmail 14507 invoked from network); 23 Mar 2012 17:13:27 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.219]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 17:13:27 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 18:13:14 +0100 From: Stefan Santesson To: pkix Message-ID: Thread-Topic: Need for an organizationalIdentifier attribute Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415371207_36724048" Subject: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:13:30 -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_3415371207_36724048 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute. But where do you store an identifier of the organization? That is, not the name stored in organization name, but the registered organization number? I've seen some odd solutions to this problem but nor clean solution. X.520 only offer organizationName and orgnizationalUnitName as organizational attributes Have anyone else come across this issue? How did you solve it? Do we need to define a clean attribute for an organizationalIdentifier? /Stefan --B_3415371207_36724048 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
When a person is associated = with an organization in a certificate the subjects employee number or alike = is often stored in the serialNumber attribute.

But = where do you store an identifier of the organization? 
That i= s, not the name stored in organization name, but the registered organization= number?

I've seen some odd solutions to this probl= em but nor clean solution.
X.520 only offer organizationName and o= rgnizationalUnitName as organizational attributes

H= ave anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier= ?

/Stefan

--B_3415371207_36724048-- From eabalea@gmail.com Fri Mar 23 10:23:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6A21F85A1 for ; Fri, 23 Mar 2012 10:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mok8ESa8VFHN for ; Fri, 23 Mar 2012 10:23:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72921F85A0 for ; Fri, 23 Mar 2012 10:23:08 -0700 (PDT) Received: by yenm5 with SMTP id m5so3271169yen.31 for ; Fri, 23 Mar 2012 10:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2MZ8lGAJoaih6uJZBsOV9HdMyv6Jbw3HdjiyB01YsE=; b=j0ik/OVvH0PqiU7lptyO3CBvMs7Mgvc6ZJsr6alnx+NGXPvRL6wWYYkFiUa/CV0U2A fxTMOnh2mNDOSc/gicGRb6pTe9K+o5gW3BgXcBMSYyxfTjLReST47IdJ3sDNmbcAXu6n +kNwkpzLTPJUppgpTfZs+KrZYTVasixpfgvpu2zIKSZr2tpeAwzhl/YOFFFQp5nGD2Ox Fu7BogDXdIrvMBwIvaWvlP0B4FGuz4eTUED8FBokBpnUN30/aNt6tCjesdWvT1a+XtLl RNjIZWfbRN4qgtZv6PRNNaHDsADtPwRwYD88n10i9MFX6M90xHPTTe/slj4dJkJChsy3 tDJA== MIME-Version: 1.0 Received: by 10.101.176.8 with SMTP id d8mr4074063anp.56.1332523388661; Fri, 23 Mar 2012 10:23:08 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Fri, 23 Mar 2012 10:23:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 18:23:08 +0100 Message-ID: From: Erwann Abalea To: Stefan Santesson Content-Type: multipart/alternative; boundary=001636c5bbb33c705d04bbec4776 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:23:09 -0000 --001636c5bbb33c705d04bbec4776 Content-Type: text/plain; charset=UTF-8 In France, and maybe in Europe, such an identifier is stored in an organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars || space || organization identifier on 35 chars max). ICD is equal to '0002' in France, and the identifier is our SIREN or SIRET. 2012/3/23 Stefan Santesson > When a person is associated with an organization in a certificate the > subjects employee number or alike is often stored in the serialNumber > attribute. > > But where do you store an identifier of the organization? > That is, not the name stored in organization name, but the registered > organization number? > > I've seen some odd solutions to this problem but nor clean solution. > X.520 only offer organizationName and orgnizationalUnitName as > organizational attributes > > Have anyone else come across this issue? > How did you solve it? > Do we need to define a clean attribute for an organizationalIdentifier? > > -- Erwann. --001636c5bbb33c705d04bbec4776 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In France, and maybe in Europe, such an identifier is stored in an organiza= tionalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars || space || = organization identifier on 35 chars max). ICD is equal to '0002' in= France, and the identifier is our SIREN or SIRET.

2012/3/23 Stefan Santesson <stefan@aaa-sec.com>
When a person is associated with an organization in a certifica= te the subjects employee number or alike is often stored in the serialNumbe= r attribute.

But where do you store an identifier of the organizatio= n?=C2=A0
That is, not the name stored in organization name, but t= he registered organization number?

I've seen s= ome odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as organiz= ational attributes

Have anyone else come across th= is issue?
How did you solve it?
Do we need to define a = clean attribute for an organizationalIdentifier?



--
Erwann.
--001636c5bbb33c705d04bbec4776-- From stefan@aaa-sec.com Fri Mar 23 10:32:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B5B21F8617 for ; Fri, 23 Mar 2012 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwhNbFxczRml for ; Fri, 23 Mar 2012 10:32:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id A2C6921F85FF for ; Fri, 23 Mar 2012 10:32:38 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D376B1DC6DD6 for ; Fri, 23 Mar 2012 18:32: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 ELRWT5u0lIG1 for ; Fri, 23 Mar 2012 18:32:37 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6DFBF1D64A16 for ; Fri, 23 Mar 2012 18:32:37 +0100 (CET) Received: (qmail 35493 invoked from network); 23 Mar 2012 17:32:37 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.219]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 17:32:37 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 18:32:08 +0100 From: Stefan Santesson To: Erwann Abalea Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415372357_36789743" Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:32: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_3415372357_36789743 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks, Yes, I have also seen such, or similar solutions. Other solutions I have seen (or heard about) is to bundle name and identifier in the organization name or to bundle the employee number and the organizational number in the serialNumber attribute. I oven saw a spec that suggested using multiple occurrences of serialNumber. One for the employee number and one for the orgNumber and to use heuristics to distinguish between them. These solutions have in common that they clearly stretch the intended semantics of these attributes and won't be understood other than under a very local context supported by customized code. /Stefan From: Erwann Abalea Date: Fri, 23 Mar 2012 18:23:08 +0100 To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute > In France, and maybe in Europe, such an identifier is stored in an > organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars || > space || organization identifier on 35 chars max). ICD is equal to '0002' in > France, and the identifier is our SIREN or SIRET. > > 2012/3/23 Stefan Santesson >> When a person is associated with an organization in a certificate the >> subjects employee number or alike is often stored in the serialNumber >> attribute. >> >> But where do you store an identifier of the organization? >> That is, not the name stored in organization name, but the registered >> organization number? >> >> I've seen some odd solutions to this problem but nor clean solution. >> X.520 only offer organizationName and orgnizationalUnitName as organizational >> attributes >> >> Have anyone else come across this issue? >> How did you solve it? >> Do we need to define a clean attribute for an organizationalIdentifier? >> > > > -- > Erwann. > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3415372357_36789743 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Thanks,

=
Yes, I have also seen such, or similar solutions.

<= div>Other solutions I have seen (or heard about) is to bundle name and ident= ifier in the organization name or to bundle the employee number and the orga= nizational number in the serialNumber attribute.
I oven saw a spec= that suggested using multiple occurrences of serialNumber. One for the empl= oyee number and one for the orgNumber and to use heuristics to distinguish b= etween them.

These solutions have in common that th= ey clearly stretch the intended semantics of these  attributes and won'= t be understood other than under a very local context supported by customize= d code.

/Stefan


=
From: Erwann Abalea <eabalea@gmail.com>
Date: Fri, 23 Mar 2012 18:23:08 +0100
To: Stefan Santesson <= stefan@aaa-sec.com>
Cc: pki= x <pkix@ietf.org>
Subject: Re: [pkix] Need for an organizationalIdent= ifier attribute

In France, and maybe in Europe, such an identifier is stored in a= n organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars || = space || organization identifier on 35 chars max). ICD is equal to '0002' in= France, and the identifier is our SIREN or SIRET.

2012/3/23 Stefan Santesson <stefan@aaa-sec.com>
When a person is associated with an organization in a certificate = the subjects employee number or alike is often stored in the serialNumber at= tribute.

But where do you store an identifier of th= e organization? 
That is, not the name stored in organization= name, but the registered organization number?

I've= seen some odd solutions to this problem but nor clean solution.
X= .520 only offer organizationName and orgnizationalUnitName as organizational= attributes

Have anyone else come across this issue= ?
How did you solve it?
Do we need to define a clean att= ribute for an organizationalIdentifier?


--
Erwann.
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3415372357_36789743-- From anders.rundgren@telia.com Fri Mar 23 10:35:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8908D21F861C for ; Fri, 23 Mar 2012 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVab6E7iRh1y for ; Fri, 23 Mar 2012 10:35:26 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE421F860E for ; Fri, 23 Mar 2012 10:35:26 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00504CD2; Fri, 23 Mar 2012 18:35:24 +0100 Message-ID: <4F6CB457.2010400@telia.com> Date: Fri, 23 Mar 2012 18:35:19 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:35:30 -0000 http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. br ar On 2012-03-23 18:13, Stefan Santesson wrote: > When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute. > > But where do you store an identifier of the organization? > That is, not the name stored in organization name, but the registered organization number? > > I've seen some odd solutions to this problem but nor clean solution. > X.520 only offer organizationName and orgnizationalUnitName as organizational attributes > > Have anyone else come across this issue? > How did you solve it? > Do we need to define a clean attribute for an organizationalIdentifier? > > /Stefan > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Fri Mar 23 10:38:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C514F21F860F for ; Fri, 23 Mar 2012 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4QLFr1D5cI9 for ; Fri, 23 Mar 2012 10:38:38 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5C121F8499 for ; Fri, 23 Mar 2012 10:38:38 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2NHcb6Y011642 for ; Fri, 23 Mar 2012 13:38:37 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 13:38:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Mar 2012 13:38:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0JGEwfmjfSNRjeRjSHRyBZR3CnYgAAUMQw References: From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 23 Mar 2012 17:38:37.0686 (UTC) FILETIME=[C758B960:01CD091B] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:38:42 -0000 The DoD guide for uniquely identifying items (http://www.acq.osd.mil/dpap/UID/attachments/DoDUIDGuide.pdf) specifies a string format for Item Unique Identifiers consisting of an enterprise identifier and an item serial number. The catalog of recognized enterprise (organization) numbers includes those from the following Issuing Agencies: * GS1 (formerly UCC/EAN) company prefix * Telcordia * Dun & Bradstreet DUNS numbers * NATO Contractor and Government Entity (NCAGE) codes * European Health Industry Business Communications Council (EHIBCC) * DoD Activity Address Code (DoDAAC) As far as I know, an attribute OID has not been defined for organizationalIdentifier based on these Issuing Agency Codes, but if one were to be defined, the IUID document has some good background information on how to construct it. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, March 23, 2012 1:13 PM To: pkix Subject: [pkix] Need for an organizationalIdentifier attribute When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute. But where do you store an identifier of the organization?=20 That is, not the name stored in organization name, but the registered organization number? I've seen some odd solutions to this problem but nor clean solution. X.520 only offer organizationName and orgnizationalUnitName as organizational attributes Have anyone else come across this issue? How did you solve it? Do we need to define a clean attribute for an organizationalIdentifier? /Stefan From peter.sylvester@edelweb.fr Fri Mar 23 10:40:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0879B21F84AA for ; Fri, 23 Mar 2012 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f+B9EgaNsHg for ; Fri, 23 Mar 2012 10:40:31 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4098721F84E4 for ; Fri, 23 Mar 2012 10:40:31 -0700 (PDT) Received: from varuna.puteaux.on-x (unknown [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id A2B6D7EB1 for ; Fri, 23 Mar 2012 18:40:30 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 8F3A77ACAB6 for ; Fri, 23 Mar 2012 18:03:11 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 709BF236368 for ; Fri, 23 Mar 2012 13:37:37 -0400 (EDT) Message-ID: <4F6CB5BA.1090509@edelweb.fr> Date: Fri, 23 Mar 2012 18:41:14 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080500080108060907020203" Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:40:36 -0000 This is a multi-part message in MIME format. --------------080500080108060907020203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit what about: http://www.cabforum.org/contents.html > > 2012/3/23 Stefan Santesson > > > When a person is associated with an organization in a certificate > the subjects employee number or alike is often stored in the > serialNumber attribute. > > But where do you store an identifier of the organization? > That is, not the name stored in organization name, but the > registered organization number? > > I've seen some odd solutions to this problem but nor clean solution. > X.520 only offer organizationName and orgnizationalUnitName as > organizational attributes > > Have anyone else come across this issue? > How did you solve it? > Do we need to define a clean attribute for an > organizationalIdentifier? > --------------080500080108060907020203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
what about:

    http://www.cabforum.org/contents.html

2012/3/23 Stefan Santesson <stefan@aaa-sec.com>
When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.

But where do you store an identifier of the organization? 
That is, not the name stored in organization name, but the registered organization number?

I've seen some odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as organizational attributes

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier?


--------------080500080108060907020203-- From piyush@identicate.com Fri Mar 23 10:45:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278A621F8609 for ; Fri, 23 Mar 2012 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41JbWten+EKJ for ; Fri, 23 Mar 2012 10:45:27 -0700 (PDT) Received: from col0-omc3-s5.col0.hotmail.com (col0-omc3-s5.col0.hotmail.com [65.55.34.143]) by ietfa.amsl.com (Postfix) with ESMTP id 47D0821F857A for ; Fri, 23 Mar 2012 10:45:27 -0700 (PDT) Received: from COL119-W57 ([65.55.34.137]) by col0-omc3-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 10:45:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1502fd9e-ce23-4da3-8cd3-a39a795ffa2e_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Fri, 23 Mar 2012 10:45:26 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2012 17:45:27.0389 (UTC) FILETIME=[BB8C70D0:01CD091C] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:45:31 -0000 --_1502fd9e-ce23-4da3-8cd3-a39a795ffa2e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i don't think that there is a consistent way of storing either org id or ev= en employee id. US Government agencies use an extension called FASC-N (Federal Agency Smart= Credential number) to store a bundle of information including=2C employee = number=2C agency code=2C agency category=2C country code=2C state code etc. -Piyush Date: Fri=2C 23 Mar 2012 18:13:14 +0100 From: stefan@aaa-sec.com To: pkix@ietf.org Subject: [pkix] Need for an organizationalIdentifier attribute When a person is associated with an organization in a certificate the subje= cts employee number or alike is often stored in the serialNumber attribute. But where do you store an identifier of the organization? That is=2C not th= e name stored in organization name=2C but the registered organization numbe= r? I've seen some odd solutions to this problem but nor clean solution.X.520 o= nly offer organizationName and orgnizationalUnitName as organizational attr= ibutes Have anyone else come across this issue?How did you solve it?Do we need to = define a clean attribute for an organizationalIdentifier? /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix = --_1502fd9e-ce23-4da3-8cd3-a39a795ffa2e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
i don't think that there is a consistent way of storing either org id or ev= en employee id.

US Government agencies use an extension = called FASC-N (Federal Agency Smart Credential number) to store a bundle of= information including=2C employee number=2C agency code=2C agency category= =2C country code=2C state code etc.

-Piyush
Date: F= ri=2C 23 Mar 2012 18:13:14 +0100
From: stefan@aaa-sec.com
To: pkix@ie= tf.org
Subject: [pkix] Need for an organizationalIdentifier attribute
When a person = is associated with an organization in a certificate the subjects employee n= umber or alike is often stored in the serialNumber attribute.
But where do you store an identifier of the organization? = =3B
That is=2C not the name stored in organization name=2C but th= e registered organization number?

I've seen some o= dd solutions to this problem but nor clean solution.
X.520 only o= ffer organizationName and orgnizationalUnitName as organizational attribute= s

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute f= or an organizationalIdentifier?

/Stefan
=

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
= --_1502fd9e-ce23-4da3-8cd3-a39a795ffa2e_-- From peter.sylvester@edelweb.fr Fri Mar 23 10:50:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56621F8622 for ; Fri, 23 Mar 2012 10:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD08MaFf931P for ; Fri, 23 Mar 2012 10:49:57 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id C57EE21F861B for ; Fri, 23 Mar 2012 10:49:56 -0700 (PDT) Received: from varuna.puteaux.on-x (unknown [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 3D4837DA9 for ; Fri, 23 Mar 2012 18:49:56 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 0D9737ACAA3 for ; Fri, 23 Mar 2012 18:12:34 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id D5544236368 for ; Fri, 23 Mar 2012 13:46:59 -0400 (EDT) Message-ID: <4F6CB7ED.6090408@edelweb.fr> Date: Fri, 23 Mar 2012 18:50:37 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.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: 8bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:50:02 -0000 On 03/23/2012 06:23 PM, Erwann Abalea wrote: > In France, and maybe in Europe, such an identifier is stored in an > organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars > || space || organization identifier on 35 chars max). ICD is equal to > '0002' in France, and the identifier is our SIREN or SIRET. "In France" is not completely correct. It applies to rules when you want to talk with the administration, French CAs that want to be conformant with the "référentiel Général de Sécurité" in order to deliver such certs obey to this rule. It just happens that the second entry of the SIRET/SIRET number, somewhat similar with the OID tree 1.3.2.sire/siret. A foreign company can have a french siren/siret under some conditions. ICDs represents very different naming schemes only a very small set are somthning that represents ids of companies. So, this is one of the ugly hacks. what about http://www.cabforum.org/contents.html The way how this is used by CAs thow does not permit at all to use permitted subtree restrictions or something like that attributes are filled in in almost any order in cert, but that's another story. From stefan@aaa-sec.com Fri Mar 23 10:51:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E54121F863E for ; Fri, 23 Mar 2012 10:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhqwQP5CD746 for ; Fri, 23 Mar 2012 10:51:20 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id DC61421F8622 for ; Fri, 23 Mar 2012 10:51:19 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 71E3A1DC6E03 for ; Fri, 23 Mar 2012 18:51:18 +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 LGJ9hjMd_O8g for ; Fri, 23 Mar 2012 18:51:18 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1C20F1D57C82 for ; Fri, 23 Mar 2012 18:51:18 +0100 (CET) Received: (qmail 56970 invoked from network); 23 Mar 2012 17:51:15 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.219]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 17:51:15 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 18:50:47 +0100 From: Stefan Santesson To: Peter Sylvester , Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F6CB5BA.1090509@edelweb.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415373475_36817763" Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:51: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_3415373475_36817763 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I don't think this helps. These are certificates where the organization (or organizational resource) is the subject. I'm looking for a solution where the subject is a person associated with an organization. /Stefan From: Peter Sylvester Date: Fri, 23 Mar 2012 18:41:14 +0100 To: Subject: Re: [pkix] Need for an organizationalIdentifier attribute > > > what about: > > http://www.cabforum.org/contents.html > >> >> >> 2012/3/23 Stefan Santesson >> >>> >>> >>> When a person is associated with an organization in a certificate the >>> subjects employee number or alike is often stored in the serialNumber >>> attribute. >>> >>> >>> >>> >>> But where do you store an identifier of the organization? >>> >>> That is, not the name stored in organization name, but the registered >>> organization number? >>> >>> >>> >>> >>> I've seen some odd solutions to this problem but nor clean solution. >>> >>> X.520 only offer organizationName and orgnizationalUnitName as >>> organizational attributes >>> >>> >>> >>> >>> Have anyone else come across this issue? >>> >>> How did you solve it? >>> >>> Do we need to define a clean attribute for an organizationalIdentifier? >>> >>> >>> >> >> > > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3415373475_36817763 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I don't think this helps.

These are certificates where the organization (or org= anizational resource) is the subject.
I'm looking for a solution w= here the subject is a person associated with an organization.

=
/Stefan

From: Peter Sylvester <peter.s= ylvester@edelweb.fr>
Date: = Fri, 23 Mar 2012 18:41:14 +0100
To: <pkix@ietf.org>
Subject: Re: [pkix] Need for an organizationalIdent= ifier attribute


what about:

    http://www.cabforum.org/contents.html

2012/3/23 Stefan Santesson &= lt;stefan@aaa-sec= .com>
When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.

But where do you store an identifier of the organization? 
That is, not the name stored in organization name, but the registered organization number?

I've seen some odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as organizational attributes

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier?


_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3415373475_36817763-- From stefan@aaa-sec.com Fri Mar 23 10:52:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF03821F8622 for ; Fri, 23 Mar 2012 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KRhKCOt2hM4 for ; Fri, 23 Mar 2012 10:52:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id DE5B021F863C for ; Fri, 23 Mar 2012 10:52:18 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 4540B1DC7554 for ; Fri, 23 Mar 2012 18:52:18 +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 dzjaqXsH9wmd for ; Fri, 23 Mar 2012 18:52:18 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 038F71DC7066 for ; Fri, 23 Mar 2012 18:52:18 +0100 (CET) Received: (qmail 67892 invoked from network); 23 Mar 2012 17:52:17 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.219]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 17:52:17 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 18:52:13 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F6CB457.2010400@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:52:23 -0000 No, The permanent identifier is an identifier of the subject and is not an attribute. I need an identifier of the subjects organization where the subject is a person. /Stefan On 12-03-23 6:35 PM, "Anders Rundgren" wrote: >http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >br >ar > >On 2012-03-23 18:13, Stefan Santesson wrote: >> When a person is associated with an organization in a certificate the >>subjects employee number or alike is often stored in the serialNumber >>attribute. >> >> But where do you store an identifier of the organization? >> That is, not the name stored in organization name, but the registered >>organization number? >> >> I've seen some odd solutions to this problem but nor clean solution. >> X.520 only offer organizationName and orgnizationalUnitName as >>organizational attributes >> >> Have anyone else come across this issue? >> How did you solve it? >> Do we need to define a clean attribute for an organizationalIdentifier? >> >> /Stefan >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tim.moses@entrust.com Fri Mar 23 10:53:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8321F8622 for ; Fri, 23 Mar 2012 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TIME=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb1tr-GgFLW3 for ; Fri, 23 Mar 2012 10:53:10 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 38CEA21F8649 for ; Fri, 23 Mar 2012 10:53:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,637,1325480400"; d="scan'208,217";a="620585" Received: from unknown (HELO sottexch8.corp.ad.entrust.com) ([10.4.51.89]) by ipedge2.entrust.com with ESMTP; 23 Mar 2012 13:53:05 -0400 Received: from sottexch7.corp.ad.entrust.com ([::1]) by sottexch8.corp.ad.entrust.com ([fe80::3d93:b474:b43c:76fe%10]) with mapi; Fri, 23 Mar 2012 13:53:05 -0400 From: Tim Moses To: 'Peter Sylvester' , "pkix@ietf.org" Date: Fri, 23 Mar 2012 13:53:05 -0400 Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0JHHdQdREMh6GwQCu5F6S/1vW2ewAASL+w Message-ID: References: <4F6CB5BA.1090509@edelweb.fr> In-Reply-To: <4F6CB5BA.1090509@edelweb.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3144629B5AC714A8BF27806EBFA705701341802A8sottexch7corp_" MIME-Version: 1.0 Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:53:15 -0000 --_000_A3144629B5AC714A8BF27806EBFA705701341802A8sottexch7corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is how the EV Guidelines (Draft v1.4) deals with it. All the best. T= im. (3) Business Category Certificate field: subject:businessCategory (OID: 2.5.4.15) Required/Optional: Required Contents: This field MUST contain one of the following strings: "Private Or= ganization", "Government Entity", "Business Entity", or "Non-Commercial Ent= ity" depending upon whether the Subject qualifies under the terms of Sectio= n 7.2.2, 7.2.3, 7.2.4 or 7.2.5 of these Guidelines, respectively. (4) Jurisdiction of Incorporation or Registration Certificate fields: Locality (if required): subject:jurisdictionOfIncorporationLocalityName (OID: 1.3.6.1.4.1.311.60.2= .1.1) ASN.1 - X520LocalityName as specified in RFC 5280 State or province (if required): subject:jurisdictionOfIncorporationStateOrProvinceName (OID: 1.3.6.1.4.1.3= 11.60.2.1.2) ASN.1 - X520StateOrProvinceName as specified in RFC 5280 Country: subject:jurisdictionOfIncorporationCountryName (OID: 1.3.6.1.4.1.311= .60.2.1.3) ASN.1 - X520countryName as specified in RFC 5280 Required/Optional: Required Contents: These fields MUST NOT contain information that is not relevant = to the level of the Incorporating Agency or Registration Agency. For examp= le, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisd= iction of Registration for a Registration Agency that operates at the count= ry level MUST include the country information but MUST NOT include the stat= e or province or locality information. Similarly, the jurisdiction for the= applicable Incorporating Agency or Registration Agency at the state or pro= vince level MUST include both country and state or province information, bu= t MUST NOT include locality information. And, the jurisdiction for the app= licable Incorporating Agency or Registration Agency at the locality level M= UST include the country and state or province information, where the state = or province regulates the registration of the entities at the locality leve= l, as well as the locality information. Country information MUST be specif= ied using the applicable ISO country code. State or province or locality i= nformation (where applicable) for the Subject's Jurisdiction of Incorporati= on or Registration MUST be specified using the full name of the applicable = jurisdiction. (5) Registration Number Certificate field: Subject:serialNumber (OID: 2.5.4.5) Required/Optional: Required Contents: For Private Organizations, this field MUST contain the Registra= tion (or similar) Number assigned to the Subject by the Incorporating or Re= gistration Agency in its Jurisdiction of Incorporation or Registration, as = appropriate. If the Jurisdiction of Incorporation or Registration does not= provide a Registration Number, then the date of Incorporation or Registrat= ion SHALL be entered into this field in any one of the common date formats. For Government Entities that do not have a Registration Number or readily v= erifiable date of creation, the CA SHALL enter appropriate language to indi= cate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Bus= iness Entity upon government registration SHALL be entered in this field. = For those Business Entities that register with an Incorporating Agency or R= egistration Agency in a jurisdiction that does not issue numbers pursuant t= o government registration, the date of the registration SHALL be entered in= to this field in any one of the common date formats. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pet= er Sylvester Sent: Friday, March 23, 2012 1:41 PM To: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute what about: http://www.cabforum.org/contents.html 2012/3/23 Stefan Santesson > When a person is associated with an organization in a certificate the subje= cts employee number or alike is often stored in the serialNumber attribute. But where do you store an identifier of the organization? That is, not the name stored in organization name, but the registered organ= ization number? I've seen some odd solutions to this problem but nor clean solution. X.520 only offer organizationName and orgnizationalUnitName as organization= al attributes Have anyone else come across this issue? How did you solve it? Do we need to define a clean attribute for an organizationalIdentifier? --_000_A3144629B5AC714A8BF27806EBFA705701341802A8sottexch7corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is how the EV Guidelines (Draft v1.4)= deals with it.  All the best.  Tim.

(3)  Business Category=

Certifica= te field:   subject:businessCategory (OID:  2.5.4= .15)

Requ= ired/Optional:   Required

Contents: This field MUST contain one of= the following strings: "Private Organization", "Government = Entity", "Business Entity", or "Non-Commercial Entity&q= uot; depending upon whether the Subject qualifies under the terms of Sectio= n 7.2.2, 7.2.3, 7.2.4 or 7.2.5 of these Guidelines, respectively.

 <= /b>

(4) Jurisd= iction of Incorporation or Registration

Certificate fields:

Locality (if required): =

subject:jurisdictionOfIncorporationLocalityName (OID: = 1.3.6.1.4.1.311.60.2.1.1)

ASN.1 - X520LocalityName as specified in = RFC 5280

Stat= e or province (if required):        = ;   

subject:jurisdictionOfIncorporationStateOrP= rovinceName (OID:  1.3.6.1.4.1.311.60.2.1.2)

ASN.1 - X520St= ateOrProvinceName as specified in RFC 5280

Country:  

  &nb= sp;   subject:jurisdictionOfIncorporationCountryName (OID:=   1.3.6.1.4.1.311.60.2.1.3)

ASN.1 – X520countryName<= /i> as specified in RFC 5280

Required/Optional:   Required

Contents: &nb= sp; These fields MUST NOT contain information that is no= t relevant to the level of the Incorporating Agency or Registration Agency.=   For example, the Jurisdiction of Incorporation for an Incorporating = Agency or Jurisdiction of Registration for a Registration Agency that opera= tes at the country level MUST include the country information but MU= ST NOT include the state or province or locality information.  Similar= ly, the jurisdiction for the applicable Incorporating Agency or Registratio= n Agency at the state or province level MUST include both country an= d state or province information, but MUST NOT include locality information.=   And, the jurisdiction for the applicable Incorporating Agency or Reg= istration Agency at the locality level MUST include the country and = state or province information, where the state or province regulates the re= gistration of the entities at the locality level, as well as the locality i= nformation.  Country information MUST be specified using the applicabl= e ISO country code.  State or province or locality information (where = applicable) for the Subject’s Jurisdiction of Incorporation or Regist= ration MUST be specified using the full name of the applicable jurisdiction= . 

 

(5) Registration Number

Certificate field:   Subject:serialN= umber (OID:  2.5.4.5)

Required/Optional:   Required

=

Contents:  = ; For Private Organizations, this field MUST contain the Registration (or s= imilar) Number assigned to the Subject by the Incorporating or Registration= Agency in its Jurisdiction of Incorporation or Registration, as appropriat= e.  If the Jurisdiction of Incorporation or Registration does not prov= ide a Registration Number, then the date of Incorporation or Registration S= HALL be entered into this field in any one of the common date formats. = ;

For Govern= ment Entities that do not have a Registration Number or readily verifiable = date of creation, the CA SHALL enter appropriate language to indicate that = the Subject is a Government Entity.

For Business Entities, the Registration Number that = was received by the Business Entity upon government registration SHALL be e= ntered in this field.  For those Business Entities that register with = an Incorporating Agency or Registration Agency in a jurisdiction that does = not issue numbers pursuant to government registration, the date of the regi= stration SHALL be entered into this field in any one of the common date for= mats.

 

 

From: pkix-bounces@ietf.or= g [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Sylvester
= Sent: Friday, March 23, 2012 1:41 PM
To: pkix@ietf.org
= Subject: Re: [pkix] Need for an organizationalIdentifier attribute=

 


what about:

    http://www.cabforum.org/contents.html=

 

2012/3/23 Stefan Santesson <stefan@aaa-sec.com>

= When a person is associated with an organization in a certificate the subje= cts employee number or alike is often stored in the serialNumber attribute.=

 

=

But where do you store an identifier of the organi= zation? 

That is, not th= e name stored in organization name, but the registered organization number?=

 

=

I've seen some odd solutions to this problem but n= or clean solution.

X.520 only= offer organizationName and orgnizationalUnitName as organizational attribu= tes

 <= /p>

Have anyone else come across this issue?

How did you solve it?

Do we need to define a clean attribute for= an organizationalIdentifier?

 

 <= /p>

= --_000_A3144629B5AC714A8BF27806EBFA705701341802A8sottexch7corp_-- From peter.sylvester@edelweb.fr Fri Mar 23 10:57:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB321F8650 for ; Fri, 23 Mar 2012 10:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPVsPIcCmflI for ; Fri, 23 Mar 2012 10:57:28 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id E269121F863D for ; Fri, 23 Mar 2012 10:57:27 -0700 (PDT) Received: from varuna.puteaux.on-x (unknown [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 47E8B7ED4 for ; Fri, 23 Mar 2012 18:57:27 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id E8AB57AC722 for ; Fri, 23 Mar 2012 18:20:04 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 061B6236368 for ; Fri, 23 Mar 2012 13:54:31 -0400 (EDT) Message-ID: <4F6CB9B0.4020302@edelweb.fr> Date: Fri, 23 Mar 2012 18:58:08 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.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 Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 17:57:28 -0000 There is also rfc4043. From tim.moses@entrust.com Fri Mar 23 11:04:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63221F865B for ; Fri, 23 Mar 2012 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqFSUnC+vjow for ; Fri, 23 Mar 2012 11:04:30 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 87EBF21F8650 for ; Fri, 23 Mar 2012 11:04:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,637,1325480400"; d="scan'208,217";a="4484250" Received: from unknown (HELO sottexch8.corp.ad.entrust.com) ([10.4.51.89]) by ipedge1.entrust.com with ESMTP; 23 Mar 2012 14:04:30 -0400 Received: from sottexch7.corp.ad.entrust.com ([::1]) by sottexch8.corp.ad.entrust.com ([fe80::3d93:b474:b43c:76fe%10]) with mapi; Fri, 23 Mar 2012 14:04:29 -0400 From: Tim Moses To: 'Stefan Santesson' Date: Fri, 23 Mar 2012 14:04:29 -0400 Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0JHaN1C1iG7/wxQiKR8S+JZO0iWAAAbBNQ Message-ID: References: <4F6CB5BA.1090509@edelweb.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3144629B5AC714A8BF27806EBFA705701341802AAsottexch7corp_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 18:04:35 -0000 --_000_A3144629B5AC714A8BF27806EBFA705701341802AAsottexch7corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's right. EV certificates are organizational certificates. All the be= st. Tim. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Friday, March 23, 2012 1:51 PM To: Peter Sylvester; pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute I don't think this helps. These are certificates where the organization (or organizational resource) = is the subject. I'm looking for a solution where the subject is a person associated with an= organization. /Stefan From: Peter Sylvester > Date: Fri, 23 Mar 2012 18:41:14 +0100 To: > Subject: Re: [pkix] Need for an organizationalIdentifier attribute what about: http://www.cabforum.org/contents.html 2012/3/23 Stefan Santesson > When a person is associated with an organization in a certificate the subje= cts employee number or alike is often stored in the serialNumber attribute. But where do you store an identifier of the organization? That is, not the name stored in organization name, but the registered organ= ization number? I've seen some odd solutions to this problem but nor clean solution. X.520 only offer organizationName and orgnizationalUnitName as organization= al attributes Have anyone else come across this issue? How did you solve it? Do we need to define a clean attribute for an organizationalIdentifier? _______________________________________________ pkix mailing list pkix@ietf= .org https://www.ietf.org/mailman/listinfo/pkix --_000_A3144629B5AC714A8BF27806EBFA705701341802AAsottexch7corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --bcaec50163fbe1009d04bc4923f6-- From dharkins@lounge.org Wed Mar 28 02:04:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49C221F89C2 for ; Wed, 28 Mar 2012 02:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez2uXLkE1n+P for ; Wed, 28 Mar 2012 02:04:04 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3A21F890F for ; Wed, 28 Mar 2012 02:04:04 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 04C121022404A; Wed, 28 Mar 2012 02:04:04 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 28 Mar 2012 02:04:04 -0700 (PDT) Message-ID: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> Date: Wed, 28 Mar 2012 02:04:04 -0700 (PDT) From: "Dan Harkins" To: turners@ieca.com 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] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 09:04:04 -0000 Hi, On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said: > Just a couple of comments the WG should consider: > >Technical: > > 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s for > the request and return the certificate(s) in a mime media type. In many > instances, the "normal" query/response for a certificate is a PKCS#10 > request followed by a PKCS#7 response, where the PKCS#7 is the degenerate > certs-only message. Does anyone see any benefit in reusing the > PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it would > align nicely/exactly with the simple PKI request/response from CMC. Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed to implement "simple CMC" and that should use a PKCS#7 as the simple response. regards, Dan. From tomas@primekey.se Wed Mar 28 02:17:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0421E804A for ; Wed, 28 Mar 2012 02:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOvZIEgSoxeV for ; Wed, 28 Mar 2012 02:17:52 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 66A5B21F89BB for ; Wed, 28 Mar 2012 02:17:52 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id BC31DE10A3 for ; Wed, 28 Mar 2012 11:17:59 +0200 (CEST) Received: from [192.168.0.3] (c-0322e055.18-1-64736c13.cust.bredbandsbolaget.se [85.224.34.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 92A64E0C5C for ; Wed, 28 Mar 2012 11:17:59 +0200 (CEST) Message-ID: <4F72D73E.1010705@primekey.se> Date: Wed, 28 Mar 2012 11:17:50 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> In-Reply-To: <4F719B3D.10101@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 09:17:53 -0000 You comment made me realize something Anders. * Support for multiple CAs Imho new protocols should support the function where the EST/CA server contains multiple CAs. Think of one EST front end with multiple CA backends. Most CA software today runs multiple CAs in a single instance, and with cloud computing this only grows. Multiple CAs can be handled with virtual hosts, but it's simpler if there is protocol suppport. Section 5.3 and 5.3.1 does not make it clear how this should work. In fact section 5.3 is very cryptic. The URL ending is /CACerts but section 5.3.1 says "CA trust anchor information in the form of a certificate.". Can /CACerts only return a single certificate? Kind of against the name, or can "trust anchor information" mean multiple independent certificate chains? For enrollment, ways of identifying the target CA is also desired. For CRMF this is usually embedded in the request, but for PKCS#10 it is not... Regards, Tomas On 03/27/2012 12:49 PM, Anders Rundgren wrote: > Continuing this thread... > > From the abstract I would be interested in hearing what > > "simple Public Key Infrastructure clients" > > actually refer to. > > "This profile, called Enrollment over Secure Transport (EST), > describes a simple yet functional certificate management protocol" > > If you combine all the options, it is not that simple anymore. > Is a client and server assumed to support all the options? > If not, how are they supposed to know which subset that can be used? > Looks like a rather configuration-dependent scheme IMHO. > > > "K1 "Algorithm agility". The protocol MUST support algorithm agility" > > The author's opinion on what that means is flawed. Although supporting > a bunch of TLS ciphers may be interesting, algorithm agility regarding > generated keys is a parameter that most (if not all) issuers care about. > > > "5.3 Distribution of CA certificates > Before engaging in enrollment operations, clients MUST request trust > anchor information (in the form of certificates) by sending an HTTPS > GET message to the EST base URI with the relative path extension > '/CACerts'" > > This mandatory requirement isn't particularly universal. A more > common method is that the user rather gets an option "accepting" the > root of the distributed certificate path. In today's server-centric > world the CA of a *client certificate* often doesn't have any > meaning for the client/user at all. > > Anders > PS. By thinking out loud I got an idea for KeyGen2! Add an option > to the install certificate part of the protocol where the issuer may > claim that this root may be of interest to user. By doing that KeyGen2 > doesn't have to bother users with (for example) accepting VISA's EMV-root > since this a thing for the merchants/acquirers to care about. DS. > > On 2012-03-27 11:25, Sean Turner wrote: >> Just a couple of comments the WG should consider: >> >> Technical: >> >> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >> for the request and return the certificate(s) in a mime media type. In >> many instances, the "normal" query/response for a certificate is a >> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the >> degenerate certs-only message. Does anyone see any benefit in reusing >> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it >> would align nicely/exactly with the simple PKI request/response from CMC. >> >> 2. in s5.6.2, just use application/pkcs8 instead of >> application/pkix-privkey. >> >> Not so technical: >> >> 1. appendix D really ought to be in its own document or in part of >> draft-nourse-scep. >> >> spt >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Wed Mar 28 03:43:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC721F8A1C for ; Wed, 28 Mar 2012 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJuP27HORCWZ for ; Wed, 28 Mar 2012 03:43:44 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3C24B21F8A23 for ; Wed, 28 Mar 2012 03:43:44 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 025911DDFFCD for ; Wed, 28 Mar 2012 12:41:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TqEVDh8RyH7W for ; Wed, 28 Mar 2012 12:41:33 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5C5041DDFA4A for ; Wed, 28 Mar 2012 12:41:33 +0200 (CEST) Received: (qmail 82442 invoked from network); 28 Mar 2012 10:41:33 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.207]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Mar 2012 10:41:33 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 28 Mar 2012 12:41:25 +0100 From: Stefan Santesson To: Santosh Chokhani , "denis.pinkas@bull.net" Message-ID: Thread-Topic: [pkix] 2560bis In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415783293_54011070" Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:43:45 -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_3415783293_54011070 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Based on the meeting yesterday and the discussions on the list I will make an overhaul of the current draft. Therefore I will allow the current draft to expire until the new draft is ready. /Stefan From: Santosh Chokhani Date: Tue, 27 Mar 2012 12:50:36 -0400 To: "denis.pinkas@bull.net" Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis > Denis, > =20 > Thanks. > =20 > I am willing to be little more liberal say that Appendix E scenarios are = valid > and acceptable as long as 2560 bis requires in the normative part of the = RFC > the client to verify that key/certificate relationships as stipulated in = the > Appendix or the proposal I made in 2004 regarding matching the certificat= e > certification path and revocation information certification path. > =20 > From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net] > Sent: Tuesday, March 27, 2012 10:04 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] 2560bis > =20 > Santosh,=20 >=20 > We are on the same track. This is one of the issues I presented this morn= ing > at the meeting.=20 > There are some other issues. >=20 > Please, take a look at the slides: > http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf > >=20 > Denis=20 >=20 >=20 >=20 >=20 > De : Santosh Chokhani > A : Scott Rea , "pkix@ietf.org" > Date : 27/03/2012 15:33 > Objet : Re: [pkix] 2560bis > Envoy=E9 par : pkix-bounces@ietf.org >=20 >=20 >=20 >=20 >=20 > There is a difference of opinion on this one. >=20 > In my reading 2560 is reasonably clear that the same CA Signing private k= ey > must be used to sign the Responder certificate as the certificate in ques= tion. > This offers the crypto binding and provides all three: high degree of > security, reduced software complexity for the OCSP client, and reduced > computational complexity for the OCSP client. Now, when do you get all t= hree? >=20 > I do not buy the text in draft bis 2560. That is taking liberty with the > intent of 2560 and reducing security and/or adding complexity. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org > ] On Behalf Of Scott Rea > Sent: Tuesday, March 27, 2012 3:32 AM > To: pkix@ietf.org > Subject: [pkix] 2560bis >=20 > If the issue with the responder cert is not clear in respect to CA rollov= er, > and it really is expected to follow existing path processing from 5280, I= am > not sure that the proposed text presented just now accomplishes that... > why would we just not say that the responder cert should be issued by the= same > trust anchor that the subject cert of the OCSP request chains to. Hence i= f the > EE cert now chains to a rolled over CA cert, then the responder cert shou= ld be > issued by that same rolled over CA cert - yes? > Regards, >=20 > -- > Scott Rea >=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_3415783293_54011070 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Based on the meeting yesterd= ay and the discussions on the list I will make an overhaul of the current dr= aft.
Therefore I will allow the current draft to expire until the = new draft is ready.

/Stefan


That̵= 7;s right.  EV certificates are organizational certificates.  All= the best.  Tim.

 

From: pkix-bounc= es@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Sante= sson
Sent: Friday, March 23, 2012 1:51 PM
To: Peter Syl= vester; pkix@ietf.org
Subject: Re: [pkix] Need for an organizatio= nalIdentifier attribute

 

I don't think this h= elps.

 =

These are certificate= s where the organization (or organizational resource) is the subject.<= /o:p>

I'm looking for a solu= tion where the subject is a person associated with an organization.

 =

/Stefan

 

=

From: Peter Sylvester <peter.sylvester@edelweb.fr>= ;
Date: Fri, 23 Mar 2012 18:41:14 +0100
To: <pkix@ietf.org>
Subject: Re: [pki= x] Need for an organizationalIdentifier attribute

 


what about:

&nbs= p;   http://www= .cabforum.org/contents.html

 

2012= /3/23 Stefan Santesson <stefan@aaa= -sec.com>

W= hen a person is associated with an organization in a certificate the subjec= ts employee number or alike is often stored in the serialNumber attribute.<= o:p>

 =

But where do you store an i= dentifier of the organization? 

That is, not the name stored in organization name, but = the registered organization number?

 

I've seen some odd solutions to this problem but nor clean solutio= n.

X.520 only off= er organizationName and orgnizationalUnitName as organizational attributes<= o:p>

 =

Have anyone else come acros= s this issue?

How= did you solve it?

Do we need to define a clean attribute for an organizationalIdentifier?

 

 

_________________________________________= ______ pkix mailing list pkix@ietf.org= https://www.ietf.or= g/mailman/listinfo/pkix

= --_000_A3144629B5AC714A8BF27806EBFA705701341802AAsottexch7corp_-- From md@e-net.lt Fri Mar 23 12:40:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088A021E804D for ; Fri, 23 Mar 2012 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsy3wbgqE39o for ; Fri, 23 Mar 2012 12:40:04 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id E48AA21E8024 for ; Fri, 23 Mar 2012 12:40:03 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SBALA-0003L9-Pi; Fri, 23 Mar 2012 21:40:00 +0200 Message-ID: <4F6CD18F.8030905@e-net.lt> Date: Fri, 23 Mar 2012 21:39:59 +0200 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080505060703030008040403" Cc: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 19:40:09 -0000 This is a multi-part message in MIME format. --------------080505060703030008040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The simple answer is: currently there is no clear solution to identify both the Subject and/or the associated Organization. New proposals from the ETSI TS 102 280 draft, IMO worth considering: Subject and issuer names may include attributes that don't disclose the semantics of its information content. This is very common e.g. for information stored in the serialNumber attribute, which may contain a national identification number, passport number or any type of locally defined identifier. The semantics identifier, defined in RFC 3739 [4] offers one way to identify the type of information that is stored in various subject name fields and attributes. RFC 3739 [4] section 3.2.6.1 defines the predefined statement "qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2. This statement defines an optional semantics information field with the following structure: SemanticsInformation ::= SEQUENCE { semanticsIdentifier OBJECT IDENTIFIER OPTIONAL, nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL } (WITH COMPONENTS {..., semanticsIdentifier PRESENT}| WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT}) NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName The semantics information field, when present, provides information about the semantics of data stored in attributes and/or names in the certificate. This Annex defines two optional semantics identifiers for inclusion in qcStatment-2 in the following subsections. B.1 Natural person sementics identifier Identifier: id-etsi-qcs-SemanticsId-Natural OBJECT IDENTIFIER ::= { TBD } Semantics definition: When this semantics identifier is included, any present serialNumber attribute in the subject field SHALL contain information using the following structure in the presented order: . 3 character natural identity type reference, . 2 character ISO 3166 [10] country code, . blank space, . identifier (according to country and identity type reference) The three initial characters has the following defined values: 1. "PAS" for identification based on passport number, 2. "IDC" for identification based on national identity card number, 3. "PNO" for identification based on (national) personal number (national civic registration number). 4. "#" followed by two characters according to local definition within the specified country and name registration authority, identifying a national scheme that is considered appropriate for national and European level. Other initial character sequences are reserved for future amendments of this standard. Examples: "PASSK P3000180", "IDCBE 590082394654" and "#EISE 200007292386" When a locally defined identity type reference is provided (with a leading "#"), the nameRegistrationAuthorities element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier generalName. The two letter identity type reference following the "#" character SHALL be unique within the context of the specified uniformResourceIdentifier. B.2 Legal person semantics identifier Identifier: id-etsi-qcs-SemanticsId-Natural OBJECT IDENTIFIER ::= { TBD } Semantics definition: When this semantics identifier is specified for the certificate, any present serialNumber attribute in the issuer field SHALL contain information using the following structure in the presented order: . 3 character natural identity type reference, . 2 character ISO 3166 [10] country code, . blank space, . identifier (according to country and identity type reference) The three initial characters has the following defined values: 1. "VAT" for identification based on VAT number, 2. "NTR" for identification based on National Trade Register. 3. "#" followed by two characters according to local definition within the specified country, identifying a national scheme that is considered appropriate for national and European level. Other initial character sequences are reserved for future amendments of this standard. Example: "VATBE 0876866142" When a locally defined identity type reference is provided (with a leading "#"), the nameRegistrationAuthorities element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier generalName. The two letter identity type reference following the "#" character SHALL be unique within the context of the specified uniformResourceIdentifier. Thanks, M.D. On 3/23/2012 7:50 PM, Stefan Santesson wrote: > I don't think this helps. > > These are certificates where the organization (or organizational > resource) is the subject. > I'm looking for a solution where the subject is a person associated > with an organization. > > /Stefan > > From: Peter Sylvester > > Date: Fri, 23 Mar 2012 18:41:14 +0100 > To: > > Subject: Re: [pkix] Need for an organizationalIdentifier attribute > > > what about: > > http://www.cabforum.org/contents.html >> >> 2012/3/23 Stefan Santesson > > >> >> When a person is associated with an organization in a >> certificate the subjects employee number or alike is often >> stored in the serialNumber attribute. >> >> But where do you store an identifier of the organization? >> That is, not the name stored in organization name, but the >> registered organization number? >> >> I've seen some odd solutions to this problem but nor clean >> solution. >> X.520 only offer organizationName and orgnizationalUnitName >> as organizational attributes >> >> Have anyone else come across this issue? >> How did you solve it? >> Do we need to define a clean attribute for an >> organizationalIdentifier? >> > > _______________________________________________ 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 --------------080505060703030008040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The simple answer is: currently there is no clear solution to identify both the Subject and/or the associated Organization. New proposals from the ETSI TS 102 280 draft, IMO worth  considering:

Subject and issuer names may include attributes that don’t disclose the semantics of its information content. This is very
common e.g. for information stored in the serialNumber attribute, which may contain a national identification number,
passport number or any type of locally defined identifier. The semantics identifier, defined in RFC 3739 [4]  offers one
way to identify the type of information that is stored in various subject name fields and attributes.
RFC 3739 [4] section 3.2.6.1 defines the predefined statement “qcStatement-2” identified by the OID id-qcspkixQCSyntax-v2.
This statement defines an optional semantics information field with the following structure:

      SemanticsInformation ::= SEQUENCE {
          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
          nameRegistrationAuthorities NameRegistrationAuthorities
                                                          OPTIONAL }
          (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
           WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})

      NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
          GeneralName
 
The semantics information field, when present, provides information about the semantics of data stored in attributes
and/or names in the certificate.
This Annex defines two optional semantics identifiers for inclusion in qcStatment-2 in the following subsections.
 
B.1 Natural person sementics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFIER ::= { TBD }
 
Semantics definition:
When this semantics identifier is included, any present serialNumber attribute in the subject field SHALL contain
information using the following structure in the presented order:
• 3 character natural identity type reference,
• 2 character ISO 3166 [10] country code,
• blank space,
• identifier (according to country and identity type reference) 
The three initial characters has the following defined values:
1. “PAS” for identification based on passport number,
2. “IDC” for identification based on national identity card number,
3. “PNO” for identification based on (national) personal number (national civic registration number).
4. “#” followed by two characters according to local definition within the specified country and name registration
authority, identifying a national scheme that is considered appropriate for national and European level.
Other initial character sequences are reserved for future amendments of this standard.
Examples: “PASSK P3000180”, “IDCBE 590082394654” and “#EISE 200007292386”
When a locally defined identity type reference is provided (with a leading “#”), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the “#” character SHALL be unique within the context of
the specified uniformResourceIdentifier.
B.2 Legal person semantics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFIER ::= { TBD }
 
Semantics definition:
When this semantics identifier is specified for the certificate, any present serialNumber attribute in the issuer field
SHALL contain information using the following structure in the presented order:
• 3 character natural identity type reference,
• 2 character ISO 3166 [10] country code,
• blank space,
• identifier (according to country and identity type reference) 
The three initial characters has the following defined values:
1. “VAT” for identification based on VAT number,
2. “NTR” for identification based on National Trade Register.
3.  “#” followed by two characters according to local definition within the specified country, identifying a national
scheme that is considered appropriate for national and European level.
Other initial character sequences are reserved for future amendments of this standard.
Example: “VATBE 0876866142”
When a locally defined identity type reference is provided (with a leading “#”), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the “#” character SHALL be unique within the context of
the specified uniformResourceIdentifier.

Thanks,
M.D.

On 3/23/2012 7:50 PM, Stefan Santesson wrote:
I don't think this helps.

These are certificates where the organization (or organizational resource) is the subject.
I'm looking for a solution where the subject is a person associated with an organization.

/Stefan

From: Peter Sylvester <peter.sylvester@edelweb.fr>
Date: Fri, 23 Mar 2012 18:41:14 +0100
To: <pkix@ietf.org>
Subject: Re: [pkix] Need for an organizationalIdentifier attribute


what about:

    http://www.cabforum.org/contents.html

2012/3/23 Stefan Santesson <stefan@aaa-sec.com>
When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.

But where do you store an identifier of the organization? 
That is, not the name stored in organization name, but the registered organization number?

I've seen some odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as organizational attributes

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier?


_______________________________________________ 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

--------------080505060703030008040403-- From DPKemp@missi.ncsc.mil Fri Mar 23 13:30:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4D21F85F6 for ; Fri, 23 Mar 2012 13:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl3hUejgsIoj for ; Fri, 23 Mar 2012 13:30:02 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5821F85F1 for ; Fri, 23 Mar 2012 13:30:01 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2NKU12d014497 for ; Fri, 23 Mar 2012 16:30:01 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 16:30:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Mar 2012 16:30:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0JHbk/gdvaVV8xT4iGT6c6zVDSJwAEPgxQ References: <4F6CB457.2010400@telia.com> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 23 Mar 2012 20:30:01.0235 (UTC) FILETIME=[B8D1C630:01CD0933] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 20:30:03 -0000 Yes, Anders and Peter Sylvester are right. The permanent identifier "assigner" field defined in RFC 4043 identifies the namespace to which the identifierValue belongs, i.e. the assigner or registrar for identifier values. Appendix B of RFC 4043 lists two sources of organization identifiers (IANA and ISO); obviously the list is not exhaustive. When you say "registered organization number", with whom is the organization registered (i.e. who is the assigner of the organization number)? In the case where an organization is the subject, the PI "assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and identifierValue would be the IANA-assigned organization number, DUNS number, etc. Although RFC 4043 defines a SAN namespace, I don't see why the PI OID (id-on-permanentIdentifier) could not also be used as an attribute type OID where the attribute value is PermanentIdentifier. You can't get around the fact that if you are talking about registered organization numbers, you MUST identify both the registrar and the organization. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, March 23, 2012 1:52 PM To: Anders Rundgren Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute No,=20 The permanent identifier is an identifier of the subject and is not an attribute. I need an identifier of the subjects organization where the subject is a person. /Stefan On 12-03-23 6:35 PM, "Anders Rundgren" wrote: >http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >br >ar > >On 2012-03-23 18:13, Stefan Santesson wrote: >> When a person is associated with an organization in a certificate the >>subjects employee number or alike is often stored in the serialNumber=20 >>attribute. >>=20 >> But where do you store an identifier of the organization? >> That is, not the name stored in organization name, but the registered >>organization number? >>=20 >> I've seen some odd solutions to this problem but nor clean solution. >> X.520 only offer organizationName and orgnizationalUnitName as=20 >>organizational attributes >>=20 >> Have anyone else come across this issue? >> How did you solve it? >> Do we need to define a clean attribute for an organizationalIdentifier? >>=20 >> /Stefan >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Fri Mar 23 14:17:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05E21F8633 for ; Fri, 23 Mar 2012 14:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQyrpKcVuTYJ for ; Fri, 23 Mar 2012 14:17:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 04A5021F862F for ; Fri, 23 Mar 2012 14:17:38 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E872D1D562A7 for ; Fri, 23 Mar 2012 22:17: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 ScHyaRwl_lqM for ; Fri, 23 Mar 2012 22:17:36 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8DCF41D55FC5 for ; Fri, 23 Mar 2012 22:17:36 +0100 (CET) Received: (qmail 79722 invoked from network); 23 Mar 2012 21:17:35 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 21:17:35 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 22:17:11 +0100 From: Stefan Santesson To: "Kemp, David P." , pkix Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 21:17:40 -0000 Dave, The subjectAlternativeName holds an alternative name of the subject. And in the present case the subject is a person. So 4043 is out of scope. /Stefan On 12-03-23 9:30 PM, "Kemp, David P." wrote: >Yes, Anders and Peter Sylvester are right. > >The permanent identifier "assigner" field defined in RFC 4043 identifies >the namespace to which the identifierValue belongs, i.e. the assigner or >registrar for identifier values. Appendix B of RFC 4043 lists two >sources of organization identifiers (IANA and ISO); obviously the list >is not exhaustive. > >When you say "registered organization number", with whom is the >organization registered (i.e. who is the assigner of the organization >number)? In the case where an organization is the subject, the PI >"assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and >identifierValue would be the IANA-assigned organization number, DUNS >number, etc. > >Although RFC 4043 defines a SAN namespace, I don't see why the PI OID >(id-on-permanentIdentifier) could not also be used as an attribute type >OID where the attribute value is PermanentIdentifier. You can't get >around the fact that if you are talking about registered organization >numbers, you MUST identify both the registrar and the organization. > >Dave > > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stefan Santesson >Sent: Friday, March 23, 2012 1:52 PM >To: Anders Rundgren >Cc: pkix >Subject: Re: [pkix] Need for an organizationalIdentifier attribute > >No, > >The permanent identifier is an identifier of the subject and is not an >attribute. >I need an identifier of the subjects organization where the subject is a >person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" >wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate the > >>>subjects employee number or alike is often stored in the serialNumber >>>attribute. >>> >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the registered > >>>organization number? >>> >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as >>>organizational attributes >>> >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an >organizationalIdentifier? >>> >>> /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 From stefan@aaa-sec.com Fri Mar 23 14:25:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5855821E802A for ; Fri, 23 Mar 2012 14:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziLfHZsIjKWL for ; Fri, 23 Mar 2012 14:25:42 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2921E8028 for ; Fri, 23 Mar 2012 14:25:42 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 265581DEAB18 for ; Fri, 23 Mar 2012 22:24: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 MPHo8wfOiz55 for ; Fri, 23 Mar 2012 22:24:49 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 84CB71DEAA34 for ; Fri, 23 Mar 2012 22:24:49 +0100 (CET) Received: (qmail 19319 invoked from network); 23 Mar 2012 21:24:49 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 21:24:49 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 22:24:34 +0100 From: Stefan Santesson To: "Moudrick M. Dadashov" Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F6CD18F.8030905@e-net.lt> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415386289_36939811" Cc: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 21:25: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_3415386289_36939811 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Both things you point out are great stuff. I happen to be the editor of both TS 102 280 and RFC 3739 and I personally use the semantics identifier in some instances and have recommended it's us= e in others. It works quite nicely. However,=20 The identifier rules defined in TS 102 280 are only applicable to personal identifiers, not organizational identifiers. And, The solution in TS 102 280 does not suggest attribute semantics overloading= . Every solution deployed in practice to store an organizational identifier i= n a certificate issued to a natural person, is solving the issue by overloading the semantics of an existing common attribute. At least as far as I have seen. /Stefan From: "Moudrick M. Dadashov" Date: Fri, 23 Mar 2012 21:39:59 +0200 To: Stefan Santesson Cc: Subject: Re: [pkix] Need for an organizationalIdentifier attribute > =20 > The simple answer is: currently there is no clear solution to identify b= oth > the Subject and/or the associated Organization. New proposals from the ET= SI TS > 102 280 draft, IMO worth considering: > =20 > Subject and issuer names may include attributes that don=B9t disclose the > semantics of its information content. This is very > common e.g. for information stored in the serialNumber attribute, which = may > contain a national identification number, > passport number or any type of locally defined identifier. The semantics > identifier, defined in RFC 3739 [4] offers one > way to identify the type of information that is stored in various subjec= t > name fields and attributes. > RFC 3739 [4] section 3.2.6.1 defines the predefined statement =B3qcStateme= nt-2=B2 > identified by the OID id-qcspkixQCSyntax-v2. > This statement defines an optional semantics information field with the > following structure: > =20 > SemanticsInformation ::=3D SEQUENCE { > semanticsIdentifier OBJECT IDENTIFIER OPTIONAL, > nameRegistrationAuthorities NameRegistrationAuthorities > OPTIONAL } > (WITH COMPONENTS {..., semanticsIdentifier PRESENT}| > WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT}) > =20 > NameRegistrationAuthorities ::=3D SEQUENCE SIZE (1..MAX) OF > GeneralName > =20 > The semantics information field, when present, provides information abou= t the > semantics of data stored in attributes > and/or names in the certificate. > This Annex defines two optional semantics identifiers for inclusion in > qcStatment-2 in the following subsections. > =20 > B.1 Natural person sementics identifier > Identifier:=20 > id-etsi-qcs-SemanticsId-Natural OBJECT IDENTIFIER ::=3D { TBD } > =20 > Semantics definition: > When this semantics identifier is included, any present serialNumber > attribute in the subject field SHALL contain > information using the following structure in the presented order: > =80 3 character natural identity type reference, > =80 2 character ISO 3166 [10] country code, > =80 blank space,=20 > =80 identifier (according to country and identity type reference) > The three initial characters has the following defined values: > 1. =B3PAS=B2 for identification based on passport number, > 2. =B3IDC=B2 for identification based on national identity card number, > 3. =B3PNO=B2 for identification based on (national) personal number (nationa= l > civic registration number). > 4. =B3#=B2 followed by two characters according to local definition within t= he > specified country and name registration > authority, identifying a national scheme that is considered appropriate = for > national and European level. > Other initial character sequences are reserved for future amendments of = this > standard. > Examples: =B3PASSK P3000180=B2, =B3IDCBE 590082394654=B2 and =B3#EISE 200007292386= =B2 > When a locally defined identity type reference is provided (with a leadi= ng > =B3#=B2), the nameRegistrationAuthorities > element of SemanticsInformation SHALL be present and SHALL contain atlea= st a > uniformResourceIdentifier > generalName. The two letter identity type reference following the =B3#=B2 > character SHALL be unique within the context of > the specified uniformResourceIdentifier. > B.2 Legal person semantics identifier > Identifier:=20 > id-etsi-qcs-SemanticsId-Natural OBJECT IDENTIFIER ::=3D { TBD } > =20 > Semantics definition: > When this semantics identifier is specified for the certificate, any pre= sent > serialNumber attribute in the issuer field > SHALL contain information using the following structure in the presented > order: > =80 3 character natural identity type reference, > =80 2 character ISO 3166 [10] country code, > =80 blank space,=20 > =80 identifier (according to country and identity type reference) > The three initial characters has the following defined values: > 1. =B3VAT=B2 for identification based on VAT number, > 2. =B3NTR=B2 for identification based on National Trade Register. > 3. =B3#=B2 followed by two characters according to local definition within = the > specified country, identifying a national > scheme that is considered appropriate for national and European level. > Other initial character sequences are reserved for future amendments of = this > standard. > Example: =B3VATBE 0876866142=B2 > When a locally defined identity type reference is provided (with a leadi= ng > =B3#=B2), the nameRegistrationAuthorities > element of SemanticsInformation SHALL be present and SHALL contain atlea= st a > uniformResourceIdentifier > generalName. The two letter identity type reference following the =B3#=B2 > character SHALL be unique within the context of > the specified uniformResourceIdentifier. > =20 > Thanks, > M.D. > =20 > On 3/23/2012 7:50 PM, Stefan Santesson wrote: >> =20 >> I don't think this helps. >> =20 >>=20 >> =20 >> =20 >> These are certificates where the organization (or organizational resourc= e) is >> the subject. >> =20 >> I'm looking for a solution where the subject is a person associated with= an >> organization. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >> From: Peter Sylvester >> Date: Fri, 23 Mar 2012 18:41:14 +0100 >> To: >> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> what about: >>> =20 >>> http://www.cabforum.org/contents.html >>> =20 >>>> =20 >>>> =20 >>>> 2012/3/23 Stefan Santesson >>>> =20 >>>>> =20 >>>>> =20 >>>>> When a person is associated with an organization in a certificate the >>>>> subjects employee number or alike is often stored in the serialNumber >>>>> attribute. >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> But where do you store an identifier of the organization? >>>>> =20 >>>>> That is, not the name stored in organization name, but the registered >>>>> organization number? >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> I've seen some odd solutions to this problem but nor clean solution. >>>>> =20 >>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>> organizational attributes >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> Have anyone else come across this issue? >>>>> =20 >>>>> How did you solve it? >>>>> =20 >>>>> Do we need to define a clean attribute for an organizationalIdentifie= r? >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =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.orghttps://www.ietf.org/mailman/listinfo/pkix >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3415386289_36939811 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,

Both things you point out are great stuff.
I happen to be the edi= tor of both TS 102 280 and RFC 3739 and I personally use the semantics ident= ifier in some instances and have recommended it's use in others.
I= t works quite nicely.

However, 

=
The identifier rules defined in TS 102 280 are only applicable to= personal identifiers, not organizational identifiers.

<= div>And,

The solution in TS 102 280 does not sugges= t attribute semantics overloading. 
Every solution deployed i= n practice to store an organizational identifier in a certificate issued to = a natural person, is solving the issue by overloading the semantics of an ex= isting common attribute.

At least as far as I have = seen.

/Stefan

From: "Moudrick M. Dadashov" <md@e-net.lt>
Date: Fri= , 23 Mar 2012 21:39:59 +0200
To: S= tefan Santesson <stefan@aaa-sec.com>
Cc: <pkix@ietf.org>
Subject:= Re: [pkix] Need for an organizationalIdentifier attribute
=

The simple answer is: currently there is no clear solution to identify both the Subject and/or the associated Organization. New proposals from the ETSI TS 102 280 draft, IMO worth  considering:<= br>
Subject and issuer names may include attributes that don’t disclo= se the semantics of its information content. This is very
common e.g. for information stored in the serialNumber attribute, which may contain a national identification number,
passport number or any type of locally defined identifier. The semantics identifier, defined in RFC 3739 [4]  offers one
way to identify the type of information that is stored in various subject name fields and attributes.
RFC 3739 [4] section 3.2.6.1 defines the predefined statement “qcStatement-2” identified by the OID id-qcspkixQCSyntax-v2= .
This statement defines an optional semantics information field with the following structure:

      SemanticsInformation ::=3D SEQUENCE {
          semanticsIdentif= ier        OBJECT IDENTIFIER   = OPTIONAL,
          nameRegistration= Authorities NameRegistrationAuthorities
            = ;            &nb= sp;            &= nbsp;            = ;        OPTIONAL }
          (WITH COMPONENTS= {..., semanticsIdentifier PRESENT}|
           WITH COMPO= NENTS {..., nameRegistrationAuthorities PRESENT})

      NameRegistrationAuthorities ::=3D  SE= QUENCE SIZE (1..MAX) OF
          GeneralName
 
The semantics information field, when present, provides information about the semantics of data stored in attributes
and/or names in the certificate.
This Annex defines two optional semantics identifiers for inclusion in qcStatment-2 in the following subsections.
 
B.1 Natural person sementics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFI= ER ::=3D { TBD }
 
Semantics definition:
When this semantics identifier is included, any present serialNumber attribute in the subject field SHALL contain
information using the following structure in the presented order:
• 3 character natural identity type reference,
• 2 character ISO 3166 [10] country code,
• blank space,
• identifier (according to country and identity type reference)&n= bsp;
The three initial characters has the following defined values:
1. “PAS” for identification based on passport number,
2. “IDC” for identification based on national identity card= number,
3. “PNO” for identification based on (national) personal nu= mber (national civic registration number).
4. “#” followed by two characters according to local defini= tion within the specified country and name registration
authority, identifying a national scheme that is considered appropriate for national and European level.
Other initial character sequences are reserved for future amendments of this standard.
Examples: “PASSK P3000180”, “IDCBE 590082394654”= ; and “#EISE 200007292386”
When a locally defined identity type reference is provided (with a leading “#”), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the “#” character SHALL be unique within the context of
the specified uniformResourceIdentifier.
B.2 Legal person semantics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFI= ER ::=3D { TBD }
 
Semantics definition:
When this semantics identifier is specified for the certificate, any present serialNumber attribute in the issuer field
SHALL contain information using the following structure in the presented order:
• 3 character natural identity type reference,
• 2 character ISO 3166 [10] country code,
• blank space,
• identifier (according to country and identity type reference)&n= bsp;
The three initial characters has the following defined values:
1. “VAT” for identification based on VAT number,
2. “NTR” for identification based on National Trade Registe= r.
3.  “#” followed by two characters according to local = definition within the specified country, identifying a national
scheme that is considered appropriate for national and European level.
Other initial character sequences are reserved for future amendments of this standard.
Example: “VATBE 0876866142”
When a locally defined identity type reference is provided (with a leading “#”), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the “#” character SHALL be unique within the context of
the specified uniformResourceIdentifier.

Thanks,
M.D.

On 3/23/2012 7:50 PM, Stefan Santesson wrote:
=
I don't think this helps.

These are certificates where the organization (or organizational resource) is the subject.
I'm looking for a solution where the subject is a person associated with an organization.

/Stefan

From: Peter Sylvester <peter.sylvester@edelweb.fr>
Date: Fri, 23 Mar 2012 18:41:14 +0100
To: <pkix@ietf.org>
Subject: Re: [pkix] Need for an organizationalIdentifier attribute


what about:

    http://www.cabfor= um.org/contents.html

2012/3/23 Stefan Santesson <stef= an@aaa-sec.com>
When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.

But where do you store an identifier of the organization? 
That is, not the name stored in organization name, but the registered organization number?
=

I've seen some odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as organizational attributes

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier?


_______________________________________________ pkix mailing list pkix@ietf.o= rg https://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_3415386289_36939811-- From DPKemp@missi.ncsc.mil Fri Mar 23 15:13:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97C21F863E for ; Fri, 23 Mar 2012 15:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CASE1YuJnTg1 for ; Fri, 23 Mar 2012 15:13:20 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 969D421F862F for ; Fri, 23 Mar 2012 15:13:20 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2NMDJOS015534 for ; Fri, 23 Mar 2012 18:13:19 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 18:13:19 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Mar 2012 18:13:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0JOmBQlIFgM8nOTNa6HfUFtaaUFgAACOpA References: From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 23 Mar 2012 22:13:19.0767 (UTC) FILETIME=[276EB270:01CD0942] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 22:13:21 -0000 You have not sufficiently specified the question. So far you have said: >>> When a person is associated with an organization in a certificate=20 >>> the subjects employee number or alike is often stored in the serialNumber=20 >>> attribute. >>>=20 >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the=20 >>> registered organization number? If the subject of a certificate is a person, then the only reason to store a "registered organization number" is to identify the assigner of the subject's "employee number or alike". RFC 4043 defines how to store an assigner (a registered organization number) and an identifierValue (an employee number) in a subject alternative name. If that is out of scope, you will need to clarify your requirements more precisely. If the requirement is to place a subject identifier into a Distinguished Name as an RDN attribute, then using a PermanentIdentifier attribute with id-on-permanentIdentifier as the attribute type is a possible (though currently undocumented) solution. Another solution would be to define a new attribute type with a different syntax >>> I've seen some odd solutions to this problem but nor clean solution. That's because DN is an odd construct - you can stick any attribute into it (such as an email address or a cert policy description or a jpeg of a cat) regardless of whether it has anything to do with a subject namespace. You could make up some "odd" attributes (such as an organization identifier attribute) along with some odd rules (such as the organization identifier is to be interpreted as the assigner of an employee number contained in a serialNumber attribute in the same or a different RDN). You need to answer questions like Is "C=3DUS, O=3DFord, ONum=3D1234, SN=3D567890, CN=3DJoe Blow" the same subject or a different subject than "C=3DUS, O=3DFord, E=3Djoe@ford.com, SN=3D567890, = ONum=3D1234, CN=3DJoe Blow"? Or you could use a clean solution (RFC 4043) that was designed explicitly to solve the problem of linking organizational identifiers to organization-assigned employee numbers in a well-defined unambiguous syntax. Dave -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Friday, March 23, 2012 5:17 PM To: Kemp, David P.; pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute Dave, The subjectAlternativeName holds an alternative name of the subject. And in the present case the subject is a person. So 4043 is out of scope. /Stefan On 12-03-23 9:30 PM, "Kemp, David P." wrote: >Yes, Anders and Peter Sylvester are right. > >The permanent identifier "assigner" field defined in RFC 4043=20 >identifies the namespace to which the identifierValue belongs, i.e. the >assigner or registrar for identifier values. Appendix B of RFC 4043=20 >lists two sources of organization identifiers (IANA and ISO); obviously >the list is not exhaustive. > >When you say "registered organization number", with whom is the=20 >organization registered (i.e. who is the assigner of the organization=20 >number)? In the case where an organization is the subject, the PI=20 >"assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and=20 >identifierValue would be the IANA-assigned organization number, DUNS=20 >number, etc. > >Although RFC 4043 defines a SAN namespace, I don't see why the PI OID >(id-on-permanentIdentifier) could not also be used as an attribute type >OID where the attribute value is PermanentIdentifier. You can't get=20 >around the fact that if you are talking about registered organization=20 >numbers, you MUST identify both the registrar and the organization. > >Dave > > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stefan Santesson >Sent: Friday, March 23, 2012 1:52 PM >To: Anders Rundgren >Cc: pkix >Subject: Re: [pkix] Need for an organizationalIdentifier attribute > >No, > >The permanent identifier is an identifier of the subject and is not an=20 >attribute. >I need an identifier of the subjects organization where the subject is=20 >a person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" >wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate=20 >>> the > >>>subjects employee number or alike is often stored in the serialNumber >>>attribute. >>>=20 >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the=20 >>> registered > >>>organization number? >>>=20 >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as=20 >>>organizational attributes >>>=20 >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an >organizationalIdentifier? >>>=20 >>> /Stefan >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > >_______________________________________________ >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 Fri Mar 23 16:48:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7696121F8505 for ; Fri, 23 Mar 2012 16:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYvTOY4vzNux for ; Fri, 23 Mar 2012 16:48:52 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8211721F8422 for ; Fri, 23 Mar 2012 16:48:52 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 53C331D6B58B for ; Sat, 24 Mar 2012 00:48:51 +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 JJ3YbHAAmrlE for ; Sat, 24 Mar 2012 00:48:50 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C08FD1D6AC7E for ; Sat, 24 Mar 2012 00:48:50 +0100 (CET) Received: (qmail 654 invoked from network); 23 Mar 2012 23:48:50 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Mar 2012 23:48:50 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 24 Mar 2012 00:48:47 +0100 From: Stefan Santesson To: "Kemp, David P." , pkix Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Mar 2012 23:48:53 -0000 There is a semantical difference between being the organization that registered the personal identifier and the organizationNumber associated with the organization specified in the organizationName attribute. The personal identifier does NOT have to be an employee number. In some cases it is a civic registration number or similar, not provided by the employing organization. E.g. Denmark has a nation wide electronic national ID Swedish helthcare has a helthcare identifier provided outside of the employing organization. I'm sure there are a kazillion other cases that does not fit RFC 4043. /Stefan On 12-03-23 11:13 PM, "Kemp, David P." wrote: >You have not sufficiently specified the question. So far you have said: > >>>> When a person is associated with an organization in a certificate >>>> the subjects employee number or alike is often stored in the >serialNumber >>>> attribute. >>>> >>>> But where do you store an identifier of the organization? >>>> That is, not the name stored in organization name, but the >>>> registered organization number? > >If the subject of a certificate is a person, then the only reason to >store a "registered organization number" is to identify the assigner of >the subject's "employee number or alike". > >RFC 4043 defines how to store an assigner (a registered organization >number) and an identifierValue (an employee number) in a subject >alternative name. If that is out of scope, you will need to clarify >your requirements more precisely. > >If the requirement is to place a subject identifier into a Distinguished >Name as an RDN attribute, then using a PermanentIdentifier attribute >with id-on-permanentIdentifier as the attribute type is a possible >(though currently undocumented) solution. Another solution would be to >define a new attribute type with a different syntax > >>>> I've seen some odd solutions to this problem but nor clean solution. > >That's because DN is an odd construct - you can stick any attribute into >it (such as an email address or a cert policy description or a jpeg of a >cat) regardless of whether it has anything to do with a subject >namespace. You could make up some "odd" attributes (such as an >organization identifier attribute) along with some odd rules (such as >the organization identifier is to be interpreted as the assigner of an >employee number contained in a serialNumber attribute in the same or a >different RDN). You need to answer questions like Is "C=US, O=Ford, >ONum=1234, SN=567890, CN=Joe Blow" the same subject or a different >subject than "C=US, O=Ford, E=joe@ford.com, SN=567890, ONum=1234, CN=Joe >Blow"? > >Or you could use a clean solution (RFC 4043) that was designed >explicitly to solve the problem of linking organizational identifiers to >organization-assigned employee numbers in a well-defined unambiguous >syntax. > >Dave > > > >-----Original Message----- >From: Stefan Santesson [mailto:stefan@aaa-sec.com] >Sent: Friday, March 23, 2012 5:17 PM >To: Kemp, David P.; pkix >Subject: Re: [pkix] Need for an organizationalIdentifier attribute > >Dave, > >The subjectAlternativeName holds an alternative name of the subject. >And in the present case the subject is a person. > >So 4043 is out of scope. > >/Stefan > > > >On 12-03-23 9:30 PM, "Kemp, David P." wrote: > >>Yes, Anders and Peter Sylvester are right. >> >>The permanent identifier "assigner" field defined in RFC 4043 >>identifies the namespace to which the identifierValue belongs, i.e. the > >>assigner or registrar for identifier values. Appendix B of RFC 4043 >>lists two sources of organization identifiers (IANA and ISO); obviously > >>the list is not exhaustive. >> >>When you say "registered organization number", with whom is the >>organization registered (i.e. who is the assigner of the organization >>number)? In the case where an organization is the subject, the PI >>"assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and >>identifierValue would be the IANA-assigned organization number, DUNS >>number, etc. >> >>Although RFC 4043 defines a SAN namespace, I don't see why the PI OID >>(id-on-permanentIdentifier) could not also be used as an attribute type > >>OID where the attribute value is PermanentIdentifier. You can't get >>around the fact that if you are talking about registered organization >>numbers, you MUST identify both the registrar and the organization. >> >>Dave >> >> >>-----Original Message----- >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > >>Stefan Santesson >>Sent: Friday, March 23, 2012 1:52 PM >>To: Anders Rundgren >>Cc: pkix >>Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> >>No, >> >>The permanent identifier is an identifier of the subject and is not an >>attribute. >>I need an identifier of the subjects organization where the subject is >>a person. >> >>/Stefan >> >>On 12-03-23 6:35 PM, "Anders Rundgren" >>wrote: >> >>>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>br >>>ar >>> >>>On 2012-03-23 18:13, Stefan Santesson wrote: >>>> When a person is associated with an organization in a certificate >>>> the >> >>>>subjects employee number or alike is often stored in the serialNumber > >>>>attribute. >>>> >>>> But where do you store an identifier of the organization? >>>> That is, not the name stored in organization name, but the >>>> registered >> >>>>organization number? >>>> >>>> I've seen some odd solutions to this problem but nor clean solution. >>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>organizational attributes >>>> >>>> Have anyone else come across this issue? >>>> How did you solve it? >>>> Do we need to define a clean attribute for an >>organizationalIdentifier? >>>> >>>> /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 From anders.rundgren@telia.com Fri Mar 23 22:44:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB8021F857A for ; Fri, 23 Mar 2012 22:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyLsvsgR39Oq for ; Fri, 23 Mar 2012 22:44:44 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 175C021F84DA for ; Fri, 23 Mar 2012 22:44:44 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00517AF4; Sat, 24 Mar 2012 06:44:42 +0100 Message-ID: <4F6D5F43.2030907@telia.com> Date: Sat, 24 Mar 2012 06:44:35 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 24 Mar 2012 05:44:45 -0000 On 2012-03-24 00:48, Stefan Santesson wrote: > There is a semantical difference between being the organization that > registered the personal identifier and the organizationNumber associated > with the organization specified in the organizationName attribute. > > The personal identifier does NOT have to be an employee number. In some > cases it is a civic registration number or similar, not provided by the > employing organization. > > E.g. > Denmark has a nation wide electronic national ID > Swedish helthcare has a helthcare identifier provided outside of the > employing organization. > I'm sure there are a kazillion other cases that does not fit RFC 4043. As I interpret the spec. it should be able to deal with any name-space/registry for any kind of entity. If both the organization and the employee are "numbered" one could use multiple PIs. It is the "assigner" that tells you what the identifier actually is. It seems hard coming up with a more precise definition. I always thought PIs should have been in the DN but as you know there were hordes if people who claim a DN must match a DIT. I may be working in the outskirts of PKI but I only find systems that parse specific attributes out of certificates and use that for access control. Attribute order (for example) seems to be of no importance. No, I don't want to discuss DN attributes again, we did that 10 yeas ago :-) If you really need a new attribute, I would make sure that it covers than a single use-case since identifiers belonging to name-spaces are pretty universal. Phone numbers, car license plates, devices, etc. Anders > > /Stefan > > > > On 12-03-23 11:13 PM, "Kemp, David P." wrote: > >> You have not sufficiently specified the question. So far you have said: >> >>>>> When a person is associated with an organization in a certificate >>>>> the subjects employee number or alike is often stored in the >> serialNumber >>>>> attribute. >>>>> >>>>> But where do you store an identifier of the organization? >>>>> That is, not the name stored in organization name, but the >>>>> registered organization number? >> >> If the subject of a certificate is a person, then the only reason to >> store a "registered organization number" is to identify the assigner of >> the subject's "employee number or alike". >> >> RFC 4043 defines how to store an assigner (a registered organization >> number) and an identifierValue (an employee number) in a subject >> alternative name. If that is out of scope, you will need to clarify >> your requirements more precisely. >> >> If the requirement is to place a subject identifier into a Distinguished >> Name as an RDN attribute, then using a PermanentIdentifier attribute >> with id-on-permanentIdentifier as the attribute type is a possible >> (though currently undocumented) solution. Another solution would be to >> define a new attribute type with a different syntax >> >>>>> I've seen some odd solutions to this problem but nor clean solution. >> >> That's because DN is an odd construct - you can stick any attribute into >> it (such as an email address or a cert policy description or a jpeg of a >> cat) regardless of whether it has anything to do with a subject >> namespace. You could make up some "odd" attributes (such as an >> organization identifier attribute) along with some odd rules (such as >> the organization identifier is to be interpreted as the assigner of an >> employee number contained in a serialNumber attribute in the same or a >> different RDN). You need to answer questions like Is "C=US, O=Ford, >> ONum=1234, SN=567890, CN=Joe Blow" the same subject or a different >> subject than "C=US, O=Ford, E=joe@ford.com, SN=567890, ONum=1234, CN=Joe >> Blow"? >> >> Or you could use a clean solution (RFC 4043) that was designed >> explicitly to solve the problem of linking organizational identifiers to >> organization-assigned employee numbers in a well-defined unambiguous >> syntax. >> >> Dave >> >> >> >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Friday, March 23, 2012 5:17 PM >> To: Kemp, David P.; pkix >> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> >> Dave, >> >> The subjectAlternativeName holds an alternative name of the subject. >> And in the present case the subject is a person. >> >> So 4043 is out of scope. >> >> /Stefan >> >> >> >> On 12-03-23 9:30 PM, "Kemp, David P." wrote: >> >>> Yes, Anders and Peter Sylvester are right. >>> >>> The permanent identifier "assigner" field defined in RFC 4043 >>> identifies the namespace to which the identifierValue belongs, i.e. the >> >>> assigner or registrar for identifier values. Appendix B of RFC 4043 >>> lists two sources of organization identifiers (IANA and ISO); obviously >> >>> the list is not exhaustive. >>> >>> When you say "registered organization number", with whom is the >>> organization registered (i.e. who is the assigner of the organization >>> number)? In the case where an organization is the subject, the PI >>> "assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and >>> identifierValue would be the IANA-assigned organization number, DUNS >>> number, etc. >>> >>> Although RFC 4043 defines a SAN namespace, I don't see why the PI OID >>> (id-on-permanentIdentifier) could not also be used as an attribute type >> >>> OID where the attribute value is PermanentIdentifier. You can't get >>> around the fact that if you are talking about registered organization >>> numbers, you MUST identify both the registrar and the organization. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> >>> Stefan Santesson >>> Sent: Friday, March 23, 2012 1:52 PM >>> To: Anders Rundgren >>> Cc: pkix >>> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >>> >>> No, >>> >>> The permanent identifier is an identifier of the subject and is not an >>> attribute. >>> I need an identifier of the subjects organization where the subject is >>> a person. >>> >>> /Stefan >>> >>> On 12-03-23 6:35 PM, "Anders Rundgren" >>> wrote: >>> >>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>> br >>>> ar >>>> >>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>> When a person is associated with an organization in a certificate >>>>> the >>> >>>>> subjects employee number or alike is often stored in the serialNumber >> >>>>> attribute. >>>>> >>>>> But where do you store an identifier of the organization? >>>>> That is, not the name stored in organization name, but the >>>>> registered >>> >>>>> organization number? >>>>> >>>>> I've seen some odd solutions to this problem but nor clean solution. >>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>> organizational attributes >>>>> >>>>> Have anyone else come across this issue? >>>>> How did you solve it? >>>>> Do we need to define a clean attribute for an >>> organizationalIdentifier? >>>>> >>>>> /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 > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From stefan@aaa-sec.com Sat Mar 24 03:16:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCB21F8702 for ; Sat, 24 Mar 2012 03:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6HQrnQ3qGV8 for ; Sat, 24 Mar 2012 03:16:17 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id DF2C121F86B5 for ; Sat, 24 Mar 2012 03:16:16 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 40D781DFCFEA for ; Sat, 24 Mar 2012 11:16:15 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mFcimMFJ0PCt for ; Sat, 24 Mar 2012 11:16:14 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 74A4B1DFD083 for ; Sat, 24 Mar 2012 11:16:05 +0100 (CET) Received: (qmail 66505 invoked from network); 24 Mar 2012 10:16:04 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Mar 2012 10:16:04 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 24 Mar 2012 11:15:51 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F6D5F43.2030907@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 24 Mar 2012 10:16:17 -0000 On 12-03-24 6:44 AM, "Anders Rundgren" wrote: >No, I don't want to discuss DN attributes again, we did that 10 yeas ago >:-) By all means, feel free to NOT hit the reply all button :) I don't disagree with your observations. It's just that there is not even a generic attribute that is suitable for storing an organizational identifier related to the organization named in the organizationName attribute (when the subject is a person). I could create my own, but I'd rather have a standard one. Generic is fine. /Stefan From era@x500.eu Sat Mar 24 03:38:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B552521F8700 for ; Sat, 24 Mar 2012 03:38:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLSyPqEuibrr for ; Sat, 24 Mar 2012 03:38:18 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4321F86FD for ; Sat, 24 Mar 2012 03:38:17 -0700 (PDT) Received: from Morten ([79.138.252.113]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id INK38815 for ; Sat, 24 Mar 2012 11:38:15 +0100 From: "Erik Andersen" To: "'pkix'" References: <4F6D5F43.2030907@telia.com> In-Reply-To: Date: Sat, 24 Mar 2012 11:38:10 +0100 Message-ID: <005c01cd09aa$39f26690$add733b0$@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: Ac0JpzIyXICc1HXiRTOYt5FWdchprAAAWDmw Content-Language: da Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 24 Mar 2012 10:38:18 -0000 Stefan, The seventh edition of X.500 will be finalised at the end this year. We = are at a stage where we in principle can only submit editorial comments. However, if we by some imagination could invent a Defect Report = requiring a new attribute type to be defined, we could sneak such new attribute type into the seventh edition of X.520. Erik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Stefan Santesson Sendt: 24. marts 2012 11:16 Til: Anders Rundgren Cc: pkix Emne: Re: [pkix] Need for an organizationalIdentifier attribute On 12-03-24 6:44 AM, "Anders Rundgren" = wrote: >No, I don't want to discuss DN attributes again, we did that 10 yeas=20 >ago >:-) By all means, feel free to NOT hit the reply all button :) I don't disagree with your observations. It's just that there is not even a generic attribute that is suitable = for storing an organizational identifier related to the organization named = in the organizationName attribute (when the subject is a person). I could create my own, but I'd rather have a standard one. Generic is fine. /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Sat Mar 24 09:45:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB221F8615 for ; Sat, 24 Mar 2012 09:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB+fY2xq2PGC for ; Sat, 24 Mar 2012 09:45:00 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id AA07821F85F0 for ; Sat, 24 Mar 2012 09:44:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EF3DE1D989A4 for ; Sat, 24 Mar 2012 17:43: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 0oNI0NEfsFmn for ; Sat, 24 Mar 2012 17:43:24 +0100 (CET) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A5B531D76D0E for ; Sat, 24 Mar 2012 17:43:24 +0100 (CET) Received: (qmail 66307 invoked from network); 24 Mar 2012 16:43:22 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.6]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Mar 2012 16:43:22 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 24 Mar 2012 17:43:16 +0100 From: Stefan Santesson To: Erik Andersen , 'pkix' Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <005c01cd09aa$39f26690$add733b0$@eu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 24 Mar 2012 16:45:01 -0000 Hi Eric, Actually I think that would be the ideal solution. >From the responses on this list there is clearly a need that has been resolved in various incompatible ways by stretching semantics of current attributes. Personally I have a government project where we will need such attribute, whether we define our own or have a standard one to use. So I would personally welcome such action by the ITU. /Stefan On 12-03-24 11:38 AM, "Erik Andersen" wrote: >Stefan, > >The seventh edition of X.500 will be finalised at the end this year. We >are >at a stage where we in principle can only submit editorial comments. > >However, if we by some imagination could invent a Defect Report requiring >a >new attribute type to be defined, we could sneak such new attribute type >into the seventh edition of X.520. > >Erik > >-----Oprindelig meddelelse----- >Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af >Stefan >Santesson >Sendt: 24. marts 2012 11:16 >Til: Anders Rundgren >Cc: pkix >Emne: Re: [pkix] Need for an organizationalIdentifier attribute > > > >On 12-03-24 6:44 AM, "Anders Rundgren" wrote: > >>No, I don't want to discuss DN attributes again, we did that 10 yeas >>ago >>:-) > >By all means, feel free to NOT hit the reply all button :) > > >I don't disagree with your observations. >It's just that there is not even a generic attribute that is suitable for >storing an organizational identifier related to the organization named in >the organizationName attribute (when the subject is a person). > >I could create my own, but I'd rather have a standard one. >Generic is fine. > >/Stefan > > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From md@e-net.lt Sun Mar 25 03:42:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91A21F8573 for ; Sun, 25 Mar 2012 03:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsF-sXdj3fRg for ; Sun, 25 Mar 2012 03:42:25 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6F21F856F for ; Sun, 25 Mar 2012 03:42:25 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SBkty-00077g-I3 for pkix@ietf.org; Sun, 25 Mar 2012 13:42:22 +0300 Message-ID: <4F6EF68D.1030509@e-net.lt> Date: Sun, 25 Mar 2012 13:42:21 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.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 Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 25 Mar 2012 10:42:26 -0000 On 3/24/2012 12:15 PM, Stefan Santesson wrote: > > On 12-03-24 6:44 AM, "Anders Rundgren" wrote: > >> No, I don't want to discuss DN attributes again, we did that 10 yeas ago >> :-) > By all means, feel free to NOT hit the reply all button :) > > > I don't disagree with your observations. > It's just that there is not even a generic attribute that is suitable for > storing an organizational identifier related to the organization named in > the organizationName attribute (when the subject is a person). Are you saying an organization identifier should vary dependent on the context (when Subject is a natural person or is a legal entity or even the cert issuer)? If yes, what is rationale? Thanks, M.D. > > I could create my own, but I'd rather have a standard one. > Generic is fine. > > /Stefan > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Mon Mar 26 01:20:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806C321F84AA for ; Mon, 26 Mar 2012 01:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.364 X-Spam-Level: X-Spam-Status: No, score=-106.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjmxS38drOpK for ; Mon, 26 Mar 2012 01:20:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8284121F8527 for ; Mon, 26 Mar 2012 01:20:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59862 helo=[10.108.71.115]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC5AH-000Hge-00; Mon, 26 Mar 2012 04:20:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> Date: Mon, 26 Mar 2012 04:19:56 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 08:20:49 -0000 Paul, I found the text that David offered to be confusing, at best. For example, if a TLS server transmits a self-signed cert in the handshake, and there is no subordinate cert representing the site, does this cert begin the cert path or not? Is there no cert path because there is just one cert? Is this cert not treated as a TA and used to verify a sig in a fashion consistent with what TAMP allows? Why does the text say that "... self-signed end-entity certificates SHOULD NOT include a BasicConstraints extension that asserts the cA boolean." If the cert has this flag set, then it is a CA cert, not an EE cert. I don't find this text to be clear or helpful. The final sentence of David's text is certainly non-judgmental, which appears to be what you would like to see, but that was not the message I (and others, see below) wanted to convey. All three of the blocks of text that appear in my message were sent to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to David. There was no disagreement with the wording I proposed. David chose to ignore two of blocks of text, and transformed the first one into the text that you prefer. So, we have an internal communication problem with the author :-). Let me reiterate that this text, while written by me, was reviewed by other, long-time PKIX contributors, two of whom (Russ and Tim) are co-authors of 5280, and its predecessors. The one 5280 co-author who has said, publicly, that he didn't view self-signed EE certs as not being inconsistent with 5280 and X.509 is Stephen Farrell. Sharon Boyen just indicated that, fro her perspective as editor, the X.509 model assumes that the signer of a cert is a CA. My goal in writing the text about self-signed certs was to clarify the 5280 position on them, saying that they are OK in certain, limited contexts. At the same time I want to state that, in general, PKIX prefers certs to be verified using CA certs, consistent with the X.509 model and general practice. I am open to revising the text in question, but I do not find what David has provided is useful. Steve From kent@bbn.com Mon Mar 26 02:09:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE9E21F84F6 for ; Mon, 26 Mar 2012 02:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOp9GrWkFaS2 for ; Mon, 26 Mar 2012 02:09:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1A21F8468 for ; Mon, 26 Mar 2012 02:09:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38025 helo=[10.108.71.115]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC5vN-000Hzp-UL for pkix@ietf.org; Mon, 26 Mar 2012 05:09:14 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 26 Mar 2012 05:09:18 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] too many negatives ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 09:09:29 -0000 Stephen Farrell noted that I inserted too many negatives in my comment about 5280 co-authors and the SS/EE cert issue. What I meant to say was: Stephen Farrell is the one co-author of 5280 who has said, publicly, that he view self-signed, EE certs as not inconsistent with 5280 and X.509. Sorry 'bout the confusion. Steve From tmiller@mitre.org Mon Mar 26 05:41:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EEE21F86F0 for ; Mon, 26 Mar 2012 05:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNL8yAebLjac for ; Mon, 26 Mar 2012 05:41:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3997921F8697 for ; Mon, 26 Mar 2012 05:41:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F1D821B04F4; Mon, 26 Mar 2012 08:41:14 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 829E221B024B; Mon, 26 Mar 2012 08:41:14 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 08:41:14 -0400 From: "Miller, Timothy J." To: "Kemp, David P." Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4aGuAgARj54A= Date: Mon, 26 Mar 2012 12:41:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.38.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D18500B89866D4793DFEE68EED2A1CC@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 12:41:16 -0000 Don't forget the "Codes for Identification of Federal and Federally-Assiste= d Organizations," NIST SP800-87 (was FIPS 95-2).=20 Identifiers we have in plenty. :) -- T On Mar 23, 2012, at 12:38 PM, Kemp, David P. wrote: > The DoD guide for uniquely identifying items > (http://www.acq.osd.mil/dpap/UID/attachments/DoDUIDGuide.pdf) specifies > a string format for Item Unique Identifiers consisting of an enterprise > identifier and an item serial number. The catalog of recognized > enterprise (organization) numbers includes those from the following > Issuing Agencies: >=20 > * GS1 (formerly UCC/EAN) company prefix > * Telcordia > * Dun & Bradstreet DUNS numbers > * NATO Contractor and Government Entity (NCAGE) codes > * European Health Industry Business Communications Council (EHIBCC) > * DoD Activity Address Code (DoDAAC) >=20 > As far as I know, an attribute OID has not been defined for > organizationalIdentifier based on these Issuing Agency Codes, but if one > were to be defined, the IUID document has some good background > information on how to construct it. >=20 > Dave >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Friday, March 23, 2012 1:13 PM > To: pkix > Subject: [pkix] Need for an organizationalIdentifier attribute >=20 > When a person is associated with an organization in a certificate the > subjects employee number or alike is often stored in the serialNumber > attribute. >=20 > But where do you store an identifier of the organization?=20 > That is, not the name stored in organization name, but the registered > organization number? >=20 > I've seen some odd solutions to this problem but nor clean solution. > X.520 only offer organizationName and orgnizationalUnitName as > organizational attributes >=20 > Have anyone else come across this issue? > How did you solve it? > Do we need to define a clean attribute for an organizationalIdentifier? >=20 > /Stefan >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Mon Mar 26 05:46:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4F21E808E for ; Mon, 26 Mar 2012 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhBHMyrhWVhe for ; Mon, 26 Mar 2012 05:46:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0821E8096 for ; Mon, 26 Mar 2012 05:46:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA1A821B0ADB; Mon, 26 Mar 2012 08:46:20 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B727021B0AD0; Mon, 26 Mar 2012 08:46:20 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 08:46:20 -0400 From: "Miller, Timothy J." To: "Moudrick M. Dadashov" Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCAACwVAIAADS+AgAAPr4CAABqsgIAAY2mAgABLy4CAAZm8gIABtPiA Date: Mon, 26 Mar 2012 12:46:19 +0000 Message-ID: References: <4F6EF68D.1030509@e-net.lt> In-Reply-To: <4F6EF68D.1030509@e-net.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.38.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <82D939CCCBB7CE42B3467F598D0F62E9@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 12:46:22 -0000 On Mar 25, 2012, at 5:42 AM, Moudrick M. Dadashov wrote: > Are you saying an organization identifier should vary dependent on the co= ntext (when Subject is a natural person or is a legal entity or even the ce= rt issuer)? If yes, what is rationale? Since there's no universally recognized international naming authority, I t= hink it's obvious that the presence of any such identifier must be qualifie= d by the authority in question. This does double duty of providing disambi= guation and providing syntax. =20 -- T From tgindin@us.ibm.com Mon Mar 26 06:50:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52E21E808B for ; Mon, 26 Mar 2012 06:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8kyUGx2lkwf for ; Mon, 26 Mar 2012 06:50:02 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD91921E8013 for ; Mon, 26 Mar 2012 06:50:01 -0700 (PDT) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Mar 2012 09:49:58 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 26 Mar 2012 09:47:40 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 36F6038C805E for ; Mon, 26 Mar 2012 09:47:36 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2QDlHYI286434 for ; Mon, 26 Mar 2012 09:47:27 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2QDlHEv024252 for ; Mon, 26 Mar 2012 09:47:17 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2QDlH90024247; Mon, 26 Mar 2012 09:47:17 -0400 In-Reply-To: References: <4F6CB457.2010400@telia.com> To: Stefan Santesson MIME-Version: 1.0 X-KeepSent: 0D594E2D:1F3A7B95-852579CA:006E773C; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Mon, 26 Mar 2012 09:47:15 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/26/2012 09:47:16, Serialize complete at 03/26/2012 09:47:16 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032613-1976-0000-0000-00000BC51BC2 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 13:50:02 -0000 PI is a valid identifier of an organization, but it doesn't fit in a DN. It's a separate GeneralName. It is perfectly true that there's a PI corresponding to Erwann's example, but most AssignerAuthority values are not defined attributes. We could define an attribute (probably a different OID from the OTHER-NAME one) whose syntax is that of PI, but would it be supported by actual LDAP implementations? Tom Gindin From: Stefan Santesson To: Anders Rundgren , Cc: pkix Date: 03/23/2012 01:52 PM Subject: Re: [pkix] Need for an organizationalIdentifier attribute Sent by: pkix-bounces@ietf.org No, The permanent identifier is an identifier of the subject and is not an attribute. I need an identifier of the subjects organization where the subject is a person. /Stefan On 12-03-23 6:35 PM, "Anders Rundgren" wrote: >http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >br >ar > >On 2012-03-23 18:13, Stefan Santesson wrote: >> When a person is associated with an organization in a certificate the >>subjects employee number or alike is often stored in the serialNumber >>attribute. >> >> But where do you store an identifier of the organization? >> That is, not the name stored in organization name, but the registered >>organization number? >> >> I've seen some odd solutions to this problem but nor clean solution. >> X.520 only offer organizationName and orgnizationalUnitName as >>organizational attributes >> >> Have anyone else come across this issue? >> How did you solve it? >> Do we need to define a clean attribute for an organizationalIdentifier? >> >> /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 From stefan@aaa-sec.com Mon Mar 26 07:12:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DF221F841C for ; Mon, 26 Mar 2012 07:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE62i0F6FGQi for ; Mon, 26 Mar 2012 07:12:26 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 01DA421F8466 for ; Mon, 26 Mar 2012 07:12:13 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id AB55F1DD56E3 for ; Mon, 26 Mar 2012 16:12:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o3ZEDm2Mwquu for ; Mon, 26 Mar 2012 16:12:11 +0200 (CEST) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 53B111DC32AE for ; Mon, 26 Mar 2012 16:12:11 +0200 (CEST) Received: (qmail 66625 invoked from network); 26 Mar 2012 14:12:09 -0000 Received: from access-50.80.rev.fr.colt.net (HELO [10.59.90.136]) (stefan@fiddler.nu@[213.41.80.50]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Mar 2012 14:12:09 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 26 Mar 2012 16:11:33 +0100 From: Stefan Santesson To: Tom Gindin Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 14:12:28 -0000 Tom, The PI is a Subject Alternative name. (I.e. name of the Subject) It works great if the subject is an organization. In the discussed case, the subject is a person, so PI does not work. /Stefan On 12-03-26 2:47 PM, "Tom Gindin" wrote: > PI is a valid identifier of an organization, but it doesn't fit >in >a DN. It's a separate GeneralName. It is perfectly true that there's a >PI corresponding to Erwann's example, but most AssignerAuthority values >are not defined attributes. We could define an attribute (probably a >different OID from the OTHER-NAME one) whose syntax is that of PI, but >would it be supported by actual LDAP implementations? > >Tom Gindin > > > > >From: Stefan Santesson >To: Anders Rundgren , >Cc: pkix >Date: 03/23/2012 01:52 PM >Subject: Re: [pkix] Need for an organizationalIdentifier attribute >Sent by: pkix-bounces@ietf.org > > > >No, > >The permanent identifier is an identifier of the subject and is not an >attribute. >I need an identifier of the subjects organization where the subject is a >person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate the >>>subjects employee number or alike is often stored in the serialNumber >>>attribute. >>> >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the registered >>>organization number? >>> >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as >>>organizational attributes >>> >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an organizationalIdentifier? >>> >>> /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 > > > From anders.rundgren@telia.com Mon Mar 26 07:47:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6865B21F84FE for ; Mon, 26 Mar 2012 07:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNg8mOd9F+AM for ; Mon, 26 Mar 2012 07:47:07 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F321F84DA for ; Mon, 26 Mar 2012 07:47:07 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E005CEE60; Mon, 26 Mar 2012 16:47:03 +0200 Message-ID: <4F70815C.4080105@telia.com> Date: Mon, 26 Mar 2012 16:46:52 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 14:47:08 -0000 Stefan, I think this discussion would run slightly smother if you provided an example of a "plausible" DN and how it is supposed to be interpreted. Since we are apparently talking about a "community" with strict rules regarding certificate content, I would still consider using a mandatory policy OID which says (in an associated document): These are the mandatory DN attributes and their interpretation. I get the feeling (could be completely wrong...) that you are talking about a DN attribute that has a relation to another DN attribute. I don't think that would be a very good target for standardization. Does (for example) X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without an O? Anders On 2012-03-26 17:11, Stefan Santesson wrote: > Tom, > > The PI is a Subject Alternative name. (I.e. name of the Subject) > > It works great if the subject is an organization. > In the discussed case, the subject is a person, so PI does not work. > > /Stefan > > On 12-03-26 2:47 PM, "Tom Gindin" wrote: > >> PI is a valid identifier of an organization, but it doesn't fit >> in >> a DN. It's a separate GeneralName. It is perfectly true that there's a >> PI corresponding to Erwann's example, but most AssignerAuthority values >> are not defined attributes. We could define an attribute (probably a >> different OID from the OTHER-NAME one) whose syntax is that of PI, but >> would it be supported by actual LDAP implementations? >> >> Tom Gindin >> >> >> >> >> From: Stefan Santesson >> To: Anders Rundgren , >> Cc: pkix >> Date: 03/23/2012 01:52 PM >> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> Sent by: pkix-bounces@ietf.org >> >> >> >> No, >> >> The permanent identifier is an identifier of the subject and is not an >> attribute. >> I need an identifier of the subjects organization where the subject is a >> person. >> >> /Stefan >> >> On 12-03-23 6:35 PM, "Anders Rundgren" wrote: >> >>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>> br >>> ar >>> >>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>> When a person is associated with an organization in a certificate the >>>> subjects employee number or alike is often stored in the serialNumber >>>> attribute. >>>> >>>> But where do you store an identifier of the organization? >>>> That is, not the name stored in organization name, but the registered >>>> organization number? >>>> >>>> I've seen some odd solutions to this problem but nor clean solution. >>>> X.520 only offer organizationName and orgnizationalUnitName as >>>> organizational attributes >>>> >>>> Have anyone else come across this issue? >>>> How did you solve it? >>>> Do we need to define a clean attribute for an organizationalIdentifier? >>>> >>>> /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 >> >> >> > > > From DPKemp@missi.ncsc.mil Mon Mar 26 07:50:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78E521E80C1 for ; Mon, 26 Mar 2012 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr5ZK4oWbI6i for ; Mon, 26 Mar 2012 07:50:13 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6DECA21E80B1 for ; Mon, 26 Mar 2012 07:50:07 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2QEo6HW035463 for ; Mon, 26 Mar 2012 10:50:06 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 10:50:06 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 Mar 2012 10:50:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0LWpAzUX6rbtp1RzmP503hOGBe5wAAIhkg References: From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 26 Mar 2012 14:50:06.0602 (UTC) FILETIME=[BBE8FEA0:01CD0B5F] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 14:50:14 -0000 PI works great where the subject of the certificate is a person and the organization (employer, national authority, membership organization like IEEE, etc) responsible for the subject identifier has (or can register with IANA or ISO) an organization OID. As of 26 March, IANA has registered nearly 40,000 enterprise numbers, the most recent of which are: 39635 Beijing ZhongChuang Telecom Test Co., Ltd 39636 Comet Computer GmbH If the requirement is an organization identifier assigned by some other authority such as Dun & Bradstreet (ICD 0060) or GS1 (ICD 0088), then the attribute still needs to contain the fields defined by PI: an assigner authority as well as the organization number. The Assigner Authority goes by multiple names: ISO/IEC calls it an International Code Designator (ICD) - the list of which can be found at http://www.cyber-identity.com/iso6523, and the DoD IUID Guide calls it an Issuing Agency Code (IAC). Whatever it's called, it must be present in the organization number. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, March 26, 2012 11:12 AM To: Tom Gindin Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute Tom, The PI is a Subject Alternative name. (I.e. name of the Subject) It works great if the subject is an organization. In the discussed case, the subject is a person, so PI does not work. /Stefan On 12-03-26 2:47 PM, "Tom Gindin" wrote: > PI is a valid identifier of an organization, but it doesn't fit >in a DN. It's a separate GeneralName. It is perfectly true that=20 >there's a PI corresponding to Erwann's example, but most=20 >AssignerAuthority values are not defined attributes. We could define=20 >an attribute (probably a different OID from the OTHER-NAME one) whose=20 >syntax is that of PI, but would it be supported by actual LDAP=20 >implementations? > >Tom Gindin > > > > >From: Stefan Santesson >To: Anders Rundgren , >Cc: pkix >Date: 03/23/2012 01:52 PM >Subject: Re: [pkix] Need for an organizationalIdentifier attribute >Sent by: pkix-bounces@ietf.org > > > >No, > >The permanent identifier is an identifier of the subject and is not an=20 >attribute. >I need an identifier of the subjects organization where the subject is=20 >a person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate=20 >>>the subjects employee number or alike is often stored in the=20 >>>serialNumber attribute. >>>=20 >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the=20 >>>registered organization number? >>>=20 >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as=20 >>>organizational attributes >>>=20 >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an organizationalIdentifier? >>>=20 >>> /Stefan >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > >_______________________________________________ >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 DPKemp@missi.ncsc.mil Mon Mar 26 09:36:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EF321E80D4 for ; Mon, 26 Mar 2012 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P933X6BwnjYR for ; Mon, 26 Mar 2012 09:36:00 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id DCB8F21E80D1 for ; Mon, 26 Mar 2012 09:35:59 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2QGZwiO037548 for ; Mon, 26 Mar 2012 12:35:59 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 12:35:58 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 Mar 2012 12:35:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0LWpAzUX6rbtp1RzmP503hOGBe5wAAIhkgAAQIq/A= References: From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 26 Mar 2012 16:35:58.0915 (UTC) FILETIME=[862F0930:01CD0B6E] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 16:36:01 -0000 Clarification: when the subject is a person, the PI assigner includes both the ICD and the organization number. For example, for a company such as Microsoft (DUNS 081466849, GS1 Global Location Number 0093007000005), the assigner value could be any of: 1.3.6.1.4.1.311 (IANA) 1.3.60.81466849 (DUNS) 1.3.88.93007000005 (GS1) The ICD is the third field of the OID (6, 60, 88 respectively in the above examples). GS1 identifiers can be found at http://gepir.gs1.org/v32/xx/search_by_name.aspx. DNB is a royal pain to use; it's probably easier to look up DUNS numbers at https://www.bpn.gov/CCRSearch/Search.aspx. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kemp, David P. Sent: Monday, March 26, 2012 10:50 AM To: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute PI works great where the subject of the certificate is a person and the organization (employer, national authority, membership organization like IEEE, etc) responsible for the subject identifier has (or can register with IANA or ISO) an organization OID. As of 26 March, IANA has registered nearly 40,000 enterprise numbers, the most recent of which are: 39635 Beijing ZhongChuang Telecom Test Co., Ltd 39636 Comet Computer GmbH If the requirement is an organization identifier assigned by some other authority such as Dun & Bradstreet (ICD 0060) or GS1 (ICD 0088), then the attribute still needs to contain the fields defined by PI: an assigner authority as well as the organization number. The Assigner Authority goes by multiple names: ISO/IEC calls it an International Code Designator (ICD) - the list of which can be found at http://www.cyber-identity.com/iso6523, and the DoD IUID Guide calls it an Issuing Agency Code (IAC). Whatever it's called, it must be present in the organization number. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, March 26, 2012 11:12 AM To: Tom Gindin Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute Tom, The PI is a Subject Alternative name. (I.e. name of the Subject) It works great if the subject is an organization. In the discussed case, the subject is a person, so PI does not work. /Stefan On 12-03-26 2:47 PM, "Tom Gindin" wrote: > PI is a valid identifier of an organization, but it doesn't fit >in a DN. It's a separate GeneralName. It is perfectly true that=20 >there's a PI corresponding to Erwann's example, but most=20 >AssignerAuthority values are not defined attributes. We could define=20 >an attribute (probably a different OID from the OTHER-NAME one) whose=20 >syntax is that of PI, but would it be supported by actual LDAP=20 >implementations? > >Tom Gindin > > > > >From: Stefan Santesson >To: Anders Rundgren , >Cc: pkix >Date: 03/23/2012 01:52 PM >Subject: Re: [pkix] Need for an organizationalIdentifier attribute >Sent by: pkix-bounces@ietf.org > > > >No, > >The permanent identifier is an identifier of the subject and is not an=20 >attribute. >I need an identifier of the subjects organization where the subject is=20 >a person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate=20 >>>the subjects employee number or alike is often stored in the=20 >>>serialNumber attribute. >>>=20 >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the=20 >>>registered organization number? >>>=20 >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as=20 >>>organizational attributes >>>=20 >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an organizationalIdentifier? >>>=20 >>> /Stefan >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > >_______________________________________________ >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 hotz@jpl.nasa.gov Mon Mar 26 11:14:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF7721E80F7 for ; Mon, 26 Mar 2012 11:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+uouYWDFYgp for ; Mon, 26 Mar 2012 11:14:25 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id A2EDE21E80EE for ; Mon, 26 Mar 2012 11:14:25 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2QIEKDr020745 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 26 Mar 2012 11:14:21 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 26 Mar 2012 11:14:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4489D8E8-8CC8-4842-BA15-0C66C193BAFF@jpl.nasa.gov> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix@ietf.org Subject: Re: [pkix] too many negatives ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 18:14:26 -0000 "not inconsistent" means "consistent"? ;-) On Mar 26, 2012, at 2:09 AM, Stephen Kent wrote: > Stephen Farrell noted that I inserted too many negatives in my comment > about 5280 co-authors and the SS/EE cert issue. What I meant to say = was: >=20 > Stephen Farrell is the one co-author of 5280 who has said, publicly, = that he view self-signed, EE certs as not inconsistent with 5280 and = X.509. >=20 > Sorry 'bout the confusion. >=20 > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From stefan@aaa-sec.com Mon Mar 26 13:40:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CA021E8110 for ; Mon, 26 Mar 2012 13:40:55 -0700 (PDT) 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=-1.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmUxZkz0s-CZ for ; Mon, 26 Mar 2012 13:40:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2621E8101 for ; Mon, 26 Mar 2012 13:40:52 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C97911DE2C70 for ; Mon, 26 Mar 2012 22:40:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Sp6_QFlvTQx for ; Mon, 26 Mar 2012 22:40:50 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 688821DE2C2D for ; Mon, 26 Mar 2012 22:40:50 +0200 (CEST) Received: (qmail 48407 invoked from network); 26 Mar 2012 20:40:48 -0000 Received: from access-49.80.rev.fr.colt.net (HELO [10.59.90.136]) (stefan@fiddler.nu@[213.41.80.49]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Mar 2012 20:40:48 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 26 Mar 2012 22:40:47 +0100 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F70815C.4080105@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 20:40:55 -0000 CN=John Doe SN=Doe GivenName=John SERIALNUMBER=123456789 (employee number) O=Example AB OU=Example department C=SE Example AB's org number is 555555-5555 Where do I store it? /Stefan On 12-03-26 3:46 PM, "Anders Rundgren" wrote: >Stefan, >I think this discussion would run slightly smother if you provided an >example of a "plausible" DN and how it is supposed to be interpreted. > >Since we are apparently talking about a "community" with strict rules >regarding certificate content, I would still consider using a mandatory >policy OID which says (in an associated document): These are the mandatory >DN attributes and their interpretation. > >I get the feeling (could be completely wrong...) that you are talking >about a DN attribute that has a relation to another DN attribute. I don't >think that would be a very good target for standardization. Does (for >example) >X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without an O? > >Anders > >On 2012-03-26 17:11, Stefan Santesson wrote: >> Tom, >> >> The PI is a Subject Alternative name. (I.e. name of the Subject) >> >> It works great if the subject is an organization. >> In the discussed case, the subject is a person, so PI does not work. >> >> /Stefan >> >> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >> >>> PI is a valid identifier of an organization, but it doesn't fit >>> in >>> a DN. It's a separate GeneralName. It is perfectly true that there's >>>a >>> PI corresponding to Erwann's example, but most AssignerAuthority values >>> are not defined attributes. We could define an attribute (probably a >>> different OID from the OTHER-NAME one) whose syntax is that of PI, but >>> would it be supported by actual LDAP implementations? >>> >>> Tom Gindin >>> >>> >>> >>> >>> From: Stefan Santesson >>> To: Anders Rundgren , >>> Cc: pkix >>> Date: 03/23/2012 01:52 PM >>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>attribute >>> Sent by: pkix-bounces@ietf.org >>> >>> >>> >>> No, >>> >>> The permanent identifier is an identifier of the subject and is not an >>> attribute. >>> I need an identifier of the subjects organization where the subject is >>>a >>> person. >>> >>> /Stefan >>> >>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>wrote: >>> >>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>> br >>>> ar >>>> >>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>> When a person is associated with an organization in a certificate the >>>>> subjects employee number or alike is often stored in the serialNumber >>>>> attribute. >>>>> >>>>> But where do you store an identifier of the organization? >>>>> That is, not the name stored in organization name, but the registered >>>>> organization number? >>>>> >>>>> I've seen some odd solutions to this problem but nor clean solution. >>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>> organizational attributes >>>>> >>>>> Have anyone else come across this issue? >>>>> How did you solve it? >>>>> Do we need to define a clean attribute for an >>>>>organizationalIdentifier? >>>>> >>>>> /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 >>> >>> >>> >> >> >> > From DPKemp@missi.ncsc.mil Mon Mar 26 14:43:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2D421F8623 for ; Mon, 26 Mar 2012 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+V2NzszLCiL for ; Mon, 26 Mar 2012 14:43:09 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id D23BA21F854F for ; Mon, 26 Mar 2012 14:43:08 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2QLh4XC043162 for ; Mon, 26 Mar 2012 17:43:04 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 17:43:04 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 Mar 2012 17:43:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0LkMmaHJYo28gcTUGy0AEYf97XiQAAHtiw References: <4F70815C.4080105@telia.com> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 26 Mar 2012 21:43:04.0163 (UTC) FILETIME=[6C7CC330:01CD0B99] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 26 Mar 2012 21:43:10 -0000 Who created Example AB's org number? The assigner can't be an example, it has to be a real organization because the schema depends on it. For example, you can't just make up a plausible country code C=3DSWED, you have to know that country codes are defined by ISO-3166, and that the 3166 schema allows only digraphs or trigraphs (e.g. C=3DSE). If you = were making up an example IP address, it would need to fit the IPv4 or IPv6 schema, and 192.578.13 would not be a valid example IP address. There isn't a real "Example AB", but there are four real Ericssons registered with GS1: 7394479000009 Ericsson Network Technologies AB, Stockholm 7311790000006 Ericsson AB, Stockholm 7350050440008 Ericssons Trading AB, Landskrona 7320940000001 Ericssons Preventive Medical Group AB, Tormestorp You could make up an arbitrary Example AB org number, but to be plausible it would need to fit a real schema (which in the case of GS1 is 13 digits). =20 There is no answer to "where do I store it" without first answering "what is it"? Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, March 26, 2012 5:41 PM To: Anders Rundgren Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute CN=3DJohn Doe SN=3DDoe GivenName=3DJohn SERIALNUMBER=3D123456789 (employee number) O=3DExample AB OU=3DExample department C=3DSE Example AB's org number is 555555-5555 Where do I store it? /Stefan On 12-03-26 3:46 PM, "Anders Rundgren" wrote: >Stefan, >I think this discussion would run slightly smother if you provided an=20 >example of a "plausible" DN and how it is supposed to be interpreted. > >Since we are apparently talking about a "community" with strict rules=20 >regarding certificate content, I would still consider using a mandatory >policy OID which says (in an associated document): These are the=20 >mandatory DN attributes and their interpretation. > >I get the feeling (could be completely wrong...) that you are talking=20 >about a DN attribute that has a relation to another DN attribute. I=20 >don't think that would be a very good target for standardization. Does=20 >(for >example) >X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without an O? > >Anders > >On 2012-03-26 17:11, Stefan Santesson wrote: >> Tom, >>=20 >> The PI is a Subject Alternative name. (I.e. name of the Subject) >>=20 >> It works great if the subject is an organization. >> In the discussed case, the subject is a person, so PI does not work. >>=20 >> /Stefan >>=20 >> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >>=20 >>> PI is a valid identifier of an organization, but it doesn't=20 >>>fit in a DN. It's a separate GeneralName. It is perfectly true=20 >>>that there's a PI corresponding to Erwann's example, but most=20 >>>AssignerAuthority values are not defined attributes. We could=20 >>>define an attribute (probably a different OID from the OTHER-NAME=20 >>>one) whose syntax is that of PI, but would it be supported by actual >>>LDAP implementations? >>> >>> Tom Gindin >>> >>> >>> >>> >>> From: Stefan Santesson >>> To: Anders Rundgren , >>> Cc: pkix >>> Date: 03/23/2012 01:52 PM >>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>attribute >>> Sent by: pkix-bounces@ietf.org >>> >>> >>> >>> No, >>> >>> The permanent identifier is an identifier of the subject and is not=20 >>>an attribute. >>> I need an identifier of the subjects organization where the subject=20 >>>is a person. >>> >>> /Stefan >>> >>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>wrote: >>> >>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>> br >>>> ar >>>> >>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>> When a person is associated with an organization in a certificate=20 >>>>> the subjects employee number or alike is often stored in the=20 >>>>> serialNumber attribute. >>>>> >>>>> But where do you store an identifier of the organization? >>>>> That is, not the name stored in organization name, but the=20 >>>>> registered organization number? >>>>> >>>>> I've seen some odd solutions to this problem but nor clean solution. >>>>> X.520 only offer organizationName and orgnizationalUnitName as=20 >>>>> organizational attributes >>>>> >>>>> Have anyone else come across this issue? >>>>> How did you solve it? >>>>> Do we need to define a clean attribute for an=20 >>>>>organizationalIdentifier? >>>>> >>>>> /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 >>> >>> >>> >>=20 >>=20 >>=20 > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From md@e-net.lt Mon Mar 26 18:06:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCCE21F852D for ; Mon, 26 Mar 2012 18:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7warfLG1D0Qg for ; Mon, 26 Mar 2012 18:06:29 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFEA21F852A for ; Mon, 26 Mar 2012 18:06:26 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SCKre-0005yv-Pa; Tue, 27 Mar 2012 04:06:22 +0300 Message-ID: <4F71128E.4050105@e-net.lt> Date: Tue, 27 Mar 2012 04:06:22 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 01:06:31 -0000 On 3/27/2012 12:40 AM, Stefan Santesson wrote: > CN=John Doe > SN=Doe > GivenName=John > SERIALNUMBER=123456789 (employee number) > O=Example AB > OU=Example department > C=SE > > Example AB's org number is 555555-5555 > > Where do I store it? Isn't this a typical RFC 4043 use case? Thanks, M.D. > > /Stefan > > On 12-03-26 3:46 PM, "Anders Rundgren" wrote: > >> Stefan, >> I think this discussion would run slightly smother if you provided an >> example of a "plausible" DN and how it is supposed to be interpreted. >> >> Since we are apparently talking about a "community" with strict rules >> regarding certificate content, I would still consider using a mandatory >> policy OID which says (in an associated document): These are the mandatory >> DN attributes and their interpretation. >> >> I get the feeling (could be completely wrong...) that you are talking >> about a DN attribute that has a relation to another DN attribute. I don't >> think that would be a very good target for standardization. Does (for >> example) >> X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without an O? >> >> Anders >> >> On 2012-03-26 17:11, Stefan Santesson wrote: >>> Tom, >>> >>> The PI is a Subject Alternative name. (I.e. name of the Subject) >>> >>> It works great if the subject is an organization. >>> In the discussed case, the subject is a person, so PI does not work. >>> >>> /Stefan >>> >>> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >>> >>>> PI is a valid identifier of an organization, but it doesn't fit >>>> in >>>> a DN. It's a separate GeneralName. It is perfectly true that there's >>>> a >>>> PI corresponding to Erwann's example, but most AssignerAuthority values >>>> are not defined attributes. We could define an attribute (probably a >>>> different OID from the OTHER-NAME one) whose syntax is that of PI, but >>>> would it be supported by actual LDAP implementations? >>>> >>>> Tom Gindin >>>> >>>> >>>> >>>> >>>> From: Stefan Santesson >>>> To: Anders Rundgren, >>>> Cc: pkix >>>> Date: 03/23/2012 01:52 PM >>>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>> attribute >>>> Sent by: pkix-bounces@ietf.org >>>> >>>> >>>> >>>> No, >>>> >>>> The permanent identifier is an identifier of the subject and is not an >>>> attribute. >>>> I need an identifier of the subjects organization where the subject is >>>> a >>>> person. >>>> >>>> /Stefan >>>> >>>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>> wrote: >>>> >>>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>>> br >>>>> ar >>>>> >>>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>>> When a person is associated with an organization in a certificate the >>>>>> subjects employee number or alike is often stored in the serialNumber >>>>>> attribute. >>>>>> >>>>>> But where do you store an identifier of the organization? >>>>>> That is, not the name stored in organization name, but the registered >>>>>> organization number? >>>>>> >>>>>> I've seen some odd solutions to this problem but nor clean solution. >>>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>>> organizational attributes >>>>>> >>>>>> Have anyone else come across this issue? >>>>>> How did you solve it? >>>>>> Do we need to define a clean attribute for an >>>>>> organizationalIdentifier? >>>>>> >>>>>> /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 From dev+ietf@seantek.com Mon Mar 26 22:13:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143B321F8760 for ; Mon, 26 Mar 2012 22:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyS5dt2vIKEn for ; Mon, 26 Mar 2012 22:13:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 757BF21F84EA for ; Mon, 26 Mar 2012 22:13:31 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 35FDB22E256 for ; Tue, 27 Mar 2012 01:13:30 -0400 (EDT) Message-ID: <4F714C78.4030506@seantek.com> Date: Mon, 26 Mar 2012 22:13:28 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 05:13:37 -0000 On 3/24/2012 3:15 AM, Stefan Santesson wrote: > It's just that there is not even a generic attribute that is suitable f= or > storing an organizational identifier related to the organization named = in > the organizationName attribute (when the subject is a person). > > I could create my own, but I'd rather have a standard one. > Generic is fine. I think the key question is: what does the organization identifier=20 represent? If it is a DUNS number, then it should be something like=20 organizationDUNSNumber=3D123456789 (restricted to NumericString, or=20 PrintableString). If it is a GS1, then it should be=20 organizationGS1GLN=3D.... If it is a number assigned by IANA, it should b= e=20 organizationIANAEnterpriseNumber=3D..., and so forth. I do not see a lot of value in having a generic organizationIdentifier,=20 because the "OI" is ambiguous. It is true that Common Name (CN),=20 Organization Name (O), and Organizational Unit Name (OU) are ambiguous,=20 but that is in the specification. X.520 says: 5.2.2 Common Name: A Common Name is not a directory name; it is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated. 5.4.1 Organization Name ...identifies an organization with which the named object is affiliated= =2E An attribute value for OrganizationName is a string chosen by the organization (e.g., O =3D "Scottish Telecommunications plc"). Any variants should be associated with the named Organization as separate and alternative attribute values. 5.4.2 Organizational Unit Name ...identifies an organizational unit with which the named object is affiliated. An attribute value for Organizational Unit Name is a string chosen by the organization of which it is part (e.g., OU =3D "Technology Division"). Note that the commonly used abbreviation "TD" would be a separate and alternative attribute value. The point of the "Name" types is to present a (possibly ambiguous)=20 string to a mythical "relying party", in a way that makes sense,=20 "conform[ing] to the naming conventions of the country or culture with=20 which it is associated". Aka, string for human user to read. But the=20 point of an identifier--at least as Stefan has requested--is to furnish=20 an *unambiguous* identifier. It is ambiguous if you say=20 organizationalIdentifier=3D081466849, but unambiguous if you say=20 organizationDUNSNumber=3D081466849. Basically, you are incorporating the = naming authority into the attribute type (as Tim hinted). You could create a general organizationIdentifier attribute, that has=20 the same overall syntax of id-on-permanentIdentifer, namely: SEQUENCE { identifierValue UTF8String, assigner OBJECT IDENTIFIER } However, a non-trivial fraction of certificate-processing code behaves=20 very badly when confronted with an attribute in a DN that is not a=20 DirectoryString, or at least a UNIVERSAL type. For example, OpenSSL will = likely barf on it. Interestingly, it would be standards-y to define organizationIdentifier=20 as OBJECT IDENTIFIER. As Dave said, you could have=20 organizationIdentifier=3D1.3.60.81466849, which represents the=20 organization's DUNS Number. You could also have=20 organizationIdentifier=3D1.3.6.1.4.1.311 in the same DN, since the IANA=20 Enterprise Number is assigned to the same entity (Microsoft Corporation) = as the DUNS Number. The only real downsides of this approach are that it is "unusual" to put = an OBJECT IDENTIFIER in an attribute value that most=20 certificate-processing code is supposed to process, and OBJECT=20 IDENTIFIER arcs have to define a mapping from the identifier to an=20 integer value. Yet since OBJECT IDENTIFIER is a UNIVERSAL type, it's not = particularly complicated to support, and it's super-compact compared to=20 the alternatives. X.520 defines no less than 10 attributes that are of=20 type OBJECT IDENTIFIER, so there is a strong argument that if you=20 support X.520 types in general, you should be supporting OBJECT=20 IDENTIFIER as a value anyway (as opposed to some arbitrary SEQUENCE that = didn't exist until 2012). There is not much to say about the "mapping to an integer value"=20 problem. If the identifiers are integral, then you're done. If they are=20 not, the maintainer of the OID arc is supposed to figure out the=20 mapping. This pushes off the problem to the OID system, which is=20 probably a better place to handle the delegation of authority in the=20 first place. Sean > > /Stefan > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From Scott@Digicert.com Tue Mar 27 00:32:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0630721F847F for ; Tue, 27 Mar 2012 00:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY-cOONvnN6B for ; Tue, 27 Mar 2012 00:32:06 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 108C121F84F1 for ; Tue, 27 Mar 2012 00:32:06 -0700 (PDT) Received: from [10.211.55.9] (unknown [64.78.193.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 38EFC8FA13E for ; Tue, 27 Mar 2012 01:32:05 -0600 (MDT) Message-ID: <4F716CF3.8060903@Digicert.com> Date: Tue, 27 Mar 2012 01:32:03 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:32:07 -0000 If the issue with the responder cert is not clear in respect to CA rollover, and it really is expected to follow existing path processing from 5280, I am not sure that the proposed text presented just now accomplishes that... why would we just not say that the responder cert should be issued by the same trust anchor that the subject cert of the OCSP request chains to. Hence if the EE cert now chains to a rolled over CA cert, then the responder cert should be issued by that same rolled over CA cert - yes? Regards, -- Scott Rea From turners@ieca.com Tue Mar 27 02:25:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4942E21F896E for ; Tue, 27 Mar 2012 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbBpIc0-XgrA for ; Tue, 27 Mar 2012 02:25:07 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.81.23]) by ietfa.amsl.com (Postfix) with ESMTP id D428121F896D for ; Tue, 27 Mar 2012 02:25:07 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 73D67209E8EA4; Tue, 27 Mar 2012 04:25:07 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 68813209E8E7B for ; Tue, 27 Mar 2012 04:25:07 -0500 (CDT) Received: from [198.180.150.230] (port=54280 helo=dhcp-17e9.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SCSeJ-0005Te-6V for pkix@ietf.org; Tue, 27 Mar 2012 04:25:07 -0500 Message-ID: <4F718771.6060906@ieca.com> Date: Tue, 27 Mar 2012 11:25:05 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (dhcp-17e9.meeting.ietf.org) [198.180.150.230]:54280 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 09:25:08 -0000 Just a couple of comments the WG should consider: Technical: 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s for the request and return the certificate(s) in a mime media type. In many instances, the "normal" query/response for a certificate is a PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the degenerate certs-only message. Does anyone see any benefit in reusing the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it would align nicely/exactly with the simple PKI request/response from CMC. 2. in s5.6.2, just use application/pkcs8 instead of application/pkix-privkey. Not so technical: 1. appendix D really ought to be in its own document or in part of draft-nourse-scep. spt From kent@bbn.com Tue Mar 27 03:04:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94321F8810 for ; Tue, 27 Mar 2012 03:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UprxMvGRhx8 for ; Tue, 27 Mar 2012 03:04:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 839E021F88C0 for ; Tue, 27 Mar 2012 03:04:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33242 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCTGJ-000HBm-IK for pkix@ietf.org; Tue, 27 Mar 2012 06:04:24 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 27 Mar 2012 06:04:34 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] minutes posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:04:38 -0000 Minutes have been uploaded: http://www.ietf.org/proceedings/83/minutes/minutes-83-pkix.pdf Please provide comments/corrections to me over the next two weeks. Thanks, Steve From stefan@aaa-sec.com Tue Mar 27 03:17:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02B921F880E for ; Tue, 27 Mar 2012 03:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.249 X-Spam-Level: X-Spam-Status: No, score=-100.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3ZTaw3CwT3A for ; Tue, 27 Mar 2012 03:17:36 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6F10121F8803 for ; Tue, 27 Mar 2012 03:17:34 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 4FB9F1DE4ADE for ; Tue, 27 Mar 2012 12:17:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qUAtRKY7fc80 for ; Tue, 27 Mar 2012 12:17:30 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B72E71DE07A5 for ; Tue, 27 Mar 2012 12:17:30 +0200 (CEST) Received: (qmail 53692 invoked from network); 27 Mar 2012 10:17:30 -0000 Received: from dhcp-1122.meeting.ietf.org (HELO [130.129.17.34]) (stefan@fiddler.nu@[130.129.17.34]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Mar 2012 10:17:30 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 27 Mar 2012 12:17:26 +0100 From: Stefan Santesson To: "Moudrick M. Dadashov" Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F71128E.4050105@e-net.lt> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 10:17:37 -0000 No, Saying this again. A subject Alternative name is an alternative name of the SUBJECT. Example AB's org number is NOT an alternative name of the subject. The subject is John Doe and not Example AB. Example AB is the subjects organization, but not the subject. /Stefan On 12-03-27 2:06 AM, "Moudrick M. Dadashov" wrote: >On 3/27/2012 12:40 AM, Stefan Santesson wrote: >> CN=John Doe >> SN=Doe >> GivenName=John >> SERIALNUMBER=123456789 (employee number) >> O=Example AB >> OU=Example department >> C=SE >> >> Example AB's org number is 555555-5555 >> >> Where do I store it? >Isn't this a typical RFC 4043 use case? > >Thanks, >M.D. > > >> >> /Stefan >> >> On 12-03-26 3:46 PM, "Anders Rundgren" >>wrote: >> >>> Stefan, >>> I think this discussion would run slightly smother if you provided an >>> example of a "plausible" DN and how it is supposed to be interpreted. >>> >>> Since we are apparently talking about a "community" with strict rules >>> regarding certificate content, I would still consider using a mandatory >>> policy OID which says (in an associated document): These are the >>>mandatory >>> DN attributes and their interpretation. >>> >>> I get the feeling (could be completely wrong...) that you are talking >>> about a DN attribute that has a relation to another DN attribute. I >>>don't >>> think that would be a very good target for standardization. Does (for >>> example) >>> X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without >>>an O? >>> >>> Anders >>> >>> On 2012-03-26 17:11, Stefan Santesson wrote: >>>> Tom, >>>> >>>> The PI is a Subject Alternative name. (I.e. name of the Subject) >>>> >>>> It works great if the subject is an organization. >>>> In the discussed case, the subject is a person, so PI does not work. >>>> >>>> /Stefan >>>> >>>> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >>>> >>>>> PI is a valid identifier of an organization, but it doesn't >>>>>fit >>>>> in >>>>> a DN. It's a separate GeneralName. It is perfectly true that >>>>>there's >>>>> a >>>>> PI corresponding to Erwann's example, but most AssignerAuthority >>>>>values >>>>> are not defined attributes. We could define an attribute (probably a >>>>> different OID from the OTHER-NAME one) whose syntax is that of PI, >>>>>but >>>>> would it be supported by actual LDAP implementations? >>>>> >>>>> Tom Gindin >>>>> >>>>> >>>>> >>>>> >>>>> From: Stefan Santesson >>>>> To: Anders Rundgren, >>>>> Cc: pkix >>>>> Date: 03/23/2012 01:52 PM >>>>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>>> attribute >>>>> Sent by: pkix-bounces@ietf.org >>>>> >>>>> >>>>> >>>>> No, >>>>> >>>>> The permanent identifier is an identifier of the subject and is not >>>>>an >>>>> attribute. >>>>> I need an identifier of the subjects organization where the subject >>>>>is >>>>> a >>>>> person. >>>>> >>>>> /Stefan >>>>> >>>>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>>> wrote: >>>>> >>>>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>>>> br >>>>>> ar >>>>>> >>>>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>>>> When a person is associated with an organization in a certificate >>>>>>>the >>>>>>> subjects employee number or alike is often stored in the >>>>>>>serialNumber >>>>>>> attribute. >>>>>>> >>>>>>> But where do you store an identifier of the organization? >>>>>>> That is, not the name stored in organization name, but the >>>>>>>registered >>>>>>> organization number? >>>>>>> >>>>>>> I've seen some odd solutions to this problem but nor clean >>>>>>>solution. >>>>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>>>> organizational attributes >>>>>>> >>>>>>> Have anyone else come across this issue? >>>>>>> How did you solve it? >>>>>>> Do we need to define a clean attribute for an >>>>>>> organizationalIdentifier? >>>>>>> >>>>>>> /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 > From kent@bbn.com Tue Mar 27 03:18:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F1A21E814A for ; Tue, 27 Mar 2012 03:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.388 X-Spam-Level: X-Spam-Status: No, score=-106.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c07tFFH0WnMF for ; Tue, 27 Mar 2012 03:18:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 958F321E8143 for ; Tue, 27 Mar 2012 03:18:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49755 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCTTy-000HM1-Iq; Tue, 27 Mar 2012 06:18:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4489D8E8-8CC8-4842-BA15-0C66C193BAFF@jpl.nasa.gov> References: <4489D8E8-8CC8-4842-BA15-0C66C193BAFF@jpl.nasa.gov> Date: Tue, 27 Mar 2012 06:18:41 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] too many negatives ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 10:18:45 -0000 At 11:14 AM -0700 3/26/12, Henry B. Hotz wrote: >"not inconsistent" means "consistent"? ;-) not necessarily. "Consistent" is a simple, positive assertion. "Not inconsistent" leaves a lot of wiggle room. Steve From anders.rundgren@telia.com Tue Mar 27 03:49:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525621F8975 for ; Tue, 27 Mar 2012 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vux7urfPJUv for ; Tue, 27 Mar 2012 03:49:38 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6521F896B for ; Tue, 27 Mar 2012 03:49:37 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D00468D87; Tue, 27 Mar 2012 12:49:34 +0200 Message-ID: <4F719B3D.10101@telia.com> Date: Tue, 27 Mar 2012 12:49:33 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Sean Turner References: <4F718771.6060906@ieca.com> In-Reply-To: <4F718771.6060906@ieca.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 10:49:38 -0000 Continuing this thread... >From the abstract I would be interested in hearing what "simple Public Key Infrastructure clients" actually refer to. "This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol" If you combine all the options, it is not that simple anymore. Is a client and server assumed to support all the options? If not, how are they supposed to know which subset that can be used? Looks like a rather configuration-dependent scheme IMHO. "K1 "Algorithm agility". The protocol MUST support algorithm agility" The author's opinion on what that means is flawed. Although supporting a bunch of TLS ciphers may be interesting, algorithm agility regarding generated keys is a parameter that most (if not all) issuers care about. "5.3 Distribution of CA certificates Before engaging in enrollment operations, clients MUST request trust anchor information (in the form of certificates) by sending an HTTPS GET message to the EST base URI with the relative path extension '/CACerts'" This mandatory requirement isn't particularly universal. A more common method is that the user rather gets an option "accepting" the root of the distributed certificate path. In today's server-centric world the CA of a *client certificate* often doesn't have any meaning for the client/user at all. Anders PS. By thinking out loud I got an idea for KeyGen2! Add an option to the install certificate part of the protocol where the issuer may claim that this root may be of interest to user. By doing that KeyGen2 doesn't have to bother users with (for example) accepting VISA's EMV-root since this a thing for the merchants/acquirers to care about. DS. On 2012-03-27 11:25, Sean Turner wrote: > Just a couple of comments the WG should consider: > > Technical: > > 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s > for the request and return the certificate(s) in a mime media type. In > many instances, the "normal" query/response for a certificate is a > PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the > degenerate certs-only message. Does anyone see any benefit in reusing > the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it > would align nicely/exactly with the simple PKI request/response from CMC. > > 2. in s5.6.2, just use application/pkcs8 instead of > application/pkix-privkey. > > Not so technical: > > 1. appendix D really ought to be in its own document or in part of > draft-nourse-scep. > > spt > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From tgindin@us.ibm.com Tue Mar 27 05:04:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4B721E81BB for ; Tue, 27 Mar 2012 05:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.16 X-Spam-Level: X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xZ0ACSd09D5 for ; Tue, 27 Mar 2012 05:04:30 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 00DA621E819D for ; Tue, 27 Mar 2012 05:04:29 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Mar 2012 06:04:28 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 Mar 2012 06:04:17 -0600 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 08233C90062 for ; Tue, 27 Mar 2012 08:04:16 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2RC4Gwn251906 for ; Tue, 27 Mar 2012 08:04:16 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2RHZ8tG010055 for ; Tue, 27 Mar 2012 13:35:08 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2RHZ8oC010050; Tue, 27 Mar 2012 13:35:08 -0400 In-Reply-To: References: To: Stefan Santesson MIME-Version: 1.0 X-KeepSent: E69AC9F4:FD1C182E-852579CE:0041CAF5; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 27 Mar 2012 08:04:15 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/27/2012 08:04:15, Serialize complete at 03/27/2012 08:04:15 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12032712-7408-0000-0000-000003BE4E3B Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 12:04:30 -0000 Stefan: I believe that a typical OTHER-NAME could be used in IssuerAltName as well as in Subject, so your insistence that PI is a Subject AltName isn't relevant. In the particular case of PI, the AssignerAuthority alone is an organization. Thus, it might well make sense to define an Organizational ID directory attribute with Object Identifier as its value syntax. It might make sense instead to define an attribute for each typical ICD root such as DUNS number or GS1 with a value syntax of NumericString. Tom Gindin From: Stefan Santesson To: Tom Gindin/Watson/IBM@IBMUS, Cc: Anders Rundgren , pkix Date: 03/26/2012 10:12 AM Subject: Re: [pkix] Need for an organizationalIdentifier attribute Tom, The PI is a Subject Alternative name. (I.e. name of the Subject) It works great if the subject is an organization. In the discussed case, the subject is a person, so PI does not work. /Stefan On 12-03-26 2:47 PM, "Tom Gindin" wrote: > PI is a valid identifier of an organization, but it doesn't fit >in >a DN. It's a separate GeneralName. It is perfectly true that there's a >PI corresponding to Erwann's example, but most AssignerAuthority values >are not defined attributes. We could define an attribute (probably a >different OID from the OTHER-NAME one) whose syntax is that of PI, but >would it be supported by actual LDAP implementations? > >Tom Gindin > > > > >From: Stefan Santesson >To: Anders Rundgren , >Cc: pkix >Date: 03/23/2012 01:52 PM >Subject: Re: [pkix] Need for an organizationalIdentifier attribute >Sent by: pkix-bounces@ietf.org > > > >No, > >The permanent identifier is an identifier of the subject and is not an >attribute. >I need an identifier of the subjects organization where the subject is a >person. > >/Stefan > >On 12-03-23 6:35 PM, "Anders Rundgren" wrote: > >>http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>br >>ar >> >>On 2012-03-23 18:13, Stefan Santesson wrote: >>> When a person is associated with an organization in a certificate the >>>subjects employee number or alike is often stored in the serialNumber >>>attribute. >>> >>> But where do you store an identifier of the organization? >>> That is, not the name stored in organization name, but the registered >>>organization number? >>> >>> I've seen some odd solutions to this problem but nor clean solution. >>> X.520 only offer organizationName and orgnizationalUnitName as >>>organizational attributes >>> >>> Have anyone else come across this issue? >>> How did you solve it? >>> Do we need to define a clean attribute for an organizationalIdentifier? >>> >>> /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 > > > From SChokhani@cygnacom.com Tue Mar 27 06:32:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E867921F8891 for ; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7+M2A9BsBnO for ; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 464E021F887E for ; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,657,1325480400"; d="scan'208";a="640840" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 27 Mar 2012 09:32:41 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 27 Mar 2012 09:32:41 -0400 From: Santosh Chokhani To: Scott Rea , "pkix@ietf.org" Date: Tue, 27 Mar 2012 09:32:39 -0400 Thread-Topic: [pkix] 2560bis Thread-Index: Ac0L6777jTvNCkplShWjdXRkOtvGQwAMd3bQ Message-ID: References: <4F716CF3.8060903@Digicert.com> In-Reply-To: <4F716CF3.8060903@Digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:32:55 -0000 There is a difference of opinion on this one. In my reading 2560 is reasonably clear that the same CA Signing private key= must be used to sign the Responder certificate as the certificate in quest= ion. This offers the crypto binding and provides all three: high degree of= security, reduced software complexity for the OCSP client, and reduced com= putational complexity for the OCSP client. Now, when do you get all three? I do not buy the text in draft bis 2560. That is taking liberty with the i= ntent of 2560 and reducing security and/or adding complexity. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Sco= tt Rea Sent: Tuesday, March 27, 2012 3:32 AM To: pkix@ietf.org Subject: [pkix] 2560bis If the issue with the responder cert is not clear in respect to CA rollover= , and it really is expected to follow existing path processing from 5280, I= am not sure that the proposed text presented just now accomplishes that... why would we just not say that the responder cert should be issued by the s= ame trust anchor that the subject cert of the OCSP request chains to. Hence= if the EE cert now chains to a rolled over CA cert, then the responder cer= t should be issued by that same rolled over CA cert - yes? Regards, -- Scott Rea _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mmyers@fastq.com Tue Mar 27 06:48:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD2021F89F7 for ; Tue, 27 Mar 2012 06:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8QYIA16msDV for ; Tue, 27 Mar 2012 06:48:52 -0700 (PDT) Received: from mailout.fastq.com (postal.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5AB21F890F for ; Tue, 27 Mar 2012 06:48:52 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q2RDmKj3012682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 06:48:22 -0700 Message-Id: <271DF0A8-F951-4CE3-9CC9-5F05EC84975F@fastq.com> From: Michael Myers To: Santosh Chokhani In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Mar 2012 06:54:00 -0700 References: <4F716CF3.8060903@Digicert.com> X-Mailer: Apple Mail (2.936) Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:48:53 -0000 On Mar 27, 2012, at 6:32 AM, Santosh Chokhani wrote: > In my reading 2560 is reasonably clear that the same CA Signing > private key must be used to sign the Responder certificate as the > certificate in question. No, not "must". N.B. section '2.2 Response': -- a Trusted Responder whose public key is trusted by the requester Mike From denis.pinkas@bull.net Tue Mar 27 07:04:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A261421E8202 for ; Tue, 27 Mar 2012 07:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1m+K5MkYRW3 for ; Tue, 27 Mar 2012 07:04:03 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id CC53521E81F7 for ; Tue, 27 Mar 2012 07:04:02 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id E75621814A; Tue, 27 Mar 2012 16:04:00 +0200 (CEST) In-Reply-To: References: <4F716CF3.8060903@Digicert.com> To: Santosh Chokhani MIME-Version: 1.0 X-KeepSent: 17B0D17A:15562340-C12579CE:004C8E01; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 27 Mar 2012 16:04:00 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 27/03/2012 16:04:00, Serialize complete at 27/03/2012 16:04:00 Content-Type: multipart/alternative; boundary="=_alternative 004D2D57C12579CE_=" Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:04:03 -0000 Message en plusieurs parties au format MIME --=_alternative 004D2D57C12579CE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Santosh, We are on the same track. This is one of the issues I presented this=20 morning at the meeting.=20 There are some other issues.=20 Please, take a look at the slides:=20 http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf Denis De : Santosh Chokhani A : Scott Rea , "pkix@ietf.org" Date : 27/03/2012 15:33 Objet : Re: [pkix] 2560bis Envoy=E9 par : pkix-bounces@ietf.org There is a difference of opinion on this one. In my reading 2560 is reasonably clear that the same CA Signing private=20 key must be used to sign the Responder certificate as the certificate in=20 question. This offers the crypto binding and provides all three: high=20 degree of security, reduced software complexity for the OCSP client, and=20 reduced computational complexity for the OCSP client. Now, when do you=20 get all three? I do not buy the text in draft bis 2560. That is taking liberty with the=20 intent of 2560 and reducing security and/or adding complexity. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 Scott Rea Sent: Tuesday, March 27, 2012 3:32 AM To: pkix@ietf.org Subject: [pkix] 2560bis If the issue with the responder cert is not clear in respect to CA=20 rollover, and it really is expected to follow existing path processing=20 from 5280, I am not sure that the proposed text presented just now=20 accomplishes that... why would we just not say that the responder cert should be issued by the=20 same trust anchor that the subject cert of the OCSP request chains to.=20 Hence if the EE cert now chains to a rolled over CA cert, then the=20 responder cert should be issued by that same rolled over CA cert - yes? Regards, -- Scott Rea =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004D2D57C12579CE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Santosh,

We are on the same track. This is one of the issues I presented this morning at the meeting.
There are some other issues.

Please, take a look at the slides: <= /font>http://www.ietf.org/proceedings/83= /slides/slides-83-pkix-4.pdf

Denis




De :     &= nbsp;  Santosh Chokhani <SChokh= ani@cygnacom.com>
A :     &n= bsp;  Scott Rea <Scott@Digicer= t.com>, "pkix@ietf.org" <pkix@ietf.org>
Date :    =    27/03/2012 15:33
Objet :        Re: [pkix] 2560bis
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



There is a difference of opinion on this one.

In my reading 2560 is reasonably clear that the same CA Signing private key must be used to sign the Responder certificate as the certificate in question.  This offers the crypto binding and provides all three: high degree of security, reduced software complexity for the OCSP client, and reduced computational complexity for the OCSP client.  Now, when do you get all three?

I do not buy the text in draft bis 2560.  That is taking liberty with the intent of 2560 and reducing security and/or adding complexity.

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org<= font size=3D2>] On Behalf Of Scott Rea
Sent: Tuesday, March 27, 2012 3:32 AM
To: pkix@ietf.org
Subject: [pkix] 2560bis

If the issue with the responder cert is not clear in respect to CA rollover, and it really is expected to follow existing path processing from 5280, I am not sure that the proposed text presented just now accomplishes that..= .
why would we just not say that the responder cert should be issued by the same trust anchor that the subject cert of the OCSP request chains to. Hence if the EE cert now chains to a rolled over CA cert, then the responder cert should be issued by that same rolled over CA cert - yes?
Regards,

--
Scott Rea

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 004D2D57C12579CE_=-- From SChokhani@cygnacom.com Tue Mar 27 07:04:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12221E8205 for ; Tue, 27 Mar 2012 07:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvUO91cDkLMx for ; Tue, 27 Mar 2012 07:04:14 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0702A21E8206 for ; Tue, 27 Mar 2012 07:04:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,657,1325480400"; d="scan'208";a="641185" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 27 Mar 2012 10:04:13 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 27 Mar 2012 10:04:13 -0400 From: Santosh Chokhani To: Michael Myers Date: Tue, 27 Mar 2012 10:04:12 -0400 Thread-Topic: [pkix] 2560bis Thread-Index: Ac0MIFS2+FqsOBchTL2FgUXwoy7GXgAAhKWA Message-ID: References: <4F716CF3.8060903@Digicert.com> <271DF0A8-F951-4CE3-9CC9-5F05EC84975F@fastq.com> In-Reply-To: <271DF0A8-F951-4CE3-9CC9-5F05EC84975F@fastq.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:04:14 -0000 Mike, My comment was in the context of one of the three models: Delegated/Designa= ted. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com]=20 Sent: Tuesday, March 27, 2012 9:54 AM To: Santosh Chokhani Cc: Scott Rea; pkix@ietf.org Subject: Re: [pkix] 2560bis On Mar 27, 2012, at 6:32 AM, Santosh Chokhani wrote: > In my reading 2560 is reasonably clear that the same CA Signing=20 > private key must be used to sign the Responder certificate as the=20 > certificate in question. No, not "must". N.B. section '2.2 Response': -- a Trusted Responder whose public key is trusted by the requester Mike From stefan@aaa-sec.com Tue Mar 27 07:32:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84C21F8523 for ; Tue, 27 Mar 2012 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.749 X-Spam-Level: X-Spam-Status: No, score=-101.749 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTkWWxmJcs4W for ; Tue, 27 Mar 2012 07:32:13 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16A21F8738 for ; Tue, 27 Mar 2012 07:32:12 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7CE911DE30F3 for ; Tue, 27 Mar 2012 16:31:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IEOyvjUG-5Km for ; Tue, 27 Mar 2012 16:31:43 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3C0EA1DE30D0 for ; Tue, 27 Mar 2012 16:31:43 +0200 (CEST) Received: (qmail 77497 invoked from network); 27 Mar 2012 14:31:40 -0000 Received: from dhcp-1122.meeting.ietf.org (HELO [130.129.17.34]) (stefan@fiddler.nu@[130.129.17.34]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Mar 2012 14:31:40 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 27 Mar 2012 16:31:35 +0100 From: Stefan Santesson To: Santosh Chokhani , Michael Myers Message-ID: Thread-Topic: [pkix] 2560bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:32:14 -0000 I'm in agreement with you Santosh. I think we seen enough rough consensus on this list and in the meeting today to change the current text in rfc2560bis to reflect what you say. /Stefan On 12-03-27 3:04 PM, "Santosh Chokhani" wrote: >Mike, > >My comment was in the context of one of the three models: >Delegated/Designated. > >-----Original Message----- >From: Michael Myers [mailto:mmyers@fastq.com] >Sent: Tuesday, March 27, 2012 9:54 AM >To: Santosh Chokhani >Cc: Scott Rea; pkix@ietf.org >Subject: Re: [pkix] 2560bis > >On Mar 27, 2012, at 6:32 AM, Santosh Chokhani wrote: > >> In my reading 2560 is reasonably clear that the same CA Signing >> private key must be used to sign the Responder certificate as the >> certificate in question. > >No, not "must". N.B. section '2.2 Response': > >-- a Trusted Responder whose public key is trusted by the requester > >Mike > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Tue Mar 27 07:50:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F39521E8197 for ; Tue, 27 Mar 2012 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[AWL=-1.762, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWHhIlYu7GTx for ; Tue, 27 Mar 2012 07:50:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA49221F867E for ; Tue, 27 Mar 2012 07:50:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 838EB21B0E08; Tue, 27 Mar 2012 10:50:02 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A10021B0D02; Tue, 27 Mar 2012 10:50:02 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 10:50:02 -0400 From: "Miller, Timothy J." To: Stefan Santesson Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAA== Date: Tue, 27 Mar 2012 14:50:01 +0000 Message-ID: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.40.40] Content-Type: multipart/signed; boundary="Apple-Mail=_895C7146-93B9-4E61-8A35-1947E14E0D0B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 14:50:14 -0000 --Apple-Mail=_895C7146-93B9-4E61-8A35-1947E14E0D0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It seems to me that this is the whole reason why multi-valued RDNs are = permitted in the first place. I.e., Stefan's example could be solved as: CN=3DJohn Doe\SERIALNUMBER=3D123456789 OU=3DExample Department O=3DExample AB\ORGIDTYPEANDVALUE=3D1.3.6.1.4.1.519.1;987654321 Of course, multi-value RDNs are a whole different can'o'worms. -- T On Mar 27, 2012, at 6:17 AM, Stefan Santesson wrote: > No, >=20 > Saying this again. > A subject Alternative name is an alternative name of the SUBJECT. >=20 > Example AB's org number is NOT an alternative name of the subject. >=20 > The subject is John Doe and not Example AB. > Example AB is the subjects organization, but not the subject. >=20 > /Stefan >=20 > On 12-03-27 2:06 AM, "Moudrick M. Dadashov" wrote: >=20 >> On 3/27/2012 12:40 AM, Stefan Santesson wrote: >>> CN=3DJohn Doe >>> SN=3DDoe >>> GivenName=3DJohn >>> SERIALNUMBER=3D123456789 (employee number) >>> O=3DExample AB >>> OU=3DExample department >>> C=3DSE >>>=20 >>> Example AB's org number is 555555-5555 >>>=20 >>> Where do I store it? >> Isn't this a typical RFC 4043 use case? >>=20 >> Thanks, >> M.D. >>=20 >>=20 >>>=20 >>> /Stefan >>>=20 >>> On 12-03-26 3:46 PM, "Anders Rundgren" >>> wrote: >>>=20 >>>> Stefan, >>>> I think this discussion would run slightly smother if you provided = an >>>> example of a "plausible" DN and how it is supposed to be = interpreted. >>>>=20 >>>> Since we are apparently talking about a "community" with strict = rules >>>> regarding certificate content, I would still consider using a = mandatory >>>> policy OID which says (in an associated document): These are the >>>> mandatory >>>> DN attributes and their interpretation. >>>>=20 >>>> I get the feeling (could be completely wrong...) that you are = talking >>>> about a DN attribute that has a relation to another DN attribute. = I >>>> don't >>>> think that would be a very good target for standardization. Does = (for >>>> example) >>>> X.520, X.509, or RFC5280 actually disallow DNs with OUs, but = without >>>> an O? >>>>=20 >>>> Anders >>>>=20 >>>> On 2012-03-26 17:11, Stefan Santesson wrote: >>>>> Tom, >>>>>=20 >>>>> The PI is a Subject Alternative name. (I.e. name of the Subject) >>>>>=20 >>>>> It works great if the subject is an organization. >>>>> In the discussed case, the subject is a person, so PI does not = work. >>>>>=20 >>>>> /Stefan >>>>>=20 >>>>> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >>>>>=20 >>>>>> PI is a valid identifier of an organization, but it = doesn't >>>>>> fit >>>>>> in >>>>>> a DN. It's a separate GeneralName. It is perfectly true that >>>>>> there's >>>>>> a >>>>>> PI corresponding to Erwann's example, but most AssignerAuthority >>>>>> values >>>>>> are not defined attributes. We could define an attribute = (probably a >>>>>> different OID from the OTHER-NAME one) whose syntax is that of = PI, >>>>>> but >>>>>> would it be supported by actual LDAP implementations? >>>>>>=20 >>>>>> Tom Gindin >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Stefan Santesson >>>>>> To: Anders Rundgren, >>>>>> Cc: pkix >>>>>> Date: 03/23/2012 01:52 PM >>>>>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>>>> attribute >>>>>> Sent by: pkix-bounces@ietf.org >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> No, >>>>>>=20 >>>>>> The permanent identifier is an identifier of the subject and is = not >>>>>> an >>>>>> attribute. >>>>>> I need an identifier of the subjects organization where the = subject >>>>>> is >>>>>> a >>>>>> person. >>>>>>=20 >>>>>> /Stefan >>>>>>=20 >>>>>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>>>> wrote: >>>>>>=20 >>>>>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>>>>> br >>>>>>> ar >>>>>>>=20 >>>>>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>>>>> When a person is associated with an organization in a = certificate >>>>>>>> the >>>>>>>> subjects employee number or alike is often stored in the >>>>>>>> serialNumber >>>>>>>> attribute. >>>>>>>>=20 >>>>>>>> But where do you store an identifier of the organization? >>>>>>>> That is, not the name stored in organization name, but the >>>>>>>> registered >>>>>>>> organization number? >>>>>>>>=20 >>>>>>>> I've seen some odd solutions to this problem but nor clean >>>>>>>> solution. >>>>>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>>>>> organizational attributes >>>>>>>>=20 >>>>>>>> Have anyone else come across this issue? >>>>>>>> How did you solve it? >>>>>>>> Do we need to define a clean attribute for an >>>>>>>> organizationalIdentifier? >>>>>>>>=20 >>>>>>>> /Stefan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> pkix mailing list >>>>>>>> pkix@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>> _______________________________________________ >>>>>>> pkix mailing list >>>>>>> pkix@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>=20 >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>=20 >>>>>>=20 >>>>>>=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 --Apple-Mail=_895C7146-93B9-4E61-8A35-1947E14E0D0B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMjAzMjcxNDUwMDFaMCMGCSqGSIb3DQEJBDEWBBSDBfSVLqa2mNZ5/iPy bnJCjVEDiTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgKc+HtMM06dwW+nzaAduC+SS0q8mUAO50RYP cDbhMCPHCqq5XCCRXuR4l65o3gJQ2FA9iNj6ivWGmnHC7MuI3A3s3ZtXydDff28YaadCcG5RA06w d3So/idLE6LL6nTyh4sCx4hhXF1n37Ys2Pnn4iVStOGdPIf3uiNWHmJ5i3a6AAAAAAAA --Apple-Mail=_895C7146-93B9-4E61-8A35-1947E14E0D0B-- From tmiller@mitre.org Tue Mar 27 07:56:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07E21E821E for ; Tue, 27 Mar 2012 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=-1.720, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd-w0ZGfiFCk for ; Tue, 27 Mar 2012 07:56:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 956C521E8217 for ; Tue, 27 Mar 2012 07:56:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F194A21B1663; Tue, 27 Mar 2012 10:56:36 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E3BC521B0B57; Tue, 27 Mar 2012 10:56:36 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 10:56:36 -0400 From: "Miller, Timothy J." To: Stefan Santesson Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAIAAAdgA Date: Tue, 27 Mar 2012 14:56:36 +0000 Message-ID: <4094ACDF-B815-4FFA-8250-2F5848B78163@mitre.org> References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> In-Reply-To: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.40.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <494B4B414AE1AD45B9788B507754EF12@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 14:56:39 -0000 Alternatively, if SAN is inappropriate, Subject Directory Attributes could = carry the Org ID type and value. One can certainly argue that my org is an= attribute of me. :) (BTW, ignore the signature on my last; damn Apple Mail is smart enough to k= now that cert us revoked, but too dumb to refuse to sign with it, and defau= lts the signing button to last selected value. I mean, really?) -- T On Mar 27, 2012, at 9:50 AM, Miller, Timothy J. wrote: > It seems to me that this is the whole reason why multi-valued RDNs are pe= rmitted in the first place. >=20 > I.e., Stefan's example could be solved as: >=20 > CN=3DJohn Doe\SERIALNUMBER=3D123456789 > OU=3DExample Department > O=3DExample AB\ORGIDTYPEANDVALUE=3D1.3.6.1.4.1.519.1;987654321 >=20 > Of course, multi-value RDNs are a whole different can'o'worms. >=20 > -- T >=20 > On Mar 27, 2012, at 6:17 AM, Stefan Santesson wrote: >=20 >> No, >>=20 >> Saying this again. >> A subject Alternative name is an alternative name of the SUBJECT. >>=20 >> Example AB's org number is NOT an alternative name of the subject. >>=20 >> The subject is John Doe and not Example AB. >> Example AB is the subjects organization, but not the subject. >>=20 >> /Stefan >>=20 >> On 12-03-27 2:06 AM, "Moudrick M. Dadashov" wrote: >>=20 >>> On 3/27/2012 12:40 AM, Stefan Santesson wrote: >>>> CN=3DJohn Doe >>>> SN=3DDoe >>>> GivenName=3DJohn >>>> SERIALNUMBER=3D123456789 (employee number) >>>> O=3DExample AB >>>> OU=3DExample department >>>> C=3DSE >>>>=20 >>>> Example AB's org number is 555555-5555 >>>>=20 >>>> Where do I store it? >>> Isn't this a typical RFC 4043 use case? >>>=20 >>> Thanks, >>> M.D. >>>=20 >>>=20 >>>>=20 >>>> /Stefan >>>>=20 >>>> On 12-03-26 3:46 PM, "Anders Rundgren" >>>> wrote: >>>>=20 >>>>> Stefan, >>>>> I think this discussion would run slightly smother if you provided an >>>>> example of a "plausible" DN and how it is supposed to be interpreted. >>>>>=20 >>>>> Since we are apparently talking about a "community" with strict rules >>>>> regarding certificate content, I would still consider using a mandato= ry >>>>> policy OID which says (in an associated document): These are the >>>>> mandatory >>>>> DN attributes and their interpretation. >>>>>=20 >>>>> I get the feeling (could be completely wrong...) that you are talking >>>>> about a DN attribute that has a relation to another DN attribute. I >>>>> don't >>>>> think that would be a very good target for standardization. Does (for >>>>> example) >>>>> X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without >>>>> an O? >>>>>=20 >>>>> Anders >>>>>=20 >>>>> On 2012-03-26 17:11, Stefan Santesson wrote: >>>>>> Tom, >>>>>>=20 >>>>>> The PI is a Subject Alternative name. (I.e. name of the Subject) >>>>>>=20 >>>>>> It works great if the subject is an organization. >>>>>> In the discussed case, the subject is a person, so PI does not work. >>>>>>=20 >>>>>> /Stefan >>>>>>=20 >>>>>> On 12-03-26 2:47 PM, "Tom Gindin" wrote: >>>>>>=20 >>>>>>> PI is a valid identifier of an organization, but it doesn't >>>>>>> fit >>>>>>> in >>>>>>> a DN. It's a separate GeneralName. It is perfectly true that >>>>>>> there's >>>>>>> a >>>>>>> PI corresponding to Erwann's example, but most AssignerAuthority >>>>>>> values >>>>>>> are not defined attributes. We could define an attribute (probably= a >>>>>>> different OID from the OTHER-NAME one) whose syntax is that of PI, >>>>>>> but >>>>>>> would it be supported by actual LDAP implementations? >>>>>>>=20 >>>>>>> Tom Gindin >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Stefan Santesson >>>>>>> To: Anders Rundgren, >>>>>>> Cc: pkix >>>>>>> Date: 03/23/2012 01:52 PM >>>>>>> Subject: Re: [pkix] Need for an organizationalIdentifier >>>>>>> attribute >>>>>>> Sent by: pkix-bounces@ietf.org >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> No, >>>>>>>=20 >>>>>>> The permanent identifier is an identifier of the subject and is not >>>>>>> an >>>>>>> attribute. >>>>>>> I need an identifier of the subjects organization where the subject >>>>>>> is >>>>>>> a >>>>>>> person. >>>>>>>=20 >>>>>>> /Stefan >>>>>>>=20 >>>>>>> On 12-03-23 6:35 PM, "Anders Rundgren" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution. >>>>>>>> br >>>>>>>> ar >>>>>>>>=20 >>>>>>>> On 2012-03-23 18:13, Stefan Santesson wrote: >>>>>>>>> When a person is associated with an organization in a certificate >>>>>>>>> the >>>>>>>>> subjects employee number or alike is often stored in the >>>>>>>>> serialNumber >>>>>>>>> attribute. >>>>>>>>>=20 >>>>>>>>> But where do you store an identifier of the organization? >>>>>>>>> That is, not the name stored in organization name, but the >>>>>>>>> registered >>>>>>>>> organization number? >>>>>>>>>=20 >>>>>>>>> I've seen some odd solutions to this problem but nor clean >>>>>>>>> solution. >>>>>>>>> X.520 only offer organizationName and orgnizationalUnitName as >>>>>>>>> organizational attributes >>>>>>>>>=20 >>>>>>>>> Have anyone else come across this issue? >>>>>>>>> How did you solve it? >>>>>>>>> Do we need to define a clean attribute for an >>>>>>>>> organizationalIdentifier? >>>>>>>>>=20 >>>>>>>>> /Stefan >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> pkix mailing list >>>>>>>>> pkix@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>>> _______________________________________________ >>>>>>>> pkix mailing list >>>>>>>> pkix@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> pkix mailing list >>>>>>> pkix@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>>=20 >>>>>>>=20 >>>>>>>=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 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Tue Mar 27 08:15:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C910921F88EC for ; Tue, 27 Mar 2012 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-aiszu3xm+0 for ; Tue, 27 Mar 2012 08:15:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8420421F88EB for ; Tue, 27 Mar 2012 08:15:15 -0700 (PDT) Received: by yenm5 with SMTP id m5so5234119yen.31 for ; Tue, 27 Mar 2012 08:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BfpCdcwrMpkaK5Q9u1eZR1zR42dgKvAkLnfYmduh2Lw=; b=dwGYhSuoU1eKGIZE+e4nZIMr1EcKV1TiUqQmTZ2H42kizWo9dP+LTbjmMXR6uk5FPV tDGyvzu8wBjtfWHr5MGhI/xs0xF9rpjAP0SgmTT7kCVzVpBS7V2e3ssvpBLWkcQIaZNE 2J57FY8L6cBvsZkRNB7saScPqrSTka6KKpJ3zPw4M0a3N/Y8C7ehDgAwTMsexYyU31aO f34TAXcNNgJ7L8mbpVPnLocP0cETQfNsf1/fOuWhXDf2mbRq1ajZGqhBC1aMNAM34qxL w4b2mGss7aGOPH4+ZwY34SKu4w8nXQr9TyMc3nYbbWP+0OBcHbo6yEjR9esTC4DWWG1G V9dA== MIME-Version: 1.0 Received: by 10.236.72.195 with SMTP id t43mr25920037yhd.126.1332861314877; Tue, 27 Mar 2012 08:15:14 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Tue, 27 Mar 2012 08:15:14 -0700 (PDT) In-Reply-To: References: <4F716CF3.8060903@Digicert.com> Date: Tue, 27 Mar 2012 17:15:14 +0200 Message-ID: From: Erwann Abalea To: denis.pinkas@bull.net Content-Type: multipart/alternative; boundary=20cf30050e4c354b3d04bc3af5f0 Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:15:16 -0000 --20cf30050e4c354b3d04bc3af5f0 Content-Type: text/plain; charset=UTF-8 Bonjour, Reading your slides, I think I found an error on page 8, "Comparison with CRLs". On this slide, you wrote "*When there is no delegation, the key that signs the CRL is the same key that issued the certificate, whether that has already been a CA key rollover or not.*" This is wrong. A CA can have 2 keys, one for certificate signature and one for CRL signature. 2012/3/27 > Santosh, > > We are on the same track. This is one of the issues I presented this > morning at the meeting. > There are some other issues. > > Please, take a look at the slides: > http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf > > Denis > > -- Erwann. --20cf30050e4c354b3d04bc3af5f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

Reading your slides, I think I found an error on page 8, &q= uot;Comparison with CRLs".

On this slide, you wrote
=C2=A0 &= quot;When there is no delegation, the key that signs the CRL
=C2=A0 i= s the same key that issued the certificate, whether that has
=C2=A0 already been a CA key rollover or not."

This is wron= g. A CA can have 2 keys, one for certificate signature and one for CRL sign= ature.

2012/3/27 <<= a href=3D"mailto:denis.pinkas@bull.net">denis.pinkas@bull.net>
Santosh,

We are on the same track. This is one of the issues I presented this morning at the meeting.
There are some other issues.

Please, take a look at the slides: http://www.ietf.org/proceedings/83= /slides/slides-83-pkix-4.pdf

Denis



--
Erwann.
--20cf30050e4c354b3d04bc3af5f0-- From SChokhani@cygnacom.com Tue Mar 27 09:50:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1273421E80D4 for ; Tue, 27 Mar 2012 09:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEZ1Vz5xS8WY for ; Tue, 27 Mar 2012 09:50:39 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 91B0B21E80A4 for ; Tue, 27 Mar 2012 09:50:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,658,1325480400"; d="scan'208,217";a="4515083" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 27 Mar 2012 12:50:37 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 27 Mar 2012 12:50:37 -0400 From: Santosh Chokhani To: "denis.pinkas@bull.net" Date: Tue, 27 Mar 2012 12:50:36 -0400 Thread-Topic: [pkix] 2560bis Thread-Index: Ac0MInqJGB3rIwP0Sz6iQZsp8TtU6gAFvBnA Message-ID: References: <4F716CF3.8060903@Digicert.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60BD7Ascygexch7cygnac_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:50:40 -0000 --_000_B83745DA469B7847811819C5005244AF0F60BD7Ascygexch7cygnac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Denis, Thanks. I am willing to be little more liberal say that Appendix E scenarios are va= lid and acceptable as long as 2560 bis requires in the normative part of th= e RFC the client to verify that key/certificate relationships as stipulated= in the Appendix or the proposal I made in 2004 regarding matching the cert= ificate certification path and revocation information certification path. From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net] Sent: Tuesday, March 27, 2012 10:04 AM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis Santosh, We are on the same track. This is one of the issues I presented this mornin= g at the meeting. There are some other issues. Please, take a look at the slides: http://www.ietf.org/proceedings/83/slide= s/slides-83-pkix-4.pdf Denis De : Santosh Chokhani > A : Scott Rea >, "pkix= @ietf.org" > Date : 27/03/2012 15:33 Objet : Re: [pkix] 2560bis Envoy=E9 par : pkix-bounces@ietf.org ________________________________ There is a difference of opinion on this one. In my reading 2560 is reasonably clear that the same CA Signing private key= must be used to sign the Responder certificate as the certificate in quest= ion. This offers the crypto binding and provides all three: high degree of= security, reduced software complexity for the OCSP client, and reduced com= putational complexity for the OCSP client. Now, when do you get all three? I do not buy the text in draft bis 2560. That is taking liberty with the i= ntent of 2560 and reducing security and/or adding complexity. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Scott Rea Sent: Tuesday, March 27, 2012 3:32 AM To: pkix@ietf.org Subject: [pkix] 2560bis If the issue with the responder cert is not clear in respect to CA rollover= , and it really is expected to follow existing path processing from 5280, I= am not sure that the proposed text presented just now accomplishes that... why would we just not say that the responder cert should be issued by the s= ame trust anchor that the subject cert of the OCSP request chains to. Hence= if the EE cert now chains to a rolled over CA cert, then the responder cer= t should be issued by that same rolled over CA cert - yes? Regards, -- Scott Rea _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_B83745DA469B7847811819C5005244AF0F60BD7Ascygexch7cygnac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Denis,<= /o:p>

 

Thanks.

 

I am willing to be littl= e more liberal say that Appendix E scenarios are valid and acceptable as lo= ng as 2560 bis requires in the normative part of the RFC the client to veri= fy that key/certificate relationships as stipulated in the Appendix or the = proposal I made in 2004 regarding matching the certificate certification pa= th and revocation information certification path.

 

From: d= enis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Tuesda= y, March 27, 2012 10:04 AM
To: Santosh Chokhani
Cc: pki= x@ietf.org
Subject: Re: [pkix] 2560bis

 

Santosh,

We are on t= he same track. This is one of the issues I presented this morning at the me= eting.
There are some other issues.

Please, take a look at the slid= es: http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf=

= Denis




De :        Santosh C= hokhani <SChokhani@cygnacom.co= m>
A :        Scott Rea <Scott@Digicert.com>, "pkix@ietf.org" <pkix@ietf.org>
Date :       &= nbsp;27/03/2012 15:33
Objet :        Re: [pkix= ] 2560bis
Envoy=E9 par :        <= span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>pkix-bounces@ietf.org <= /p>

=




There is a difference of opinion on this one.

= In my reading 2560 is reasonably clear that the same CA Signing private= key must be used to sign the Responder certificate as the certificate in q= uestion.  This offers the crypto binding and provides all three: high = degree of security, reduced software complexity for the OCSP client, and re= duced computational complexity for the OCSP client.  Now, when do you = get all three?

I do not buy the text in draft bis 2560. &nb= sp;That is taking liberty with the intent of 2560 and reducing security and= /or adding complexity.

-----Original Message-----
<= tt>From: pkix-bounces@ietf.org= [mailto:pkix-bounces@ietf.org] On Behalf Of Scott Rea
Sent: Tuesday, March 27,= 2012 3:32 AM
To: pkix@ietf.or= g
Subject: [pkix] 2560bis

If the issue with= the responder cert is not clear in respect to CA rollover, and it really i= s expected to follow existing path processing from 5280, I am not sure that= the proposed text presented just now accomplishes that...
why = would we just not say that the responder cert should be issued by the same = trust anchor that the subject cert of the OCSP request chains to. Hence if = the EE cert now chains to a rolled over CA cert, then the responder cert sh= ould be issued by that same rolled over CA cert - yes?
Regards,=

--
Scott Rea

_________________= ______________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
___________________= ____________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

= --_000_B83745DA469B7847811819C5005244AF0F60BD7Ascygexch7cygnac_-- From DPKemp@missi.ncsc.mil Tue Mar 27 10:04:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2148F21E8115 for ; Tue, 27 Mar 2012 10:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woBzQhKIqqdR for ; Tue, 27 Mar 2012 10:04:00 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8721E8044 for ; Tue, 27 Mar 2012 10:04:00 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2RH3xS5055902 for ; Tue, 27 Mar 2012 13:03:59 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 13:03:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Mar 2012 13:03:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0MAtvKGMX19AH5RlewpUaP+YW/QAAMoD/A References: <4F71128E.4050105@e-net.lt> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 27 Mar 2012 17:03:59.0192 (UTC) FILETIME=[9A1EB580:01CD0C3B] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 17:04:01 -0000 Repetition does not increase the truth of a false statement. You say:=20 >>>>>>> When a person is associated with an organization in a=20 >>>>>>>certificate the subjects employee number or alike is often=20 >>>>>>>stored in the serialNumber attribute. >>>>>>> >>>>>>> But where do you store an identifier of the organization? The subject of your certificate is a person. The PI subject alternative name contains an alternative name of the SUBJECT. The PI assigner is the ORGANIZATION with which the subject is associated. The concept really isn't that difficult to understand -- C=3D and O=3D are not = subjects either, but they ARE contained in the subject DN. As Sean Leonard says, it is possible to create an organizationDUNSNumber attribute, or an organizationNumber attribute whose value is a fully-qualified OID. The OID could even be represented as a verbose Directory String instead of the compact OID universal type. But even if an appropriate encoding is defined you still have the semantic problem of saying that the DN contains an attribute that "represents an organization that is associated with the subject" and "assigns the subject's serialNumber attribute". The PI SAN explicitly captures that relationship. Using multiple DN attributes to express the same relationship is an ugly hack, in part because the organizationName may not be the assigner of the subject's serialNumber, as when an employee cert contains O=3Demployer and a national identifying number. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, March 27, 2012 7:17 AM To: Moudrick M. Dadashov Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute No, Saying this again. A subject Alternative name is an alternative name of the SUBJECT. Example AB's org number is NOT an alternative name of the subject. The subject is John Doe and not Example AB. Example AB is the subjects organization, but not the subject. /Stefan On 12-03-27 2:06 AM, "Moudrick M. Dadashov" wrote: >On 3/27/2012 12:40 AM, Stefan Santesson wrote: >> CN=3DJohn Doe >> SN=3DDoe >> GivenName=3DJohn >> SERIALNUMBER=3D123456789 (employee number) O=3DExample AB = OU=3DExample=20 >> department C=3DSE >> >> Example AB's org number is 555555-5555 >> >> Where do I store it? >Isn't this a typical RFC 4043 use case? > >Thanks, >M.D. > From DPKemp@missi.ncsc.mil Tue Mar 27 15:46:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FFD21E8024 for ; Tue, 27 Mar 2012 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.44 X-Spam-Level: X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K2GiExgiCD4 for ; Tue, 27 Mar 2012 15:46:15 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1169121E814C for ; Tue, 27 Mar 2012 15:46:12 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2RMkCqe061002 for ; Tue, 27 Mar 2012 18:46:12 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 18:46:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Mar 2012 18:46:12 -0400 Message-ID: In-Reply-To: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAIAALZ4g References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 27 Mar 2012 22:46:12.0324 (UTC) FILETIME=[68D20240:01CD0C6B] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 22:46:15 -0000 The cleanest solution may be to use the serialNumber attribute with a fully-qualified value (e.g., "assigner:identifier" or "identifier@assigner"): CN =3D John Doe SerialNumber =3D 1.3.60.987654321:123456 OU =3D Example Department O =3D Example AB C =3D SE Defining a fully-qualified subject identifier in accordance with ISO/IEC 6523 wouldn't require any new attribute, it would just specify a new way to populate the existing attribute. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Tuesday, March 27, 2012 10:50 AM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute It seems to me that this is the whole reason why multi-valued RDNs are permitted in the first place. I.e., Stefan's example could be solved as: CN=3DJohn Doe\SERIALNUMBER=3D123456789 OU=3DExample Department O=3DExample AB\ORGIDTYPEANDVALUE=3D1.3.6.1.4.1.519.1;987654321 Of course, multi-value RDNs are a whole different can'o'worms. -- T From md@e-net.lt Tue Mar 27 16:18:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4121E8064 for ; Tue, 27 Mar 2012 16:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlxdFoL0nvFf for ; Tue, 27 Mar 2012 16:18:05 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5321E8032 for ; Tue, 27 Mar 2012 16:18:04 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SCfeN-0001lu-B5 for pkix@ietf.org; Wed, 28 Mar 2012 02:18:03 +0300 Message-ID: <4F724AA9.60504@e-net.lt> Date: Wed, 28 Mar 2012 02:18:01 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 23:18:06 -0000 Thanks, David, this one looks really elegant.. M.D. On 3/28/2012 1:46 AM, Kemp, David P. wrote: > The cleanest solution may be to use the serialNumber attribute with a > fully-qualified value (e.g., "assigner:identifier" or > "identifier@assigner"): > > CN = John Doe > SerialNumber = 1.3.60.987654321:123456 > OU = Example Department > O = Example AB > C = SE > > Defining a fully-qualified subject identifier in accordance with ISO/IEC > 6523 wouldn't require any new attribute, it would just specify a new way > to populate the existing attribute. > > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Miller, Timothy J. > Sent: Tuesday, March 27, 2012 10:50 AM > To: Stefan Santesson > Cc: pkix > Subject: Re: [pkix] Need for an organizationalIdentifier attribute > > It seems to me that this is the whole reason why multi-valued RDNs are > permitted in the first place. > > I.e., Stefan's example could be solved as: > > CN=John Doe\SERIALNUMBER=123456789 > OU=Example Department > O=Example AB\ORGIDTYPEANDVALUE=1.3.6.1.4.1.519.1;987654321 > > Of course, multi-value RDNs are a whole different can'o'worms. > > -- T > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Tue Mar 27 16:39:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAFE21F85EC for ; Tue, 27 Mar 2012 16:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D59bwfT4U5J2 for ; Tue, 27 Mar 2012 16:39:48 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9821F85E6 for ; Tue, 27 Mar 2012 16:39:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so447053ghb.31 for ; Tue, 27 Mar 2012 16:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nzZyfYvQsVtEuvJgfanrRPsSO4XvTYNz2eQgpu4WJrU=; b=aHmpgyi8odvEg4CJ9x3/LySFqNjS002E9h3Ds4SWzsp7mN5yAcS0pNb0e0siBoMof8 OcmtsCvOnEEG/TQ+3NxmlPCwmi0eEBgNuMnvqwtgXraedFQ9Af5uHqTFweSmnxaqKJAj lx5JBXzCC7KQuR8AppZLL/Nyuc//scoDm00R3Xzf1MlUN0uVITPjGQMfP2N9cGGeA5Gy YFzbLFjb2t/Wj5Sd7Cg+WToJC9wkF5Ld3DC5M10i1DHYxIeK2K3BhRlKN4Gc55Il2oI4 F/XCCyudIFE7MRIVfZFiqPZXChNNF7syZHOakhbTElxEj0XM3ZUjlDXWkAlycNnMPCF9 2UwA== MIME-Version: 1.0 Received: by 10.236.80.39 with SMTP id j27mr28056085yhe.92.1332891586865; Tue, 27 Mar 2012 16:39:46 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Tue, 27 Mar 2012 16:39:46 -0700 (PDT) In-Reply-To: References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> Date: Wed, 28 Mar 2012 01:39:46 +0200 Message-ID: From: Erwann Abalea To: "Kemp, David P." Content-Type: multipart/alternative; boundary=20cf30050be28f290904bc4201f6 Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 27 Mar 2012 23:39:49 -0000 --20cf30050be28f290904bc4201f6 Content-Type: text/plain; charset=UTF-8 2 potential problems: - the serialNumber attribute is limited to 64 characters by RFC5280, and among the 170+ different ICDs some of them allow for more than 64 characters by themselves (that is, just to identify the "organization ID", or the "assigner" in your scheme). - some of those ICDs allow for non numerical identifiers; I haven't checked if the ':' or '@' character (or whatever is proposed as a separator between assigner and identifier) is allowed for several of those ICDs, but it could be true. 2012/3/28 Kemp, David P. > The cleanest solution may be to use the serialNumber attribute with a > fully-qualified value (e.g., "assigner:identifier" or > "identifier@assigner"): > > CN = John Doe > SerialNumber = 1.3.60.987654321:123456 > OU = Example Department > O = Example AB > C = SE > > Defining a fully-qualified subject identifier in accordance with ISO/IEC > 6523 wouldn't require any new attribute, it would just specify a new way > to populate the existing attribute. -- Erwann. --20cf30050be28f290904bc4201f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2 potential problems:

=C2=A0- the serialNumber att= ribute is limited to 64 characters by RFC5280, and among the 170+ different= ICDs some of them allow for more than 64 characters by themselves (that is= , just to identify the "organization ID", or the "assigner&q= uot; in your scheme).
=C2=A0- some of those ICDs allow for non numerical identifiers; I haven'= ;t checked if the ':' or '@' character (or whatever is prop= osed as a separator between assigner and identifier) is allowed for several= of those ICDs, but it could be true.

2012/3/28 Kemp, David P. <DPKemp@missi.ncsc.mil= >
The cleanest solution may be to use the serialNumber attribute with a
fully-qualified value (e.g., "assigner:identifier" or
"identifier@assigner"):

=C2=A0CN =3D John Doe
=C2=A0SerialNumber =3D 1.3.60.987654321:123456
=C2=A0OU =3D Example Department
=C2=A0O =3D Example AB
=C2=A0C =3D SE

Defining a fully-qualified subject identifier in accordance with ISO/IEC 6523 wouldn't require any new attribute, it would just specify a new wa= y
to populate the existing attribute.
=C2=A0
-- <= br>Erwann.
--20cf30050be28f290904bc4201f6-- From dev+ietf@seantek.com Tue Mar 27 22:10:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4079E21E808B for ; Tue, 27 Mar 2012 22:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aEclMKyUYpW for ; Tue, 27 Mar 2012 22:10:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 52EB521E802A for ; Tue, 27 Mar 2012 22:10:34 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BEB2822E253 for ; Wed, 28 Mar 2012 01:10:27 -0400 (EDT) Message-ID: <4F729D41.5000200@seantek.com> Date: Tue, 27 Mar 2012 22:10:25 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 05:10:35 -0000 I agree (with the detractors). serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] is = a PrintableString that "specifies an identifier, the serial number of an = object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is=20 not; the range of Serial Number is very limited. The intent of the=20 serial number is to record the serial number of inventory items, such as = routers, Apple iPhones, tanks, and the like. A serial number is=20 generally permanently etched onto an object. It's for property, not=20 people. We do not assign serial numbers to human beings, unless you want = to set up another Auschwitz or some Orwellian state. If you want other attributes that could arguably apply to people, check=20 out the COSINE Unique Identifier [0.9.2342.19200300.100.1.44,=20 DirectoryString], or the X.520 Unique Identifier [2.5.4.45, BIT STRING]. = The X.520 one is probably not what anybody wants here, but I am=20 including it for completeness. RFC 4524 sec. 2.24: "The COSINE Unique Identifier specifies a unique=20 identifier for an object represented in the Directory. The domain within = which the identifier is unique and the exact semantics of the identifier = are for local definition. For a person, this might be an institution-=20 wide payroll number. For an organizational unit, it might be a=20 department code." X.520:2005 sec. 5.2.7: "The Unique Identifier attribute type specifies=20 an identifier which may be used to distinguish between object references = when a distinguished name has been reused. It may be, for example, an=20 encoded object identifier, certificate, date, timestamp, or some other=20 form of certification on the validity of the distinguished name." Despite all of that, Serial Number, Unique Identifier, and (X.500)=20 Unique Identifier all refer to some unique value that is associated with = the *subject*, not the organization to which the subject belongs. The OP = asked for an attribute that "serves to identify an organization with=20 which the named object is affiliated" (borrowing the verbiage from X.520 = for Organization Name). So, the best is to specify different attributes=20 for different types of identifiers, or specify one attribute, and make=20 the value explicitly include an assigning entity in a completely=20 unambiguous way. Perhaps we should let the OP, Stefan, chime in for like the sixth time=20 :) and repeat that he wants an organizational identifier, not a subject=20 identifier. Stefan: what exactly are you trying to do? Is it sufficient to define an = organizationSwedishRegistrationNumber attribute (for example) for a=20 community of use? Or, are you really, really looking for an=20 organizationIdentifier attribute--one that is generic in the attribute=20 type--and defines the assigning entity in the attribute value? If the=20 latter, can you give several concrete examples or organization=20 identifiers that you find acceptable for your usage? Sean On 3/27/2012 4:39 PM, Erwann Abalea wrote: > 2 potential problems: > > - the serialNumber attribute is limited to 64 characters by RFC5280,=20 > and among the 170+ different ICDs some of them allow for more than 64=20 > characters by themselves (that is, just to identify the "organization=20 > ID", or the "assigner" in your scheme). > - some of those ICDs allow for non numerical identifiers; I haven't=20 > checked if the ':' or '@' character (or whatever is proposed as a=20 > separator between assigner and identifier) is allowed for several of=20 > those ICDs, but it could be true. > > 2012/3/28 Kemp, David P. > > > The cleanest solution may be to use the serialNumber attribute with= a > fully-qualified value (e.g., "assigner:identifier" or > "identifier@assigner"): > > CN =3D John Doe > SerialNumber =3D 1.3.60.987654321:123456 > OU =3D Example Department > O =3D Example AB > C =3D SE > > Defining a fully-qualified subject identifier in accordance with > ISO/IEC > 6523 wouldn't require any new attribute, it would just specify a > new way > to populate the existing attribute. > > --=20 > Erwann. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From Jeff.Hodges@KingsMountain.com Wed Mar 28 01:02:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282BA21F85E3 for ; Wed, 28 Mar 2012 01:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.086 X-Spam-Level: X-Spam-Status: No, score=-100.086 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozCKlCw7koir for ; Wed, 28 Mar 2012 01:02:40 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 4D13121F85D7 for ; Wed, 28 Mar 2012 01:02:40 -0700 (PDT) Received: (qmail 20560 invoked by uid 0); 28 Mar 2012 08:02:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 28 Mar 2012 08:02:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=bLUS15RaUmvzTVShSwhuKdyzp/hMDDUcROk+Dx0vvyA=; b=1xXcpIpPGr4CV5oeQ48ffte8GfKHZ5mpiR70NhPvkDFnmr8oxlC1y2TEx0SclhCMcrzrWCmX8ZiGwNhwCNcybZQy1f7nX0hp44+ZYFKF5ansnqPPUEaHXOOj/4G+KFTd; Received: from dhcp-5698.meeting.ietf.org ([130.129.86.152]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SCnq1-0002F3-Fh; Wed, 28 Mar 2012 02:02:37 -0600 Message-ID: <4F72C59A.90900@KingsMountain.com> Date: Wed, 28 Mar 2012 01:02:34 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF PKIX WG , IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.86.152 authed with jeff.hodges+kingsmountain.com} Subject: [pkix] fyi: CA/Browser Forum (CABF) reform deliberations + Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:02:41 -0000 The CA/Browser Forum (CABF) was mentioned a few times during this very interesting presentation in the PKIX session at IETF-83 Paris yesterday... Trust-Related Activities: Internet Certification Authorities Revocation and SSL Replacements/Enhancements https://www.ietf.org/proceedings/83/slides/slides-83-pkix-10.pdf FYI, as I mentioned in the session, the CA/Browser Forum (CABF) is entertaining governance reforms, as announced here. CA/Browser Forum Announces Organizational Reform Working Group http://cabforum.org/org_announcement.html The CABF is soliciting public input, the deadline for input is unfortunately fast approaching, it is this Friday, March 30, 2012. In terms of the sorts of reforms some parties are proposing, here's PayPal's input.. PayPal supports reform at the CA/Browser Forum http://www.thesecuritypractice.com/the_security_practice/2012/03/paypal-supports-reform-at-the-cabrowser-forum.html I'm here @ietf-83, feel free to reach out if you have any questions, =JeffH From benlaurie@gmail.com Wed Mar 28 01:10:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918BD21F88B7; Wed, 28 Mar 2012 01:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-mR91gS0fXF; Wed, 28 Mar 2012 01:10:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0378B21F86DB; Wed, 28 Mar 2012 01:10:27 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so589211vbb.31 for ; Wed, 28 Mar 2012 01:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WQDQcgROi6RCl8Wnyz55esHkeZfxoXnA32FbFkXchSI=; b=pLV6WlvFJssLzVYR+QrQlIcC3vUGeDxIT85IrnYvUxr0GIalCXIaNyKU6b5LHX4xg+ FdwnOIv0KCFC8ed3DI/4MEDX+yizWQo5tBKsHMobj6aEE87pGOBUlLQXax6UWw07oTsn WRT1SLxdlb8OlEkrNmFvPO6qlDEsf3zkKFcStI2yM68FUB8qvIV+4DbgmHEuoDTpxAF5 m0PbGbSoX5fjCiHG9tugaF4j5nI2xTzdlulLQl1YTzF12WGtU+hTgiVRNaoHirWRt6a7 gmwZqNhsBIP2eAYaKz+ndcgY+XhexC+c/ybGJFezn9EMQNfZZtj32ieJabl+W6wMontu ccAw== MIME-Version: 1.0 Received: by 10.52.176.198 with SMTP id ck6mr11276140vdc.0.1332922227425; Wed, 28 Mar 2012 01:10:27 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.26.170 with HTTP; Wed, 28 Mar 2012 01:10:27 -0700 (PDT) In-Reply-To: <4F72C59A.90900@KingsMountain.com> References: <4F72C59A.90900@KingsMountain.com> Date: Wed, 28 Mar 2012 08:10:27 +0000 X-Google-Sender-Auth: L32pJKJdBzTYu9af5EqokxM1Q-0 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: multipart/alternative; boundary=bcaec50163fbe1009d04bc4923f6 Cc: IETF PKIX WG , IETF Security Area Advisory Group Subject: Re: [pkix] [saag] fyi: CA/Browser Forum (CABF) reform deliberations + Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:10:35 -0000 --bcaec50163fbe1009d04bc4923f6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 8:02 AM, =JeffH wrote: > The CA/Browser Forum (CABF) was mentioned a few times during this very > interesting presentation in the PKIX session at IETF-83 Paris yesterday... > > Trust-Related Activities: > Internet Certification Authorities > Revocation and SSL Replacements/Enhancements > https://www.ietf.org/**proceedings/83/slides/slides-**83-pkix-10.pdf Hmmm... a) Doesn't mention Certificate Transparency. b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is a TTP, which is incorrect. --bcaec50163fbe1009d04bc4923f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 28, 2012 at 8:02 AM, =3DJeff= H <Je= ff.Hodges@kingsmountain.com> wrote:
The CA/Browser Forum (CABF) was mentioned a few times during this very inte= resting presentation in the PKIX session at IETF-83 Paris yesterday...

Trust-Related Activities:
Internet Certification Authorities
Revocation and SSL Replacements/Enhancements
https://www.ietf.org/proceedings/83/slides/slide= s-83-pkix-10.pdf

Hmmm...

a) Doesn't mention Certificate Transparency.
<= br>
b) Thinks Sovereign Keys (and presumably, had they mentioned = it, CT) is a TTP, which is incorrect.

From: Santosh Chokhani <<= a href=3D"mailto:SChokhani@cygnacom.com">SChokhani@cygnacom.com>
Date: Tue, 27 Mar 2012 12:50:36 -0400To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject:= Re: [pkix] 2560bis

Denis,

 

=

Thanks.

 

I am willing to be little more liberal say that Appendix E scenarios are= valid and acceptable as long as 2560 bis requires in the normative part of = the RFC the client to verify that key/certificate relationships as stipulate= d in the Appendix or the proposal I made in 2004 regarding matching the cert= ificate certification path and revocation information certification path.

 =

From: denis.pinkas@b= ull.net [mailto:denis.pinkas@bull= .net]
Sent: Tuesday, March 27, 2012 10:04 AM
To: Sa= ntosh Chokhani
Cc: pkix@ietf.org
Subject: Re: [pkix] 2560bis

 

Santosh,

We are on the same track. Th= is is one of the issues I presented this morning at the meeting.
= There are so= me other issues.

Please, take a look at the slides: http://www.ietf.org/proceedin= gs/83/slides/slides-83-pkix-4.pdf

Denis




De :        Santosh Chokhani <SChokhani@cygnacom.com>
Scott Rea <Scott@Digicert.com>, "pkix@ietf.or= g" <pkix@ietf.org>
<= span style=3D"font-size: 7.5pt; color: rgb(95, 95, 95); font-family: Arial, sa= ns-serif; ">Date :        27/03/2012 15:33
Objet :        Re: [pkix] 2560bis
Envoy=E9 par :        pkix-bounces@ietf.org




There is a = difference of opinion on this one.

In my reading 2560 is reasonably c= lear that the same CA Signing private key must be used to sign the Responder= certificate as the certificate in question.  This offers the crypto bi= nding and provides all three: high degree of security, reduced software comp= lexity for the OCSP client, and reduced computational complexity for the OCS= P client.  Now, when do you get all three?

I do not buy= the text in draft bis 2560.  That is taking liberty with the intent of= 2560 and reducing security and/or adding complexity.

-----O= riginal Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Scott Rea
Sent: = Tuesday, March 27, 2012 3:32 AM
To: pkix@ietf.org
Subject: [pkix] 2560bis

If = the issue with the responder cert is not clear in respect to CA rollover, an= d it really is expected to follow existing path processing from 5280, I am n= ot sure that the proposed text presented just now accomplishes that...<= br>why would we just not say that the responder cert should be issued by= the same trust anchor that the subject cert of the OCSP request chains to. = Hence if the EE cert now chains to a rolled over CA cert, then the responder= cert should be issued by that same rolled over CA cert - yes?
R= egards,

--
Scott Rea

___________= ____________________________________
pkix mailing list
<= tt>pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
_______________________= ________________________
pkix mailing list
pkix@ietf.org
https://w= ww.ietf.org/mailman/listinfo/pkix

=
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3415783293_54011070-- From stefan@aaa-sec.com Wed Mar 28 03:45:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E7C21E801A for ; Wed, 28 Mar 2012 03:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a--Fz3W02GSP for ; Wed, 28 Mar 2012 03:45:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3845521E8019 for ; Wed, 28 Mar 2012 03:45:34 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 08DF61DC4773 for ; Wed, 28 Mar 2012 12:45:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j9FyPO-Yzx0G for ; Wed, 28 Mar 2012 12:45:33 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BD6B21DC2C3E for ; Wed, 28 Mar 2012 12:45:33 +0200 (CEST) Received: (qmail 19220 invoked from network); 28 Mar 2012 10:45:33 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.207]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Mar 2012 10:45:33 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 28 Mar 2012 12:45:18 +0100 From: Stefan Santesson To: "Kemp, David P." , pkix Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 10:45:35 -0000 Hi David, I think this is where you derail: On 12-03-27 6:03 PM, "Kemp, David P." wrote: >The PI assigner is >the ORGANIZATION with which the subject is associated. No, the PI assigner is the organization that assigns the identifier. Not the organization within which the subject is associated. The assigner might be the DUNS och VAT registration authority. The subject's organization might be something completely different. /Stefan From stefan@aaa-sec.com Wed Mar 28 04:07:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A84221F8757 for ; Wed, 28 Mar 2012 04:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.056 X-Spam-Level: X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUct1G2chEYf for ; Wed, 28 Mar 2012 04:07:42 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 9738421F885D for ; Wed, 28 Mar 2012 04:07:41 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 958A41DC7458 for ; Wed, 28 Mar 2012 13:07:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hc-nKpXrAzyV for ; Wed, 28 Mar 2012 13:07:39 +0200 (CEST) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BE3C51DB60DF for ; Wed, 28 Mar 2012 13:07:38 +0200 (CEST) Received: (qmail 77754 invoked from network); 28 Mar 2012 11:07:38 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.207]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Mar 2012 11:07:38 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 28 Mar 2012 13:07:32 +0100 From: Stefan Santesson To: Sean Leonard , Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F729D41.5000200@seantek.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 11:07:43 -0000 Hi Sean, Except for the fact that serialNumber (despite it's original intended use) in practice is used world wide as the common attribute for a subject distinguishing identifier, I think I agree with everything you say. On the defacto use of the serial number attribute, se standards like RFC 3739 and ETSI TS 102 280. I'm pretty open to what type of attribute that would be created to meet the org identifier need as long as: - It can represent an arbitrary identifier of the organization specified in the organizationName attribute (the subjects organization) I would be happy with a generic attribute that allows any ASCII string (IA5String) or DirectoryString (allowing UTF-8). I will use the semantics identifier in RFC 3739 to specify exactly what type of value the identifier holds. To me that would be the cleanest way to go as I just need a container for the actual value. One that is not an abuse of the assigned attribute semantics. However, I could live also with a structured attribute, holding some identifier of type and/or assigner. I would respect if others feel they need that functionality. So I would prefer a straight generic attribute with a simple string value, but could live with both. My use case is simply that I need to issue certs that reflect the identity carried in a SAML assertion. Sometimes this will include an organizational identifier that I need to store in the subject RDN. I can use a private attribute OID, but would prefer not to do so. /Stefan On 12-03-28 6:10 AM, "Sean Leonard" wrote: >I agree (with the detractors). > >serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] is >a PrintableString that "specifies an identifier, the serial number of an >object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is >not; the range of Serial Number is very limited. The intent of the >serial number is to record the serial number of inventory items, such as >routers, Apple iPhones, tanks, and the like. A serial number is >generally permanently etched onto an object. It's for property, not >people. We do not assign serial numbers to human beings, unless you want >to set up another Auschwitz or some Orwellian state. > >If you want other attributes that could arguably apply to people, check >out the COSINE Unique Identifier [0.9.2342.19200300.100.1.44, >DirectoryString], or the X.520 Unique Identifier [2.5.4.45, BIT STRING]. >The X.520 one is probably not what anybody wants here, but I am >including it for completeness. > >RFC 4524 sec. 2.24: "The COSINE Unique Identifier specifies a unique >identifier for an object represented in the Directory. The domain within >which the identifier is unique and the exact semantics of the identifier >are for local definition. For a person, this might be an institution- >wide payroll number. For an organizational unit, it might be a >department code." > >X.520:2005 sec. 5.2.7: "The Unique Identifier attribute type specifies >an identifier which may be used to distinguish between object references >when a distinguished name has been reused. It may be, for example, an >encoded object identifier, certificate, date, timestamp, or some other >form of certification on the validity of the distinguished name." > > >Despite all of that, Serial Number, Unique Identifier, and (X.500) >Unique Identifier all refer to some unique value that is associated with >the *subject*, not the organization to which the subject belongs. The OP >asked for an attribute that "serves to identify an organization with >which the named object is affiliated" (borrowing the verbiage from X.520 >for Organization Name). So, the best is to specify different attributes >for different types of identifiers, or specify one attribute, and make >the value explicitly include an assigning entity in a completely >unambiguous way. > >Perhaps we should let the OP, Stefan, chime in for like the sixth time >:) and repeat that he wants an organizational identifier, not a subject >identifier. > >Stefan: what exactly are you trying to do? Is it sufficient to define an >organizationSwedishRegistrationNumber attribute (for example) for a >community of use? Or, are you really, really looking for an >organizationIdentifier attribute--one that is generic in the attribute >type--and defines the assigning entity in the attribute value? If the >latter, can you give several concrete examples or organization >identifiers that you find acceptable for your usage? > >Sean > >On 3/27/2012 4:39 PM, Erwann Abalea wrote: >> 2 potential problems: >> >> - the serialNumber attribute is limited to 64 characters by RFC5280, >> and among the 170+ different ICDs some of them allow for more than 64 >> characters by themselves (that is, just to identify the "organization >> ID", or the "assigner" in your scheme). >> - some of those ICDs allow for non numerical identifiers; I haven't >> checked if the ':' or '@' character (or whatever is proposed as a >> separator between assigner and identifier) is allowed for several of >> those ICDs, but it could be true. >> >> 2012/3/28 Kemp, David P. > > >> >> The cleanest solution may be to use the serialNumber attribute with >>a >> fully-qualified value (e.g., "assigner:identifier" or >> "identifier@assigner"): >> >> CN = John Doe >> SerialNumber = 1.3.60.987654321:123456 >> OU = Example Department >> O = Example AB >> C = SE >> >> Defining a fully-qualified subject identifier in accordance with >> ISO/IEC >> 6523 wouldn't require any new attribute, it would just specify a >> new way >> to populate the existing attribute. >> >> -- >> 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 From Jeff.Hodges@KingsMountain.com Wed Mar 28 05:03:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7C21E808D for ; Wed, 28 Mar 2012 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.189 X-Spam-Level: X-Spam-Status: No, score=-100.189 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxAdfUQAsmEs for ; Wed, 28 Mar 2012 05:03:04 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 35E8021E815E for ; Wed, 28 Mar 2012 05:03:03 -0700 (PDT) Received: (qmail 8249 invoked by uid 0); 28 Mar 2012 12:03:02 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 28 Mar 2012 12:03:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=U100soFIxGWrLqttnZ4S24xIOGU7o6voGHXsxoil2LE=; b=yGRC5S93Qs1QfthMm9gS6FF0JAonVOfUndrqJrDeZFq9l1UAgbYuDXeAOHbY8zoG/k/QNkVMO6IqKyEahg8W+yp9tkaKi8MTAp/nOD+e4meNnZZHtBhrP6djrbmPnLiZ; Received: from dhcp-5698.meeting.ietf.org ([130.129.86.152]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SCrag-0006lB-CF; Wed, 28 Mar 2012 06:03:02 -0600 Message-ID: <4F72FDF3.1080206@KingsMountain.com> Date: Wed, 28 Mar 2012 05:02:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Ben Laurie , IETF PKIX WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.86.152 authed with jeff.hodges+kingsmountain.com} Subject: Re: [pkix] Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:03:04 -0000 [ trimming cc: to just pkix@ ] [ topic trimmed to Revocation and TLS/SSL Replacements/Enhancements ] > a) Doesn't mention Certificate Transparency. indeed. neither did it mention CRLSets. > b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is > a TTP, which is incorrect. I tend to agree, tho it depends on how one defines a trust 3d party (TTP). Their definition is different than yours it would seem. =JeffH From tom@ritter.vg Wed Mar 28 05:13:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5896E21E8199 for ; Wed, 28 Mar 2012 05:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p53jc3l9Nf2Q for ; Wed, 28 Mar 2012 05:13:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB58A21E8197 for ; Wed, 28 Mar 2012 05:13:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1497806obb.31 for ; Wed, 28 Mar 2012 05:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SrpL+3HDrTAEDthh3UKpESJKmW9lTWddIXQd3862wAg=; b=YfB0zap8QFOCG0K6lBcCoY/B7GBjXGKg3vUwPsGi8LXD16qs1x62ipfOZ3pVOe8PTg ytnCmYh6ORwo4Iwdc57sdYOiXb7KgvhXKUDnod77QxigfBTHL94G1jgRa/BWroN84Bjm HQAY0Js7xSyA5kWXj4UibLb8RrsQVrM5F0c/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=SrpL+3HDrTAEDthh3UKpESJKmW9lTWddIXQd3862wAg=; b=TfXvwLt53Ysdoh7lC1FOdrN/F6GlGjU4QNDsFFitvByGyFvrCYsJC7nWGgEcZesrGW S7W7bdcW9vLTvkGAPGUjvXVfkAJtgN9iNOiHilFsPy5zfohDpWpvgqBOFiebmD3YHUUZ A0f56ltVMIDjlEqR2UszXDQbG5JvLDCW6rBPy1HBh5vl6JDFwXoxwfcFZlx9DoqG4TdI qxXzwlRUiTZGYfGqRlBGT9/yXTP0bKh6NxUGlrBmhrCbjUsO6tQBAdbEsXw+SlQgStSo mxkQSMcVbpg2Q8vCP3rjml7tQZkC0RCTVCq9q26TXR9aDs5ho6aF/Kzu3ZHQ8ZlrUyPS 1/2w== Received: by 10.60.9.38 with SMTP id w6mr36546709oea.41.1332936829279; Wed, 28 Mar 2012 05:13:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.199.41 with HTTP; Wed, 28 Mar 2012 05:13:29 -0700 (PDT) In-Reply-To: <4F72FDF3.1080206@KingsMountain.com> References: <4F72FDF3.1080206@KingsMountain.com> From: Tom Ritter Date: Wed, 28 Mar 2012 08:13:29 -0400 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnWxk2FBoqii/ydXeYE3HBf3dRAhlhuV1ogKYvxDdWTR415Vj8Ls4prR8m2jrB1t2DZByeS Cc: IETF PKIX WG , Ben Laurie Subject: Re: [pkix] Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:13:51 -0000 On the same topic, I recently published a whitepaper as part of Black Hat, a subset of which also covers "Revocation and PKI Improvements". (The whole paper also goes into TLS improvements of the past couple years, things in draft status, STS, Caja, CSP, etc, etc.) At the end, (in the very last section), I tried to find a set of concepts that would be good to keep in mind when evaluating any PKI or Revocation proposal. The paper is at http://ritter.vg/p/2012-TLS-Survey.pdf and there's a video here, although it doesn't go into as much detail about the PKI stuff: https://media.blackhat.com/bh-eu-12/videos/bh-eu-12-Ritter-Future-of-Security-Protocols.mp4 I'm working on a followup which inverts the discussion, talking about the properties we like (such "No Extra Network Trips") and thinking about the fundamental ways (and constraints) to achieve that. -tom On 28 March 2012 08:02, =JeffH wrote: > [ trimming cc: to just pkix@ ] > [ topic trimmed to Revocation and TLS/SSL Replacements/Enhancements ] > >> a) Doesn't mention Certificate Transparency. > > indeed. neither did it mention CRLSets. > > >> b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is >> a TTP, which is incorrect. > > I tend to agree, tho it depends on how one defines a trust 3d party (TTP). > Their definition is different than yours it would seem. > > > =JeffH > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Wed Mar 28 05:39:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F2E21E81DE for ; Wed, 28 Mar 2012 05:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QSS9wACqA78 for ; Wed, 28 Mar 2012 05:39:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 665B221E81DC for ; Wed, 28 Mar 2012 05:39:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9D14421B113D; Wed, 28 Mar 2012 08:39:00 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 90BD521B1139; Wed, 28 Mar 2012 08:39:00 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Wed, 28 Mar 2012 08:39:00 -0400 From: "Miller, Timothy J." To: Stefan Santesson Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAIAALZ4ggABmZgCAAFxigIAAdIoAgAAIyoA= Date: Wed, 28 Mar 2012 12:38:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.40.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <90F324A716740C4AAB8B261CC7CC9F15@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Sean Leonard Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 12:39:02 -0000 On Mar 28, 2012, at 7:07 AM, Stefan Santesson wrote: > My use case is simply that I need to issue certs that reflect the identit= y > carried in a SAML assertion. > Sometimes this will include an organizational identifier that I need to > store in the subject RDN. > I can use a private attribute OID, but would prefer not to do so. Are you sticking to the suggested attribute types in the RFC, or are any X.= 520 types available? If you permit X.520, it seems simple enough; Unique I= dentifier & DN Qualifier could carry an encoded type/value pair. DN Qualifier is also in the 5280 suggested attributes, so that one kinda ju= mps out at me. -- T= From DPKemp@missi.ncsc.mil Wed Mar 28 06:02:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB05421E8224 for ; Wed, 28 Mar 2012 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjdeL+5Zt9ng for ; Wed, 28 Mar 2012 06:02:02 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id F372A21E8222 for ; Wed, 28 Mar 2012 06:02:01 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2SD21ks066800 for ; Wed, 28 Mar 2012 09:02:01 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 09:02:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Mar 2012 09:02:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0Mz+iDi7J/nzQhTpuhYoAwMlEc3AAEWOMQ References: From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 28 Mar 2012 13:02:01.0327 (UTC) FILETIME=[F7360FF0:01CD0CE2] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 13:02:03 -0000 OK, if you are looking for an organizationID that corresponds to the organizationName in the subject DN, I'd still suggest that regardless of what attribute type it is stored in, the value be constructed in accordance with the standard for identifying organizations, ISO/IEC 6523. It's possible to use any arbitrary value with local significance only, but that is the semantics of a Name, not an Identifier, and if a new attribute type is created to hold a local value, it should be called something like orgAltName, not orgID. Dave -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Wednesday, March 28, 2012 7:45 AM To: Kemp, David P.; pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute Hi David, I think this is where you derail: On 12-03-27 6:03 PM, "Kemp, David P." wrote: >The PI assigner is >the ORGANIZATION with which the subject is associated. No, the PI assigner is the organization that assigns the identifier. Not the organization within which the subject is associated. The assigner might be the DUNS och VAT registration authority. The subject's organization might be something completely different. /Stefan From DPKemp@missi.ncsc.mil Wed Mar 28 06:29:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3521F8946 for ; Wed, 28 Mar 2012 06:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b525jcAkbtmG for ; Wed, 28 Mar 2012 06:29:21 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1021F8945 for ; Wed, 28 Mar 2012 06:29:20 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2SDTKfh067374 for ; Wed, 28 Mar 2012 09:29:20 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 09:29:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Mar 2012 09:29:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAIAALZ4ggABmZgCAAFxigIAAdIoAgAAIyoD//8df0A== References: From: "Kemp, David P." To: X-OriginalArrivalTime: 28 Mar 2012 13:29:20.0545 (UTC) FILETIME=[C842E110:01CD0CE6] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 13:29:22 -0000 Neither Unique Identifier nor DN Qualifier fit the need. From X.520: 5.2.7 Unique Identifier The Unique Identifier attribute type specifies an identifier which may be used to distinguish between object references when a distinguished name has been reused. It may be, for example, an encoded object identifier, certificate, date, timestamp, or some other form of certification on the validity of the distinguished name. 5.2.8 DN Qualifier The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished name of an entry. It is intended to be used for entries held in multiple DSAs which would otherwise have the same name, and that its value be the same in a given DSA for all entries to which this information has been added. Unique Identifier applies to the full distinguished name, not a single RDN like organizationName. DN Qualifier is both specific to a DSA and has the disadvantage of opening the multi-valued RDN can of worms. Such a field would not be appropriate in a static object like a certificate that could be stored in multiple DSAs - its value might be correct for one DSA but would be incorrect for all others. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Wednesday, March 28, 2012 8:39 AM To: Stefan Santesson Cc: ; Sean Leonard Subject: Re: [pkix] Need for an organizationalIdentifier attribute On Mar 28, 2012, at 7:07 AM, Stefan Santesson wrote: > My use case is simply that I need to issue certs that reflect the=20 > identity carried in a SAML assertion. > Sometimes this will include an organizational identifier that I need=20 > to store in the subject RDN. > I can use a private attribute OID, but would prefer not to do so. Are you sticking to the suggested attribute types in the RFC, or are any X.520 types available? If you permit X.520, it seems simple enough; Unique Identifier & DN Qualifier could carry an encoded type/value pair. DN Qualifier is also in the 5280 suggested attributes, so that one kinda jumps out at me. -- T _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Wed Mar 28 06:52:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5B21F88D5 for ; Wed, 28 Mar 2012 06:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5X4kZuqhYPw for ; Wed, 28 Mar 2012 06:52:51 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5B21F8808 for ; Wed, 28 Mar 2012 06:52:50 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 45C3B1DC586B for ; Wed, 28 Mar 2012 15:52:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pVRUDi7kUoc8 for ; Wed, 28 Mar 2012 15:52:47 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E8B8E1DC5CAF for ; Wed, 28 Mar 2012 15:52:47 +0200 (CEST) Received: (qmail 49795 invoked from network); 28 Mar 2012 13:52:47 -0000 Received: from dhcp-105a.meeting.ietf.org (HELO [130.129.16.90]) (stefan@fiddler.nu@[130.129.16.90]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Mar 2012 13:52:47 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 28 Mar 2012 15:52:42 +0100 From: Stefan Santesson To: "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , Sean Leonard Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 13:52:52 -0000 Hi, Neither of them are listed as organizational attributes, as such they are not naturally associated with the organization. Both are AFAIK associated with the subject and not the subject's organization. If I recall right, both these attributes were abandoned from use in early versions of RFC5280 due to nasty encoding issues. So I would prefer a new organizational attribute /Stefan On 12-03-28 1:38 PM, "Miller, Timothy J." wrote: >On Mar 28, 2012, at 7:07 AM, Stefan Santesson wrote: > >> My use case is simply that I need to issue certs that reflect the >>identity >> carried in a SAML assertion. > >> Sometimes this will include an organizational identifier that I need to >> store in the subject RDN. > >> I can use a private attribute OID, but would prefer not to do so. > >Are you sticking to the suggested attribute types in the RFC, or are any >X.520 types available? If you permit X.520, it seems simple enough; >Unique Identifier & DN Qualifier could carry an encoded type/value pair. > >DN Qualifier is also in the 5280 suggested attributes, so that one kinda >jumps out at me. > >-- T >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Wed Mar 28 06:59:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F621F89FF for ; Wed, 28 Mar 2012 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muZ0eIHwT-Ac for ; Wed, 28 Mar 2012 06:59:02 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA8621F898D for ; Wed, 28 Mar 2012 06:59:01 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2SDx1Ix067924 for ; Wed, 28 Mar 2012 09:59:01 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 09:59:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Mar 2012 09:59:00 -0400 Message-ID: In-Reply-To: <4F729D41.5000200@seantek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0MoSLnYUa2S0+HQgOAq84lSzLqygAR7+mw References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> <4F729D41.5000200@seantek.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 28 Mar 2012 13:59:01.0108 (UTC) FILETIME=[ED8F3B40:01CD0CEA] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 13:59:03 -0000 You've just provided additional proof of Godwin's law, although PKIX is the last place I'd have expected to find it! The technical objections are all reasonable, but regardless of whether you believe the U.S. or any other country is equivalent to Auschwitz, it's an undeniable fact that every country in the world assigns serial numbers to people. I have a social security number in the U.S, an employer number created specifically to avoid using the SSN, a driver's license number issued by my state of residence, and an EDI_PI on my government-issued PKI token, just to name a few. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Sean Leonard Sent: Wednesday, March 28, 2012 1:10 AM To: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute I agree (with the detractors). serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] is a PrintableString that "specifies an identifier, the serial number of an object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is not; the range of Serial Number is very limited. The intent of the serial number is to record the serial number of inventory items, such as routers, Apple iPhones, tanks, and the like. A serial number is generally permanently etched onto an object. It's for property, not people. We do not assign serial numbers to human beings, unless you want to set up another Auschwitz or some Orwellian state. From DPKemp@missi.ncsc.mil Wed Mar 28 07:48:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ECB21E8278 for ; Wed, 28 Mar 2012 07:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAlkTDmg2d6B for ; Wed, 28 Mar 2012 07:48:59 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1792821E8255 for ; Wed, 28 Mar 2012 07:48:58 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2SEmwwq069151 for ; Wed, 28 Mar 2012 10:48:58 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 10:48:58 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Mar 2012 10:48:57 -0400 Message-ID: In-Reply-To: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: AQHNCRhGHDxOJ0LmskWzC91CnPICB5Z4Z3+AgAAEuYCABHKNgIAAF42A///5GwCAAHOmgIAAOXAAgACquwCAADtkAIABSsNQ References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 28 Mar 2012 14:48:58.0061 (UTC) FILETIME=[E7E1F7D0:01CD0CF1] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 14:48:59 -0000 This is (mostly) correct. The orgID does not identify the subject of the certificate, the issuer of the certificate, or the assigner of the subject's serialNumber. So the example is solved by putting O and orgID in the same multi-valued RDN. And unless you wanted to create a family of type-specific attributes to be placed in single-valued RDNs (orgID, orgUnit1ID, orgUnit2ID, orgUnit3ID, ...), putting the name and the ID in the same RDN is the only way to link them in general. It doesn't solve the serialNumber problem - the assigner is still unspecified since the serial number has no relationship to orgName/orgID. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Tuesday, March 27, 2012 10:50 AM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Need for an organizationalIdentifier attribute It seems to me that this is the whole reason why multi-valued RDNs are permitted in the first place. I.e., Stefan's example could be solved as: CN=3DJohn Doe\SERIALNUMBER=3D123456789 OU=3DExample Department O=3DExample AB\ORGIDTYPEANDVALUE=3D1.3.6.1.4.1.519.1;987654321 Of course, multi-value RDNs are a whole different can'o'worms. -- T From turners@ieca.com Wed Mar 28 08:25:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7E721E81F6 for ; Wed, 28 Mar 2012 08:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYFP9iHREx0M for ; Wed, 28 Mar 2012 08:25:20 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.82.15]) by ietfa.amsl.com (Postfix) with ESMTP id E970B21E8158 for ; Wed, 28 Mar 2012 08:25:19 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 479D21BDB55DB; Wed, 28 Mar 2012 10:25:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 3A6411BDB55BB for ; Wed, 28 Mar 2012 10:25:19 -0500 (CDT) Received: from [198.180.150.230] (port=58619 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SCukQ-0005kO-SJ for pkix@ietf.org; Wed, 28 Mar 2012 10:25:19 -0500 Message-ID: <4F732D5D.8020306@ieca.com> Date: Wed, 28 Mar 2012 17:25:17 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20120306124950.6304.26283.idtracker@ietfa.amsl.com> In-Reply-To: <20120306124950.6304.26283.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120306124950.6304.26283.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: v230.vpn.iad.rg.net (dhcp-2594.meeting.ietf.org) [198.180.150.230]:58619 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: I-D Action: draft-pettersen-tls-ext-multiple-ocsp-03.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, 28 Mar 2012 15:25:21 -0000 In case you weren't aware of this draft that's been bouncing around for a bit. Send comments to tls@ietf.org. spt -------- Original Message -------- Subject: I-D Action: draft-pettersen-tls-ext-multiple-ocsp-03.txt Date: Tue, 06 Mar 2012 04:49:50 -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 : Adding Multiple TLS Certificate Status Extension requests Author(s) : Yngve N. Pettersen Filename : draft-pettersen-tls-ext-multiple-ocsp-03.txt Pages : 9 Date : 2012-03-06 This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. Also being introduced is a new OCSP- based method that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pettersen-tls-ext-multiple-ocsp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-pettersen-tls-ext-multiple-ocsp-03.txt _______________________________________________ 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 dev+ietf@seantek.com Wed Mar 28 08:37:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD921E824C for ; Wed, 28 Mar 2012 08:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUfIVGWGVYYZ for ; Wed, 28 Mar 2012 08:37:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BD2CB21E8180 for ; Wed, 28 Mar 2012 08:37:02 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4412122E25E for ; Wed, 28 Mar 2012 11:36:56 -0400 (EDT) Message-ID: <4F733017.1040301@seantek.com> Date: Wed, 28 Mar 2012 08:36:55 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> <4F729D41.5000200@seantek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 15:37:04 -0000 Not to belabor the unsavory topic, but, my comparison was based on the=20 fact that a serial number is permanent and tangible property of an=20 object. We can pretty much all agree that a certificate's serial number=20 is intrinsic to its identity. You change the serial number, you get a=20 different certificate. If you have an iPod with a serial number, the=20 serial number is permanently etched onto the hardware and firmware. With the examples you provided, there are specific regulations and=20 exceptions that allow for people in the United States to change their=20 social security numbers, employer numbers, and driver's license numbers=20 (the greatest reason for allowing this, by the way, is privacy). Let's go back to *organization identifiers*, instead of permanent=20 identifiers for people. Unlike people, organizations are basically=20 creatures of the state. So, they can have numbers (like statewide or=20 countrywide corporate registration numbers) that are not expected to=20 change unless there is a change in the organization of the corporation.=20 Organizations are also public by their nature--generally even sole=20 proprietorships want to get their information "out there" in order to=20 conduct business. The CAB Forum is an example where they put unique Registration Numbers=20 in EV SSL certificates (ironically, in the serialNumber, but in any=20 event, as I said, the CAB Forum is interested in authenticating business = entities, not people). They have a specific profile that explicitly=20 spells out how the Registration Number in the serialNumber is=20 interpreted, via jurisdictionOfIncorporationCountryName [required],=20 jurisdictionOfIncorporationStateOrProvinceName [required if=20 disambiguates], and jurisdictionOfIncorporationLocalityName [required if = disambiguates]. Sean On 3/28/2012 6:59 AM, Kemp, David P. wrote: > You've just provided additional proof of Godwin's law, although PKIX is= > the last place I'd have expected to find it! > > The technical objections are all reasonable, but regardless of whether > you believe the U.S. or any other country is equivalent to Auschwitz, > it's an undeniable fact that every country in the world assigns serial > numbers to people. I have a social security number in the U.S, an > employer number created specifically to avoid using the SSN, a driver's= > license number issued by my state of residence, and an EDI_PI on my > government-issued PKI token, just to name a few. > > Dave > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of= > Sean Leonard > Sent: Wednesday, March 28, 2012 1:10 AM > To: pkix@ietf.org > Subject: Re: [pkix] Need for an organizationalIdentifier attribute > > I agree (with the detractors). > > serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] i= s > a PrintableString that "specifies an identifier, the serial number of a= n > object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is > not; the range of Serial Number is very limited. The intent of the > serial number is to record the serial number of inventory items, such a= s > routers, Apple iPhones, tanks, and the like. A serial number is > generally permanently etched onto an object. It's for property, not > people. We do not assign serial numbers to human beings, unless you wan= t > to set up another Auschwitz or some Orwellian state. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From dev+ietf@seantek.com Wed Mar 28 08:53:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D45821E8294 for ; Wed, 28 Mar 2012 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+yZ5XOM6iXi for ; Wed, 28 Mar 2012 08:53:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4621E80B8 for ; Wed, 28 Mar 2012 08:53:09 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A75BD22E1EB for ; Wed, 28 Mar 2012 11:53:08 -0400 (EDT) Message-ID: <4F7333E3.5080206@seantek.com> Date: Wed, 28 Mar 2012 08:53:07 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 15:53:33 -0000 On 3/28/2012 5:07 AM, Stefan Santesson wrote: > Hi Sean, > > Except for the fact that serialNumber (despite it's original intended use) > in practice is used world wide as the common attribute for a subject > distinguishing identifier, I think I agree with everything you say. > > On the defacto use of the serial number attribute, se standards like RFC > 3739 and ETSI TS 102 280. I concede the point about the serialNumber's practical use these days. However, RFC 3739 and ETSI TS 102 280 actually are more squishy: RFC 3739 sec. 3.1.2: "The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It MAY contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA's responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions." (ETSI TS 102 280 doesn't say anything different.) So as we see, the serialNumber doesn't have any structure--and to the extent that it has structure, it's a local matter for the CA. > My use case is simply that I need to issue certs that reflect the identity > carried in a SAML assertion. > Sometimes this will include an organizational identifier that I need to > store in the subject RDN. Okay. Have you considered a standardized, but protocol-specific, organizationSAMLIdentity attribute or something like that? In that case, the authority for disambiguating the identity devolves to the SAML spec. I have worked with SAML but am not sure I understand what you mean by "the identity carried in a SAML assertion." SAML carries a lot of random attributes and assertions, and you could be referring to one of several parties to a SAML transaction. Can you specify the specific protocol elements of SAML that you are trying to put into an RDN? -Sean From md@e-net.lt Wed Mar 28 12:21:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB7321F8958 for ; Wed, 28 Mar 2012 12:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m5FTdXy7jMz for ; Wed, 28 Mar 2012 12:21:33 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6981F21F895C for ; Wed, 28 Mar 2012 12:21:31 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.103]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SCyQy-0005BR-MR; Wed, 28 Mar 2012 22:21:28 +0300 Message-ID: <4F7364B5.3090504@e-net.lt> Date: Wed, 28 Mar 2012 22:21:25 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sean Leonard References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org> <4F729D41.5000200@seantek.com> <4F733017.1040301@seantek.com> In-Reply-To: <4F733017.1040301@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 19:21:34 -0000 Anybody can help me with a reference to the [formal] definitions of the two terms: "identifier" and "attribute"? I'm looking for a most "technology neutral" definition, something like: Identifier - a characteristics of a Subject that uniquely differentiates similar subjects. Attribute - a characteristics of a Subject. Thanks, M.D. On 3/28/2012 6:36 PM, Sean Leonard wrote: > Not to belabor the unsavory topic, but, my comparison was based on the > fact that a serial number is permanent and tangible property of an > object. We can pretty much all agree that a certificate's serial > number is intrinsic to its identity. You change the serial number, you > get a different certificate. If you have an iPod with a serial number, > the serial number is permanently etched onto the hardware and firmware. > > With the examples you provided, there are specific regulations and > exceptions that allow for people in the United States to change their > social security numbers, employer numbers, and driver's license > numbers (the greatest reason for allowing this, by the way, is privacy). > > Let's go back to *organization identifiers*, instead of permanent > identifiers for people. Unlike people, organizations are basically > creatures of the state. So, they can have numbers (like statewide or > countrywide corporate registration numbers) that are not expected to > change unless there is a change in the organization of the > corporation. Organizations are also public by their nature--generally > even sole proprietorships want to get their information "out there" in > order to conduct business. > > The CAB Forum is an example where they put unique Registration Numbers > in EV SSL certificates (ironically, in the serialNumber, but in any > event, as I said, the CAB Forum is interested in authenticating > business entities, not people). They have a specific profile that > explicitly spells out how the Registration Number in the serialNumber > is interpreted, via jurisdictionOfIncorporationCountryName [required], > jurisdictionOfIncorporationStateOrProvinceName [required if > disambiguates], and jurisdictionOfIncorporationLocalityName [required > if disambiguates]. > > Sean > > On 3/28/2012 6:59 AM, Kemp, David P. wrote: >> You've just provided additional proof of Godwin's law, although PKIX is >> the last place I'd have expected to find it! >> >> The technical objections are all reasonable, but regardless of whether >> you believe the U.S. or any other country is equivalent to Auschwitz, >> it's an undeniable fact that every country in the world assigns serial >> numbers to people. I have a social security number in the U.S, an >> employer number created specifically to avoid using the SSN, a driver's >> license number issued by my state of residence, and an EDI_PI on my >> government-issued PKI token, just to name a few. >> >> Dave >> >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Sean Leonard >> Sent: Wednesday, March 28, 2012 1:10 AM >> To: pkix@ietf.org >> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> >> I agree (with the detractors). >> >> serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] is >> a PrintableString that "specifies an identifier, the serial number of an >> object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is >> not; the range of Serial Number is very limited. The intent of the >> serial number is to record the serial number of inventory items, such as >> routers, Apple iPhones, tanks, and the like. A serial number is >> generally permanently etched onto an object. It's for property, not >> people. We do not assign serial numbers to human beings, unless you want >> to set up another Auschwitz or some Orwellian state. >> >> _______________________________________________ >> 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 DPKemp@missi.ncsc.mil Wed Mar 28 12:50:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31C621F87A4 for ; Wed, 28 Mar 2012 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id celwvDpO-MXk for ; Wed, 28 Mar 2012 12:50:11 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id C46C021F84F9 for ; Wed, 28 Mar 2012 12:50:11 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2SJoAh0076111 for ; Wed, 28 Mar 2012 15:50:10 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 15:50:10 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Mar 2012 15:50:10 -0400 Message-ID: In-Reply-To: <4F7364B5.3090504@e-net.lt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Need for an organizationalIdentifier attribute Thread-Index: Ac0NGAl4GIclZj79ThOJL41J3ifYbgAAnWqQ References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org><4F729D41.5000200@seantek.com><4F733017.1040301@seantek.com> <4F7364B5.3090504@e-net.lt> From: "Kemp, David P." To: X-OriginalArrivalTime: 28 Mar 2012 19:50:10.0885 (UTC) FILETIME=[FC200F50:01CD0D1B] Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 19:50:12 -0000 RFC 4949 says: $ attribute (N) Information of a particular type concerning an identifiable system entity or object. An "attribute type" is the component of an attribute that indicates the class of information given by the attribute; and an "attribute value" is a particular instance of the class of information indicated by an attribute type. $ identifier (I) A data object -- often, a printable, non-blank character string -- that definitively represents a specific identity of a system entity, distinguishing that identity from all others. (Compare: identity.) Tutorial: Identifiers for system entities must be assigned very carefully, because authenticated identities are the basis for other security services, such as access control service. ISO 6523 defines identifier as "A character or group of characters constituting a data element value used to identify or name an object and possibly to indicate certain properties of that object". ISO 11179 defines attribute as "A characteristic of an object or entity". The RFC 4949 definitions are more IT-oriented; the more colloquial definition of attribute in ISO 11179 assumes knowledge that a "characteristic" inherently must have both a type (e.g., "color") and a value (e.g., "red"). Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Moudrick M. Dadashov Sent: Wednesday, March 28, 2012 3:21 PM To: Sean Leonard Cc: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute Anybody can help me with a reference to the [formal] definitions of the two terms: "identifier" and "attribute"? I'm looking for a most "technology neutral" definition, something like: Identifier - a characteristics of a Subject that uniquely differentiates similar subjects. Attribute - a characteristics of a Subject. Thanks, M.D. From md@e-net.lt Wed Mar 28 13:21:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16A21E8106 for ; Wed, 28 Mar 2012 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlv5pWCI9NFr for ; Wed, 28 Mar 2012 13:21:22 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id D74CF21E8105 for ; Wed, 28 Mar 2012 13:21:21 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.103]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SCzMu-0006VM-B1 for pkix@ietf.org; Wed, 28 Mar 2012 23:21:20 +0300 Message-ID: <4F7372C4.1040306@e-net.lt> Date: Wed, 28 Mar 2012 23:21:24 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <733383E2-0A3F-4920-B39B-01D6F693BBF9@mitre.org><4F729D41.5000200@seantek.com><4F733017.1040301@seantek.com> <4F7364B5.3090504@e-net.lt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 20:21:24 -0000 Many thanks.. M.D. On 3/28/2012 10:50 PM, Kemp, David P. wrote: > RFC 4949 says: > > $ attribute > (N) Information of a particular type concerning an identifiable > system entity or object. An "attribute type" is the component of > an attribute that indicates the class of information given by the > attribute; and an "attribute value" is a particular instance of > the class of information indicated by an attribute type. > > $ identifier > (I) A data object -- often, a printable, non-blank character > string -- that definitively represents a specific identity of a > system entity, distinguishing that identity from all others. > (Compare: identity.) > > Tutorial: Identifiers for system entities must be assigned very > carefully, because authenticated identities are the basis for > other security services, such as access control service. > > ISO 6523 defines identifier as "A character or group of characters > constituting a data element value used to identify or name an object and > possibly to indicate certain properties of that object". > > ISO 11179 defines attribute as "A characteristic of an object or > entity". > > The RFC 4949 definitions are more IT-oriented; the more colloquial > definition of attribute in ISO 11179 assumes knowledge that a > "characteristic" inherently must have both a type (e.g., "color") and a > value (e.g., "red"). > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Moudrick M. Dadashov > Sent: Wednesday, March 28, 2012 3:21 PM > To: Sean Leonard > Cc: pkix@ietf.org > Subject: Re: [pkix] Need for an organizationalIdentifier attribute > > Anybody can help me with a reference to the [formal] definitions of the > two terms: "identifier" and "attribute"? > > I'm looking for a most "technology neutral" definition, something like: > > Identifier - a characteristics of a Subject that uniquely differentiates > similar subjects. > Attribute - a characteristics of a Subject. > > Thanks, > M.D. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From david.cooper@nist.gov Wed Mar 28 15:25:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326621E8108 for ; Wed, 28 Mar 2012 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMXtvorFzvME for ; Wed, 28 Mar 2012 15:25:31 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 10DAC21E8122 for ; Wed, 28 Mar 2012 15:25:30 -0700 (PDT) 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 q2SMPMOL027551 for ; Wed, 28 Mar 2012 18:25:22 -0400 Message-ID: <4F738FD2.8060104@nist.gov> Date: Wed, 28 Mar 2012 18:25:22 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: PKIX References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 28 Mar 2012 22:25:31 -0000 On 03/26/2012 04:19 AM, Stephen Kent wrote: 
All three of the blocks of text that appear in my message were sent 
to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to 
David. There was
no disagreement with the wording I proposed. David chose to ignore 
two of blocks of text, and transformed the first one into the text 
that you prefer. So, we have an internal communication problem with 
the author :-).

When Steve Kent sent me these three blocks of text, the only thing that his message said about the text was "Here is proposed text for 5280bis to move forward."  There was no indication in any way that the text had been reviewed by anyone else before Steve sent it to me.  I did not use the first block of text that Steve proposed as it appeared to state that self-signed end-entity certificates MUST be marked as CA certificates, and so I did my best to come up with alternative text.  I tried my best to incorporate the ideas from the other two blocks of text, but I incorporated the ideas into areas of the document that were more appropriate: mention of RFC 5937 in the text that already mentions using extensions in a self-signed certificate to set the inputs to path validation and mention of actions that a malicious CA could take in the paragraph that discusses the risk of CA compromise.

When I posted the draft I asked Sean Turner if it was acceptable to him, since the draft was updated based on a request from him to address self-signed end-entity certificates (http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean said that he thought the revised draft looked okay.

I saw that this draft was discussed during the PKIX session:
This topic was added at the beginning of the meeting, at Paul Hoffman's request. David Cooper, the document author was not present. Paul suggests that we work on the list to revise the text dealing with self-signed end-entity certificates, as the primary, remaining open issue for this document. Steve Kent agreed to work with Paul on revised text on this topic.

So, I expect to see new text on self-signed end-entity certificates proposed on the list at some point.  In addition, Paul Hoffman has proposed updated text for the Abstract and Introduction.  Unless I see further discussion on the list, I will take the meeting minutes to indicate that no further changes are required to any of the other text in the draft.

From stefan@aaa-sec.com Thu Mar 29 01:40:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738BE21F8810 for ; Thu, 29 Mar 2012 01:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHyiOU19ogCl for ; Thu, 29 Mar 2012 01:40:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38021F86B1 for ; Thu, 29 Mar 2012 01:40:54 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9C0B71DE5AD7 for ; Thu, 29 Mar 2012 10:40:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 44R40xXYpEYP for ; Thu, 29 Mar 2012 10:40:51 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3C6161DE735A for ; Thu, 29 Mar 2012 10:40:51 +0200 (CEST) Received: (qmail 37343 invoked from network); 29 Mar 2012 08:40:51 -0000 Received: from dhcp-105a.meeting.ietf.org (HELO [130.129.16.90]) (stefan@fiddler.nu@[130.129.16.90]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2012 08:40:51 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 29 Mar 2012 10:40:39 +0100 From: Stefan Santesson To: "Moudrick M. Dadashov" , Message-ID: Thread-Topic: Art of changing subject of a thread: was Re: [pkix] Need for an organizationalIdentifier attribute In-Reply-To: <4F7372C4.1040306@e-net.lt> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Art of changing subject of a thread: was Re: Need for an organizationalIdentifier attribute X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 29 Mar 2012 08:40:55 -0000 It's perfectly fine to ask questions that are not related to the topic being discussed. However, when doing so, please change the subject of discussion (as I did with this mail. This helps avoiding two discussions to be carried out under the same subject. Thanks. /Stefan On 12-03-28 9:21 PM, "Moudrick M. Dadashov" wrote: >Many thanks.. > >M.D. > >On 3/28/2012 10:50 PM, Kemp, David P. wrote: >> RFC 4949 says: >> >> $ attribute >> (N) Information of a particular type concerning an identifiable >> system entity or object. An "attribute type" is the component of >> an attribute that indicates the class of information given by the >> attribute; and an "attribute value" is a particular instance of >> the class of information indicated by an attribute type. >> >> $ identifier >> (I) A data object -- often, a printable, non-blank character >> string -- that definitively represents a specific identity of a >> system entity, distinguishing that identity from all others. >> (Compare: identity.) >> >> Tutorial: Identifiers for system entities must be assigned very >> carefully, because authenticated identities are the basis for >> other security services, such as access control service. >> >> ISO 6523 defines identifier as "A character or group of characters >> constituting a data element value used to identify or name an object and >> possibly to indicate certain properties of that object". >> >> ISO 11179 defines attribute as "A characteristic of an object or >> entity". >> >> The RFC 4949 definitions are more IT-oriented; the more colloquial >> definition of attribute in ISO 11179 assumes knowledge that a >> "characteristic" inherently must have both a type (e.g., "color") and a >> value (e.g., "red"). >> >> Dave >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Moudrick M. Dadashov >> Sent: Wednesday, March 28, 2012 3:21 PM >> To: Sean Leonard >> Cc: pkix@ietf.org >> Subject: Re: [pkix] Need for an organizationalIdentifier attribute >> >> Anybody can help me with a reference to the [formal] definitions of the >> two terms: "identifier" and "attribute"? >> >> I'm looking for a most "technology neutral" definition, something like: >> >> Identifier - a characteristics of a Subject that uniquely differentiates >> similar subjects. >> Attribute - a characteristics of a Subject. >> >> Thanks, >> M.D. >> >> _______________________________________________ >> 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 pala@isis.poly.edu Thu Mar 29 02:28:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FFC21F88D2 for ; Thu, 29 Mar 2012 02:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CQo28BKb22z for ; Thu, 29 Mar 2012 02:28:24 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id A116021F88B7 for ; Thu, 29 Mar 2012 02:28:24 -0700 (PDT) Received: (qmail 85065 invoked from network); 29 Mar 2012 09:28:16 -0000 Received: from unknown (HELO titan.openca.dyndns.org) (madwolf@82.225.250.52) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 29 Mar 2012 09:28:16 -0000 Message-ID: <4F742B28.9070402@isis.poly.edu> Date: Thu, 29 Mar 2012 11:28:08 +0200 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] Question about parameters in X509 certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pala@isis.poly.edu List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:28:25 -0000 Hi all, I am trying to understand (and back it up with normative references) what type of parameter specifications for DSA and EC are allowed (especially for US Federal Issued Certs). In particular, I think that RFC5480 says that implicitCurve MUST NOT be used in PKIX compliant certs, and, from the Common Policy framework for the federal government it seems that that is backed up also in that document. It is unclear, to me, the DSS case. In particular, in RFC 3279 , section 2.3.2, says: "The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key. If the DSA domain parameters are omitted from the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the subject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the subject's DSA parameters are not available through other means, then clients MUST reject the certificate." Does this still stands ? Is the case for omitted parameters for the DSS certs still supported by pkix ? IF so, do you know about the Federal Bridge PKI / other environment that use/ever used DSA certs with null parameters (to be imported from the CA or other means) ? Cheers, -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director& Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu From housley@vigilsec.com Thu Mar 29 03:29:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0B621F8931 for ; Thu, 29 Mar 2012 03:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKFeJdXL-RSP for ; Thu, 29 Mar 2012 03:29:14 -0700 (PDT) Received: from services-1.meeting.ietf.org (unknown [IPv6:2001:df8:0:5::6]) by ietfa.amsl.com (Postfix) with ESMTP id D671221F8927 for ; Thu, 29 Mar 2012 03:29:13 -0700 (PDT) Received: from [IPv6:2001:df8::32:6233:4bff:fe20:eb18] (unknown [IPv6:2001:df8:0:32:6233:4bff:fe20:eb18]) by services-1.meeting.ietf.org (Postfix) with ESMTP id B22F0688E3; Thu, 29 Mar 2012 10:29:08 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4F742B28.9070402@isis.poly.edu> Date: Thu, 29 Mar 2012 06:29:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F742B28.9070402@isis.poly.edu> To: pala@isis.poly.edu X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] Question about parameters in X509 certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 29 Mar 2012 10:29:14 -0000 Max: > I am trying to understand (and back it up with normative references) = what type of parameter specifications > for DSA and EC are allowed (especially for US Federal Issued Certs). >=20 > In particular, I think that RFC5480 says that implicitCurve MUST NOT = be used in PKIX compliant certs, > and, from the Common Policy framework for the federal government it = seems that that is backed up > also in that document. >=20 > It is unclear, to me, the DSS case. In particular, in RFC 3279 , = section 2.3.2, says: >=20 > "The AlgorithmIdentifier within subjectPublicKeyInfo is the only place = within a certificate where > the parameters may be used. If the DSA algorithm parameters are = omitted from the subjectPublicKeyInfo > AlgorithmIdentifier and the CA signed the subject certificate using = DSA, then the certificate issuer's DSA > parameters apply to the subject's DSA key. If the DSA domain = parameters are omitted from the SubjectPublicKeyInfo > AlgorithmIdentifier and the CA signed the subject certificate using a = signature algorithm other than DSA, then the > subject's DSA domain parameters are distributed by other means. If the = subjectPublicKeyInfo AlgorithmIdentifier > field omits the parameters component, the CA signed the subject with a = signature algorithm other than DSA, and the > subject's DSA parameters are not available through other means, then = clients MUST reject the certificate." >=20 > Does this still stands ? Is the case for omitted parameters for the = DSS certs still supported by pkix ? > IF so, do you know about the Federal Bridge PKI / other environment = that use/ever used DSA certs with > null parameters (to be imported from the CA or other means) ? Yes, this still stands. If you are concerned about this is a bridge CA environment, the safe = thing to do is always include the DSA or ECDSA parameters in the subject = public key. In the ECDSA case, it can be a single OID. Russ From turners@ieca.com Thu Mar 29 05:01:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAC021F8A31 for ; Thu, 29 Mar 2012 05:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZGuwBQYpnY3 for ; Thu, 29 Mar 2012 05:01:41 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [64.5.50.2]) by ietfa.amsl.com (Postfix) with ESMTP id C7E9521F8A23 for ; Thu, 29 Mar 2012 05:01:41 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 684212092496E; Thu, 29 Mar 2012 07:01:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 491E9209248AE for ; Thu, 29 Mar 2012 07:01:41 -0500 (CDT) Received: from [198.180.150.230] (port=60643 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDE2u-0001L4-Er; Thu, 29 Mar 2012 07:01:40 -0500 Message-ID: <4F744F23.4060907@ieca.com> Date: Thu, 29 Mar 2012 14:01:39 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pala@isis.poly.edu References: <4F742B28.9070402@isis.poly.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (dhcp-2594.meeting.ietf.org) [198.180.150.230]:60643 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" Subject: Re: [pkix] Question about parameters in X509 certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 29 Mar 2012 12:01:42 -0000 On 3/29/12 12:29 PM, Russ Housley wrote: > Max: > >> I am trying to understand (and back it up with normative references) what type of parameter specifications >> for DSA and EC are allowed (especially for US Federal Issued Certs). >> >> In particular, I think that RFC5480 says that implicitCurve MUST NOT be used in PKIX compliant certs, >> and, from the Common Policy framework for the federal government it seems that that is backed up >> also in that document. >> >> It is unclear, to me, the DSS case. In particular, in RFC 3279 , section 2.3.2, says: >> >> "The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where >> the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfo >> AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA >> parameters apply to the subject's DSA key. If the DSA domain parameters are omitted from the SubjectPublicKeyInfo >> AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the >> subject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier >> field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the >> subject's DSA parameters are not available through other means, then clients MUST reject the certificate." >> >> Does this still stands ? Is the case for omitted parameters for the DSS certs still supported by pkix ? >> IF so, do you know about the Federal Bridge PKI / other environment that use/ever used DSA certs with >> null parameters (to be imported from the CA or other means) ? > > Yes, this still stands. > > If you are concerned about this is a bridge CA environment, the safe thing to do is always include the DSA or ECDSA parameters in the subject public key. In the ECDSA case, it can be a single OID. Best to just always include the parameter, which is just the curve's OID. spt From denis.pinkas@bull.net Thu Mar 29 05:23:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0571221F8A9D for ; Thu, 29 Mar 2012 05:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s5ChYLbi0ve for ; Thu, 29 Mar 2012 05:23:44 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6021F8A9B for ; Thu, 29 Mar 2012 05:23:43 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id CD29B18008; Thu, 29 Mar 2012 14:23:42 +0200 (CEST) In-Reply-To: <4F738FD2.8060104@nist.gov> References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> <4F738FD2.8060104@nist.gov> To: "David A. Cooper" MIME-Version: 1.0 X-KeepSent: 3ED657D2:047BB764-C12579D0:00433A7A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Thu, 29 Mar 2012 14:23:42 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 29/03/2012 14:23:42, Serialize complete at 29/03/2012 14:23:42 Content-Type: multipart/alternative; boundary="=_alternative 0043F937C12579D0_=" Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 29 Mar 2012 12:23:46 -0000 Message en plusieurs parties au format MIME --=_alternative 0043F937C12579D0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable David, A point I mentioned during my presentation about rfc2560bis (slide 3). " which keyUsage bits and extended key usage OIDs shall be present=20 in the CA certificate is not even said". In RFC 5280 , for the key usage bits we have in particular: keyCertSign (5), cRLSign (6), We do not have OCSPSign. It would be nice both in RFC 5280 and in rfc2560bis to clarify which=20 fields or extensions allow to know=20 that the entity is allowed to sign OCSP responses directly. Denis=20 De : "David A. Cooper" A : PKIX Date : 29/03/2012 00:25 Objet : Re: [pkix] 5280 clarifications Envoy=E9 par : pkix-bounces@ietf.org On 03/26/2012 04:19 AM, Stephen Kent wrote:=20 All three of the blocks of text that appear in my message were sent=20 to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to=20 David. There was no disagreement with the wording I proposed. David chose to ignore=20 two of blocks of text, and transformed the first one into the text=20 that you prefer. So, we have an internal communication problem with=20 the author :-). When Steve Kent sent me these three blocks of text, the only thing that=20 his message said about the text was "Here is proposed text for 5280bis to=20 move forward." There was no indication in any way that the text had been=20 reviewed by anyone else before Steve sent it to me. I did not use the=20 first block of text that Steve proposed as it appeared to state that=20 self-signed end-entity certificates MUST be marked as CA certificates, and = so I did my best to come up with alternative text. I tried my best to=20 incorporate the ideas from the other two blocks of text, but I=20 incorporated the ideas into areas of the document that were more=20 appropriate: mention of RFC 5937 in the text that already mentions using=20 extensions in a self-signed certificate to set the inputs to path=20 validation and mention of actions that a malicious CA could take in the=20 paragraph that discusses the risk of CA compromise. When I posted the draft I asked Sean Turner if it was acceptable to him,=20 since the draft was updated based on a request from him to address=20 self-signed end-entity certificates ( http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean = said that he thought the revised draft looked okay. I saw that this draft was discussed during the PKIX session: This topic was added at the beginning of the meeting, at Paul Hoffman's=20 request. David Cooper, the document author was not present. Paul suggests=20 that we work on the list to revise the text dealing with self-signed=20 end-entity certificates, as the primary, remaining open issue for this=20 document. Steve Kent agreed to work with Paul on revised text on this=20 topic. So, I expect to see new text on self-signed end-entity certificates=20 proposed on the list at some point. In addition, Paul Hoffman has=20 proposed updated text for the Abstract and Introduction. Unless I see=20 further discussion on the list, I will take the meeting minutes to=20 indicate that no further changes are required to any of the other text in=20 the draft. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0043F937C12579D0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable David,

A point I mentioned during my presen= tation about rfc2560bis (slide 3).

" which keyUsage bits and exten= ded key usage OIDs shall be present
in the CA certificate is not even sa= id".

In RFC 5280 , for the key usage bits we have in particular:

keyCertSign             (5),
cRLSign                 (6),

We do not have OCSPSign.

It would be nice both in RFC 5280 and in rfc2560bis to clarify which fields or extensions allow to know
that the entity is allowed to sign OCSP responses directly.

Denis




De :     &= nbsp;  "David A. Cooper" <david.cooper@nist.gov>
A :     &n= bsp;  PKIX <pkix@ietf.org><= /font>
Date :    =    29/03/2012 00:25
Objet :        Re: [pkix] 5280 clarifications
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



On 03/26/2012 04:19 AM, Stephen Kent wrote:
All three of the blocks of text that appear in my message were sent
to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to
David. There was
no disagreement with the wording I proposed. David chose to ignore
two of blocks of text, and transformed the first one into the text
that you prefer. So, we have an internal communication problem with
the author :-).

When Steve Kent sent me these three blocks of text, the only thing that his message said about the text was "Here is proposed text for 5280bis to move forward."  There was no indication in any way that the text had been reviewed by anyone else before Steve sent it to me.  I did not use the first block of text that Steve proposed as it appeared to state that self-signed end-entity certificates MUST be marked as CA certificates, and so I did my best to come up with alternative text.  I tried my best to incorporate the ideas from the other two blocks of text, but I incorporated the ideas into areas of the document that were more appropriate: mention of RFC 5937 in the text that already mentions using extensions in a self-signed certificate to set the inputs to path validation and mention of actions that a malicious CA could take in the paragraph that discusses the risk of CA compromise.

When I posted the draft I asked Sean Turner if it was acceptable to him, since the draft was updated based on a request from him to address self-sig= ned end-entity certificates (http://www.= ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean said that he thought the revised draft looked okay.

I saw that this draft was discussed during the PKIX session:
This topic was added at the beginning of the meeting, at Paul Hoffman's request. David Cooper, the document author was not presen= t. Paul suggests that we work on the list to revise the text dealing with self-signed end-entity certificates, as the primary, remaining open issue for this document. Steve Kent agreed to work with Paul on revised text on this topic.

So, I expect to see new text on self-signed end-entity certificates proposed on the list at some point.  In addition, Paul Hoffman has proposed updated text for the Abstract and Introduction.  Unless I see further discussion on the list, I will take the meeting minutes to indicate that no further changes are required to any of the other text in the draft.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0043F937C12579D0_=-- From hallam@gmail.com Thu Mar 29 11:42:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8F21F87EB for ; Thu, 29 Mar 2012 11:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0-v6hPfeHCK for ; Thu, 29 Mar 2012 11:42:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A77921F877F for ; Thu, 29 Mar 2012 11:42:21 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1019186obb.31 for ; Thu, 29 Mar 2012 11:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HAYVhxpvILoLH1lIW3bEKmN4ziZT0hW2CLgdI/G8SGc=; b=SbipiUVKCnD0fbU3Fu4usFLpEWSZNZ3FpAqTGa6LUUzcOSJeOYJthmVnBJyspaSVdB cWHy2MJKgv6rdeBOj8qnIu/Ddpfxk/Wn71UkH/VUYyfrGvUr7JOBgeInnlhc5JyiF151 a2aJr/75oXs1cMZrZ2uGjApVrTtr2eP7XHxE3b1lmmvLRWJRluIDV7JQgJxVUc5xKbXU cpBBBwg2I19Sr8eDlvemeGzE6vHjkJcMpGY+6+sexPRVLrUWPzQS6qlC/+r45AtYjA9l 1muMqOTD0CHQJ3EjjKMK7PZFubdw8uW9A55+ptajKdLo8XgneGI2ktzC+hycvwysbJJM zw6g== MIME-Version: 1.0 Received: by 10.182.139.33 with SMTP id qv1mr17078708obb.10.1333046540731; Thu, 29 Mar 2012 11:42:20 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Thu, 29 Mar 2012 11:42:20 -0700 (PDT) In-Reply-To: <4F72FDF3.1080206@KingsMountain.com> References: <4F72FDF3.1080206@KingsMountain.com> Date: Thu, 29 Mar 2012 14:42:20 -0400 Message-ID: From: Phillip Hallam-Baker To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF PKIX WG , Ben Laurie Subject: Re: [pkix] Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:42:37 -0000 Umm, it is trusted to provide a service but constrained in the service it provides. If there was only one DNS registrar, that company could keep you off the Internet by refusing to provide you with any domain. If there are multiple registrars then this becomes a less practical attack but so does the SK protocol. Given the lack of details that the authors of these proposals have provided, I am really not sure what is part of their proposal and what is being read into them by reviewers. Like certain politicians policy proposals they can satisfy everyone right up until they are required to specify them in sufficient detail that people can see what it does not cover. Very often a protocol design will be able to support A or B but not both. You can eliminate false positives in spam filtering very easily, as you can with false negatives: just accept everything or nothing. Yet during the DKIM discussions we had people whose approach to policy was that the client would use algorithm A to interpret it in one case and algorithm B to interpret it in another. And they just would not accept the fact that this was not a solution to the problem On Wed, Mar 28, 2012 at 8:02 AM, =JeffH wrote: > [ trimming cc: to just pkix@ ] > [ topic trimmed to Revocation and TLS/SSL Replacements/Enhancements ] > >> a) Doesn't mention Certificate Transparency. > > indeed. neither did it mention CRLSets. > > >> b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is >> a TTP, which is incorrect. > > I tend to agree, tho it depends on how one defines a trust 3d party (TTP). > Their definition is different than yours it would seem. > > > =JeffH > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From rob.stradling@comodo.com Thu Mar 29 13:05:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABC21E805F for ; Thu, 29 Mar 2012 13:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPEza0coH9t2 for ; Thu, 29 Mar 2012 13:05:14 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC9B21E801F for ; Thu, 29 Mar 2012 13:05:13 -0700 (PDT) Received: (qmail 1210 invoked from network); 29 Mar 2012 20:05:12 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 29 Mar 2012 20:05:12 -0000 Received: (qmail 27883 invoked by uid 1000); 29 Mar 2012 20:05:12 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 29 Mar 2012 21:05:12 +0100 Message-ID: <4F74C077.4050103@comodo.com> Date: Thu, 29 Mar 2012 21:05:11 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: "pkix@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Kathleen Wilson Subject: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:05:15 -0000 RFC5280 says: "4.2.1.10. Name Constraints ...Conforming CAs MUST mark this extension as critical" Can anyone explain the reason for this requirement? Mozilla are currently considering requiring CAs in their Root Program to include the Name Constraints extension in "external" subordinate CA certificates (i.e. where the holder of the sub-CA private key is a different organization to the Root CA). Setting the critical flag would cause any software that doesn't recognize the Name Constraints extension to barf. I'm told that Apple's iOS and OSX platforms are among those that don't recognize the Name Constraints extension, so specifying critical Name Constraints is a non-starter. Therefore, Mozilla's current plan is to recommend that Name Constraints be non-critical. Should RFC5280 be updated to specify that Name Constraints need not be critical? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From SChokhani@cygnacom.com Thu Mar 29 13:09:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5664821E805F for ; Thu, 29 Mar 2012 13:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEi-Je67AbJT for ; Thu, 29 Mar 2012 13:09:39 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id A974C21E801A for ; Thu, 29 Mar 2012 13:09:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,669,1330923600"; d="scan'208";a="4542925" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 29 Mar 2012 16:09:36 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 29 Mar 2012 16:09:36 -0400 From: Santosh Chokhani To: Rob Stradling , "pkix@ietf.org" Date: Thu, 29 Mar 2012 16:09:35 -0400 Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0N512B5EDUo3U1RxKrhFkwjJiq3QAAEkrg Message-ID: References: <4F74C077.4050103@comodo.com> In-Reply-To: <4F74C077.4050103@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:09:40 -0000 It is critical so that relying parties that do not understand this extensio= n do not unwittingly accept a certificate that has been issued for a name s= pace the CA is specifically prohibited from. If the extension was made NC, relying party will accept a certificate for w= hich the CA has violated the constraint. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob= Stradling Sent: Thursday, March 29, 2012 4:05 PM To: pkix@ietf.org Cc: Kathleen Wilson Subject: [pkix] Criticality of Name Constraints in 5280 RFC5280 says: "4.2.1.10. Name Constraints ...Conforming CAs MUST mark this extension as critical" Can anyone explain the reason for this requirement? Mozilla are currently considering requiring CAs in their Root Program to in= clude the Name Constraints extension in "external" subordinate CA certifica= tes (i.e. where the holder of the sub-CA private key is a different organiz= ation to the Root CA). Setting the critical flag would cause any software that doesn't recognize t= he Name Constraints extension to barf. I'm told that Apple's iOS and OSX p= latforms are among those that don't recognize the Name Constraints extensio= n, so specifying critical Name Constraints is a non-starter. Therefore, Mo= zilla's current plan is to recommend that Name Constraints be non-critical. Should RFC5280 be updated to specify that Name Constraints need not be crit= ical? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From agl@google.com Thu Mar 29 13:14:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FBE21E80C3 for ; Thu, 29 Mar 2012 13:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iPw8t4x0Ghp for ; Thu, 29 Mar 2012 13:14:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC421E805F for ; Thu, 29 Mar 2012 13:14:31 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2005902ggm.31 for ; Thu, 29 Mar 2012 13:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=fTH8rVqsahBaJuAf7hAgENVJVbWguDL/I2TnRBLcfhA=; b=bltdxniuY/aoCKbvfarW+bnFVMgGdwYIu14ScWpxQyGUvUuXddsiuXWBNLv5G7hQx1 HsTKcie3bpdHM1BgjyfST9Qkts4flMCTNw33a6t3CYGNKuquoSd9U3PfmDQcXhC5CT1l Cucp3v5iX+0I2684rQsmUReFMn43Dkq3OgwoIq3gR7PaI7Hr+NCrERGYOHzLcVIq56R8 eg6DQDCjoO5ikVeqfM/OKJX85Jh2gQIqh1sLIuWOlH5qDSz3ytoe5CR4INxligFxNhsr EngWspXjxu8xIp1spl586YB05NPcQXgBo7O99uFiUjVvGYWuRqV7iZwssJfv+zM6Egsr UvtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fTH8rVqsahBaJuAf7hAgENVJVbWguDL/I2TnRBLcfhA=; b=ZPT+aNkpmAK61g+oGlZLZd0GBLAuerY5nGD3GVaa3PpH0slrZrfnHz8n3ukQR5JPra fD5UALEGTElDVkAcFUpE5xSFye+J/+jo/kpdlzbYiZoEzEep91t2bvTZ/YcxN+MXtcz1 mLWdOrtWkS0ZRsx4WNdeq3JwKo1T3OzEh7o4maLXNCunzFHOvlxZIYhJzdAXEZg6H7Dt mUQITdNZpUOZ7zXiX1L6KUkttoZ825GwlQy/YhhN+TzMS6NWVzXbqhnkghbSJZsFfE5f 4BvVtoEAoJt+z2/yos7cNCCRU9IYUk91S/TmPws9isOO+x02MSJ5ZOpvRnvCjJ60162n 4F9A== Received: by 10.50.191.169 with SMTP id gz9mr2846483igc.5.1333052070386; Thu, 29 Mar 2012 13:14:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.191.169 with SMTP id gz9mr2846015igc.5.1333052066865; Thu, 29 Mar 2012 13:14:26 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Thu, 29 Mar 2012 13:14:26 -0700 (PDT) In-Reply-To: <4F74C077.4050103@comodo.com> References: <4F74C077.4050103@comodo.com> Date: Thu, 29 Mar 2012 16:14:26 -0400 Message-ID: From: Adam Langley To: Rob Stradling Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmZkujm9AWkNpbTMKo8saB4yUhMDwDpDieQJyuuwb56FfrIPjv0d/TkupzmFcuCbbXUHlLeId/SqJaEZXtMTOOJFuJrXTBoiY9LlG6X65l+YcjKRgM5f/dkYLSb+58VlVWFlEVn Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:14:32 -0000 On Thu, Mar 29, 2012 at 4:05 PM, Rob Stradling wrote: > Should RFC5280 be updated to specify that Name Constraints need not be > critical? If the certificate would otherwise have been an unrestricted intermediate CA then obviously non-critical Name Constraints are beneficial. I'm not aware of any software that enforces this requirement and agree that the MUST in RFC 5280 is unhelpful and support the idea that it should be removed. Cheers AGL From carl@redhoundsoftware.com Thu Mar 29 13:34:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB10821E80CD for ; Thu, 29 Mar 2012 13:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIRCnxUIkcIB for ; Thu, 29 Mar 2012 13:34:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4F21E80CA for ; Thu, 29 Mar 2012 13:34:46 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1997610yhk.31 for ; Thu, 29 Mar 2012 13:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=W6u3PRvUGT2Z0pSt+RafT3pvPTeJe+Zjt4XDE3qH+zI=; b=HyWIHpvbTL8hegfBgtR63RwJ9/DOR5ponfIwW/yPkaSOPhB+nd7aEtc6yquLvMr4Jm CzFXzdAFL7YBOzuPzznspliWaH5nKHMAKvOsh0AwISmqgon83nYJqW3XmI6X6I6rlVjQ +ij/RW3cfRu5dZe5m5raP2nt0VJQkpHz8FF0qe9Xp/deIK6PChzWtiIZCszJv5VCkQSE HdISkuJIx+LwkjcO5vxYdoSAl+/yQCR0agABSYO9kI/EQsBbOuAoi534UQwrDmj+wQ18 adccErn18IhdTr7riHA+RAjhhoPxkvs+kOtfYBURQAzVYli386zkzOaHrU9N18tsQEMU rvEw== Received: by 10.236.116.66 with SMTP id f42mr35763839yhh.70.1333053285976; Thu, 29 Mar 2012 13:34:45 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id o41sm19110846yhj.7.2012.03.29.13.34.24 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 13:34:45 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 29 Mar 2012 16:34:06 -0400 From: Carl Wallace To: Adam Langley , Rob Stradling Message-ID: Thread-Topic: [pkix] Criticality of Name Constraints in 5280 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkMdxOq0vdwQ02ayJVUVCKjy53sJHd44wT0oj4GTd7GB6DWVadd9dconrhwYwiTyqkzW++Y Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:34:47 -0000 On 3/29/12 4:14 PM, "Adam Langley" wrote: >On Thu, Mar 29, 2012 at 4:05 PM, Rob Stradling >wrote: >> Should RFC5280 be updated to specify that Name Constraints need not be >> critical? > >If the certificate would otherwise have been an unrestricted >intermediate CA then obviously non-critical Name Constraints are >beneficial. What do you mean by otherwise unrestricted? That sounds like the question is whether to include name constraints at all. > >I'm not aware of any software that enforces this requirement and agree >that the MUST in RFC 5280 is unhelpful and support the idea that it >should be removed. Do you mean you are not aware of any path validation software that enforces name constraints, any path validation software that requires name constraints to be critical or any CA software that requires name constraints to be critical when generating certificates? From agl@google.com Thu Mar 29 13:46:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483DE21E801B for ; Thu, 29 Mar 2012 13:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jQBxN8sgKqv for ; Thu, 29 Mar 2012 13:46:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8AB521E805F for ; Thu, 29 Mar 2012 13:46:16 -0700 (PDT) Received: by yenm5 with SMTP id m5so2017378yen.31 for ; Thu, 29 Mar 2012 13:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type:content-transfer-encoding; bh=LH9LzAwaSX905W6qivtZDyhYILRyM8WHhJ8p0w0J0Mo=; b=cB0rgEpFXzL67xibTe9UWkLLg3r4GDQnQiIRhbWPYCy5rKGMOLuY6YaaWTrFgMmdm1 g7AuvZ2de7hXBlOyrG3yZQCvkB4crD9An9ECeMqvajE4vP8tH2EZgx0Eyf1wjJ2v2abn /fXa5IYqVoAfEv6myBddC81QWm2wMf8nnahwnbUcqWj8qEGAAPXLhf0lZ9zK/zwghJmO mvG95Y893H7I09Jhl3lA5OuBiwJ2eeicAZivMno52ZkkGBFZbHdBb6tGzmJYOcVyLkCI Y/DjSRdeiXGGWv/eQZygGmYr+gzuujX4w1LjmW9jyThpUd3iDMPgBIN1RQaJOJZLgobl A58w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:x-gm-message-state:content-type :content-transfer-encoding; bh=LH9LzAwaSX905W6qivtZDyhYILRyM8WHhJ8p0w0J0Mo=; b=Y8zIUcCSROHh13egOAhIWVMuI98/rn2ugEKT1pOSpOeJVy/y4bsPvIWp0jgqqgb4Hz SGlYCsfCF3hc+4Qe1gKUOVLmci5+O1xPA69aYmBMh7wFs42c/nKbSYtUvux46amD8wn3 G7g7++vCSd1I5EjEgD+kap0lSw4dAfdo6KQr9tsnurekFY6tihZyoRZWFcVGb3yZnkDq xIxt50ErsirzIlE5a4ek2LsatCs/ZiITUSqtTiAhYJViFJW5EFu0ZrstYF1wWi8gONmQ E9MKZSS3IjSA0BqL+Z1cfxLnxSGdecG2Z0OElbVNoql3uKOdcFtoGxKZxb65gPfMh8oX tzAg== Received: by 10.50.163.98 with SMTP id yh2mr2928232igb.5.1333053976055; Thu, 29 Mar 2012 13:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.163.98 with SMTP id yh2mr2928221igb.5.1333053975993; Thu, 29 Mar 2012 13:46:15 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Thu, 29 Mar 2012 13:46:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 16:46:15 -0400 Message-ID: From: Adam Langley To: Carl Wallace X-System-Of-Record: true X-Gm-Message-State: ALoCoQl0DOJWBUbbSsttTe1YnJ9jMb9f2OhekZmXNILeq9ynZas/TA/qwgiwjx6/hIswzgH8Nn8snkUUkJnDMPP4cEpBbqM6F6hkvkrsOljjR8OmriRCB+Gi4wX4trRaMsN5du1M16Za Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:46:17 -0000 On Thu, Mar 29, 2012 at 4:34 PM, Carl Wallace w= rote: > What do you mean by otherwise unrestricted? =C2=A0That sounds like the qu= estion > is whether to include name constraints at all. Yes. The reality is that CAs do issue intermediate CA certificates to organisations for that are intended to be used with a small number of domains (i.e. internally). Today, those intermediate CA certificates have no technical constraints, save perhaps a path length constraint. Using a critical name constraint would break many clients that can't process them. Using a non-critical name constraint would technically constrain the intermediate with no loss in functionality. (That's assuming that there aren't clients that reject non-critical name constraints.) Since the alternative is a non-constrained certificate, it would seem to be a good thing to do where possible. > Do you mean you are not aware of any path validation software that > enforces name constraints, any path validation software that requires nam= e > constraints to be critical I mean that I've not encountered any path validation software that requires that a name constraint, when present, to be critical. If anybody knows otherwise, I'm sure Rob would be interested to hear about it. Cheers AGL From stephen.farrell@cs.tcd.ie Thu Mar 29 14:38:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964C321F8603 for ; Thu, 29 Mar 2012 14:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jriu-COTy16c for ; Thu, 29 Mar 2012 14:38:36 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFF921F8557 for ; Thu, 29 Mar 2012 14:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B2E5E171C04; Thu, 29 Mar 2012 22:38:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333057113; bh=me87AO5JTzMVro Qq6hFo3qSpmoR/vIuo1IZc24IXmbI=; b=NzGvc41wauGqCWvwlGEwrEZejvldcf Y+7gPnrQTlT/BigJtnSayRKg9Qo90bJ09ii+RRnQ9Bi1z9MtHRP4AIFxVD83wxHH sZaBJB5YR6FwFwig1W4ANALyai2pGrEVU05PlzThAdkLE5Gtw5ubV0Tf1fxE5Tb4 piDCUzBQ282XjVwGJzsVSh4YNMGrUMxF8483hWUcABLobl0Q+kagO2lcwMvyLyBT c4Lpfk30EyQ4Ao8R3z74Couk0Rzh3v6EDyKeJLW2SNLMmxetRh99BEQVqEu9v1mz l3WUrnJNXF/XelndU1f1+mUuk9CuJTcX5z5IL3IuFnT4SjlAs7jNjnqQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Xkaw10NycDlg; Thu, 29 Mar 2012 22:38:33 +0100 (IST) Received: from [192.168.101.215] (LPuteaux-156-16-48-239.w82-127.abo.wanadoo.fr [82.127.107.239]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 48D03171C17; Thu, 29 Mar 2012 22:38:30 +0100 (IST) Message-ID: <4F74D655.6080509@cs.tcd.ie> Date: Thu, 29 Mar 2012 22:38:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Santosh Chokhani References: <4F74C077.4050103@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:38:57 -0000 On 03/29/2012 09:09 PM, Santosh Chokhani wrote: > It is critical so that relying parties that do not understand this extension do not unwittingly accept a certificate that has been issued for a name space the CA is specifically prohibited from. > > If the extension was made NC, relying party will accept a certificate for which the CA has violated the constraint. +1 to Santosh's point. If RP s/w skips over it then it seems pointless in terms of the function for which it was designed. (All of 17 or so years ago!) If some other function is what's wanted really then I don't see why this change is any easier than another extension. I could maybe see an argument to allow some equivalent to non-critical NameConstraints as a way of helping to get initial deployment but that doesn't seem to be the argument being offered here. But starting to (finally) use this extension would be a good thing, so maybe it's worth thinking about. S > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Thursday, March 29, 2012 4:05 PM > To: pkix@ietf.org > Cc: Kathleen Wilson > Subject: [pkix] Criticality of Name Constraints in 5280 > > RFC5280 says: > "4.2.1.10. Name Constraints > ...Conforming CAs MUST mark this extension as critical" > > Can anyone explain the reason for this requirement? > > Mozilla are currently considering requiring CAs in their Root Program to include the Name Constraints extension in "external" subordinate CA certificates (i.e. where the holder of the sub-CA private key is a different organization to the Root CA). > Setting the critical flag would cause any software that doesn't recognize the Name Constraints extension to barf. I'm told that Apple's iOS and OSX platforms are among those that don't recognize the Name Constraints extension, so specifying critical Name Constraints is a non-starter. Therefore, Mozilla's current plan is to recommend that Name Constraints be non-critical. > > Should RFC5280 be updated to specify that Name Constraints need not be critical? > > Thanks. > > -- > Rob Stradling > Senior Research& Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > 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 hotz@jpl.nasa.gov Thu Mar 29 16:42:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9521F860B for ; Thu, 29 Mar 2012 16:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V11IfyzlfSTG for ; Thu, 29 Mar 2012 16:42:59 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1759721F8608 for ; Thu, 29 Mar 2012 16:42:51 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2TNgd1L013839 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 29 Mar 2012 16:42:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 29 Mar 2012 16:42:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> References: <4F74C077.4050103@comodo.com> To: Santosh Chokhani X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:42:59 -0000 Is it meaningful/useful to do TAMP without supporting this extension as = critical? On Mar 29, 2012, at 1:09 PM, Santosh Chokhani wrote: > It is critical so that relying parties that do not understand this = extension do not unwittingly accept a certificate that has been issued = for a name space the CA is specifically prohibited from. >=20 > If the extension was made NC, relying party will accept a certificate = for which the CA has violated the constraint. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Rob Stradling > Sent: Thursday, March 29, 2012 4:05 PM > To: pkix@ietf.org > Cc: Kathleen Wilson > Subject: [pkix] Criticality of Name Constraints in 5280 >=20 > RFC5280 says: > "4.2.1.10. Name Constraints > ...Conforming CAs MUST mark this extension as critical" >=20 > Can anyone explain the reason for this requirement? >=20 > Mozilla are currently considering requiring CAs in their Root Program = to include the Name Constraints extension in "external" subordinate CA = certificates (i.e. where the holder of the sub-CA private key is a = different organization to the Root CA). > Setting the critical flag would cause any software that doesn't = recognize the Name Constraints extension to barf. I'm told that Apple's = iOS and OSX platforms are among those that don't recognize the Name = Constraints extension, so specifying critical Name Constraints is a = non-starter. Therefore, Mozilla's current plan is to recommend that = Name Constraints be non-critical. >=20 > Should RFC5280 be updated to specify that Name Constraints need not be = critical? >=20 > Thanks. >=20 > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > 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 ------------------------------------------------------ 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 tgindin@us.ibm.com Thu Mar 29 17:49:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DFD21F85C9 for ; Thu, 29 Mar 2012 17:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDntIC-kR-Cv for ; Thu, 29 Mar 2012 17:49:36 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB421F85C7 for ; Thu, 29 Mar 2012 17:49:17 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 29 Mar 2012 18:49:17 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 29 Mar 2012 18:49:14 -0600 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 3AB6EC90052 for ; Thu, 29 Mar 2012 20:49:13 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2U0nDvR259692 for ; Thu, 29 Mar 2012 20:49:13 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2U0nDKP019169 for ; Thu, 29 Mar 2012 21:49:13 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2U0nDK8019166; Thu, 29 Mar 2012 21:49:13 -0300 In-Reply-To: References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> <4F738FD2.8060104@nist.gov> To: denis.pinkas@bull.net MIME-Version: 1.0 X-KeepSent: E8F737C7:E58D9F2A-852579D0:0051CEAF; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 29 Mar 2012 20:49:16 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/29/2012 20:49:12, Serialize complete at 03/29/2012 20:49:12 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12033000-3352-0000-0000-000003ADCB60 Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 30 Mar 2012 00:49:36 -0000 Denis: As you know, the flag is in EKU and is called id-kp-OCSPSigning,=20 and OCSP responders should have it set. So there are three questions=20 which 2560-bis must cover: 1) Should an OCSP response be accepted which is signed by a=20 certificate with EKU present if id-kp-OCSPSigning is not set? 2) Should an OCSP response be accepted which is signed by a v3=20 certificate with no EKU extension? 3) Should an OCSP response be accepted which is signed by a v1 or v2=20 certificate? 2560-bis section 2.5.6.1 says that unless the RP's local=20 configuration contains the signing certificate individually, the answer to = all three of these questions is "only if it's the issuer's certificate". Tom Gindin From: denis.pinkas@bull.net To: "David A. Cooper" ,=20 Cc: PKIX Date: 03/29/2012 08:24 AM Subject: Re: [pkix] 5280 clarifications Sent by: pkix-bounces@ietf.org David,=20 A point I mentioned during my presentation about rfc2560bis (slide 3).=20 " which keyUsage bits and extended key usage OIDs shall be present=20 in the CA certificate is not even said".=20 In RFC 5280 , for the key usage bits we have in particular:=20 keyCertSign (5),=20 cRLSign (6),=20 We do not have OCSPSign.=20 It would be nice both in RFC 5280 and in rfc2560bis to clarify which=20 fields or extensions allow to know=20 that the entity is allowed to sign OCSP responses directly.=20 Denis=20 De : "David A. Cooper" =20 A : PKIX =20 Date : 29/03/2012 00:25=20 Objet : Re: [pkix] 5280 clarifications=20 Envoy=E9 par : pkix-bounces@ietf.org=20 On 03/26/2012 04:19 AM, Stephen Kent wrote:=20 All three of the blocks of text that appear in my message were sent=20 to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to=20 David. There was no disagreement with the wording I proposed. David chose to ignore=20 two of blocks of text, and transformed the first one into the text=20 that you prefer. So, we have an internal communication problem with=20 the author :-). When Steve Kent sent me these three blocks of text, the only thing that=20 his message said about the text was "Here is proposed text for 5280bis to=20 move forward." There was no indication in any way that the text had been=20 reviewed by anyone else before Steve sent it to me. I did not use the=20 first block of text that Steve proposed as it appeared to state that=20 self-signed end-entity certificates MUST be marked as CA certificates, and = so I did my best to come up with alternative text. I tried my best to=20 incorporate the ideas from the other two blocks of text, but I=20 incorporated the ideas into areas of the document that were more=20 appropriate: mention of RFC 5937 in the text that already mentions using=20 extensions in a self-signed certificate to set the inputs to path=20 validation and mention of actions that a malicious CA could take in the=20 paragraph that discusses the risk of CA compromise. When I posted the draft I asked Sean Turner if it was acceptable to him,=20 since the draft was updated based on a request from him to address=20 self-signed end-entity certificates ( http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean = said that he thought the revised draft looked okay. I saw that this draft was discussed during the PKIX session:=20 This topic was added at the beginning of the meeting, at Paul Hoffman's=20 request. David Cooper, the document author was not present. Paul suggests=20 that we work on the list to revise the text dealing with self-signed=20 end-entity certificates, as the primary, remaining open issue for this=20 document. Steve Kent agreed to work with Paul on revised text on this=20 topic.=20 So, I expect to see new text on self-signed end-entity certificates=20 proposed on the list at some point. In addition, Paul Hoffman has=20 proposed updated text for the Abstract and Introduction. Unless I see=20 further discussion on the list, I will take the meeting minutes to=20 indicate that no further changes are required to any of the other text in=20 the draft. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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 From tgindin@us.ibm.com Thu Mar 29 18:02:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12AF21E808A for ; Thu, 29 Mar 2012 18:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95HLv9jxgEUO for ; Thu, 29 Mar 2012 18:02:02 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2794E21E8086 for ; Thu, 29 Mar 2012 18:02:02 -0700 (PDT) Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 29 Mar 2012 21:02:01 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e3.ny.us.ibm.com (192.168.1.103) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 29 Mar 2012 21:02:00 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3513938C8054 for ; Thu, 29 Mar 2012 21:01:59 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2U11xxl238962 for ; Thu, 29 Mar 2012 21:01:59 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2U11wfM025937 for ; Thu, 29 Mar 2012 22:01:59 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2U11wB1025829; Thu, 29 Mar 2012 22:01:58 -0300 In-Reply-To: <8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> References: <4F74C077.4050103@comodo.com> <8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> To: "Henry B. Hotz" MIME-Version: 1.0 X-KeepSent: A57B115E:2925E326-852579D1:000488BF; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 29 Mar 2012 21:02:00 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/29/2012 21:01:57, Serialize complete at 03/29/2012 21:01:57 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12033001-8974-0000-0000-000007B5C38C Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 01:02:03 -0000 It may not be meaningful to implement TAMP without supporting this extension, but relying parties which recognize an extension don't usually need to care if the extension is critical or not. Is it truly more secure to have a lightly deployed critical constraint extension, such that most single-organization intermediates have no name constraint for RP's to enforce, than a widely deployed non-critical one which is enforced by the majority of RP's but ignored by a quarter of them? I think that requiring constraint extensions to be critical can sometimes be a case of making the best the enemy of the good. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: "Henry B. Hotz" To: Santosh Chokhani , Cc: "pkix@ietf.org" , Kathleen Wilson Date: 03/29/2012 07:43 PM Subject: Re: [pkix] Criticality of Name Constraints in 5280 Sent by: pkix-bounces@ietf.org Is it meaningful/useful to do TAMP without supporting this extension as critical? On Mar 29, 2012, at 1:09 PM, Santosh Chokhani wrote: > It is critical so that relying parties that do not understand this extension do not unwittingly accept a certificate that has been issued for a name space the CA is specifically prohibited from. > > If the extension was made NC, relying party will accept a certificate for which the CA has violated the constraint. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Thursday, March 29, 2012 4:05 PM > To: pkix@ietf.org > Cc: Kathleen Wilson > Subject: [pkix] Criticality of Name Constraints in 5280 > > RFC5280 says: > "4.2.1.10. Name Constraints > ...Conforming CAs MUST mark this extension as critical" > > Can anyone explain the reason for this requirement? > > Mozilla are currently considering requiring CAs in their Root Program to include the Name Constraints extension in "external" subordinate CA certificates (i.e. where the holder of the sub-CA private key is a different organization to the Root CA). > Setting the critical flag would cause any software that doesn't recognize the Name Constraints extension to barf. I'm told that Apple's iOS and OSX platforms are among those that don't recognize the Name Constraints extension, so specifying critical Name Constraints is a non-starter. Therefore, Mozilla's current plan is to recommend that Name Constraints be non-critical. > > Should RFC5280 be updated to specify that Name Constraints need not be critical? > > Thanks. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > 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 ------------------------------------------------------ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Thu Mar 29 18:22:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F9C21F8504 for ; Thu, 29 Mar 2012 18:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbtA1m7J-ea9 for ; Thu, 29 Mar 2012 18:22:46 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 930EB21F84FE for ; Thu, 29 Mar 2012 18:22:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,339,1330923600"; d="scan'208";a="663132" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 29 Mar 2012 21:22:32 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 29 Mar 2012 21:22:32 -0400 From: Santosh Chokhani To: Tom Gindin , "Henry B. Hotz" Date: Thu, 29 Mar 2012 21:22:31 -0400 Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0OELigLPi+a1EWTwqhbnIiX4A1eAAAWewQ Message-ID: References: <4F74C077.4050103@comodo.com> <8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 01:22:48 -0000 Tom, If you go back to the archives, we have asked for and 5280 bis clarifies th= at the relying parties need not and should not examine criticality of any e= xtension. This came up 5-6 years back in the context of Sun Java and inhib= it any policy. So, any RP that enforces constraints on the producers that = are NOT stipulated in Section 6 of 5280, are over-reaching. In terms of making extension non-critical, folks can do so if they want to.= But, 5280 should not recommend that. The fact that Apple and Mozilla have not gotten the semantics of an extensi= on right after over 10 years is a problem that Mozilla and Apple need to ad= dress and not a security standard. I would not want an upstream offline, secure CA to constrain an online CA a= nd due to compromise of the online CA or RA or rogue RA to create certifica= tes for Google or other major companies and 25% (your number) of browsers t= o be snookered into using them. This stuff is not hard to understand or implement. Why do not Browsers imp= lement the 10-15 old X.509 standard properly before adding band aids that d= o not scale. There are plenty of toolkits out there that do this right and= some of them are available with source code on open source for variety of = platforms. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Thursday, March 29, 2012 9:02 PM To: Henry B. Hotz Cc: Kathleen Wilson; pkix@ietf.org; Santosh Chokhani Subject: Re: [pkix] Criticality of Name Constraints in 5280 It may not be meaningful to implement TAMP without supporting this = extension, but relying parties which recognize an extension don't usually n= eed to care if the extension is critical or not. Is it truly more secure t= o have a lightly deployed critical constraint extension, such that most sin= gle-organization intermediates have no name constraint for RP's to enforce,= than a widely deployed non-critical one which is enforced by the majority = of RP's but ignored by a quarter of them? I think that requiring constraint extensions to be critical can som= etimes be a case of making the best the enemy of the good. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employe= r From: "Henry B. Hotz" To: Santosh Chokhani ,=20 Cc: "pkix@ietf.org" , Kathleen Wilson=20 Date: 03/29/2012 07:43 PM Subject: Re: [pkix] Criticality of Name Constraints in 5280 Sent by: pkix-bounces@ietf.org Is it meaningful/useful to do TAMP without supporting this extension as=20 critical? On Mar 29, 2012, at 1:09 PM, Santosh Chokhani wrote: > It is critical so that relying parties that do not understand this=20 extension do not unwittingly accept a certificate that has been issued for= =20 a name space the CA is specifically prohibited from. >=20 > If the extension was made NC, relying party will accept a certificate=20 for which the CA has violated the constraint. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 Rob Stradling > Sent: Thursday, March 29, 2012 4:05 PM > To: pkix@ietf.org > Cc: Kathleen Wilson > Subject: [pkix] Criticality of Name Constraints in 5280 >=20 > RFC5280 says: > "4.2.1.10. Name Constraints > ...Conforming CAs MUST mark this extension as critical" >=20 > Can anyone explain the reason for this requirement? >=20 > Mozilla are currently considering requiring CAs in their Root Program to= =20 include the Name Constraints extension in "external" subordinate CA=20 certificates (i.e. where the holder of the sub-CA private key is a=20 different organization to the Root CA). > Setting the critical flag would cause any software that doesn't=20 recognize the Name Constraints extension to barf. I'm told that Apple's=20 iOS and OSX platforms are among those that don't recognize the Name=20 Constraints extension, so specifying critical Name Constraints is a=20 non-starter. Therefore, Mozilla's current plan is to recommend that Name=20 Constraints be non-critical. >=20 > Should RFC5280 be updated to specify that Name Constraints need not be=20 critical? >=20 > Thanks. >=20 > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > 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 ------------------------------------------------------ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From dev+ietf@seantek.com Thu Mar 29 20:54:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF6F21E803A for ; Thu, 29 Mar 2012 20:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLtp3NS2981t for ; Thu, 29 Mar 2012 20:54:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A011B21E8018 for ; Thu, 29 Mar 2012 20:54:20 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A81B122E1EB for ; Thu, 29 Mar 2012 23:54:12 -0400 (EDT) Message-ID: <4F752E63.2070109@seantek.com> Date: Thu, 29 Mar 2012 20:54:11 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F74C077.4050103@comodo.com> <8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070006050209040009070409" Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 03:54:22 -0000 This is a cryptographically signed message in MIME format. --------------ms070006050209040009070409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree with Santosh's assessment. [Except the Mozilla part: the new=20 PKIX API is supposed to implement name constraints.] Name constraints are very useful to constrain the (otherwise unbounded)=20 authority of intermediate CAs, when intermediate CAs are issued to=20 specific parties for specific communities. Every customer that relies upon certificates, and that has procurement=20 standards in place (e.g., government agencies), ought to require RFC=20 5280 compliance--including processing name constraints--as a condition=20 of purchase. Reality is very different. iOS/OSX devices don't implement every=20 standard properly (and also aren't bought en masse by government=20 agencies), yet are shiny and manage to capture 50% of the mobile=20 smartphone industry's profits. iOS/OSX will probably implement name=20 constraints when it hits them in the pocketbook, or becomes a PR fiasco. = On the other hand, if they do not feel the need to "conform to RFC=20 5280", and don't hold themselves out to do so, it's a moot point. Yet the standard ought to toe the line; otherwise, you have a standard=20 that doesn't offer any guarantees of standard behavior. If the CA=20 conforms to RFC 5280, the CA expects applications to honor what it=20 technically imposes. While 5280 requires applications to process name=20 constraints, it doesn't require applications to check the criticality=20 flag of the name constraints extension. 5280 only imposes the=20 criticality flag on CAs, not applications. So the fact that AGL has not=20 encountered path validation software that requires the criticality flag=20 to be set, is expected. Perhaps Mozilla should take the opportunity to=20 needle Apple about its lack of support. Sean On 3/29/2012 6:22 PM, Santosh Chokhani wrote: > Tom, > > If you go back to the archives, we have asked for and 5280 bis clarifie= s that the relying parties need not and should not examine criticality of= any extension. This came up 5-6 years back in the context of Sun Java a= nd inhibit any policy. So, any RP that enforces constraints on the produ= cers that are NOT stipulated in Section 6 of 5280, are over-reaching. > > In terms of making extension non-critical, folks can do so if they want= to. But, 5280 should not recommend that. > > The fact that Apple and Mozilla have not gotten the semantics of an ext= ension right after over 10 years is a problem that Mozilla and Apple need= to address and not a security standard. > > I would not want an upstream offline, secure CA to constrain an online = CA and due to compromise of the online CA or RA or rogue RA to create cer= tificates for Google or other major companies and 25% (your number) of br= owsers to be snookered into using them. > > This stuff is not hard to understand or implement. Why do not Browsers= implement the 10-15 old X.509 standard properly before adding band aids = that do not scale. There are plenty of toolkits out there that do this r= ight and some of them are available with source code on open source for v= ariety of platforms. > > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: Thursday, March 29, 2012 9:02 PM > To: Henry B. Hotz > Cc: Kathleen Wilson; pkix@ietf.org; Santosh Chokhani > Subject: Re: [pkix] Criticality of Name Constraints in 5280 > > It may not be meaningful to implement TAMP without supporting = this extension, but relying parties which recognize an extension don't us= ually need to care if the extension is critical or not. Is it truly more= secure to have a lightly deployed critical constraint extension, such th= at most single-organization intermediates have no name constraint for RP'= s to enforce, than a widely deployed non-critical one which is enforced b= y the majority of RP's but ignored by a quarter of them? > I think that requiring constraint extensions to be critical ca= n sometimes be a case of making the best the enemy of the good. > > Tom Gindin > > P.S. - The opinions above are mine, and not necessarily those of my emp= loyer > > > > > From: "Henry B. Hotz" > To: Santosh Chokhani, > Cc: "pkix@ietf.org", Kathleen Wilson > > Date: 03/29/2012 07:43 PM > Subject: Re: [pkix] Criticality of Name Constraints in 5280 > Sent by: pkix-bounces@ietf.org > > > > Is it meaningful/useful to do TAMP without supporting this extension as= > critical? > > On Mar 29, 2012, at 1:09 PM, Santosh Chokhani wrote: > >> It is critical so that relying parties that do not understand this > extension do not unwittingly accept a certificate that has been issued = for > a name space the CA is specifically prohibited from. >> If the extension was made NC, relying party will accept a certificate > for which the CA has violated the constraint. >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f > Rob Stradling >> Sent: Thursday, March 29, 2012 4:05 PM >> To: pkix@ietf.org >> Cc: Kathleen Wilson >> Subject: [pkix] Criticality of Name Constraints in 5280 >> >> RFC5280 says: >> "4.2.1.10. Name Constraints >> ...Conforming CAs MUST mark this extension as critical" >> >> Can anyone explain the reason for this requirement? >> >> Mozilla are currently considering requiring CAs in their Root Program = to > include the Name Constraints extension in "external" subordinate CA > certificates (i.e. where the holder of the sub-CA private key is a > different organization to the Root CA). >> Setting the critical flag would cause any software that doesn't > recognize the Name Constraints extension to barf. I'm told that Apple'= s > iOS and OSX platforms are among those that don't recognize the Name > Constraints extension, so specifying critical Name Constraints is a > non-starter. Therefore, Mozilla's current plan is to recommend that Na= me > Constraints be non-critical. >> Should RFC5280 be updated to specify that Name Constraints need not be= > critical? >> Thanks. >> >> -- >> Rob Stradling >> Senior Research& Development Scientist >> COMODO - Creating Trust Online >> _______________________________________________ >> 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 > ------------------------------------------------------ > 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 > > _______________________________________________ > 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 --------------ms070006050209040009070409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPWTCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggWpMIIEkaAD AgECAhAE4fJRzgMuxe5iQpo2hGvXMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTEyMzAwMDAwMFoXDTEyMTEyMjIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUZGV2K2lldGZAc2VhbnRlay5jb20wggGiMA0GCSqGSIb3 DQEBAQUAA4IBjwAwggGKAoIBgQDKpMfZgjhbBCd/C7wSpKbCiilFKbPm07KfI9CKCFSk2O1V C/6ZCrcmfU/8gLcRKh0gORDZIIwIt65GQQt+VwJYVrewxqn/AMWShUb73rsffdR5YMLUJEkl AcpUt6DtnEfXWEp84qh4PFOr8H2DU+ne8naHb1Fa1Q7L/rmewh6fC8WYaS4uHToXSWyujYIF xVPSZ8zzfpj+4VC/Jh3uC9ZOLp0aM9a1iXFT6/iiC46fSj595D3Jvhb+lC05VUXeyaeeLmqM z0occF6xAeI2+1jRjTlM5xEfRNmUsZ9ezgez34UzAByt0F8UkYjLMBmG1NGRLEd1YAguTIYf 7XBh0proZAUCccwl0pPy6sJW34rG1ICro+Pw0S2mgDyux4E4BeuAsquMGokoVGIJM9T4JKrG u8eadM+tzxC6sgkG9u0Aeb0hthgUtp1wfeAt1QStgh3j0LnkznOSQQKNkRUW7gyxtW7nTtph p2n4uDUjKNzrNULKSWL5H/vUl8HZcQCY25UCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBRgv7ghgRzdyPGwrHiV5x9Js5jjbjAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4w TKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZG aHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRT ZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29t MB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCE k+Gh1kssCAxUD3kHKxN3edhTanjIXyS+U9u3H4n/CL1ukVR3qxHUPVJWg2nzdile2OEVmlb+ sYcOfguPhhm8Id6CmJYdBfm0b5+UoioTtfP+GggDYuohidrMFiN1JdTQKFJA6Tpu8mNdJsCc HQYvE7OZvFhkdNNJcBOeU8NXpUW5I9gdKkmcnv90uu5KokVCSDGmspiznOgAnlYfZaAT5fai H2Yic+IVFsz/J2AQqAYfL3Kf0LwuR5vEG2quqJ/acLG7/0nOufuMZiL5+2iVS4bAlDSwOz+9 NpJMfNoWWpFjwsSulhPkuCG6BkBypsrphIi8xwAjVLWe8dqv+KAhMYIEjDCCBIgCAQEwgagw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEATh8lHOAy7F7mJC mjaEa9cwCQYFKw4DAhoFAKCCAjgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTIwMzMwMDM1NDExWjAjBgkqhkiG9w0BCQQxFgQULQrnCSoWOpL+VkZIslkf PxIEpNgwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG5Bgkr BgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEATh8lHOAy7F7mJCmjaEa9cwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAE4fJRzgMuxe5iQpo2hGvXMA0GCSqG SIb3DQEBAQUABIIBgI2ttbm0ZE3zrdpzPl4dxbAWfEmKpkBJyQbaa9imvDdjwvb3i5Fvo2zm YgQ1p3Tn4rhtxyjpJZNiUMNjV58lUjieJjUDnkWKfIA49AARIWLltQAD6ZEsYtAUcasL8f8U k5RoYa0XJeXtg3HQtBiJFazycpf7cZmn1U+saBIWiyWQECN2gY5mpoui2lS9WMeOuYSqijFN xU+c8c+HCs9LYzmB24a8BBwioHK0ks+/B+mATtg/pdZoKpygrLhapzanjZ/bHDIQpb4GauZm U5sJhj5lDyIdH+18LR9cELFKE0RrK5MLQlyM637N4+f8ZHjeKc/HDkGjUvyCuAfkSpDudeEK HLNDACg3eSFMLdqT0PlP0Lz8eZVRbX6v13XacYnPbqeH39RjjjwoQlqBz07EtoV2kwKzyRv6 3lhNOpJzIhyUz2ruHcDZuI6e+pRJl6RJghQpAWtzXgvK2bgajv0+afVAzMNZc+oi/hk+H7h5 43qbpGC+rVrcfjr4D7okR1k/kAAAAAAAAA== --------------ms070006050209040009070409-- From Jeff.Hodges@KingsMountain.com Fri Mar 30 01:13:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECF21F87B0 for ; Fri, 30 Mar 2012 01:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.016 X-Spam-Level: X-Spam-Status: No, score=-99.016 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-nUIBsCb+-t for ; Fri, 30 Mar 2012 01:13:21 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 611F121F8794 for ; Fri, 30 Mar 2012 01:13:20 -0700 (PDT) Received: (qmail 12665 invoked by uid 0); 30 Mar 2012 08:13:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 30 Mar 2012 08:13:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Qwi0dsFcmEGnQhCx9ZXa27Bd13PHE67g2C1pR2Tgl7s=; b=Iet+V11UxpRxOB1XTN3VNI/3Y/CI9bBT6Nu7MPOMcGzuW5gmR8qvhwt6PcjT2BBIIktXslDdm8e6C9dy4QZMp6fZpXD7NVrXwy/aMpFdT2KXGmlXl+tkcfm+AcPq5pY6; Received: from dhcp-5698.meeting.ietf.org ([130.129.86.152]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SDWxT-0006Xc-8v; Fri, 30 Mar 2012 02:13:19 -0600 Message-ID: <4F756B1D.1090101@KingsMountain.com> Date: Fri, 30 Mar 2012 01:13:17 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF PKIX WG , IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.86.152 authed with jeff.hodges+kingsmountain.com} Subject: Re: [pkix] fyi: CA/Browser Forum (CABF) reform deliberations X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 30 Mar 2012 08:13:22 -0000 > FYI, as I mentioned in the session, the CA/Browser Forum (CABF) is entertaining > governance reforms, as announced here. > > CA/Browser Forum Announces Organizational Reform Working Group > http://cabforum.org/org_announcement.html > > The CABF is soliciting public input, the deadline for input is unfortunately > fast approaching, it is this Friday, March 30, 2012. FWIW, I hear tell (as I suspected) that "late" input will still be considered, although the longer submitters wait, the less time and opportunity there will be to incorporate their feedback into any proposal that will come to a vote (slated for mid-April). > In terms of the sorts of reforms some parties are proposing, here's PayPal's > input.. > > PayPal supports reform at the CA/Browser Forum > > http://www.thesecuritypractice.com/the_security_practice/2012/03/paypal-supports-reform-at-the-cabrowser-forum.html > > I'm here @ietf-83, feel free to reach out if you have any questions, =JeffH From benlaurie@gmail.com Fri Mar 30 02:27:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA5121F85D0 for ; Fri, 30 Mar 2012 02:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImWj8SCiVlOA for ; Fri, 30 Mar 2012 02:27:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C79321F8842 for ; Fri, 30 Mar 2012 02:27:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so320988vbb.31 for ; Fri, 30 Mar 2012 02:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=q8dnC1IrA5653fQXy2+IKNj7ZUAFp9MXFZd6HYEEkmU=; b=mm6WpQVNjPeJnHfbrczKdpV9dMgaogl7YwqemPH72lXXwy6VDblsHCkH3cCXziKqtv aXD+EpSmsdZiWz7ydkxCGZW+nl/NTnhakQDxtMkIJmxiCJ8My4pD0DeoyAwEb/Ica2ME RCPxkY8H6N56eo8dnDAFbm432qI0cwmYKAT4hYaZ8xRC8EjzPnTN4j8QYG2gEQ6XDs2r C6roK06wcpcOUigaQ+/L8CcQo3Buzo8FtF/OkpRAcHQYMIWRiNHZs8XwYvagg43EaBpL xoCR83YzGxy9MMSHwSVi2QF0KAZdwmM9Y20KDOAiNHUC1aSifzhMv9kmxmh6dByIdaxk fakQ== MIME-Version: 1.0 Received: by 10.220.116.7 with SMTP id k7mr752019vcq.13.1333099628668; Fri, 30 Mar 2012 02:27:08 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.26.170 with HTTP; Fri, 30 Mar 2012 02:27:08 -0700 (PDT) In-Reply-To: References: <4F72FDF3.1080206@KingsMountain.com> Date: Fri, 30 Mar 2012 09:27:08 +0000 X-Google-Sender-Auth: 2T_dK3ZCFI9LEUnLyjnKpA7BAOQ Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d0438942bd125a204bc727144 Cc: IETF PKIX WG Subject: Re: [pkix] Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:27:10 -0000 --f46d0438942bd125a204bc727144 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 29, 2012 at 6:42 PM, Phillip Hallam-Baker wrote: > Umm, it is trusted to provide a service but constrained in the service > it provides. > > If there was only one DNS registrar, that company could keep you off > the Internet by refusing to provide you with any domain. If there are > multiple registrars then this becomes a less practical attack but so > does the SK protocol. > > > Given the lack of details that the authors of these proposals have > provided, Which proposals are "these proposals"? > I am really not sure what is part of their proposal and what is being read into them by reviewers. Like certain politicians policy > proposals they can satisfy everyone right up until they are required > to specify them in sufficient detail that people can see what it does > not cover. > --f46d0438942bd125a204bc727144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 29, 2012 at 6:42 PM, Phillip= Hallam-Baker <hal= lam@gmail.com> wrote:
Umm, it is trusted to provide a service but constrained in the service
it provides.

If there was only one DNS registrar, that company could keep you off
the Internet by refusing to provide you with any domain. If there are
multiple registrars then this becomes a less practical attack but so
does the SK protocol.


Given the lack of details that the authors of these proposals have
provided,

Which proposals are "these p= roposals"?
=A0
I am re= ally not sure what is part of their proposal and what
is being read into them by reviewers. Like certain politicians policy
proposals they can satisfy everyone right up until they are required
to specify them in sufficient detail that people can see what it does
not cover.
--f46d0438942bd125a204bc727144-- From hallam@gmail.com Fri Mar 30 04:11:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D8121F87BA for ; Fri, 30 Mar 2012 04:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWCe-4Tweoo8 for ; Fri, 30 Mar 2012 04:11:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8721F87B0 for ; Fri, 30 Mar 2012 04:11:09 -0700 (PDT) Received: by obbta17 with SMTP id ta17so988134obb.31 for ; Fri, 30 Mar 2012 04:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dUu9wlMwHdlJGz8DEiVE1qe/7rIq07LwwM2ud7iVc3A=; b=DZ6Mvo1UKfd1nlbebhMX4mJkGRCBLk7IO2u7kIe9O/IKgQZVlKWTlyMkKnbyVJmT8x 6fyDXeZ03U+em9V/392QBH7+puvQJU2kFeRmAq5WFbclDwR6MkU9FJyiD52P4Fkl5xMH mMjUQGeaU2wW7TLSNh0QR8/WNyTDPo0MBbcHhZkiZMqIh4m2c1+qT+MDpS+uH7Jh5nmm xM6bKYqH71G/MTMpwS0PeFrIGc0zyViTuxVk+YwxPlH93ZW4f/SNBpea01nZdGQLmjc+ noCAQgcf/L8tAOQwGpqiiRY7mdgp2MYumorkaHkxDmvB7VVODanLp8vShqg22EY2zCrW qdBQ== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr2223924obw.10.1333105868812; Fri, 30 Mar 2012 04:11:08 -0700 (PDT) Received: by 10.182.227.35 with HTTP; Fri, 30 Mar 2012 04:11:08 -0700 (PDT) In-Reply-To: References: <4F72FDF3.1080206@KingsMountain.com> Date: Fri, 30 Mar 2012 07:11:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF PKIX WG Subject: Re: [pkix] Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:11:10 -0000 SK no specification Convergence no specification, just some markting pages and a talk ranting against CAs. I am not going to reverse engineer people's ideas from code unless I am being paid my expert witness/consultant rate and there is a particular reason (e.g. patent dispute) that the code in question is worth reading. On Fri, Mar 30, 2012 at 5:27 AM, Ben Laurie wrote: > > > On Thu, Mar 29, 2012 at 6:42 PM, Phillip Hallam-Baker > wrote: >> >> Umm, it is trusted to provide a service but constrained in the service >> it provides. >> >> If there was only one DNS registrar, that company could keep you off >> the Internet by refusing to provide you with any domain. If there are >> multiple registrars then this becomes a less practical attack but so >> does the SK protocol. >> >> >> Given the lack of details that the authors of these proposals have >> provided, > > > Which proposals are "these proposals"? > >> >> I am really not sure what is part of their proposal and what >> >> is being read into them by reviewers. Like certain politicians policy >> proposals they can satisfy everyone right up until they are required >> to specify them in sufficient detail that people can see what it does >> not cover. -- Website: http://hallambaker.com/ From denis.pinkas@bull.net Fri Mar 30 04:59:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B4421F86AF for ; Fri, 30 Mar 2012 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC5sKfSLXYXN for ; Fri, 30 Mar 2012 04:59:15 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA8521F869C for ; Fri, 30 Mar 2012 04:59:15 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 4A3F218166; Fri, 30 Mar 2012 13:59:14 +0200 (CEST) In-Reply-To: References: <7A8AF058-EA27-4FD6-9871-A6234266DB8C@vpnc.org> <8A73F616-F8BA-4CEF-8EE4-C0F968384920@vpnc.org> <4F738FD2.8060104@nist.gov> To: Tom Gindin MIME-Version: 1.0 X-KeepSent: 5DFCD1D7:27C34401-C12579D1:00403198; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 30 Mar 2012 13:59:13 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 30/03/2012 13:59:14, Serialize complete at 30/03/2012 13:59:14 Content-Type: multipart/alternative; boundary="=_alternative 0041CB76C12579D1_=" Cc: PKIX Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 30 Mar 2012 11:59:17 -0000 Message en plusieurs parties au format MIME --=_alternative 0041CB76C12579D1_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Slide 3 is not about the delegated case, nor about a local configuration. It is about what is called in rfc2560bis the "Integrated OCSP Responders"=20 case. In RFC 5280 we should say briefly what is used for OCSP in that case. In rfc2560bis-05 we should provide details. The key point is: if the=20 certificate from the OCSP responder=20 does not include an id-kp-OCSPSigning extension, and if there is no local=20 configuration then what should be the content of the key usage extension and what other controls=20 should be done on the certificate by the client. Once these controls will be written, we will need to add some more=20 material in the security considerations section. Denis De : Tom Gindin A : denis.pinkas@bull.net Cc : "David A. Cooper" , PKIX Date : 30/03/2012 02:49 Objet : Re: [pkix] 5280 clarifications Denis: As you know, the flag is in EKU and is called id-kp-OCSPSigning,=20 and OCSP responders should have it set. So there are three questions=20 which 2560-bis must cover: 1) Should an OCSP response be accepted which is signed by a=20 certificate with EKU present if id-kp-OCSPSigning is not set? 2) Should an OCSP response be accepted which is signed by a v3=20 certificate with no EKU extension? 3) Should an OCSP response be accepted which is signed by a v1 or v2=20 certificate? 2560-bis section 2.5.6.1 says that unless the RP's local=20 configuration contains the signing certificate individually, the answer to = all three of these questions is "only if it's the issuer's certificate". Tom Gindin From: denis.pinkas@bull.net To: "David A. Cooper" ,=20 Cc: PKIX Date: 03/29/2012 08:24 AM Subject: Re: [pkix] 5280 clarifications Sent by: pkix-bounces@ietf.org David,=20 A point I mentioned during my presentation about rfc2560bis (slide 3).=20 " which keyUsage bits and extended key usage OIDs shall be present=20 in the CA certificate is not even said".=20 In RFC 5280 , for the key usage bits we have in particular:=20 keyCertSign (5),=20 cRLSign (6),=20 We do not have OCSPSign.=20 It would be nice both in RFC 5280 and in rfc2560bis to clarify which=20 fields or extensions allow to know=20 that the entity is allowed to sign OCSP responses directly.=20 Denis=20 De : "David A. Cooper" =20 A : PKIX =20 Date : 29/03/2012 00:25=20 Objet : Re: [pkix] 5280 clarifications=20 Envoy=E9 par : pkix-bounces@ietf.org=20 On 03/26/2012 04:19 AM, Stephen Kent wrote:=20 All three of the blocks of text that appear in my message were sent=20 to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to=20 David. There was no disagreement with the wording I proposed. David chose to ignore=20 two of blocks of text, and transformed the first one into the text=20 that you prefer. So, we have an internal communication problem with=20 the author :-). When Steve Kent sent me these three blocks of text, the only thing that=20 his message said about the text was "Here is proposed text for 5280bis to=20 move forward." There was no indication in any way that the text had been=20 reviewed by anyone else before Steve sent it to me. I did not use the=20 first block of text that Steve proposed as it appeared to state that=20 self-signed end-entity certificates MUST be marked as CA certificates, and = so I did my best to come up with alternative text. I tried my best to=20 incorporate the ideas from the other two blocks of text, but I=20 incorporated the ideas into areas of the document that were more=20 appropriate: mention of RFC 5937 in the text that already mentions using=20 extensions in a self-signed certificate to set the inputs to path=20 validation and mention of actions that a malicious CA could take in the=20 paragraph that discusses the risk of CA compromise. When I posted the draft I asked Sean Turner if it was acceptable to him,=20 since the draft was updated based on a request from him to address=20 self-signed end-entity certificates ( http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean = said that he thought the revised draft looked okay. I saw that this draft was discussed during the PKIX session:=20 This topic was added at the beginning of the meeting, at Paul Hoffman's=20 request. David Cooper, the document author was not present. Paul suggests=20 that we work on the list to revise the text dealing with self-signed=20 end-entity certificates, as the primary, remaining open issue for this=20 document. Steve Kent agreed to work with Paul on revised text on this=20 topic.=20 So, I expect to see new text on self-signed end-entity certificates=20 proposed on the list at some point. In addition, Paul Hoffman has=20 proposed updated text for the Abstract and Introduction. Unless I see=20 further discussion on the list, I will take the meeting minutes to=20 indicate that no further changes are required to any of the other text in=20 the draft. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0041CB76C12579D1_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom,

Slide 3 is not about the delegated case, nor about a local configuration.

It is about what is called in rfc2560bis the "Integrated OCSP Responders" case.

In RFC 5280 we should say briefly what is used for OCSP in that case.

In rfc2560bis-05 we should provide detail= s. The key point is: if the certificate from the OCSP responder
does not include an id-kp-OCSPSigning extension, and if there is no local configuration then what
should be the content of the key usage ex= tension and what other controls should be done on the certificate
by the client.

Once these controls will be written, we w= ill need to add some more material in the security considerations section.

Denis



De :     &= nbsp;  Tom Gindin <tgindin@us.i= bm.com>
A :     &n= bsp;  denis.pinkas@bull.net
Cc :   &nb= sp;    "David A. Cooper" <david.cooper@nist.gov>, PKIX <pkix@ietf.org>
Date :    =    30/03/2012 02:49
Objet :        Re: [pkix] 5280 clarifications



        Denis:

       As you know, the flag is in EKU and is called id-kp-OCSPSigning,
and OCSP responders should have it set.  So there are three questions
which 2560-bis must cover:
1)      Should an OCSP response be accepted which is signed by a
certificate with EKU present if id-kp-OCSPSigning is not set?
2)      Should an OCSP response be accepted which is signed by a v3
certificate with no EKU extension?
3)      Should an OCSP response be accepted which is signed by a v1 or v2
certificate?
       2560-bis section 2.5.6.1 says that unless the RP's local
configuration contains the signing certificate individually, the answer to
all three of these questions is "only if it's the issuer's certificate= ".

Tom Gindin





From:   denis.pinkas@bull.net
To:     "David A. Cooper" <david.cooper@nist.gov>,
Cc:     PKIX <pkix@ietf.org>
Date:   03/29/2012 08:24 AM
Subject:        Re: [pkix] 5280 clarifications
Sent by:        pkix-bounces@ietf.org



David,

A point I mentioned during my presentation about rfc2560bis (slide 3).

" which keyUsage bits and extended key usage OIDs shall be present
in the CA certificate is not even said".

In RFC 5280 , for the key usage bits we have in particular:

keyCertSign             (5),
cRLSign                 (6),

We do not have OCSPSign.

It would be nice both in RFC 5280 and in rfc2560bis to clarify which
fields or extensions allow to know
that the entity is allowed to sign OCSP responses directly.

Denis




De :        "David A. Cooper" <david.coope= r@nist.gov>
A :        PKIX <pkix@ietf.org>
Date :        29/03/2012 00:25
Objet :        Re: [pkix] 5280 clarifications
Envoy=E9 par :        pkix-bounces@ietf.org



On 03/26/2012 04:19 AM, Stephen Kent wrote:
All three of the blocks of text that appear in my message were sent
to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to
David. There was
no disagreement with the wording I proposed. David chose to ignore
two of blocks of text, and transformed the first one into the text
that you prefer. So, we have an internal communication problem with
the author :-).


When Steve Kent sent me these three blocks of text, the only thing that
his message said about the text was "Here is proposed text for 5280bis to
move forward."  There was no indication in any way that the text had been
reviewed by anyone else before Steve sent it to me.  I did not use the
first block of text that Steve proposed as it appeared to state that
self-signed end-entity certificates MUST be marked as CA certificates, and
so I did my best to come up with alternative text.  I tried my best to
incorporate the ideas from the other two blocks of text, but I
incorporated the ideas into areas of the document that were more
appropriate: mention of RFC 5937 in the text that already mentions using
extensions in a self-signed certificate to set the inputs to path
validation and mention of actions that a malicious CA could take in the
paragraph that discusses the risk of CA compromise.

When I posted the draft I asked Sean Turner if it was acceptable to him,
since the draft was updated based on a request from him to address
self-signed end-entity certificates (
http://www.ietf.org/mail-archive/web/pkix/c= urrent/msg29661.html), and Sean
said that he thought the revised draft looked okay.

I saw that this draft was discussed during the PKIX session:
This topic was added at the beginning of the meeting, at Paul Hoffman's
request. David Cooper, the document author was not present. Paul suggests
that we work on the list to revise the text dealing with self-signed
end-entity certificates, as the primary, remaining open issue for this
document. Steve Kent agreed to work with Paul on revised text on this
topic.

So, I expect to see new text on self-signed end-entity certificates
proposed on the list at some point.  In addition, Paul Hoffman has
proposed updated text for the Abstract and Introduction.  Unless I see
further discussion on the list, I will take the meeting minutes to
indicate that no further changes are required to any of the other text in
the draft.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0041CB76C12579D1_=-- From kent@bbn.com Fri Mar 30 05:19:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9C21F86F7 for ; Fri, 30 Mar 2012 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqLB9xasFMYe for ; Fri, 30 Mar 2012 05:19:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 40DFA21F86B9 for ; Fri, 30 Mar 2012 05:19:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35081 helo=[10.108.68.118]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDand-000FbB-E6; Fri, 30 Mar 2012 08:19:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 30 Mar 2012 08:19:36 -0400 To: Adam Langley From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:19:41 -0000 At 4:46 PM -0400 3/29/12, Adam Langley wrote: >... > >I mean that I've not encountered any path validation software that >requires that a name constraint, when present, to be critical. If >anybody knows otherwise, I'm sure Rob would be interested to hear >about it. Adam, I applaud your interest in using NameConstraints to improve secruity relative to the browser public TA trust model. BBN has developed and used (and sometimes sold) CA SW that enforces the critical marking requirement, probably since the late 1990's. It's been part of the PKIX standards since the beginning, RFC 2459 in 1999. However, as Santosh noted, an RP need not enforce the marking, just pay attention to it when present. I don't recall if our RP (vs. CA) software tried to enforce the marking, or if there was a local option to do so, or not. Santosh also noted the reason this is extension MUST be critical. The problem we face here is that you want to make use of this extension, yet not require strict adherence by RPs, to enable an incremental rollout of the feature. The concern is that RPs might not follow 5280 (and its 2 predecessor cert & CRL profile RFCs) re support of this extension. I'd like to see a survey of which RPs in the context of interest do not follow a part of the standard that has been around for >10 years, and encourage them to fix this problem. Again, I am encouraged by efforts to improve secruity in the browser PKI context, but changes to 5280 need to be very well justified, and, based on the discussion so far, I don't think that criterion has been met. CAs should follow the RFC, and mark the extension as critical. RPs have been required to support this extension for a very long time. Steve From DPKemp@missi.ncsc.mil Fri Mar 30 06:49:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE621F85D6 for ; Fri, 30 Mar 2012 06:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-wzJDa8BPpL for ; Fri, 30 Mar 2012 06:49:01 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6302721F85D2 for ; Fri, 30 Mar 2012 06:49:01 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2UDn0di002021 for ; Fri, 30 Mar 2012 09:49:00 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 09:49:00 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 30 Mar 2012 09:48:59 -0400 Message-ID: In-Reply-To: <4F752E63.2070109@seantek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0OKNKqsFTr1u28T+SXos4jyg0DFAATgwuQ References: <4F74C077.4050103@comodo.com><8C346E61-496A-4707-9EF9-4539B1FCB542@jpl.nasa.gov> <4F752E63.2070109@seantek.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 30 Mar 2012 13:49:00.0243 (UTC) FILETIME=[DC3E0230:01CD0E7B] Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:49:02 -0000 +1. This is not a case of better being the enemy of good - RP applications can do anything they want, including using a manufacturer-default trust anchor list, ignoring or incorrectly processing any certificate field or extension, and barfing on any standards-compliant input. But the critical flag signals intent of the public key infrastructure - non-critical can be safely ignored while ignoring critical extensions results in security-relevant violations of the PKI's intent. A PKI that includes name constraints but signals that ignoring them is not security-relevant is lying. It would be great if all applications understood the signal, but some percentage not understanding it is a lesser evil than making the signal itself incorrect. Dave -----Original Message----- From: Sean Leonard Yet the standard ought to toe the line; otherwise, you have a standard that doesn't offer any guarantees of standard behavior. If the CA conforms to RFC 5280, the CA expects applications to honor what it technically imposes. While 5280 requires applications to process name constraints, it doesn't require applications to check the criticality flag of the name constraints extension. 5280 only imposes the criticality flag on CAs, not applications.=20 From mrex@sap.com Fri Mar 30 11:51:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5C21F8644 for ; Fri, 30 Mar 2012 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.067 X-Spam-Level: X-Spam-Status: No, score=-10.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJvYG7Q7+ZMX for ; Fri, 30 Mar 2012 11:51:37 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B145721F863C for ; Fri, 30 Mar 2012 11:51:36 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2UIpTOX027639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 20:51:29 +0200 (MEST) From: Martin Rex Message-Id: <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 30 Mar 2012 20:51:28 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Mar 30, 12 08:19:36 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, kwilson@mozilla.com Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:51:37 -0000 Stephen Kent wrote: > > At 4:46 PM -0400 3/29/12, Adam Langley wrote: > >... > > > >I mean that I've not encountered any path validation software that > >requires that a name constraint, when present, to be critical. If > >anybody knows otherwise, I'm sure Rob would be interested to hear > >about it. > > Adam, I applaud your interest in using NameConstraints to improve secruity > relative to the browser public TA trust model. I'm a little confused. The endpoint identification performed with the "browser public TA trust model" is based on DNS names rather than on distinguished directory names. > > The concern is that RPs might not follow 5280 (and its 2 predecessor > cert & CRL profile RFCs) re support of this extension. rfc5280 and its predecessors "require" support for name constraints *ONLY* on the directory name. Support for name constraints on subjectAltNames (those that are typically used for server endpoint identification performed with the "browser public TA trust model" is _not_ required, only recommended. So rfc5280 compliance seem not to help here at all, see last paragraph here: http://tools.ietf.org/html/rfc5280#page-40 Looking at *real* existing certs, like the one presented by "https://www.google.pl" when connecting with *NO* TLS extension SNI, contains 436 subject alt names of type DNSName, all different. If that cert would have to be equipped with subject alt name constraints for each and every of those names, it would probably grow much larger than 16 KByte and cause a number of TLS clients to abort the handshake due to the size of the server certificate... -Martin From DPKemp@missi.ncsc.mil Fri Mar 30 12:10:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F188721F8625 for ; Fri, 30 Mar 2012 12:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j33uUMjtspVv for ; Fri, 30 Mar 2012 12:10:06 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id C709021F864F for ; Fri, 30 Mar 2012 12:10:05 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q2UJ9xQ9008254 for ; Fri, 30 Mar 2012 15:09:59 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 15:09:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 30 Mar 2012 15:09:58 -0400 Message-ID: In-Reply-To: <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0OpixAS/ExvDQ1TNmYfzgvn7MKxAAAFzTw References: from "Stephen Kent" atMar 30, 12 08:19:36 am <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> From: "Kemp, David P." To: X-OriginalArrivalTime: 30 Mar 2012 19:09:59.0305 (UTC) FILETIME=[B389A790:01CD0EA8] Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:10:07 -0000 The certificate you cite is intended for the following purposes: "Ensures the identity of a remote computer", i.e. it is an end entity cert. Why would an EE cert be affected when 5280 prohibits it?: "The name constraints extension, which MUST be used only in a CA certificate, ..." And by extension, what would be the purpose of putting name constraints in the certificate of the terminal CA in a path (the one that issued the EE certs)? Hammers can be used on thumbs as well as nails; a cross-certification environment must be designed intelligently for name constraints to be of any use. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Martin Rex Sent: Friday, March 30, 2012 2:51 PM To: Stephen Kent Cc: pkix@ietf.org; kwilson@mozilla.com Subject: Re: [pkix] Criticality of Name Constraints in 5280 Stephen Kent wrote: >=20 > At 4:46 PM -0400 3/29/12, Adam Langley wrote: > >... > > > >I mean that I've not encountered any path validation software that=20 > >requires that a name constraint, when present, to be critical. If=20 > >anybody knows otherwise, I'm sure Rob would be interested to hear=20 > >about it. >=20 > Adam, I applaud your interest in using NameConstraints to improve=20 > secruity relative to the browser public TA trust model. I'm a little confused. The endpoint identification performed with the "browser public TA trust model" is based on DNS names rather than on distinguished directory names. >=20 > The concern is that RPs might not follow 5280 (and its 2 predecessor=20 > cert & CRL profile RFCs) re support of this extension. rfc5280 and its predecessors "require" support for name constraints *ONLY* on the directory name. Support for name constraints on subjectAltNames (those that are typically used for server endpoint identification performed with the "browser public TA trust model" is _not_ required, only recommended. So rfc5280 compliance seem not to help here at all, see last paragraph here: http://tools.ietf.org/html/rfc5280#page-40 Looking at *real* existing certs, like the one presented by "https://www.google.pl" when connecting with *NO* TLS extension SNI, contains 436 subject alt names of type DNSName, all different. If that cert would have to be equipped with subject alt name constraints for each and every of those names, it would probably grow much larger than 16 KByte and cause a number of TLS clients to abort the handshake due to the size of the server certificate... -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Fri Mar 30 12:23:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B58D21F86BE for ; Fri, 30 Mar 2012 12:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9U1VFY8Xibt for ; Fri, 30 Mar 2012 12:23:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4095A21F86B7 for ; Fri, 30 Mar 2012 12:23:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2UJNQrM001683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 21:23:26 +0200 (MEST) From: Martin Rex Message-Id: <201203301923.q2UJNQAr017374@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Fri, 30 Mar 2012 21:23:26 +0200 (MEST) In-Reply-To: from "Kemp, David P." at Mar 30, 12 03:09:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:23:29 -0000 Kemp, David P. wrote: > > The certificate you cite is intended for the following purposes: > "Ensures the identity of a remote computer", > > i.e. it is an end entity cert. Why would an EE cert be affected when > 5280 prohibits it?: > "The name constraints extension, which MUST be used only in a CA > certificate, ..." > > And by extension, what would be the purpose of putting name constraints > in the certificate of the terminal CA in a path (the one that issued the > EE certs)? Hammers can be used on thumbs as well as nails; a > cross-certification environment must be designed intelligently for name > constraints to be of any use. Admittedly, I had confused the certificate that would have to carry the name constraints extensions. But the problem is actually the same. The discussion is about constraining a subCA / intermediateCA, and per TLS spec, the server MUST send his entire cert chain in the Certificate handshake message (and may omit only the self-signed rootCA cert at the end of the path). Since the limitation in some TLS clients in the installed base is about the size of a handshake message (or more precisely about the lack of support for fragmented handshake messages) combined with a TLS record size limit of 16 KByte. -Martin From hotz@jpl.nasa.gov Fri Mar 30 14:12:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79DA21F84A7 for ; Fri, 30 Mar 2012 14:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPwURjCJOq7Z for ; Fri, 30 Mar 2012 14:12:22 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 09D6521F845C for ; Fri, 30 Mar 2012 14:12:21 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2ULCKwv014871 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Fri, 30 Mar 2012 14:12:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Henry B. Hotz" In-Reply-To: <4F74C077.4050103@comodo.com> Date: Fri, 30 Mar 2012 14:12:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8036E189-B789-4B2F-84F5-B0418D758C9A@jpl.nasa.gov> References: <4F74C077.4050103@comodo.com> To: "pkix@ietf.org PKIX" X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:12:22 -0000 I agree with the standard that an extension which could cause a security = issue if ignored should be marked critical. Also that RP software = should hard-fail if it doesn't understand such an extension. Anything = else would seem to significantly reduce the clarity and value of the = standard. That said, it would seem that the real-world situation conspires against = such functionality. Could the people working on 5280bis please include = some practical guidance for how to deal with an environment which does = not fully support that behavior? Surely there are people on this list = who have actually implemented or used name constraints (e.g. at BBN, = hint, hint ;-) and can provide experience with how to deal with the = compatibility issues. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mrex@sap.com Fri Mar 30 15:21:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AAA21F86AF for ; Fri, 30 Mar 2012 15:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.869 X-Spam-Level: X-Spam-Status: No, score=-8.869 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YRYgKirsplO for ; Fri, 30 Mar 2012 15:21:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E551F21F864A for ; Fri, 30 Mar 2012 15:21:13 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2UMLBdp015363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 Mar 2012 00:21:11 +0200 (MEST) From: Martin Rex Message-Id: <201203302221.q2UMLBku027824@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Sat, 31 Mar 2012 00:21:11 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Mar 23, 12 06:13:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Need for an organizationalIdentifier attribute 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, 30 Mar 2012 22:21:16 -0000 Stefan Santesson wrote: > > When a person is associated with an organization in a certificate the > subjects employee number or alike is often stored in the serialNumber > attribute. > > But where do you store an identifier of the organization? > That is, not the name stored in organization name, but the registered > organization number? > > I've seen some odd solutions to this problem but nor clean solution. > X.520 only offer organizationName and orgnizationalUnitName as > organizational attributes > > Have anyone else come across this issue? > How did you solve it? > Do we need to define a clean attribute for an organizationalIdentifier? For the GKVnet in Germany (www.itsg.de), a regulartory requirement for electronic data exchange between employers and statutory health insurances, an additional OU= Name component is used--probably the most backwards compatible approach. CN=Peter Mustermann, OU=BN12345678, OU=XYZ GmbH, O=ITSG TrustCenter fuer Arbeitgeber, C=DE (and curiously they avoided the umlaut in the O= component...) The PKI is used with PKCS#7/CMS to sign&encrypt the data. While the CN= in the certificates contains a human being's real name, the certificate AFAIK represents an entire organization, whose organizational ID (Betriebsnummer) is encoded in the first OU=, and whose registered name is encoded in the second OU=, so it is not quite the same scenario that you described. I also believe that an organization ID attribute in a certificate that identifies a person (so that this attribute represents an affiliation) should be represented in a subject name attribute and does NOT belong into SubjectAltNames (which are supposed to be alternative representations of the subject and therefore be distinct values for distinct subjects. -Martin From tgindin@us.ibm.com Fri Mar 30 15:31:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA58C21F85ED for ; Fri, 30 Mar 2012 15:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3powAUH4hZQ for ; Fri, 30 Mar 2012 15:31:46 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5121F85D5 for ; Fri, 30 Mar 2012 15:31:46 -0700 (PDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Mar 2012 16:31:44 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 30 Mar 2012 16:31:35 -0600 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id F0787C90052 for ; Fri, 30 Mar 2012 18:31:33 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2UMVYE3304224 for ; Fri, 30 Mar 2012 18:31:34 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2UMVY4S027791 for ; Fri, 30 Mar 2012 19:31:34 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2UMVX0f027749; Fri, 30 Mar 2012 19:31:33 -0300 In-Reply-To: <201203301923.q2UJNQAr017374@fs4113.wdf.sap.corp> References: from "Kemp, David P." at Mar 30, 12 03:09:58 pm <201203301923.q2UJNQAr017374@fs4113.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 70A6AA8F:16A49E3C-852579D1:0072E72E; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Fri, 30 Mar 2012 18:31:37 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 03/30/2012 18:31:33, Serialize complete at 03/30/2012 18:31:33 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12033022-1780-0000-0000-000004665928 X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000264; HX=3.00000186; KW=3.00000007; PH=3.00000001; SC=3.00000001; SDB=6.00126622; UDB=6.00030148; UTC=2012-03-30 22:31:44 Cc: pkix@ietf.org Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:31:46 -0000 Martin: The name constraint needed would probably just be a list of permitted subtrees of type DNSName. In some intermediate certificates, each subtree would contain the name of a TLD, while in others each subtree would contain a DNS domain belonging to the organization for whom the intermediate issued certs. It seems unlikely that there would be more than ten or twelve of them in a particular intermediate, and thus they'd take up much less than 1 KB. That size is normally increased by only two bytes by making the extension critical. Tom Gindin From: Martin Rex To: DPKemp@missi.ncsc.mil (Kemp David P.), Cc: pkix@ietf.org Date: 03/30/2012 03:28 PM Subject: Re: [pkix] Criticality of Name Constraints in 5280 Sent by: pkix-bounces@ietf.org Kemp, David P. wrote: > > The certificate you cite is intended for the following purposes: > "Ensures the identity of a remote computer", > > i.e. it is an end entity cert. Why would an EE cert be affected when > 5280 prohibits it?: > "The name constraints extension, which MUST be used only in a CA > certificate, ..." > > And by extension, what would be the purpose of putting name constraints > in the certificate of the terminal CA in a path (the one that issued the > EE certs)? Hammers can be used on thumbs as well as nails; a > cross-certification environment must be designed intelligently for name > constraints to be of any use. Admittedly, I had confused the certificate that would have to carry the name constraints extensions. But the problem is actually the same. The discussion is about constraining a subCA / intermediateCA, and per TLS spec, the server MUST send his entire cert chain in the Certificate handshake message (and may omit only the self-signed rootCA cert at the end of the path). Since the limitation in some TLS clients in the installed base is about the size of a handshake message (or more precisely about the lack of support for fragmented handshake messages) combined with a TLS record size limit of 16 KByte. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Sat Mar 31 17:15:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4F21F8795 for ; Sat, 31 Mar 2012 17:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhYT2FCNYzPK for ; Sat, 31 Mar 2012 17:15:01 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA821F878B for ; Sat, 31 Mar 2012 17:15:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,350,1330923600"; d="scan'208";a="4560796" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 31 Mar 2012 20:14:45 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 31 Mar 2012 20:14:45 -0400 From: Santosh Chokhani To: "Kemp, David P." , "pkix@ietf.org" Date: Sat, 31 Mar 2012 20:14:43 -0400 Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0OpixAS/ExvDQ1TNmYfzgvn7MKxAAAFzTwAD1Lv4A= Message-ID: References: from "Stephen Kent" atMar 30, 12 08:19:36 am <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 00:15:01 -0000 Dave, I agree with you for the most part. There may be scenarios when name constraints in terminal CA certificate mak= e sense. One example is when a public trust "trust anchor" or intermediate CA may is= sue certificated to online terminal CA may provide them their name space or= inhibit them from issuing some high value site certificates. Another example is for security reasons an Enterprise may have separate ter= minal CA for human and device certificates and auto issuance of devices bei= ng less secure, may want to constrain the name spaces for both CAs. There may be other example. Thus, we should not say that terminal CAs neve= r need name constraints in their certificates. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kem= p, David P. Sent: Friday, March 30, 2012 3:10 PM To: pkix@ietf.org Subject: Re: [pkix] Criticality of Name Constraints in 5280 The certificate you cite is intended for the following purposes: "Ensures the identity of a remote computer", i.e. it is an end entity cert. Why would an EE cert be affected when 5280 prohibits it?: "The name constraints extension, which MUST be used only in a CA certificate, ..." And by extension, what would be the purpose of putting name constraints in = the certificate of the terminal CA in a path (the one that issued the EE ce= rts)? Hammers can be used on thumbs as well as nails; a cross-certificatio= n environment must be designed intelligently for name constraints to be of = any use. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Friday, March 30, 2012 2:51 PM To: Stephen Kent Cc: pkix@ietf.org; kwilson@mozilla.com Subject: Re: [pkix] Criticality of Name Constraints in 5280 Stephen Kent wrote: >=20 > At 4:46 PM -0400 3/29/12, Adam Langley wrote: > >... > > > >I mean that I've not encountered any path validation software that=20 > >requires that a name constraint, when present, to be critical. If=20 > >anybody knows otherwise, I'm sure Rob would be interested to hear=20 > >about it. >=20 > Adam, I applaud your interest in using NameConstraints to improve=20 > secruity relative to the browser public TA trust model. I'm a little confused. The endpoint identification performed with the "bro= wser public TA trust model" is based on DNS names rather than on distinguis= hed directory names. >=20 > The concern is that RPs might not follow 5280 (and its 2 predecessor=20 > cert & CRL profile RFCs) re support of this extension. rfc5280 and its predecessors "require" support for name constraints *ONLY* on the directory name. Support for name constraints on subjectAltNa= mes (those that are typically used for server endpoint identification perfo= rmed with the "browser public TA trust model" is _not_ required, only recommended. So rfc5280 compliance seem not to hel= p here at all, see last paragraph here: http://tools.ietf.org/html/rfc5280#page-40 Looking at *real* existing certs, like the one presented by "https://www.go= ogle.pl" when connecting with *NO* TLS extension SNI, contains 436 subject = alt names of type DNSName, all different. If that cert would have to be equipped with subject alt name constraints fo= r each and every of those names, it would probably grow much larger than 16= KByte and cause a number of TLS clients to abort the handshake due to the = size of the server certificate... -Martin _______________________________________________ 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