Subject: [core] Fwd: Re: Certificate mode in -16

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Apr 2013 21:53:22 +0300

FYI

-------- Original Message --------
Subject: Re: [core] Certificate mode in -16
Date: Tue, 30 Apr 2013 21:51:31 +0300
From: Hannes Tschofenig <[email-masked]>
To: Carsten Bormann <[email-masked]>
CC: [email-masked]

Hi Carsten,

On 04/30/2013 08:28 PM, Carsten Bormann wrote:
>     CoRE support for certificate status checking requires further work.
>     As a mapping of OCSP [RFC2560] onto CoAP is not currently defined and
>     OCSP may also not be easily applicable in all environments, an
>     alternative approach may be using the TLS Certificate Status Request
>     extension ([RFC6066] section 8, also known as "OCSP stapling"), if
>     the limitations of that extension are acceptable.

The issue with OCSP stapling is that it only provides the OCSP response
for the server's own certificate, but not the status of intermediate
certificates in the chain. Despite the constraint nature it seems that
some of the embedded folks,like the Zigbee Alliance, envision a fairly
deep certificate hierarchy.

So, you might just better go for
http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08
instead.

Since the embedded devices often have a nailed up communication
relationship an alternative is to use only shared secrets or raw public
keys instead (if you care about the communication overhead and the
lightweight nature of the CoAP environment).

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Apr 2013 20:58:36 +0200

> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08

Maybe its best to reference both; it is unfortunate that the situation here is a bit volatile.
Do you know anything about the implementation status of status_request_v2?

Grüße, Carsten