Stefan, > Is this important enough to do that? IMHO, yes - the "running code" aspects of existing responder behavior/limitations are definitely important enough for an RFC like this that revises a protocol spec, and the alternatives to "revoked" feel like an important complement to those aspects (discussion what to do instead when responder behavior/limitations are encountered). I appreciate the level of work that may be involved in capturing this, as I've had my share of contentious discussions in WGs that I chair - FWIW, I'm currently chairing my 4th and 5th WGs. OTOH, when a WG has put that much time/effort into reaching a (compromise) decision, it really is valuable to record why the decision was reached to avoid recovering that ground in the future and (specific to this situation) to give implementers some more context/information on how the protocol is likely to work in practice. Thanks, --David > -----Original Message----- > From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] > Sent: Wednesday, March 27, 2013 11:38 AM > 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 > > I could. > > My worry is just that this is such a contentious subject and it took us x > hundreds of emails to reach this state, that if I add more explanations, > people will start disagreeing with it and that we end up in a long debate > on how to correctly express this. > > Is this important enough to do that? > > /Stefan > > > On 3/27/13 3:30 PM, "Black, David" <david.black@xxxxxxx> wrote: > > >Hi Stefan, > > > >> Does this answer your question? > > > >Yes, please add some of that explanation to the next version of the draft > >;-). > >Coverage of existing responder behavior/limitations (important "running > >code" > >concerns, IMHO) and alternatives to using "revoked" ("have a number of > >tools > >to prevent the client from accepting a bad certificate") seem particularly > >relevant. > > > >Thanks, > >--David > > > >> -----Original Message----- > >> From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] > >> Sent: Wednesday, March 27, 2013 7:44 AM > >> 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, > >> > >> Yes I missed to respond to that aspect. > >> > >> This is a bit complicated, but we have a large legacy to take into > >>account > >> where some responders implements just RFC 2560, while some deliver > >> pre-generated responses according to RFC 5019 (Light-weight OCSP). LW > >> responders are not capable of producing a signed response at the time of > >> responding and in case such responder finds a request for a certificate > >> where no pre-produced response exists, it will reply with an unsigned > >> error response "unauthorized", which also is a legitimate way to > >>respond. > >> So the actual OCSP responder may actually know that the certificate was > >> never issued, but since it delivers pre-produced responder through a > >>CDN, > >> it can not provide a revoked response in real time. > >> > >> So the major aim with the current writing is to declare that the revoked > >> response is a MAY because there are other valid alternatives. > >> > >> We also want to avoid putting down a SHOULD respond revoked if a > >> certificate is known to be not-issued, because that would require us to > >> define what "known to be non-issued" actually means. And that could be > >> quite tricky as OCSP responders by no means are required to have this > >> knowledge. > >> > >> The OCSP responder simply have a number of tools to prevent the client > >> from accepting a bad certificate. > >> This update of OCSP simply allows responders to use the "revoked" > >>response > >> as a preventive measure, without mandating it. > >> > >> This is also related to activities in the CA Browser Forum where they > >>put > >> down requirements on responders complying with CAB rules to not respond > >> "good" to certificates that were never issued. > >> With this update in OCSP, they can now mandate in their policies both > >>the > >> fact that their responders MUST know if a certificate was never issued > >>and > >> MUST respond "revoked". > >> > >> So we allow other communities to raise the bar even if the base standard > >> defines the response as optional. > >> > >> In theory we could possibly say that responding revoked is optional, but > >> if you choose between revoked and unknown then you SHOULD favour revoked > >> over unknown. But such nested requirements just feels bad and impossible > >> to test compliance against. I'd much rather just leave it optional. I > >> think the Note gives a clear recommendation on this and the rationale > >> without spelling it out as a requirement. > >> > >> Does this answer your question? > >> > >> > >> On 3/27/13 12:51 AM, "Black, David" <david.black@xxxxxxx> wrote: > >> > >> >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 > >> >> >---------------------------------------------------- > >> >> > > >> >> > > >> >> > >> >> > >> > > >> > >> > > > >