Subject: Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 10:34:19 -0400

Martin,

I went all the way to Sam's original message about his discuss on the 
draft that became RFC 5019:

https://www.ietf.org/mail-archive/web/pkix/current/msg03627.html

and reviewed the 60 or so messages in the thread.

Aside: I think when you're referring to "updating" RFC 5019 you're 
referring to the updates header.  I'd not put a lot of weight in the 
presence or absence of the updates header.  The IESG has waffled 
including it, authors forgetting about including it, etc.  What's clear 
in the thread was that there was a WGLC issued with the understanding 
that pre-RFC 5109 was going update the semantics of the error code in 
RFC 2560.  I can't find any objections and the WG consensus was to 
proceed.  Should the header have been added - maybe, but I don't 
actually find any messages asking for it to be added and push back on 
it.  What the text in 5019 says is that "this profile extends the RFC 
2560 [OCSP] definition of "unauthorized" as follows:"

Your issue, at least to me, seems to be that you'd prefer that new error 
codes be defined instead of double-upping on unauthorized error.  I've 
been letting this exchange go to see if anybody else rallies to your 
flag (i.e., joins your cause, gets on your bandwagon, etc).  I've not 
seen that and I think you're in the rough here.

But, as one of my fellow ADs constantly reminds everyone, one person can 
blow up consensus if they're right.  So...

I think all of this is based on your message to PKIX in late January:

"
The "unauthorized" response of rfc2560 means

"this is not a public service, and your OCSP request is outside of
  our terms-of-service.  Go away."
"

I think you're reading a whole lot in to definition from RFC 2560:

  The response "unauthorized" is returned in cases where the client is
  not authorized to make this query to this server.

I find it really hard to make the leap to if client sends a request to a 
non-public server and continues to request status information that it 
means they've violated the terms of use of the private server and by 
doing so the client has committed a crime.

If we're about interoperability, then I'm waiting for those that think 
this change breaks things.  To date I've not see folks say that it does.

Yes, this is all an odd way to use an error code for application
specific reasons. However, there really is no point is us moving away
from that (again, admittedly odd) behavior if there's no sign that any
client will be updated for this. The lack of implementers backing
your point seems to put you even deeper in the rough.

Unless I've misconstrued something, that's the rough consensus.

spt

On 3/23/13 2:52 AM, Martin Rex wrote:
> The IESG wrote:
>>
>> The IESG has received a request from the Public-Key Infrastructure
>> (X.509) WG (pkix) to consider the following document:
>> - 'X.509 Internet Public Key Infrastructure Online Certificate Status
>>     Protocol - OCSP'
>>    <draft-ietf-pkix-rfc2560bis-15.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2013-03-27.
>
> I'm having an issue with a subtle, backwards-incompatible change
> of the semantics of the exception case with the error code
> "unauthorized", which tries to rewrite history 13 years into the
> without actually fitting the OCSP spec.
>
> It's about the second change from the introduction:
>
>       o  Section 2.3 extends the use of the "unauthorized" error
>           response, as specified in [RFC5019].
>
> While it is true that the error code abuse originally first appeared
> in rfc5019, the change was never declared as an update to rfc2560,
> nor filed as an errata to rfc2560.
>
> The original Exception cases in rfc2560 define the following semantics:
>
>    http://tools.ietf.org/html/rfc2560#section-2.3
>
>     2.3 Exception Cases
>
>     In case of errors, the OCSP Responder may return an error message.
>     These messages are not signed. Errors can be of the following types:
>
>     -- malformedRequest
>     -- internalError
>     -- tryLater
>     -- sigRequired
>     -- unauthorized
>
>   [...]
>
>     The response "sigRequired" is returned in cases where the server
>     requires the client sign the request in order to construct a
>     response.
>
>     The response "unauthorized" is returned in cases where the client is
>     not authorized to make this query to this server.
>
>
> The proposed "extended" semantics from the rfc2560bis draft:
>
>    http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9
>
>     The response "unauthorized" is returned in cases where the client is
>     not authorized to make this query to this server or the server is not
>     capable of responding authoritatively (cf. [RFC5019], Section 2.2.3).
>
> The rfc5019 semantics "The server can not provide an authoritative response
> to this specific request" is incompatible with the semantics "you are not
> authorized to sumbit OCSP requests to this service".
>
> There is another serious conflict with the rfc5019 repurposed error code
> semantics and rfc2560.  While rfc5019 is limited to a single status request,
> rfc2560 and rfc2560bis both allow a list of several Requests to
> be sent in a single OCSPRequest PDU.  An OCSP response, however, is
> not allowed to contain responseBytes when an error code is returned
> inthe response status:
>
>    http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1
>
>     4.2.1 ASN.1 Specification of the OCSP Response
>
>     An OCSP response at a minimum consists of a responseStatus field
>     indicating the processing status of the prior request. If the value
>     of responseStatus is one of the error conditions, responseBytes are
>     not set.
>
>     OCSPResponse ::= SEQUENCE {
>        responseStatus         OCSPResponseStatus,
>        responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }
>
>
> So it is impossible to convey "OCSP responder is not capable of
> responding authoritatively" for a subset of Requests in the requestList
> and regular status for the remaining Requests in the List by using
> a repurposed "unauthorized" error code.
>
> The current draft neither mention this contradiction, nor does it
> provide any guidance how an implementation should behave in this
> situation.
>
>
> I would appreciate if this problem of draft-*-rfc2560bis could be fixed
> prior to making it a successor for rfc2560.
>
>
> -Martin
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 8 Apr 2013 13:35:00 -0700

Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the "suitability for the intended purpose" test.  Or at least it fails the KISS principle w.r.t. that.

Rephrasing:  an OCSP client should be able to tell from an OCSP response if:  a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions.  It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so.  Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice.

Therefore I vote against moving this draft forward.  I just don't see the point.

If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote.  Obviously an appendix in 2560bis would serve just as well.

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 8 Apr 2013 15:01:04 -0700

+1. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henry B. Hotz
> Sent: Monday, April 08, 2013 1:35 PM
> To: Sean Turner
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509
> Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP)
> to Proposed Standard
> 
> Actually, what I get from this and all the other discussions is that it's
unclear if
> the updated OCSP satisfies the "suitability for the intended purpose"
test.
> Or at least it fails the KISS principle w.r.t. that.
> 
> Rephrasing:  an OCSP client should be able to tell from an OCSP response
if:
> a) the subject cert is on the CAs white list, b) the subject cert is on
the CAs
> black list, c) the subject cert is not on either list, or finally d) the
OCSP server
> is obsolete, and doesn't support making those distinctions.  It's not
trivial to
> see how to parse 2560bis responses w.r.t. those cases, therefore it's
highly
> likely that computational complexity will prevent us from doing so.  Even
if
> that's not actually the case, then implementor misunderstandings will
> prevent us from doing so in practice.
> 
> If someone were to write an informational RFC which explained how to
> determine which of the 4 cases an OCSP response fell into, AND if said RFC
> also convinced me that the decision process was easy to understand, THEN I
> would change my vote.  Obviously an appendix in 2560bis would serve just
as
> well.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Apr 2013 11:02:44 +0100

Nothing has changed in this regard.

The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that extensions may be used to expand this
default information about the status.

This is how it always have been, and still is in RFC 256bis.

The revoked response simply means that the certificate is revoked.
Combined with the new extension, it MAY also be used for non-issued certs.

It's really as simple as that.

It is only the discussion on this list that is confusing and that has
managed turn something really simple into a complicated debate.

/Stefan

On 4/8/13 9:35 PM, "Henry B. Hotz" <[email-masked]> wrote:

>unclear if the updated OCSP satisfies the "suitability for the intended
>purpose" test.  Or at least it fails the KISS principle w.r.t. that.
>
>if:  a) the subject cert is on the CAs white list, b) the subject cert is
>on the CAs black list, c) the subject cert is not on either list, or
>finally d) the OCSP server is obsolete, and doesn't support making those
>distinctions.  It's not trivial to see how to parse 2560bis responses
>w.r.t. those cases, therefore it's highly likely that computational
>complexity will prevent us from doing so.  Even if that's not actually
>the case, then implementor misunderstandings will prevent us from doing
>so in practice.
>
>determine which of the 4 cases an OCSP response fell into, AND if said
>RFC also convinced me that the decision process was easy to understand,
>THEN I would change my vote.  Obviously an appendix in 2560bis would
>serve just as well.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Apr 2013 06:37:49 +0100

On 4/12/13 1:31 AM, "Henry B. Hotz" <[email-masked]> wrote:

>What I would find helpful, and what I think some people really would
>like, is for OCSP to be able to provide white-list information in
>addition to the previous black-list information.  When I read through
>2560bis, I could not tell if there was an extension which would allow an
>RP to tell if "good" actually meant a cert was on the white list (and to
>know the responder has the white list), or merely not on the black list.
>(Yes, I'm repeating myself.  Am I making more sense, or just wasting
>everyone's time?)

What we have done is to roll out the red carpet and made it possible for
you to do that.

- The only thing you need to do now is to define a "white-list" extension.

To put it simply. Given how OCSP is designed, the only way to allow "good"
to represent a white-list, is if "revoked" can be returned for everything
else.
Everything else in this context means every other revoked or non-issued
certificate serial number under that CA.

With RFC 2560 that is not possible in a clean way.
With this new extension in RFC 2560bis, it is now possible.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Apr 2013 17:31:38 -0700

> This is how it always have been, and still is in RFC 256bis.

So a non-issued cert may be "good".

> Combined with the new extension, it MAY also be used for non-issued certs.

So a non-issued cert may be "revoked".

> It's really as simple as that.

I would have thought that what was simple was to say a non-issued cert was "unknown", since it's neither known-good, nor known-revoked.  Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert?

> managed turn something really simple into a complicated debate.

What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility.  That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol.  

I don't find the claim that nothing has changed helpful.

What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information.  When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if "good" actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list.  (Yes, I'm repeating myself.  Am I making more sense, or just wasting everyone's time?)

>> THEN I would change my vote.  Obviously an appendix in 2560bis would

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Apr 2013 04:35:16 +0200 (CEST)

Henry B. Hotz wrote:
> 
> Stefan Santesson <[email-masked]> wrote:
> >

An rfc2560 OCSP responder might return "good" status for a "not issued"
cert.  That is listed as a caveat in the rfc2560 description for "good".

> So a non-issued cert may be "revoked".

Yes.  That is already possible and fully conforming with rfc2560.
It is just not explicitly standardized how to do it.

IMO it is preferable to standardize how to do it consistently,
rather than "letting a thousand flowers bloom" on the significantly
underspecified rfc2560.

> I would have thought that what was simple was to say a non-issued cert
> was "unknown", since it's neither known-good, nor known-revoked.

That is another permissible response for an rfc2560 OCSP responder.
But there is more to consider than just what is permissible by the spec,
and that is client behaviour of an installed base that has grown over
more than a decade.  If a non-marginal fraction of the installed base
will either fallback to CRL checking or do a soft-fail (assume good)
upon receiving "unknown" status, then this choice of response might
not be very sensible.

>
> Is there any collection of extensions which will allow an RP to know,
> for sure, what value will be returned for a never-issued cert?

The two MUSTs at the end of section 2.2 in rfc2560bis-18 plus the
MUST contain the responseExtension from section 4.4.8.

To facilitate recognizing the revocationTime from the end of
section 2.2 rfc2560bis-18, it really ought to be written as UTCTime!

from (-18):
 -  MUST specify the revocationTime January 1, 1970, and;

to (example):
 -  MUST specify the revocationTime "700101000000Z"

> What *I* find confusing is the apparent degree of belief that it is
> possible to improve 2560 and simultaneously to maintain backward
> compatibility.  That should only be possible if there are some
> previously-ignored extensions which alter the semantics of the
> information --- effectively creating a version 2 protocol.  

As far as the spec rfc2560 is concerned, this is trivial from a formal
perspective since there is hardly any client behaviour defined in rfc2560.

But the absence of definition  of client behaviour in rfc2560 also
limits what kind of behaviour can be added now.  In particular, mandating
specific behaviour (MUST rather than SHOULD) or prohibiting specific
behaviour (MUST NOR rather than SHOULD NOT) is going to be a backwards
incompatible change, and unless there is a really convincing rationale
for addition of MUST / MUST NOT behaviour, this will result in a
conflict with rfc2119 Section 6!
  http://tools.ietf.org/html/rfc2119#section-6

> I don't find the claim that nothing has changed helpful.

The claim that "nothing has changed" is provably untrue as long as
the imperative MUST for using the Extension in section 4.4.8 of
rfc2560bis-18 persists.

> 2560bis, I could not tell if there was an extension which would allow
> an RP to tell if "good" actually meant a cert was on the white list
> (and to know the responder has the white list), or merely not on the
> black list.  (Yes, I'm repeating myself.  Am I making more sense,
> or just wasting everyone's time?)

You're correct, a white-list confirmation is not in rfc2560bis.

There seem to be white-list confirmations in current use as OCSP extensions
for some "Qualified Electronic Signature" (QES) usage scenarios, but the
PKIX WG constituency in favour of the rfc2560 defects prevented that any
existing solutions would be adopted for rfc2560bis.

The technical issue with white-listing is, that the original claim about
the OCSP protocol properties is technically wrong.  rfc2560 OCSP,
just like CRLs, is _not_ about the status of certificates, it is purely
about the status of certificate serial numbers.

In order to obtain a technically sound white-listing response, the
"good" response will have to include a certificate hash in an OCSP
singleResponse extension, not just a mere serial number.  And that
seems to be the solution adopted by some existing "QES" usage scenarios.

Since such solutions exist, adopting one of those in rfc2560bis should
be technically trivial.  But... this is PKIX WG, and my impression over
the past 2 years following this WG is that _nothing_ is trivial in PKIX.

I remember that fruitless discussion about an rfc5280 CRL processing defect.
A related, more severe defect exists in X.509 08/2005. Curiously, the X.509
defect has already been sensibly fixed in X.509 11/2008. However, it turned
out to be impossible to make PKIX adopt the X.509 11/2008 fix for rfc5280bis.
During a hot debate, a significant momentum even emerged to adopt further
breakage from X.509 08/2005 instead the fix from X.509 11/2008, and it
took some effort to prevent the additional breakage from getting
rough consensus within PKIX WG...

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 13 Apr 2013 09:03:35 +0200

On 4/13/13 2:53 AM, "Henry B. Hotz" <[email-masked]> wrote:

>You've just said that there are only two valid responses from an OCSP
>server which has access to a white list.  In other words such a server
>inherently cannot provide any information about the actual revocation
>status of a cert, and its responses cannot distinguish between a
>lost/forged/whatever cert and a known-bad (actually revoked) cert.

I realize it's unfair of me to take this quote out of context.  Apologies,
but I want to focus on it. (Stole your words :))

No that is NOT what I say.

An extension may differentiate which serial number that results in a
"revoked" response, that is actually issued and revoked, or if there is
any other particular reason for responding "revoked".
In my universe a syntactically valid serial number can only be good,
revoked or non-issued. But expressing this in general terms anyway.

So with the help of extensions, a responder can provide both white and
black list data.

The legacy client will just look at the status and act accordingly. The
extension aware client and a later audit can use the extensions to further
determine what happened.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 13 Apr 2013 19:35:25 +0200

On 4/13/13 6:51 PM, "Piyush Jain" <[email-masked]> wrote:

>any
>> other particular reason for responding "revoked".
>revoked
>> or non-issued. But expressing this in general terms anyway.
>
>[Piyush]  From an RP's perspective finding status of serial numbers serves
>no purpose unless they can associate that serial number with a
>certificate.

Absolutely, that is the client's perspective of this.

>When an OCSP client extracts the serial number from a certificate and
>sends
>it the responder to determine the status, it is acting under a very
>important assumption - the CA has issued that certificate and that it has
>issued only one certificate with that serial.

Absolutely

>If you say that this assumption is invalid, your trichotomy of serial
>status
>is not mutually exclusive any more. Same serial can now be associated
>with a
>good, revoked and non-issued status.

I didn't say that. I said it can "only be good, revoked or non-issued"

Notice the difference? My sentence contains the word "or", yours the word
"and".

These are the three possible states of a serial number. It must always be
in ONE of these states.

>And also the client cannot be sure if
>the CA delegated responder's certificate is good or non-issued. This
>renders
>OCSP completely useless.

I did not talk about responder certificates.

>black
>> list data.
>[Piyush] May be you are right. But I doubt that you want a discussion on
>feasibility/security implications of this, otherwise it would've been a
>stated goal of 2560bis and would have been captured in the abstract.

If new extensions are defined, then the RFC defining these extensions will
discuss relevant security implications related to those extensions.

>I tried to think ahead but I cannot figure out a way to communicate the
>white listed status of a CA delegated responder to the client without
>avoiding circular logic.

I can.

The "good" response provides by default a minimum level of positive
confirmation.
But it is also make clear that an extensions allows "good" to say more, as
long as it fits within that default statement of "good".

A white list falls within that basic statement.
That is, the serial numbers that will return "good" in a "white-list"
scenario would also return "good" if the responder provided default OCSP
status information.
White listing will simply reduce the number of "good" status to occasions
where it represent a known existing certificate.

>
>I completely fail to see why revoked for non-issued is a pre-requisite for
>future extensions that can be used to provide white-list data (if it is
>even
>possible under CA delegated responder trust model).

I'll try again. It is only possible to reduce the "good" status responses
to white listed certificates if another suitable status can be return for
any other requested serial number.
That is, the combined set of revoked and non-issued serial numbers that
does not belong in the while list.

Responding "unknown" may not be desirable, as it is likely to cause the
client to try another source.

With the update of RFC2560bis it is now being made clear (in the
definition of "revoked"), that it is conformant to respond "revoked" to
both revoked and "non-issued" certificates, while before, that could be
questioned as a stretch of semantics.

So yes indeed, the updates makes it easy to take the next step into a
white-list OCSP responder by adding a suitable extension.
Of course, only those understanding the new extension will know that it is
a "white list" response.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 14 Apr 2013 01:24:09 +0200

On 4/13/13 8:56 PM, "Piyush Jain" <[email-masked]> wrote:

>> >[Piyush]  From an RP's perspective finding status of serial numbers
>> >serves no purpose unless they can associate that serial number with a
>> >certificate.
>> 
>Great. We agree
>> >sends it the responder to determine the status, it is acting under a
>> >very important assumption - the CA has issued that certificate and that
>> >it has issued only one certificate with that serial.
>> 
>> Absolutely
>Great. We agree.  
>Let me reiterate -OCSP client extracts the serial number assuming that the
>CA issued the certificate and issued only one certificate with that serial
>number. So why do we need the responder to return non-issued for the same
>certificate?

Because of your lack of fantasy :)
Shift your focus from the client to the server.

A client have control over never asking for a non-issued certificate,
unless the CA is broken.
The server have not.

A bad, broken or malicious client may for what ever reason it may have,
send a request for a non-issued certificate.
If that happens, the protocol should allows ways to handle that.

Just imagine a such benign situation of a client with a bug, that sends
the wrong serial number if the most significant bit is set.
For half of it's requests it sends requests for completely non existent
certs.

Perhaps not likely, but possible.

The chance of discovering this error increase significantly if the
non-issued serial number requests returns "revoked" instead of "good".

This just on top of the case of a broken CA.

>> >status is not mutually exclusive any more. Same serial can now be
>> >associated with a good, revoked and non-issued status.
>> 
>I stand by my words :).

Feel free. But saying a million times that a black stone is white, does
not change its colour.

>in
>> ONE of these states.
>As long as you assume that a certificate signed by the CA cannot be
>non-issued i.e. CA knows what certificates it issued.
>If you break that assumption, you have to deal with the possibility of
>different certificates with same serial numbers (after all certificates
>are
>getting issued without CA's knowledge). This implies that the same serial
>number can be associated with a good certificate and a non-issued
>certificate.
>
>Let me frame it in a different way. If you get a "good" response from a
>responder that issues "revoked" for "non-issued", can you be sure that the
>certificate you are checking is not a non-issued certificate?
>

No, to take it to that level, you need a new white list extension.
You see this from the wrong angle.

This change is not intended to provide the client indisputable knowledge
about whether a certificate is non-issued or not.
It is intended to give the responder a means of causing the client to
reject rather than accept something that is known not to be good.

>> >renders OCSP completely useless.
>> 
>You did not. But that does not make my statement any less relevant or
>incorrect and strengthens Henry's point about this spec achieving what it
>is
>trying to do.
>

It makes your statement totally irrelevant until the point where you can
demonstrate its relevance.

/Stefan

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 12 Apr 2013 17:53:10 -0700

> to represent a white-list, is if "revoked" can be returned for everything

I realize it's unfair of me to take this quote out of context.  Apologies, but I want to focus on it.

You've just said that there are only two valid responses from an OCSP server which has access to a white list.  In other words such a server inherently cannot provide any information about the actual revocation status of a cert, and its responses cannot distinguish between a lost/forged/whatever cert and a known-bad (actually revoked) cert.

The actual information which an OCSP responder might (should?) have would include both a white list and a black list.  An RP using OCSP to determine "the current status of a digital certificate without requiring CRLs" (as it says in the abstract) would hope to receive the available information about a subject cert.  In other words, after a successful query, it would hope to know if the subject cert was known-good, known-bad, or neither.

By combining the known-bad and neither responses, the RP must now use CRLs in order to distinguish those two cases.  

This situation would appear to contradict the first sentence in the abstract of the document.  Doesn't a change which requires a change in the abstract exceed the authorized scope of this revision to 2560?  If it doesn't then I think the abstract needs to be updated.

I don't understand why we're trying so hard to avoid providing both the white-list and the black-list information at the same time in OCSP responses.  

(Nit:  Since the Introduction repeats the Abstract, the reference to 5912 added to the Abstract should also be added to the Introduction.)

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 13 Apr 2013 09:51:28 -0700

any
revoked

[Piyush]  From an RP's perspective finding status of serial numbers serves
no purpose unless they can associate that serial number with a certificate.
When an OCSP client extracts the serial number from a certificate and sends
it the responder to determine the status, it is acting under a very
important assumption - the CA has issued that certificate and that it has
issued only one certificate with that serial.
If you say that this assumption is invalid, your trichotomy of serial status
is not mutually exclusive any more. Same serial can now be associated with a
good, revoked and non-issued status. And also the client cannot be sure if
the CA delegated responder's certificate is good or non-issued. This renders
OCSP completely useless.

black

I completely fail to see why revoked for non-issued is a pre-requisite for
future extensions that can be used to provide white-list data (if it is even
possible under CA delegated responder trust model).

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 13 Apr 2013 11:56:46 -0700

Great. We agree
Great. We agree.  

I stand by my words :).

in
different certificates with same serial numbers (after all certificates are

You did not. But that does not make my statement any less relevant or
incorrect and strengthens Henry's point about this spec achieving what it is
trying to do.

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 13 Apr 2013 18:01:07 -0700

Stefan,

I don't think that we have any gaps in the technical understanding of this
proposal. Based on the discussions over the last few months, I can
confidently say that the difference of opinion is around the benefits of
adoptions and the costs associated with it.

Here are the possible goals that had been discussed
1) Address CA compromise issue
2) Provide certificate white list/black list information to the clients
3) Allow CAs to return revoked for non-issued. Some clients in some
situation benefit by not falling back to CRL validation.

I understand that according to you, 3 is the only goal for this update. So I
am basing the following on that goal

Benefits
~~~~~~~
- In some situations, It allows clients to reject some (not all)
fraudulently issued certificates that are and not detected by the CA.
- It allows buggy clients sending incorrect serial number to detect the bug.
(This is based on your last post, but I don't think that you seriously
consider this a benefit :))
Limitations
~~~~~~~~
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
- Works only if attacker did not fraudulently issued a responder
certificate.
- Works only if client is configured to use OCSP as primary validation
option
- Works only if responder is not a CRL based responder.
- Works only if responder is producing live responses. 

Cons (this is where we have the disagreement)
~~~~
- Stated goal leaves it to the imagination of readers to figure out the
problem that is being tackled.
- Provides false sense of security. Readers may believe that it addresses CA
compromise issue.
- Challenges the fundamental assumption behind x.509 processing that
certificate signature and certificate issuance are equivalent.
- Leaves the clients to deal with the paradox of responder trust if they
choose to interpret the response as meaning non-issued as opposed to revoked
- It's a change in the main document, so every implementer will have to go
through it even though the benefit is very limited to specific scenarios.
- The unintended consequence is that people will incorrectly start believing
that CRLs are less secure that OCSP.
- The draft exceeds the stated goal in the abstract (protocol useful in
determining the current   status of a digital certificate without requiring
CRLs)

I understand that you don't see the cons listed above as major problem.  
Your position is that it does not affect any other deployments except the
CAs who want to support it. That is technically correct, but the side effect
of this explicit endorsement from pkix is that the proponents start touting
this as the secure solution that needs to be adopted by everyone. They don't
have the luxury/motivation to look at pkix discussions to understand the
limitations of this approach.
As an example, there was a proposal in CAB forum to move away from CRL based
responders. Thankfully, a few vendors who have heavily invested in
pre-signed OCSP infrastructure voted against it.

On a final note, I understand there are facts and there are opinions and
this particular instance there are opinions galore (including mine:) ).
I suggest we move on, and let the IETF decide. I don't think our opinions
will converge with any more discussion. We'll have lot more data in a few
years to evaluate the diverse opinions that were presented in this WG. There
is always the option of coming out with another update if things don't go as
planned :).

-Piyush

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Saturday, April 13, 2013 4:24 PM
> To: Piyush Jain; 'Henry B. Hotz'
OCSP)
> >> >serves no purpose unless they can associate that serial number with
> >> >a certificate.
> >>
> >> >When an OCSP client extracts the serial number from a certificate
> >> >and sends it the responder to determine the status, it is acting
> >> >under a very important assumption - the CA has issued that
> >> >certificate and that it has issued only one certificate with that
serial.
> >>
> >> Absolutely
> >Great. We agree.
> >Let me reiterate -OCSP client extracts the serial number assuming that
> >the CA issued the certificate and issued only one certificate with that
> >serial number. So why do we need the responder to return non-issued for
> >the same certificate?
> 
unless
> the CA is broken.
send
> a request for a non-issued certificate.
the
> wrong serial number if the most significant bit is set.
certs.
> The chance of discovering this error increase significantly if the
non-issued
> serial number requests returns "revoked" instead of "good".
> 
> >> >If you say that this assumption is invalid, your trichotomy of
> >> >serial status is not mutually exclusive any more. Same serial can
> >> >now be associated with a good, revoked and non-issued status.
> >>
> >> Notice the difference? My sentence contains the word "or", yours the
> >>word  "and".
> >
> >I stand by my words :).
> 
not
> change its colour.
> >are getting issued without CA's knowledge). This implies that the same
> >serial number can be associated with a good certificate and a
> >non-issued certificate.
> >
> >responder that issues "revoked" for "non-issued", can you be sure that
> >the certificate you are checking is not a non-issued certificate?
> >
> 
reject
> rather than accept something that is known not to be good.
> 
> 
> >
> >>
> >> >And also the client cannot be sure if the CA delegated responder's
> >> >certificate is good or non-issued. This renders OCSP completely
> >> >useless.
> >>
> >incorrect and strengthens Henry's point about this spec achieving what
> >it is trying to do.
> >
> 
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 16 Apr 2013 18:26:18 -0700

On Apr 13, 2013, at 4:24 PM, Stefan Santesson <[email-masked]> wrote:

>>> These are the three possible states of a serial number. It must always
>>> be in ONE of these states.

Disagree.

The protocol is intended to provide information ("Status") about an identified cert (or serial number if you prefer) so an RP can make the best decision possible about how to treat it within the scope if its own application.  That means that the OCSP responder SHOULD NOT (IMO) conceal the distinction between non-issued and good, nor should it conceal the distinction between non-issued and revoked (for exactly the same reason).  Doing either one of those effectively prevents the information from one of the white- or black-lists from contributing to OCSP responses.  

I don't think it's safe in the first place to assume we know what all the current clients do or want.  I likewise don't think it's safe to assume we know what they will do, should do, or want in the future.  It may be clear how to handle a white-listed or black-listed cert.  However, I can think of several different scenarios for how a non-issued cert ought to be handled.  All of that is outside the scope of OCSPs perview.

>> is trying to do.

I likewise haven't' addressed responder cert's as a special case. :-/

I need to study the spec more carefully.  IIUC Martin seems to imply that you can infer if a cert is white-list/black-list/neither based on new extensions, if enough of them are present.  IIUC Stefan seems to imply the opposite, though the extensions should tell you where the ambiguity is.  My read supported the latter, but I don't want to stake my reputation on it.

------------------------

Assuming what Stefan implies, would people be happy if we updated the abstract/introduction to say that a "new" OCSP response, combined with the CRL would allow an RP to infer which of the three status's a cert has?

When I opposed this draft, I had not yet thought of this combination of protocols.  I see the combination as unnecessarily high-overhead, but a step forward.

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 17 Apr 2013 14:41:04 +0200

> that is not associated with a good certificate.

This can be remedied by using an extension in which a server providing white-list information conveys a hash of the
(genuine) certificate having this serial number. Note, that such an extension does not only exist but is already used in
the context of qualified certificates in Germany: CertHash (OID 1.3.36.8.3.13), defined in CommonPKI.

Johannes

---

From: [email-masked] (Martin Rex)
Date: Thu, 18 Apr 2013 23:22:19 +0200 (CEST)

Johannes Merkle wrote:
> This can be remedied by using an extension in which a server providing
> white-list information conveys a hash of the (genuine) certificate
> having this serial number. Note, that such an extension does not only
> exist but is already used in the context of qualified certificates
> in Germany: CertHash (OID 1.3.36.8.3.13), defined in CommonPKI.

Including URLs for publicly availble specs&infos will be appreciated!
(it is my first encounter with CommonPKI)

Peter Rybar seemed to have suggested inclusion of CertHash in July 2012:
  http://www.ietf.org/mail-archive/web/pkix/current/msg31385.html

but only had a reference to a powerpoint presentation from 2004
with an "experimental" tag.

Google led me here:
  http://www.t7ev.org/ws/T7-en/Common-PKI-V20-Specification

The v2.0 specification PDF document is a concatenation of several documents,

In Common PKI Part 4: Operational Protocols (page 150 of 361) there
is the definition of a CertHash extension to be used in OCSP response
singleExtension:

  3.1.2  Common PKI Private OCSP Extensions

  Table 15: CertHash (Positive Statement)

  id-commonpki-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 3 13}

  CertHash ::= SEQUENCE {
      hashAlgorithm      AlgorithmIdentifier,
      certificateHash    OCTET STRING }

  certificateHash  -- A hash over the DER-encoding of the entire PKC or
  AC (i.e. NOT a hash over tbsCertificate).

     [...]

  Common PKI Profile: The responder may include this extension in a
  response to send the hash of the requested certificate to the responder.
  This hash is cryptographically bound to the certificate and serves as
  evidence that the certificate is known to the responder (i.e. it has
  been issued and is present in the directory).  Hence, this extension
  is a means to provide a positive statement of availability as described
  in T8.[8].  As explained in T13.[1], clients may rely on this information
  to be able to validate signatures after the expiry of the corresponding
  certificate. Hence, clients MUST support this extension.  If a positive
  statement of availability is to be delivered, this extension syntax
  and OID MUST be used.

CommonPKI seems to be about qualified electronic signatures for the German
Digital Signature Act.  Are there any similar standards published
by other (european or otherwise) countries for an private OCSP extension
with a positive statement about certificate issuance?

I think we should have added this to rfc2560bis!

-Martin