On Wed, Apr 01, 2020 at 02:25:30PM -0400, Michael Richardson wrote: > > Hi, I had a discussion with Max this morning. He reminded me of the back and > forth that we made on what thing would be pinned. > We have come up with the following text changes. > > There are three pieces: the Registrar, to the MASA, and re-inforcing the > RFC8366 process at the Pledge as it applies to provisional TLS connection. > > I haven't read the rest of this thread. > I will do that this afternoon, and I may polish this diff based upon comments > there.
Thanks, this seems like it will hit all the right spots. A few aids to polishing inline. > > https://tinyurl.com/uek8a66 > > @@ -2043,8 +2044,39 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, > nil]]]></artwork> > <t>The voucher media type "application/voucher-cms+json" is defined > in > <xref target="RFC8366" /> and is also used for the registrar > voucher-request. It is a JSON document that has been > signed using a CMS structure. > - The registrar MUST sign the registrar voucher-request. The entire > registrar certificate chain, > - up to and including the Domain CA, MUST be included in the CMS > structure. > + The registrar MUST sign the registrar voucher-request. > + </t> > + <t> > + <xref target="RFC8366" /> is quite flexible in what may be put into > + the 'pinned-domain-cert': it may range from the End Entity (EE) The transition from "registrar voucher request" to "pinned-domain-cert" is pretty abrupt; maybe something like "the voucher-request CMS object includes some number of certificates that are input to the MASA as it populates the "pinned-domain-cert" field of the voucher."? > + Certificate that the Registrar uses, to the entire private > + Enterprise CA certificate. > + More specific certificates result in a tighter binding, while less > + specific certificates result in more flexibility. This leaves what exactly is tightly bound/flexible a bit vague (which may be good!); if I did want to be more specific it might be "tigher binding of pledge to authorized entity in the Domain", which ... doesn't exactly roll of the tongue. > + </t> > + <t> > + A Registrar which is seeking a nonceless voucher for later offline > use > + benefits from a less specific certificate, as it permits the actual > + keypair used by a future Registrar to be determined by the pinned > + certificate authority. > + </t> > + <t> > + A less specific certificate, such a public WebPKI certificate > authority, would be Maybe "In some cases a less specific certificate, [...], could be too open"? (Add "In some cases" and s/would/could/.) > + too open, and could permit any entity that can receive a > + certificate from that authority to assume ownership of a device Maybe "any entity issued a certificate by that authority"? > + that has a voucher pinned. > + Future work may provide a solution to pin both a certificate and a > + name. ", that would reduce such risk of malicious ownership assertions"? > + </t> > + <t> > + The Registrar SHOULD request a voucher with the most specificity > + consistent with the mode that it is operating in. > + In order to do this, when the Registrar prepares the CMS structure > + for the signed voucher-request, it SHOULD include only certificates > + which are part of the chain that it wishes the MASA to pin. > + This MAY be as small as only the End-Entity certificate (with > cmcRC set) that Hmm, we do use a bare "cmcRC" exactly once in the -39, but id-kp-cmcRA appears twice. (I'm not sure whether it matters which one to write.) > + it uses as it's TLS Server Certificate, or it MAY be the entire > + chain, including the Domain CA. > </t> > > <t>MASA impementations SHOULD anticipate future media > @@ -2140,19 +2172,29 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, > nil]]]></artwork> > > <section anchor="MASApinned" title="MASA pinning of registrar"> > <t> > - The registrar's certificate chain is extracted from the signature > - method. The entire registrar certificate chain was > - included in the CMS structure, as specified in <xref > target="RequestVoucherFromMASA" />. > - This CA certificate will be used to populate the > - "pinned-domain-cert" of the voucher being issued. > + A certificate chain is extracted from the Registrar's signed CMS > container. > + This chain may be as short as a single End-Entity Certificate, up > + to the entire registrar certificate chain, including the Domain > + CA certificate, > + as specified in <xref target="RequestVoucherFromMASA" />. > </t> > <t> > - If this domain CA is unknown to the MASA, then it is to be > + If the domain's CA is unknown to the MASA, then it is to be > considered a temporary trust anchor for the rest of the steps > in this section. The intention is not to authenticate the > message as having come from a fully validated origin, but > to establish the consistency of the domain PKI. > </t> > + <t> > + The MAY use as much of the certificate chain that it received MASA? > + from the Registrar as appropriate determined by MASA policy. Maybe comma before "determined"? > + A MASA MAY have a local policy that it only pins the End-Entity > + certificate. This is consistent with <xref target="RFC8366" />. > + Details of the policy will typically depend upon the degree of > + Supply Chain Integration, the mechanism used by the Registrar to This seems like a misplaced comma or incomplete list or something. > + authenticate. Such a policy would also determine how a > + the MASA will respond to a request for a nonceless voucher. > + </t> > </section> > > <section anchor="revocationcheck" > @@ -2377,9 +2419,10 @@ INSERT_TEXT_FROM_FILE example-voucher.json END > <t hangText="assertion:">The method used to verify the relationship > between pledge and registrar. See <xref > target="MASAassertion"/>.</t> > - <t hangText="pinned-domain-cert:">The domain CA cert. See <xref > + <t hangText="pinned-domain-cert:">A certificate. See <xref > target="MASApinned"/>. This figure is illustrative, for an example, > - see <xref target="exampleprocess" /></t> > + see <xref target="exampleprocess" /> where an End Entity certificate > + is used. </t> > <t hangText="serial-number:">The serial-number as provided in the > voucher-request. Also see <xref target="MASAassertion"/>.</t> > <t hangText="domain-cert-revocation-checks:">Set as appropriate for > the > > @@ -2454,11 +2501,20 @@ INSERT_TEXT_FROM_FILE example-voucher.json END > </section> > <section anchor="PledgeAuthenticationOfProvisionalTLS" > title="Pledge authentication of provisional TLS connection"> > - <t>The 'pinned-domain-cert' element of the voucher contains the > domain > - CA's public key. The pledge MUST use the 'pinned-domain-cert' > trust > - anchor to immediately complete authentication of the provisional > TLS > - connection.</t> > - <t>If a registrar's credentials cannot be verified using the > + <t> > + Following the process described in <xref target="RFC8366" />, > + the pledge should consider the public key from the > + pinned-domain-cert as the sole temporary trust anchor. > + </t> > + <t> > + The pledge then evaluates the TLS Server Certificate chain that > it > + received when the TLS connection was formed using this trust > + anchor. > + It is possible that the pinned-domain-cert matches the End-Entity > + Certificate provided in the TLS Server. > + </t> > + <t> > + If a registrar's credentials cannot be verified using the > pinned-domain-cert trust anchor from the voucher then the TLS > connection is immediately > discarded and the pledge abandons attempts to bootstrap with this How much more polishing/comments do you want before publishing a -40? Thanks again for putting this together! -Ben P.S. If the s/public key/certificate/ from my Comment would make it into the -40, that would be greatly appreciated. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
