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

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

Hi Stefan,

> Does this answer your question?

Yes, please add some of that explanation to the next version of the draft ;-).
Coverage of existing responder behavior/limitations (important "running code"
concerns, IMHO) and alternatives to using "revoked" ("have a number of tools
to prevent the client from accepting a bad certificate") seem particularly
relevant.

Thanks,
--David

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Wednesday, March 27, 2013 7:44 AM
> 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,
> 
> Yes I missed to respond to that aspect.
> 
> This is a bit complicated, but we have a large legacy to take into account
> where some responders implements just RFC 2560, while some deliver
> pre-generated responses according to RFC 5019 (Light-weight OCSP). LW
> responders are not capable of producing a signed response at the time of
> responding and in case such responder finds a request for a certificate
> where no pre-produced response exists, it will reply with an unsigned
> error response "unauthorized", which also is a legitimate way to respond.
> So the actual OCSP responder may actually know that the certificate was
> never issued, but since it delivers pre-produced responder through a CDN,
> it can not provide a revoked response in real time.
> 
> So the major aim with the current writing is to declare that the revoked
> response is a MAY because there are other valid alternatives.
> 
> We also want to avoid putting down a SHOULD respond revoked if a
> certificate is known to be not-issued, because that would require us to
> define what "known to be non-issued" actually means. And that could be
> quite tricky as OCSP responders by no means are required to have this
> knowledge.
> 
> The OCSP responder simply have a number of tools to prevent the client
> from accepting a bad certificate.
> This update of OCSP simply allows responders to use the "revoked" response
> as a preventive measure, without mandating it.
> 
> This is also related to activities in the CA Browser Forum where they put
> down requirements on responders complying with CAB rules to not respond
> "good" to certificates that were never issued.
> With this update in OCSP, they can now mandate in their policies both the
> fact that their responders MUST know if a certificate was never issued and
> MUST respond "revoked".
> 
> So we allow other communities to raise the bar even if the base standard
> defines the response as optional.
> 
> In theory we could possibly say that responding revoked is optional, but
> if you choose between revoked and unknown then you SHOULD favour revoked
> over unknown. But such nested requirements just feels bad and impossible
> to test compliance against. I'd much rather just leave it optional. I
> think the Note gives a clear recommendation on this and the rationale
> without spelling it out as a requirement.
> 
> Does this answer your question?
> 
> 
> On 3/27/13 12:51 AM, "Black, David" <[e-mail]> wrote:
> 
> >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]
> >> >----------------------------------------------------
> >> >
> >> >
> >>
> >>
> >
> 
>