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

["Black, David" <[e-mail]>]

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