Subject: [pkix] Trusted responders in OCSP

From: Stefan Santesson <[email-masked]>
Date: Sat, 28 May 2011 21:24:34 +0200

I'm worried about the new wording in rfc2560bis regarding trusted
responders.

I've spent some time now doing actual implementation of OCSP checking using
existing libraries and I fear that current RFC 256obis will cause more
confusion and less interoperability, than if we keep 2560 as it is.

The current bis text might be all "X.509" purish but it is not very helpful
in attaining interoperability.

RFC 2560 does not deal with key rollover. It seams to assume that CAs do
what they in practice always do, i.e. They let the lifetime of their issuing
key exceed the lifetime of any certificate they issue.
The self designation express that the responder certificate "is THE
certificate of the CA" that issued the cert being checked. I interpret this
to be the CA certificate found in the cert path of the certificate being
validated.

Most implementers seems to have agreed and understood this to be an easy
check.

If (response signature can be verified by CA cert) {check OK} else {ceck
FAIL}

The same goes for designated responders:

If (designated responder cert can be verified by the CA cert) {check OK}
else {ceck FAIL}

Since this is the current configuration around which interoperability is
achieved, this is the configuration that should be promoted in rfc2560bis as
MUST implement for OCSP clients.
Anything else should be OPTIONAL.

Beyond this there are a kazillion of configuration options for allowing key
rollover, designated responders and even (which I have seen examples of)
designated CAs only issuing responder certs. These are all fine in local
communities under local policy, but no one should expect a general OCSP
client to handle them.

/Stefan

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 30 May 2011 10:11:43 +0200

I agree that, also according to my experience, this is how OCSP
validation works in practice today. Wich is probably why it generally
works quite well.

Cheers,
Tomas

On 05/28/2011 09:24 PM, Stefan Santesson wrote:
> I've spent some time now doing actual implementation of OCSP checking
> using existing libraries and I fear that current RFC 256obis will cause
> more confusion and less interoperability, than if we keep 2560 as it is.
> 
> The current bis text might be all "X.509" purish but it is not very
> helpful in attaining interoperability.
> 
> what they in practice always do, i.e. They let the lifetime of their
> issuing key exceed the lifetime of any certificate they issue.
> certificate of the CA" that issued the cert being checked. I interpret
> this to be the CA certificate found in the cert path of the certificate
> being validated.
> 
> achieved, this is the configuration that should be promoted in
> rfc2560bis as MUST implement for OCSP clients.
> Beyond this there are a kazillion of configuration options for allowing
> key rollover, designated responders and even (which I have seen examples
> of) designated CAs only issuing responder certs. These are all fine in
> local communities under local policy, but no one should expect a general
> OCSP client to handle them.
> 
> /Stefan
> 
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 May 2011 11:46:37 +0200

This is how I would like to change this section in RFC 2560bis

http://tinyurl.com/2560bis-tr

/Stefan

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 30 May 2011 15:16:22 +0200

Much clearer, and easier to read, than the current text IMHO.
Such, easy to read, texts, limiting the MUST options, are good for
interoperability.

Regards,
Tomas