Benjamin Kaduk <[email protected]> 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 protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
