> Does this solve you issue. > I think this is as far as dare to go without risking a heated debate. Yes, that suffices for me - it provides a cogent explanation of why "revoked" is optional, and the existing text on CRLs as a fallback mechanism suffices to illuminate a likely consequence of not using "revoked". Thank you, --David > -----Original Message----- > From: Carlisle Adams [mailto:cadams@xxxxxxxxxxxxxxx] > Sent: Thursday, March 28, 2013 9:57 AM > To: 'Stefan Santesson'; Black, David; sts@xxxxxxxxxxx; mmyers@xxxxxxxxx; > ambarish@xxxxxxxxx; slava.galperin@xxxxxxxxx; gen-art@xxxxxxxx > Cc: pkix@xxxxxxxx; 'Sean Turner'; ietf@xxxxxxxx > Subject: RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > Hi, > > This wording sounds fine to me. Thanks Stefan! > > Carlisle. > > > -----Original Message----- > From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] > Sent: March-28-13 6:34 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 have given this a go by expanding the note as follows: > > 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. The > "revoked" status is still optional in this context in order to > maintain backwards compatibility with deployments of RFC 2560. > For example, the responder may not have any knowledge about > whether a requested serial number has been assigned to any > issued certificate, or the responder may provide pre produced > responses in accordance with RFC 5019 and, for that reason, is > not capable of providing a signed response for all non-issued > certificate serial numbers. > > > Does this solve you issue. > I think this is as far as dare to go without risking a heated debate. > > /Stefan > > > On 3/27/13 5:08 PM, "Black, David" <david.black@xxxxxxx> wrote: > > >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 > >> >> >> >---------------------------------------------------- > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> > >> > > > > >