Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
"Black, David" <david.black@emc.com> Tue, 09 April 2013 15:57 UTC
Return-Path: <david.black@emc.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287F421F942D; Tue, 9 Apr 2013 08:57:47 -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 Vy-D2-6oAP1R; Tue, 9 Apr 2013 08:57:43 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8054321F9415; Tue, 9 Apr 2013 08:57:39 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r39FvP4a032358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 11:57:26 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 9 Apr 2013 11:57:09 -0400
Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r39Fv46i012569; Tue, 9 Apr 2013 11:57:04 -0400
Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Tue, 9 Apr 2013 11:57:03 -0400
From: "Black, David" <david.black@emc.com>
To: Piyush Jain <piyush@ditenity.com>, 'Sean Turner' <turners@ieca.com>
Date: Tue, 09 Apr 2013 11:57:02 -0400
Thread-Topic: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Thread-Index: AQHHvIU0pEj95jqjILpXYwEgVOm34gLGPak8AXFeg0kBCCz4MwNWbgjOAWN27bMCjnis0AKXx8I0mGHZF+CAABrXQA==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293E22DA2@MX15A.corp.emc.com>
References: <003e01ce3077$5b6329f0$12297dd0$@ditenity.com> <20130403160532.EB4FD1A68A@ld9781.wdf.sap.corp> <00a401ce3092$0a1415d0$1e3c4170$@ditenity.com> <5163270C.20300@ieca.com> <07af01ce34a4$582df1d0$0889d570$@ditenity.com> <5163840F.2030508@ieca.com> <083601ce34e7$e3dcef40$ab96cdc0$@ditenity.com> <8D3D17ACE214DC429325B2B98F3AE71293E22D3E@MX15A.corp.emc.com> <08b901ce3534$e057b920$a1072b60$@ditenity.com>
In-Reply-To: <08b901ce3534$e057b920$a1072b60$@ditenity.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
X-EMM-MHVC: 1
X-Mailman-Approved-At: Sat, 20 Apr 2013 16:53:15 -0700
Cc: "ambarish@gmail.com" <ambarish@gmail.com>, "slava.galperin@gmail.com" <slava.galperin@gmail.com>, "cadams@eecs.uottawa.ca" <cadams@eecs.uottawa.ca>, 'Stefan Santesson' <stefan@aaa-sec.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "sts@aaa-sec.com" <sts@aaa-sec.com>, "pkix@ietf.org" <pkix@ietf.org>, "Black, David" <david.black@emc.com>
Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 15:57:47 -0000
Piyush, > I think I failed to clarify this in my last message. Let me try again. I > based my interpretation on the following response from Stefan : [ ... snip ...] > The above explanation at the minimum indicates the author's intent that > clients should treat such certificates as "revoked" and not "non-issued". This may be where we're talking past each other, because what matters is the text in the draft. I understand Stefan's intent, and believe that the use of lower case "should" in the text quoted above is a fair summary of what's in the current draft. That's not an absolute prohibition on or requirement for client behavior, although it's certainly the client behavior that responders should expect (again, lower case "should"). > However, if readers of the draft do not think that the draft explicitly > mandates it, we have a bigger problem w.r.t. to establishing trust in such > responses. Please see the text from section 4.2.2.2 bullet 2 and 3(page 15) > > Begin TEXT > ~~~~~~~~~ > Clients MUST reject the response if the certificate required to validate > the signature on the response fails to meet at least one of the following > criteria: > 1. Matches a local configuration of OCSP signing authority for the > certificate in question; or > 2. Is the certificate of the CA that issued the certificate in > question; or > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension > and is issued by the CA that issued the certificate in question as stated > above." > End Text > ~~~~~~~ > > Based on above the responder trust models referred to by "2." and "3." > cannot be used to communicate "non-issued". I think the mechanics of the response validation checks are fine - is the concern that use of "that issued" for items 2 and 3 may be incorrect wrt known non-issued certificates? It may be useful to keep in mind that the CA may have issued the "non-issued" certificate, but no longer has any record of having done so, so I disagree with the statement that the later two models cannot be used to communicate "non-issued", as the CA's signature on such a certificate may be valid. Thanks, --David > -----Original Message----- > From: Piyush Jain [mailto:piyush@ditenity.com] > Sent: Tuesday, April 09, 2013 11:14 AM > To: Black, David; 'Sean Turner' > Cc: ambarish@gmail.com; slava.galperin@gmail.com; cadams@eecs.uottawa.ca; > 'Stefan Santesson'; sts@aaa-sec.com; pkix@ietf.org; gen-art@ietf.org; 'Henry > B. Hotz' > Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > > I do not see that prohibition in the new text in -16. In the cited email > > message, I do see a disagreement between you and Stefan about what > > implementations are likely to do, but I don't see any text in the draft > that > > dictates that implementations must or must not make that interpretation. > > I think I failed to clarify this in my last message. Let me try again. I > based my interpretation on the following response from Stefan : > > BEGIN QUOTE > ~~~~~~~~~~~ > " The draft does NOT define a "not-issued" response. It allows the "revoked" > response if a certificate serial number has never been issued. That is two > entirely different things. If you ask how to deal with the response, then > the client will not get a non- issued response. It will get a "revoked" > status." > END QUOTE > ~~~~~~~~ > > The above explanation at the minimum indicates the author's intent that > clients should treat such certificates as "revoked" and not "non-issued". > However, if readers of the draft do not think that the draft explicitly > mandates it, we have a bigger problem w.r.t. to establishing trust in such > responses. Please see the text from section 4.2.2.2 bullet 2 and 3(page 15) > > Begin TEXT > ~~~~~~~~~ > Clients MUST reject the response if the certificate required to validate > the signature on the response fails to meet at least one of the following > criteria: > 1. Matches a local configuration of OCSP signing authority for the > certificate in question; or > 2. Is the certificate of the CA that issued the certificate in > question; or > 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension > and is issued by the CA that issued the certificate in question as stated > above." > End Text > ~~~~~~~ > > Based on above the responder trust models referred to by "2." and "3." > cannot be used to communicate "non-issued". > > -Piyush > >
- [pkix] Gen-ART review of draft-ietf-pkix-rfc2560b… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- [pkix] Gen-ART review of draft-ietf-pkix-rfc2560b… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Andris Berzins
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Andris Berzins
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Sean Turner
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson