[cabfpub] Fwd: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Yngve N. Pettersen (Developer Opera Software ASA)]

Hi,

This is a promising development regarding OCSP responses for certificates  
that the CA does not know about.

 From sec 2.2 http://www.ietf.org/id/draft-ietf-pkix-rfc2560bis-06.txt

    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 status request
    for a non-issued certificate.

------- Forwarded message -------
From: "Stefan Santesson" <stefan at aaa-sec.com>
To: pkix at ietf.org
Cc:
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06
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.

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


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