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

From: "Black, David" <[email-masked]>
Date: Mon, 25 Mar 2013 20:25:57 -0400

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.

[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.

[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.

[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	

[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.

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.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 03:21:02 +0100

Hi David,

Thanks for the review.
My reply in line.

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

>		- explicitly designate this authority to another entity.

I Agree. I will adopt your text.

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

>	Responding with a "revoked" state for a certificate that has never been	

Good suggestions. I will update accordingly.

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

>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

---

From: Sean Turner <[email-masked]>
Date: Tue, 26 Mar 2013 18:04:48 -0400

> I defer this one to Sean. I think he has this one under control.

I actually contacted all but one of the authors of RFC 2560.  The ones I 
did get in contact with indicated it was fine to publishing under the 
new rules.  The one I did not contact is deceased.   I decided it would 
be in poor taste to contact the widower on this issue.  Based on 
discussions with people who knew the author very well and the minimal 
changes in the draft, I'm comfortable progressing the document with the 
deceased authors name on it and without the disclaimer.

spt

---

From: "Black, David" <[email-masked]>
Date: Tue, 26 Mar 2013 19:51:57 -0400

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

> >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:[email-masked]]
> Sent: Monday, March 25, 2013 10:21 PM
> To: Black, David; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; Sean Turner; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Hi David,
> 
> Thanks for the review.
> My reply in line.
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Mar 2013 12:44:07 +0100

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" <[email-masked]> wrote:

>> >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.
>> >
>>numbers
>> >     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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Mar 2013 16:37:45 +0100

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" <[email-masked]> wrote:

>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
>
>> Sent: Wednesday, March 27, 2013 7:44 AM
>> >> >This draft is on the right track but has open issues, described in
>>the
>> >> >review.
>> >> >
>> >> >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
>> >> is allowed in order to reduce the risk of relying parties using CRLs
>>as
>> >>a
>> >> >(vs. a "MAY" requirement)?  This requirement was a "MUST" in RFC
>>2560,
>> >>but
>> >> >The above text after starting with the "if" is too narrow - it
>>should
>> >>say:
>> >> >
>> >> >  -- The document seems to lack a disclaimer for pre-RFC5378 work,
>>but
>> >>may
>> >> >     the BCP78 rights to the IETF Trust, then this is fine, and you
>>can
>> >> >ignore

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Mar 2013 11:34:02 +0100

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" <[email-masked]> wrote:

>Stefan,
>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
>
>> Sent: Wednesday, March 27, 2013 11:38 AM
>> >> fact that their responders MUST know if a certificate was never
>>issued
>> >>and
>> >> MUST respond "revoked".
>> >>
>> >> >> >"unknown" for a known non-issued certificate is a "MAY"
>>requirement
>> >>and
>> >> >> >I am the assigned Gen-ART reviewer for this draft. For
>>background on
>> >> >> >Gen-ART, please
>> >> >> >see the FAQ at
>> >> >> >"unknown" for a known non-issued certificate is a "MAY"
>>requirement
>> >>and
>> >> >> >       The key that signs a certificate's status information
>>need not be
>> >>the
>> >> >> >       ensure that the entity signing this information is
>>authorized to
>> do
>> >> >> >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
>> >> >> >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
>> >> >> >       ensure that the entity signing this information is
>>authorized to
>> do
>> >> >> >Is the "SHOULD" requirement still appropriate for the DSA with
>>SHA-1
>> >> >>combo
>> >> >> >       certificate that is not yet issued, but soon will be
>>issued, if
>> the
>> >> >> >       Responding with a "revoked" state for a certificate that
>>has never
>> >> >>been
>> >> >>
>> >> >> >       might be asked to report the validity of a certificate on
>>a date
>> in
>> >> >> >not rely solely on signatures in archived certificates for
>>ensuring
>> >>the
>> >> >> incorporated into this document. The reason behind the text is
>>only
>> >>to
>> >> >> keep a tight lid on. I really want to avoid doing recommendations
>>in
>> >> >>this
>> >> >> >This looks like it's ok because all the authors of RFC 2560 are
>>also
>> >> >> >authors of

---

From: "Black, David" <[email-masked]>
Date: Wed, 27 Mar 2013 10:30:01 -0400

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 27 Mar 2013 12:08:34 -0400

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

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Mar 2013 10:51:22 -0400

> 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

> From: Carlisle Adams [mailto:[email-masked]]
> Sent: Thursday, March 28, 2013 9:57 AM
> To: 'Stefan Santesson'; Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; 'Sean Turner'; [email-masked]
> Subject: RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
>
> Hi,
>
> This wording sounds fine to me.  Thanks Stefan!
>
> Carlisle.
>
>
> Sent: March-28-13 6:34 AM
> >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
> >
> >> To: Black, David; [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]; [email-masked];
> >> [email-masked]
> >> 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.
> >>
> >> >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
> >> >
> >> >> 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
> >> >> 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.
> >> >>
> >> >> 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.
> >> >>
> >> >> 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
> >> >> 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".
> >> >>
> >> >> In theory we could possibly say that responding revoked is
> >> >> optional,
> >>but
> >> >> 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.
> >> >>
> >> >> >> >               numbers is allowed in order to reduce the risk
> >> >> >> > of
> >>relying
> >> >> >> >               considerably higher if an "unknown" response
> >> >> >> > was
> >>returned.
> >> >> >> >
> >> >> >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
> >> >> >> >This draft is on the right track but has open issues,
> >> >> >> >described
> >>in
> >> >>the
> >> >> >> >review.
> >> >> >> >
> >> >> >> >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
> >> >> >> >               numbers is allowed in order to reduce the risk
> >> >> >> > of
> >>relying
> >> >> >> >               considerably higher if an "unknown" response
> >> >> >> > was
> >>returned.
> >> >> >> >
> >> >> >> >It appears that the reason is that the use of "revoked" in
> >> >> >> >this
> >> >> >>situation
> >> >> >> >already explained in the security considerations section, but
> >> >> >> >it
> >> >>should
> >> >> >> 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
> >> >> >> >entirely", despite being enclosed in an either-or construct.
> >> >> >> >I
> >> >> >>strongly
> >> >> >> >       so.  Therefore, a certificate's issuer MUST do one of
> >> >> >> > the
> >> >>following:
> >> >> >> >               - explicitly designate this authority to
> >> >> >> > another
> >>entity.
> >> >> >>
> >> >> >>
> >> >> >> The change in algorithm requirements was provided by RFC 6277,
> >> >> >>and further  refined in this draft in accordance with requests
> >> >> >>from Sean
> >>Turner.
> >> >> >>
> >> >> >> >
> >> >> >> >       issued may enable someone to obtain a revocation
> >> >> >> > response
> >>for a
> >> >> >> >       In archival applications it is quite possible that an
> >> >> >> > OCSP
> >> >>responder
> >> >> >> >       circumstances the responder MUST NOT generate a
> >> >> >> > signature
> >>using a
> >> >> >> >validity and integrity of the archived certificates because
> >> >> >> >the
> >> >> >>signature
> >> >> >> Historical validation is a real can of worms that I really
> >> >> >> would
> >> >>like to
> >> >> >> >     the BCP78 rights to the IETF Trust, then this is fine,
> >> >> >> >and
> >>you
> >> >>can
> >> >> >> >ignore
> >> >> >> >David L. Black, Distinguished Engineer EMC Corporation, 176
> >> >> >> >South St., Hopkinton, MA  01748

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Mar 2013 15:53:53 +0100

Great,

I will issue an update shortly.

/Stefan

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

>> >>[email-masked];
>> >> >> >> >Given this explanation, I'm surprised that the use of
>>"revoked"
>> >> >> >>instead of
>> >> >>[email-masked];
>> >> >> >> >Given this explanation, I'm surprised that the use of
>>"revoked"
>> >> >> >>instead of

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Mar 2013 19:15:53 -0400

The -16 version of this draft resolves all of the concerns raised by the
Gen-ART review of the -15 version.

Thanks,
--David

> From: Black, David
> Sent: Monday, March 25, 2013 8:26 PM
> To: [email-masked]; [email-masked]; [email-masked];
> Cc: Black, David; [email-masked]; Sean Turner; [email-masked]
> Subject: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Authors,
>

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 09:17:08 -0700

' "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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Thursday, March 28, 2013 3:34 AM
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> >> >> if you choose between revoked and unknown then you SHOULD
> favour
> >>revoked
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Mar 2013 17:37:10 +0100

>required won't be backward compatible.

Yes. Making it required would prohibit other valid ways to respond to this
situation that is allowed by RFC 2560 and RFC 5019.
Such as responding "good" or responding with "unauthorized" error.

>revoked for such serial numbers.

The latter is what optional means.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 10:12:38 -0700

Not arguing that it should be required. I'm with you on keeping it optional.

It is your statement about backward compatibility to justify it that is
incorrect.
Backward compatibility "with deployments of RFC2560" is not affected in
either case. Legacy clients will continue to work whether you make it
required or optional.

You probably meant "maintain compliance with RFC 2560 and RFC 5019."

-Piyush

> Sent: Friday, March 29, 2013 9:37 AM
> To: Piyush Jain; 'Black, David'; [email-masked]; [email-masked];
> >' "revoked" status is still optional in this context in order to
> >maintain backwards compatibility with deployments of RFC 2560.'
> >
> >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.
> 
> >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.
>

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 12:27:40 -0700

Hi David,

Your interpretation of the text is right on target.
How, based on the past discussions in this WG, that is not the intent.

The sole reason cited for overloading the meaning of revoked status with
non-issued was that it allows new servers to interoperate with legacy
clients. The WG agreed that there are many better alternatives but they all
break compatibility with older clients. In fact, a more secure and complete
proposal by Denis was not adopted because of the same reason.

I believe that Stefan is trying to convey that requiring servers to return
revoked in this context will make them non-compliant with 2560 and 5019 as
opposed to breaking interoperability with legacy clients.

Cheers
-Piyush

> From: Black, David [mailto:[email-masked]]
> Sent: Friday, March 29, 2013 11:18 AM
> To: Piyush Jain; 'Stefan Santesson'; [email-masked]; [email-masked];
> Cc: [email-masked]; Black, David
> Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Hi Piyush,
> 
> The usual backwards compatibility concern is mixed new/legacy
> deployments.
> In this case, the specifics appear to be:
> 
> New clients with legacy servers cannot expect to see "revoked" in this
case.
> This matters because a hypothetical client coded to depend on a "revoked"
> response in this case won't work correctly with legacy servers (even
though
> it'd be rather questionable to code that dependency into a new client -
never
> underestimate the creativity and cleverness of implementers).
> 
> New servers with legacy clients risk breaking clients that can't cope with
> "revoked" in this case, as you noted:
> 
> >>> any other approach would break backward compatibility with legacy
> >>> clients.
> 
> Both of these are justifications for "optional", as these RFCs apply to
both
> clients and servers.
> > From: Piyush Jain [mailto:[email-masked]]
> > Sent: Friday, March 29, 2013 1:13 PM
> > To: 'Stefan Santesson'; Black, David; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; gen- [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> >
> > It is your statement about backward compatibility to justify it that
> > is incorrect.
> > Backward compatibility "with deployments of RFC2560" is not affected
> > in either case. Legacy clients will continue to work whether you make
> > it required or optional.
> >
> > > [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > >legacy clients. And now the draft says that revoked is optional
> > > >because making it required won't be backward compatible.
> > >
> > > Yes. Making it required would prohibit other valid ways to respond
> > > to this situation that is allowed by RFC 2560 and RFC 5019.
> > > >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.
> > >

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Mar 2013 20:56:22 +0100

>either case. Legacy clients will continue to work whether you make it

Legacy servers won't

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 14:06:38 -0700

Not sure if I understand.
Are you saying legacy servers won't work with 2560bis clients?

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 30 Mar 2013 01:20:34 +0100

Legacy servers would not comply with RFC2560bis IF revoked response for
non issued certs would be required.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 17:55:24 -0700

Agreed.

The text, however incorrectly states 
"revoked" status is still optional in this context in order to maintain
backwards compatibility with deployments of RFC 2560.'

Please note the subtle difference between being backward compatible with
deployments and being compliant with standards.

> Sent: Friday, March 29, 2013 5:21 PM
> >> >in either case. Legacy clients will continue to work whether you
> >> >make it required or optional.
> >>
> >> Legacy servers won't
> >>
> >> /Stefan
> >>
> >
> >
>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 31 Mar 2013 00:58:13 +0100

>deployments and being compliant with standards.

No I don't get it. And I'm really trying.

This is what backward compatibility of a standard is.
A standard is backwards compatible if any valid implementation of the old
standard is also a valid implementation of the revised standard.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 30 Mar 2013 17:53:25 -0700

> standard is also a valid implementation of the revised standard.

And I always thought that compatibility applies to implementations.

Anyway, I'm pasting David's interpretation of the text that he sent in one
of the messages in this thread. I would appreciate it if you can share you
thoughts on this interpretation.
If this is how most people see it, they would conclude that both clients and
server would need to be updated together if servers start returning revoked
for non-issued. I know that this is not what you trying to convey.

Pasted from David's message
~~~~~~~~~~~~~~~~~~~~~~
"The usual backwards compatibility concern is mixed new/legacy deployments.
In this case, the specifics appear to be:
New clients with legacy servers cannot expect to see "revoked" in this case.
This matters because a hypothetical client coded to depend on a "revoked"
response in this case won't work correctly with legacy servers (even though
it'd be rather questionable to code that dependency into a new client -
never underestimate the creativity and cleverness of implementers).
New servers with legacy clients risk breaking clients that can't cope with
"revoked" in this case, as you noted:"
End
~~~

---

From: "Black, David" <[email-masked]>
Date: Sat, 30 Mar 2013 22:03:11 -0400

> for non-issued. I know that this is not what you trying to convey.
I don't think that's a good inference ... but this is getting confusing, so
let's go back to the beginning.

An important consideration is that "revoked" is defined in RFC 2560, so all
existing clients have to be able to cope with that response, independent of
whether they comply with 2560 or 2560bis.  They apparently do cope just fine,
as Piyush wrote:

> Legacy clients will continue to work whether you make it required or optional.
What's new is that there's an additional case, non-issued certificate
serial number, where a 2560bis server could return "revoked" but
a 2560 server will never return "revoked".  OTOH, use of "revoked"
can't be required in this case for the reasons described in Stefan's
new text in 2560bis.

That would appear to lead to the following:

- Server (responder) use of "revoked" for non-issued certificate
    serial numbers is optional for the reasons that Stefan described,
    but suggested when possible because it reduces the likelihood
    of relying parties falling back to CRLs by comparison to use of
    "unknown".  I'm carefully avoiding use of "SHOULD" here.
- Clients (requesters) MUST NOT depend on receiving "revoked" for
    non-issued certificate numbers because servers that comply
    with RFC 2560 won't do that.  According to Piyush, all existing
    deployed clients already meet this "MUST NOT" requirement, so
    nothing else is needed.

Stefan's text in -16 covers the first point.  The second point could
be added for additional explanation, but it would need to go outside
the "NOTE:" due to its use of "MUST NOT."

Thanks,
--David

________________________________
From: Piyush Jain [[email-masked]]
Sent: Saturday, March 30, 2013 8:53 PM
To: 'Stefan Santesson'; Black, David; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15