Subject: Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-16

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2013 13:35:52 +0300

Thank you for your review and re-review, David. I'm basing my recommendation for this document on your review. (Although some of the discussion still continues…)

Jari

On Mar 29, 2013, at 1:15 AM, "Black, David" <[email-masked]> wrote:

> The -16 version of this draft resolves all of the concerns raised by the
> Gen-ART review of the -15 version.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Black, David
>> Sent: Monday, March 25, 2013 8:26 PM
>> To: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Cc: Black, David; [email-masked]; Sean Turner; [email-masked]
>> Subject: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
>> 
>> 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.
>> 
>> [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.
>> 
>> [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.
>> 
>> [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
>> 
>> [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.
>> 
>> 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.
>> 
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>> [email-masked]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art