Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Stefan Santesson <[e-mail]>]

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" <[e-mail]> 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:[e-mail]]
>> Sent: Wednesday, March 27, 2013 7:44 AM
>> To: Black, David; [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> Cc: [e-mail]; Sean Turner; [e-mail]
>> 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" <[e-mail]> 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:[e-mail]]
>> >> Sent: Monday, March 25, 2013 10:21 PM
>> >> To: Black, David; [e-mail]; [e-mail];
>>[e-mail];
>> >> [e-mail]; [e-mail]; [e-mail]
>> >> Cc: [e-mail]; Sean Turner; [e-mail]
>> >> 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" <[e-mail]> 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
>> >> >[phone]             FAX: [phone]
>> >> >[e-mail]        Mobile: [phone]
>> >> >----------------------------------------------------
>> >> >
>> >> >
>> >>
>> >>
>> >
>> 
>> 
>