Data size optimization: Pledge excludes CA cert in DTLS handshake

[EskoDijk]

One proposed optimization of (handshake) data size is the following:

• Pledge excludes the (root) CA cert in the DTLS handshake, when initially connecting to the Registrar.
• Excluding the root CA cert is a well-known method in the TLS world, see e.g. https://security.stackexchange.com/questions/65332/ssl-root-certificate-optional top answer. That's because the root CA cert will already sit in the trust store of the communication peer.
• The assumption here is that either
  • if the Registrar is of the non-promiscuous type it will already have/store all relevant Manufacturer CA certificates in its trust store. No others will be allowed anyway.
  • if the Registrar is of the promiscuous type, receive the CA cert from the Pledge won't make a difference - it's a private root CA cert with no added value or added information that Registrar could use to base its decision on.
• So, there's no need for the Pledge to send it. It will be identified by the AuthorityKeyIdentifier field in the Pledge IDevID and the Registrar can check this AKI against the items in its trust store.

This would save quite some data (100s of bytes).

For the particular case of a promiscuous Registrar that still wants to get more manufacturer info before allowing the Pledge on the network, it can connect via TLS to the MASA URI and it will get the full cert chain of the manufacturer, either public PKI or private PKI based. It can then decide whether to trust it or not.

[EskoDijk]

Email sent to ANIMA WG list: https://mailarchive.ietf.org/arch/msg/anima/H2wqXRp9zPyPilzudXrLkirMvHY/

[EskoDijk]

Discussion was done in the ANIMA design team calls earlier:

• cannot rely on TLS handshake to MASA to obtain the right CA certificate - per the BRSKI specifications, the type of authentication used on that TLS is independent of the CA that signed the IDevID certificate of the Pledge.
• best approach is to add a MASA HTTP resource for obtaining all the root CA certificates associated to Pledges being under the authority of that MASA.
• Re-use the EST resource "/cacerts" for this purpose seems easiest.

[EskoDijk]

Based on the PR text, it looks like this issue gives rise to some more complexity than originally anticipated. So I would propose to keep such work for the future.

For the present I-D we can either 1) not mention this topic at all; or 2) mention that a Manufacturer MAY build a Pledge that suppresses the root CA certificate for the IDevID DTLS handshake but that this only works if the Manufacturer has a business system in place to always deliver the correct IDevID root certs to each customer. (And how this is distributed: out of scope.)