Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Nov 2012 14:10:49 +0100

In-line;

On 11/1/12 12:12 AM, "Piyush Jain" <[email-masked]> wrote:

>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Stefan Santesson
>> Sent: Wednesday, October 31, 2012 11:47 AM
>> To: [email-masked]
>> Subject: [pkix] Proposed resolution to non-issued certificates - 2560bis
>> 
>> I didn't put up an end date for the straw-poll, but the trend seems
>>clear.
>> 
>> The results so far (if I counted right)
>> 
>> Supporting #1: 22
>> Supporting #2: 0
>> Supporting #3 using "unknown": 6
>> Supporting #3 using "unauthorised: 2
>> 
>> 6 persons supporting #1 has expressed various levels of support/demand
>>for
>> an explicit declaration that the OCSP responder supports the enhanced
>> definition of "revoked" to include "no issued".
>> 
>> 1 person responded off-line supporting #1.
>> 
>> 
>> If the trend reflects the opinion of the WG. This is my proposed
>> resolution:
>> 
>> 
>> 1) Extend the "revoked" response to also be allowed for non-issued
>> certificates. Clearly stating that this is optional if and only if the
>OCSP
>> responder knows that the requested serial number has never been issued.
>[Piyush] This requires changing the current text for 'good'. Pasted for
>your
>reference
>
>The "good" state indicates a positive response to the status inquiry.
>   At a minimum, this positive response indicates that the certificate
>   is not revoked, but does not necessarily mean that the certificate
>   was ever issued or that the time at which the response was produced
>   is within the certificate's validity interval. Response extensions
>   may be used to convey additional information on assertions made by
>   the responder regarding the status of the certificate such as
>   positive statement about issuance, validity, etc.

This is still true.

>
>> 2) Specify that a "revoked" status for a non-issued certificate serial
>number
>> MUST have revocationTime set to Jan 1, 1970 and MUST set the
>> revocationReason to certificateHold (6).
>[Piyush] There were some objections on using certificateHold as
>revocationReason for this purpose. CA compromise would be more appropriate
>because the only scenario where this is beneficial is when the CA is
>compromised.

Absolutely not. The CA is not compromised just because I ask for a serial
number that was never issued.

>
>> 2) Define a new optional non-critical extension declaring that OCSP
>> responder returns "revoked" for non-issued certificates according to the
>> updated standard. This extension MUST be present in all responses where
>> the "revoked" response is returned as a result of a status request for a
>non-
>> issued certificate.
>[Piyush] Are you proposing that the specification of this extension would
>be
>part of OCSP or it would be published as a separate specification?
>I think that it should not be part of main OCSP specification, given that
>it
>is useful only in the exceptional scenario where CA gets compromised.

Proposing to include it in the base standard. It can also be used to
measure whether an OCSP responder adopts this response behaviour even if
the CA is not compromised.

>> 
>> 
>> Rationale:
>> The certificateHold reason feels important for one particular reason.
>>If a
>CA is
>> issuing certificates with sequential serial numbers, then it could be
>possible
>> to obtain a revoked response for a certificate serial number that is not
>yet
>> issued, but soon will be issued. That the certificate serial number is
>currently
>> not issued, does not mean that it never will, thus the certificateHold
>reason
>> seems more appropriate.
>> 
>[Piyush] Given that a fraudulent certificate has been issued with a serial
>number, the CA would eventually revoke the certificate with this serial
>number and would not issue any newer certificate with the same serial.
>I think the confusion arises from the fact that we've been using
>'not-issued' and 'fraudulently-issued' interchangeably. All this time I'd
>been thinking that we are discussing the latter. If that is indeed the
>case,
>caCompromise seems more appropriate.

No, for reason above.

>
>> The date 1 Jan, 1970 is appropriate since it is common in programming
>> languages to express time as milliseconds since jan 1, 1970. Selecting
>this
>> time avoids time expression as a negative integer.
>> 
>> This date translates to (java):
>> Date revocationTime = new Date(0);  //Jan 1st, 1970
>> 
>> The extension would be a simple OID with no data structure and MUST not
>> be set to critical.
>> 
>> 
>> Question:
>> Would it make sense to require an OCSP responder that adopts the
>> expanded use of "revoked" to always include the new extension?
>> It would add the benefit that someone receiving "good" can know that the
>> OCSP responder has checked that the certificate in fact has been issued
>>by
>> the CA.
>> In such case it may be reasonable to add an optional data structure
>>which
>> MAY contain a hash of the cert.
>> Such hash would make the positive confirmation even stronger, adding
>>proof
>> of existence of the certificate.
>[Piyush] I hope that you realize that big enterprise PKI deployments use
>OCSP and CRLs interchangeably. And with this proposal OCSP becomes more
>authoritative than CRL.
>So I guess the next step would be to change the basic path validation
>algorithm to drop the use of CRLs in favor of OCSP and also drop the
>signature verification (off course if the RP knows that his OCSP responder
>issues stronger positive confirmations).

It is not part of this work to update CRL processing or path validation.

>> 
>> But perhaps this will bee too much to agree on :)
>> 
>[Piyush] How about a thinner profile of SCVP that could address everything
>you are trying to achieve in OCSP.

It is neither part of this work to update SCVP. Just to update OCSP.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 1 Nov 2012 08:23:02 -0700

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 6:11 AM
> To: Piyush Jain; [email-masked]
> Subject: Re: [pkix] Proposed resolution to non-issued certificates -
2560bis
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Stefan Santesson
> >> 6 persons supporting #1 has expressed various levels of
> >>support/demand for  an explicit declaration that the OCSP responder
> >>supports the enhanced  definition of "revoked" to include "no issued".
> >>
> >your reference
[Piyush]It is tree in theoretical sense, but incomplete and confusing. The
meaning of 'good' changes, if the responder returns revoked for
'fraudulently-issued' certificates.
 In such cases, a positive proof implies that the certificate was issued.
Also, the last sentence in the above paragraph does not apply for such
responders.
> >revocationReason for this purpose. CA compromise would be more
> >appropriate because the only scenario where this is beneficial is when
> >the CA is compromised.
> 

[Piyush] All this time, the reason to propose this change has been that it
helps the situation where certificates are fraudulently issued. If the RP is
not doing signature checking than this discussion is moot. If RP has
verified that signature is correct and CA thinks it is not issued, it is
caCompromise.
CA may be compromised or not. But this response is telling the RP that if he
thinks that certificate is signed by the CA, then it implies that CA is
compromised.
> >> responder returns "revoked" for non-issued certificates according to
> >> the updated standard. This extension MUST be present in all responses
> >> where the "revoked" response is returned as a result of a status
> >> request for a
> >non-
> >> issued certificate.
> >[Piyush] Are you proposing that the specification of this extension
> >would be part of OCSP or it would be published as a separate
> >specification?
> >I think that it should not be part of main OCSP specification, given
> >that it is useful only in the exceptional scenario where CA gets
> >compromised.
> 
measure
> whether an OCSP responder adopts this response behaviour even if the CA is
> not compromised.
> 
[Piyush] This is something new. So what are the benefits of this if the CA
is not compromised? What value does it add over signature checking?
And I thought that in one of you previous emails you said that there was a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. Don't know if that is still the case.
> >[Piyush] Given that a fraudulent certificate has been issued with a
> >serial number, the CA would eventually revoke the certificate with this
> >serial number and would not issue any newer certificate with the same
> serial.
> >'not-issued' and 'fraudulently-issued' interchangeably. All this time
> >I'd been thinking that we are discussing the latter. If that is indeed
> >the case, caCompromise seems more appropriate.
> 
> No, for reason above.
> 
> >
> >> The extension would be a simple OID with no data structure and MUST
> >> not be set to critical.
> >>
> >>
> >> Question:
> >> It would add the benefit that someone receiving "good" can know that
> >>the  OCSP responder has checked that the certificate in fact has been
> >>issued by  the CA.
> >>which  MAY contain a hash of the cert.
> >>proof  of existence of the certificate.
> >[Piyush] I hope that you realize that big enterprise PKI deployments
> >use OCSP and CRLs interchangeably. And with this proposal OCSP becomes
> >more authoritative than CRL.
> >signature verification (off course if the RP knows that his OCSP
> >responder issues stronger positive confirmations).
> 
[Piyush] Are you saying that there is no need to evaluate how this work
affects other standards created by pkix.
> >[Piyush] How about a thinner profile of SCVP that could address
> >everything you are trying to achieve in OCSP.
> 
[Piyush] SCVP does not need to be updated. It already has provisions for
what you are trying to duplicate in OCSP.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Nov 2012 16:39:55 +0100

As a short reply.

No, the good response is still true from a very practical perspective.
It is exactly as written.

Secondly,
Even if the major reason for allowing revoked for non-ussued certs is to
detect/react to compromised CA situations, this does NOT mean that any
request for a non-issued cert is caused by a compromised CA.

It can simply be caused by a bug in the requesting client or a deliberate
false request.
It's therefore wrong to reply that the CA is compromised, unless you know
that the CA is compromised.

/Stefan

On 11/1/12 4:23 PM, "Piyush Jain" <[email-masked]> wrote:

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

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 1 Nov 2012 09:37:19 -0700

> Sent: Thursday, November 01, 2012 8:40 AM
2560bis
> It is exactly as written.
[Piyush] I'm sure you have your reasons. But the obvious question that comes
to my mind is that if a responder returns revoked for non-issued, than why
can't good be considered a proof of issuance. The current text fails to
capture this.
> detect/react to compromised CA situations, 
[Piyush] That is the reason that has been cited. The way I see it is to
allow CAs to continue operations even after the compromise. I have not seen
a single discussion on how CA would react if starts getting such requests.
It does give the CAs the tool to advertise the security of their systems to
unsuspecting customers who do not understand the OCSP trust model.

>this does NOT mean that any

[Piyush]Nor does it mean that certificate was issued and put on hold, which
is what certifcateOnHold implies.

> It can simply be caused by a bug in the requesting client or a deliberate
false
> request.
[Piyush] In either of these cases, what the responder returns has no value.
The best response in such cases is to return transport level error (HTTP
422). 
I hope that the expectation here is not that this response will help RPs to
recover from software bugs or that it will teach malicious clients to play
nice.

> that the CA is compromised.
[Piyush] Only scenario that matters is the one in which CA is compromised.
In every other scenario the content of the response is irrelevant.
> >> >> From: [email-masked] [mailto:[email-masked]] On
> >> >> Behalf Of Stefan Santesson
> >> >> I didn't put up an end date for the straw-poll, but the trend
> >> >>seems clear.
> >> >>
> >> >[Piyush] This requires changing the current text for 'good'. Pasted
> >> >for your reference
> >> >
> >[Piyush]It is tree in theoretical sense, but incomplete and confusing.
> >The meaning of 'good' changes, if the responder returns revoked for
> >> >appropriate because the only scenario where this is beneficial is
> >> >when the CA is compromised.
> >>
> >> Absolutely not. The CA is not compromised just because I ask for a
> >>serial  number that was never issued.
> >
> >[Piyush] All this time, the reason to propose this change has been that
> >it helps the situation where certificates are fraudulently issued. If
> >the RP is not doing signature checking than this discussion is moot. If
> >RP has verified that signature is correct and CA thinks it is not
> >issued, it is caCompromise.
> >CA may be compromised or not. But this response is telling the RP that
> >if he thinks that certificate is signed by the CA, then it implies that
> >CA is compromised.
> >>
> >>
> >> >
> >> >> 2) Define a new optional non-critical extension declaring that
> >> >> OCSP responder returns "revoked" for non-issued certificates
> >> >> according to the updated standard. This extension MUST be present
> >> >> in all responses where the "revoked" response is returned as a
> >> >> result of a status request for a
> >> >non-
> >> >> issued certificate.
> >> whether an OCSP responder adopts this response behaviour even if the
> >>CA is  not compromised.
> >>
> >[Piyush] This is something new. So what are the benefits of this if the
> >CA is not compromised? What value does it add over signature checking?
> >And I thought that in one of you previous emails you said that there
> >was a WG decision to limit changes to RFC 2560 to what is necessary to
> >resolve previous ambiguity. Don't know if that is still the case.
> >>
> >> >>
> >> >>
> >> >> Rationale:
> >> >serial number, the CA would eventually revoke the certificate with
> >> >this serial number and would not issue any newer certificate with
> >> >the same
> >> serial.
> >> >'not-issued' and 'fraudulently-issued' interchangeably. All this
> >> >time I'd been thinking that we are discussing the latter. If that is
> >> >indeed the case, caCompromise seems more appropriate.
> >>
> >> No, for reason above.
> >>
> >> >
> >> >> The date 1 Jan, 1970 is appropriate since it is common in
> >> >> programming languages to express time as milliseconds since jan 1,
> 1970.
> >> >> Selecting
> >> >this
> >> >> The extension would be a simple OID with no data structure and
> >> >> MUST not be set to critical.
> >> >>
> >> >>
> >> >> Question:
> >> >> It would add the benefit that someone receiving "good" can know
> >> >>that the  OCSP responder has checked that the certificate in fact
> >> >>has been issued by  the CA.
> >> >> In such case it may be reasonable to add an optional data
> >> >>structure which  MAY contain a hash of the cert.
> >> >> Such hash would make the positive confirmation even stronger,
> >> >>adding proof  of existence of the certificate.
> >> >use OCSP and CRLs interchangeably. And with this proposal OCSP
> >> >becomes more authoritative than CRL.
> >> >So I guess the next step would be to change the basic path
> >> >validation algorithm to drop the use of CRLs in favor of OCSP and
> >> >also drop the signature verification (off course if the RP knows
> >> >that his OCSP responder issues stronger positive confirmations).
> >>
> >[Piyush] SCVP does not need to be updated. It already has provisions
> >for what you are trying to duplicate in OCSP.
> >>
> >> /Stefan
> >>
> >
> >

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Nov 2012 20:37:47 +0100

To clear a few things up.

The current draft does not reflect the straw-poll. It will be updated to
capture that which is/will be agreed.

CA compromise is a worse choice since it could be interpreted that no
certs from that CA can be trusted.
certificateHold only affects that serialNumber and only temporary, thus it
is more suitable from a practical standpoint.

Yes, combined with the optional extension, "good" will be a positive
statement of the existence of the cert. This is perfectly compliant with
the current "good" text saying "Response extensions may be used to convey
additional information on assertions made by the responder regarding the
status of the certificate such as positive statement about issuance,
validity, etc"

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 1 Nov 2012 15:12:59 -0700

So far we've outlined 3 scenarios in which this response makes sense
1) Buggy Client
2) Malicious client
3) CA compromise

For 1 and 2, the content of the response does not matter.
That leaves us with 3 in which case caCompromise is right choice. And your
conclusion is right. Once the CA is compromised, no certificates issued by
that CA could be trusted.

BTW, I hope that there will be guidance in the updated draft on what to
include in CRL References extension in such cases.
It might suffice to say that the responder MUST not include the CRL
References extension if it is issuing revoked for fraudulently-issued
certificates.

-Piyush

> Sent: Thursday, November 01, 2012 12:38 PM
2560bis
> CA compromise is a worse choice since it could be interpreted that no
certs
> from that CA can be trusted.

> certificateHold only affects that serialNumber and only temporary, thus it
is
> more suitable from a practical standpoint.

> statement of the existence of the cert. This is perfectly compliant with
the
> current "good" text saying "Response extensions may be used to convey
validity,
> etc"
> >[Piyush] I'm sure you have your reasons. But the obvious question that
> >comes to my mind is that if a responder returns revoked for non-issued,
> >than why can't good be considered a proof of issuance. The current text
> >fails to capture this.
> >>
> >> Secondly,
> >> Even if the major reason for allowing revoked for non-ussued certs is
> >> to detect/react to compromised CA situations,
> >allow CAs to continue operations even after the compromise. I have not
> >seen a single discussion on how CA would react if starts getting such
> >requests.
> >It does give the CAs the tool to advertise the security of their
> >systems to unsuspecting customers who do not understand the OCSP trust
> >model.
> >
> >[Piyush]Nor does it mean that certificate was issued and put on hold,
> >which is what certifcateOnHold implies.
> >
> >>
> >The best response in such cases is to return transport level error
> >(HTTP 422).
> >I hope that the expectation here is not that this response will help
> >RPs to recover from software bugs or that it will teach malicious
> >clients to play nice.
> >
> >> It's therefore wrong to reply that the CA is compromised, unless you
> >>know  that the CA is compromised.
> >> >> >> Supporting #3 using "unknown": 6 Supporting #3 using
> >> >> >> "unauthorised: 2
> >> >> >>
> >> >> >>support/demand for  an explicit declaration that the OCSP
> >> >> >>responder supports the enhanced  definition of "revoked" to
> >> >> >>include "no
> >issued".
> >> >> >>
> >> >> >> 1) Extend the "revoked" response to also be allowed for
> >> >> >> non-issued certificates. Clearly stating that this is optional
> >> >> >> if and only if the
> >> >> >OCSP
> >> >> >[Piyush] This requires changing the current text for 'good'.
> >> >> >Pasted for your reference
> >> >> >
> >> >> >   may be used to convey additional information on assertions
> >> >> > made
> >>by
> >> >Also, the last sentence in the above paragraph does not apply for
> >> >such responders.
> >> >>
> >> >> >
> >> >[Piyush] All this time, the reason to propose this change has been
> >> >that it helps the situation where certificates are fraudulently
> >> >issued. If the RP is not doing signature checking than this
> >> >discussion is moot. If RP has verified that signature is correct and
> >> >CA thinks it is not issued, it is caCompromise.
> >> >CA may be compromised or not. But this response is telling the RP
> >> >that if he thinks that certificate is signed by the CA, then it
> >> >implies that CA is compromised.
> >> >>
> >> >>
> >> >> >
> >> >> >> according to the updated standard. This extension MUST be
> >> >> >> present in all responses where the "revoked" response is
> >> >> >> returned as a result of a status request for a
> >> >> >non-
> >> >> >> issued certificate.
> >> >> >[Piyush] Are you proposing that the specification of this
> >> >> >extension would be part of OCSP or it would be published as a
> >> >> >separate specification?
> >> >> >I think that it should not be part of main OCSP specification,
> >> >> >given that it is useful only in the exceptional scenario where CA
> >> >> >gets compromised.
> >> >>
> >> >> whether an OCSP responder adopts this response behaviour even if
> >> >[Piyush] This is something new. So what are the benefits of this if
> >> >the CA is not compromised? What value does it add over signature
> checking?
> >> >was a WG decision to limit changes to RFC 2560 to what is necessary
> >> >to resolve previous ambiguity. Don't know if that is still the case.
> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Rationale:
> >> >> >[Piyush] Given that a fraudulent certificate has been issued with
> >> >> >a serial number, the CA would eventually revoke the certificate
> >> >> >with this serial number and would not issue any newer certificate
> >> >> >with the same
> >> >> serial.
> >> >> >time I'd been thinking that we are discussing the latter. If that
> >> >> >is indeed the case, caCompromise seems more appropriate.
> >> >>
> >> >> No, for reason above.
> >> >>
> >> >> >
> >> >> >> Would it make sense to require an OCSP responder that adopts
> >> >> >>the expanded use of "revoked" to always include the new
> extension?
> >> >> >>that the  OCSP responder has checked that the certificate in
> >> >> >>fact has been issued by  the CA.
> >> >> >[Piyush] I hope that you realize that big enterprise PKI
> >> >> >deployments use OCSP and CRLs interchangeably. And with this
> >> >> >proposal OCSP becomes more authoritative than CRL.
> >> >[Piyush] Are you saying that there is no need to evaluate how this
> >> >work affects other standards created by pkix.
> >> >>
> >> >> >>

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 2 Nov 2012 11:16:33 +0100

Stefan,

I agree with David A. Cooper and Piyush.

And also retroactive revocation is not allowed in X.509.

The certificate status "revoked" in OCSP must be consistent with the status in CRL.

In this case it is not consistent because status "revoked" is proposed to be in OCSP but in the same time it is not included in CRL.

Validation will be different by CRL/OCSP!

Don't forget that also thisUpdate MUST be correctly used and included in OCSP response.

   - thisUpdate: The time at which the status being indicated is known to be correct.

It mans any new "correct" revocation MUST be with revocation value which is greater than value thisUpdate of any issued CRL/OCSP.

Including revocation date/time before value thisUpdate (of any already issued CRL/OCSP) is destruction of X.509 fundamental rules for validations.

Date and time of revocation MUST be only after value thisUpdate which is included in last issued CRL or OCSP.

[David A. Cooper]

 In your message yesterday you raised the issue of OCSP responders that have access to a database of issued certificates that are currently valid, but not of the certificates that were issued but that have now expired.

 As I explained before (http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html), I believe that would be a non-backward compatible change.

 Once the CA is compromised, no certificates issued by that CA could be trusted.

Peter Rybar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Piyush Jain
Sent: Thursday, November 01, 2012 11:13 PM
To: 'Stefan Santesson'; [email-masked]
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

1) Buggy Client

2) Malicious client

3) CA compromise

certificates.

-Piyush

2560bis

certs

 

is

 

the

validity,

> >> It can simply be caused by a bug in the requesting client or a

> >>deliberate

> >[Piyush] In either of these cases, what the responder returns has no

> >value.

> >[Piyush] Only scenario that matters is the one in which CA is

compromised.

> >> >> Subject: Re: [pkix] Proposed resolution to non-issued certificates

> >> >> -

> >> >> >> Subject: [pkix] Proposed resolution to non-issued certificates

> >> >> >> - 2560bis

> >> >> >> If the trend reflects the opinion of the WG. This is my

> >> >> >> proposed

> >> >> >> responder knows that the requested serial number has never been

> >> >> issued.

> >> >> >The "good" state indicates a positive response to the status

> >>inquiry.

> >> >> >   At a minimum, this positive response indicates that the

> >>certificate

> >> >> >   is not revoked, but does not necessarily mean that the

> >>certificate

> >> >> >   was ever issued or that the time at which the response was

> >>produced

> >> >> >   is within the certificate's validity interval. Response

> >>extensions

> >> > In such cases, a positive proof implies that the certificate was

> >>issued.

> >> >> >> 2) Specify that a "revoked" status for a non-issued certificate

> >> >> >> serial

> >> >> Proposing to include it in the base standard. It can also be used

> >> >> to

> >> >> >> The certificateHold reason feels important for one particular

> >reason.

> >> >> >> issuing certificates with sequential serial numbers, then it

> >> >> >> could be

> >> >> >> to obtain a revoked response for a certificate serial number

> >> >> >> that is not

> >> >> >> issued, but soon will be issued. That the certificate serial

> >> >> >> number is

> >> >> >> not issued, does not mean that it never will, thus the

> >> >> >> certificateHold

> >> >> >> programming languages to express time as milliseconds since jan

> >> >> >> 1,

> >> >> It is not part of this work to update CRL processing or path

> >validation.

 

pkix mailing list

[email-masked]

---

From: Simon Tardell <[email-masked]>
Date: Fri, 2 Nov 2012 13:08:15 +0100

On Fri, Nov 2, 2012 at 11:16 AM, Peter Rybar <[email-masked]> wrote:

> ** **
>
> Stefan,****
>
> ** **
>
> I agree with David A. Cooper and Piyush.****
>
> ** **
>
> And also retroactive revocation is not allowed in X.509.****
>
> The certificate status "revoked" in OCSP must be consistent with the
> status in CRL.****
>
> In this case it is not consistent because status "revoked" is proposed to
> be in OCSP but in the same time it is not included in CRL.****
>
So a CA that does answer revoked for never issued MUST NOT use CRLs.

> **
>
> Don't forget that also thisUpdate MUST be correctly used and included in
> OCSP response.****
>
> ** **
>
>    - thisUpdate: The time at which the status being indicated is known to
> be correct.****
>
> ** **
>
> It mans any new "correct" revocation MUST be with revocation value which
> is greater than value thisUpdate of any issued CRL/OCSP.
>
Including revocation date/time before value thisUpdate (of any already
> issued CRL/OCSP) is destruction of X.509 fundamental rules for validations.
> ****
>
> Date and time of revocation MUST be only after value thisUpdate which is
> included in last issued CRL or OCSP.****
>
> **
>

I don't quite understand. The revocationTime of a RevokedInfo must
logically be earlier than the thisUpdate of the response, unless we assume
that we are dealing with a precog OCSP responder. The OCSP responder should
try to keep the thisUpdate as close to "now" as it can, to limit the window
where compromised keys can be used.

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Nov 2012 16:14:15 +0100

>that CA could be trusted.

Right, so no external person should be able to cause the OCSP responder to
claim that the CA is compromised, unless the CA is compromised.

>References extension if it is issuing revoked for fraudulently-issued

No, that would be outside of the scope of the OCSP standard. This standard
describes the OCSP protocol. It can't pose requirements on use of other
services.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Nov 2012 16:19:31 +0100

Agree with Simon,

Except on the CRL issue. It is not up to the OCSP standard to limit the use
of other services for revocation status checking.
Just because security of OCSP has been enhanced slightly, does not
necessarily mean that clients must stop using CRL:s.

/Stefan

From:  Simon Tardell <[email-masked]>
Date:  Friday, November 2, 2012 1:08 PM
To:  Peter Rybar <[email-masked]>
Cc:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] Proposed resolution to non-issued certificates -
2560bis

>> In this case it is not consistent because status "revoked" is proposed to be
>> in OCSP but in the same time it is not included in CRL.
>> 
>> It mans any new "correct" revocation MUST be with revocation value which is
>> greater than value thisUpdate of any issued CRL/OCSP.
>> 
>> Including revocation date/time before value thisUpdate (of any already issued
>> CRL/OCSP) is destruction of X.509 fundamental rules for validations.
>> 
>> included in last issued CRL or OCSP.
>> 
> 
> I don't quite understand. The revocationTime of a RevokedInfo must logically
> be earlier than the thisUpdate of the response, unless we assume that we are
> dealing with a precog OCSP responder. The OCSP responder should try to keep
> the thisUpdate as close to "now" as it can, to limit the window where
> compromised keys can be used.
>  
> /Simon

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 2 Nov 2012 11:39:35 -0400

The CRL references extension is defined in Section 4.4.2 of RFC 2560 as 
an extension that may be included in the singleExtensions field of an 
OCSP response.  So, what is it about Piyush's request that is outside of 
the scope of the OCSP standard?

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 2 Nov 2012 08:40:17 -0700

Couple of points Stefan

1) The responder is not broadcasting this to the whole world. Only to the
external person who is sending such a request. None of the pkix standards
say that if a revocation provider cites caCompromise as reason for
revocation for an issued certificated, all the certificates issued by that
CA should be considered revoked. On a side note, it might not be a bad thing
if the RP can authoritatively determine if the CA was compromised. However,
it does not apply in this case because it seems that any talk of responder
trust is taboo in the scope of this discussion.

2) CRL References is a single response extension which is part of OCSP. I
can't imagine how this proposed change affects an extension define within
OCSP can be out of scope.

> Sent: Friday, November 02, 2012 8:14 AM
2560bis
> >That leaves us with 3 in which case caCompromise is right choice. And
> >your conclusion is right. Once the CA is compromised, no certificates
> >issued by that CA could be trusted.
> 
> >> The current draft does not reflect the straw-poll. It will be updated
> >> to capture that which is/will be agreed.
> >>
> >> additional information on assertions made by the responder regarding
> >> the status of the certificate such as positive statement about
> >> issuance,
> >validity,
> >> etc"
> >>
> >> /Stefan
> >>
> >>
> >>
> >> >[Piyush] I'm sure you have your reasons. But the obvious question
> >> >that comes to my mind is that if a responder returns revoked for
> >> >non-issued, than why can't good be considered a proof of issuance.
> >> >The current text fails to capture this.
> >> >>
> >> >> Secondly,
> >> >> Even if the major reason for allowing revoked for non-ussued certs
> >> >> is to detect/react to compromised CA situations,
> >> >[Piyush] That is the reason that has been cited. The way I see it is
> >> >to allow CAs to continue operations even after the compromise. I
> >> >have not seen a single discussion on how CA would react if starts
> >> >getting such requests.
> >> >systems to unsuspecting customers who do not understand the OCSP
> >> >trust model.
> >> >
> >> >[Piyush]Nor does it mean that certificate was issued and put on
> >> >hold, which is what certifcateOnHold implies.
> >> >
> >> >>
> >> >> It's therefore wrong to reply that the CA is compromised, unless
> >> >>you know  that the CA is compromised.
> >> >> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >> >> >> On Behalf Of Stefan Santesson
> >> >> >> >> I didn't put up an end date for the straw-poll, but the
> >> >> >> >>trend seems clear.
> >> >> >> >>
> >> >> >> >> non-issued certificates. Clearly stating that this is
> >> >> >> >> optional if and only if the
> >> >> >> >OCSP
> >> >> >The meaning of 'good' changes, if the responder returns revoked
> >> >> >for 'fraudulently-issued' certificates.
> >> >> >> >[Piyush] There were some objections on using certificateHold
> >> >> >> >as revocationReason for this purpose. CA compromise would be
> >> >> >> >more appropriate because the only scenario where this is
> >> >> >> >beneficial is when the CA is compromised.
> >> >> >>
> >> >> >> Absolutely not. The CA is not compromised just because I ask
> >> >> >>for a serial  number that was never issued.
> >> >> >
> >> >> >[Piyush] All this time, the reason to propose this change has
> >> >> >been that it helps the situation where certificates are
> >> >> >fraudulently issued. If the RP is not doing signature checking
> >> >> >than this discussion is moot. If RP has verified that signature
> >> >> >is correct and CA thinks it is not issued, it is caCompromise.
> >> >> >> >> 2) Define a new optional non-critical extension declaring
> >> >> >> >> that OCSP responder returns "revoked" for non-issued
> >> >> >> >> certificates according to the updated standard. This
> >> >> >> >> extension MUST be present in all responses where the
> >> >> >> >> "revoked" response is returned as a result of a status
> >> >> >> >> request for a
> >> >> >> >non-
> >> >> >> >> issued certificate.
> >> >> >> >given that it is useful only in the exceptional scenario where
> >> >> >> >CA gets compromised.
> >> >> >>
> >> >> >> whether an OCSP responder adopts this response behaviour even
> >> >> >>if the CA is  not compromised.
> >> >> >>
> >> >> >[Piyush] This is something new. So what are the benefits of this
> >> >> >if the CA is not compromised? What value does it add over
> >> >> >signature
> >> checking?
> >> >> >And I thought that in one of you previous emails you said that
> >> >> >there was a WG decision to limit changes to RFC 2560 to what is
> >> >> >necessary to resolve previous ambiguity. Don't know if that is
still the
> case.
> >> >> >> >[Piyush] Given that a fraudulent certificate has been issued
> >> >> >> >with a serial number, the CA would eventually revoke the
> >> >> >> >certificate with this serial number and would not issue any
> >> >> >> >newer certificate with the same
> >> >> >> serial.
> >> >> >> >I think the confusion arises from the fact that we've been
> >> >> >> >using 'not-issued' and 'fraudulently-issued' interchangeably.
> >> >> >> >All this time I'd been thinking that we are discussing the
> >> >> >> >latter. If that is indeed the case, caCompromise seems more
> appropriate.
> >> >> >>
> >> >> >> No, for reason above.
> >> >> >>
> >> >> >> >
> >> >> >> >> The extension would be a simple OID with no data structure
> >> >> >> >> and MUST not be set to critical.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Question:
> >> >> >> >> It would add the benefit that someone receiving "good" can
> >> >> >> >>know that the  OCSP responder has checked that the
> >> >> >> >>certificate in fact has been issued by  the CA.
> >> >> >> >> Such hash would make the positive confirmation even
> >> >> >> >>stronger, adding proof  of existence of the certificate.
> >> >> >> >validation algorithm to drop the use of CRLs in favor of OCSP
> >> >> >> >and also drop the signature verification (off course if the RP
> >> >> >> >knows that his OCSP responder issues stronger positive
> confirmations).
> >> >> >>
> >> >> >[Piyush] Are you saying that there is no need to evaluate how
> >> >> >this work affects other standards created by pkix.
> >> >> >>
> >> >> >> >>
> >> >> >> >[Piyush] How about a thinner profile of SCVP that could
> >> >> >> >address everything you are trying to achieve in OCSP.
> >> >> >>
> >> >> >[Piyush] SCVP does not need to be updated. It already has
> >> >> >provisions for what you are trying to duplicate in OCSP.
> >> >> >>
> >> >> >> /Stefan
> >> >> >>
> >> >> >
> >> >> >

---

From: Peter Rybar <[email-masked]>
Date: Fri, 2 Nov 2012 16:44:31 +0100

It means the time value in thisUpdate field is a time when CA database
was locked in the process of creating CRL/OCSP response. CRL contains
only revocations with time which were before time value of thisUpdate
field. Any revocatins registered while database was locked must not be
included and are included after next lock of CA database when a new
CRL will be generated.
Peter Rybar

---

From: Simon Tardell <[email-masked]>
Date: Fri, 2 Nov 2012 17:24:58 +0100

> included and are included after next lock of CA database when a new

I am not sure I follow you. Why does the OCSP responder have to care about
when the CRLs are produced (if there are any at all) if it has access to
the database?

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Nov 2012 17:24:52 +0100

Piyush and Dave

I'm so sorry. To much stress today. I completely misread your post.

Yes, you made a great point. Thanks for bringing it up. I agree, it makes
perfect sense to not allow the CRL references extension when responding to
non-issued certificates.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 2 Nov 2012 10:02:43 -0700

I think Peter's point is that most folks consider revocationTime in OCSP
equivalent to revocationDate in CRL.

This interpretation is not ill-formed given that OCSP has no text describing
what revocationTime means in OCSP context.

And if you go by this interpretation, according to 5280, revocationDate
cannot precede thisUpdate of an earlier CRL if the revocation for the
certificate is being reported the first time.

Not saying that OCSP has to follow these rules, but given that it is
deviating from CRLs on the meaning of revocationTime and revocationReason, a
separated section describing these fields should be added.

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Tardell
Sent: Friday, November 02, 2012 9:25 AM
To: Peter Rybar
Cc: Stefan Santesson; [email-masked]
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

I am not sure I follow you. Why does the OCSP responder have to care about
when the CRLs are produced (if there are any at all) if it has access to the
database?

/Simon

---

From: [email-masked] (Martin Rex)
Date: Fri, 2 Nov 2012 19:04:27 +0100 (CET)

> OCSP can be out of scope.

If this is about the optional CrlID OCSP SingleResponseExtension,
I previously mentioned this and Stefan acknowledged it here:

  http://www.ietf.org/mail-archive/web/pkix/current/msg31881.html

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 2 Nov 2012 19:46:44 +0100 (CET)

> what revocationTime means in OCSP context.

But somewhat ignorant of how X.509 defines the meaning of revocationDate.

  ITU-T Rec. X.509 (08/2005), page 34:

   8.5.1 Requirements

   The following requirements relate to CRLs:

   d) A CRL contains, for each revoked certificate, the date when the
      authority posted the revocation. Further information may be known
      as to when an actual or suspected key compromise occurred, and this
      information may be valuable to a certificate user. The revocation
      date is insufficient to solve some disputes because, assuming the
      worst, all signatures issued during the validity period of the
      certificate have to be considered invalid. However, it may be
      important for a user that a signed document be recognized as
      valid even though the key used to sign the message was compromised
      after the signature was produced. To assist in solving this problem,
      a CRL entry can include a second date which indicates when it was
      known or suspected that the private key was compromised.

X.509 is pretty clear that the "revocationDate" entry does *NOT* mean
when a certificate was revoked, but instead, that it means when a
revocation was first published for the cert serial.  And this refers
to "publication on CRL", because publishing a CRL is the X.509 method
to "publish a revocation".

revocationDate of a CRL does not give you either of the two interesting
times: (a) when a certificate was revoked and (b) since when a certificate
is supposed to be invalid.

For conveying the latter (b), an optional crlEntry extension was defined,
and it is explicitly defined to predate "revocationDate":

  ITU-T Rec. X.509 (08/2005), page 36:

   8.5.2.4 Invalidity date extension

   This CRL entry extension field indicates the date at which it is
   known or suspected that the private key was compromised or that
   the certificate should otherwise be considered invalid. This date
   may be earlier than the revocation date in the CRL entry, which is
   the date at which the authority processed the revocation.

But we're actually discussing a certificate status reported through
OCSP that is *NOT* based on a revocation on a CRL.  So CRL semantics
clearly do not apply.  Now since the OCSP responder will typically

  (a) not have access to the cert for which the status is requested,

  (b) not know for which point in time the client will perform
      the validity check when obtaining the OCSP response

  (c) not know whether the RP supports the InvalidityDate extension.

A sensible and safe approach to issue a OCSP status response, for a cert
for which no record of issue exists, that will cause the RP to reject
that cert with very high probability, is to fill revocationDate with
a value suffiently far in the past, like Jan 1st, 1970.

> certificate is being reported the first time.

OCSP was designed to report on status _other_ than revocation,
but didn't define any codepoints to convey "reject this cert"
other than those defined for CRLs.  And from that list, in order
to interoperate with the installed base "certificateHold, reject"
appears to be the most sensible choice.

Look at the history of draft-ietf-pkix-ocsp:

Section 3/2 Protocol Overview

 01-05:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the revocation state of an identified certificate.

 06-07:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the state of an identified certificate. 

 rfc2560:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of an identified certificate.

OCSP is *NOT* limited to CRLs as information source.
But it is currently limited to CRL ReasonCodes to expressing
"reject this cert".

> separated section describing these fields should be added.

There is no such thing as a strict sequence of OCSP responses, so the
conventions that apply to the relation of revocationDate to thisUpdate
for a serial listed on a CRL do not apply to OCSP.  FWIW, they also
apply only to the very first CRL that this serial appears on, so in
general, this is a pretty irrelevant characteristic for code that
processes CRLs and OCSP responses.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 2 Nov 2012 12:53:33 -0700

> But somewhat ignorant of how X.509 defines the meaning of revocationDate.

Don't know how you concluded this from either mine or Peter's comments.

My interpretation was that revocationDate tells you a) but not b). For b)
you need invalidity date extension. Your assertion is that revocationDate
does not tell you the revocation time. I think it is incorrect.  Here is the
excerpt from 5280 section 5.1.2.6
  "Certificates revoked by the CA are uniquely identified by the certificate
serial number.  The date on which the revocation occurred is specified.  The
time for revocationDate MUST  be expressed as described in section 5.1.2.4."

> OCSP was designed to report on status _other_ than revocation, but didn't
define any codepoints to convey "reject this cert"  other than those defined
for CRLs.  

OCSP explicitly states that good status implies that certificate was never
revoked and does not necessarily imply that cert was issued or valid. And
that response extension may be used to convey additional information
regarding the status such as positive statements about issuance and
validity.  The code points were not defined but the provision for including
those additional statuses is clearly stated - by defining response
extension, not by overloading the meaning of revoked. 

>And from that list, in order to interoperate with the installed base
"certificateHold, reject" appears to be the most sensible choice.
I fail to understand how this helps interoperability. And what "install
base" are you talking about - public CA deployments, enterprise OCSP
deployments or something else.

> conventions that apply to the relation of revocationDate to thisUpdate for
a
> serial listed on a CRL do not apply to OCSP.  FWIW, they also apply only
to the
> very first CRL that this serial appears on, so in general, this is a
pretty
> irrelevant characteristic for code that processes CRLs and OCSP responses.

All the more reason to add sections in OCSP to clarify the meaning of
revcationTime and revocationReason in OCSP. Currently there is no text for
these fields in OCSP and people fallback to 5280 to figure out what it means
and how it should be set.

---

From: [email-masked] (Martin Rex)
Date: Fri, 2 Nov 2012 23:05:47 +0100 (CET)

> time for revocationDate MUST  be expressed as described in section 5.1.2.4."

rfc5280 is inaccurate in that it assumes that "revocationDate" means
revocationDate, andignores the X.509 definition.

But the date when either the cert holder reported/requested or the CA
decided or acknowledged that the cert is to be revoked is somewhat
irrelevant for the code that is processing these data structures.
The only point in times interesting to them is (a) when was it first
posted/published or (b) at which time invalidity should be assumed
to have started.

> revoked and does not necessarily imply that cert was issued or valid.
> And that response extension may be used to convey additional information
> validity.

Correct.  OCSP says that a simple-minded OCSP responder, like one feeding
on CRLs, may respond "good" for certs / serials that may have never been
issued.  

What it neither says, and certainly not suggest is that an OCSP responder
who is well aware that a certificate was never issued, should also
respond "good".

It actually fairly basic common sense that the description of positive
confirmations of cert issuance is complemented about negative
confirmations (=revoked status, due to a lack of alternative
negative confirmations) about not-issued certs.

>
> The code points were not defined but the provision for including

The text under good only describes positive confirmations.
Negative confirmations would not make any sense under status "good".

> deployments or something else.

The installed base of RPs, to which a responsible OCSP responder wants
to deliver the message "you ought to reject this cert", plus counting
in that this status can not be conveyed through CRLs (to which some RPs
will fallback if OCSP returns an error) or that some implementations
will soft-fail when OCSP returns an error.

>> a serial listed on a CRL do not apply to OCSP.  FWIW, they also apply only
>> to the very first CRL that this serial appears on, so in general, this
>> is a pretty irrelevant characteristic for code that processes
>> CRLs and OCSP responses.
> 

What the revocationDate means to an RP is extremely context dependent,
so if anything could be clarified, then that it can not be clarified
due to how its defined in X.509.

Recall ITU-T Rec. X.509 (08/2005), page 35

  d) A CRL contains, for each revoked certificate, the date when the
     authority posted the revocation. Further information may be known
     as to when an actual or suspected key compromise occurred, and this
     information may be valuable to a certificate user. The revocation
     date is insufficient to solve some disputes because, assuming the
     worst, all signatures issued during the validity period of the
     certificate have to be considered invalid. However, it may be
     important for a user that a signed document be recognized as valid
     even though the key used to sign the message was compromised after
     the signature was produced. To assist in solving this problem,
     a CRL entry can include a second date which indicates when it was
     known or suspected that the private key was compromised.

"The revocation date is insufficient to solve some disputes ..."
"To assist in solving ..."

bottom line is that X.509 says, revocationDate can mean anything to
anybody, and you might need a layer and a court to analyze what it means
with respect to a particular's CA certificate practice statement.

It is up to the RP to decide what it means in terms of risk management
and whether to ignore any given revocationDate and invalidityDate
timestamps.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 3 Nov 2012 08:39:51 -0700

> posted/published or (b) at which time invalidity should be assumed to have
> started.

I think these statements about relevance are based on a narrow viewpoint.
One example is an application which needs to trigger an audit for all
transactions that happened between invalidity time and revocation time.
Both dates are required in this case. Just because you have not found a use
case does not make this information irrelevant. 

> who is well aware that a certificate was never issued, should also respond
> "good".

But it clearly says that responder should return revoked for certificates
that have been revoked. 

> confirmations  (=revoked status, due to a lack of alternative negative
confirmations) about not-issued certs.

Again, the common sense you talk about is based on set of limited use cases
- public CAs with browser clients.
You can find lot of corner cases that people like to address using OCSP. And
that is why there are response extensions. 
Here is another example - Checking the bank balance of the certificate
holder before allowing a financial transaction to go through. The negative
proof in this case does not warrant a revoked response. Instead the
information should be communicated using response extension. And if you are
wondering, this is not a fictitious use case. I know of at least one OCSP
responder that is designed for such use cases, what the vendor calls
'state-full validations'. 

What defies common sense is encouraging users to question the signature on
EE certificates and trusting the signature on responder certificates, even
though both are signed by the same authority.
And just to get the terminology right, these are not non-issued
certificates, these are certificates issued without the CA's knowledge, i.e.
fraudulently issued certificates. So even if the responder decides to return
revoked for such certificates, CA compromise is the right reason code.