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

[Stefan Santesson <[e-mail]>]

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]
>> >----------------------------------------------------
>> >
>> >
>> 
>> 
>