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@xxxxxxxxxxx; mmyers@xxxxxxxxx; ambarish@xxxxxxxxx; > slava.galperin@xxxxxxxxx; cadams@xxxxxxxxxxxxxxx; gen-art@xxxxxxxx > Cc: Black, David; pkix@xxxxxxxx; Sean Turner; ietf@xxxxxxxx > 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@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >