Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

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.


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)
+          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.
+        </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
+          too open, and could permit any entity that can receive a
+          certificate from that authority to assume ownership of a device
+          that has a voucher pinned.
+          Future work may provide a solution to pin both a certificate and a
+          name.
+        </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
+          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
+            from the Registrar as appropriate determined by MASA policy.
+            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
+            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



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-