Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

[Tom Gindin <[e-mail]>]

        Phill:

        Why do you think that a non-critical CRL entry extension will 
result in clients accepting the referenced cert?  RFC 5280 5.3 says that 
RP's can ignore unrecognized extensions to an entry, not that they can 
ignore entries containing unrecognized extensions.  A CRL entry without an 
extension (indeed, almost any CRL entry except one containing reasonCode 
removeFromCRL) implies that the certificate should be rejected for current 
use.  So marking reason non-critical shouldn't hurt anything.

                Tom Gindin




From:   Phillip Hallam-Baker <[e-mail]>
To:     Stefan Santesson <[e-mail]>, 
Cc:     "[e-mail]" <[e-mail]>
Date:   11/01/2012 09:46 AM
Subject:        Re: [pkix] Straw-poll on OCSP responses for non-revoked 
certificates.
Sent by:        [e-mail]



1 and 3b

Reading through the thread it appears that the poll has actually turned 
into 

3a Do nothing
3b Add in unknown.

But going back to the original straw poll, I think that it is pretty clear 
that any viable implementation of 'unknown' would have to be implemented 
as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL 
extension giving the revocation reason as 'It never existed'

Marking the reason as non-critical looks like it is only going to result 
in the undesired behavior as clients will reject the CRL entry completely 
and accept the cert as good. Which is stupid behavior but so was not 
having the status 'never existed'.

I would prefer the form of the OCSP 'does not exist' entry to specify a 
range of cert serial numbers that do not exist. This permits pre-signing 
of the responses and avoids a potential DoS issue.  



On Tue, Oct 30, 2012 at 5:52 AM, Stefan Santesson <[e-mail]> 
wrote:
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.






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



-- 
Website: http://hallambaker.com/
_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix