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

[Benjamin Kaduk <[e-mail]>]

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.