Thank you for your review and re-review, David. I'm basing my recommendation for this document on your review. (Although some of the discussion still continues…)
Jari On Mar 29, 2013, at 1:15 AM, "Black, David" <[email protected]> wrote: > 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: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected] >> Cc: Black, David; [email protected]; Sean Turner; [email protected] >> 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 >> [email protected] Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
