Gen-ART review of draft-ietf-pkix-rfc2560bis-16

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