Subject: [pkix] 2560bis

From: Stephen Kent <[email-masked]>
Date: Sun, 29 Jul 2012 13:13:40 -0400

Folks,

Recent messages exchanges point to significant disagreement about the 
future direction
for this doc. At the March meeting Stefan presented a proposal for how 
to move
ahead, as outlined in his slides. As noted in the minutes, the audience 
(at the mic)
included one indication of support for this streamlined approach, and 
one expression
of concern. Not a lot of interest.

Work on this doc has dragged on for 2 years now. In October of 2011 
Santosh argued that
version -04 of the doc was, in his opinion, a step backwards, adding 
more confusion to
RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of 
2012), and
thus he created the current, stripped-down version of the doc (-05) 
which was published
recently.

Given the mixed response to this version, it's not clear that the WG 
members who are interested
in OCSP clarifications are in agreement on how to proceed.

So, let's begin a straw poll on the topic.  Here are the options I am 
offering:

     A - continue to work with the -05 version as the basis for an RFC
     B - revert to the -04 version as the basis for an RFC
     C - don't publish a clarifications document for OCSP
     D - the respondent volunteers to work on a new version of 2560bis

Please send your replies to the list starting now. The straw poll will close
in two weeks, on August 12. While there are many other, legitimate 
comments one could
offer, I am interested only in replies to this multiple choice straw 
poll (i.e., no
essay replies :-) )

Thanks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Sun, 29 Jul 2012 13:18:57 -0400

A.

On Jul 29, 2012, at 1:13 PM, Stephen Kent wrote:

> Folks,
> 
> Recent messages exchanges point to significant disagreement about the future direction
> for this doc. At the March meeting Stefan presented a proposal for how to move
> ahead, as outlined in his slides. As noted in the minutes, the audience (at the mic)
> included one indication of support for this streamlined approach, and one expression
> Work on this doc has dragged on for 2 years now. In October of 2011 Santosh argued that
> version -04 of the doc was, in his opinion, a step backwards, adding more confusion to
> RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of 2012), and
> thus he created the current, stripped-down version of the doc (-05) which was published
> recently.
> 
> Given the mixed response to this version, it's not clear that the WG members who are interested
> So, let's begin a straw poll on the topic.  Here are the options I am offering:
> 
> in two weeks, on August 12. While there are many other, legitimate comments one could
> offer, I am interested only in replies to this multiple choice straw poll (i.e., no
> essay replies :-) )
> 
> Thanks,
> 
> Steve
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 29 Jul 2012 16:01:17 -0400

Steve,

My vote would be A + adding client side processing rules a la Section 6 of 5280.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Sunday, July 29, 2012 1:14 PM
To: pkix
Subject: [pkix] 2560bis

Folks,

Recent messages exchanges point to significant disagreement about the future direction for this doc. At the March meeting Stefan presented a proposal for how to move ahead, as outlined in his slides. As noted in the minutes, the audience (at the mic) included one indication of support for this streamlined approach, and one expression of concern. Not a lot of interest.

Work on this doc has dragged on for 2 years now. In October of 2011 Santosh argued that version -04 of the doc was, in his opinion, a step backwards, adding more confusion to RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of 2012), and thus he created the current, stripped-down version of the doc (-05) which was published recently.

Given the mixed response to this version, it's not clear that the WG members who are interested in OCSP clarifications are in agreement on how to proceed.

Please send your replies to the list starting now. The straw poll will close in two weeks, on August 12. While there are many other, legitimate comments one could offer, I am interested only in replies to this multiple choice straw poll (i.e., no essay replies :-) )

Thanks,

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Jul 2012 21:04:26 +0100

a

---

From: Stephen Kent <[email-masked]>
Date: Sun, 29 Jul 2012 17:16:20 -0400

I've seen message from you, today, but I don;t recall if I saw the 
messages because I also
was cc'd.

I have seen errors from the mail list manager software, as would be the 
case if your
messages were being held.

Steve

On 7/29/12 4:51 PM, Michael Myers wrote:
> Ping.
>
> I suspect I'm not getting through to PKIX for some reason.
>
> Mike
>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 29 Jul 2012 19:56:40 -0700

Voting for A.

Clarifications.

The approach of A is to start from the original 2560 RFC and only fix what
is "broken" or clearly needed, include errata's and include the published
OCSP algorithm agility RFC.
The 05 draft is a starting point where I have included all the advertised
fixes of 04, without rewriting the whole OCSP spec.

If anyone now feels that anything is missing (like Santosh advertised),
then we can discuss adding more stuff, but any stuff added/clarified must
be motivated and agreed.

Proceeding with alternative B probably also includes finding an author
that is prepared to bring the 04 draft to completion.
At present I doubt that I can take on doing that given the opposition
(including my own) of the 04 draft approach.

Steve and I have agreed to submit the 05 version tomorrow (to make it more
accessible). If the WG decides to go ahead with option B, then 04 can be
resubmitted as 06.
Until then the 05 draft is available here:
http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.txt

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 30 Jul 2012 10:06:35 -0400

Voting for B.

As primary author of the -04 draft, I am willing to work to bring that 
draft to completion, following the "Way forward" that Stefan described 
in the final slide of his presentation as the March meeting:

• Resolve the designated responder clarification
• Final review?
• WG-‐LC

• Let’s get this over with.

On 07/29/2012 10:56 PM, Stefan Santesson wrote:
> .

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 30 Jul 2012 10:28:30 -0400

David,

I am willing to support you on Option B.  I do not recall if this was in our private conversation only or in the PKIX post, but in order for that to work, you need to discuss how the client need to enforce the various trust models you present in the annex(es) and how that relates to gaining crypto binding since name uniqueness is not guaranteed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Monday, July 30, 2012 10:07 AM
To: pkix
Subject: Re: [pkix] 2560bis

Voting for B.

As primary author of the -04 draft, I am willing to work to bring that draft to completion, following the "Way forward" that Stefan described in the final slide of his presentation as the March meeting:

• Resolve the designated responder clarification • Final review?
• WG-‐LC

On 07/29/2012 10:56 PM, Stefan Santesson wrote:
> Voting for A.
>
>
> Clarifications.
>
> The approach of A is to start from the original 2560 RFC and only fix 
> what is "broken" or clearly needed, include errata's and include the 
> published OCSP algorithm agility RFC.
> The 05 draft is a starting point where I have included all the 
> advertised fixes of 04, without rewriting the whole OCSP spec.
>
> If anyone now feels that anything is missing (like Santosh 
> advertised), then we can discuss adding more stuff, but any stuff 
> added/clarified must be motivated and agreed.
>
> Steve and I have agreed to submit the 05 version tomorrow (to make it 
> more accessible). If the WG decides to go ahead with option B, then 04 
> can be resubmitted as 06.
>> future direction for this doc. At the March meeting Stefan presented 
>> a proposal for how to move ahead, as outlined in his slides. As noted 
>> in the minutes, the audience (at the mic) included one indication of 
>> support for this streamlined approach, and one expression of concern. 
>> Not a lot of interest.
>>
>> Santosh argued that version -04 of the doc was, in his opinion, a 
>> step backwards, adding more confusion to RFC 2560 vs. clarifying it. 
>> Stefan agreed (in a message in March of 2012), and thus he created 
>> the current, stripped-down version of the doc (-05) which was 
>> published recently.
>>
>> members who are interested in OCSP clarifications are in agreement on 
>> how to proceed.
>>
>> Please send your replies to the list starting now. The straw poll 
>> will close in two weeks, on August 12. While there are many other, 
>> legitimate comments one could offer, I am interested only in replies 
>> to this multiple choice straw poll (i.e., no essay replies :-) )
>>
>> Thanks,
>>
>> Steve
>>
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 30 Jul 2012 11:59:10 -0400

Santosh,

I believe that I found the message to which you are referring.  As you 
noted in your message, these issues are not particular to OCSP, but are 
relevant to X.509-based PKIs in general.  The issues also apply, for 
example, to the processing of CRLs and to attribute certificates.  At 
the time, I suggested addressing things like this by writing a separate 
document that describes best practices for both issuers and relying 
parties, not just for OCSP, but for the PKI in general.  I said that I 
would be willing to work on such a document, but got no responses to 
that suggestion.

As for 2560bis, I certainly want to do my best to address everyone's 
concerns, but I can only do so within the mandate that I was given to 
not make any changes to the protocol.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 09:17:48 -0700

The 05 draft is now submitted:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-05

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 30 Jul 2012 12:18:15 -0400

David,

The problem with saying these problems are not unique OCSP is somewhat misleading.  While what you say is true, draft 04 took an explicit step away from crypto binding (which is implicit and explicit in places in 2560) and relied on names alone without discussing compensating controls.

Thus, while the issue may be general, for a bis to be in the right direction from the current RFC, it needs to address it or point to a document that addresses it.  Thus, this is something that needs to be integral to 2560 bis strategy, be it in the document or in a separate guidance that bis cites.

In terms of working on such item, if the WG is in favor of it and the WG chairs want me to, I am happy to work on it with you.

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 11:59 AM
To: Santosh Chokhani
Cc: pkix
Subject: Updating the -04 draft of 2560bis (was Re: [pkix] 2560bis)

Santosh,

I believe that I found the message to which you are referring.  As you noted in your message, these issues are not particular to OCSP, but are relevant to X.509-based PKIs in general.  The issues also apply, for example, to the processing of CRLs and to attribute certificates.  At the time, I suggested addressing things like this by writing a separate document that describes best practices for both issuers and relying parties, not just for OCSP, but for the PKI in general.  I said that I would be willing to work on such a document, but got no responses to that suggestion.

As for 2560bis, I certainly want to do my best to address everyone's concerns, but I can only do so within the mandate that I was given to not make any changes to the protocol.

Dave

On 07/30/2012 10:28 AM, Santosh Chokhani wrote:
>> Proceeding with alternative B probably also includes finding an 
>> author that is prepared to bring the 04 draft to completion.
>> more accessible). If the WG decides to go ahead with option B, then 
>> 04 can be resubmitted as 06.
>> http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.t
>> x
>> t
>>
>>
>>
>> /Stefan
>>    
>>
>>
>>> Recent messages exchanges point to significant disagreement about 
>>> the future direction for this doc. At the March meeting Stefan 
>>> presented a proposal for how to move ahead, as outlined in his 
>>> slides. As noted in the minutes, the audience (at the mic) included 
>>> one indication of support for this streamlined approach, and one expression of concern.
>>> Not a lot of interest.
>>>
>>> members who are interested in OCSP clarifications are in agreement 
>>> on how to proceed.
>>>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 09:44:06 -0700

I agree with Santosh here that RFC 2560 provided mechanisms for crypto
binding, it just failed to be clear enough on the subject.

More importantly, this is how OCSP is implemented, thus the update need to
reflect that.
The 05 draft has a paragraph in section 4.2.2.2 (2nd paragraph) that deals
with client behavior.

The principle for authorized responders being. Clients MUST recognize OCSP
certs issued by the same CA key as issued the cert being checked. Clients
MAY recognize OCSP certs issued by the CA using a different key.

The wording may not be perfect (suggestions are welcome) but in principle
I think this provides what you ask for.

/Stefan

On 12-07-30 9:18 AM, "Santosh Chokhani" <[email-masked]> wrote:

>David,
>
>The problem with saying these problems are not unique OCSP is somewhat
>misleading.  While what you say is true, draft 04 took an explicit step
>away from crypto binding (which is implicit and explicit in places in
>2560) and relied on names alone without discussing compensating controls.
>
>Thus, while the issue may be general, for a bis to be in the right
>direction from the current RFC, it needs to address it or point to a
>document that addresses it.  Thus, this is something that needs to be
>integral to 2560 bis strategy, be it in the document or in a separate
>guidance that bis cites.
>
>In terms of working on such item, if the WG is in favor of it and the WG
>chairs want me to, I am happy to work on it with you.
>
>example, to the processing of CRLs and to attribute certificates.  At the
>time, I suggested addressing things like this by writing a separate
>would be willing to work on such a document, but got no responses to that
>suggestion.
>
>concerns, but I can only do so within the mandate that I was given to not
>make any changes to the protocol.
>
>Dave
>
>> I am willing to support you on Option B.  I do not recall if this was
>>in our private conversation only or in the PKIX post, but in order for
>>that to work, you need to discuss how the client need to enforce the
>>various trust models you present in the annex(es) and how that relates
>>to gaining crypto binding since name uniqueness is not guaranteed.
>>
>> ? Resolve the designated responder clarification ? Final review?
>> ? WG--LC
>>
>> ? Let’s get this over with.
>>
>>
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 30 Jul 2012 13:52:12 -0400

Stefan,

As I stated in a previous message 
(http://www.ietf.org/mail-archive/web/pkix/current/msg31423.html), I 
believe there is a bit of miscommunication here.

RFC 2560 imposes a requirement of "same CA," and your draft doesn't 
change that. What it does say in Section 4.2.2.2 is that "The CA SHOULD 
use the same issuing key...." In other words, it is not a violation of 
the protocol to use different keys, but it isn't a good idea either.

In the -04 draft, I didn't include any conformance requirements in this 
area (such as you propose in the second paragraph of Section 4.2.2.2 of 
the -05 draft) since there were no conformance requirements in RFC 2560, 
and I was mandated not to make any changes. However, I came as close to 
saying "SHOULD use the same key" as I thought that I could without 
violating the "no changes" mandate. I included notes that warned issuers 
that use of different keys would cause interoperability problems since 
some clients would be unable to process such responses, and I included 
an example in Appendix E to show how a CA could perform a key rollover 
while continuing to work with clients that require the target 
certificate and the OCSP responder certificate to be signed using the 
same key.

I'm not against what you wrote in Section 4.2.2.2 of the -05 draft, as 
it is not inconsistent with RFC 2560. However, it is a change from RFC 
2560 since it is specifying conformance requirements and RFC 2560 didn't 
specify any.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 11:38:04 -0700

I view it as a clarification, as it is consistent with the general
perceived intention of the standard and consistent with current deployment.

The clarification is necessary for OSCP response providers. They need this
to know what configuration they have reason to expect to work with
compliant clients.
That is, issue from the same key and it works. If you don't, you can't
expect it to work.

The clarifications is necessary for clients to know why they are required
to support.

Hence the clarification is necessary.

/Stefan

On 12-07-30 10:52 AM, "David A. Cooper" <[email-masked]> wrote:

>>>the
>>>that

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 12:06:41 -0700

Sorry, bad typo here:

>The clarifications is necessary for clients to know why they are required

This should be:
The clarifications is necessary for clients to know what they are required
to support.

---

From: [email-masked] (Martin Rex)
Date: Tue, 31 Jul 2012 22:32:33 +0200 (CEST)

I'm for option  A.

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 31 Jul 2012 19:46:12 -0400

B.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Kent [[email-masked]]
Sent: Sunday, July 29, 2012 1:13 PM
To: pkix
Subject: [pkix] 2560bis

Folks,

Thanks,

Steve