Hi Stefan, This looks good - thank you for the prompt response. It looks like my speculation on item [1] was wrong, so could you respond to the question below, please?: > >[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? -------------- Beyond that, the proposed actions (or proposed non-actions) on items [2]-[5] are fine with me, Sean's taken care of the author permissions item from idnits, and I assume someone has or will check the ASN.1 . Thanks, --David > -----Original Message----- > From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] > Sent: Monday, March 25, 2013 10:21 PM > To: Black, David; sts@xxxxxxxxxxx; mmyers@xxxxxxxxx; ambarish@xxxxxxxxx; > slava.galperin@xxxxxxxxx; cadams@xxxxxxxxxxxxxxx; gen-art@xxxxxxxx > Cc: pkix@xxxxxxxx; Sean Turner; ietf@xxxxxxxx > Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > Hi David, > > Thanks for the review. > My reply in line. > > On 3/26/13 1:25 AM, "Black, David" <david.black@xxxxxxx> wrote: > > >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. > > No, this is not the main reason. The main reason is the one stated as a > Note: in this section: > > 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. > > > > > >[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. > > > I Agree. I will adopt your text. > > > > >[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. > > The change in algorithm requirements was provided by RFC 6277, and further > refined in this draft in accordance with requests from Sean Turner. > > > > >[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 > > Good suggestions. I will update accordingly. > > > > >[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. > > This note if I remember correctly is imported from RFC 6277, which is > incorporated into this document. The reason behind the text is only to > avoid usages of insecure algorithms. > Historical validation is a real can of worms that I really would like to > keep a tight lid on. I really want to avoid doing recommendations in this > space as it may trigger a whole flood of things that could be equally > important to say about this subject. > > > > >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. > > > I defer this one to Sean. I think he has this one under control. > > > Thanks again for the review. > > /Stefan > > > > > >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 > >---------------------------------------------------- > > > > > >