Great, I will issue an update shortly. /Stefan On 3/28/13 3:51 PM, "Black, David" <david.black@xxxxxxx> wrote: >> 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 >> >> >> >> >---------------------------------------------------- >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >