Subject: Re: [pkix] RFC2560bis update

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 11:11:18 -0400

Stefan,

If you agree that the approach taken in the -04 draft would result
in a better document than the approach of trying to minimize the
textual changes from RFC 2560, then I don't understand why you
want to go with the latter approach.

The main reason for creating 2560bis was to deal with the problem
of people misinterpreting RFC 2560.  For example, we were getting
messages on the PKIX mail list about browser vendors having to
deal with PKI vendors that had created infrastructures with OCSP
responders that were not compatible with the browser's
implementation, with the PKI vendors then pointing to RFC 2560
(and their interpretation of it) as the basis for arguing that
there was nothing wrong with their infrastructure's architecture
and so the browser vendor needed to deal with it in some manner.
I very careful in the development of the earlier drafts of -04 to
include plenty of text (along with examples in Appendix E) to help
ensure that even someone who wasn't a PKI expert would be able to
understand it.  I was also extremely careful to avoid making any
changes to the protocol, as I was directed when I was given the
assignment to develop 2560bis.

I understand there was some disagreement expressed during the last
IETF meeting with some of the text in the -04 draft, but I don't
think that's an argument for starting from scratch with a new
approach that emphasizes minimizing the textual changes in the
document.  On the contrary, I think it highlights the reason that
we need to go with the approach in the -04 draft.  Most of the
comments that have been made on the -04 draft have been arguments
that the -04 draft differs from RFC 2560 (or at least from what
the commenters believe that RFC 2560 intended to say).  If members
of the PKIX WG can't agree on what RFC 2560 means, then it
shouldn't be a surprise that non-PKI experts are even more prone
to misinterpreting it.

It may be easier to get consensus if we leave the text mostly
unchanged.  But if consensus is achieved because text that is
prone to misinterpretation is left unchanged so that no one can
argue that the protocol was changed, even though they continue to
disagree about what the text means, then we haven't really
achieved the goal that we set for ourselves in developing
2560bis.  Given how import OCSP is, I think it is most important
to make 2560bis the best possible document that it can be rather
than settling for something that is less than ideal in the name of
expedience.

Let us please return to working from the -04 draft.  There seemed
to be consensus that that draft was close to being done, and I
believe that the new text will be very helpful in ensuring that
there is a common understanding of the protocol and enabling clear
communication between producers and consumers (e.g., a browser
vendor could inform PKI vendors that it requires the use of either
integrated OCSP responders in which the target certificate and
response are signed by the same key, as depicted in Figure 1, or
designated OCSP responders in which the target certificate and the
OCSP responder certificate are signed by the same key, as depicted
in Figures 4, 8, and 9).

Dave

On 07/25/2012 06:14 PM, Stefan Santesson wrote:

Hi David,

I appreciate your effort, but we had long serious discussions
on this at the last PKIX meeting and the direction was clear.

We needed to take a step back from the "complete overhaul"
approach and focus on the important changes in a format that was
closer to the original document.

In the end, your document might be better, but a more
restricted approach is easier to evaluate and process through
the WG and the IETF.

/Stefan

From: "David A. Cooper"
<[email-masked]>

Date: Tuesday, 24
July, 2012 5:49 PM

To: Stefan Santesson
<[email-masked]>

Subject: Re: [pkix]
RFC2560bis update

Stefan,

I don't understand why you decided to start from scratch
on the development on 2560bis.  It was my impression
that the -04 draft was very close to being ready to
publish, and that there were only a few minor issues
that needed to be addressed.

There is a reason that the -04 draft is so different
than RFC 2560.  We undertook the development of 2560bis
because there was a lot of message traffic on the PKIX
mail list from people who were having problems as a
result of others misinterpreting RFC 2560.  So, the goal
in developing 2560bis wasn't to make the few changes
mentioned in the Introduction but to address the
problems of people misunderstanding the document.

When I first worked to develop 2560bis, I quickly came
to the conclusion that it would be impossible to address
all of the confusion people were having about OCSP
without reorganizing the document in order to improve
its readability, and when I presented the initial draft
of 2560bis at IETF 78 there was a lot of support for the
approach that I took.  One of the mandates that I was
given when asked to work on 2560bis was to make no
changes to the protocol, and I worked very hard to
ensure that I didn't make any changes.

So, given all of the work that has gone into developing
2560bis and the substantial improvement it makes in the
presentation of the protocol, I don't see the reason to
start from scratch on this and to make the primary goal
to change the text of the document as little as possible
rather than to fix the the problems that lead to the
decision to develop this document in the first place.

Thanks,

Dave

On 07/20/2012 01:07 PM, Stefan Santesson wrote:

All,

I finally got to tackle
the update of RFC2560bis document.

At the last ITEF/PKIX
meeting we concluded that this effort needs a restart.

The changes in the 04
draft compared to the original document are so
extensive that it is hard to make sure that the update
is actually compatible with the existing standard.

I have therefore made a
new draft almost from scratch, trying to change as
little as possible compared to RFC 2560.

The new draft is
available here:

http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_02.txt

A diff compared to RFC
2560 is available here:

http://tinyurl.com/rfc2560bis05diff

The list of changes
(this list is included in the draft) is:

This document differs from RFC 2560 in only a few areas:

o Section 4.1.1 specifies the ASN.1 syntax for the nonce
extension, which was missing in RFC 2560.

o Section 4.4.7 specifies a new extension that may be included in
a request message to specify signature algorithms the client
would prefer the server use to sign the response as specified
in [RFC6277].

o Section 2.3 extends the use of the "unauthorized" error
response, as specified in [RFC5019].

o Section 4.2.1 and 4.2.2.3 states that a response may include
revocation status information for certificates that were not
included in the request, as permitted in [RFC5019].

o Section 4.3 changes set of cryptographic algorithms that
clients must support and the set of cryptographic algorithms
that clients should support as specified in [RFC6277].

o Section 4.2.2.2 has been updated to clarify when a responder is
considered an Authorized Responder.

Section headings and
numbering are as much as possible kept intact from RFC
2560.

The ASN-1 modules are
imported form rfc2560bis draft 04.

What important updates
did I miss to cover in this draft?

If this is considered a
good starting point for a restarted draft effort, then
I will publish this as draft 05 as soon as the draft
submission is re-opened.

/Stefan

---

From: [email-masked]
Date: Fri, 27 Jul 2012 17:25:25 +0200

Dave,

Your email states:

"Let us please return to working from the -04 draft.  There seemed to be 
consensus that that draft was close to being done, ..."

I fully agree that we should continue working from the -04 draft, because 
the structure of RFC 2560 needs to be changed.

However, I strongly disagree "that the draft was close to being done". 
Many changes still need to be done and several pages 
of the draft would need to be deleted.

Denis

De :    "David A. Cooper" <[email-masked]>
A :     "[email-masked]" <[email-masked]>
Date :  27/07/2012 17:11
Objet : Re: [pkix] RFC2560bis update
Envoyé par :    [email-masked]

Stefan,

If you agree that the approach taken in the -04 draft would result in a 
better document than the approach of trying to minimize the textual 
changes from RFC 2560, then I don't understand why you want to go with the 
latter approach.

The main reason for creating 2560bis was to deal with the problem of 
people misinterpreting RFC 2560.  For example, we were getting messages on 
the PKIX mail list about browser vendors having to deal with PKI vendors 
that had created infrastructures with OCSP responders that were not 
compatible with the browser's implementation, with the PKI vendors then 
pointing to RFC 2560 (and their interpretation of it) as the basis for 
arguing that there was nothing wrong with their infrastructure's 
architecture and so the browser vendor needed to deal with it in some 
manner.  I very careful in the development of the earlier drafts of -04 to 
include plenty of text (along with examples in Appendix E) to help ensure 
that even someone who wasn't a PKI expert would be able to understand it. 
I was also extremely careful to avoid making any changes to the protocol, 
as I was directed when I was given the assignment to develop 2560bis.

I understand there was some disagreement expressed during the last IETF 
meeting with some of the text in the -04 draft, but I don't think that's 
an argument for starting from scratch with a new approach that emphasizes 
minimizing the textual changes in the document.  On the contrary, I think 
it highlights the reason that we need to go with the approach in the -04 
draft.  Most of the comments that have been made on the -04 draft have 
been arguments that the -04 draft differs from RFC 2560 (or at least from 
what the commenters believe that RFC 2560 intended to say).  If members of 
the PKIX WG can't agree on what RFC 2560 means, then it shouldn't be a 
surprise that non-PKI experts are even more prone to misinterpreting it.

It may be easier to get consensus if we leave the text mostly unchanged. 
But if consensus is achieved because text that is prone to 
misinterpretation is left unchanged so that no one can argue that the 
protocol was changed, even though they continue to disagree about what the 
text means, then we haven't really achieved the goal that we set for 
ourselves in developing 2560bis.  Given how import OCSP is, I think it is 
most important to make 2560bis the best possible document that it can be 
rather than settling for something that is less than ideal in the name of 
expedience.

Let us please return to working from the -04 draft.  There seemed to be 
consensus that that draft was close to being done, and I believe that the 
new text will be very helpful in ensuring that there is a common 
understanding of the protocol and enabling clear communication between 
producers and consumers (e.g., a browser vendor could inform PKI vendors 
that it requires the use of either integrated OCSP responders in which the 
target certificate and response are signed by the same key, as depicted in 
Figure 1, or designated OCSP responders in which the target certificate 
and the OCSP responder certificate are signed by the same key, as depicted 
in Figures 4, 8, and 9).

Dave

I appreciate your effort, but we had long serious discussions on this at 
the last PKIX meeting and the direction was clear.
We needed to take a step back from the "complete overhaul" approach and 
focus on the important changes in a format that was closer to the original 
document.

In the end, your document might be better, but a more restricted approach 
is easier to evaluate and process through the WG and the IETF.

/Stefan

From: "David A. Cooper" <[email-masked]>
Date: Tuesday, 24 July, 2012 5:49 PM
To: Stefan Santesson <[email-masked]>
Subject: Re: [pkix] RFC2560bis update

Stefan,

I don't understand why you decided to start from scratch on the 
development on 2560bis.  It was my impression that the -04 draft was very 
close to being ready to publish, and that there were only a few minor 
issues that needed to be addressed.

There is a reason that the -04 draft is so different than RFC 2560.  We 
undertook the development of 2560bis because there was a lot of message 
traffic on the PKIX mail list from people who were having problems as a 
result of others misinterpreting RFC 2560.  So, the goal in developing 
2560bis wasn't to make the few changes mentioned in the Introduction but 
to address the problems of people misunderstanding the document.

When I first worked to develop 2560bis, I quickly came to the conclusion 
that it would be impossible to address all of the confusion people were 
having about OCSP without reorganizing the document in order to improve 
its readability, and when I presented the initial draft of 2560bis at IETF 
78 there was a lot of support for the approach that I took.  One of the 
mandates that I was given when asked to work on 2560bis was to make no 
changes to the protocol, and I worked very hard to ensure that I didn't 
make any changes.

So, given all of the work that has gone into developing 2560bis and the 
substantial improvement it makes in the presentation of the protocol, I 
don't see the reason to start from scratch on this and to make the primary 
goal to change the text of the document as little as possible rather than 
to fix the the problems that lead to the decision to develop this document 
in the first place.

Thanks,

Dave

I finally got to tackle the update of RFC2560bis document.

At the last ITEF/PKIX meeting we concluded that this effort needs a 
restart.
The changes in the 04 draft compared to the original document are so 
extensive that it is hard to make sure that the update is actually 
compatible with the existing standard.

I have therefore made a new draft almost from scratch, trying to change as 
little as possible compared to RFC 2560.

The new draft is available here:
http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_02.txt

A diff compared to RFC 2560 is available here:
http://tinyurl.com/rfc2560bis05diff

The list of changes (this list is included in the draft) is:

Section headings and numbering are as much as possible kept intact from 
RFC 2560.
The ASN-1 modules are imported form rfc2560bis draft 04.

What important updates did I miss to cover in this draft?

If this is considered a good starting point for a restarted draft effort, 
then I will publish this as draft 05 as soon as the draft submission is 
re-opened.

/Stefan
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Fri, 27 Jul 2012 17:52:40 +0200 (CEST)

> the structure of RFC 2560 needs to be changed.

I strongly disagree!

If you believe that you need a completely different document structure,
then you should write a completely independent OCSPv2 document that
deals with new future implementations of OCSPv2 and does not care
about the installed base.

If the idea is to make slight modifications to the existing description
of OCSP (rfc2560) that will be clearer to *NEW* implementations that
want to interop with the currently installed base of rfc2560, then
it is vitally important that the changes are small and obvious,
such as when using rfcdiff on rfc2560 and rfc2560bis.

I like Stefan's approach.

-Martin

---

From: [email-masked]
Date: Fri, 27 Jul 2012 18:10:11 +0200

Martin,

You are (voluntarily) misinterpreting my statement.

 I do care about the installed base, and this is why on several aspects 
draft-04 is far from what it should be.

The document needs to be clarified and corrected on several aspects, in 
particular those  dealing with OCSP responses validation.

See my slides from the last meeting in Paris. If you have problems with 
some text in these slides, then, please be very specific.

Denis

De :    [email-masked] (Martin Rex)
A :     [email-masked]
Cc :    "David A. Cooper" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date :  27/07/2012 17:52
Objet : Re: [pkix] RFC2560bis update

I strongly disagree!

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 12:19:17 -0400

Martin,

You seem to be conflating changing the document structure with changing 
the protocol.  The main driver in the development of the -04 draft of 
2560bis was to make the description of the protocol clearer without 
making any changes to the protocol.  Why would we need to change the 
version number of the protocol if we're not changing the protocol?  The 
document structure of RFC 5280 is very different from the document 
structure of X.509, but RFC 5280 still specifies v3 certificates and v2 
CRLs.  No one suggested that had to specify a different version number 
for the certificates and CRLs just because it uses a different document 
structure to describe them.

The changes between RFC 2560 and 2560bis, which are very minor, are 
detailed in the Introduction (just as Stefan has done in his proposed 
text), so a reader does not have to rely on rfcdiff to determine what 
has changed.

Interoperability is the reason that we need to rewrite this with a 
different document structure.  We have interoperability problems now 
with the current text as a result of people not fully understanding the 
text.  If we want interoperability, we need to fix that.

Dave

On 07/27/2012 11:52 AM, Martin Rex wrote:
> .

---

From: [email-masked] (Martin Rex)
Date: Fri, 27 Jul 2012 19:02:43 +0200 (CEST)

> text.  If we want interoperability, we need to fix that.

You're missing the point.

The protocol is *NOT* what some folks may have had on their minds when
rfc2560 was developed.  Instead, the protocol is defined by what the
*current* document says (plus the variation in reading the existing
text has created in readers/ implementers).

If you want to change that text, then you DO, in fact, change the protocol.

A clarification of the existing protocol means that you leave the existing
text and structure as is (except for real errata), and add explanations,
clarification and recommendations how to best interpret and implement
the existing protocol, in order to improve interop with and within the
installed base.

Really, the smaller the changes to an existing implementation are, and
the clearer the advantage of such a small change is conveyed, the more
likely such a change will be made available as a software patch to
the installed base.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jul 2012 10:30:17 -0700

For the record, I disagree with Martin on this. If the protocol changes are all fairly legitimately clarifications, then the protocol number should not be changed. You can (and, unfortunately probably will) argue about whether or not a particular clarification is a change, but that's mostly irrelevant in the real world of deployments.

The IPsec WG dealt with these issue in the IKEv2bis work and, in the end, all implementations just did the right thing.

--Paul Hoffman

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 13:35:42 -0400

Martin,

You can disagree all you want, but it is possible to change the way that 
a protocol is described without changing the protocol itself.  So your 
assertion that "If you want to change that text, then you DO, in fact, 
change the protocol" is simply wrong. Otherwise, you're going to have to 
explain why PKIX was fundamentally wrong to describe X.509 certificates 
in RFC 5280 without changing the version number for the certificates.

I also notice that you haven't pointed to a single instance in the -04 
draft of 2560bis where the reorganization of the document has resulted 
in a change in the protocol, other than those changes explicitly 
highlighted in the Introduction.  You insist that one cannot change the 
text without changing the protocol.  So, provide some evidence.

In addition, if you are so against changing the text because changing 

> likely such a change will be made available as a software patch to

This implies that you are the one who wants to make (small) changes to 
the protocol.

---

From: [email-masked] (Martin Rex)
Date: Fri, 27 Jul 2012 20:19:30 +0200 (CEST)

David A. Cooper wrote:
> 
>    it is possible to change the way that a protocol is described
> without changing the protocol itself.

In theory this is possible, in practice this has NEVER works.

>
> So your assertion that "If you want to change that text, then you DO,
> in fact, change the protocol" is simply wrong.

Just the contrary.  If you did not want change the protocol (and the
interoperability-impaired implemenations based on the existing spec),
then we should end the discussion and kill the rfc2560bis document
here and now.

>
> Otherwise, you're going to have to 

This is something that the authors of X.509 and PKIX would have to explain!

And both of them did:

ITU-T T-REC X.509 11-2008  3rd page:

  Summary

  ITU-T Recommendation X.509 | ISO/IEC 9594-8 defines a framework for
  public-key certificates and attribute certificates. These frameworks
  may be used by other standards bodies to profile their application
  to Public Key Infrastructures (PKI) and Privilege Management
  Infrastructures (PMI).  [...]

RFC5280 PKIX, page 1:

   Abstract

   This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.

> This implies that you are the one who wants to make (small) changes to 

I'm sorry if my english is so terrible.

I am violently opposing to changing the protocol (i.e. the spec).

I am, however, all for giving very precise hints to implementors what
to consider during new implementations or what to change in the behaviour
of existing implementations in order to improve interoperability with
other implementations.

One of the big problems of the feature-ladden protocols around X.509/PKIX
is that there exist independent implementations based on perfectly valid
individual subsets of protocol options that turn out to be non-interoperable
to each other.

There are other that believe that by changing requirement levels for
some protocol options or by killing some protocol options that are
being used in a fashion not intended by the original protocol designers,
is the better approach, because they want to complain to vendors about
non-compliance to a *NEW* protocol spec.

I do not like the latter approach at all, I do not believe that it
works in any reasonable fashion, but most importantly, it has the
pre-requisite of CHANGING the protocol.  Those pushing the latter approach
should at least be honest about that.

-Martin

---

From: "Art Allison" <[email-masked]>
Date: Fri, 27 Jul 2012 14:53:30 -0400

I have not seen another substantive change listed that I happened to spot.
 
The use of the IA5String was optional, but is prohibited in -06 (and at least back to -04)..
This is clearly not backwards compatible for any implementation that choose to use the IA5String.

In general, adding a substantive feature might be reasonable to obtain more capability, but directly obsoleting previous hard-coded implementations in shipped products would force those using the old approach to ignore the new RFC.

Art

Art Allison 
Senior Director Advanced Engineering, Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org 
Advocacy  Education  Innovation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, July 27, 2012 2:20 PM
To: David A. Cooper
Cc: [email-masked]
Subject: Re: [pkix] RFC2560bis update

> in fact, change the protocol" is simply wrong.

Just the contrary.  If you did not want change the protocol (and the interoperability-impaired implemenations based on the existing spec), then we should end the discussion and kill the rfc2560bis document here and now.

> explain why PKIX was fundamentally wrong to describe X.509 
> certificates in RFC 5280 without changing the version number for the certificates.

And both of them did:

  Summary

RFC5280 PKIX, page 1:

   Abstract

> > Really, the smaller the changes to an existing implementation are, 
> > and the clearer the advantage of such a small change is conveyed, 
> > the more likely such a change will be made available as a software 
> > patch to the installed base.
> 

I am, however, all for giving very precise hints to implementors what to consider during new implementations or what to change in the behaviour of existing implementations in order to improve interoperability with other implementations.

One of the big problems of the feature-ladden protocols around X.509/PKIX is that there exist independent implementations based on perfectly valid individual subsets of protocol options that turn out to be non-interoperable to each other.

There are other that believe that by changing requirement levels for some protocol options or by killing some protocol options that are being used in a fashion not intended by the original protocol designers, is the better approach, because they want to complain to vendors about non-compliance to a *NEW* protocol spec.

I do not like the latter approach at all, I do not believe that it works in any reasonable fashion, but most importantly, it has the pre-requisite of CHANGING the protocol.  Those pushing the latter approach should at least be honest about that.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 14:59:20 -0400

Art,

I believe that you are referring to the rules for encoding the 
explicitText string in draft-ietf-pkix-rfc5280-clarifications, not to 
2560bis, which is the topic of this discussion.

Dave

---

From: "Art Allison" <[email-masked]>
Date: Fri, 27 Jul 2012 15:01:18 -0400

Apologies.. 
Yes, wrong thread <principal applies here too, though not the specific cite>

Art Allison 

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Friday, July 27, 2012 2:59 PM
To: Art Allison
Cc: [email-masked]
Subject: Re: [pkix] RFC2560bis update

Art,

I believe that you are referring to the rules for encoding the explicitText string in draft-ietf-pkix-rfc5280-clarifications, not to 2560bis, which is the topic of this discussion.

Dave

On 07/27/2012 02:53 PM, Art Allison wrote:
> Senior Director Advanced Engineering, Technology National Association 
> of Broadcasters
> 1771 N Street NW
> Washington, DC 20036
> Phone  202 429 5418
> Fax  202 775 4981
> www.nab.org
>> This implies that you are the one who wants to make (small) changes 
>> to the protocol.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 15:28:40 -0400

Art,

Actually, it is not the same principle.  Martin is claiming that it is 
not possible to change the way one describes a protocol (in order to 
make the description of the protocol more clear) without 
(unintentionally) changing the protocol itself.  The change the you cite 
in the 5280 update document wasn't unintentional, so it not an example 
of a change that was accidentally (and unknowingly) introduced as a 
result of an attempt to state the same requirements in a different way.

The change that you cite in the 5280 update document actually dates back 
to the -00 draft of that document 
(http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-00). 
As I recall, the proposed change was made for (at least) a couple of 
reasons.

The scope of the 5280 update document was initially limited to 
addressing issues that were discovered as a result of an effort to find 
interoperable implementations of the features in RFC 5280, as was 
required at the time to advance a document to the status of Draft 
Standard.  One of the things that I documented as an issue in my report 
(http://tools.ietf.org/id/draft-cooper-pkix-rfc5280-impl-report-01.txt) 
was the following:

    The user notice certificate policy qualifier allows for user notice
    text to be encoded using one of four string types: IA5String,
    VisibleString, BMPString, and UTF8String.  While RFC 2459 and RFC
    3280 provided no guidance on the selection of an encoding, RFC 5280
    requires that user notice text be encoded in either UTF8String or
    IA5String.  During the search for interoperable implementations,
    several Web server and email client certificates were located that
    included user notices, but they all encoded the user notices using
    the VisibleString type.  A few people also noted that at least one CA
    product encoded user notice text in BMPString.  Therefore, an update
    to RFC 5280 [RFC5280u] is being developed that permits user notices
    to be encoded as VisibleString or BMPString.

So, this change was not made with a disregard for backwards 
compatibility with existing implementations, but in an effort to more 
closely align the requirements with the behavior of existing 
implementations.

This change was further supported by the statement in the text that "The 
explicitText string SHOULD NOT include any control characters."  If I 
recall correctly, a comparison of IA5String and VisibleString showed 
VisibleString to consist of the characters of IA5String minus the 
control characters, so VisibleString was the more appropriate choice for 
encoding in addition to being the one that implementers were already using.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 14:18:25 -0700

This statement by Denis is one of the reasons why I believe it is better to
reduce the changes to what is necessary.

Changing the whole document structure may provide some advantages, but
brings more disadvantages.
Practically it makes it very hard for a reader to figure out what has
actually changed.

It also makes it a lot harder to process the document through the IETF as
people will disagree on whether the changes is actually better/more accurate
and whether they pose substantial changes that may render a compliant
implementer non-comformant.

Things are not black or white. I simply believe that doing minimal changes
to the original document serves the community best.
Don't fix what is not broken.

/Stefan

From:  <[email-masked]>
Date:  Friday, 27 July, 2012 8:25 AM
To:  "David A. Cooper" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] RFC2560bis update

> However, I strongly disagree "that the draft was close to being done". Many
> changes still need to be done and several pages

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 30 Jul 2012 16:14:52 -0700

Going back to my memories of the discussions that prompted this update, there are two issues I thought were important:  1) the lack of clarity about what the response codes meant, and 2) the need for some allowance for a separating the signer for revocation info from the main CA chain.  I note that there is a new MAY which might allow a way to address 2).  If it actually allows some mitigation of a hacked CA, I wish there were some corresponding discussion.

T. Miller had a very nice writeup comparing the three response codes with what a responder would actually be able to know and answer for.  I see no changes relating to that.  IMO that info needs to get put in.  IMO it ought to replace the paragraph which says a "never issued" cert is "good".  That probably violates the stated scope of this update, so I my be in the rough, consensus-wise.

At the very highest level, a PKI with long-lived certs needs a parallel infrastructure which can prevent bad certs from being used.  OCSP is the thing which is actually deployed for that function.  IMO it needs to be fixed so it can actually provide that functionality.  For me getting the function done effectively trumps details about backward compatibility.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 18:49:25 -0700

Henry,

On 12-07-30 4:14 PM, "Henry B. Hotz" <[email-masked]> wrote:

>Going back to my memories of the discussions that prompted this update,
>there are two issues I thought were important:  1) the lack of clarity
>about what the response codes meant, and 2) the need for some allowance
>for a separating the signer for revocation info from the main CA chain.
>I note that there is a new MAY which might allow a way to address 2).  If
>it actually allows some mitigation of a hacked CA, I wish there were some
>corresponding discussion.
>
>T. Miller had a very nice writeup comparing the three response codes with
>what a responder would actually be able to know and answer for.  I see no
>changes relating to that.  IMO that info needs to get put in.  IMO it
>ought to replace the paragraph which says a "never issued" cert is
>"good".  That probably violates the stated scope of this update, so I my
>be in the rough, consensus-wise.

Text regarding response codes has been updated, but only to accommodate
Lightweight OCSP.
This effort is not suitable for what you ask for, which I think
discussions on this list has demonstrated.

>
>At the very highest level, a PKI with long-lived certs needs a parallel
>infrastructure which can prevent bad certs from being used.  OCSP is the
>thing which is actually deployed for that function.  IMO it needs to be
>fixed so it can actually provide that functionality.  For me getting the
>function done effectively trumps details about backward compatibility.

The problem is that not all agree what "that problem" means in reality.
There is no way the current OCSP protocol can assure that a bad
certificate form a compromised CA will be marked "bad".
If the CA is not compromised, the current protocol works as it is.

Discussions has shown that it is hard to agree on what level of
"compromise" that OCSP protocol should be able to capture as result of
such effort.

Thus, it need to be discussed separate form this update.

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 31 Jul 2012 10:56:03 -0400

Henry,

I believe that you are referring to discussions that took place on the 
mail list earlier this year in which people proposed changes to OCSP.

The decision to develop 2560bis was made a couple of years ago, and it 
was agreed at the time that the scope of the update would be limited to 
making the presentation of the protocol more clear and that no changes 
would be made to the protocol.

As I recall there were several discussion threads involving questions 
about OCSP at the time.  Here is one of the messages that I found from 
one of those threads that helped to motivate the development of 2560bis: 
http://www.ietf.org/mail-archive/web/pkix/current/msg27687.html. That 
message provides one example of the problems that were occurring as a 
result of some people misunderstanding RFC 2560, and the types of issues 
that I worked very hard to try to address in the -04 draft of 2560bis.

Dave

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 31 Jul 2012 11:04:33 -0700

So we agree that I'm in the rough consensus-wise about what I think needs to be done to OCSP.  ;-)  There is a perfectly defensible viewpoint that OCSP is the wrong solution for the problem anyway, and you should use SCVP instead (if it were available anyway).

My frustration is that just doing the MUST's for the RFCs that are actually implemented (e.g. in browsers and public CAs) and deployed doesn't get you the advertised level of security.  You need to pick and choose options, lobotomize deployments, and implement extra stuff to get to what I would consider "good" security.  There doesn't seem to be consensus to close the gap.  Or at least attempts to gain consensus seem to generate an excessive amount of heat.  I've even seen multiple threats to ignore the products of this group if the results don't meet some constraints some implementor wants, irrespective of the technical goals or overall consensus.

I'm just frustrated that the kinds of clarifications in 2560bis seem inadequate to deal with the overall gap between the advertised security and actual security of the biggest application of this protocol.  *sigh*