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

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

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

Nope, that is entirely impossible (unless the validation system is
thoroughly fubar'ed).

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

This is non-sensical.

As I just wrote in a previous message, the semantics of "certificateHold"
is essentially unchanged from X.509 08/1997:

   A certificate may be placed on hold 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).

   Once a hold has been issued, it may be handled in one of three ways:

   a) it may remain on hold with no further action, causing users to reject
      transactions issued during the hold period; or,

So if your OCSP client has a problem with processing temporary revocations,
then this problem will apply to both, CRL-based certificateHold and
certificateHold synthesized by the OCSP responder for not-issued certs,
and your OCSP client is in dire need of fixing.

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

Regular X.509v3 certificates do not have a "thisUpdate" field, so I
fail to understand this latter statement.

OCSP responses with revoked/certificateHold are (and have always been)
superseded by OCSP responses with "good" status.

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 3 Apr 2013 11:17:19 +0200

Marin,
According to e.g. RFC 2560  
- thisUpdate: The time at which the status being indicated is known to be correct.

I was pointing on other things then you have written in your last response.

The time value in thisUpdate of OCSP (or CRL) is the value of the time when the status of certificate is know as correct. It means any changes of that status e.g. indicated in OCSP revocationTime will be with the time value which is after the value of thisUpdate of any already issued OCSP (or CRL).
It means thisUpdate is upper border and critical for validation systems where revocationTime contains real revocation or only a hold.
Also when hold is used the revocation is 
in one case removed or 
in the second case associated revocationTime with hold is then associated with real reason of revocation. 
The value of revocationTime is not changed when hold is finally changed to e.g. keyCompromise!

Peter

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

This is non-sensical.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 3 Apr 2013 07:34:51 -0700

The subtle point you missed is that x.509 requires revocation date to be
after thisUpdate whereas in a non-issued revoked response revocation date
will be before thisUpdate.
And clients who worry about compliance do check for these things.

> Sent: Wednesday, April 03, 2013 1:48 AM
> To: Peter Rybar
thoroughly
> fubar'ed).
> > 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.
> certificateHold synthesized by the OCSP responder for not-issued certs,
and
> your OCSP client is in dire need of fixing.
> 
> 
> >
> Regular X.509v3 certificates do not have a "thisUpdate" field, so I fail
to
> understand this latter statement.
>

---

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 16:51:08 +0200 (CEST)

> And clients who worry about compliance do check for these things.

The subtle point you missed is that this "x.509 requirement" can
NOT possibly apply to OCSP, and for CRLs applies strictly to the very
first CRL on which the CRL is published, but *NOT* any subsequent
CRL on which the revocation is carried through.

And client who worry about rfc5280/PKIX conformance, will _not_ perform
such checks, as rfc5280 explicitly RECOMMENDS against RPs performing such
(Section 4 and Section 5) conformance checks during certificate (path)
validation.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 03 Apr 2013 16:52:04 +0100

On 4/3/13 3:34 PM, "Piyush Jain" <[email-masked]> wrote:

>after thisUpdate

You got that wrong.

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

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

Revocation date is the date on which the revocation occurred, which is
earlier than the time when the CRL, listing this revocation, was issued
(thisUpdate).

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 3 Apr 2013 08:10:58 -0700

My mistake. As Martin pointed out this applies to first CRL issued by the
CA, and the semantics of OCSP this update do not apply to CRLs.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2013 8:52 AM
> To: Piyush Jain; [email-masked]; 'Peter Rybar'
> Cc: 'Andris Berzins'; [email-masked]; [email-masked]
> >The subtle point you missed is that x.509 requires revocation date to
> >be after thisUpdate
> 
> You got that wrong.
> 
earlier
> than the time when the CRL, listing this revocation, was issued
(thisUpdate).