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