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

From: Esko Dijk <[email-masked]>
Date: Wed, 1 Apr 2020 09:16:32 +0000

Michael, Could you clarify what you mean with "EE certificate" and "domain's EE certificate" ? Of which entity? And how can a domain have an end entity certificate - I expect this to always be a CA?

I share Ben's view that the pinned-domain-cert is a CA certificate. If not the case, then the text needs to be updated in several places. 

Based on the discussion, trying to list some practical cases we can have of the pinned-domain-cert:

1. the Registrar's certificate, which is an RA type certificate at least. (It MAY be a CA certificate instead of RA, if the Registrar itself acts as CA non-delegated. )
  This is the most narrow pinned certificate that enables the Pledge to validate the Registrar it's talking to. If we allow RA certificate pinning then the BRSKI text needs to be updated!
2. the Domain CA certificate used by the EST server (=Registrar) to sign newly created certificates. (This MAY equal the Registrar's certificate, although it typically will not be.)
  This is a wider pinned certificate that enables the Pledge to validate the Registrar it's talking to, and also validate the Domain CA that will be used later on to issue operational certificate via EST.
  It is not necessarily a root CA certificate. This case is compatible with current BRSKI text.
3. a Domain CA cert of a domain larger than the above EST CA.
  It is not necessarily a root CA certificate. This case is compatible with current BRSKI text.
4. the root CA cert of the Domain.
  This case seems compatible with current BRSKI text, although the text suggest that typically the root CA is something with wider scope, beyond the pinned-domain-cert. (But not necessarily)

Also there are use cases where full PKI is used, and other use cases where a "cheap" self-signed root CA (not using PKI) is used for e.g. a building installation - I say that both cases need to be supported by BRSKI.
In the latter case, the self-signed limited-scope root CA will typically be used as the pinned-domain-cert. And the EST server will create certificates signed by this same root CA.

Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, March 31, 2020 22:42
To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

Benjamin Kaduk <[email-masked]> wrote:
    > My interpretation of "pinned-domain-cert is always a CA certificate" seems
    > to have persistent support throughout the text:

I see how you might conclude that the pinned-domain-cert is always a CA
certificate from the text, rather than being a trust-anchor that the pledge
is to use to validate the chain that it got.

It certainly can be a CA certificate. That does work, because when the
pledge puts it into it's trust-anchor list, the result is that it is able to
validate the TLS Server Certificate of the provisional TLS connection.
But, it has no RFC6125 process it can follow to validate a name.

It does not have to be *the* CA root certificate, it could be some
intermediate CA if such a thing existed (such as an Enterprise CA), and in
some cases, if this was a public trust root and there were no path
constraints, that might actually be *insecure*, since that would authenticate
any TLS connection.

I think that this means that the voucher would be able to validate any
owner within that public CA's list.  It's okay if it's a private CA.

Eliot says in the call:
      The pinned-domain-cert must include sufficient chain to validate the TLS
      connection.  This certificate must only be used for this purpose.
      Longer use trust anchors are retrieved as part of the EST /cacerts request.

My implementation of the MASA puts the EE certificate in which is as narrow
as one can be.  The Siemens implementation puts in the CA certificate, and we
interoperate because of how we treat this on the pledge.  Siemens has much
stronger supply chain restrictions though.

This is the diff that I would make.
I am most concerned about the difference in the voucher:

-        <t hangText="pinned-domain-cert:">The domain CA cert. See <xref
+        <t hangText="pinned-domain-cert:">The domain's EE cert. See <xref

Because this is too narrow rather than too wide now.

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index b800ec3..3bdf797 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2143,11 +2143,11 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
             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
+            The EE certificate will be used to populate the
             "pinned-domain-cert" of the voucher being issued.
           </t>
           <t>
-            If this domain CA is unknown to the MASA, then it is to be
+            If this 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
@@ -2377,7 +2377,7 @@ 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:">The domain's EE cert. See <xref
           target="MASApinned"/>. This figure is illustrative, for an example,
         see <xref target="exampleprocess" /></t>
         <t hangText="serial-number:">The serial-number as provided in the
@@ -2454,10 +2454,12 @@ 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>
+            The 'pinned-domain-cert' element of the voucher contains the
+            domain CA's issued EE certificate. 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
             pinned-domain-cert trust anchor from the voucher then the TLS
             connection is immediately

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 1 Apr 2020 16:35:08 +0000

On the discussion of what the ‘pinned-domain-cert’ is please refer to the language of RFC8366:

      leaf pinned-domain-cert {
        type binary;
        mandatory true;
        description
          "An X.509 v3 certificate structure, as specified by RFC 5280,
           using Distinguished Encoding Rules (DER) encoding, as defined
           in ITU-T X.690.
           This certificate is used by a pledge to trust a Public Key
           Infrastructure in order to verify a domain certificate
           supplied to the pledge separately by the bootstrapping
           protocol.  The domain certificate MUST have this certificate
           somewhere in its chain of certificates.  This certificate
           MAY be an end-entity certificate, including a self-signed
           entity.";

Within that document we opted for this language as it supports a large set of use cases including offline voucher issuance etc. It supports pinning a specific end-entity and it supports pinning a CA. Each of these have operational benefits as discussed extensively throughout this working groups activities. The example voucher’s within draft-ietf-anima-bootstrapping-keyinfra-39 are consistent with this. 

This discussion has raises a discontinuity though. The brski draft encourages, actually mandates, using the CA certificate. This is too likely too strong of a “be conservative in what you do” as it limits use of public CA infrastructures and it causes confusion in the intended pledge behavior of “be generous in what you accept”. 

To resolve this the draft can be slightly less explicit in which certificate is sent from the registrar to be pinned. This is not as conservative as the current language but ensures all uses cases envisioned by the RFC8366 work is maintained. The following is a summary of changes intended but expect an actual diff real soon:

s 5.5. Registrar Requests Voucher from MASA
"The entire registrar certificate chain, up to and including the Domain CA, MUST be included in the CMS structure.”
This sentence will be softened to allow the registrar flexibility to choose how high up the chain to pin. This is ‘less conservative’ and admits the flexibility intended. 

s 5.5.2 MASA pinning of registrar
"This CA certificate will be used to populate the "pinned-domain-cert" of the voucher being issued.”
This sentence to clarify that the highest cert in the chain submitted by the registrar is used rather than the explicit CA certificate. This is being more “generous in what you accept”. 

s 5.6.2 Pledge authentication of provisional TLS connection
"The 'pinned-domain-cert' element of the voucher contains the domain CA's public key.” 
This language aligned with the RFC8366 language to ensure we maintain the “generous in what you accept” behavior intended by RFC8366. 

Michael is a rock star and is working on the actual text changes. 

-max

> On Apr 1, 2020, at 3:16 AM, Esko Dijk <[email-masked]> wrote:
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Apr 2020 14:25:30 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Apr 2020 15:45:40 -0400

> have of the pinned-domain-cert:

I believe that we concur on the uses.
I'm not sure if you are saying the CA:TRUE is a requirement.
I do not want to mandate that.  CA:TRUE is, of course, acceptable.

I think that today's revised text supports all of your use cases.
If you find some fell out of bounds, then it's a mistake.

    > In the latter case, the self-signed limited-scope root CA will
    > typically be used as the pinned-domain-cert. And the EST server will
    > create certificates signed by this same root CA.

I believe that by number of Registrar's the self-signed private CA will be
the most common.   It is what I have suggested in
draft-richardson-anima-registrar-operations.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Apr 2020 20:01:10 -0700

> 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.

> +          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."?

> +          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.

> +          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/.)

> +          certificate from that authority to assume ownership of a device

Maybe "any entity issued a certificate by that authority"?

> +          Future work may provide a solution to pin both a certificate and a

", that would reduce such risk of malicious ownership assertions"?

> +          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.)

> +            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"?

> +            Supply Chain Integration, the mechanism used by the Registrar to

This seems like a misplaced comma or incomplete list or something.

>              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.

---

From: Esko Dijk <[email-masked]>
Date: Thu, 2 Apr 2020 06:46:59 +0000

> I do not want to mandate that.  CA:TRUE is, of course, acceptable.

The current BRSKI text to me suggests that CA:TRUE is a requirement for the pinned-domain-cert. But I'm okay with not having CA:TRUE for this certificate, as you propose, in which case I think the BRSKI text needs some minor updates on the wording.
For example, if it's just a Registrar cert with CA:FALSE and RA:TRUE then it shouldn't be called a "domain CA" cert or "domain cert".

If the Registrar is not a CA, it does need to be a Registration Authority (RA). (See Section 2.5.3 / 2.5.5 / 5.5.4 / https://tools.ietf.org/html/rfc6402#section-2.10 )
So the requirement for the pinned cert is that it is either RA or CA.  (Both seems also possible to encode in the cert, although that seems equivalent to a CA.)

Esko

---

From: Esko Dijk <[email-masked]>
Date: Thu, 2 Apr 2020 08:46:14 +0000

Hello Max,

Taking the RFC8366 text you quote, and especially this part:

> The domain certificate MUST have this certificate
>           somewhere in its chain of certificates.  

It seems quite a strong requirement. The domain certificate mentioned in the text is there defined as is the certificate that the Pledge will later obtain via EST (as part of BRSKI) , and the text requires that the pinned certificate MUST be in the cert chain of that EST-certificate.
It cannot be an RA:TRUE and CA:FALSE certificate, I think, because a certificate chain should have CA certificates only except for the first cert (which is the domain EE cert obtained via EST).
A CA:TRUE certificate for the domain certificate would meet that requirement.

Or am I overlooking something?

Esko

-----Original Message-----
From: Max Pritikin (pritikin) <[email-masked]> 
Sent: Wednesday, April 1, 2020 18:35
To: Esko Dijk <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

-max

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Apr 2020 13:54:51 -0400

Hi, I have applied your edits. Some were already pointed out by Max.
I have changed all instances of cmcRA to id-kp-cmcRA, and noticed that I had
two typos of "cmcRC".

> the -40, that would be greatly appreciated.

I have made that change.

I have added to C.2:
        <t>
          For readability, the output of the asn1parse has been truncated at
          72 columns rather than wrapped.
        </t>

I found that wrapping the long sequences of HEX numbers did not contribute to
understanding, and was just burning "trees".  It's the sequence/etc. that
probably matters.  If the asn1parse output is totally meaningless, I would
not be opposed to removing it.
The goal of these examples is to provide input to other implementations.

I have generated -40 and I am posting it now.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Apr 2020 22:01:28 -0400

Esko Dijk <[email-masked]> wrote:
    > The current BRSKI text to me suggests that CA:TRUE is a requirement for
    > the pinned-domain-cert. But I'm okay with not having CA:TRUE for this
    > certificate, as you propose, in which case I think the BRSKI text needs
    > some minor updates on the wording.

    > For example, if it's just a Registrar cert with CA:FALSE and RA:TRUE
    > then it shouldn't be called a "domain CA" cert or "domain cert".

    > If the Registrar is not a CA, it does need to be a Registration
    > Authority (RA). (See Section 2.5.3 / 2.5.5 / 5.5.4 /
    > https://tools.ietf.org/html/rfc6402#section-2.10 )

    > So the requirement for the pinned cert is that it is either RA or CA.
    > (Both seems also possible to encode in the cert, although that seems
    > equivalent to a CA.)

I think you that you are likely correct: every entry in a chain which is not
the EE, has CA:TRUE, and the last one, is the Registrar which ought to have
cmcRA set.

If I were to locate a PKIX-lawyer hat, I would say that the Pledge SHOULD
check this.   Given that there is a strong desire to operate registrar's
using only certificates obtained via ACME (LE), and it will be difficult to
get cmcRA set... I don't know what to do here.
  <Please insert long EMU Thread here>

We have written in the ACP document that a device SHOULD verify the cmcRA bit
is set on any EST server that the device speaks to to renew it's certificate.

Please note that I am saying "device" and not pledge!
We did not insist on cmcRA be set in section 5.1, specifically because we
didn't know if RA:TRUE was something we could insist upon here.

---

From: Esko Dijk <[email-masked]>
Date: Mon, 6 Apr 2020 11:19:14 +0000

Hello Michael,

Currently BRSKI Section 5.5.4 has this text:

   The MASA MUST verify that the registrar voucher-request is signed by a registrar

If the Registrar would use a non-RA certificate e.g. ACME (LE) standard EE certificate, then it seems that it cannot get anything from MASA...?
And BRSKI would not work?

Esko

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Apr 2020 20:39:52 -0400

> Currently BRSKI Section 5.5.4 has this text:

    doc> The MASA MUST verify that the registrar voucher-request is signed by a registrar

    > If the Registrar would use a non-RA certificate e.g. ACME (LE) standard
    > EE certificate, then it seems that it cannot get anything from MASA...?

I agree that there are potential issues here.

1) I think that the MASA may skip that check for recognized registrars, so
   that the ACME integration work can work.  This would be a local
   configuration.

2) It may be that draft-ietf-acme-integrations and/or
   draft-friel-acme-subdomains may need to specify a way to ask for cmcRA to
   be set within ACME, when using ACME when doing the pre-authorization for "domain.com"
        cf: NOTE: Pre-Authorization of "domain.com" is complete
   The ACME spec does support authorizations for domains, and maybe that
   would be the best way to do this.
   This also supports the concept that the cmcRA bit ought to apply to all RA
   operations (CMP and well as EST), as proposed in LAMPS.

I think that we should perhaps plan a design team meeting/BOF around this discussion.

---

From: Esko Dijk <[email-masked]>
Date: Mon, 20 Apr 2020 09:06:55 +0000

>    that the ACME integration work can work.  This would be a local

This option sounds acceptable to me - if the MASA is pre-configured to trust a particular certificate supplied by the customer, then it can be set as trusted as an authorized RA for that customer.  Although doing the "RA check" on the Registrar cert would be an even more secure solution, thinking about some possible attacks where an employee could misuse this process to get his/her own EE certificate approved to 'act as RA'. But it's up to the manufacturer & customer here to choose the solution that works and provides sufficient security in their view.

>    be set within ACME, when using ACME when doing the pre-authorization for "domain.com"

It would be great if such functionality is supported.  I do not currently follow ACME in any way so I hope others have opportunity to bring this idea in.

Esko

IoTconsultancy.nl  |  Email/Skype: [email-masked]