[pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-16
"Black, David" <david.black@emc.com> Thu, 28 March 2013 23:16 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 C7C2B21F8F0F; Thu, 28 Mar 2013 16:16:42 -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 Iy5vg6NTvyJD; Thu, 28 Mar 2013 16:16:42 -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 C13A721F8F1F; Thu, 28 Mar 2013 16:16:34 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2SNG7g1031849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Mar 2013 19:16:07 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 28 Mar 2013 19:15:55 -0400
Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2SNFsj9030538; Thu, 28 Mar 2013 19:15:55 -0400
Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 28 Mar 2013 19:15:54 -0400
From: "Black, David" <david.black@emc.com>
To: "Black, David" <david.black@emc.com>, "sts@aaa-sec.com" <sts@aaa-sec.com>, "mmyers@fastq.com" <mmyers@fastq.com>, "ambarish@gmail.com" <ambarish@gmail.com>, "slava.galperin@gmail.com" <slava.galperin@gmail.com>, "cadams@eecs.uottawa.ca" <cadams@eecs.uottawa.ca>, "gen-art@ietf.org" <gen-art@ietf.org>
Date: Thu, 28 Mar 2013 19:15:53 -0400
Thread-Topic: Gen-ART review of draft-ietf-pkix-rfc2560bis-16
Thread-Index: Ac4puHxAH7Fxh7AxT6S6tCMO9vgxrgCUWZuQ
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293D36A70@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71293AEEDBC@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293AEEDBC@MX15A.corp.emc.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Fri, 29 Mar 2013 09:41:07 -0700
Cc: "pkix@ietf.org" <pkix@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>
Subject: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-16
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: Thu, 28 Mar 2013 23:16:43 -0000
The -16 version of this draft resolves all of the concerns raised by the Gen-ART review of the -15 version. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, March 25, 2013 8:26 PM > To: sts@aaa-sec.com; mmyers@fastq.com; ambarish@gmail.com; > slava.galperin@gmail.com; cadams@eecs.uottawa.ca; gen-art@ietf.org > Cc: Black, David; pkix@ietf.org; Sean Turner; ietf@ietf.org > Subject: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > Authors, > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please > see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: draft-ietf-pkix-rfc2560bis-15 > Reviewer: David L. Black > Review Date: March 25, 2013 > IETF LC End Date: March 27, 2013 > > Summary: > This draft is on the right track but has open issues, described in the review. > > This draft updates the OCSP protocol for obtaining certificate status > with some minor extensions. > > Because this is a "bis" draft, I reviewed the diffs against RFC 2560. > > I did not check the ASN.1. I also did not see a writeup for this draft > in the data tracker, and so will rely on the document shepherd to > ensure that the ASN.1 has been checked when the writeup is prepared. > > I found five open issues, all of which are minor, plus one idnits item > that is probably ok, but should be double-checked. > > Minor issues: > > [1] Section 2.2: > > NOTE: The "revoked" state for known non-issued certificate serial > numbers is allowed in order to reduce the risk of relying > parties using CRLs as a fall back mechanism, which would be > considerably higher if an "unknown" response was returned. > > Given this explanation, I'm surprised that the use of "revoked" instead of > "unknown" for a known non-issued certificate is a "MAY" requirement and > not a "SHOULD" requirement. Why is that the case? > > It appears that the reason is that the use of "revoked" in this situation > may be dangerous when serial numbers can be predicted for certificates that > will be issued in the future. If that's what's going on, this concern is > already explained in the security considerations section, but it should > also be mentioned here for completeness. > > [2] Section 4.2.2.2: > > The key that signs a certificate's status information need not be the > same key that signed the certificate. It is necessary however to > ensure that the entity signing this information is authorized to do > so. Therefore, a certificate's issuer MAY either sign the OCSP > responses itself or it MAY explicitly designate this authority to > another entity. > > The two instances of "MAY" in the above text were both "MUST" in RFC 2560. > > The RFC 2560 text construction of "MUST" or "MUST" is a bit odd, but the two > "MAY"s in this draft are even worse, as they allow "MAY do something else > entirely", despite being enclosed in an either-or construct. I strongly > suspect that the latter was not intended, so the following would be clearer: > > The key that signs a certificate's status information need not be the > same key that signed the certificate. It is necessary however to > ensure that the entity signing this information is authorized to do > so. Therefore, a certificate's issuer MUST do one of the following: > - sign the OCSP responses itself, or > - explicitly designate this authority to another entity. > > [3] Section 4.3: > > Is the "SHOULD" requirement still appropriate for the DSA with SHA-1 combo > (vs. a "MAY" requirement)? This requirement was a "MUST" in RFC 2560, but > I wonder about actual usage of DSA in practice. > > [4] Section 5, last paragraph: > > Responding a "revoked" state to certificate that has never been > issued may enable someone to obtain a revocation response for a > certificate that is not yet issued, but soon will be issued, if the > CA issues certificates using sequential certificate serial number > assignment. > > The above text after starting with the "if" is too narrow - it should say: > > if the certificate serial number of the certificate that > will be issued can be predicted or guessed by the requester. > Such prediction is easy for a CA that issues certificates > using sequential certificate serial number assignment. > > There's also a nit in original text - its first line should be: > > Responding with a "revoked" state for a certificate that has never been > > [5] Section 5.1.1: > > In archival applications it is quite possible that an OCSP responder > might be asked to report the validity of a certificate on a date in > the distant past. Such a certificate might employ a signing method > that is no longer considered acceptably secure. In such > circumstances the responder MUST NOT generate a signature using a > signing mechanism that is not considered acceptably secure. > > This could use an additional warning that certificate archival should > not rely solely on signatures in archived certificates for ensuring the > validity and integrity of the archived certificates because the signature > algorithm(s) may transition to no longer being considered acceptably > secure at some point after the certificates are archived. > > Nits: > > idnits 2.12.15 said: > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) > > This looks like it's ok because all the authors of RFC 2560 are also authors > of > this draft, but it should be double-checked. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >
- [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