Hi Michael,
On Mon, Mar 30, 2020 at 10:10:52PM -0400, Michael Richardson wrote:
>
>
> Benjamin Kaduk via Datatracker <[email protected]> wrote:
> > Unfortunately, it seems that the "pinned-domain-cert" in the issued
> voucher
> > is the registrar's cert, not the CA cert. (Given that the documented
> > workflow is
>
> That's entirely correct.
> The thing in the voucher validates the TLS connection that the pledge sees.
I'm not quite sure if the "that" that is entirely correct is intended to be
"the voucher artifact in the -39" or "pinned-domain-cert should be the CA
cert that signed the registrar's cert".
I agree that the primary role of the pinned-domain-cert is to validate the
provisional TLS connection to the registrar, but validating a TLS
connection can be done by indicating that any certificate in the chain is
trusted, from leaf/end-entity up to root CA. If the pledge goes on to
perform full EST (which is currently listed as optional), then the exact
contents of the pinned-domain-cert don't matter in practice very much other
than validating the provisional TLS connection, but for the case where the
pledge stops after BRSKI and does not do full EST, having a domain CA
certificate seems much more useful than just knowing that the registrar's
end-entity certificate is trusted.
My interpretation of "pinned-domain-cert is always a CA certificate" seems
to have persistent support throughout the text:
Section 5.5.2:
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 Section 5.5. This CA certificate will
be used to populate the "pinned-domain-cert" of the voucher being
issued.
Section 5.6:
pinned-domain-cert: The domain CA cert. See Section 5.5.2. This
figure is illustrative, for an example, see Appendix C.2
Section 5.6.2:
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.
[...]
The pinned-domain-cert MAY be installed as an trust anchor for future
operations such as enrollment (e.g. [RFC7030] as recommended) or
trust anchor management or raw protocols that do not need full PKI
based key management. It can be used to authenticate any dynamically
discovered EST server that contain the id-kp-cmcRA extended key usage
extension as detailed in EST RFC7030 section 3.6.1; but to reduce
system complexity the pledge SHOULD avoid additional discovery
operations. Instead the pledge SHOULD communicate directly with the
[...]
but I'd be happy to learn why I'm misreading things.
As far as the bigger picture goes, I think that the BRSKI document as a
whole is essentially done, and only know of the last issues (noted in my
ballot position on the -39) that, given my current understanding of the
document, seems to be factual errors where the document is internally
inconsistent with itself. Once they get resolved (whether by educating me
on my improper understanding or by updating the text), I expect to change
my ballot position to YES so the document can get approved for publication.
(With Ignas having cycled off the IESG, it currently does not have a YES.)
I am even willing to produce an updated example voucher artifact myself, if
that would help expedite things -- I believe I already have the needed
keys/certs locally from my review of the -39. As an alternate option, if
more expedient, I could probably even accept just adding a note to the
example that says that the pledge goes on to perform full EST, so the
pinned-domain-cert is only needed to validate the provisional TLS
connection.
Please let me know if I'm missing anything here.
Thanks,
Ben
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
