All,
At IETF115 I mentioned an open issue for constrained BRSKI is about a proposed
optimization. Feedback is requested on this!
The idea is that the Pledge does not send the root CA certificate, as part of
the Client Certificate message of the DTLS handshake with the Registrar.
In TLS/DTLS 1.2 this root CA cert is optionally excluded, as per below text
from RFC 5246:
the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
For constrained BRSKI we could RECOMMEND the Pledge to do this, to reduce data
size on constrained networks and speed up the process.
The assumption on the Registrar is then that either one of these two cases hold:
1. Known vendor and/or sales integration: the domain owner Registrar already
has the vendor’s root CA cert for the product(s) the owner wants to bootstrap.
This it uses during handshake client verification.
2. Unknown vendor and no sales integration: the Registrar can on-the-fly
identify the Pledge based on the presented IDevID certificate in the handshake,
and fetch the vendor’s root CA cert by connecting to the MASA server over TLS.
See also Github issue
https://github.com/anima-wg/constrained-voucher/issues/239.
So if a Pledge vendor sells only under model 1), then excluding the root CA
cert is always fine.
If a vendor sells under model 2) always or sometimes, then excluding the root
CA cert is fine under the condition that the TLS connection to the MASA will
provide the needed root CA cert. If that MASA TLS connection is authenticated
otherwise (e.g. something exotic like PSK from a QR code, or using an identity
from public PKIX hierarchy not related to the Pledge’s root CA) then it implies
the Pledge MUST include the root CA cert in its Client Certificate message.
Therefore, what we achieve is a substantial savings of over-the-wire data for
the common cases.
If the proposed solution for model 2) above sounds too restrictive, an
alternative idea is to define a new HTTPS resource on the MASA server under the
path “/.well-known/brski/cacerts” which contains all the root CA certs for all
Pledges that are supported by that MASA. This HTTPS resource is only strictly
required if the vendor makes Pledges that omit the root CA certificate in the
handshake.
Regards
Esko
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
