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) <priti...@cisco.com>
Sent: Wednesday, April 1, 2020 18:35
To: Esko Dijk <esko.d...@iotconsultancy.nl>
Cc: Michael Richardson <mcr+i...@sandelman.ca>; Benjamin Kaduk <ka...@mit.edu>;
anima@ietf.org
Subject: Re: [Anima] Benjamin Kaduk's Discuss on
draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
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 <esko.d...@iotconsultancy.nl> wrote:
>
> 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 <anima-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: Tuesday, March 31, 2020 22:42
> To: Benjamin Kaduk <ka...@mit.edu>; The IESG <i...@ietf.org>;
> draft-ietf-anima-bootstrapping-keyin...@ietf.org; anima-cha...@ietf.org;
> anima@ietf.org; tte+i...@cs.fau.de
> Subject: Re: [Anima] Benjamin Kaduk's Discuss on
> draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
>
>
> Benjamin Kaduk <ka...@mit.edu> 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 <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
