PS, a small additional remark to my below email question: > BRSKI-35 requires MASA to pin the Domain CA cert; why would the MASA not do > this? > What the Pledge saw during the DTLS handshake is the cert chain > Registrar-cert -> Domain-CA-cert > (typically 2 certs long). At the moment the Pledge receives the Voucher > pinning the Domain CA cert > it knows it can trust the Registrar, trust the DTLS session, trust the > Domain, and trust any EST certificate > that is issued in the next step - the EST-created operational (domain) > certificates are not signed by > Registrar but by the EST CA == Domain CA. So having Domain CA as trust > anchor to validate your own > new certificate, and possibly also other device's certs in the same Domain, > makes sense.
What the Pledge saw during the DTLS handshake could also have been the Registrar-cert only (so, a chain of 2 with the self-signed root CA omitted - 1 cert sent over the wire). When the Pledge then receives the Voucher pinning the Domain CA cert it takes the Domain CA cert and uses it to validate the Registrar cert, the DTLS session etc. So it also works when the Domain CA cert is not sent during the DTLS handshake, which can be configured by the Registrar DTLS server if it would send it or not. Chains with intermediate certs are also possible but for constrained devices defining a (low) cert chain limit is useful, hence my examples with chains of 2. Esko -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Esko Dijk Sent: Wednesday, February 12, 2020 17:56 To: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) Thanks, meanwhile I read BRSKI-35 5.4 / 5.4.1 better and I am reconsidering my proposal. These sections state that the Registrar's client authentication towards MASA may differ depending on business-process and security choices; independent from the Domain (CA) authentication. In BRSKI the Domain CA is "extracted from the signature method" (5.5.2), so from the Registrar's signed CMS structure; not from identities exchanged in the TLS handshake between Registrar/MASA. This sounds like an intentional design choice of BRSKI we should stick to. When the Registrar uses CMS-signing, all the information required by MASA is in there. When the Registrar uses COSE_Sign1, there is not enough information -- only a KID identifying the keypair of the signer. But not a certificate or cert chain, so the MASA would miss this information and cannot pin anything. So am I right in concluding that the Registrar *must* use CMS-signing in case the Pledge has identified itself by certificate in the DTLS handshake? This fits with constrained-voucher-07 section 4: "The use of CMS signatures implies the use of PKIX format certificates" . Then it is also the other way around, the use of PKIX certificates (by the Pledge) implies the use of CMS signatures by the Registrar. The Pledge should still be able to sign with COSE_Sign1 I think because of the small-size benefit. It can simply use the private key of its IDevID-cert to sign. > In the more constrained cases, the Registrar is identified by a Raw Public > Key. [This works in DTLS and will work in LAKE by design] Agree that in the most constrained cases the Registrar is identified towards the Pledge by an RPK; and vice versa Pledge identifies towards Registrar with its RPK. I assume the Registrar may still identify differently towards the MASA depending on business-process taking into account the 5.4 / 5.4.1 text above. E.g., using a full certificate chain, possibly PKIX, with a completely different identity than the RPK it used towards the Pledge. But if this assumption is not right please let me know. > In the more constrained cases, the Registrar is identified by a Raw Public > Key. [This works in DTLS and will work in LAKE by design] > This is what should be pinned by the MASA, because that's what the pledge saw. Agree for this case; the only thing that can sensibly be pinned is the Registrar's RPK. Question: Is it the intention of constrained-voucher-07 that the Registrar always uses COSE_Sign1 signed Voucher Request to MASA, in case the Pledge identified itself with RPK during the DTLS handshake? (Hinted at in constrained-voucher-07 section 4. But not fully clear.) > If you are using a certificate chain for the Registrar end point, the MASA > does not have to pin the Domain CA, it can instead pin the Registrar > certificate, since again, that's what the pledge saw (and signed). BRSKI-35 requires MASA to pin the Domain CA cert; why would the MASA not do this? What the Pledge saw during the DTLS handshake is the cert chain Registrar-cert -> Domain-CA-cert (typically 2 certs long). At the moment the Pledge receives the Voucher pinning the Domain CA cert it knows it can trust the Registrar, trust the DTLS session, trust the Domain, and trust any EST certificate that is issued in the next step - the EST-created operational (domain) certificates are not signed by Registrar but by the EST CA == Domain CA. So having Domain CA as trust anchor to validate your own new certificate, and possibly also other device's certs in the same Domain, makes sense. > If you want us to define a way to pin the domain CA, then I think that right > answer is to pass that entire chain along to the Pledge in the BRSKI-EST > channel in the DTLS header, and have the pledge sign that entire object. > This wouldn't be very constrained, so I am not sure why one would do this > rather than using TLS in that case. I think this way to pin the Domain CA is already specified in BRSKI-35 and passes on quite naturally into constrained-BRSKI, and as long as the Registrar uses CMS signing in its Voucher Request towards MASA the initial problem statement is not so relevant. And it does not take a huge amount of resources (network/memory/code/time) on a Pledge. The cert chains can be kept to a minimum (i.e. chain of 2). Of course working with certificates is always more resource-demanding than RPKs-only! Best regards Esko IoTconsultancy.nl | Email/Skype: esko.d...@iotconsultancy.nl -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Michael Richardson Sent: Monday, February 10, 2020 18:56 To: anima@ietf.org Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49) In https://github.com/anima-wg/constrained-voucher/issues/49, Esko Dijk asks: > In BRSKI (5.5.2 MASA pinning of registrar) it is clear how the MASA can > get the complete cert chain of the Registrar from the CMS signature > structure. The Registrar's Domain CA cert is included in there and is used > as the pinned domain cert in the Voucher. However, when we now use > COSE-signed Voucher Request by the Registrar, the Registrar's Domain CA > cert is not included in the COSE-sign structure so the MASA cannot > "extract" it per BRSKI 5.5.2. > It would be good to make more explicit how the MASA should extract the > Registrar's Domain CA cert in this case (Note: the Domain CA could be the > Registrar itself but not necessarily.) The obvious candidate is to get it > from the DTLS or TLS handshake that Registrar performs with MASA. This is > already hinted at in the text in section 6.1.3 / 6.2.3 inside the YANG > module description "... it is wasteful ... " but that is not quite > clear. When Registrar is using COSE signing the MASA *has* to get the > certificate from the handshake if the MASA wants to pin the entire > certificate in the Voucher, there seems to be no other option. Section > 6.3.2 now mentions "out of band" distribution but that's not very clever if > you want automated bootstrapping - it needs to go all in-protocol / > in-band. > It should be noted also that this modifies the BRSKI requirement section > 5.5.2 on how the pinned Domain CA cert is obtained. In the more constrained cases, the Registrar is identified by a Raw Public Key. [This works in DTLS and will work in LAKE by design] This is what should be pinned by the MASA, because that's what the pledge saw. If you are using a certificate chain for the Registrar end point, the MASA does not have to pin the Domain CA, it can instead pin the Registrar certificate, since again, that's what the pledge saw (and signed). If you want us to define a way to pin the domain CA, then I think that right answer is to pass that entire chain along to the Pledge in the BRSKI-EST channel in the DTLS header, and have the pledge sign that entire object. This wouldn't be very constrained, so I am not sure why one would do this rather than using TLS in that case. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
