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

["Piyush Jain" <[e-mail]>]

' "revoked" status is still optional in this context in order to maintain
backwards compatibility with deployments of RFC 2560.'

I fail to understand this statement about backward compatibility.
 How does "revoked" being "optional/required breaks backward compatibility?
The only reason cited in the WG discussions to use revoked for "not-issued"
was that any other approach would break backward compatibility with legacy
clients. And now the draft says that revoked is optional because making it
required won't be backward compatible.

And it gives the impression that best course of action for 2560bis
responders is to start issuing revoked for "not-issued", which is far from
the originally stated goal to provide a way for CAs to be able to return
revoked for such serial numbers.

-Piyush

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Stefan Santesson
> Sent: Thursday, March 28, 2013 3:34 AM
> To: Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pkix] 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]; gen-
> [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]
> >> >> >> >----------------------------------------------------
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix