Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Oct 2012 16:24:31 +0200

Peter,

An OCSP responder is by default a service providing information about
current certificates.
The default response you get from an OCSP responder is "good" unless the
cert is known to be bad or not a cert the responder can provide status for.

If you need it to respond about old certificates, and as a client know that
the responder does this in a way that suits your needs, you will need to add
an extension.
Such extension will not be part of the rfc256bis effort.

Is there any text in the current draft that you think is unclear on this?

/Stefan

From:  Peter Rybar <[email-masked]>
Date:  Friday, October 19, 2012 3:12 PM
To:  'Carl Wallace' <[email-masked]>, 'Simon Tardell'
<[email-masked]>
Cc:  'Peter Rybar' <[email-masked]>, Stefan Santesson
<[email-masked]>, <[email-masked]>
Subject:  RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

>> Well, yes, sort of. You can only be sure to validate a signature at the
>> moment of production.
> 
>  
> 
> What if the signature key was compromised at the moment of production but is
> not yet on a revocation list?
> [PR] According to clause 2.4  -  thisUpdate: The time at which the status
> being indicated is known to be correct
> It means when signature time-stamp time is X then any OCSP responses with
> thisUpdate time X+y are sufficient to validate because the status is correct.
> Y is in the interval <0, producedAt - X>
> 
>  
>> At any later point in time the signature key may be compromised, or the
>> algorithms involved may have become to weak. (In which case the time of
>> revocation in the OCSP response is worth nothing to you). The risk increases
>> as time passes. And of course, the revocation information may not be kept
>> around after the expiry of the certificate.
>> 
>>  
>> 
>> That's why you should validate signatures as soon as possible.
> 
>  
> 
> For these archival purposes wouldn't it be better to have the final revocation
> list before removed due to expiry?  In any case, you'd need verification
> information collected after some grace period following moment of production.
> 
> [PR] Grace period is not a fixed value of the time interval.
> Grace period is changeable because the first OCSP response with thisUpdate
> time value > than time of signature time-stamp contains correct status.
>  
>> 
>>  
>> 
>> If you need to ascertain that a signature was valid at a later time, you have
>> to trust your system that it performed the validation at the time it first
>> received the signature. That trust must be established through some kind of
>> mix of policies and technical measures (such as timestamping).
> 
>  
> 
> In the dark corner just beyond the dark corner that is SCVP, there's a spec
> (RFC 5276) that defines a binding of evidence records to artifacts that can be
> returned via SCVP.  This provides for timestamping.
> [PR] The validation is simplified when OCSP response with positive statement
> as a hash value of requested certificate is used.
> Positive statement is evidence that OCSP know the status of certificate and
> also protect the integrity of certificate with a new more secure hash
> algorithm.
> 
>  
> Peter Rybar
>  
>> 
>> 
>> 
>> Simon Tardell, 
>> 
>> Technology Nexus.
>> 
>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <[email-masked]> wrote:
>> Stefan,
>> 
>> I have a question about the present OCSP RFC and at the end of the mail about
>> the new situation which will happen according to your new proposal.
>> 
>> The presence of the positive statement in OCSP response is important for
>> electronic signature validations, especially for an expired certificate.
>> Positive statement is the hash value of a certificate whose status is
>> provided in OCSP response.
>> 
>> Electronic signature validation is usually about the signatures created in
>> the past and validated now, when the certificate is expired.
>> 
>> When the certificate expires then revocation is usually removed from CRL and
>> the revoked certificate can be provided as "good" in OCSP response.
>> Is it acceptable? I think not.
>> 
>> According to your new draft there is not defined a value of revocationTime.
>> RFC must also define the value of revocationTime when the certificate which
>> was never issued is as "revoked".
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06
>> 
>> Have you also covered the situation when the certificate is expired, REMOVED
>> FROM CRL and will be provided as revoked with incorrect revocationTime e.g.
>> with the value before or after the revocationTime which was present in the
>> removed record from CRL?
>> Because according to sentence in your draft ""revoked" - This state SHOULD
>> also be returned if the responder knows that the requested certificate has
>> never been issued." the following situation can happen: when certificate is
>> removed from CRL after expiration and CA/OCSP responder is responsible for
>> this certificate but have not record about expired certificate and for that
>> reason it is identified as "never been issued".
>> 
>> ...
>> revoked     [1]     IMPLICIT RevokedInfo,
>> ...
>> 
>>    RevokedInfo ::= SEQUENCE {
>>        revocationTime             GeneralizedTime,
>>        revocationReason    [0]    EXPLICIT CRLReason OPTIONAL }
>> 
>> As you have mentioned in the mail:
>> 
>> "On the "revoked" state, the old spec did not even consider the case of a
>> certificate being requested where the OCSP responder knows that the
>> certificate was never issued."
>> 
>> "It simply recommend a known to be bad certificate to result
>> in "revoked" in order to prevent damage as far as possible. It also opens
>> for definition of new extensions through which such knowledge could be
>> obtained."
>> Peter Rybar
>> National Security Authority
>> Information Security and Electronic Signature Department
>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic
>> e-mail: [email-masked]
>> e-mail: [email-masked]
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Stefan Santesson
>> Sent: Monday, October 15, 2012 1:49 AM
>> To: [email-masked]
>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06
>> 
>> All,
>> 
>> I have just posted an update of rfc2560bis (OCSP update) after carefully
>> reviewing all comments on the list.
>> 
>> Some notes about the update:
>> 
>> - Added the previous OCSP editors with updated affiliations.
>> - Added some calcifications on ResponderID as suggested by Simon Josefsson.
>> - Updated the clarifications on Authorized responders. The requirements
>> have not changed. I just tried to improve the text.
>> - Updated a clarification on the "revoked" state to be the preferred
>> response if a certificate is known by the responder to never have been
>> issued.
>> - Some minor editorial nits.
>> 
>> 
>> Regarding backwards compatibility I mean that none of the clarifications
>> changes RFC 2560.
>> 
>> On Authorized responders it has always been the case that a responder
>> certificate issued with the same key as was used to issue the certificate
>> being checked for revocation, represents a valid Authorized responder.
>> There has never been an explicit requirement to support key rollover and
>> key rollover support has never been in the "spirit" of the original
>> standard as it clearly attempted to provide direct cryptographic binding
>> between the responder and the CA.
>> 
>> On the "revoked" state, the old spec did not even consider the case of a
>> certificate being requested where the OCSP responder knows that the
>> certificate was never issued. It is clearly counterproductive to respond
>> good when a certificate is known to be bad. A responder must pick one
>> response and picking "revoked" breaks nothing, but has the desired effect,
>> that is, to prevent the certificate from being accepted. The current text
>> makes clear that there is no mechanism in the current standard by which a
>> client can know how a responder will respond to a request for a not issued
>> certificate. It simply recommend a known to be bad certificate to result
>> in "revoked" in order to prevent damage as far as possible. It also opens
>> for definition of new extensions through which such knowledge could be
>> obtained.
>> 
>> The current updates also clearly opens a path for the CAB forum efforts to
>> define a suitable solution for server certificates.
>> 
>> I have not, even thug suggested, added any requirements on what clients
>> should do with the checked cert as a result of a particular response. I
>> don't believe such requirements are suitable as it is policy and not
>> protocol. We have no right to demand that all systems MUST reject any
>> certificate for any reason as they may have a local policy that overrules
>> the OCSP response. This protocol only provides information about the cert
>> status, it does not mandate validation policy.
>> 
>> I have not included any of the substantial changes i the Pinkas draft. I
>> want to wait for a list of motivation for each change before including any
>> of them. So there changed may be up for debate before this draft is ready
>> for WGLC.
>> 
>> /Stefan
>> 
>> 
>> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>>  
>> _______________________________________________ pkix mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 19 Oct 2012 10:34:16 -0700

Stefan,

I think some of you interpretations below are twisted to accommodate the new
provisions for providing revoked responses for unissued certificates.

Providing responses for expired certificates is within the scope of 2560
using archive cutoff extension.

The original authors of 2560 can correct me if I'm wrong, but it is my
understanding that a response from OCSP responder is not supposed to
indicate if a certificate is good or bad but to indicate if a certificate is
revoked or unrevoked by the issuing authority. The fact that certificate is
issued by the CA is checked by the RP by verifying the signature on the
certificate.

This draft introduces the concept of returning revoked responses for
unissued certificates. There are many unintended consequences of this
approach

-          Revocation statuses become non-deterministic based on who you are
asking (A responder with access to CA database vs. one without vs. checking
status off a CRL). If I'm archiving a signed document with the relevant
artifacts to determine the validity status of the document, this becomes a
huge problem. Note that a revoked status implies that certificate was good
between the time of its issuance and that of its revocation. Any document
that is signed within that period should still be considered valid.

-          It would confuse an implementer about what "non-issued" means.
The fact that the CA signed the certificate implies it was issued. If a
certificate is issued fraudulently, based on its security practices, it is
up to the CA to either revoke the issued certificate, or ask its issuing
authority to revoke its own certificate.

-Piyush

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Friday, October 19, 2012 7:25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

Peter,

/Stefan

It means when signature time-stamp time is X then any OCSP responses with
thisUpdate time X+y are sufficient to validate because the status is
correct. 

For these archival purposes wouldn't it be better to have the final
revocation list before removed due to expiry?  In any case, you'd need
verification information collected after some grace period following moment
of production.

 

If you need to ascertain that a signature was valid at a later time, you
have to trust your system that it performed the validation at the time it
first received the signature. That trust must be established through some
kind of mix of policies and technical measures (such as timestamping).

In the dark corner just beyond the dark corner that is SCVP, there's a spec
(RFC 5276) that defines a binding of evidence records to artifacts that can
be returned viaSCVP.  This provides for timestamping.  

Peter Rybar

Simon Tardell, 

Technology Nexus.

Stefan,

I have a question about the present OCSP RFC and at the end of the mail
about the new situation which will happen according to your new proposal.

Have you also covered the situation when the certificate is expired, REMOVED
FROM CRL and will be provided as revoked with incorrect revocationTime
e.g.with the value before or after the revocationTime which was present in
the removed record from CRL?
Because according to sentence in your draft ""revoked" - This state SHOULD
also be returned if the responder knows that the requested certificate has
never been issued." the following situation can happen: when certificate is
removed from CRL after expiration and CA/OCSP responder is responsible for
this certificate but have not record about expired certificate and for that
reason it is identified as "never been issued".

...

Peter Rybar

-----Original Message-----

All,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 20 Oct 2012 04:22:51 +0200

I'm sorry. I fail to the any of the problems you raise.

If you receive a request for a certificate that you know has never been
issued, and you choose to reply revoked, what problems can you cause?
What in your mind is a more appropriate response?

It does not make OCSP more non-deterministic. If you ask status for an
issued cert from a non-broken CA, nothing is non-deterministic.
If you ask for status for a non-issued certificate, or a bad certificate
from a broken CA, then the result is by default non-deteministic and has
always been. However, choosing a revoked response may save the relying
party, at best, but can hurt no-one

What is your problem on the practical ground.

/Stefan

From:  Piyush Jain <[email-masked]>
Date:  Friday, October 19, 2012 7:34 PM
To:  Stefan Santesson <[email-masked]>, 'Peter Rybar' <[email-masked]>,
'Carl Wallace' <[email-masked]>, 'Simon Tardell'
<[email-masked]>
Cc:  'Peter Rybar' <[email-masked]>, <[email-masked]>
Subject:  RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

> Providing responses for expired certificates is within the scope of 2560 using
> archive cutoff extension.
>  
> The original authors of 2560 can correct me if I¹m wrong, but it is my
> understanding that a response from OCSP responder is not supposed to indicate
> if a certificate is good or bad but to indicate if a certificate is revoked or
> unrevoked by the issuing authority. The fact that certificate is issued by the
> CA is checked by the RP by verifying the signature on the certificate.
>  
> This draft introduces the concept of returning revoked responses for unissued
> certificates. There are many unintended consequences of this approach
> status off a CRL). If I¹m archiving a signed document with the relevant
> between the time of its issuance and that of its revocation. Any document that
> is signed within that period should still be considered valid.
> 
> -          It would confuse an implementer about what ³non-issued² means. The
> fact that the CA signed the certificate implies it was issued. If a
> certificate is issued fraudulently, based on its security practices, it is up
> to the CA to either revoke the issued certificate, or ask its issuing
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan
> Santesson
> An OCSP responder is by default a service providing information about current
> certificates.
> 
> The default response you get from an OCSP responder is "good" unless the cert
> is known to be bad or not a cert the responder can provide status for.
> 
>  
> 
> Cc: 'Peter Rybar' <[email-masked]>, Stefan Santesson <[email-masked]>,
> <[email-masked]>

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 20 Oct 2012 08:48:44 -0700

Please see inline

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; [email-masked]
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Piyush] It depends on how you define "never been issued", which btw becomes
unclear after introduction of the new text. There are two interpretations

1)      Certificate is not signed by the CA or

2)      Certificate is not present in the database of issued certificates
that CA maintains.

One unintended consequence of first interpretation will be that RPs would
stop performing signature checks if their responder/CA publicizes that it
returns revoked for "non-issued" certificates.

If the interpretation is 2, then this scenario is not possible unless the CA
is compromised.

[Piyush] I would say the appropriate response is good (if the certificate is
not marked as revoked), because that is what the RP will see if it consults
a CRL or a responder detached from the CA. 

Revoked for "not issued" adds no value because the only case in which an RP
would send a query for a "non-issued" certificate is when the CA is
compromised.

[Piyush] It does not make OCSP non-deterministic but it makes revocation
checking non-deterministic. The goal of OCSP is to address operational
limitations of CRLs, not functional limitations.  The fact that you'll get
different answers from two sources, both of which are authorized by the same
CA makes revocation checking non deterministic. 

[Piyush] I agree that a revoke response does not hurt anyone. But the point
is that it provides a false sense of additional security to the RP without
providing any. As an RP, I won't trust what my responder says if the
authority that certified it is compromised.

[Piyush]  Let's say that we still need to address this scenario and revoked
is the appropriate response. In that case

-          The text needs to be explicit about the revocation time in this
situation. Revoked implies good until a certain date and this distinction is
important for long term archiving applications. For unissued certificate the
revocation time should probably be set to -infinity.

-          It needs to call out that in this particular scenario it is
addressing a functional limitation of CRLs (ability to detect CA compromise)
not an operational limitation.

-          I think we need additional text in security considerations to
indicate that RP is communicating with a responder certified by a
compromised CA in this scenario.

/Stefan

Stefan,

-Piyush

 

Peter,

/Stefan

 

Peter Rybar

Simon Tardell, 

Technology Nexus.

Stefan,

...

Peter Rybar

-----Original Message-----

All,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 21 Oct 2012 17:52:10 +0200

I don't think the "not issued" is unclear.

The possibility to send a revoked reply only applies then the responder
"knows" that the requested certificate has never been issued.
How the responder knows this is totally irrelevant, but unless the responder
knows this, it can't choose this option and has to reply "good".

It does not make revocation checking non-deterministric.
"good" still means what is declared in the standard (The cert is not known
to be revoked, but it may never have been issued).
"revoked" still have a deterministic meaning, that is, don't trust this
cert. The old exact semantics was "the cert IS revoked". The new semantic is
"the cert is revoked or possibly might never been issued"

The new response semantic of revoked is backwards compatible and not less
deterministic than the good, response.

So, I still don't see any practical problems here.

/Stefan

Date:  Saturday, October 20, 2012 5:48 PM

> [Piyush] It depends on how you define ³never been issued², which btw becomes
> 2)      Certificate is not present in the database of issued certificates that
> CA maintains.
> 
> One unintended consequence of first interpretation will be that RPs would stop
> performing signature checks if their responder/CA publicizes that it returns
> revoked for ³non-issued² certificates.
> not marked as revoked), because that is what the RP will see if it consults a
> CRL or a responder detached from the CA.
> Revoked for ³not issued² adds no value because the only case in which an RP
> would send a query for a ³non-issued² certificate is when the CA is
> compromised.
> 
>  
> 
> It does not make OCSP more non-deterministic. If you ask status for an issued
> cert from a non-broken CA, nothing is non-deterministic.
> limitations of CRLs, not functional limitations.  The fact that you¹ll get
> If you ask for status for a non-issued certificate, or a bad certificate from
> a broken CA, then the result is by default non-deteministic and has always
> been. However, choosing a revoked response may save the relying party, at
> best, but can hurt no-one
> [Piyush] I agree that a revoke response does not hurt anyone. But the point is
> that it provides a false sense of additional security to the RP without
> providing any. As an RP, I won¹t trust what my responder says if the authority
> that certified it is compromised.
>  
> 
> [Piyush]  Let¹s say that we still need to address this scenario and revoked is
> the appropriate response. In that case
> revocation time should probably be set to infinity.
> 
> indicate that RP is communicating with a responder certified by a compromised
> CA in this scenario.
> 
>  
>  
> 
> /Stefan
> 
>  
> 
> 'Carl Wallace' <[email-masked]>, 'Simon Tardell' <[email-masked]>
>> if a certificate is good or bad but to indicate if a certificate is revoked
>> or unrevoked by the issuing authority. The fact that certificate is issued by
>> the CA is checked by the RP by verifying the signature on the certificate.
>>  
>>>> revocation in the OCSP response is worth nothing to you). The risk
>>>> increases as time passes. And of course, the revocation information may not
>>>> be kept around after the expiry of the certificate.
>>>> 
>>>>  
>>>> 
>>>> When the certificate expires then revocation is usually removed from CRL
>>>> and the revoked certificate can be provided as "good" in OCSP response.
>>>> Have you also covered the situation when the certificate is expired,
>>>> REMOVED FROM CRL and will be provided as revoked with incorrect
>>>> revocationTime e.g.with the value before or after the revocationTime which
>>>> was present in the removed record from CRL?

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 21 Oct 2012 10:42:50 -0700

So what is "not-issued" - not signed by the CA or not present in CA
database?

It is unclear to folks who have been using signature verification as a way
to check issuance. Isn't it a fair conclusion that I do not need to perform
signature checks if the responder can check issuance for me?

You said that the possibility to send revoked reply only applies when the
responder 'knows' that requested certificate has never been issued. 

Please note that the responder will encounter this kind of request only in
two situations. First in which the RP sends a request for a certificate
without checking the signature and second in which the responder itself is
compromised by virtue of its issuing authority being compromised. In either
case what the responder responds with does not matter.

I've no problem with your proposal to respond with 'revoked' in this
situation.

I've fundamental problem with the introduction of 'non-issued' concept in
OCSP, which seems to provide additional security in this exceptional
scenario without actually providing any.

It'll be very helpful if I can see at least one practical scenario where
this additional text would add value.

-Piyush

Sent: Sunday, October 21, 2012 8:52 AM

/Stefan

Please see inline

 

/Stefan

Stefan,

-Piyush

 

Peter,

/Stefan

 

Peter Rybar

Simon Tardell, 

Technology Nexus.

Stefan,

...

Peter Rybar

-----Original Message-----

All,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 21 Oct 2012 20:03:20 +0200

In line;

Date:  Sunday, October 21, 2012 7:42 PM

> So what is ³not-issued² - not signed by the CA or not present in CA database?

Not issued means it has never been issued. What's unclear about that?

Of course it is not present in the database if it is not issued.
If you delete things from your database and don't know if this one has been
deleted, then you don't know that it has never been issued and can't reply
revoked.

> It is unclear to folks who have been using signature verification as a way to
> check issuance. Isn¹t it a fair conclusion that I do not need to perform

No that is not a fair conclusion. These are entirely different things.

> responder ¹knows¹ that requested certificate has never been issued.
> Please note that the responder will encounter this kind of request only in two
> situations. First in which the RP sends a request for a certificate without
> checking the signature and second in which the responder itself is compromised
> by virtue of its issuing authority being compromised. In either case what the
> responder responds with does not matter.
>  

Some people are pretty convinced it does (from CAB forum), they are so
convinced that they are prepared to break compatibility with OCSP. By this
little extension that hurst no-one, they don't have to.

> I¹ve no problem with your proposal to respond with Œrevoked¹ in this
> situation.

Good.

> I¹ve fundamental problem with the introduction of Œnon-issued¹ concept in
> OCSP, which seems to provide additional security in this exceptional scenario
> without actually providing any.

It provides some, but not much. People keep coming back to that fact that if
this had been the practice of Diginotar, the security breach would have been
discovered a lot earlier. So there might be some gain with no pain.

However, in combination with an extension that adds information, this might
actually be increasingly valuable.
If an OCSP responder starts receiving status requests for certs it knows it
has not issued, it can actually give explicit information about this using
an extension and it can take adequate measures.
But in order to respond to the user, it need to pick one of the responses.
Either good + extension or revoked+extension.

This proposal is not meant to require any OCSP responder to deal with the
concept of "non-issued" certs. It merely allows an OCSP responder to respond
to such request.

>  
> It¹ll be very helpful if I can see at least one practical scenario where this
> additional text would add value.

Stated in my previous comments.

/Stefan

> "good" still means what is declared in the standard (The cert is not known to
> be revoked, but it may never have been issued).
> 
> "revoked" still have a deterministic meaning, that is, don't trust this cert.
> The old exact semantics was "the cert IS revoked". The new semantic is "the
> cert is revoked or possibly might never been issued"
> 
>  
> 
>> returns revoked for ³non-issued² certificates.
>> providing any. As an RP, I won¹t trust what my responder says if the
>> [Piyush]  Let¹s say that we still need to address this scenario and revoked
>>> -          It would confuse an implementer about what ³non-issued² means.
>>>> What if the signature key was compromised at the moment of production but
>>>> is not yet on a revocation list?
>>>>> increases as time passes. And of course, the revocation information may
>>>>> not be kept around after the expiry of the certificate.
>>>>> 
>>>>>  
>>>>> 
>>>> [PR] The validation is simplified when OCSP response with positive
>>>> statement as a hash value of requested certificate is used.
>>>>> RFC must also define the value of revocationTime when the certificate
>>>>> which was never issued is as "revoked".
>>>>> never been issued." the following situation can happen: when certificate
>>>>> is removed from CRL after expiration and CA/OCSP responder is responsible
>>>>> for this certificate but have not record about expired certificate and for
>>>>> that reason it is identified as "never been issued".
>>>>> 
>>>>> ...

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Oct 2012 15:48:50 +0200

Peter,

You have a point there. I missed that, good catch.

/Stefan

From:  Peter Rybar <[email-masked]>
Date:  Monday, October 22, 2012 2:38 PM
To:  Stefan Santesson <[email-masked]>
Cc:  Peter Rybar <[email-masked]>, Carl Wallace <[email-masked]>,
Simon Tardell <[email-masked]>, <[email-masked]>
Subject:  Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

> Stefan,
> 
> You have defined in draft that certificate identified with correct (hash of
> issuer name, hash of  issuer key) and with unknown cert serial number xyz is
> revoked. 
> Correct response must also contains the value of item revocationTime.
> 
> Do you know the correct value of  revocationTime in situation which you have
> described?
> ...
> Peter
> 2012/10/19 Stefan Santesson <[email-masked]>
>> Peter,
>>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Oct 2012 16:03:17 +0200

To the PKIX list:

    Without changing the meaning of "good" and of either "revoked" or
    "unknown", it is not possible to address the case of what is
     presently called "non-issued certificates".

The current text from RFC 2560 is:

    "The "good" state indicates a positive response to the state 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 state of the certificate such as
    positive statement about issuance, validity, etc.

    The "revoked" state indicates that the certificate has been revoked
    (either permanantly or temporarily (on hold)).

    The "unknown" state indicates that the responder doesn't know about
    the certificate being requested".

    A minor change should be done to advertise that "good" may be
    returned when the certificate was never issued and CRLs are being
    used.

Replacement text for the definition of the "good" state:

    "The "good" state indicates a positive response to the state 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 *(e.g. when CRLs are used by the OCSP responders)*
   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 OCSP
    responder regarding the state of the certificate such as *an **
**   indication that the OCSP responder has a direct access to the **
**   database of issued certificates*, validity, etc ... "

    Then either the meaning of "rekoved" or of "unknown" needs to be
    changed.

    draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and
    proposes to keep the meaning of "unknown" unchanged and to change
    the meaning of "revoked" in the following way:

    "The "revoked" state indicates that the certificate has been revoked
    (either permanently or temporarily (on hold)). This state SHOULD also
    be returned if the responder *knows that the requested certificate 
has **
**   never been issued*. Note that the receiver of a response may have to
    consult out-of-band knowledge, or information in an extension defined
    outside of this standard, to know whether a particular responder has
    knowledge about whether a requested certificate has been issued or
    not and whether it responds "good" or "revoked" to a state request
    for a non-issued certificate".

    There is a door opened for a future extension "to know whether a
    particular responder has knowledge about whether a requested
    certificate has been issued or not".

    However, the extension proposed in 
draft-pinkas-2560bis-certinfo-00.txt,
    carries a slightly different meaning:

       - an indication that the serial number of the target
         certificate is not present in the database,

*Saying that the certificate has not been issued is not fully appropriate.*

The text should be modified in the following way:

    "The "revoked" state indicates that the certificate has been revoked
    (either permanently or temporarily (on hold)).  This state SHOULD
    also be returned if the responder *has an access to the database
    of **issued certificates and if the serial number of the target **
**   certificate is not present in that database. *

*In this case, the "revoked" state indicates either that the **
**   certificate has never been issued or that it has been issued but **
**   subsequently removed (by an attack or by accident) from the
    database **of issued certificates.*

    Response extensions may be used  to convey additional information
    on assertions made by the OCSP  responder regarding the state of the
    certificate such as *an **indication that the OCSP responder has
    a direct access to the **database of issued certificates*, validity, 
etc ... "

An alternative is to keep the meaning of "revoked" and to change
the meaning of "unknown" in the following way:

    "The "unknown" status indicates either that the server doesn't know
    about the certificate being requested *or the revocation status
    of the certificate being requested*

    Response extensions may be used  to convey additional information
    on assertions made by the OCSP  responder regarding the state of the
    certificate such as *an **indication that the OCSP responder has
    a direct access to the **database of issued certificates*, validity, 
etc ..."

There are pros and cons for each alternative. If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:

    CertStatus ::= CHOICE {
        good        [0]     IMPLICIT NULL,
        revoked     [1]     IMPLICIT RevokedInfo,
        unknown     [2]     IMPLICIT UnknownInfo }

    RevokedInfo ::= SEQUENCE {
        revocationTime              GeneralizedTime,
        revocationReason    [0]     EXPLICIT CRLReason
                                    OPTIONAL }

    UnknownInfo ::= NULL

CRLReason is imported from PKIX1Implicit88 { iso(1) 
identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }

CRLReason is defined in RFC 5280 as:

    CRLReason ::= ENUMERATED {
         unspecified             (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6),
              -- value 7 is not used
         removeFromCRL           (8),
         privilegeWithdrawn      (9),
         aACompromise           (10) }

For the revocationTime should we use the content of notBefore field from 
the certificate ?

For the revocationReason should we use unspecified or keyCompromise ?

In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen 
as "safer"
for old implemenations, changing the meaning of "unknown" also seems to 
be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP 
responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an 
alternative source
of revocation information like CRLs.

Denis

> In line;
>
> From: Piyush Jain <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>, 
> 'Peter Rybar' <[email-masked] <mailto:[email-masked]>>, 'Carl Wallace' 
> <[email-masked] <mailto:[email-masked]>>, 'Simon 
> Tardell' <[email-masked] <mailto:[email-masked]>>
> Cc: 'Peter Rybar' <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>
>     So what is "not-issued" - not signed by the CA or not present in
>     CA database?
>
>
> If you delete things from your database and don't know if this one has 
> been deleted, then you don't know that it has never been issued and 
> can't reply revoked.
>
>
>     It is unclear to folks who have been using signature verification
>     as a way to check issuance. Isn't it a fair conclusion that I do
>     not need to perform signature checks if the responder can check
>     issuance for me?
>
>
>     You said that the possibility to send revoked reply only applies
>     when the responder 'knows' that requested certificate has never
>     been issued.
>
>     Please note that the responder will encounter this kind of request
>     only in two situations. First in which the RP sends a request for
>     a certificate without checking the signature and second in which
>     the responder itself is compromised by virtue of its issuing
>     authority being compromised. In either case what the responder
>     responds with does not matter.
>
>
> convinced that they are prepared to break compatibility with OCSP. By 
> this little extension that hurst no-one, they don't have to.
>
>     I've no problem with your proposal to respond with 'revoked' in
>     this situation.
>
>
> Good.
>
>     I've fundamental problem with the introduction of 'non-issued'
>     concept in OCSP, which seems to provide additional security in
>     this exceptional scenario without actually providing any.
>
>
> It provides some, but not much. People keep coming back to that fact 
> that if this had been the practice of Diginotar, the security breach 
> would have been discovered a lot earlier. So there might be some gain 
> with no pain.
>
> However, in combination with an extension that adds information, this 
> might actually be increasingly valuable.
> If an OCSP responder starts receiving status requests for certs it 
> knows it has not issued, it can actually give explicit information 
> about this using an extension and it can take adequate measures.
> But in order to respond to the user, it need to pick one of the 
> responses. Either good + extension or revoked+extension.
>
> This proposal is not meant to require any OCSP responder to deal with 
> the concept of "non-issued" certs. It merely allows an OCSP responder 
> to respond to such request.
>
>     It'll be very helpful if I can see at least one practical scenario
>     where this additional text would add value.
>
>
>     *From:*Stefan Santesson [mailto:[email-masked]]
>     *Sent:* Sunday, October 21, 2012 8:52 AM
>     *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
>     *Cc:* 'Peter Rybar'; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>     The possibility to send a revoked reply only applies then the
>     responder "knows" that the requested certificate has never been
>     issued.
>
>     How the responder knows this is totally irrelevant, but unless the
>     responder knows this, it can't choose this option and has to reply
>     "good".
>
>     "good" still means what is declared in the standard (The cert is
>     not known to be revoked, but it may never have been issued).
>
>     "revoked" still have a deterministic meaning, that is, don't trust
>     this cert. The old exact semantics was "the cert IS revoked". The
>     new semantic is "the cert is revoked or possibly might never been
>     issued"
>
>     The new response semantic of revoked is backwards compatible and
>     not less deterministic than the good, response.
>
>     *From: *Piyush Jain <[email-masked] <mailto:[email-masked]>>
>     *Date: *Saturday, October 20, 2012 5:48 PM
>     *To: *Stefan Santesson <[email-masked]
>     <mailto:[email-masked]>>, 'Peter Rybar' <[email-masked]
>     <mailto:[email-masked]>>, 'Carl Wallace'
>     <[email-masked] <mailto:[email-masked]>>,
>     'Simon Tardell' <[email-masked] <mailto:[email-masked]>>
>     *Cc: *'Peter Rybar' <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>     *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>         Please see inline
>
>         *From:*Stefan Santesson [mailto:[email-masked]]
>         *Sent:* Friday, October 19, 2012 7:23 PM
>         *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
>         *Cc:* 'Peter Rybar'; [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>         If you receive a request for a certificate that you know has
>         never been issued, and you choose to reply revoked, what
>         problems can you cause?
>
>         */[Piyush] It depends on how you define "never been issued",
>         which btw becomes unclear after introduction of the new text.
>         There are two interpretations/*
>
>         1)*/Certificate is not signed by the CA or/*
>
>         2)*/Certificate is not present in the database of issued
>         certificates that CA maintains./*
>
>         */One unintended consequence of first interpretation will be
>         that RPs would stop performing signature checks if their
>         responder/CA publicizes that it returns revoked for
>         "non-issued" certificates./*
>
>         */If the interpretation is 2, then this scenario is not
>         possible unless the CA is compromised./*
>
>         */[Piyush] I would say the appropriate response is good (if
>         the certificate is not marked as revoked), because that is
>         what the RP will see if it consults a CRL or a responder
>         detached from the CA. /*
>
>         */Revoked for "not issued" adds no value because the only case
>         in which an RP would send a query for a "non-issued"
>         certificate is when the CA is compromised./*
>
>         It does not make OCSP more non-deterministic. If you ask
>         status for an issued cert from a non-broken CA, nothing is
>         non-deterministic.
>
>         */[Piyush] It does not make OCSP non-deterministic but it
>         makes revocation checking non-deterministic. The goal of OCSP
>         is to address operational limitations of CRLs, not functional
>         limitations.  The fact that you'll get different answers from
>         two sources, both of which are authorized by the same CA makes
>         revocation checking non deterministic. /*
>
>         If you ask for status for a non-issued certificate, or a bad
>         certificate from a broken CA, then the result is by default
>         non-deteministic and has always been. However, choosing a
>         revoked response may save the relying party, at best, but can
>         hurt no-one
>
>         */[Piyush] I agree that a revoke response does not hurt
>         anyone. But the point is that it provides a false sense of
>         additional security to the RP without providing any. As an RP,
>         I won't trust what my responder says if the authority that
>         certified it is compromised./*
>
>         */[Piyush] /* Let's say that we still need to address this
>         scenario and revoked is the appropriate response. In that case
>
>         -The text needs to be explicit about the revocation time in
>         this situation. Revoked implies good until a certain date and
>         this distinction is important for long term archiving
>         applications. For unissued certificate the revocation time
>         should probably be set to --infinity.
>
>         -It needs to call out that in this particular scenario it is
>         addressing a functional limitation of CRLs (ability to detect
>         CA compromise) not an operational limitation.
>
>         -I think we need additional text in security considerations to
>         indicate that RP is communicating with a responder certified
>         by a compromised CA in this scenario.
>
>         /Stefan
>
>         *From: *Piyush Jain <[email-masked]
>         <mailto:[email-masked]>>
>         *Date: *Friday, October 19, 2012 7:34 PM
>         *To: *Stefan Santesson <[email-masked]
>         <mailto:[email-masked]>>, 'Peter Rybar' <[email-masked]
>         <mailto:[email-masked]>>, 'Carl Wallace'
>         <[email-masked]
>         <mailto:[email-masked]>>, 'Simon Tardell'
>         <[email-masked] <mailto:[email-masked]>>
>         *Cc: *'Peter Rybar' <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>
>         *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>             Stefan,
>
>             I think some of you interpretations below are twisted to
>             accommodate the new provisions for providing revoked
>             responses for unissued certificates.
>
>             Providing responses for expired certificates is within the
>             scope of 2560 using archive cutoff extension.
>
>             The original authors of 2560 can correct me if I'm wrong,
>             but it is my understanding that a response from OCSP
>             responder is not supposed to indicate if a certificate is
>             good or bad but to indicate if a certificate is revoked or
>             unrevoked by the issuing authority. The fact that
>             certificate is issued by the CA is checked by the RP by
>             verifying the signature on the certificate.
>
>             This draft introduces the concept of returning revoked
>             responses for unissued certificates. There are many
>             unintended consequences of this approach
>
>             -Revocation statuses become non-deterministic based on who
>             you are asking (A responder with access to CA database vs.
>             one without vs. checking status off a CRL). If I'm
>             archiving a signed document with the relevant artifacts to
>             determine the validity status of the document, this
>             becomes a huge problem. Note that a revoked status implies
>             that certificate was good between the time of its issuance
>             and that of its revocation. Any document that is signed
>             within that period should still be considered valid.
>
>             -It would confuse an implementer about what "non-issued"
>             means. The fact that the CA signed the certificate implies
>             it was issued. If a certificate is issued fraudulently,
>             based on its security practices, it is up to the CA to
>             either revoke the issued certificate, or ask its issuing
>             *From:[email-masked]
>             <mailto:[email-masked]>
>             [mailto:[email-masked]] *On Behalf Of *Stefan Santesson
>             *Sent:* Friday, October 19, 2012 7:25 AM
>             *To:* Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
>             *Cc:* 'Peter Rybar'; [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>             Peter,
>
>             An OCSP responder is by default a service providing
>             information about current certificates.
>
>             The default response you get from an OCSP responder is
>             "good" unless the cert is known to be bad or not a cert
>             the responder can provide status for.
>
>             If you need it to respond about old certificates, and as a
>             client know that the responder does this in a way that
>             suits your needs, you will need to add an extension.
>
>             *From: *Peter Rybar <[email-masked] <mailto:[email-masked]>>
>             *Date: *Friday, October 19, 2012 3:12 PM
>             *To: *'Carl Wallace' <[email-masked]
>             <mailto:[email-masked]>>, 'Simon Tardell'
>             <[email-masked] <mailto:[email-masked]>>
>             *Cc: *'Peter Rybar' <[email-masked]
>             <mailto:[email-masked]>>, Stefan Santesson
>             <[email-masked] <mailto:[email-masked]>>,
>             <[email-masked] <mailto:[email-masked]>>
>             *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>                     Well, yes, sort of. You can only be sure to
>                     validate a signature at the moment of production.
>
>                 What if the signature key was compromised at the
>                 moment of production but is not yet on a revocation list?
>
>                 [PR] According to clause 2.4  -  thisUpdate: The time
>                 at which the status being indicated is known to be correct
>
>                 It means when signature time-stamp time is X then any
>                 OCSP responses with thisUpdate time X+y are sufficient
>                 to validate because the status is correct.
>
>                     At any later point in time the signature key may
>                     be compromised, or the algorithms involved may
>                     have become to weak. (In which case the time of
>                     revocation in the OCSP response is worth nothing
>                     to you). The risk increases as time passes. And of
>                     course, the revocation information may not be kept
>                 For these archival purposes wouldn't it be better to
>                 have the final revocation list before removed due to
>                 expiry?  In any case, you'd need verification
>                 Grace period is changeable because the first OCSP
>                 response with thisUpdate time value > than time of
>                 signature time-stamp contains correct status.
>
>                     If you need to ascertain that a signature was
>                     valid at a later time, you have to trust your
>                     system that it performed the validation at the
>                     time it first received the signature. That trust
>                     must be established through some kind of mix of
>                     policies and technical measures (such as
>                     timestamping).
>
>                 In the dark corner just beyond the dark corner that is
>                 SCVP, there's a spec (RFC 5276) that defines a binding
>                 of evidence records to artifacts that can be returned
>                 viaSCVP.  This provides for timestamping.
>
>                 [PR] The validation is simplified when OCSP response
>                 with positive statement as a hash value of requested
>                 certificate is used.
>
>                 Positive statement is evidence that OCSP know the
>                 status of certificate and also protect the integrity
>                 of certificate with a new more secure hash algorithm.
>
>                 Peter Rybar
>
>
>
>                     Simon Tardell,
>
>                     Technology Nexus.
>
>                     On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Stefan,
>
>                     I have a question about the present OCSP RFC and
>                     at the end of the mail about the new situation
>                     which will happen according to your new proposal.
>
>                     The presence of the positive statement in OCSP
>                     response is important for electronic signature
>                     validations, especially for an expired
>                     certificate. Positive statement is the hash value
>                     of a certificate whose status is provided in OCSP
>                     response.
>
>                     Electronic signature validation is usually about
>                     the signatures created in the past and validated
>                     now, when the certificate is expired.
>
>                     When the certificate expires then revocation is
>                     usually removed from CRL and the revoked
>                     certificate can be provided as "good" in OCSP
>                     response.
>                     RFC must also define the value of revocationTime
>                     when the certificate which was never issued is as
>                     "revoked".
>                     Have you also covered the situation when the
>                     certificate is expired, REMOVED FROM CRL and will
>                     be provided as revoked with incorrect
>                     revocationTime e.g.with the value before or after
>                     the revocationTime which was present in the
>                     removed record from CRL?
>                     Because according to sentence in your draft
>                     ""revoked" - This state SHOULD also be returned if
>                     the responder knows that the requested certificate
>                     has never been issued." the following situation
>                     can happen: when certificate is removed from CRL
>                     after expiration and CA/OCSP responder is
>                     responsible for this certificate but have not
>                     record about expired certificate and for that
>                     "On the "revoked" state, the old spec did not even
>                     consider the case of a certificate being requested
>                     where the OCSP responder knows that the
>                     <mailto:[email-masked]>
>                     e-mail: [email-masked] <mailto:[email-masked]>
>
>
>                     From: [email-masked]
>                     <mailto:[email-masked]>
>                     [mailto:[email-masked]
>                     <mailto:[email-masked]>] On Behalf Of
>                     Stefan Santesson
>                     To: [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                     pkix mailing list [email-masked]
>                     <mailto:[email-masked]>

---

From: Simon Tardell <[email-masked]>
Date: Mon, 22 Oct 2012 16:35:21 +0200

>  If the meaning of "revoked"
[…]

>         cessationOfOperation    (5),
For the revocationTime should we use the content of notBefore field from the
> certificate ?

The certificate that was not issued could have any time. It is also not
seen by the responder. The reasonable revocationTime would be "the
beginning of time". Any time which is before any reasonable issuance time
of any certificate in the PKI would do. The issuance time of the issuing CA
would do, or for that matter the battle of Hastings.

> For the revocationReason should we use unspecified or keyCompromise ?

revocationReason must be certificateHold, since, in principle, the
certificate may be issued at a later point in time. If a key was
compromised, it would be the CA key, not the key that the certificate.

> for old implemenations, changing the meaning of "unknown" also seems to be
> a reasonable alternative.
>

Which would be putting requirements on the behavior of already existing
OCSP clients out there that we know are not true and are out of the control
of most people setting up PKIs.

Simon Tardell,
Technology Nexus.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Oct 2012 16:52:53 +0200

Simon,

You said:

"revocationReason must be certificateHold, since, in principle, the 
certificate may be issued at a later point in time".

I don't believe this is appropriate. If you have certificateHold then 
the OCSP client may make other calls later on
to check if the suspension state has finished or not.

The less controversial revocationReason is "unspecified".Let us go for 
"unspecified".

Denis

>     For the revocationTime should we use the content of notBefore
>     field from the certificate ?
>
>
> The certificate that was not issued could have any time. It is also 
> not seen by the responder. The reasonable revocationTime would be "the 
> beginning of time". Any time which is before any reasonable issuance 
> time of any certificate in the PKI would do. The issuance time of the 
> issuing CA would do, or for that matter the battle of Hastings.
>
>     Although I understand that changing the meaning of "revoked" may
>     be seen as "safer"
>     for old implemenations, changing the meaning of "unknown" also
>     seems to be a reasonable alternative.
>
>     In this case, it might be useful (and sufficient) to say that if
>     an OCSP responder is authoritative
> Which would be putting requirements on the behavior of already 
> existing OCSP clients out there that we know are not true and are out 
> of the control of most people setting up PKIs.
>
> Simon Tardell,
> Technology Nexus.
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Oct 2012 16:53:47 +0200

Ryan,

Given your argumentation, let us go for "revoked", rather than "unknown ".

However, adding a note in the draft to record why this choice was made 
might be useful.

Denis

> Though I prefer the Unknown approach today all OCSP capable browsers 
> other than Opera ignore Unknown OCSP responses.
>
> Given the arguable limited value of changing the response definitions 
> at all it seems accommodating this seems the most prudent approach.
>
> This is why the CABFORUM accepted the revoked response approach even 
> though it is not as pure.
>
> Sent from my iPhone
>
> On Oct 22, 2012, at 7:03 AM, Denis Pinkas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> To the PKIX list:
>>
>> Â Â  Without changing the meaning of "good" and of either "revoked" or
>> Â Â  "unknown", it is not possible to address the case of what is
>> Â Â Â  presently called "non-issued certificates".
>>
>> Â Â  "The "good" state indicates a positive response to the state 
>> 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 state of the certificate such as
>> Â Â  positive statement about issuance, validity, etc.
>>
>> Â Â  The "revoked" state indicates that the certificate has been revoked
>> Â Â  (either permanantly or temporarily (on hold)).
>>
>> Â Â  The "unknown" state indicates that the responder doesn't know about
>> Â Â  the certificate being requested".
>>
>>
>> Â Â  A minor change should be done to advertise that "good" may be
>> Â Â  returned when the certificate was never issued and CRLs are being
>> Â Â  used.
>>
>>
>> Â Â  "The "good" state indicates a positive response to the state 
>> 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 *(e.g. when CRLs are used by the OCSP responders)*
>> Â  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 OCSP
>> Â Â  responder regarding the state of the certificate such as *an **
>> **Â Â  indication that the OCSP responder has a direct access to the **
>> **Â Â  database of issued certificates*, validity, etc ... "
>>
>> Â Â  Then either the meaning of "rekoved" or of "unknown" needs to be
>> Â Â  changed.
>>
>> Â Â  draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and
>> Â Â  proposes to keep the meaning of "unknown" unchanged and to change
>> Â Â  the meaning of "revoked" in the following way:
>>
>> Â Â  "The "revoked" state indicates that the certificate has been revoked
>> Â Â  (either permanently or temporarily (on hold)). This state SHOULD 
>> also
>> Â Â  be returned if the responder *knows that the requested 
>> certificate has **
>> **Â Â  never been issued*. Note that the receiver of a response may 
>> have to
>> Â Â  consult out-of-band knowledge, or information in an extension 
>> defined
>> Â Â  outside of this standard, to know whether a particular responder has
>> Â Â  knowledge about whether a requested certificate has been issued or
>> Â Â  not and whether it responds "good" or "revoked" to a state request
>> Â Â  for a non-issued certificate".
>>
>> Â Â  There is a door opened for a future extension "to know whether a
>> Â Â  particular responder has knowledge about whether a requested
>> Â Â  certificate has been issued or not".
>>
>> Â Â  However, the extension proposed in 
>> Â Â  carries a slightly different meaning:
>>
>> Â Â Â Â Â  - an indication that the serial number of the target
>> Â Â Â Â Â Â Â  certificate is not present in the database,
>>
>> Â Â  "The "revoked" state indicates that the certificate has been 
>> revoked
>> Â Â  (either permanently or temporarily (on hold)).Â  This state SHOULD
>> Â Â  also be returned if the responder *has an access to the database
>> Â Â  ofÂ **issued certificates and if the serial number of the target **
>> **Â Â  certificate is not present in that database. *
>>
>> Â Â *In this case, the "revoked" state indicates either that the **
>> **Â Â  certificate has never been issued or that it has been issued 
>> but **
>> **Â Â  subsequently removed (by an attack or by accident) from the
>> Â Â  database **of issued certificates.*
>>
>> Â Â  Response extensions may be usedÂ  to convey additional information
>> Â Â  on assertions made by the OCSPÂ  responder regarding the state 
>> of the
>> Â Â  certificate such as *an **indication that the OCSP responder has
>> Â Â  a direct access to the **database of issued certificates*, 
>> validity, etc ... "
>>
>> Â Â  "The "unknown" status indicates either that the server doesn't know
>> Â Â  about the certificate being requested *or the revocation status
>> Â Â  of the certificate being requested*
>>
>> Â Â  Response extensions may be usedÂ  to convey additional information
>> Â Â  on assertions made by the OCSPÂ  responder regarding the state 
>> of the
>> Â Â  certificate such as *an **indication that the OCSP responder has
>> Â Â  a direct access to the **database of issued certificates*, 
>> validity, etc ..."
>>
>> Â Â  CertStatus ::= CHOICE {
>> Â Â Â Â Â Â  goodÂ Â Â Â Â Â Â  [0]Â Â Â Â  IMPLICIT NULL,
>> Â Â Â Â Â Â  revokedÂ Â Â Â  [1]Â Â Â Â  IMPLICIT RevokedInfo,
>> Â Â Â Â Â Â  unknownÂ Â Â Â  [2]Â Â Â Â  IMPLICIT UnknownInfo }
>>
>> Â Â  RevokedInfo ::= SEQUENCE {
>> Â Â Â Â Â Â  revocationTimeÂ Â Â Â Â Â Â Â Â Â Â Â Â GeneralizedTime,
>> Â Â Â Â Â Â  revocationReasonÂ Â Â  [0]Â Â Â Â  EXPLICIT CRLReason
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
>> OPTIONAL }
>>
>> Â Â  UnknownInfo ::= NULL
>>
>> Â Â  CRLReason ::= ENUMERATED {
>> Â Â Â Â Â Â Â  unspecifiedÂ Â Â Â Â Â Â Â Â Â Â Â  (0),
>> Â Â Â Â Â Â Â  keyCompromiseÂ Â Â Â Â Â Â Â Â Â  (1),
>> Â Â Â Â Â Â Â  cACompromiseÂ Â Â Â Â Â Â Â Â Â Â  (2),
>> Â Â Â Â Â Â Â  affiliationChangedÂ Â Â Â Â  (3),
>> Â Â Â Â Â Â Â  supersededÂ Â Â Â Â Â Â Â Â Â Â Â Â  (4),
>> Â Â Â Â Â Â Â  cessationOfOperationÂ Â Â  (5),
>> Â Â Â Â Â Â Â  certificateHoldÂ Â Â Â Â Â Â Â  (6),
>> Â Â Â Â Â Â Â Â Â Â Â Â  -- value 7 is not used
>> Â Â Â Â Â Â Â  removeFromCRLÂ Â Â Â Â Â Â Â Â Â  (8),
>> Â Â Â Â Â Â Â  privilegeWithdrawnÂ Â Â Â Â  (9),
>> Â Â Â Â Â Â Â  aACompromiseÂ Â Â Â Â Â Â Â Â Â  (10) }
>>
>>
>> For the revocationTime should we use the content of notBefore field 
>> from the certificate ?
>>
>> Although I understand that changing the meaning of "revoked" may be 
>> seen as "safer"
>> for old implemenations, changing the meaning of "unknown" also seems 
>> to be a reasonable alternative.
>>
>> In this case, it might be useful (and sufficient) to say that if an 
>> OCSP responder is authoritative
>>> To: Stefan Santesson <[email-masked] 
>>> <mailto:[email-masked]>>, 'Carl Wallace' <[email-masked]

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 22 Oct 2012 08:32:39 -0700

I'm sorry but definition of not issued is still unclear to me if you say
that that a certificate can be cryptographically bound to the CA and still
not-issued.

The ambiguity is introduced because now I can do everything that 5280 asks
me to validate a certificate and still cannot be sure if the certificate was
ever issued.

Here are the scenarios where meaning of not issued is unclear to me.

1)      A genuine certificate issued by the CA, present in the CA database

2)      A genuine certificate issued by the CA, removed from the CA database
by the CA

3)      A genuine certificate issued by the CA, removed from the CA database
by an attacker

4)      A fraudulent certificate issued by an attacker, present in the CA
database

5)      A fraudulent certificate issued by an attacker, removed from the CA
database

6)      A fraudulent certificate containing an AIA pointing to a fraudulent
OCSP responder (also cryptographically bound to the CA), issued by an
attacker, removed from the CA database.

If the CA can differentiate among these cases, it can mark the fraudulent
certificates as revoked and we won't need an overloaded definition of
not-issued. Also not that if an attacker can carry out '4' it can also carry
out '5' and '6'

The people who are convinced that this is the way to go have not addressed
the issues raised in this WG. The little extension does not hurt anyone but
it does not provide any value in general except to a few implementations
which are compromised. But it does take you down a slippery slope when you
start promising that an OCSP responder can do much more than it is supposed
to.

I don't think that it is unreasonable for a smart implementer to stop
signature checking if his responder claims that it checks issuance. 

As for the diginotor case, for some people who say that security breach
could've been detected early if this practice was in place, there is another
set of people who believe that attacker could've circumvented these measures
quite easily with the kind of access he had.

If you and other folks in the group feel that this text should be added, I
think at the minimum we also need to do the following

-          Provide explicit guidance on what the revocation time should be.
Such certificates are different from 'normal' revoked certificate and their
revocation time should probably be set to something before the validity of
issuing CA. This distinction is important for time based validations and
long term archiving applications

-          I think it will be useful to indicate in the security
considerations section, that in such a scenario, CA is compromised and that
there is a high chance that RP is interacting with a compromised responder.

Sent: Sunday, October 21, 2012 11:03 AM

In line;

 

 

 

Good.

 

/Stefan

-Piyush

/Stefan

Please see inline

 

/Stefan

Stefan,

-Piyush

 

Peter,

/Stefan

 

Peter Rybar

Simon Tardell, 

Technology Nexus.

Stefan,

...

Peter Rybar

-----Original Message-----

All,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Oct 2012 17:57:29 +0200

1-3 = issued
4-6 =not issued

Given Peter Rybar's last comment, I'm leaning to my original suggestion to
allow "unknown".

We agree that this is a poor security measure. If the worlds largest PKI
(web pki) decides to forbid the "good" response in situations where the
responder knows that it revives a request for a fraudulent certificate, then
I want to allow them that possibility.

The alternative is to force them to break OCSP.

I could live with a wording saying that a responder MAY respond "unknown" to
a request for a known fraudulent (or not never issued) cert if the responder
possess such knowledge of course..
Note that this does not have to mean that the CA is broken, is may also be
due to an error in the request from the client.

/Stefan

Date:  Monday, October 22, 2012 5:32 PM

> I¹m sorry but definition of not issued is still unclear to me if you say that
> that a certificate can be cryptographically bound to the CA and still
> not-issued.
> The ambiguity is introduced because now I can do everything that 5280 asks me
> to validate a certificate and still cannot be sure if the certificate was ever
> issued.
>  
> certificates as revoked and we won¹t need an overloaded definition of
> not-issued. Also not that if an attacker can carry out Œ4¹ it can also carry
> out Œ5¹ and Œ6¹
>  
> The people who are convinced that this is the way to go have not addressed the
> issues raised in this WG. The little extension does not hurt anyone but it
> does not provide any value in general except to a few implementations which
> are compromised. But it does take you down a slippery slope when you start
> promising that an OCSP responder can do much more than it is supposed to.
> I don¹t think that it is unreasonable for a smart implementer to stop
> could¹ve been detected early if this practice was in place, there is another
> set of people who believe that attacker could¹ve circumvented these measures
> Such certificates are different from Œnormal¹ revoked certificate and their
> issuing CA. This distinction is important for time based validations and long
> term archiving applications
> 
> has not issued, it can actually give explicit information about this using an
> extension and it can take adequate measures.
> 
>>>> I think some of you interpretations below are twisted to accommodate the
>>>> new provisions for providing revoked responses for unissued certificates.
>>>> indicate if a certificate is good or bad but to indicate if a certificate
>>>> is revoked or unrevoked by the issuing authority. The fact that certificate
>>>> is issued by the CA is checked by the RP by verifying the signature on the
>>>> certificate.
>>>>  
>>>> -          Revocation statuses become non-deterministic based on who you
>>>> are asking (A responder with access to CA database vs. one without vs.
>>>> checking status off a CRL). If I¹m archiving a signed document with the
>>>> relevant artifacts to determine the validity status of the document, this
>>>> becomes a huge problem. Note that a revoked status implies that certificate
>>>> was good between the time of its issuance and that of its revocation. Any
>>>> document that is signed within that period should still be considered
>>>> valid.
>>>> 
>>>> the responder does this in a way that suits your needs, you will need to
>>>> add an extension.
>>>> 
>>>>> verification information collected after some grace period following
>>>>> moment of production.
>>>>> 
>>>>> In the dark corner just beyond the dark corner that is SCVP, there's a
>>>>> spec (RFC 5276) that defines a binding of evidence records to artifacts
>>>>> that can be returned viaSCVP.  This provides for timestamping.
>>>>> Positive statement is evidence that OCSP know the status of certificate
>>>>> and also protect the integrity of certificate with a new more secure hash
>>>>> algorithm.
>>>>> 
>>>>>  
>>>>> Peter Rybar
>>>>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Simon Tardell,
>>>>>> 
>>>>>> Technology Nexus.
>>>>>> 
>>>>>> Electronic signature validation is usually about the signatures created
>>>>>> in the past and validated now, when the certificate is expired.
>>>>>> 
>>>>>> revocationTime e.g.with the value before or after the revocationTime
>>>>>> which was present in the removed record from CRL?
>>>>>> Because according to sentence in your draft ""revoked" - This state
>>>>>> SHOULD also be returned if the responder knows that the requested
>>>>>> certificate has never been issued." the following situation can happen:
>>>>>> when certificate is removed from CRL after expiration and CA/OCSP
>>>>>> responder is responsible for this certificate but have not record about
>>>>>> expired certificate and for that reason it is identified as "never been
>>>>>> issued".
>>>>>> 
>>>>>> ...

---

From: Simon Tardell <[email-masked]>
Date: Mon, 22 Oct 2012 18:30:41 +0200

On Mon, Oct 22, 2012 at 4:52 PM, Denis Pinkas <[email-masked]> wrote:

> I don't believe this is appropriate. If you have certificateHold then the
> OCSP client may make other calls later on

Which is entirely appropriate.  If you make a standard OCSP query the
certificate is identified with the hash of the issuer name and key and the
serial number. There is nothing that prevents a CA from later issuing a
certificate with the just-queried key. It would be unlikely, given best
practices for generating serial numbers, but still.

On the other hand, one could imagine a scenario where there is a time lag
between the issuance of the certificate and the insertion of the
certificate into the responder database (e.g. where the token hasn't been
"activated" or "acknowledged" yet and the issuer wants to prevent the token
from being used before such "activation"). If the relying party would get a
definite revocation reason code it would not (necessarily) try again once
the token has been "activated" and the certificate is valid for use and
used to generate a second signature (since it knows a definite reason code
doesn't change).

This scenario isn't as contrived as it may seem.

/Simon

The less controversial revocationReason is "unspecified". Let us go for

---

From: Simon Tardell <[email-masked]>
Date: Mon, 22 Oct 2012 18:42:38 +0200

On Mon, Oct 22, 2012 at 5:57 PM, Stefan Santesson <[email-masked]>wrote:

I could live with a wording saying that a responder MAY respond "unknown"
> to a request for a known fraudulent (or not never issued) cert if the
> responder possess such knowledge of course..
>

I think it is unfortunate to reopen this discussion now.

I suggest that we use your current text plus that, if "revoked" is used to
say "never issued/not in database", the revocationReason should be
certificateHold and that revocationTime should be set to midnight Jan 1
1950 (or some other time before the rise of PKI).

On the other hand, I think we should consider Denis' comment:

>    of
> **   of ** issued certificates and if the serial number of the target
>   * In this case, the "revoked" state indicates either that the
> **   certificate has never been issued or that it has been issued but
> **   database **of issued certificates.*
>    a direct access to the
> **   a direct access to the **database of issued certificates*, validity,
> etc ... "

It should be difficult for the responder to tell the difference by itself,
but I think, given the kind of hair-splitters we are, it is best to be as
clear as possible. ;)

/Simon

> I’m sorry but definition of not issued is still unclear to me if you say
> not-issued.****
> me to validate a certificate and still cannot be sure if the certificate
> was ever issued.****
>
> ** **
>
> Here are the scenarios where meaning of not issued is unclear to me.****
>
> ****
> 2)      A genuine certificate issued by the CA, removed from the CA
> database by the CA****
>
> 3)      A genuine certificate issued by the CA, removed from the CA
> database by an attacker****
>
> database****
> 5)      A fraudulent certificate issued by an attacker, removed from the
> CA database****
>
> 6)      A fraudulent certificate containing an AIA pointing to a
> fraudulent OCSP responder (also cryptographically bound to the CA), issued
> by an attacker, removed from the CA database.****
>
> ** **
>
> certificates as revoked and we won’t need an overloaded definition of
> not-issued. Also not that if an attacker can carry out ‘4’ it can also
> carry out ‘5’ and ‘6’****
>
> ** **
>
> to.****
> I don’t think that it is unreasonable for a smart implementer to stop
> signature checking if his responder claims that it checks issuance. ****
>
> ** **
>
> could’ve been detected early if this practice was in place, there is
> another set of people who believe that attacker could’ve circumvented these
> measures quite easily with the kind of access he had.****
>
> ** **
>
> think at the minimum we also need to do the following****
>
> -          Provide explicit guidance on what the revocation time should
> be. Such certificates are different from ‘normal’ revoked certificate and
> their revocation time should probably be set to something before the
> validity of issuing CA. This distinction is important for time based
> validations and long term archiving applications****
>
> ****
> ** **
> ** **
> *From:* Stefan Santesson [mailto:[email-masked] <[email-masked]>]
> *Sent:* Sunday, October 21, 2012 11:03 AM
> *Cc:* 'Peter Rybar'; [email-masked]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
> ** **
>
> In line;****
>
> ** **
>
> *From: *Piyush Jain <[email-masked]>
> *Date: *Sunday, October 21, 2012 7:42 PM
> *To: *Stefan Santesson <[email-masked]>, 'Peter Rybar' <[email-masked]>,
> *Cc: *'Peter Rybar' <[email-masked]>, <[email-masked]>
> *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
> ** **
>
> So what is “not-issued” - not signed by the CA or not present in CA
> database?****
>
> ** **
>
> Not issued means it has never been issued. What's unclear about that?****
>
> ** **
>
> Of course it is not present in the database if it is not issued.****
>
> been deleted, then you don't know that it has never been issued and can't
> reply revoked.****
>
> ** **
>
> ** **
>
> to check issuance. Isn’t it a fair conclusion that I do not need to perform
> signature checks if the responder can check issuance for me?****
>
> ** **
>
> No that is not a fair conclusion. These are entirely different things.****
>
> ** **
>
>  ****
>
> responder ’knows’ that requested certificate has never been issued. ****
>
> case what the responder responds with does not matter.****
>
>  ****
>
> ** **
>
> little extension that hurst no-one, they don't have to.****
>
> ** **
>
> I’ve no problem with your proposal to respond with ‘revoked’ in this
> situation.****
>
> ** **
>
> Good.****
>
> ** **
>
> I’ve fundamental problem with the introduction of ‘non-issued’ concept in
> scenario without actually providing any.****
>
> ** **
>
> It provides some, but not much. People keep coming back to that fact that
> if this had been the practice of Diginotar, the security breach would have
> been discovered a lot earlier. So there might be some gain with no pain.**
> **
>
> ** **
>
> might actually be increasingly valuable.****
>
> If an OCSP responder starts receiving status requests for certs it knows
> it has not issued, it can actually give explicit information about this
> using an extension and it can take adequate measures.****
>
> Either good + extension or revoked+extension.****
>
> ** **
>
> concept of "non-issued" certs. It merely allows an OCSP responder to
> respond to such request.****
>
> ** **
>
>  ****
>
> It’ll be very helpful if I can see at least one practical scenario where
> this additional text would add value.****
>
> ** **
>
> Stated in my previous comments.****
>
> ** **
>
> /Stefan****
>
> ** **
>
>  ****
>
> -Piyush****
>
> *From:* Stefan Santesson [mailto:[email-masked] <[email-masked]>]
> *Cc:* 'Peter Rybar'; [email-masked]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> I don't think the "not issued" is unclear.****
>
>  ****
>
> "knows" that the requested certificate has never been issued.****
>
> responder knows this, it can't choose this option and has to reply "good".
> ****
>
>  ****
>
> It does not make revocation checking non-deterministric. ****
>
> to be revoked, but it may never have been issued).****
>
> cert. The old exact semantics was "the cert IS revoked". The new semantic
> is "the cert is revoked or possibly might never been issued"****
>
>  ****
>
> deterministic than the good, response.****
>
>  ****
>
> So, I still don't see any practical problems here.****
>
>  ****
>
> /Stefan****
>
>  ****
>
>  ****
>
> *From: *Piyush Jain <[email-masked]>
> *To: *Stefan Santesson <[email-masked]>, 'Peter Rybar' <[email-masked]>,
> *Cc: *'Peter Rybar' <[email-masked]>, <[email-masked]>
> *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> Please see inline****
>
>  ****
>
> *From:* Stefan Santesson [mailto:[email-masked] <[email-masked]>]
> *Cc:* 'Peter Rybar'; [email-masked]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> I'm sorry. I fail to the any of the problems you raise.****
>
>  ****
>
> issued, and you choose to reply revoked, what problems can you cause?****
>
> *[Piyush] It depends on how you define “never been issued”, which btw
> becomes unclear after introduction of the new text. There are two
> interpretations*****
>
> 1)      *Certificate is not signed by the CA or*****
>
> 2)      *Certificate is not present in the database of issued
> certificates that CA maintains.*****
>
> *One unintended consequence of first interpretation will be that RPs
> would stop performing signature checks if their responder/CA publicizes
> that it returns revoked for “non-issued” certificates.*****
>
> *If the interpretation is 2, then this scenario is not possible unless
> the CA is compromised.*****
>
>  ****
>
> What in your mind is a more appropriate response?****
>
> *[Piyush] I would say the appropriate response is good (if the
> certificate is not marked as revoked), because that is what the RP will see
> if it consults a CRL or a responder detached from the CA. *****
>
> *Revoked for “not issued” adds no value because the only case in which an
> RP would send a query for a “non-issued” certificate is when the CA is
> compromised.*****
>
>  ****
>
> issued cert from a non-broken CA, nothing is non-deterministic.****
>
> *[Piyush] It does not make OCSP non-deterministic but it makes revocation
> limitations of CRLs, not functional limitations.  The fact that you’ll get
> different answers from two sources, both of which are authorized by the
> same CA makes revocation checking non deterministic. *****
>
>  ****
>
> party, at best, but can hurt no-one****
>
> *[Piyush] I agree that a revoke response does not hurt anyone. But the
> point is that it provides a false sense of additional security to the RP
> without providing any. As an RP, I won’t trust what my responder says if
> the authority that certified it is compromised.*****
>
>  ****
>
> What is your problem on the practical ground.****
>
> *[Piyush] * Let’s say that we still need to address this scenario and
> revoked is the appropriate response. In that case****
>
> -          The text needs to be explicit about the revocation time in
> this situation. Revoked implies good until a certain date and this
> distinction is important for long term archiving applications. For unissued
> certificate the revocation time should probably be set to –infinity.****
>
> addressing a functional limitation of CRLs (ability to detect CA
> compromise) not an operational limitation.****
>
> compromised CA in this scenario.****
>
>  ****
>
>  ****
>
> /Stefan****
>
>  ****
>
> *From: *Piyush Jain <[email-masked]>
> *To: *Stefan Santesson <[email-masked]>, 'Peter Rybar' <[email-masked]>,
> *Cc: *'Peter Rybar' <[email-masked]>, <[email-masked]>
> *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> Stefan,****
>
>  ****
>
> new provisions for providing revoked responses for unissued certificates.*
> ***
>
> using archive cutoff extension.****
>
>  ****
>
> The original authors of 2560 can correct me if I’m wrong, but it is my
> certificate.****
>  ****
> approach****
> checking status off a CRL). If I’m archiving a signed document with the
> document that is signed within that period should still be considered valid.
> ****
>
> -          It would confuse an implementer about what “non-issued” means.
> authority to revoke its own certificate.****
>
>  ****
>
> -Piyush****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Stefan Santesson
> *Cc:* 'Peter Rybar'; [email-masked]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> Peter,****
>
>  ****
>
> current certificates.****
>
> ****
>  ****
> If you need it to respond about old certificates, and as a client know
> that the responder does this in a way that suits your needs, you will need
> to add an extension.****
>
> Such extension will not be part of the rfc256bis effort.****
>
>  ****
>
> Is there any text in the current draft that you think is unclear on this?*
> ***
>
>  ****
>
> /Stefan****
>
>  ****
>
>  ****
>
> *From: *Peter Rybar <[email-masked]>
> *To: *'Carl Wallace' <[email-masked]>, 'Simon Tardell' <
> [email-masked]>
> *Cc: *'Peter Rybar' <[email-masked]>, Stefan Santesson <
> [email-masked]>, <[email-masked]>
> *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> moment of production. ****
>
>  ****
>
> is not yet on a revocation list?****
>
> being indicated is known to be correct****
>
> correct. ****
> Y is in the interval <0, producedAt - X>****
>
>  ****
>
> be kept around after the expiry of the certificate. ****
>
>  ****
>
> That's why you should validate signatures as soon as possible. ****
>
>  ****
>
> of production.****
> [PR] Grace period is not a fixed value of the time interval. ****
>
> time value > than time of signature time-stamp contains correct status.***
> *
>
>  ****
>
>  ****
>
> kind of mix of policies and technical measures (such as timestamping).****
>
>  ****
>
> that can be returned viaSCVP.  This provides for timestamping.  ****
>
> statement as a hash value of requested certificate is used.****
>
> algorithm.****
>  ****
> Peter Rybar****
>  ****
> Simon Tardell, ****
> Technology Nexus.****
> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <[email-masked]> wrote:****
>
> Stefan,
>
> As you have mentioned in the mail:****
>
> certificate was never issued."****
>
> obtained."****
> e-mail: [email-masked]****
>
>
> https://www.ietf.org/mailman/listinfo/pkix****
>
>  ****
>
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix****
>
>

---

From: [email-masked] (Martin Rex)
Date: Mon, 22 Oct 2012 23:53:19 +0200 (CEST)

Simon Tardell wrote:
>
> I suggest that we use your current text plus that, if "revoked" is used
> to say "never issued/not in database", the revocationReason should be

I support the "revoked, ReasonCode=CertificateHold" for OCSP responders
that can not find proof/indication that the cert in question was properly
issued.

The CertificateHold reason code is vitally important, because otherwise
the CA would have to keep track of OCSP responses given out from the
CA's OCSP responder that declared a serial as "permanently revoked"
in order to ensure that the CA will never issue a cert with that serial
in the future.  Looks like an unnecessary and easily avoidable burden to me.

I don't like the particular date Jan 1, 1950, for safety, a date >= 1970
ought to be chosen (so that it does not get negative when converted
to time_t, which has potential to confuse some code).

And since the timestamp is a GeneralizedTime, the date ought to be
given in exactly that format, e.g.  "700101010101Z"

What also should be noted is that the optional OCSP SingleResponseExtension
"CrlID" must not be used when this "not issued" certificate was not
conveyed through a CRL--and there currently is no means to convey
proof-of-cert-existence through CRLs unless they're revoked, and in the
latter case there would be no "not issued" OCSP response to convey.

> *Saying that the certificate has not been issued is not fully appropriate.*

I believe it is very inappropriate for the spec to make any assumptions
about why exactly the OCSP responder believes that a cert (serial) has not
ever been issued.  The reason can be manyfold.  Besides an accidental or
fraudulent deletion (attack), it may be something as simple as a
database software bug.

What we might want to say is that failures to access the database
of issued certs ought to result in an unknown rather than revoked
OCSP response.

The records of issuance, that the OCSP responder has access to,
need not contain the whole certificate.  The information may be
limited to serial numbers of issued certificates, and it SHOULD
include a hash of the cert (at least SHA-1, preferably SHA-256 as well).
In particular, the OCSP responder may not have access to the
validity of issued certs or any other certificate characteristics or
certificate attributes.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Oct 2012 00:19:04 +0200

Martin,

What you say here makes sense to me.

I do in particular support the 1 jan 1970 time as it is the time zero
point for may Date formats.

/Stefan

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Oct 2012 09:07:04 +0200

Bonjour,

> that can not find proof/indication that the cert in question was properly

I don't think it's wise to use one reason code to cover two reasons.
The latest CAs we deployed want to have certificates issued in a
suspended state until the smartcard has been delivered, whence
"certificateHold" reason code, with CRLs filled in that way. For these
CAs, an OCSP responder will respond "certificateHold" for legitimate
certificates, and you're proposing to also reply "certificateHold" for
random serial numbers.

> in the future.  Looks like an unnecessary and easily avoidable burden to me.

This is why I don't think that declaring an unknown and potentially
random serial number as revoked is good. Nor useful.
An attacker will most likely intercept communications with the
responder and reply something like "unauthorized", or any unsigned
error code.

> latter case there would be no "not issued" OCSP response to convey.

See, by declaring a non-issued certificate as revoked, you're asking
the CA to lie about its revocation date and declare it's not been
issued in a CRL. How can it be right?

> fraudulent deletion (attack), it may be something as simple as a

Or invalid encoding in client, or wrong issuerKeyHash (the serial
exists, but for another CA), or random serial, or specially crafted
numbers, or unrecognized hash function, ... All these cases have been
spotted on our responders, and we haven't wrongly issued certificates.

-- 
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 09:31:25 +0200 (CEST)

Erwann Abalea wrote:
> 
> Martin Rex <[email-masked]>:
>>
>> Simon Tardell wrote:
>>>

CertificateHold is EXACTLY the correct ReasonCode:
It indicates that the CA has not issued a cert with the given serial
*YET*, but it MAY eventually issue such a cert in the future
(sometimes even in the _very_next_future_ ... i.e. it is about
 to become visible to the OCSP responder, but not visible yet).

> responder and reply something like "unauthorized", or any unsigned

This rationale is a non-sequitur.

An attacker can substitute any response with any kind of error.
Or make the DNS lookup of the OCSP responder fail, or insert
a ICMP error or TCP on the connection attempt to the OCSP responder.

The purpose of the change here is to have the proper OCSP responder
return completely useless responses in a situation where the OCSP
responder has access to the CA issue logs and can determine that
the cert in the request has not been issued (yet).

> issued in a CRL. How can it be right?

You're absolutely NOT lying at all.  The cert with that serial has
not been issued yet, but a cert with that cert may get issued in the
future.  The CertificateHold is perfectly appropriate to describe
this situation.

> spotted on our responders, and we haven't wrongly issued certificates.

I was saying that the spec should advise against OCSP response recipients
to draw conclusions (about causes), and take the response as what it is,
a description of state, *NOT* an indicator of any precice cause.

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Oct 2012 11:58:57 +0200

Martin,

Erwann said:

"I don't think it's wise to use one reason code to cover two reasons.

random serial numbers".

You said:

"CertificateHold is EXACTLY the correct ReasonCode:
It indicates that the CA has not issued a cert with the given serial
*YET*, but it MAY eventually issue such a cert in the future
(sometimes even in the_very_next_future_  ... i.e. it is about
  to become visible to the OCSP responder, but not visible yet)".

I am sorry, but I agree with Erwann and thus I disagree with you.

The certificateHold state was not created to have certificates issued
in a suspended state. It was created to allow a user to suspend its certificates
rather than revoking its certificates, in case a smart card was temporarily lost and
since after a revocation it may take a while to get a new smart card.

Some people, then used also the certificateHold state to have certificates issued
in a suspended state. This is legitimate since it complies with the semantics of
the certificateHold state.

We should not change/overload the meaning of CertificateHold.
.
Denis

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 12:17:25 +0200 (CEST)

Denis Pinkas wrote:
> in a suspended state. It was created to allow a user to suspend its
> certificates rather than revoking its certificates, in case a smart
> card was temporarily lost and since after a revocation it may take
> a while to get a new smart card.
> 
> Some people, then used also the certificateHold state to have
> certificates issued in a suspended state. This is legitimate since
> it complies with the semantics of the certificateHold state.
> 

The purpose of the CertificateHold is to convey from the CA to the RP
"you should not currently trust the certificate with this serial,
because it is not certain that the entity which is currently
in control of the associated private key is actually the entity
which the cert says it is." 

When an OCSP responder has access to the certificate issue logs,
and does not find proof that a requested serial was issued,
then the message it wants to convey to the RP is
"you should not currently trust the certificate with this serial,
because it is not certain that the entity which is currently
in control of the associated private key is actually the entity
which the cert says it is."

So we are *NOT* changing nor overloading the semantics of CertificateHold
_at_all_ with this expanded definition !

-Martin

"

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Oct 2012 12:18:19 +0200

2012/10/23 Martin Rex <[email-masked]>

>  to become visible to the OCSP responder, but not visible yet).

No. It indicates that the corresponding (existent) certificate has been put
on hold.
You're asking the CA to assert a status for a non-existent certificate.

What's next? Ask CAs to sign the next OCSP response with a "removeFromCRL"
code for dumb serial numbers for which they replied "certificateHold"? Why
not also add a holdInstructionCode extension to the OCSP response, and
define proper codes?

The number of bogus requests far outweighs the number of bad certificates.
In our case, as a public CA, it even outweighs the number of good public
certificates we produced.

Asking for a signed response to a bogus request gives anonymous attackers
much power. Consider big CAs that receive billions of OCSP requests a week,
or even a day (that's reality). Do you really consider that asking for
billions of signatures a day for bogus requests, asserting an authoritative
status for nonexistent certificate is the right thing to do?

With my "CA" hat, I see that OCSP is a hidden cost, and you want to make it
more costly.
With my "user" hat, I see that revocation checks are not properly done,
pressure is put on certificate issuers but if relying parties don't do
their job it's useless.
The two added together will just build something more costly but still
useless.

> This rationale is a non-sequitur.

No sophism here. My point is that I don't think the problem is correctly
addressed.

> a ICMP error or TCP on the connection attempt to the OCSP responder.

Correct. And? Whatever you ask the CA to do, the attacker can avoid it.
Wrong end of the problem.

> future.  The CertificateHold is perfectly appropriate to describe

The OCSP request doesn't match an existent certificate, yet you want the CA
to declare it as revoked, discuss about the correct revocation reason to
use, and a correct revocation date. But this response is not a lie.
Something's wrong.

> a description of state, *NOT* an indicator of any precice cause.

That's the good end of the problem.

-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Oct 2012 12:27:58 +0200

> which the cert says it is."

RFC5280 doesn't say anything about the meaning of revocation reason codes.
X.509 do, in 8.5.2.2:
"A certificate may be placed on hold by issuing a CRL entry with a reason
code of certificateHold. The certificate hold
notice may include an optional hold instruction code to convey additional
information to certificate users (see 8.5.2.3)."

-- 
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 12:38:29 +0200 (CEST)

> You're asking the CA to assert a status for a non-existent certificate.

Where exactly does X.509 or PKIX require that a serial on a CRL
will have to refer to an existing cert, i.e. one that the CA has
positive proof to have issued.  I (now) believe this is a completely
flawed assumption.

CRLs and OCSP only assert a state to a certificate serial.
Infering about existance/noexistance of certs is a logical fallacy.

> not also add a holdInstructionCode extension to the OCSP response, and

removeFromCRL doesn't make sense in an OCSP response, because OCSP does
not hand out CRLs. 

> With my "CA" hat, I see that OCSP is a hidden cost, and you want to make it

Having an OCSP responder look at cert issuance logs and produce an
intelligible, risk-reducing response rather that an entirely useless
response will be a completely optional feature!

Nobody is pushing *YOU* to have your OCSP responder adopt this.

But why are you so obsessed in denying others that possibility?

If you're concerned about the load of creating signatures
for "not issued" requests, you may want to talk to Denis first,
who proposed to create signatures on errors, and in particular on
"not authorized" errors (which includes requests for status of
certs from other CAs).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 12:50:23 +0200 (CEST)

> information to certificate users (see 8.5.2.3)."

Now you're kidding me.

We're talking about the semantics of the "certificateHold" status.
A protocol element without semantics would be utterly useless.

And the text that you quote gives a STRONG HINT that this status
was intended to have a rather broad meaning, and not only the
narrow meaning of two specific usage cases that you mentioned
(token lost, or new token in the mail).

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Oct 2012 13:24:55 +0200

> positive proof to have issued.  I (now) believe this is a completely

X.509, 7.3
revokedCertificates identifies certificates that have been revoked. The
revoked certificates are identified by their serial
numbers.

CRL as in "Certificate Revocation List", not as in "inexistent Certificate
Revocation List".
Fraudulently producing certificates is bad, but producing a CRL for
nonexistent certificate is good?

> Infering about existance/noexistance of certs is a logical fallacy.

The certificate is identified by its serial number (along with its issuer
name, of course). What is the meaning/value of a serial number that doesn't
identify anything?

> removeFromCRL doesn't make sense in an OCSP response, because OCSP does

But holdInstructionCode could make sense, right?

> "not authorized" errors (which includes requests for status of

I apologize if I offended you, I'm not pointing at you personally, just
replying to the thread. I choose an anchor and it was one of your posts,
nothing more.

I have nothing against a "positive assertion", maybe the hash of the
certificate for which the responder produces a good answer. If the
responder can have access to an issuance log and pick useful authoritative
information from it and optionally deliver it with the response, I'm fine.
Asking for a signed response from a bogus request is different. The thread
then slept into producing a revoked response for bogus requests, and
discussing about what could a plausible reason code and revocation date be.

I believe that a well-behaving CA shouldn't produce a CRL containing random
serial numbers provided by anonymous requesters.
By extension, I believe that a well-behaving OCSP responder shouldn't
assert anything authoritative (either good or revoked) about a random
serial number. That's a fail for the "good" response because an OCSP
responder can be based on a blacklist, I don't think that changing "good"
into "revoked" is the right way to solve this problem.

-- 
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 15:41:21 +0200 (CEST)

Erwann Abalea wrote:
> Martin Rex <[email-masked]> wrote:
>> 
>> Erwann Abalea wrote:
>> > No. It indicates that the corresponding (existent) certificate has been
>> > put on hold.

It uses serial numbers (and an implied isser name) to identify
certificates in order for disambiguation.
This is not a requirement that the serial refers to a cert that the
CA has positive proof to have consciously issued/signed with its key.

> nonexistent certificate is good?

Unconvincing.

The C is to clarify that the CRL does not revoke Apples and neither
Oranges, but Certificates.  And in order to disambiguate between
certs issued by the same CA, the list identifies/disambiguates
certs by their serial number.

You're arguing here that DigiNotar was "breaking" the OCSP protocol
and hurting RPs when they decided to respond "revoked" to requests
for certs for which they had no record of issuance.  I believe
it was perfectly reasonable, fully conforming and actively
helping RPs.
 
Do you realize that X.509 defines a "Revoked Group of certificates"
crlExtension, with a "serialNumberRange" options.  There is *NO* requirement
that the CA has positively created/issued all certs within the range
before it can use that extension.  So the idea that a CRL can contain
revocations for certs for which the CA does not have records of
issuance is already part of X.509 08/2005!

Distinguishing why in particular a specific serial in not on the
cert isse record (accidentally lost, fraudulently deleted,
created by a precomputed hash collision, whathaveyou) would
be splitting hairs over a total non-issue.

> name, of course). What is the meaning/value of a serial number that doesn't

When an RP sends an OCSP with a particular serial, then the OCSP responder
has to assume that the OCSP requestor is serious about his request
and is actually looking at a *REAL* certificate.  So it is perfectly valid
and reasonable for the OCSP responder to refer to that cert from the
request by the very same serial and return a "revoked, certificateHold"
status when it can not find this serial on the certificate issue logs.

> But holdInstructionCode could make sense, right?

If you ignore for a moment that holdInstructionCode was removed
from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject
is another STRONG hint that certificateHold was defined intentionally
with a very broad scope, even though certificateHold at early stages
might have been motivated by a few, very specific use cases.

Sensible protocol designers will try to provide an abstraction for
initial use cases in order to remain open and easily extensible
for related usage scenarios in the future.  Having to retrofit
agility into a protocol can otherwise be very painful.

And while the original 3 basic CertStatus { good, revoked, unknown }
were evidently short-sighted, the CRLEntry ReasonCode "certificateHold"
does not suffer from such a limitiation - YMMV.

> 
>>>
>>> With my "CA" hat, I see that OCSP is a hidden cost, and you want to make
>>> it more costly.
> 

Personally, I consider the original OCSP design, where the RP
rather than the certified entity obtains the OCSP response,
a fairly useless protocol for online authentication.

With the TLS multiple-OCSP-stapling extension, where the cert bearer
can obtain&refresh the OCSP responses for his own cert chain
out-of-band, OCSP may become an alternative to CRL processing.

> serial numbers provided by anonymous requesters.

A "CRL request" is a simple download request.  The RP does not convey
any serials to the CA, and given the serial number space of 160 bits,
it would be unfeasible for the CA to guess what cert serials an RP,
who has just requested download of a CRL, is going to check between
now an the next periodical CRL download.

> into "revoked" is the right way to solve this problem.

A well-behaving OCSP responder is one that does not let RPs fall for
fraudulent certs when it knows pretty damn well that the cert that
the RP is requesting the status, for can not possibly be a bona fide
certificate.   An OCSP responder that lets RPs down so recklessly
does not count as trustworthy on my scorecard. (Bad dog, no cookie).

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 23 Oct 2012 08:11:07 -0700

> fraudulent certs when it knows pretty damn well that the cert that the RP
is
> requesting the status, for can not possibly be a bona fide

This is the unintended consequence that I was talking about earlier. People
will actually start believing that OCSP responders certified by a
compromised CA are trustworthy and authoritative if these responders issue
revoked for fraudulent certificates. 

Martin - If the RP does not check that the payload certificate is bound to
the issuing CA, OCSP response is meaningless. And if the payload certificate
is cryptographically bound to the CA, and CA thinks it is not issued then
the CA and as a result OCSP responder certified by the CA are compromised
and hence not trustworthy.

Not saying that OCSP responder should return revoked in this case, but if it
does the, right reason code should be CACompromised. After all such a
certificate could only be issued (or shall I say non-issued) if the CA is
compromised.

-Piyush

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Oct 2012 20:40:08 +0200

> CA has positive proof to have consciously issued/signed with its key.

We disagree here, clearly.

> it was perfectly reasonable, fully conforming and actively

Wrong trial. I'm not arguing that DigiNotar broke anything by responding
"revoked" for existent certificates that shouldn't have been produced. I'm
arguing that responding "revoked" for a non existent certificate (that's
different that a "wrongly issued certificate unknown to the CA") cannot be
a CA responsibility.

> issuance is already part of X.509 08/2005!

Yes. But who uses that?
Public CAs are required to introduce entropy in the certificate serial
number to defeat prefix-chosen collisions, so the serial number of a
certificate is not sequential anymore.

> be splitting hairs over a total non-issue.

I'm not arguing about the reason a certificate isn't known to the CA, but
on existent vs non-existent (really non-existent) certificates.

> status when it can not find this serial on the certificate issue logs.

Really? Do you have access to a real world OCSP responder? You'll find real
dumb things in the logs.
In no particular order:
 - wrong encoding: a '+' gets changed into a "%20" probably because it got
changed into a " " somewhere in the middle
 - wrong encoding: somewhere in the request you'll find data probably
coming from heap/stack corruption (part of environment, or other things)
 - unused URI elements: after the GET request you can find a '?' with a
query string
 - requests for a real certificate serial number but issued to another CA
served by the same OCSP platform (mixed issuer*Hash+serialNumber)
 - requests for a serial number close from a real one, differing only by a
few bits; this raised alarms, required a complete audit of the issuing
platform including authenticated logs, without any result
 - crafted requests with a lot of "/", or a lot of "A" in the base64
encoding, because it's a non authenticated web server, and surely an
attractive target
 - good requests with additional bytes after them, probably some bad use of
strlen() or similar function
 - requests with an unsupported hash algorithm, resulting into a
non-existent issuer*Hash+serialNumber combination, yet the responder has to
reply something; since july I can see some requests with GOST R34.11, all
improperly encoded

You find reasonable to assume that whatever is requested by any
unauthenticated RP corresponds to a real certificate and is a correctly
formed request. That's a wrong assumption and is contradicted by real
world. Yet, additional pressure is put on OCSP producers, not on OCSP
consumers.

> > > > code for dumb serial numbers for which they replied
> "certificateHold"?
> > > Why

Reading X.509 11/2008 shows that holdInstructionCode hasn't been removed,
and isn't declared as deprecated. The description of this extension has
been the same since the 08/1997 edition.
I don't know what motivated the removal of this extension in RFC5280, as
it's not even deprecated. Same as privateKeyUsagePeriod. Do RFC5280
consider these extensions as non existent? (a real question)
id-holdinstruction-reject is still declared (in the ASN.1 module), and it
defined a RP behavior to adopt. It's logical to consider that rejecting a
certificates revoked with reason "certificateHold" is a valid behavior. But
that doesn't say that "certificateHold" can be used for whatever reason you
might find useful, and especially not to declare non-existent (really
non-existent) certificates as revoked.

> a fairly useless protocol for online authentication.

I see OCSP as a light CRL. The OCSP thisUpdate/nextUpdate have the same
semantic as the CRL lastUpdate/nextUpdate, "good" can be a valid response
for non-existent certificates.
That's unfortunate, I agree. RFC5019 adds some balance, distributing good
practice between OCSP responders and RP.

> out-of-band, OCSP may become an alternative to CRL processing.

OCSP stapling with a blacklist based OCSP suffers the same problem. I'm not
saying that multi-stapling isn't to be pushed.

> now an the next periodical CRL download.

My point was that a CRL is a signed object, a commitment from the
Authority. And the Authority shouldn't declare things on identities it
doesn't know about. A CRL is supposed to revoke known certificates, each
with a correct revocation date (and not something set at epoch 0, you can't
play with revocation dates at will), and possibly with a correct reason and
other extensions.

> does not count as trustworthy on my scorecard. (Bad dog, no cookie).

We agree on this point, a well-behaving OCSP responder shouldn't declare
that a non-existent certificate is valid.
A difference lies in the "non-existent":
 - the serial number really corresponds to a non-existent certificate (even
with a perfect CA, such requests will exist)
 - the serial number corresponds to an existent certificate unknown to the
CA

Case 1 is MUCH more frequent. Case 2 is dangerous (DigiNotar, etc).
The OCSP responder cannot distinguish between the two.
For me, asking for the OCSP responder (often the CA itself) to declare than
a non-existent certificate (Case 1) is revoked is a bad practice, and it
even doesn't solve the problem.
Asking for OCSP responders to add something to "good" responses proving
they have access to a list of issued certificates (like the hash of the
certificate) is a better way to solve the problem. It must be backed-up
with rules or recommendations applied to RP to avoid a fallback to CRLs.

-- 
Erwann.

---

From: Peter Rybar <[email-masked]>
Date: Mon, 22 Oct 2012 14:38:38 +0200

Stefan,

You have defined in draft that certificate identified with correct (hash of
issuer name, hash of  issuer key) and with unknown cert serial number xyz
is revoked.
Correct response must also contains the value of item revocationTime.

Do you know the correct value of  revocationTime in situation which you
have described?
...
revoked     [1]     IMPLICIT RevokedInfo,
...

> to add an extension.
> To: 'Carl Wallace' <[email-masked]>, 'Simon Tardell' <
> [email-masked]>
>
> Cc: 'Peter Rybar' <[email-masked]>, Stefan Santesson <

---

From: [email-masked] (Martin Rex)
Date: Wed, 24 Oct 2012 20:10:16 +0200 (CEST)

> We disagree here, clearly.

OK. I don't see any convergence.  Let's agree that we disagree.

> 
> > > CRL as in "Certificate Revocation List", not as in "inexistent
> > > Certificate Revocation List".

Once Diginotar realized that they may be fraudulent certs around
of which they have no records of issuance, they very probably started
replying "revoked" for *ANY* serial number not in their records,
and did not require anyone to demonstrate to them that the certificate
with that serial really exists.  Safety first.

> > issuance is already part of X.509 08/2005!

That doesn't matter.  It was just to show you that the spec itself
does not require any certs that appear on a CRL to have actually
ever been issued -- just that they're unambiguously identified.

> certificate is not sequential anymore.

Maybe you completely misunderstood that requirement.
(btw. this is neither a PKIX nor an X.509 requirement).

The CA /Browser Forum Baseline Requirements v1.1 (14-Sep-2012)
https://www.cabforum.org/Baseline_Requirements_V1_1.pdf

  9.6 Certificate Serial Number

  CAs SHOULD generate non-sequential Certificate serial numbers
  that exhibit at least 20 bits of entropy

Non-sequential only means that when a CA issues certs (#n1) and (#n2)
with serial (sn1) and (sn2) and n2 = n1+1 then sn2 = sn1+1 should not apply.

It is, however, perfectly permissible and perfectly sensible that
for n2 > n1  sn2 > sn1 still applies so that ranges will still work,
i.e. to compose a SerialNumber (which is up to 160 bits), from a
strictly monotonically increasing part at the beginning, followed
by a cryptographically random part of at least 20 bits

(Personally, I would use more like 64 random bits, but I also don't
run large CAs that issue millions of certs -- because the size of
the serial significantly impacts the size of the CRLs.  Looking
at one of the CRLs issued by one of the US DOD CAs with more than
one million entries, the cert serials are 3 bytes...).

> on existent vs non-existent (really non-existent) certificates.

You _are_ splitting hairs.  How would a CA (and its OCSP server) distinguish
certs that are not on record as ever being issued from certs that
are not on record as ever being issued?

> Really? Do you have access to a real world OCSP responder?

I don't use OCSP at all.  We're doing online authentication on
large servers, so OCSP, as it currently exists, is a total non-starter.
We do not even implement it.

The TLS extension for stapling multiple OCSP-response might become a
reason to revisit this decision.

> You'll find real dumb things in the logs.

Please don't tell me that this surprised you.  That had to be expected!
And that MUST NOT cause problems.  If a request is for a CA/issuer name
which the OCSP server is not authoritative for, then an unsigned "unknown"
response is just fine.  OCSP doesn't have the "recursion requested"
flag that DNS has.  (Well, unless you count the not well thought out
idea of a universal local OCSP responder).

The only thing that is a real (OCSP) design flaw is the idea that each and
every RP doing online authentication would perform OCSP requests.
That scales nowhere and was obvious from the beginning.

Switching from 1024-bit to 2048-bit RSA keys is probably going to
hit OCSP servers pretty hard (because of the 6x larger CPU-cycles
for the signature operation).

> world. Yet, additional pressure is put on OCSP producers, not on OCSP

The operational paradigm of the OCSP protocol specified in rfc2560 
is that OCSP server MUST assume that the client is honest and
serious about his request.

A model where only the certificate holder performs OCSP requests for
his forward cert chain (as with the TLS extension for stapling
multiple OCSP responses) has the advantage that any such cert
holder could use this very certificate to sign the OCSP request --
in case the OCSP server wants some means to recognize requests
from clients that "have paid their due...".

> been the same since the 08/1997 edition.

X.509 08/2005 page 36: Section 8.5.2.3 Hold instruction code extension
   [...]
   This extension is always non-critical. No standard hold instruction
   codes are defined in this Directory Specification.

X.509 11/2008 page 37: Section 8.5.2.3 Hold instruction code extension

   This extension is always non-critical. No standard hold instruction
   codes are defined in this Directory Specification.

To me, that statement "No standard hold instruction codes are defined
in this Directory Specification." very much says that this feature
was removed from the standard (i.e. is no longer part of the spec).

>
> I don't know what motivated the removal of this extension in RFC5280,

Maybe there are others who understand the X.509 change the way I do?

>
> But that doesn't say that "certificateHold" can be used for whatever
> reason you might find useful, and especially not to declare non-existent
> (really non-existent) certificates as revoked.

That is non-sense.  No CA needs *your* permission to put whatever
serial it likes on its CRL.  That is entirely up to the discretion
of the CA.  There is no requirement in X.509 and PKIX that such
a serial refers to a cert that a CA has positive proof about
ever having issued.  And this is also entirely irrelevant for the
proper operation/function of the protocol.

> practice between OCSP responders and RP.

OCSP isn't all flawed.  What is definitely flawed is the distribution
scheme for OCSP responses (RPs instead of certificate holders),
and the scheme for identifying authorized OCSP responders
(through information in the EE cert, rather than through a
 seperate key/chain hardwired into the CA cert), because the
current OCSP model breaks completely for a CA compromise
(which is a real pity!).

> 
>>> I believe that a well-behaving CA shouldn't produce a CRL containing
>>> random serial numbers provided by anonymous requesters.
>>
> doesn't know about.

A **certificate** is a declaration (signed by the CA) about other
identities.

A CRL entry and an OCSP response are different, identifying only
a serial plus an optional issuer/CA name.  Therefore a revocation
of a serial does not declare things on identities it doesn't know
about -- on the contrary -- it is actually a refusal of the CA
to declare things on identities it doesn't know about.

A CA's OCSP responder who _has_ accessed to the logs of issued
certs, and which does _not_ reply "revoked,certificateHold" on
a serial that it does not find in the CA's issue logs,
is _actively_ declaring things about identities as valid
that it doesn't know about!  So you've actually bitten yourself
in the tail with that statement above.  ;-)

>
> A CRL is supposed to revoke known certificates, each
> with a correct revocation date (and not something set at epoch 0,
> you can't play with revocation dates at will), and possibly with
> a correct reason and other extensions.

The revocation dates for serials that refer to "issued certs" on CRLs are
subject to the CA's Certificate practice statement (CPS), but I'm not
currently aware of any requirements by the specs.

For serials of certs that the CA can no identify as having issued,
the CPS does not apply, so anything goes.

>  - the serial number really corresponds to a non-existent certificate
>    (even with a perfect CA, such requests will exist)
>  - the serial number corresponds to an existent certificate unknown
>    to the CA
> 

Case 2 is dangerous because of the
"Can't happen -- nuke the whole PKI if it happens" approach of X.509.

For OCSP, this could be fixed by changing how an authorized OCSP signer
is identified, by hardwiring a seperate trust path into the CA cert,
rather than into the EE cert.

> The OCSP responder cannot distinguish between the two.

Then please let's stop making this useless distinction in the discussion
of the OCSP protocol!

> with rules or recommendations applied to RP to avoid a fallback to CRLs.

The hard-fail option didn't work for the existing OCSP, how likely
is it that it would work for a brand-new optional protocol extension?

The "cert hash" option in the reply can not protect against any attacks,
whereas the "revoked,certificateHold" option for serials not on the
record of issued certs can at least protect against _some_ attacks.

Since there are several design flaws in play, there is not going to be
one single silver bullet that is going to solve all problems.

Not changing anything at all would mean that we will be stuck with the
known problems forever, which does not look like a sensible decision.
So lets try to fix the issues one at a time.  Every journey starts
with a first step.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 24 Oct 2012 22:22:52 +0200 (CEST)

Patching a defect of my last message:

> record of issued certs can at least protect against _some_ attacks.

The "cert hash" in the OCSP response option protects against
hash-collisions and fraudulently issued without record of certs
that re-use the serial of regular valid certs to appear innocent
from not being detectable.

So that cert hash should probably use at least SHA-256.  Being a
new protocol feature, that ought to be easy (we skipped SHA-1
in DANE as well).

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 24 Oct 2012 15:37:25 -0700

> The "cert hash" in the OCSP response option protects against
hash-collisions
> and fraudulently issued without record of certs that re-use the serial of
> regular valid certs to appear innocent from not being detectable.
> 
> So that cert hash should probably use at least SHA-256.  Being a new
protocol
> feature, that ought to be easy (we skipped SHA-1 in DANE as well).

[Piyush]  I think you mean appears to protect. 
I hope people really don't start believing that this extension protects them
from a CA compromise scenario.

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Oct 2012 00:40:35 +0200 (CEST)

> signature checking if his responder claims that it checks issuance. 

I completely fail to follow your argument here.

When you say "stop signature checking", do you mean checking the
CA signature on the certificate for which you perform the OCSP request?

In the exceptional case that
  - you exclusively use a securely preconfigured local OCSP responder,
  - this securely preconfigured local OCSP responder uses the optional
    cert hash extension in his responses and the hash returned with
    a good response matches the cert in question
  - you fully trust that securely preconfigured local OCSP responder
    to issue any cert it pleases like an omnipotent universal CA

then you may omit the signature check on the certificate in question.

In all other situations, you MUST verify the CA signature of the certificate
before using any OCSP AIA in that cert to query its status -- or you
misunderstand the X.509 security architecture and why it is vitally
important that (a) (1) is the very first step in the certificate
processing specified in PKIX/rfc5280:

   http://tools.ietf.org/html/rfc5280#section-6.1.3

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Oct 2012 00:47:21 +0200 (CEST)

Piyush Jain wrote:
>> protocol feature, that ought to be easy (we skipped SHA-1 in DANE as well).
> 
> I hope people really don't start believing that this extension
> protects them from a CA compromise scenario.

You're confusing things.  The reason why this protection currently
does not work is not that there is a problem with conveying back
the hash, but that the current scheme to identify an authorized OCSP
responder cert is fatally flawed.

Fixing the authorized OCSP responder issue is by defining a new
attribute that is hardwired into the CA cert in order to establish
an alternative trust path.

The other thing you seem to totally discount is that not every
breach of the CAs security amounts to a full and thorough compromise,
i.e. that the attacker can get hold of an carry away the CA private
signature key.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 24 Oct 2012 20:56:05 -0700

> From: Martin Rex [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2012 3:47 PM
> To: Piyush Jain
> Cc: [email-masked]; 'Peter Rybar'; [email-masked]; 'Stefan Santesson'
> >> hash-collisions and fraudulently issued without record of certs that
> >> re-use the serial of regular valid certs to appear innocent from not
> >> being detectable.
> >>
> You're confusing things.  The reason why this protection currently does
not
> work is not that there is a problem with conveying back the hash, but that
> the current scheme to identify an authorized OCSP responder cert is
fatally
> flawed.
[Piyush] I'm confused but only after your comments. What scheme are you
talking about - CA delegated trust or direct trust dictated by local policy?
> 
> Fixing the authorized OCSP responder issue is by defining a new attribute
> that is hardwired into the CA cert in order to establish an alternative
trust
> path.
[Piyush] We are not talking about overhauling the protocol here. Are you
implying that without this new attribute (whatever it is) the proposed
change of returning revoked for fraudulent cert is not beneficial? If so
then this discussion is moot.
> 
> The other thing you seem to totally discount is that not every breach of
the
> CAs security amounts to a full and thorough compromise, i.e. that the
> attacker can get hold of an carry away the CA private signature key.
> 
[Piyush] If an attacker can issue fraudulent certificate it can issue a
fraudulent certificate that points to a fraudulent OCSP responder also
issued by the compromised CA. Unless you create a trust model where
responder trust is independent of CA trust, these proposals just amount to
hacks.
Intent of OCSP is to address operational issues associated with CRL not to
detect CA compromises.

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 24 Oct 2012 21:26:10 -0700

> Sent: Wednesday, October 24, 2012 3:41 PM
> To: Piyush Jain
> Cc: 'Stefan Santesson'; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell';
'Peter
> Rybar'; [email-masked]
> > The people who are convinced that this is the way to go have not
> > addressed the issues raised in this WG. The little extension does not
> > hurt anyone but it does not provide any value in general except to a
> > few implementations which are compromised. But it does take you down a
> > slippery slope when you start promising that an OCSP responder can do
> > much more than it is supposed to.
> >
[Piyush]  I think your comments below indicate that you understand the
argument.
> 
> When you say "stop signature checking", do you mean checking the CA
> signature on the certificate for which you perform the OCSP request?
[Piyush] Yes.
> then you may omit the signature check on the certificate in question.

[Piyush] And this is the only exceptional case where the cert hash extension
and returning revoked for not-issued has any value. In every other scenario
it's just a hack providing no additional security. 

> misunderstand the X.509 security architecture and why it is vitally
important
> that (a) (1) is the very first step in the certificate processing
specified in
> PKIX/rfc5280:
[Piyush]  And yet you are arguing for an extension which enables responders
to say that certificate can be non-issued even though the RP has verified
that the CA issued it by performing signature verification.
All this extension does is creates a paradox. If signature on the payload
certificate verifies certificate is issued. If you cannot trust this
cryptographic binding, you cannot trust the cryptographic binding on the
responder's cert because the responder cert is also issued by the same CA.

If the little extension benefits a small number of people who obviously do
not have too much confidence in the security of their CA deployments, they
can publish an informational RFC to accommodate this. Putting it in the
standard just adds overhead for majority of vendors out there who at the
minimum need to justify the reason for not including this feature in their
implementation.

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 26 Oct 2012 09:16:46 -0700

the
> attacker can get hold of an carry away the CA private signature key.

[Piyush] Here is the bulletin published by NIST that pertains to this issue
http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf
NIST recommends revoking the certificate in case of impersonation and RA
compromise and revoking the CA in case of CA system or CA private key
compromise.

Let us know if/why you disagree with these recommendations and the kind of
compromise in which this extension would make sense.

---

From: [email-masked] (Martin Rex)
Date: Sat, 27 Oct 2012 04:44:33 +0200 (CEST)

Piyush Jain wrote:
> > the CAs security amounts to a full and thorough compromise, i.e. that the

These recommendations are the longer version of

"CA compromise can not possibly happen.  If it happens anyhow, nuke the PKI"

There are two things to do here:

(1) do like NIST, openly admit that existing X.509/PKIX is defective
    describe the consequences for the installed base in case you're using
    X.509/PKIX.

(2) fix the architecture of X.509 so that the CA key is no longer
    an unavoidable single-point-of-failure, and that the authentication
    can be restored to secure operation after the breach is detected
    for existing/deployed PKI credentials for use with RPs that use
    (modified) OCSP for revocation checking, _even_ when the CA signing
    key plus the OCSP signing key were captured by the attacker.

I'm fully aware that patching/updating a huge installed base is going
to be a significant effort, and drag along for quite a while.
It is worthwhile and should be done.
Been there, still fixing... (rfc5746, TLS secure renegotiation).

I'm aware that original OCSP is limited in functionality to
essentially splitting CRL checking into two tasks, and that it
wasn't seen a chance to remediate the problem of a CA compromise
through an independent trust path.  So lets fix it.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 26 Oct 2012 22:19:08 -0700

> Sent: Friday, October 26, 2012 7:45 PM
> To: Piyush Jain
> > > breach of the CAs security amounts to a full and thorough
> > > compromise, i.e. that the attacker can get hold of an carry away the
CA
> private signature key.
> > NIST recommends revoking the certificate in case of impersonation and
> > RA compromise and revoking the CA in case of CA system or CA private
> > key compromise.
> >
> > Let us know if/why you disagree with these recommendations and the
> > kind of compromise in which this extension would make sense.
> 
[Piyush] I think that the conclusion is unfair - X.509/PKIX is defective
because a few CAs get compromised.

>     key plus the OCSP signing key were captured by the attacker.
[Piyush] May be there is a silver bullet out there. But I have not seen one
yet. None of the proposals here satisfy what you are asking. The closest one
was from Phil some time ago where he informally proposed OCSP responder key
should not be bound to the CA that issues EE certificate. And that one did
not get any support here.

BTW authentication can be restored by revoking the CA and reissuing the end
entity certificates with a new key.  Not saying that it is easy but it is
doable, and unfortunately the only way to patch the vulnerabilities
introduced by a CA compromise.
 
> I'm fully aware that patching/updating a huge installed base is going to
be a
> significant effort, and drag along for quite a while.
[Piyush] I'm all for improvement, the idea of overloading OCSP as it stands
today is just a hack. I have not seen a single attack scenario where
responding for so called un-issued certificates helps.  People have been
splitting hair by saying that even CA compromise can have different
severance level. Unless you can document those and provide guidance on how
this change would help, you are just adding to the confusion.
 
> 
> I'm aware that original OCSP is limited in functionality to essentially
splitting
> CRL checking into two tasks, and that it wasn't seen a chance to remediate
> the problem of a CA compromise through an independent trust path.  So lets
> fix it.
> 
[Piyush] I think I fail to see the problem here. If CA is compromised,
revoke the CA and reissue the ee with new CA key. 
If you have a proposal that allows the CA to operate securely even after a
compromise, I'm all ears.

---

From: [email-masked] (Martin Rex)
Date: Tue, 30 Oct 2012 00:23:28 +0100 (CET)

Piyush Jain wrote:
> I think that the conclusion is unfair - X.509/PKIX is defective

X.509/PKIX is defective because it breaks badly already on fraudulent
cert issuance (a weaker form of CA compromise) and can not cope at all
with CA key compromise.

> May be there is a silver bullet out there.  But I have not seen one yet.

I don't think silver bullets exist (I wrote that previously),
but one can hardly do worse that rfc2560 for online status checking
of certs.  OCSP was artificially limited to "as bad as CRL checking."

>
> None of the proposals here satisfy what you are asking.  The closest one

If you imply revoking the compromised CA key by revoking the CA cert,
then this isn't restoring authentication at all.  It is nuking the old
PKI and re-creating a new PKI.

In case that this procedure assumes that using an audited log of issued
certs can be used to automatically re-signed the public keys with the
new CA cert and distribute only that cert (omitting the RA step),
then this is conceptually on the right track.

We do not even need to issue new certs -- if we extend OCSP to provide
an independent confirmation to _others_ (RPs) right away, then we
do not have to unconditionally force each PKI credential through a
cert replacement _before_ it can be used again.  Instead, the CA may
keep the existing credential working and have PKI credentials gradually
updated.

Yes, Phil is right that the rfc2560 approach that the same CA key
can sign valid OCSP signer keys is one of the design flaws of OCSP.

> this change would help, you are just adding to the confusion.

rfc2560 OCSP currently delivers a poor ROI, and by extending
the protocol, we could significantly improve its value.

The TLS renegotiation issue was based on a completely flawed assumption
(by primarily the renegotiating servers), infering from the renegotiation
happening inside TLS that the remote peer will still be the same after
renegotiation completes.

It would have been obvious, for anyone who cared to really check, that
there was *NO* cryptographic binding between the two TLS connection states.

The flaw with CRLs and OCSP is that it tries to infer, from a lack
of a revocation, that a certificate has been properly issued and is valid.
Evidently, this turned out to be a logical fallacy with respect to
real world usage scenarios.

The design of CRLs is pretty much fubar, but OCSP gets at least the
basic request-response semantics right, in that it is about a positive
confirmation for the status of cert, rather than a flawed inference
on the lack of a published revocation.

In order to get rid of the CA-key-is-single-point-of-failure,
a secondary trust path is necessary, one which can not be forged
even when the CA cert signing key is compromised, two independent
CA keys, that can be seperated and seperately protected, i.e.

  (1) CA-key-1 to sign EE certs

  (2) independent CA-key-2 to sign short-lived OCSP signer certs

To issue (=sign) EE-Certs, only CA-key-1 needs to be accessible
by the OnlineCA.

One of the problems create by compromise of the CA-key-1 is that
we can no longer trust any information in certs signed with CA-key-1
_unless_ we can obtain an independent confirmation of the certificate
hash signed by an independent key.

So in order to convey the necessary information in a fashion that is
not affected by a CA-key-1 compromise, but still locally available
to the certificate path validation function, we could convey
(a) the location of the OCSP responder and (b) the CA-key-2 that
is solely authorized to sign OCSP responder keys through new
attributes of the CA cert that carries CA-key-1.

An approach to make this mostly backwards-interoperable with rfc2560
would be to create a self-issued CA cert with CA-key-2 signed by
CA-key-1, adding the certificate hash of this self-issued cert
into the CA cert that carries CA-key-1, and create all OCSP responses
with two path certs, the OCSP signer cert and the self-issued
CA-key-2 signed by CA-key-1 cert.

Vanilla rfc2560 RPs will remain unprotected from a CA key compromise,
since they will continue to happily accept OCSP signer certs signed
by CA-key-1.  That is to be expected with a protocol design flaw.
The important thing here is that you do not need two different
kind of OCSP responses, but can still process value-added OCSP responses
with rfc2560 RPs.  (Similarly, TLS server implementations without rfc5746
will remain susceptible to the TLS renegotiation problem, but that
should not stop anyone from adopting new protocol features).

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Oct 2012 11:52:47 +0200

Before we loose everyone engaged in this, I would like to make a
straw-poll:

Background:
A client may do a request for a certificate that has never been issued by
the CA.
This request may be done deliberately, by mistake or as a consequence of a
compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge
about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with
a particular serialNumber value has been issued or not.

The following is agreed:
   - An OCSP responder is allowed to respond "good" to a status request
for a non-revoked certificate, disregarding if it has ever been issued.

   - A client, having no additional out-of-band knowledge about the OCSP
responder, will just know that the certificate is "not revoked" when
receiving a "good" response, unless the response includes one or more
response extensions that provides additional information.

The following is debated:
   - Is an OCSP responder allowed to respond "revoked" even if a requested
certificate serial number is not on the list of revoked certificates, IF
the OCSP responder has positive knowledge that the requested serial number
does NOT represent a valid certificate issued by the identified CA?

Rationale for:
There are a number of reasons to allow this that has been mentioned, such
as:
 - It breaks nothing. A legitimate request for an issued certificate will
get a legitimate deterministic response.
 - It's safer. Responding "revoked" may not prevent a compromised CA from
being exploited. But if a request for a serialNumber that is known to be
bad is done nevertheless, a "revoked" response will at least be safer than
responding "good".
 - Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that
the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows that the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined if the
base standard allows a status other than "good" in such situation.
 - Supporting Web-PKI. The CAB-Forum has indicated that they will profile
the OCSP protocol for use with web server authentication. In such profile
they have indicated that they will NOT allow the "good" response unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this
states that "good" MUST be returned unless the certificate has been
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that
it is wrong and confusing to allow anything but "good" as a response to a
non-revoked certificate (if the cert is issued by a CA that is served by
this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked". It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.

Please reply with either:

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate
to be "bad".

2. Require that the OCSP responder MUST respond "good" in this situation.

3. Neither 1 or 2 (motivate).

Note: both alternatives are placed in a context where the certificate is
claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 30 Oct 2012 12:22:21 +0100

Hi,

I prefer Option 1: Return revoked when a certificate is not known to have  
been issued.

> Before we loose everyone engaged in this, I would like to make a

<snip>

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Oct 2012 13:42:37 +0200

Also #1. 

It is wrong to assume that a compromised CA will issue any CA with any serial number. The compromises of Diginotar and InstantSSL.it did not allow the attacker to choose a serial number, only to sign a particular request.

Yoav

On Oct 30, 2012, at 1:22 PM, Yngve Nysaeter Pettersen wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 30 Oct 2012 13:35:11 +0100

Bonjour,

Option #3, reply with an unsigned response (unauthorized), RP SHOULD
have a hard-fail behavior.

2012/10/30 Stefan Santesson <[email-masked]>:
[...]

-- 
Erwann.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 30 Oct 2012 12:40:59 +0000

> cert issuance (a weaker form of CA compromise) and can not cope at all

Do you have an alternative to the technology, because AFAICT, no PKI standards recover well from a breach of trust.  Even the web of trust has issues; if a well-connected introducer is compromised, all descendent keys become suspect--which can potentially encompass all nodes in the graph.  This can be as devestating as a CA compromise, and would likewise require a re-execution of a large number of signing ceremonies.

> real world usage scenarios.

Absent a trusted observer, there is no positive statement that can be issued by a CA that positively identifies only "valid" certificates.  Given a trusted observer, why not make him the CA and be done with it?

-- T

---

From: David Chadwick <[email-masked]>
Date: Tue, 30 Oct 2012 13:44:04 +0000

1

---

From: "Art Allison" <[email-masked]>
Date: Tue, 30 Oct 2012 09:59:57 -0400

3) Neither. Add new optional response = unissued.
The conflation of revoked and unissued that seems to be unresolvable by the current protocol says to me the current protocol is inadequate and a new response is needed.  
 
Responding revoked for an unissued cert is a lie.  No RFC should ever attempt to make implmentors lie, as some will refuse to do so and lack of interoperablity across implementations results.  And, relevant to implementation decisions; I am responsible for a contract with a vendor that has an OCSP function.   
 
Art Allison
Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981
www.nab.org <http://www.nab.org/> 
*Advocacy  Education  Innovation*

________________________________

From: [email-masked] on behalf of Stefan Santesson
Sent: Tue 10/30/2012 5:52 AM
To: [email-masked]
Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Background:

The following is agreed:

Rationale for:

Rationale against:

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 30 Oct 2012 14:07:26 +0000

>3) Neither. Add new optional response = unissued.

UNKNOWN would satisfy in this case, but that wasn't a poll option.  :)

I disagree in re: lying.  The OCSP responder can respond REVOKED and the CA could add it to the CRL afterward, and a relying party wouldn't be able to tell the difference.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 30 Oct 2012 10:24:19 -0400

Stefan,

I vote for option 1, that is claim it to be revoked.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Tuesday, October 30, 2012 5:53 AM
To: [email-masked]
Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not.

The following is agreed:
   - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued.

   - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information.

The following is debated:
   - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA?

Rationale for:
There are a number of reasons to allow this that has been mentioned, such
as:
 - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response.
 - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good".
 - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation.
 - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber.

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long debates.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 30 Oct 2012 15:26:19 +0100

2012/10/30 Miller, Timothy J. <[email-masked]>:
[...]
> I disagree in re: lying.  The OCSP responder can respond REVOKED and the CA could add it to the CRL afterward, and a relying party wouldn't be able to tell the difference.

You'll then have to set a revocation date to be set in the CRL, which
might be different than the one defined here. Some asked for epoch,
some asked for 1950, but since you can't use as a revocation date for
a certificate a date earlier than the thisUpdate of a previous CRL in
which that certificate wasn't revoked, a RP will be able to tell the
difference (that's normative).
Of course, this certificate won't be removed from the CRL since you
don't know its expiration date (nice to make a CRL grow indefinitely).
And if the CA has some sort of constraints in its DB (which can be
considered as good practice), then a false certificate may have to be
created and inserted before being able to revoke it.

-- 
Erwann.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Oct 2012 16:26:28 +0200

> I disagree in re: lying.  The OCSP responder can respond REVOKED and the CA could add it to the CRL afterward, and a relying party wouldn't be able to tell the difference.

An OCSP query does not reveal the CDP, so the CA wouldn't know which CRL up update.

If it did work, that would be a good way to attack the CA - every request ends up as an entry in the CRL. How quickly can we get to gigabyte-sized CRLs?

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 30 Oct 2012 16:40:12 +0100

I vote for option 3, Neither (which is I hope "unknown").

Trusted services shall not cheat.

Status "revoked" is untruth.
RFC define: The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)).

The status "good" shall be used with a positive statement extension like hash of certificate otherwise we have unclear status.

A client may do a request for a certificate that has "never" been issued by the CA according to information in "old" OCSP database.
This request may be done by 'extremely' quick request after issuing certificate and for that reason OCSP database is not updated and expectations like: deliberately, by mistake or as a consequence of a compromised CA are in this case not correct. 

Also deliberately created values of serialNumber which are expected that will be included in new certificates issued at any time later can harm validations services when "revoked" will be included in responses because any cache or archive databases containing such untruth responses of serialNumber marked as "revoked" with different thisUpdate values than later issued and successively revoked real certificates with the same serialNumber will cause unknown verification sates in many applications.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Oct 2012 08:47:41 -0700

> but where that OCSP responder for any other reason knows the certificate

1 seems fine *as long as* the document defining this change explicitly says "the term 'revoked' now means 'revoked or never issued'". That is, "revoked" cannot just magically mean "bad" or "not good", it needs to have a specific defined meaning. I have no problem with the use of the English word "revoked" in the protocol having a real-world meaning beyond "revoked".

--Paul Hoffman

---

From: Juan Gonzalez <[email-masked]>
Date: Tue, 30 Oct 2012 09:51:27 -0600

Option 3) Neither 1 or 2

I agree about responding Unknown.

-- 

*AVISO DE PRIVACIDAD*
Los datos personales que usted nos proporcione están sujetos a los términos
de la Ley Federal de Protección de Datos Personales en Posesión de los
Particulares (LFPDPPP). Para mayor información acerca del tratamiento y de
los derechos que puede hacer valer, usted puede acceder al Aviso de
Privacidad completo a través de la página www.seguridata.com/privacidad.htm.
Es importante que lo lea previamente a cualquier envío de información sobre
datos personales. SeguriData Privada S.A. de C.V.,  tiene su domicilio en
Insurgentes Sur, 2375 tercer piso, Colonia Tizapán, C.P. 01000, Delegación
Álvaro Obregón, en México, D.F.,  y utilizará sus datos personales
únicamente para la finalidad para la que sean obtenidos.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 30 Oct 2012 15:59:51 +0000

#1 

The system should fail closed. I agree with Paul Hoffman's point that this extends the definition of the 'revoked' response during this protocol exchange which must be noted. I'd also accept a new "unknown, fail closed" type response so long as clients that don't yet understand this new response fail closed.

- max

---

From: Simon Tardell <[email-masked]>
Date: Tue, 30 Oct 2012 17:02:00 +0100

> 3. Neither 1 or 2 (motivate).
1.

I see some people saying 3/ "unknown", because "revoked" would be lying.
Well, "unknown" be lying so much more, if you let it be an assertion that
the certificate has never been issued. Furthermore it would open security
holes by prompting some client implementations to fall back to CRLs or try
later.

/Simon

---

From: Carl Wallace <[email-masked]>
Date: Tue, 30 Oct 2012 12:09:19 -0400

1 but would like for the responder certificate or response to include some
indication that the responder is using these new semantics.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Oct 2012 09:15:11 -0700

> The system should fail closed. I agree with Paul Hoffman's point that this extends the definition of the 'revoked' response during this protocol exchange which must be noted. I'd also accept a new…

Max has a good point. I would say "#1, possibly followed by a new optional extension later that would clarify which part of the new 'revoked' is meant".

--Paul Hoffman

---

From: "Rick Robinson" <[email-masked]>
Date: Tue, 30 Oct 2012 10:19:09 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, October 30, 2012 3:53 AM
To: [email-masked]
Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Background:

The OCSP protocol does not require OCSP responders to have any knowledge
about issued certificates. It must only know about revoked certificates that
are within it's current validity period. However, some OCSP responders
closely coupled with the CA may also know if a certificate with a particular
serialNumber value has been issued or not.

The following is agreed:
   - An OCSP responder is allowed to respond "good" to a status request for
a non-revoked certificate, disregarding if it has ever been issued.

The following is debated:
   - Is an OCSP responder allowed to respond "revoked" even if a requested
certificate serial number is not on the list of revoked certificates, IF the
OCSP responder has positive knowledge that the requested serial number does
NOT represent a valid certificate issued by the identified CA?

Rationale for:
There are a number of reasons to allow this that has been mentioned, such
as:
 - It breaks nothing. A legitimate request for an issued certificate will
get a legitimate deterministic response.
 - It's safer. Responding "revoked" may not prevent a compromised CA from
being exploited. But if a request for a serialNumber that is known to be bad
is done nevertheless, a "revoked" response will at least be safer than
responding "good".
 - Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about the
requested certificate. This may include a positive confirmation that the
certificate has been issued as well as information that this particular OCSP
responder will only respond "good" if it knows that the requested
certificate has been issued, otherwise it will respond "revoked". An
extension with such semantics can only be defined if the base standard
allows a status other than "good" in such situation.
 - Supporting Web-PKI. The CAB-Forum has indicated that they will profile
the OCSP protocol for use with web server authentication. In such profile
they have indicated that they will NOT allow the "good" response unless the
requested certificate is known to have been issued. This means that they
will require OCSP responder in their infrastructure to have this knowledge.
Such profile would have to break the base OCSP standard if this states that
"good" MUST be returned unless the certificate has been revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that
it is wrong and confusing to allow anything but "good" as a response to a
non-revoked certificate (if the cert is issued by a CA that is served by
this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked". It would be
easy to adapt an attack to circumvent such response, for example by issuing
a fake certificate that duplicates a legitimate serialNumber.

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate to
be "bad".

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 30 Oct 2012 10:46:04 -0600

3 - Many CAs already respond with either unknown or unauthorized.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rick
Robinson
Sent: Tuesday, October 30, 2012 10:19 AM
To: [email-masked]
Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked
certificates.

-----Original Message-----

Background:

The following is agreed:

Rationale for:

Rationale against:

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Oct 2012 09:31:43 -0800

Option 1.

Melinda

---

From: [email-masked] (Martin Rex)
Date: Tue, 30 Oct 2012 20:00:29 +0100 (CET)

> indication that the responder is using these new semantics.

I also choose 1, and I am not aware of any technical objection against 1,
why _permitting_ (rather than requiring) OCSP responders to do this
should be detrimental to the security of the peer authentication performed
by the RP or to the interop between the RP and the OCSP responder. 

I'm OK with defining an RECOMMENDing an explicit confirmation of
these semantics through a non-critical response extension.

Option 2 looks like a coffin nail for *ALL* OCSP extensibility to me.
It just doesn't make sense to me to add a "perfect" option on top of
good and permitting only _new_ RPs to recognize it; allowing+expecting
them to then fail on "good" no longer being good enough, while
effectively misleading the entire installed base on the guidance
to better not trust the cert (serial) in the response.

Option 3 looks like a technical problem.  Error responses are unsigned
and (a) are supposed to cause a fallback to CRLs (but CRLs processing
can not possibly detect the problem that the OCSP responder is trying
to convey) and (b) can not be cached by RPs that use OCSP to determine
that status of their communication peer's certificate.

About RPs that retry for OCSP responses with status "revoked,certificateHold",
the existing semantics of nextUpdate should be followed:

   http://tools.ietf.org/html/rfc2560#section-2.4

The removeFromCRL reason code is limited to delta-CRLs in order to
supersede a certificateHold of the baseCRL to which the delta CRL refers.
On the next regular CRL, a certificateHold crlEntry may reappear when
the permanent status is still undetermined, may be dropped/missing
when the hold status is lifted, or it may be replaced by a permanent
revocation.

-Martin

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Oct 2012 15:36:12 -0400

> The system should fail closed. I agree with Paul Hoffman's point that this extends the definition of the 'revoked' response during this protocol exchange which must be noted. I'd also accept a new…

Max and Paul have raised good points. I support #1, if and only if there is a way for the relying party to tell wether the OCSP Responder is using the original definition or the new and improved one.

Russ

---

From: [email-masked] (Martin Rex)
Date: Tue, 30 Oct 2012 21:47:21 +0100 (CET)

Miller, Timothy J. wrote:
> Do you have an alternative to the technology, because AFAICT,
> no PKI standards recover well from a breach of trust.

The design flaw of PKI is that all CA keys are single points of
failure.  There is a complete lack of backup if one fails, or can
be made to fail.

Designing a technology with complete lack of a backup system seems
like a bad idea to me.  Like skydiving with only one single parachute,
or designing a large commercial passenger jet with just a single turbo-fan
engine (something which FAA might refuse to certify for good reasons).

The fact that _no_ existing PKI standards provide backup facilities
today is a mere technical defect that _could_ be fixed.

>
> Even the web of trust has issues; if a well-connected introducer is
> compromised, all descendent keys become suspect--which can potentially
> encompass all nodes in the graph.  This can be as devestating as a
> CA compromise, and would likewise require a re-execution of a large
> number of signing ceremonies.

I beg to differ.

When a well-connected introducer is newly compromised,
then this does not affect any trust relationships previously confirmed
by that introducer, only precludes adoption of trust for new relationships.

When a well-connected introducer turns out to have been never been
trust-worthy, it affects only those trust relationships where he
is the _only_ introducer (same effect as in single-key PKI models).

> Absent a trusted observer, there is no positive statement that can
> be issued by a CA that positively identifies only "valid" certificates.
> Given a trusted observer, why not make him the CA and be done with it?

Maybe because PKI(X) should be more about real-wold PKIs, and
less about Utopia.

Why should businesses and banks deal with accounting, audits and
fraud prevention, if they could simply use a system where fraud
is impossible.  As it turns out, it is impossible to create and run a 
"system where fraud is impossible" in the real world (even if they
wanted to), especially at a cost-level where business operation
makes sense.  So the second best approach is a security trade-off,
a system that makes business sense and can cope reasonably with
common real-world _operational_ problems, like software being subject
to bugs and staff being susceptible to social engineering, bribery
and threat/coercion.

I could imagine why crooks, hackers and certain agencies might not like
a backup scheme that makes subverting the PKI significantly harder.
But why should an engineer, and in particular one who understands and
cares about security, oppose addition of a backup scheme to address
the susceptibility of X.509 PKI to operational problems and risks
from the pesky (physical) real world?

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Tue, 30 Oct 2012 22:29:56 -0400

1

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 31 Oct 2012 02:40:24 +0000

Option 1.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 31 Oct 2012 02:20:28 -0700

Option 1

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 31 Oct 2012 11:36:22 +0100

Option 1 with strong support for Paul's request to change the name of this status (e.g. to "revoked or never issued").

While I agree to defining an extension signaling the new semantic, I deem it more important to have an extension
providing positive evidence (not just indication) of the fact that a certificate has been issued, e.g. by including a
hash of the certificate in question.

> It would

This attack would be prevented by returning in the response the hash value of the certificate.

Inclusion of a new status, as suggested in some answers, would require a new protocol version number.

Johannes

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 Oct 2012 12:46:38 +0100

Response #3 : status : unknown

Response #1 would also be acceptable, but as a second choice.

Quick explanation: "unknown" is the right status.

If the OCSP client verifies that the response is from an authorized 
responder for the CA which has issued the certificate:
unknown is a definite response and is safe (no other mechanism SHALL be 
used).

On the contrary, if the OCSP client does not verify that the response is 
from an authorized responder for the CA which has
issued the certificate, then another mechanism will be used : either 
another OCSP server or CRLs.

If CRLs are used, "revoked" is safer, but it is semantically incorrect. 
So a change in its semantics would be mandatory.

The problem is that the change should be "revoked or unknown" which may 
be rather confusing.

---

From: "Art Allison" <[email-masked]>
Date: Wed, 31 Oct 2012 10:39:03 -0400

I am ok with the choice others suggested for option 3 - add new optional
response value = Unknown.  

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Denis Pinkas
Sent: Wednesday, October 31, 2012 7:47 AM
To: [email-masked]
Subject: Re: [pkix] Straw-poll on OCSP responses for
non-revokedcertificates.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 31 Oct 2012 07:42:22 -0700

Same as Dennis.

Sent from my iPhone

On Oct 31, 2012, at 4:46 AM, Denis Pinkas <[email-masked]> wrote:

> Quick explanation: “unknown” is the right status. 
> 
> If the OCSP client verifies that the response is from an authorized responder for the CA which has issued the certificate: 
> unknown is a definite response and is safe (no other mechanism SHALL be used).
>  
> On the contrary, if the OCSP client does not verify that the response is from an authorized responder for the CA which has 
> issued the certificate, then another mechanism will be used : either another OCSP server or CRLs. 
> 
> If CRLs are used, “revoked” is safer, but it is semantically incorrect. So a change in its semantics would be mandatory.
> The problem is that the change should be "revoked or unknown" which may be rather confusing.

---

From: "Ben Wilson" <[email-masked]>
Date: Wed, 31 Oct 2012 09:35:40 -0600

I don’t think the original ballot changed.  #1 was to allow revoked.  #3 was do nothing.  So, a vote that they favor “3 – unknown” is out of scope, but hopefully everyone understands that this is the nature of a straw poll?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ryan Hurst
Sent: Wednesday, October 31, 2012 8:42 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Same as Dennis.

Sent from my iPhone

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 31 Oct 2012 17:30:26 +0100

#3 is "neither 1 or 2 (motivate)". It can be fulfilled by anything else.

2012/10/31 Ben Wilson <[email-masked]>:
> I don’t think the original ballot changed.  #1 was to allow revoked.  #3 was
> do nothing.  So, a vote that they favor “3 – unknown” is out of scope, but
> hopefully everyone understands that this is the nature of a straw poll?

-- 
Erwann.

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 31 Oct 2012 09:41:51 -0700

> Sent: Tuesday, October 30, 2012 1:47 PM
> To: Miller, Timothy J.
> Cc: [email-masked]; Piyush Jain; [email-masked]; 'Stefan Santesson'
> > > X.509/PKIX is defective because it breaks badly already on
> > > fraudulent cert issuance (a weaker form of CA compromise) and can
> > > not cope at all with CA key compromise.
> >
> > Do you have an alternative to the technology, because AFAICT, no PKI
> > standards recover well from a breach of trust.
> 
> The design flaw of PKI is that all CA keys are single points of failure.
There is a
> complete lack of backup if one fails, or can be made to fail.

> 
> Designing a technology with complete lack of a backup system seems like a
> bad idea to me.  Like skydiving with only one single parachute, or
designing a
> large commercial passenger jet with just a single turbo-fan engine
> (something which FAA might refuse to certify for good reasons).
>
[Piyush] Technology is what it is. You can always design you system that
uses the technology in a way that makes it fault tolerant. In your example
above engine is the technology and jet is the system. You can always have a
system where you provide secondary method for authentication (may be certs
issued of a bakup CA) while you recover from main CA compromise.
 
> 
> The fact that _no_ existing PKI standards provide backup facilities today
is a
> mere technical defect that _could_ be fixed.
> 
> 
> 
> >
> > encompass all nodes in the graph.  This can be as devestating as a CA
> > compromise, and would likewise require a re-execution of a large
> When a well-connected introducer is newly compromised, then this does not
> affect any trust relationships previously confirmed by that introducer,
only
> precludes adoption of trust for new relationships.
> 
> When a well-connected introducer turns out to have been never been trust-
> worthy, it affects only those trust relationships where he is the _only_
> introducer (same effect as in single-key PKI models).
> 
> 
> >
[Piyush] Why call it a flaw. My car does not have a flaw just because it
cannot fly. 
OCSP and CRLs make simple statement - Is the certificate in question revoked
by the issuing authority, nothing more, and nothing less.
If you want more out of you server, deploy SCVP.

What real world usage scenario? My car fell off the cliff. It would've been
nice if it could fly, but unfortunately my poor driving habits (or faulty
brakes in my car) are no reason to change the design of cars.
The scenarios that you mention are exceptions rather than norms. 

> > Absent a trusted observer, there is no positive statement that can be
> > issued by a CA that positively identifies only "valid" certificates.
> Maybe because PKI(X) should be more about real-wold PKIs, and less about
> Utopia.
> 
> Why should businesses and banks deal with accounting, audits and fraud
> prevention, if they could simply use a system where fraud is impossible.
As it
> turns out, it is impossible to create and run a "system where fraud is
> impossible" in the real world (even if they wanted to), especially at a
cost-
> level where business operation makes sense.  So the second best approach
> is a security trade-off, a system that makes business sense and can cope
> reasonably with common real-world _operational_ problems, like software
> being subject to bugs and staff being susceptible to social engineering,
> bribery and threat/coercion.
> 
> 
[Piyush] Crooks would actually love the schemes that are being proposed
here. Let the victims continue to operate with the illusion of security.
Your argument would've been meaningful in this discussion if
- trust model is changes so that RP trusts the responder and CA
independently (CA compromise should not imply responder compromise)
- OCSP is the only way to check revocation status of the certificate. (RPs
should not arrive at different conclusion if the use CRLs instead of OCSP)

But I've not seen above being recommended in any of the proposals. And I
think the reason is obvious. You can deploy SCVP in DPV mode to address the
points that you raised above.

---

From: "Art Allison" <[email-masked]>
Date: Wed, 31 Oct 2012 14:15:30 -0400

I answered the actual question asked. (I do not opine on what might have been intended to be asked.)

If the current scope prevents fixing the situation, expect lack of interoperability to continue. 

Changing the scope has a time line and, properly, should be justified.

Using the scope to ignore a problem has been done many times in the past, not just in IETF but elsewhere.  Contrast with allowing scope creep which prevents timely resolution of a problem.  Choose carefully.

Art

Art Allison 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Wilson
Sent: Wednesday, October 31, 2012 11:36 AM
To: [email-masked]
Subject: Re: [pkix] Straw-poll on OCSP responses fornon-revoked certificates.

Same as Dennis.

Sent from my iPhone

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 31 Oct 2012 19:46:46 +0100

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

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.

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.

But perhaps this will bee too much to agree on :)

/Stefan

---

From: Tom Ritter <[email-masked]>
Date: Wed, 31 Oct 2012 15:17:07 -0400

> 3. Neither 1 or 2 (motivate).

#1.

-tom

---

From: Tom Ritter <[email-masked]>
Date: Wed, 31 Oct 2012 15:32:23 -0400

Think I missed this email while sending in my vote, sorry.

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

Cool.

> revocationReason to certificateHold (6).

Is the 0 unix epoch overloaded/used in other contexts?  Have CAs set this
date as the revocation date in other situations/for legacy reasons?  Would
it be better to use something similar like Jan 2, 1970?  It's another magic
value which is crappy but...

> the "revoked" response is returned as a result of a status request for a

Cool.

> of existence of the certificate.

I'll register my vote for all these items also - I like the idea of
providing transparency into the operations of the responders.

-tom.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 31 Oct 2012 22:25:15 +0100

Here is my own concerns with inclusion of an optional cert hash in the
extension.

There might be OCSP responders that do have access to a database of issued
certs that are currently valid, but not the history of issued certs
(expired).
They could not use this extension to include a cert hash as they can't know
if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use
an OID to indicate this particular behaviour with regard to "revoked"
response.
It may be wise therefore to allow a separate process come up with a separate
extension for positive confirmations.
Not that I don't like such functionality.

The alternative is to extend this process long enough that we feel sure we
got it right.

/Stefan

From:  Tom Ritter <[email-masked]>
Date:  Wednesday, October 31, 2012 8:32 PM
To:  Stefan Santesson <[email-masked]>
Cc:  IETF PKIX <[email-masked]>
Subject:  Re: [pkix] Proposed resolution to non-issued certificates -
2560bis

> I'll register my vote for all these items also - I like the idea of providing
> transparency into the operations of the responders.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 31 Oct 2012 18:23:01 -0400

Stefan,

Up until now, you have been discussing extending the revoked
response as indicated in your current draft of 2560bis:

The "revoked" state indicates that the certificate has been
revoked

(either permanently or temporarily (on hold)). This state
SHOULD also

be returned if the responder knows that the requested
certificate has

never been issued.

Does your message below mean that you now intend to extend the
meaning of "revoked" even further to include certificates that
were issued by CA and that were never revoked, but that are 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.

Dave

On 10/31/2012 05:25 PM, Stefan Santesson wrote:

Here is my own concerns with inclusion of an optional cert
hash in the extension.

There might be OCSP responders that do have access to a
database of issued certs that are currently valid, but not the
history of issued certs (expired).

They could not use this extension to include a cert hash as
they can't know if a particular serial number of an expired cert
is asked for.

Thus it may be wise to separate these issues and keep it
simple and just use an OID to indicate this particular behaviour
with regard to "revoked" response.

It may be wise therefore to allow a separate process come up
with a separate extension for positive confirmations.

The alternative is to extend this process long enough that we
feel sure we got it right.

/Stefan

Date: Wednesday,
October 31, 2012 8:32 PM

To: Stefan Santesson
<[email-masked]>

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

Question:

Would it make sense to require an OCSP responder that adopts
the expanded

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

Such hash would make the positive confirmation even
stronger, adding proof

I'll register my vote for
all these items also - I like the idea of providing
transparency into the operations of the responders.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 31 Oct 2012 23:35:22 +0100

> Does your message below mean that you now intend to extend the meaning of
> "revoked" even further to include certificates that were issued by CA and that
> were never revoked, but that are now expired?

No

You got me wrong.

Not issued = never issued.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 31 Oct 2012 16:12:55 -0700

> Sent: Wednesday, October 31, 2012 11:47 AM
> To: [email-masked]
> Subject: [pkix] Proposed resolution to non-issued certificates - 2560bis
> 
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.

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

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

> languages to express time as milliseconds since jan 1, 1970. Selecting
this
> time avoids time expression as a negative integer.
> 
> 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?
[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).
> 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.