Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

From: "Black, David" <[email-masked]>
Date: Fri, 29 Mar 2013 14:17:38 -0400

Hi Piyush,

The usual backwards compatibility concern is mixed new/legacy deployments.
In this case, the specifics appear to be:

New clients with legacy servers cannot expect to see "revoked" in this case.
This matters because a hypothetical client coded to depend on a "revoked"
response in this case won't work correctly with legacy servers (even though
it'd be rather questionable to code that dependency into a new client -
never underestimate the creativity and cleverness of implementers).

New servers with legacy clients risk breaking clients that can't cope with
"revoked" in this case, as you noted:

>>> any other approach would break backward compatibility with
>>> legacy clients.

Both of these are justifications for "optional", as these RFCs apply to both
clients and servers.

Thanks,
--David

> -----Original Message-----
> From: Piyush Jain [mailto:[email-masked]]
> Sent: Friday, March 29, 2013 1:13 PM
> To: 'Stefan Santesson'; Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; gen-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Not arguing that it should be required. I'm with you on keeping it optional.
> 
> It is your statement about backward compatibility to justify it that is
> incorrect.
> Backward compatibility "with deployments of RFC2560" is not affected in
> either case. Legacy clients will continue to work whether you make it
> required or optional.
> 
> You probably meant "maintain compliance with RFC 2560 and RFC 5019."
> 
> -Piyush
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Friday, March 29, 2013 9:37 AM
> > To: Piyush Jain; 'Black, David'; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> >
> > On 3/29/13 5:17 PM, "Piyush Jain" <[email-masked]> wrote:
> >
> > >' "revoked" status is still optional in this context in order to
> > >maintain backwards compatibility with deployments of RFC 2560.'
> > >
> > >I fail to understand this statement about backward compatibility.
> > >How does "revoked" being "optional/required breaks backward
> > compatibility?
> > >The only reason cited in the WG discussions to use revoked for
> > >"not-issued"
> > >was that any other approach would break backward compatibility with
> > >legacy clients. And now the draft says that revoked is optional because
> > >making it required won't be backward compatible.
> >
> > Yes. Making it required would prohibit other valid ways to respond to this
> > situation that is allowed by RFC 2560 and RFC 5019.
> > Such as responding "good" or responding with "unauthorized" error.
> >
> > >
> > >And it gives the impression that best course of action for 2560bis
> > >responders is to start issuing revoked for "not-issued", which is far
> > >from the originally stated goal to provide a way for CAs to be able to
> > >return revoked for such serial numbers.
> >
> > The latter is what optional means.
> >
> > /Stefan
> >
> 
>

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 2 Apr 2013 16:36:11 +0200

Stefan,

When revoked for "not-issued" is created by OCSP server then according to actual rfc2560bis is unclear, what must be included in thisUpdate and nextUpdate fields.
Rfc2560bis must also define rules for value of thisUpdate and nextUpdate fields.

RFC 2560:
   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate

Peter

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Apr 2013 16:54:41 +0100

Peter,

Those fields are not treated in any special way depending on what status
you provide in a response.

/Stefan

On 4/2/13 3:36 PM, "Peter Rybar" <[email-masked]> wrote:

>Stefan,
>
>When revoked for "not-issued" is created by OCSP server then according to
>actual rfc2560bis is unclear, what must be included in thisUpdate and
>nextUpdate fields.
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 2 Apr 2013 08:07:11 -0700

> Those fields are not treated in any special way depending on what status
you
> provide in a response.
This statement is no longer true with 2560bis since OCSP is no longer
equivalent to CRLs

Excerpt from Section 4.2.2
~~~~~~~~~~~~~~~~~~~~
The thisUpdate and nextUpdate fields define a recommended validity interval.
This interval corresponds to the {thisUpdate, nextUpdate}  interval in CRLs.

  .....
Responses where the nextUpdate value   is not set are equivalent to a CRL
with no time for nextUpdate (see  Section 2.4).
End
~~~

In case of revoked for non-issued, thisUpdate should probably be the start
validity of CA certificate and next Update should be current time + skew.

-Piyush

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Tuesday, April 02, 2013 8:55 AM
> To: Peter Rybar; [email-masked]
> Cc: [email-masked]
> Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15
> 
> Peter,
> 
you
> provide in a response.
> >When revoked for "not-issued" is created by OCSP server then according
> >to actual rfc2560bis is unclear, what must be included in thisUpdate
> >and nextUpdate fields.

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 18:14:18 +0200 (CEST)

> you provide in a response.

I agree that there is intentionally *no* special treatment for thisUpdate
and nextUpdate, i.e. they should probably be similar to traditional
situations when certificateHold appears on a CRL.

But since this synthesized "certificateHold" revocation for a not-issued
certificate does not originate from a CRL, an implementor might wonder
what to put into these fields when changing existing code, in particular
existing code that would copy values from the CRL for "certficateHold"
that originates from a CRL.

Anyhow, I think that rfc2560bis can not (and should not) make suggestions
for specific values.  What values would your OCSP implementation use for
"good" or "unknown" responses for the same CA?  Those values look like
they might be from the right ballpark.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 18:18:05 +0200 (CEST)

Followup to myself (to clarify):

> they might be from the right ballpark.

I meant "suggestion for _one_ specific value".  Providing a more general
guidance what might be an appropriate value would be fine.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 2 Apr 2013 09:34:03 -0700

> they might be from the right ballpark.

2560-bis states that these values correspond to those in CRLs.
Implementations that I know of set these values from the CRL for good
responses and use current time for unknown responses.

This is how 2560 defines these fields
- thisUpdate: The time at which the status being indicated is known  to be
correct
 - nextUpdate: The time at or before which newer information will be
available about the status of the certificate

So for non-issued, thisUpdate should be start of CAs validity interval (all
certs are revoked until they get issued) and nextUpdate should be current
time (a certificate with that serial can be issued anytime).

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 18:51:22 +0200 (CEST)

> time (a certificate with that serial can be issued anytime). 

Fine with me.

What I meant (and failed to clarify) is that rfc2560bis should not define
special values for thisUpdate/nextUpdate that are specific to the
"not issued reported as revoked/certificateHold" situation.

-Martin

---

From: "Andris Berzins" <[email-masked]>
Date: Tue, 02 Apr 2013 19:54:50 +0300

> time (a certificate with that serial can be issued anytime).

That would signal to relying party that relying party has received old information (old thisUpdate)
and would query again on nextUpdate and again would get old response with old thisUpdate and so on.

thisUpdate and nextUpdate should be current time IMHO.

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 2 Apr 2013 10:36:37 -0700

> 
> That would signal to relying party that relying party has received old
> information (old thisUpdate) and would query again on nextUpdate and
> again would get old response with old thisUpdate and so on.
> 

[Piyush] This is the intent.
The information is correct as of CA start validity time and can change anytime.

In this case the certificate is revoked since the CA came into being.
The only time when this information gets updates is when the certificate gets issued. At that time the response will contain thisUpdate and nextUpdate from the CRL.

---

From: "Andris Berzins" <[email-masked]>
Date: Tue, 02 Apr 2013 20:50:43 +0300

> The information is correct as of CA start validity time and can change anyti

That information is correct not only as of CA start of validity, but also on time
requested, and therefore thisUpdate should be set to the current time, i.e.,
to the time that CA knows that certificate is still not issued.

This is what thisUpdate is about. Why to fix it to some useless value?

> The only time when this information gets updates is when the certificate get
>s issued. At that time the response will contain thisUpdate and nextUpdate f
>rom the CRL.

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 20:16:34 +0200 (CEST)

another followup to myself, in order to clarify.
> > available about the status of the certificate

The original guidance in rfc2560 for thisUpdate/nextUpdate is fine with me.

> > time (a certificate with that serial can be issued anytime). 
 
What I meant (and failed to clarify) is that rfc2560bis should *NOT* define
special values for thisUpdate/nextUpdate that are specific to the
"not issued reported as revoked/certificateHold" situation, so I
effectively disagree with the latter statement.

You specific guidance on nextUpdate := current Time is actually problematic!

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

               Responses whose nextUpdate value is earlier than
   the local system time value SHOULD be considered unreliable.

because a nextUpdate = "current Time" on the OCSP responder may often
result in nextUpdate < "current Time" on the OCSP client when processing
the OCSP response.

The semantics that you might have been looking for is "nextUpdate not set".

I believe, however, that the OCSP responder should not return
"nextUpdate not set" for the not-issued situation if it would return
nextUpdate several hours or days into the future for "good", "unknown"
or CRL-originated "certificateHold" situations.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 2 Apr 2013 11:27:02 -0700

> The original guidance in rfc2560 for thisUpdate/nextUpdate is fine with
me.

[Piyush] Which original guidance? There is a note that says that these
values correspond to the values in the CRL.

> result in nextUpdate < "current Time" on the OCSP client when processing
[Piyush] Servers typically add a skew and clients typically assume a skew
when they process the response.
> The semantics that you might have been looking for is "nextUpdate not
set".
[Piyush] Agreed. Not set implies newer responses are available all the time.

> 
> I believe, however, that the OCSP responder should not return "nextUpdate
> not set" for the not-issued situation if it would return nextUpdate
several
> hours or days into the future for "good", "unknown"
[Piyush] What is the reason for this belief? I bet it contradicts with the
rationale behind marking the reason code as "onHold".

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Apr 2013 21:14:04 +0100

>values correspond to the values in the CRL.

They do.

Correspond = to be similar or analogous; be equivalent in function,
position, amount, etc.
(http://dictionary.reference.com/browse/correspond)

ThisUpdate in CRL (http://tools.ietf.org/html/rfc5280#section-5.1.2.4)

So it is analogous to the issuance date of a CRL, not necessarily THE
issuance date of a CRL.

It is obviously the most recent time when this information was known to be
correct, as per definition.

This is all inherited from RFC 2560 and has not caused confusion to my
knowledge.

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 22:05:34 +0200 (CEST)

> values correspond to the values in the CRL.

The meaning of thisUpdate/nextUpdate as described in rfc2560 section 2.4:

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

   2.4 Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

> when they process the response.

I tend to distinguish these three:
  -  servers defensively adding "slack" (when creating timestamps),
     positive slack for timestamps in the future, negative slack for
     timestamps that represent current time or time in the past.
  -  clients accounting for clock skew when comparing timestamps
     from received or cached PDUs to current time
  -  clients additionally allowing a grace period for revocation
     information that is outdated (i.e. beyond it's accompanying nextUpdate)

During verification of CRLs, my client code ignores thisUpdate, does
_not_ use a clock skew for nextUpdate, and would allow a user-configurable
grace period.

> [Piyush] Agreed. Not set implies newer responses are available all the time.

The "nextUpdate not set" semantics also discourages a client from caching
this revocation information.  There may be situations or environments,
when this is desired, but the impact on the client processing latency and
OCSP responder load should be carefully weighed.

> > several hours or days into the future for "good", "unknown"

Technically, the "good" status is no less temporary than the certificateHold
status (that includes the CA-asserted and CRL-published certificateHold).

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 2 Apr 2013 14:08:56 -0700

http://dictionary.reference.com/browse/correspond also lists the meaning as
"to be in agreement or conformity" and this is how responder implementations
interpret it today (at least for good and revoked certificates).
The reason these specs are created is to avoid ambiguity and have
implementers interpret it in a consistent way.

> correct, as per definition.
Is this based on your understanding of how existing responders set
thisUpdate in OCSP response or is it based on the dictionary meaning of
"correspond"?

For this boundary case where revoked cannot be tied to the CRL, implementers
have to think about what value to put in this field.
You seem to be saying that the right value for this field is current time. 

> Sent: Tuesday, April 02, 2013 1:14 PM
> To: Piyush Jain; [email-masked]
> Cc: [email-masked]; [email-masked]
position,
> amount, etc.
issuance
> date of a CRL.

---

From: [email-masked] (Martin Rex)
Date: Tue, 2 Apr 2013 23:26:13 +0200 (CEST)

Stefan Santesson wrote:
>
> "Piyush Jain" <[email-masked]> wrote:
> > 

Correct.  thisUpdate/nextUpdate is determined by the OCSP responder.

It might be copied from a base CRL used in determining the certificate
serial status (even for CAs that publish deltaCRLs, in case that
the OCSP responder supports only baseCRLs).

It might be copied from a delta CRL.

It might be based on meta-knowledge about _real_ update frequency of
base&delta CRLs (rather than the nextUpdate validity suggestion
that is conveyed within base&delta CRLs nexUpdate).

It might be based on other information sources besides CRLs, to which the
OCSP responder has access, such as direct access to a CA cert status
database, and not be related to any CRLs.

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 3 Apr 2013 09:58:14 +0200

In this case when response is only about, as proposed by Piyush "Section 2.2 extends the use of the "revoked" response for certificate serial numbers that are not associated with any issued certificates.", such serial number it does not represent certificate and applications MUST not use it for validations, because certificate does not exist.

When applications already have such certificate then applications MUST start appropriate actions to inform users to contact CAs where it will be resolved.

Such additional recommended steps must be included in rfc2560bis note.

When is used the "revoked" response for certificate serial number that is not associated with issued certificate then the OCSP nextUpdate field is not used and OCSP thisUpdate field is better to be set to some strange value or to proposed value of issuer CA cert notBefore.

Probably "the virtual/fake certificate" unknown to CA or OCSP server has expired nearly after or at the time from issuer CA cert notBefore field. :o)

Peter

---

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 10:11:03 +0200 (CEST)

Peter Rybar wrote:
> 
> When is used the "revoked" response for certificate serial number that
> is not associated with issued certificate then the OCSP nextUpdate
> field is not used and OCSP thisUpdate field is better to be set to some
> strange value or to proposed value of issuer CA cert notBefore.

I strongly disagree and consider this a bad idea.

There is already a special value assigned to the revocationDate.
Messing around with thisUpdate/nextUpdate is not going to provide
any additonal value, but will cause confusion, be incompatible with
the rfc2560-defined semantics of thisUpdate/nextUpdate and may even
cause problems -- depending on the ordering of the checks performed
while processing an OCSP response.

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 3 Apr 2013 10:35:37 +0200

Yes, "revoked" response for certificate serial number that is not associated with issued certificate can confuse validations systems.

When is used the "revoked" response for certificate serial number that is not associated with issued certificate and the OCSP thisUpdate value is actual time X and real certificate was issued in some short time before X then it will be a real confusion for clients ordering responses according to OCSP thisUpdate value when OCSP database will be later updated with a real issued certificate with the same serial number.  

To avoid it the value of thisUpdate of not issued cert must be older then thisUpdate of real certificate with the same serial number.

Peter

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 10:11 AM
To: Peter Rybar
Cc: 'Andris Berzins'; 'Piyush Jain'; 'Stefan Santesson'; [email-masked]; [email-masked]
Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

-Martin

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 16:23:09 -0400

Peter,

The ocsp responder can only act on the information it has.  If the 
responder knows that the certificate was issued, then it wouldn't send a 
response indicating the status it knows about (good/revoked/unknown); if 
it's revoked it won't include the special revovationTime.  If the 
responder doesn't know the certificate was issued before time X, then 
the response will include the revoked with the special revocationTime. 
If the client goes back later and asks again, the responder now can 
respond indicating the status it knows about (good/revoked/unknown); if 
it's revoked it won't include the special revocationTime.

I don't see any requirement in RFC 2560 or 2560bis for clients to order 
requests according to thisUpdate.

spt

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 23:10:35 +0200 (CEST)

> requests according to thisUpdate.

Correct observation.

After this discussion, I believe this lack of documented requirement(s)
(for OCSP response caching and updating of that cache) to be a defect
of rfc2560/rfc2560bis.

rfc2560 provides exactly zero guidance on OCSP response caching,
and when an OCSP responder obtains certificate serial status information
from different information sources, then this creates a potential and
non-obvious ambiguity for implementors.

rfc2560bis introduces the explicit notion of OCSP responders feeding
on multiple information sources (such as CRLs _plus_ direct access
to cert issue records), so I think continued silence on OCSP response
caching and the exact semantics of thisUpdate for OCSP cache updates
a bad idea that may result in real interop problems.

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

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 10 Apr 2013 11:01:00 +0200

The value of thisUpdate is important and must contain correct time value according to the time when information about the certificate status was updated from CA issuing certificates whose status CRL or OCSP provides.

When OCSP is based on database then thisUpdate contains the time when OCSP database was updated according to information from CA.
When OCSP is based on CRL then thisUpdate of OCSP contains the same value as is included in thisUpdate field of last CRL or delta CRL available for OCSP responder.
It means the value of thisUpdate is not actual time and must be also correct for non-issued cert status. But, which time is correct for non-issued cert status? It must be also the time value when white list was updated in OCSP database with data provided by issuer CA of certificates whose status OCSP provides.

Practical usage:

In case when the validation system must provide information about the certificate status which is stable and will not be later changed, then the system must provide also the point of the time in the past when such certificate status was declared as correct.

Such point of the time is indicated in CRL or in OCSP response by the time value in the field thisUpdate.

ITU-T X.509 defines rules for CRL about the time value of thisUpdate when the revocation time revocationDate is included in first CRL (subsequent CRL contains this value of revocationDate).

RFC 2560 defines semantics of thisUpdate field as:
   - thisUpdate: The time at which the status being indicated is known to be correct.

According to such semantics of thisUpdate fields in CRL or in OCSP the validation system provides the value of thisUpdate field in the validation result as the time to which the status of certificate is known as correct while any time later the certificate status can be changed if thisUpdate is not after the expiration time of the certificate.

Peter Rybar

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, April 08, 2013 11:11 PM
To: Sean Turner
Cc: Peter Rybar; [email-masked]; [email-masked]; [email-masked]; 'Stefan Santesson'
Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

Correct observation.

-Martin