Telechat Review of draft-ietf-pkix-rfc2560bis-16
review-ietf-pkix-rfc2560bis-16-genart-telechat-black-2013-04-05-00

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: sts at aaa-sec.com; mmyers at fastq.com; ambarish at gmail.com;
> slava.galperin at gmail.com; cadams at eecs.uottawa.ca; gen-art at ietf.org
> Cc: Black, David; pkix at ietf.org; Sean Turner; ietf at ietf.org
> 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
> david.black at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>