New MASA /cacerts resource; and the optional omission IDevID root CA cert #261
Conversation
…DevID root CA certificate in DTLS handshake.
| This document supports efficient operation of Pledges in constrained networks, by letting a Pledge optionally omit the sending of its root CA certificate in the DTLS handshake with the Registrar. | ||
| This optimization requires a Registrar to have an alternative method to obtain this root CA certificate, which it may need for validation and logging purposes. The alternative method defined here is | ||
| that the Registrar can request the relevant root CA certificate(s) directly from the MASA. Although the operator of a Registrar may have already obtained such CA certificate(s) via a vendor-specific method | ||
| (e.g. part of sales integration), a standardized method is still needed for cases where such vendor-specific methods do not exist or are not known to the operator. |
There was a problem hiding this comment.
Should this also say something about semi-promiscuous Registrars, where a human will be asked?
Obtaining the root certificate might help the human decide WTF this new device is.
There was a problem hiding this comment.
In current text this use case is included in the broad "validation and logging purposes". Validation could be with or without human in the loop. It can be expanded a bit to mention different methods of validation; I'll think about that and do a PR update.
|
|
||
| ### Pledge CA Certificates Request | ||
| A Registrar, after having established a TLS connection to the MASA, MAY request the full set of root CA certificates for all Pledges that are managed in scope of this MASA, by sending a Pledge CA | ||
| Certificates Request. This uses a HTTPS GET with the operation MASA URI path of "/.well-known/brski/cacerts". |
There was a problem hiding this comment.
Does this amend RFC8995, (which creates the BRSKI-MASA protocol), or does it amend RFC7030 (which defined cacerts), or ??
There was a problem hiding this comment.
@pritikin might have an opinion about whether there is any IANA Considerations here.
There was a problem hiding this comment.
It does not amend 8995, since 8995 resources are left untouched. It adds a resource which be simply be recorded in the IANA registry here: https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml#brski-well-known-uris
It also does not amend RFC7030 since it targets the BRSKI protocol and not EST. The name "cacerts" is simply borrowed and can be changed if it helps for clarity (but in principle, the well-known BRSKI and well-known EST namespaces are fully separate so we can borrow the name if we want.)
The IANA section can be added in this PR once we think this is useful to have. (E.g. we might be able to quantify the performance gain and see if it's worth the extra text and complexity.)
| A successful response MUST be a certs-only CMC Simple PKI Response, | ||
| as defined in {{RFC5272}}, containing the certificates described in the | ||
| following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent | ||
| with a Content-Transfer-Encoding of "base64" {{RFC2045}}. |
There was a problem hiding this comment.
Didn't we create an alternative for certs-only?
Wouldn't it be better to mandate that?
There was a problem hiding this comment.
If we are are returning an SMIME document, maybe we should put some content in it for the human to review.
There was a problem hiding this comment.
The only alternative we have finished was for the constrained Pledge: Coap content format 287 per RFC 9148. This is "application/pkix-cert" and can carry only a single X509 certificate. This can work well if the Registrar would signal the exact identity of the Pledge to the MASA and then the MASA can return the correct root CA cert for it.
That would also avoid the problem of MASA possibly needing to return many (100s?) of certificates to the Registrar , not knowing which one the Registrar is going to need.
(We did consider some alternatives for fetching multiple certs, e.g. via Coap resources name/0, name/1, etc. to fetch N certs one by one. But not pursued)
| with a Content-Transfer-Encoding of "base64" {{RFC2045}}. | ||
|
|
||
| The MASA MUST include at least the root CA certificate(s) of the IDevID certificate chain(s) of any Pledge that the Registrar may potentially require. | ||
| To determine what the Registrar may potentially require, without knowing yet the exact identity of the Pledge, the MASA may use one or more of the following context information: |
There was a problem hiding this comment.
The Registrar probably already has the IDevID, which is how it got the MASAUrl.
Probably this request occurs before the requestvoucher?
Could a third party do usefully use this? Could a malicious party learn something from visiting it?
There was a problem hiding this comment.
The Registar indeed already has the IDevID of the Pledge, including things like serial-number and Authority Key Identifier. So it could make use of this information to signal to the MASA what root CA cert it wants to have.
That would be an extra barrier for a 3rd party to get certificate information. Not sure if a malicious 3rd party would learn much from getting all the root CA certs though.
One idea is the following: Registrar sends a POST request with a complete voucher-request object to the resource "/rootcacert" which returns in response the single X.509 root CA cert. This is similar to how a Registrar sends the voucher-request object as an identifier to request the Pledge's audit log, in RFC 8995 5.8. The voucher-request object fully identifies the Pledge as well as the domain of the Registrar, which could be useful. And it allows code re-use I guess between MASA resource handlers.
EskoDijk
added
the
future
This is a proposal how it may look like.