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

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

Stefan,

> Is this important enough to do that?

IMHO, yes - the "running code" aspects of existing responder behavior/limitations
are definitely important enough for an RFC like this that revises a protocol spec,
and the alternatives to "revoked" feel like an important complement to those
aspects (discussion what to do instead when responder behavior/limitations are
encountered).

I appreciate the level of work that may be involved in capturing this, as
I've had my share of contentious discussions in WGs that I chair - FWIW,
I'm currently chairing my 4th and 5th WGs.  OTOH, when a WG has put that much
time/effort into reaching a (compromise) decision, it really is valuable
to record why the decision was reached to avoid recovering that ground
in the future and (specific to this situation) to give implementers some
more context/information on how the protocol is likely to work in practice.

Thanks,
--David

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Wednesday, March 27, 2013 11:38 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
>
> I could.
>
> My worry is just that this is such a contentious subject and it took us x
> hundreds of emails to reach this state, that if I add more explanations,
> people will start disagreeing with it and that we end up in a long debate
> on how to correctly express this.
>
> Is this important enough to do that?
>
> /Stefan
>
>
> On 3/27/13 3:30 PM, "Black, David" <[e-mail]> wrote:
>
> >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]
> >> >> >----------------------------------------------------
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>