Subject: [pkix] Responder trust issue for non-issued certificates not addressed in 2560 bis draft 11

From: "Piyush Jain" <[email-masked]>
Date: Sun, 27 Jan 2013 08:12:59 -0800

Stefan,

I raised the issue regarding responder trust in case of non-issued
certificate earlier (please see attached email). 

In my opinion, section 4.2.2.2 in the current draft violates section 9 of
RFC 2418 in cases where the responder indicates that the certificate is
non-issued.
Not sure if my proposal in the attached email handles  this issue
completely, but it is a step forward from the current text.

Regards
-Piyush

Subject: RE: Addressing issues in 4.2.2.2 of rfc2560bis-08
From: "Piyush Jain" <[email-masked]>
To: <[email-masked]>
Date: Mon, 14 Jan 2013 16:16:59 -0800

I just realized that even my new proposal does not fix the paradox if the
RP decides to consider the CA as compromised in context of current
transaction.
Unfortunately, I don't see any way to resolve this paradox under existing
OCSP trust models.
Here is the revised text where I changed the recommendation to consider CA
compromised for future use instead of current and future uses. It is akin
to saying - Trust me for once when I say "I always lie" :).

NEW PROPOSED TEXT

Systems or applications that rely on OCSP responses MUST be capable of
detecting and enforcing use of the id-kp-OCSPSigning value as described
above. They MAY provide a means of locally configuring one or more OCSP
signing authorities, and specifying the set of CAs for  which each signing
authority is trusted. They MUST reject the response if the certificate
required to validate the signature on the response fails to meet at least
one of the following criteria:
   1. Matches a local configuration of OCSP signing authority for the
certificate in question; or
   2. Is the certificate of the CA that signed the certificate in
question; or
   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
extension and is signed by the CA that signed the certificate in question
as stated above."

If the response trust is established by using either (1) or (2) and if the
response status is revoked with reason code notIssuedOrIrregularlyIssued
(7), it implies that the CA has no record of issuance of some of the
certificates that were signed using its private key. In this case, it is
recommended that the relying application considers the CA that issued the
certificate in question as compromised for any future use. 

> -----Original Message-----
> From: Piyush Jain [mailto:[email-masked]]
> Sent: Saturday, January 12, 2013 7:50 AM
> To: [email-masked]
> Subject: Addressing issues in 4.2.2.2 of rfc2560bis-08
> 
> Hi list,
> 
> Here is the proposal to address the issue in section 4.2.2.2 that I
brought up
> in bullet point 4 of my original review post . You don't need to refer
to that
> post. Context is provided below.
> 
> CURRENT TEXT
> 
> Systems or applications that rely on OCSP responses MUST be capable of
> detecting and enforcing use of the id-kp-OCSPSigning value as described
> above. They MAY provide a means of locally configuring one or more OCSP
> signing authorities, and specifying the set of CAs for  which each
signing
> authority is trusted. They MUST reject the response if the certificate
> required to validate the signature on the response fails to meet at
least one
> of the following criteria:
>    1. Matches a local configuration of OCSP signing authority for the
certificate
> in question; or
>    2. Is the certificate of the CA that issued the certificate in
question; or
>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
extension
> and is issued by the CA that issued the certificate in question as
stated
> above."
> 
> ISSUES
> - Creates a paradox If (2) or (3) are used to establish trust in the
response
> and if the response is marked as revoked because certificate was "not-
> issued". If the RP trusts response, it implies that the certificate was
not
> issued by the CA which implies that the RP should not trust the
response.
> This can be addressed by changing all references to "issued" to "signed"
in
> the above text. Please not that this is a problem only for certificates
that
> exist, not for non-existent certificate. RPs who send queries for
non-existent
> certificates have no way to establish trust in the response if the
response is
> signed by a delegated responder.
> - If the RP determines that certificate was signed by the CA and if the
> response is marked as revoked with extended revoked definition, it
implies
> that RP has encountered a certificate signed by the CA for which CA has
no
> record of issuance. Most likely cause for this is RA/CA compromise.
Others
> have pointed out there may be some 'not so severe' reasons such as loss
of
> issuance record etc. Unfortunately, there is no way for the responder to
> communicate the exact reason to the RP and RPs should assume the worst
> case scenario.
> 
> PROPOSED TEXT
> 
> Systems or applications that rely on OCSP responses MUST be capable of
> detecting and enforcing use of the id-kp-OCSPSigning value as described
> above. They MAY provide a means of locally configuring one or more OCSP
> signing authorities, and specifying the set of CAs for  which each
signing
> authority is trusted. They MUST reject the response if the certificate
> required to validate the signature on the response fails to meet at
least one
> of the following criteria:
>    1. Matches a local configuration of OCSP signing authority for the
certificate
> in question; or
>    2. Is the certificate of the CA that signed the certificate in
question; or
>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
extension
> and is signed by the CA that signed the certificate in question as
stated
> above."
> 
> If the response trust is established by using either (1) or (2) and if
the
> response status is revoked with reason code notIssuedOrIrregularlyIssued
> (7), it implies that the CA has no record of issuance of some of the
certificates
> that were signed using its private key. In this case, it is recommended
that
> the relying application considers the CA that issued the certificate in
question
> as compromised for any current or future use.
> 
> COMMENTS:
> I'm using Denis's proposal to represent "non-issued" by reason code
> notIssuedOrIrregularlyIssued(7). If the consensus is that we extended
> revoked extension is a better choice, then we can change the text
> accordingly.

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 20:37:57 +0100

We are not trying to solve CA compromise. CA compromise and strategies for
dealing with them is far to complex to deal with in this update.
Further I don't think we should put any requirements on clients to do
anything in this regard in the base protocol standard.

This and other PKI problem works as long as the trusted authorities are
intact and honest.
Dealing with and detecting compromise is not part of the protocol design.

What you say is true, but including that information would be very
incomplete.
I would prefer not to go there at all.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 27 Jan 2013 16:47:48 -0800

Stefan,

You've decided to introduce the concept of non-issued certificates as part
of this update.
Don't you think it makes sense to provide guidance to compliant clients as
to what their behavior should be if they receive such a response?

If clients continue to trust a responder that returned non-issued for a
certificate for which the client has performed signature verification, it
takes a huge risk by assuming that CA is not compromised.

This is an excerpt from section 9 of RFC 2418
"It should be noted that all IETF working groups are required to examine and
understand the security implications of any technology they develop.  This
analysis must be included in any resulting RFCs in a Security Considerations
section.  Note that merely noting a significant security hole is no longer
sufficient.  IETF developed technologies should not add insecurity to the
environment in which they are run."

> This and other PKI problem works as long as the trusted authorities are
intact and honest.
Unfortunately, this is not true according to current update. You need
non-issued only if you questioning the value of signature on the certificate
being validated. 

> Dealing with and detecting compromise is not part of the protocol design.
I thought this was the only reason for the new changes in current draft,
driven by requirements from CAB forum.

If you just want them to allow changing the meaning of revoked, have them do
it through a single response extension which defines the meaning through an
object which is part of that extension. They can then define the extended
meaning in a separate document and do the security analysis there.
If you are introducing non-issued in main OCSP document, you should provide
guidelines on how a compliant client should deal with such a response.

> What you say is true, but including that information would be very
incomplete.
I agree with you there. Unfortunately what we have today is incomplete
because we have not provided any guidance to compliant clients on how to
deal with such a response securely.

> I would prefer not to go there at all.
We are already going there with this update.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Sunday, January 27, 2013 11:38 AM
> To: Piyush Jain; [email-masked]
> Subject: Re: Responder trust issue for non-issued certificates not
addressed
> in 2560 bis draft 11
intact
> and honest.
> >In my opinion, section 4.2.2.2 in the current draft violates section 9
> >of RFC 2418 in cases where the responder indicates that the certificate
> >is non-issued.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 07:19:26 +0100

Let me correct you on one thing.

I have not decided to introduce the concept of non-issued.
That is a WG decision.

I personally don't expect clients to assume anything but the fact that the
trust service they trust, is actually trustworthy and intact.
I don't expect clients to be on the scout for detecting compromised CA's.

Saying that clients SHOULD treat that CA as compromised, puts requirements
on client code developers to:
- Detect the reason for revocation
- Trying to determine if it may be caused by CA compromise
- Remembering that CA to alter the interpretation of results for certs
issued by that CA in the future.

This is going WAY beyond what clients should be expected to do.

The fact that we give servers a legitimate way to not respond "god" to
non-issued certificates, does not mean that we need to impose a new scope
of operation upon the clients.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 28 Jan 2013 08:18:29 -0800

> I have not decided to introduce the concept of non-issued. That is a WG
decision.
My apologies.  It was wrong choice of words on my part.

trust service they trust, is actually trustworthy and intact.
This is a good point. Can you please clarify how the client can establish
trust in a response signed by a delegated responder if the response says
that certificate is non-issued. There will be developers who will read this
RFC and ponder over the same question. 
For your reference I am including the relevant text from 2560-bis-11 that
deals with responder trust

--BEGIN QUOTE
They MUST reject the response if the certificate required to validate the
signature on the  response fails to meet at least one of the following
criteria:
   1. Matches a local configuration of OCSP signing authority for the
certificate in question; or
   2. Is the certificate of the CA that issued the certificate in question;
or
   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
extension and is issued by the CA that issued the certificate in  question
as stated above."
--END QUOTE

You can see that based on above, the client MUST reject the response if it
is signed by either the CA or a CA delegated responder and if the payload
certificate is not issued by the same CA.

> - Remembering that CA to alter the interpretation of results for certs
issued
> by that CA in the future.

All fair points. I'm open to any other solution that addresses these issues
that were brought up earlier. (I believe that you acknowledged them as
well).
- How can a compliant client establish trust in a response signed by a
delegated responder that indicates that certificate is not issued by the CA?
- How should a client deal with the scenario where it has a certificate that
is signed by the CA but the CA delegated responder returns a response saying
that the certificate is non-issued.? IMO, the only conclusion here is that
the CA or RA is compromised and any proposed solution should capture this
fact. May be we can have a provision for determining client behavior based
on a local policy, to allow clients to make the choice for themselves.
Nevertheless, the document should state the implications of any choice
clearly. 

> The fact that we give servers a legitimate way to not respond "god" to
non-issued certificates, 
Slight correction there. Servers can respond with unknown, UNAUTHORIZED, TRY
LATER even before the current update and many large CA vendors already do
this. You probably meant - legitimate way to respond 'revoked' for
"non-issued".

> does not mean that we need to impose a new scope of operation upon the
clients.
We have a new extension that is being defined in this update. I appreciate
the backward compatibility requirement. However, the document still needs to
define how future clients who decide to parse this extension, deal with this
information. Otherwise, what is the point of including this extension at
all?

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 17:50:14 +0100

Comments in line

On 1/28/13 5:18 PM, "Piyush Jain" <[email-masked]> wrote:

>Can you please clarify how the client can establish

I think I understand what you mean, but reading the question literally, I
don't

Trust in a responder is established before you try to interpret it's
responses.
If you ask how to deal with the response, then the client will not get a
non-issued response. It will get a "revoked" status.
This indicates that the certificate they asked about should not be trusted.

This is all they are expected to do.
They are not expected to contact the CA, call the fire department ore
trigger a national alert :)

This may not be perfect, but it is better than receiving a "good" response.

>question;

It's quite easy. If they trust the responder, they are supposed to trust
the response.
If they have not established the trust described above, they MUST reject
the response.

This has nothing to do with what responses they get.

>delegated responder that indicates that certificate is not issued by the

This is reiterating the same issue.
Establishing trust and parsing responses are two separate issues. Getting
a possible "revoked" instead of a "good" does not change this.

A client may of course draw conclusions about a certificate that seems
genuine, but shows signs of being non-issued, but they are not expected to
do so.
They are just expected to not accept the certificate if its marked
"revoked". As they always have been.

>Nevertheless, the document should state the implications of any choice

Again, the responder responds revoked. The fact that it is non-issued is
hidden in heuristics that the client isn't expected to deal with or
understand.
In the "client" world, the client is dealing with a revoked cert that is
placed on hold.

>this. You probably meant - legitimate way to respond 'revoked' for

Absolutely :)

>information. Otherwise, what is the point of including this extension at

Actually not.
There is no need to define client strategies for mitigating or detecting
compromised CAs based on the fact that we allowed a revoked response to
non-issued certs.

This is beyond the scope of the defined protocol to provide such guidance.
As long as the protocol is implemented correctly, vendors are free to add
any functionality or strategy on top of this.

Whatever guidance we would try to come up with, it would be incomplete or
to narrow to be generally applicable.
In addition, we could easily spend a couple of years debating what that
strategy should be.

If we ask the clients to be anything but a statless machine dealing with
status requests independently according to it's configured trust model, we
are asking too much.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 28 Jan 2013 10:09:13 -0800

You said
>"It's quite easy. If they trust the responder, they are supposed to trust
the response.
the response.
>This has nothing to do with what responses they get."

I disagree with this statement. The document clearly states that contents of
responses should be looked at before accepting the response. This includes
looking at signature and certid contained in the response. 
Not-issued response is something that is introduced in this draft and the
current discussion is about how the client establishes trust in such a
response.

> If you ask how to deal with the response, then the client will not get a
non- issued response. It will get a "revoked" status.
> This indicates that the certificate they asked about should not be
trusted.

I was under the impression that syntax of 'revoked' is only being used for
backward compatibility. And that revocation date-1970 in conjunction with
revocation status onhold implies that certificate is not-issued. Also the
new extended revoked extension implies that certificate is not-issued.
Are you now arguing that 'revoked' and 'not-issued' should be semantically
equivalent as well? 

Finally, here is a point regarding providing guidance to clients.
Non-issued response is a new state that is being introduced in this update.
The only reason revoked is being overloaded is to maintain backward
compatibility with existing clients. However, to assume that future clients
won't try to interpret the meaning of extended revoked extension is
short-sighted. Avoiding guidelines on how clients deal with it is bound to
cause confusion for anyone who uses this RFC  to implement a OCSP client.
The fact is that in absence of such guidelines, clients would probably
continue to trust a responder that is issued by a CA which is compromised
(level of compromise is irrelevant here). At the minimum, we should clarify
the implications so clients can make informed choices.  I repeat that
failing to do so is violation of RFC 2418.

[-----Original Message-----
> Sent: Monday, January 28, 2013 8:50 AM
> Subject: Re: [pkix] Responder trust issue for non-issued certificates not
> addressed in 2560 bis draft 11
> 
> Comments in line
> 
> >Can you please clarify how the client can establish trust in a response
> >signed by a delegated responder if the response says that certificate
> >is non-issued. There will be developers who will read this RFC and
> >ponder over the same question.
> >For your reference I am including the relevant text from 2560-bis-11
> >that deals with responder trust
> 
don't
responses.
> If you ask how to deal with the response, then the client will not get a
non-
> issued response. It will get a "revoked" status.
trigger
> a national alert :)
> >They MUST reject the response if the certificate required to validate
> >the signature on the  response fails to meet at least one of the
> >following
> >criteria:
> >extension and is issued by the CA that issued the certificate in
> >question as stated above."
> >--END QUOTE
> >
> >You can see that based on above, the client MUST reject the response if
> >it is signed by either the CA or a CA delegated responder and if the
> >payload certificate is not issued by the same CA.
> 
the
the
> >All fair points. I'm open to any other solution that addresses these
> >issues that were brought up earlier. (I believe that you acknowledged
> >them as well).
a
> possible "revoked" instead of a "good" does not change this.
> 
"revoked".
> As they always have been.
> 
> 
> >- How should a client deal with the scenario where it has a certificate
> >that is signed by the CA but the CA delegated responder returns a
> >response saying that the certificate is non-issued.? IMO, the only
> >conclusion here is that the CA or RA is compromised and any proposed
> >solution should capture this fact. May be we can have a provision for
> >determining client behavior based on a local policy, to allow clients
> >to make the choice for themselves.
understand.
> In the "client" world, the client is dealing with a revoked cert that is
placed on
> hold.
> >Slight correction there. Servers can respond with unknown,
> >UNAUTHORIZED, TRY LATER even before the current update and many
> large
> >CA vendors already do this. You probably meant - legitimate way to
> >respond 'revoked' for "non-issued".
> 
> Absolutely :)
> 
> >
> >We have a new extension that is being defined in this update. I
> >appreciate the backward compatibility requirement. However, the
> >document still needs to define how future clients who decide to parse
> >this extension, deal with this information. Otherwise, what is the
cx> >point of including this extension at all?
> As long as the protocol is implemented correctly, vendors are free to add
any
> functionality or strategy on top of this.
> 
status
> requests independently according to it's configured trust model, we are
> asking too much.
> 
> /Stefan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 21:24:51 +0100

>looking at signature and certid contained in the response.

Of course, I didn't say it because its central and kind of obvious.

> 
>Not-issued response is something that is introduced in this draft

No, look closer. The draft does NOT define a "not-issued" response. It
allows the "revoked" response if a certificate serial number has never
been issued.
That is two entirely different things.

>and the

As it would with any other response.

>revocation status onhold implies that certificate is not-issued.

No. The meaning is just to allow the server to provide a response that has
the likely outcome that the client will not use that cert, if there even
is such a cert and the request isn't simply an error.

> Also the

No, the extension signals that the server supports this extended use of
revoked. It says nothing about whether it is used for any of the certs in
a particular response.

>Non-issued response is a new state that is being introduced in this

This is getting tiresome. No, there is no new state. There is an extended
use of "revoked".

>cause confusion for anyone who uses this RFC  to implement a OCSP client.

No, all may experience with PKI development suggests contrary to your
prediction.
However, if we tried to craft some extensive guidance on how to try to
detect and mitigate CA compromise, that will definitely cause confusion
and make implementers think they have to deal with this.

>(level of compromise is irrelevant here).

Which is exactly what we expect them to do. It is not the clients task to
spot and correct the problem of compromised CAs.
That is the task of trust service providers and the controls they put in
place.

> At the minimum, we should clarify

No. Security considerations requires you to discuss security issues
introduced by a protocol.
The added mechanism does not introduce any new security vulnerabilities
that you have pointed out.
To the contrary.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 28 Jan 2013 13:09:59 -0800

Stefan,

Clearly we have disagreement on how this issue is addressed in current
draft.  
I'm actually surprised at your statement that clients should not
differentiate between non-issued and revoked certs, given that the draft
mandates that servers include extended revoked extension if it  is changing
the meaning of revoked. If it is so, why bloat the response with this
extension at all.

So far, besides you and me, Peter Rybar is the only one who has referred to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.

-Piyush

> Sent: Monday, January 28, 2013 12:25 PM
> >I disagree with this statement. The document clearly states that
> >contents of responses should be looked at before accepting the
> >response. This includes looking at signature and certid contained in
> >the response.
> 
allows
> the "revoked" response if a certificate serial number has never been
issued.
> >I was under the impression that syntax of 'revoked' is only being used
> >for backward compatibility. And that revocation date-1970 in
> >conjunction with revocation status onhold implies that certificate is
not-
> issued.
is such a
> cert and the request isn't simply an error.
> 
> 
> > Also the
> >Are you now arguing that 'revoked' and 'not-issued' should be
> >semantically equivalent as well?
> 
a
> particular response.
use
> of "revoked".
> >compatibility with existing clients. However, to assume that future
> >clients won't try to interpret the meaning of extended revoked
> >extension is short-sighted. Avoiding guidelines on how clients deal
> >with it is bound to cause confusion for anyone who uses this RFC  to
> >implement a OCSP client.
> 
and
> make implementers think they have to deal with this.
> 
> 
> >continue to trust a responder that is issued by a CA which is
> >compromised (level of compromise is irrelevant here).
> 
spot
> and correct the problem of compromised CAs.
place.
> No. Security considerations requires you to discuss security issues
introduced
> by a protocol.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 22:37:31 +0100

Piyush,

>the meaning of revoked. If it is so, why bloat the response with this

As it has been stated here before, and also communicated in the minutes of
the last PKIX meeting in Atlanta, the rationale behind including this
extension is to allow audits.
If something goes wrong and you go through the records, there will be
evidence that the responder that provided a particular response of
interest, supported this functionality.

No client is required to understand this extension or to do anything with
it to function properly.
My personal preference would be to not define this extension at all, but
having this extension is so far WG rough consensus and hence it is
included in the draft.
Enough people feel strongly about it and it does no damage to have it
there.

/Stefan

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

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 29 Jan 2013 09:52:47 +0100

Stefan,

The discussion is now days and nights since we have participants from 
around the world.
I have not yet started to review your answers to my comments, but in the 
mean time I took a look
at the numerous messages that have been exchanged.

You said: "My personal preference would be to not define this extension 
at all",

Piyush does not want it either.

I don't think it is needed either.

Since the revocation date is set to January, 1rst 1970, I can't imagine 
*today *another real use case where we would have that date.
So checking this value is entirely sufficient to know that the 
certificate serial number has not been used to the knowledge of the CA.

So we are at least three persons who believe that we should not define 
that extension.

Now, if some other persons can demonstrate that this extension is really 
needed, then it is time for them to speak up.

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jan 2013 10:14:09 +0100

It's not a matter of what individuals want.

It is about finding to best common ground that everyone can live with.
It was evident form the last PKIX meeting in Atlanta, and from the
discussion on the list that preceded that meeting, that having this
extension was necessary to reach WG consensus on expanding the "revoked"
scope.

This has already been dealt with in the WG process. Those who need to speak
up are those wanting to change the decision and demonstrate why it need to
be removed.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Tuesday, January 29, 2013 9:52 AM
To:  Stefan Santesson <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

>     
>  
> Stefan,
>  
>  The discussion is now days and nights since we have participants from around
> the world.
>  I have not yet started to review your answers to my comments, but in the mean
> time I took a look
>  You said: "My personal preference would be to not define this extension at
> all", 
>  
>  Since the revocation date is set to January, 1rst 1970, I can't imagine today
> another real use case where we would have that date.
>  So checking this value is entirely sufficient to know that the certificate
> serial number has not been used to the knowledge of the CA.
>  
>  So we are at least three persons who believe that we should not define that
> extension.
>  
>> On 1/28/13 10:09 PM, "Piyush Jain" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>  
>>>  
>>> Stefan,
>>> 
>>>> On 1/28/13 7:09 PM, "Piyush Jain" <[email-masked]>
>>>> <mailto:[email-masked]>  wrote:
>>>> 
>>>>  
>>>>>  
>>>>> You said
>>>>>  
>>>>>>  
>>>>>> This indicates that the certificate they asked about should not be
>>>>>>  
>>>>>  
>>>>> trusted.
>>>>> 
>>> [email-masked]://www.ietf.org/mailman/listinfo/pkix
>>>  
>>  
>> [email-masked]://www.ietf.org/mailman/listinfo/pkix
>>  
>  
>  
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 29 Jan 2013 10:33:32 +0100

Stefan,

Since you say that from the last PKIX meeting in Atlanta, and from the 
discussion on the list that preceded that meeting,
it is *evident* that this extension is needed, would be please recall 
shortly why ?

In addition, would you be able to provide a counter argument to my 
argumentation below ?

Then we should also other people that are not on the same time zone to 
speak up.

Denis

> extension was necessary to reach WG consensus on expanding the 
> "revoked" scope.
>
> This has already been dealt with in the WG process. Those who need to 
> speak up are those wanting to change the decision and demonstrate why 
> it need to be removed.
>
> /Stefan
>
> From: Denis Pinkas <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [pkix] Responder trust issue for non-issued certificates 
> not addressed in 2560 bis draft 11
>
>     Stefan,
>
>     The discussion is now days and nights since we have participants
>     from around the world.
>     I have not yet started to review your answers to my comments, but
>     in the mean time I took a look
>     You said: "My personal preference would be to not define this
>     extension at all",
>
>     Since the revocation date is set to January, 1rst 1970, I can't
>     imagine *today *another real use case where we would have that date.
>     So we are at least three persons who believe that we should not
>     define that extension.
>
>     Now, if some other persons can demonstrate that this extension is
>     really needed, then it is time for them to speak up.
>
>     Denis
>
>
>>     Piyush,
>>
>>     On 1/28/13 10:09 PM, "Piyush Jain"<[email-masked]>  wrote:
>>
>>>     Stefan,
>>>
>>>>     To: Piyush Jain;[email-masked]
>>>>     On 1/28/13 7:09 PM, "Piyush Jain"<[email-masked]>  wrote:
>>>>
>>>>>     You said
>     [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jan 2013 10:43:12 +0100

Draft 12 is posted.

This update includes:
- The ASN.1 is consolidated and now contains just one 88 syntax section and
one 2002 syntax section. The OCSP module from 5912 has been imported and
updated.
- The ASN.1 update includes extension definitions for the no check extension
as well as the new extended revoke extension.
- A few minor editorial cleanups
- Added a note in the extended revoke extension section 4.4.8 to clarify
that clients do not have to process this extension in order to determine
status on certificates.

This document now only lacks the new OIDs for the new ASN.1 modules. As soon
as I have them, I will post draft 13.

I know that not everyone is super happy with the result, but on the other
hand, that seldom is the case with updates of this kind.

It is however my view that the document in it's current shape is a
reasonable capture of rough WG consensus, and that it now is ready for
shipping to the IESG.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jan 2013 10:53:59 +0100

Denis,

It would be easier if you read the messages on the list.
I answered the same very question on the list less than 24 hours ago.

Your contribution to this process is most welcome, but if you want to be
part of it, then please participate while the issue is discussed and not at
the very last minute months after the issue is decided and closed.

During the straw poll on this list on the way forward regarding this
extended revoked definition, this was discussed and agreed.
The issue was than discussed further at Atlanta and concluded in the
minutes.
http://www.ietf.org/proceedings/85/minutes/minutes-85-pkix

Just because you now raise the issue again, does not mean that the people
who participated while the issue was discussed has to rush to their
keyboards and defending their position.
In general, if you want to change the directions of things we already have
concluded, then you need to gather support for your arguments to change it.

We need to keep the process going.

/Stefan

Date:  Tuesday, January 29, 2013 10:33 AM

>  it is evident that this extension is needed, would be please recall shortly
> why ?
>  
>  Then we should also other people that are not on the same time zone to speak
> up.
>   
>  Denis
>  
>  
>  
>  
>>  
>> It was evident form the last PKIX meeting in Atlanta, and from the discussion
>> on the list that preceded that meeting, that having this extension was
>> necessary to reach WG consensus on expanding the "revoked" scope.
>>  
>> 
>>  
>>  
>> up are those wanting to change the decision and demonstrate why it need to be
>> removed.
>>  
>> 
>>  
>>  
>> /Stefan
>>  
>> 
>>  
>>   
>>> today another real use case where we would have that date.

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 29 Jan 2013 08:06:33 -0800

Just want to clarify.

While I agree with Denis that semantics of extended revoked extension are
equivalent to a revoked response with revocation date set to 1970, it is a
minor issue from my point of view.

My bigger concern is the assumption in Stefan's argument that clients do not
need to interpret the meaning of extended revoked except for
logging/auditing purpose. This assumption is not stated in the document
anywhere even though the document clearly states what extended revoked
response looks like and how it can be differentiated from a regular revoked
response.

Assuming that COMPLIANT client implementations will automatically treat
extended revoked as regular revoked is IMO short sighted. I know that this
will work for legacy clients, but is bound to cause confusion for future
implementations.

-Piyush

From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 12:53 AM
To: Stefan Santesson
Cc: Piyush Jain; [email-masked]
Subject: Re: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

Stefan,

Denis

Piyush,
 
On 1/28/13 10:09 PM, "Piyush Jain"  <mailto:[email-masked]>
<[email-masked]> wrote:

Stefan,
 
mandates that servers include extended revoked extension if it  is
changing

 
/Stefan

So far, besides you and me, Peter Rybar is the only one who has referred
to
this issue in one of his posts, acknowledging that it exists.
I hope we have opinions of a few others folks before we decide one way or
other.
 
-Piyush

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, January 28, 2013 12:25 PM
To: Piyush Jain; [email-masked]
Subject: Re: [pkix] Responder trust issue for non-issued certificates
not

On 1/28/13 7:09 PM, "Piyush Jain"  <mailto:[email-masked]>
<[email-masked]> wrote:

You said

"It's quite easy. If they trust the responder, they are supposed to
trust

the response.

If they have not established the trust described above, they MUST
reject

the response.

 

allows

issued.

and the

 

If you ask how to deal with the response, then the client will not
get a

trusted.

not-

issued.
 
No. The meaning is just to allow the server to provide a response that
has
the likely outcome that the client will not use that cert, if there even

is such a

Also the

No, the extension signals that the server supports this extended use of
revoked. It says nothing about whether it is used for any of the certs
in

a

particular response.

Finally, here is a point regarding providing guidance to clients.
Non-issued response is a new state that is being introduced in this
update.

This is getting tiresome. No, there is no new state. There is an
extended

use

of "revoked".

and

Which is exactly what we expect them to do. It is not the clients task
to

spot

place.

introduced

by a protocol.
 
/Stefan

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 29 Jan 2013 18:06:27 +0100

Stefan,

I agree with Piyush Jain about the unclear situations for RP with the "revoked" status for non-issued … (probably issued but the record is not in database or the key was compromised).

Especially it is unclear from the liability point of view.

What 2560bis draft 12 is trying to be solved with extension of "revoked" status? :

"if the associated CA has no record of ever having issued a certificate with
the certificate serial number in the request, using any current or..."

This situation is already covered in standard way as you can see later in my mail when "unauthorized" is returned.

Another problematic part is using the certificateHold in revocations.

The text in 4.4.8 Extended Revoked Definition contains “to allow audits to determine the type of operation by the responder”

As it was many times presented, the usage of the status certificateHold is forbidden in many systems because e.g. in mutual authentications when user SSL/TSL certificate is several times in certificateHold for some reason and then again valid you have not evidence in last CRL or in actual OCSP when in the past was access according to certificateHold of user SSL/TSL certificate forbidden for user. The usage of certificateHold is a killer for audits or validation systems.

You have not evidence why and when in the past some actions were or were not correct.

But can you imagine how you will validate e.g. signatures with signature timestamp when the usage of certificateHold is possible and certificate can be several times in certificateHold. When certificate is in certificateHold then such transaction in that time must not be valid! 

For that reason when transactions realized in the past are also important is some resent actions and not only as online actual then PKI must be able to provide evidence and for that reason certificateHold must not be used. 

http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-12

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 <http://tools.ietf.org/html/rfc5019#section-2.2.3>  2.2.3).

http://tools.ietf.org/html/rfc5019#section-2.2.3

 <http://tools.ietf.org/html/rfc5019#section-2.2.3> 2.2.3.  OCSPResponseStatus Values

   As long as the OCSP infrastructure has authoritative records for a
   particular certificate, an OCSPResponseStatus of "successful" will be
   returned.  When access to authoritative records for a particular
   certificate is not available, the responder MUST return an
   OCSPResponseStatus of "unauthorized".  As such, this profile extends
   the RFC 2560 <http://tools.ietf.org/html/rfc2560>  [OCSP <http://tools.ietf.org/html/rfc5019#ref-OCSP> ] definition of "unauthorized" as follows:
 
      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.
 
   For example, OCSP responders that do not have access to authoritative
   records for a requested certificate, such as those that generate and
   distribute OCSP responses in advance and thus do not have the ability
   to properly respond with a signed "successful" yet "unknown"
   response, will respond with an OCSPResponseStatus of "unauthorized".
   Also, in order to ensure the database of revocation information does
   not grow unbounded over time, the responder MAY remove the status
   records of expired certificates.  Requests from clients for
   certificates whose record has been removed will result in an
   OCSPResponseStatus of "unauthorized".
 
   Security considerations regarding the use of unsigned responses are
   discussed in [OCSP <http://tools.ietf.org/html/rfc5019#ref-OCSP> ].

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Tuesday, January 29, 2013 10:43 AM
To: [email-masked]
Subject: [pkix] 2560bis draft 12 posted

Draft 12 is posted.

This update includes:

- The ASN.1 is consolidated and now contains just one 88 syntax section and one 2002 syntax section. The OCSP module from 5912 has been imported and updated.

- The ASN.1 update includes extension definitions for the no check extension as well as the new extended revoke extension.

- Added a note in the extended revoke extension section 4.4.8 to clarify that clients do not have to process this extension in order to determine status on certificates.

This document now only lacks the new OIDs for the new ASN.1 modules. As soon as I have them, I will post draft 13.

I know that not everyone is super happy with the result, but on the other hand, that seldom is the case with updates of this kind.

It is however my view that the document in it's current shape is a reasonable capture of rough WG consensus, and that it now is ready for shipping to the IESG.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 29 Jan 2013 18:57:30 +0100

I agree that certificateHold should not be used. See explanations below.

However, I disagree with Peter on several points:

        The use of the "unauthorized" error is not the right approach.It 
is changing its semantics.

        It is perfectly possible to use the onhold state when validating 
electronic signature.
        If the certificate is onhold, then the global status for the 
validation of the electronic signature is "unknown".

But since an onhold state MUST NOT stay for ever, some software will 
trying again later on to see whether the certificate is valid or revoked.
Since the semantics of onhold was changed, these application will be 
locked for ever (i.e. will wait for ever unless their code is modified).
This means *this change is not backwards compatible with existing 
implementations*.

In the mean time, some countries do not allow to place a certificate 
onhold, which is also a problem.
This means *this change is not backwards compatible with existing 
legislations.**
*
This is why the use of the reason code notIssuedOrIrregularlyIssued (7) 
is a clean way to solve the problem.

Denis

> Stefan,
>
> I agree with Piyush Jain about the unclear situations for RP with the 
> "revoked" status for non-issued... (probably issued but the record is 
> not in database or the key was compromised).
>
> This situation is already covered in standard way as you can see later 
> in my mail when "unauthorized" is returned.
>
> The text in 4.4.8 Extended Revoked Definition contains "to allow*audits*  to determine the type of operation by the responder"
>
> As it was many times presented, the usage of the status 
> certificateHold is forbidden in many systems because e.g. in mutual 
> authentications when user SSL/TSL certificate is several times in 
> certificateHold for some reason and then again valid you have not 
> evidence in last CRL or in actual OCSP when in the past was access 
> according to certificateHold of user SSL/TSL certificate forbidden for 
> user. The usage of certificateHold is a killer for audits or 
> validation systems.
>
> But can you imagine how you will validate e.g. signatures with 
> signature timestamp when the usage of certificateHold is possible and 
> certificate can be several times in certificateHold. When certificate 
> is in certificateHold then such transaction in that time must not be 
> valid!
>
> For that reason when transactions realized in the past are also 
> important is some resent actions and not only as online actual then 
> PKI must be able to provide evidence and for that reason 
> certificateHold must not be used.
>
>     capable of responding authoritatively (cf.[RFC5019], Section 2.2.3  <http://tools.ietf.org/html/rfc5019#section-2.2.3>).
>
>         2.2.3 <http://tools.ietf.org/html/rfc5019#section-2.2.3>.
>         OCSPResponseStatus Values
>
>   
>   
>     certificate is not available,*the responder MUST return an*
> *    OCSPResponseStatus of "unauthorized".*   As such, this profile extends
>     theRFC 2560  <http://tools.ietf.org/html/rfc2560>  [OCSP  <http://tools.ietf.org/html/rfc5019#ref-OCSP>] definition of "unauthorized" as follows:
>   
>     discussed in [OCSP  <http://tools.ietf.org/html/rfc5019#ref-OCSP>].
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Stefan Santesson
> *Sent:* Tuesday, January 29, 2013 10:43 AM
> *To:* [email-masked]
> *Subject:* [pkix] 2560bis draft 12 posted
>
> Draft 12 is posted.
>
> This update includes:
>
> - The ASN.1 is consolidated and now contains just one 88 syntax 
> section and one 2002 syntax section. The OCSP module from 5912 has 
> been imported and updated.
>
> - The ASN.1 update includes extension definitions for the no check 
> extension as well as the new extended revoke extension.
>
> - Added a note in the extended revoke extension section 4.4.8 to 
> clarify that clients do not have to process this extension in order to 
> determine status on certificates.
>
> This document now only lacks the new OIDs for the new ASN.1 modules. 
> As soon as I have them, I will post draft 13.
>
> I know that not everyone is super happy with the result, but on the 
> other hand, that seldom is the case with updates of this kind.
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jan 2013 19:47:16 +0100

I added some text about this in 4.4.8 as a result of our discussion to make
it clear that clients do not have to parse this extension at all.

/Stefan

From:  Piyush Jain <[email-masked]>
Date:  Tuesday, January 29, 2013 5:06 PM
To:  'Denis Pinkas' <[email-masked]>, Stefan Santesson
<[email-masked]>
Cc:  <[email-masked]>
Subject:  RE: [pkix] Responder trust issue for non-issued certificates not
addressed in 2560 bis draft 11

> My bigger concern is the assumption in Stefan¹s argument that clients do not
> need to interpret the meaning of extended revoked except for logging/auditing
> purpose. This assumption is not stated in the document anywhere even though
> the document clearly states what extended revoked response looks like and how
> it can be differentiated from a regular revoked response.
>

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jan 2013 01:25:46 +0100 (CET)

> in my mail when "unauthorized" is returned.

That is a misunderstanding based on a defective document.

>    capable of responding authoritatively (cf. [RFC5019],
>    Section <http://tools.ietf.org/html/rfc5019#section-2.2.3>  2.2.3).

It's the first time that I see that idea.  IMO it is a pretty bad idea.
As you may note, rfc5019 does not claim to update rfc2560, and so
it does not do that.  The quoted re-interpretation is also in serious
conflict with the original definition/meanding of "unauthorized".

>From how the error codes are defined in rfc2560
  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

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

   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.

Unauthorized means that the client is not authorized to use the service,
and a reasonable client will use such a response to blacklist an
OCSP responder and *NEVER* ask it again for anything.

An OCSP server that uses "unauthorized" in the extended fashion of
rfc5019 or the way that you suggest, is FULLY BROKEN on my scorecard.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jan 2013 01:54:51 +0100 (CET)

> conflict with the original definition/meanding of "unauthorized".

Sorry for not having noticed this goof earlier.

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

This typically also means, that the OCSP responder probably did not
even look at the contents on the request at all, but decided only based
on the clients signature or the client's network address.

Ignoring "terms of service" of a Server that is accessed via the
internet, is a pretty bad idea, because in some jurisdication this
can currently be artificially inflated to be a felony.

While I agree that OCSP wasn't designed with a lot of thought about
extensibility (with respect to cert status an exceptions),
retroactively misappropiating an "unauthorized" response in the
fashion of 5019 looks like a very bad idea to me.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 29 Jan 2013 16:56:51 -0800

That is an interesting catch Peter.

So another implication of adopting revoked for non-issued is that it breaks compliance with 5019.

I’m wondering if it makes sense to list these implications in a different RFC, so CA responders can make an informed choice about adopting revoked for non-issued.

So far I have

-          Ambiguity in responder trust model for such responses

-          Inability to perform pre-signing.

-          Breaking compliance with 5019

-          Incompatibility with legislations that prohibit use of onHold

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Rybar
Sent: Tuesday, January 29, 2013 9:06 AM
To: 'Stefan Santesson'; [email-masked]
Subject: Re: [pkix] 2560bis draft 12 posted

Stefan,

 

 

 

  _____  

Draft 12 is posted.

This update includes:

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jan 2013 02:25:22 +0100 (CET)

Piyush Jain wrote:
> 
> I'm wondering if it makes sense to list these implications in a
> different RFC, so CA responders can make an informed choice about
> adopting revoked for non-issued.
> 
> So far I have
> 

That is a purely philosophical concept, not a technical one.

> -          Inability to perform pre-signing.

This is a clear misunderstanding.  You can still pre-sign responses for
all existing and revoked certs just like with rfc2560.

> -          Breaking compliance with 5019

with respect to the abuse of "unauthorized", 5019 itself is seriously broken.

> -          Incompatibility with legislations that prohibit use of onHold

That is complete and utter non-sense (as I've previously explained),
any such prohibition for "onHold" can not apply to not-issued cert serials.

However expecting OCSP clients to continue talking to an OCSP responder
that returned "unauthorized" will make you liable under the current
US CFAA crminial statute, that breakage of 5019 should be much more
of a concern for folks that are sensitive to legal issues.

-Martin

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 30 Jan 2013 13:35:07 +1100

[RFC 5019 "Lightweight OCSP Profile", section 2.2.3." OCSPResponseStatus Values"]

>> When access to authoritative records for a particular
>> ...

The 2560bis update doesn't clash with RFC5019 here.
A server with a list of all known-good cert serial numbers IS capable of responding authoritatively. It authoritatively knows there is no records for any "non-issued" serial number it is asked about -- there is no access that it lacks. So the RFC5019 use of "unauthorized" does not apply.

--
James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 30 Jan 2013 05:53:02 +0100

This one is not true,

It is obvious that no responder will pre sign revoked responses for all
possible non-issued certificates.

Does this prevent a responder from generating pre signed responses  No.
Does this means that a responder will never generate pre signed responses
for a non-issued cert serial number  No

I taked to Scott Rea about this. They have a global network for distributing
pre signed responses and they are constantly monitoring the requests. If
there would be a certain pattern of requests for a particular un-known cert
serial number, they could add that serial number to the pre-signed batches.
I assume that also would trigger an investigation about the cause of these
requests, but that's a completely different story.

/Stefan

From:  Piyush Jain <[email-masked]>
Date:  Wednesday, January 30, 2013 1:56 AM
To:  'Peter Rybar' <[email-masked]>, Stefan Santesson <[email-masked]>,
<[email-masked]>
Subject:  RE: [pkix] 2560bis draft 12 posted

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 29 Jan 2013 22:40:31 -0800

Inline

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 8:53 PM
To: Piyush Jain; 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] 2560bis draft 12 posted

This one is not true,

[Piyush] Only if you change the meaning of pre-signed J

[Piyush] true that.

Does this prevent a responder from generating pre signed responses - No.

Does this means that a responder will never generate pre signed responses
for a non-issued cert serial number - No

[Piyush] If you are familiar with pre-signing infrastructure, you would know
that in most cases, generating a live response is not an option. Pre-signed
responses are distributed to CDNs or keyless caching responder. So the
implication is that most of the time the responder will have to return
UNAUTHORIZED for non-issued serials.

Claiming that responders can do pre-signing for non-issued serials because
of presence for a few non-issued serials in the pre-signed cache is
misleading IMO. 

Unless you are changing your stance now and saying that non-issued serials
case is interesting only for a few certificates and it is okay for the
responder to return UNAUTHORIZED in most cases.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 29 Jan 2013 23:06:53 -0800

I think that authority of server becomes contextual in case of non-issued
serial numbers.

 Query for non-issued serials can only imply one of two things :
1) Client is in possession of the certificate for which server has no
issuance record (fraudulently issued)
2) Client is not in possession of the certificate (malicious or
non-compliant client)

If server assumes one, it ceases to be authoritative and should return
UNAUTHORIZED (according to 5019)
If it assumes 2, the content of response is immaterial and it should return
the response that minimizes its resource expenditure i.e. unsigned
UNAUTHORIZED.

You can always argue that one can remain authoritative even after being
compromised.

-Piyush

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Tuesday, January 29, 2013 6:35 PM
> To: [email-masked]
> >> When access to authoritative records for a particular certificate is
> >> not available, the responder MUST return an OCSPResponseStatus of
> >> "unauthorized".
> >> ...
> >> is not authorized to make this query to this server or the server  is
> >> not capable of responding authoritatively.
> 
> 
> A server with a list of all known-good cert serial numbers IS capable of
> responding authoritatively. It authoritatively knows there is no records
for
> any "non-issued" serial number it is asked about -- there is no access
that it
> lacks. So the RFC5019 use of "unauthorized" does not apply.
> 
> --
> James Manger

---

From: "Ryan Hurst" <[email-masked]>
Date: Tue, 29 Jan 2013 23:33:32 -0800

There are plenty of cumulative caching pre-producing OCSP responders out
there.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Piyush Jain
Sent: Tuesday, January 29, 2013 10:41 PM
To: 'Stefan Santesson'; 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] 2560bis draft 12 posted

Inline

This one is not true,

[Piyush] true that.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 30 Jan 2013 08:38:37 +0100

> UNAUTHORIZED for non-issued serials.

Yes, I'm very familiar with that.

And yes, they would respond "unauthorized" by default. That has not changed
either.
The new thing is that they could add a pre signed "revoked" response if they
monitor requests for a non-issued serial number asked in a certain manner or
pattern.

I'm not suggesting. I'm just telling you what a current CA on the market,
that is using CDNs for distribution of pre-signed responses are considering.
And YES, it is still perfectly legal and valid to return "unauthorized"
according to the non changed Light weight profile.
This is just another tool in the toolbox that does not create a perfect
world, but might make it marginally better.

Your approach to this subject seems like a perfect example of "perfect is
the enemy of good".
http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

/Stefan

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 30 Jan 2013 10:16:03 +0100

Stefan,

When RFC defines only possibility to provide “revoked” for “non-issued” without providing mechanism how the CA can recovery from the situation when RP have certificate signed by CA but CA have not evidence about issuance is an ostrich-like policy.

You have explained: 

When RP permanently disturbing CA with OCSP requests of certificate serial number which is not in CA electronic evidence then CA can use pre-signed response where this serial number will be revoked as certificateHold. 

In this way it is expected that RP clients will not anymore creating OCSP request for validation of some electronic evidence supported by such certificate.

It is ostrich-like policy and it has nothing solved and certificateHold causes that legacy client will repeatedly try to get a new status of actual certificateHold state.

Instead of such unclear revocation it will be more helpful to include in draft a new singleRequestExtensions extension: 

ext-ocsp-CertOfNoIssueRecordFound EXTENSION ::= { SYNTAX Certificate 

   IDENTIFIED BY id-pkix-ocsp-CertOfNoIssueRecordFound }

This singleRequestExtensions will be used by RP clients when “right” OCSP responder will return "unknown" state or unauthorized error message.

According to it OCSP responder will be able to analyze received certificate and together with CA create analysis and making decisions how it can be solved.

Peter Rybar

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2013 8:39 AM
To: Piyush Jain; 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] 2560bis draft 12 posted

[Piyush] If you are familiar with pre-signing infrastructure, you would know that in most cases, generating a live response is not an option. Pre-signed responses are distributed to CDNs or keyless caching responder. So the implication is that most of the time the responder will have to return UNAUTHORIZED for non-issued serials.

And yes, they would respond "unauthorized" by default. That has not changed either.

The new thing is that they could add a pre signed "revoked" response if they monitor requests for a non-issued serial number asked in a certain manner or pattern.

I'm not suggesting. I'm just telling you what a current CA on the market, that is using CDNs for distribution of pre-signed responses are considering.

And YES, it is still perfectly legal and valid to return "unauthorized" according to the non changed Light weight profile.

This is just another tool in the toolbox that does not create a perfect world, but might make it marginally better.

Your approach to this subject seems like a perfect example of "perfect is the enemy of good".

/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jan 2013 10:21:42 -0500

Martin,

...
> of a concern for folks that are sensitive to legal issues.
Might I ask from which law school you received your JD?

Steve

---

From: Simon Tardell <[email-masked]>
Date: Wed, 30 Jan 2013 16:51:07 +0100

> trying again later on to see whether the certificate is valid or revoked.

But this is wrong. It is quite clear that if a certificate is revoked with
whatever reason code, the certificate is not valid for use at that point in
time. Nothing more, nothing less. That use (at a time of invalidity) does
not become valid if the certificate is unsuspended later. The certificate
will be valid for new uses after the time of unsuspension, but you do not
need, and should not, recheck the revocation status. There is of course a
problem that there could be a time lag between the use of the certificate
and the revocation checking during which it could be unsuspended, but this
problem is no different from the time lag at the other end of the
revocation period (i.e. that you could be looking at revocation data that
represents a time period somewhat before the time you are interested in).
As always, the cure is to minimize these windows and balance the cost for
doing so against the risk and size of any potential damage.

> implementations*.

The semantics aren't changed. These applications are buggy. You have to be
a lot more specific for this to be worthy of consideration, I'd say.

> legislations.*

The French legislation you quoted earlier is clearly not a problem here, as
I pointed out before (Nov 8 & 9). What other regulations do you have in
mind? To be able to asses this we need to look at the letter of the law. In
my recollection, the German law is not worded in such a way to prevent this
either (indeed, I believe that text we are writing makes a good foundation
for solving some of the requirements the German law does have).

/Simon

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jan 2013 18:23:52 +0100 (CET)

> Might I ask from which law school you received your JD?

What is relevant here is the opionion and actions of US federal
prosecutors, e.g. US Attourneys Steve Heymann and Carmen Ortiz,
who seriously believe that a terms-of-use violation is a
felony crime under the CFAA.

They exercised there state-assigned powers and tortured Aaron Swartz
with plea-boarding and threatened him to the point that he commited suicide.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jan 2013 13:33:34 -0500

Martin,
> felony crime under the CFAA.
What is relevant is that you are not an attorney and have no
basis for admonishing this list re the legal implications of OCSP
processing.

We're developing voluntary, not de jure, standards.

Steve

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jan 2013 20:10:26 +0100 (CET)

> basis for admonishing this list re the legal implications of OCSP

This is BS.

Here in Germany, and maybe in a few other decent democracies,
there are quite strict requirements for criminal statutes.
That requirement is, that it MUST be obvious to the average human
being that an action is a criminal offense.  In Germany, if the
criminal statute is not sufficiently clear, then it may not be
used for that purpose, because any such use would be unconstitutional
and therefore null and void.  Our constitutional court has been
pretty clear about this everytime that it was asked.  And the
European Court of Human Right (ECHR) has been at least as strict
(if not stricter) in applying that dogma.

So "are you an attourney" is somewhat of a clueless question.

> We're developing voluntary, not de jure, standards.

But the behaviour and the semantics that we specify in our standards,
and the behaviour exhibited by implementations of our standards,
will have de jure implications in the real world.

When rfc2560 was published, the semantics of the Exception Case
"unauthorized" was published as:

And it would be technically entirely inappropriate to completely withdraw
that response code and re-issue it with a completely different meaning
after almost 14 years.

A semantic of the kind "this server is unable to obtain authoritative
information about the status of this cert serial", has exactly nothing
in common with the original meaning of "unauthorized" from rfc2560.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 30 Jan 2013 11:29:47 -0800

Let me see if I understood it right.

What you are implying is that a responder who has indicated that it returns
revoked for non-issued can legally return either UNAUTHORIZED or revoked for
a non-issued certificate.

In fact all CA responders will need to do this if they pre-sign responses.

I don't argue with this. However, that incremental benefit to a small
community of responders is coming at a cost to other compliant clients and
future implementations, just because the main document is being changed all
over the place. The changes are not trivial because they deviate from two
basic design assumptions of original OCSP (and those of other pkix
documents) 

1)      Signed by CA and Issued by CA are synonymous. This is not true after
this update. The sad thing is that in many places even this updated document
uses 'signed' and 'issued' interchangeably.

2)      Certificate status can be either good or revoked. Not true anymore.
This is particularly interesting. In discussion over last few months, there
have been arguments about non-issued being a different status and then
follow-up arguments that clients should treat non-issued as revoked to
establish trust in the response even though the clients have a clear way of
differentiating between revoked and non-issued state.

If you think about it, the only thing that was needed in the toolbox was to
allow revoked for any negative proof. It could've been achieved without
getting into the debate of issued/non-issued.

"The "revoked" state indicates that the certificate has been revoked(either
permanantly or temporarily (on hold)). It may also indicate that the
responder has determined that the certificate is untrustworthy due to some
other reason". How the responder makes that determination is beyond the
scope of this document"
 
The above text leaves the implementations accountable for their choice,
which arguably is a short term patch for addressing fraudulently issued
certificate. 
 
I agree perfectionism is impractical. But you still need to understand what
perfectionism is, to make an informed choice of deviating from it. Twisting
its definition does not help.
Open standards, IMO should strive to be perfect and should not introduce any
vulnerability just to satisfy the needs of non-compliant implementations.
The problem that you are trying to solve here won't have existed if the
client implementations had complied with original 2560 and 5280.
OPERA browser is one example which has evolved to a state where it correctly
rejects a certificate if it cannot determine the status of a certificate.
Other clients will have no motivation to change when this new guidance is
published, and will remain vulnerable to simple attack where an attacker
breaks the communication between the client and the responder.

 

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 11:39 PM
To: Piyush Jain; 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] 2560bis draft 12 posted

/Stefan