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

From: Stefan Santesson <[email-masked]>
Date: Mon, 15 Oct 2012 01:49:29 +0200

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

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 19 Oct 2012 13:07:40 +0200

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,

/Stefan

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

---

From: Simon Tardell <[email-masked]>
Date: Fri, 19 Oct 2012 13:56:58 +0200

It seems to me that if you remove information about the revocation status
for expired certificates you can't be expected to be able to answer the
question of whether it was ever issued. Or put in reverse: If you keep
track of all certificates ever issued, then it is reasonable to assume that
you keep track of all revocations of the same.

Also: "Electronic signature validation is usually about the signatures
created in the past and validated now, when the certificate is expired."

Well, yes, sort of. You can only be sure to validate a signature at the
moment of production. 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.

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

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.
> 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".
>
> ...
> "On the "revoked" state, the old spec did not even consider the case of a
> certificate was never issued."

---

From: Carl Wallace <[email-masked]>
Date: Fri, 19 Oct 2012 08:31:05 -0400

From:  Simon Tardell <[email-masked]>
Date:  Friday, October 19, 2012 7:56 AM
To:  Peter Rybar <[email-masked]>
Cc:  Peter Rybar <[email-masked]>, Stefan Santesson
<[email-masked]>, <[email-masked]>
Subject:  Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

> It seems to me that if you remove information about the revocation status for
> expired certificates you can't be expected to be able to answer the question
> of whether it was ever issued. Or put in reverse: If you keep track of all
> certificates ever issued, then it is reasonable to assume that you keep track
> of all revocations of the same.
> 
> Also: "Electronic signature validation is usually about the signatures created
> in the past and validated now, when the certificate is expired."
> 
> 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?

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

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 via SCVP.  This provides for timestamping.

>> 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.
>> 
>> 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?
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 19 Oct 2012 15:08:45 +0200

Peter and Simon,

There are two different topics covered by these two emails:

    1 - verification of an OCSP response that was issued in the past, and
    2 - status of a certificate that was never was never issued.

1) Verification of an OCSP response that was issued in the past

RFC 2560 ,nor the draft from Stefan, does not address verification in 
the past.
This topic are addressed in details in: draft-pinkas-rfc2560bis-03.
Hereafter are only a few extracts.

Page 5:

oSection 4.3 addresses the verification of an OCSP response

both at the current time and at a time in the past.

Page 21:

4.3.2. Response processing by an OCSP client

OCSP responses can be verified at the current time by an OCSP client

when receiving a response, whereas old responses can be verified at

a time in the past by a verifier.The algorithm below addresses

both cases.

Prior to processing a basic response, OCSP clients MUST determine

the checking time, which may be either the current time or a time

in the past.

Page 22:

If the certificate status from the single certificate response is

either "good" or "revoked", OCSP clients or verifiers SHALL check

that the checking time is within the validity period of the target

certificate.

(...)

If the checking time is a time in the past, verifiers MUST check

that the producedAt field is in accordance with the verification

rules (e.g. close and/or after the date of a time-stamp token).

In addition, if the nextUpdate field is present, OCSP clients MUST

check that the time which is indicated is greater than the checking

time, otherwise the single response MUST be discarded.

2) Status of a certificate that was never was never issued

  There is a strong agreement that, if the OCSP responder has access to 
the database
  of issued certificates, the revocation status shall never be "good". 
The only question
  is whether the returned revocation status shall be "revoked" or "unknown":

    - with "revoked", the RP will not accept the certificate and will 
stop the processing.

    - with "unknown", the RP will not accept the certificate, but may 
attempt to access other sources of information.

  However IMO, "unknown" is more appropriate, since if the proposed non 
criticalcertinfo extension is used,
  (see draft-pinkas-2560bis-certinfo-00)"unkown" make more sense (how 
would you revoke a certificate that was
  never issued ???) and the extension provides more details to RPs that 
are able to process it.

The case that Peter mentioned, i.e. "certificate removed from CRL after 
expiration" does not exist, ... unless
the Archive Cutoff extension is supported.

Denis

> It seems to me that if you remove information about the revocation 
> status for expired certificates you can't be expected to be able to 
> answer the question of whether it was ever issued. Or put in reverse: 
> If you keep track of all certificates ever issued, then it is 
> reasonable to assume that you keep track of all revocations of the same.
>
> Well, yes, sort of. You can only be sure to validate a signature at 
> the moment of production. 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.
>
> 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).
>
> 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 reason it is identified as "never been issued".
>
>     ...
>     "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."
>     e-mail: [email-masked] <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]>

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 19 Oct 2012 15:12:13 +0200

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. 

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.

Stefan,

...

Peter Rybar

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

/Stefan

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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 19 Oct 2012 14:32:57 -0400

On 10/19/2012 07:07 AM, Peter Rybar
wrote:

Peter,

There seems to be disagreement on this, but I think that the
situation described above needs to be prohibited.  If a responder is
going to use "revoked" as a response for a certificate that has
never been issued, then it must remember every certificate that has
ever been issued, even ones that have been revoked.  Technically,
this is what the text requires, since it only permits the "revoked"
response in two cases (1) the certificate has been revoked and (2)
the responder knows that the certificate has never been
issued.  Providing a response of "revoked" for an expired
certificate that was never revoked would be incorrect.

Some may argue that as long as the response does not include an
archive cutoff extension, it doesn't matter if the response
indicates a status of "revoked" even if the certificate was issued
and was not revoked.  However, RFC 2560 only says that OCSP servers
that provide status information about revoked certificates SHOULD
include the archive cutoff extension.  So, an RFC 2560-compliant
responser that maintains information about expired certificates
could provide a response of "revoked" for an expired certificate
without including the archive cutoff extension, and a client should
be able to take the response to mean that the certificate was
revoked.  If the situation you describe were allowed, then a client
could receive a response of "revoked" for an expired certificate
that had not been revoked.  While clients could be designed to treat
the response status for an expired certificate as meaningless unless
the archive cutoff extension is present, that would be a
non-backward compatible change from the current specification.

Dave

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 19 Oct 2012 20:37:08 +0200

> response if a certificate is known by the responder to never have been

Very good.

Thank you.

-- 
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: "David A. Cooper" <[email-masked]>
Date: Fri, 19 Oct 2012 14:41:11 -0400

In the second sentence I meant to say
"even ones that have expired."

On 10/19/2012 02:32 PM, David A. Cooper wrote:

Peter,

There seems to be disagreement on this, but I think that the
situation described above needs to be prohibited.  If a responder
is going to use "revoked" as a response for a certificate that has
never been issued, then it must remember every certificate that
has ever been issued, even ones that have been revoked.
Technically, this is what the text requires, since it only permits
the "revoked" response in two cases (1) the certificate has been
revoked and (2) the responder knows that the certificate has never
been issued.  Providing a response of "revoked" for an expired
certificate that was never revoked would be incorrect.

Some may argue that as long as the response does not include an
archive cutoff extension, it doesn't matter if the response
indicates a status of "revoked" even if the certificate was issued
and was not revoked.  However, RFC 2560 only says that OCSP
servers that provide status information about revoked certificates
SHOULD include the archive cutoff extension.  So, an RFC
2560-compliant responser that maintains information about expired
certificates could provide a response of "revoked" for an expired
certificate without including the archive cutoff extension, and a
client should be able to take the response to mean that the
certificate was revoked.  If the situation you describe were
allowed, then a client could receive a response of "revoked" for
an expired certificate that had not been revoked.  While clients
could be designed to treat the response status for an expired
certificate as meaningless unless the archive cutoff extension is
present, that would be a non-backward compatible change from the
current specification.

Dave