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

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

> Does this solve you issue.
> I think this is as far as dare to go without risking a heated debate.

Yes, that suffices for me - it provides a cogent explanation of why
"revoked" is optional, and the existing text on CRLs as a fallback
mechanism suffices to illuminate a likely consequence of not using
"revoked".

Thank you,
--David

> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Thursday, March 28, 2013 9:57 AM
> To: 'Stefan Santesson'; Black, David; [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,
>
> This wording sounds fine to me.  Thanks Stefan!
>
> Carlisle.
>
>
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: March-28-13 6:34 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 have given this a go by expanding the note as follows:
>
> 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. The
>          "revoked" status is still optional in this context in order to
>          maintain backwards compatibility with deployments of RFC 2560.
>          For example, the responder may not have any knowledge about
>          whether a requested serial number has been assigned to any
>          issued certificate, or the responder may provide pre produced
>          responses in accordance with RFC 5019 and, for that reason, is
>          not capable of providing a signed response for all non-issued
>          certificate serial numbers.
>
>
> Does this solve you issue.
> I think this is as far as dare to go without risking a heated debate.
>
> /Stefan
>
>
> On 3/27/13 5:08 PM, "Black, David" <[e-mail]> wrote:
>
> >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]
> >> >> >> >----------------------------------------------------
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
>