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

[Stefan Santesson <[e-mail]>]

Great,

I will issue an update shortly.

/Stefan

On 3/28/13 3:51 PM, "Black, David" <[e-mail]> wrote:

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