> > It looks like the "domain certificate" here is then not meant as (1)
> > the EE certificate that the EST server will hand to the Pledge later on
> > (as I thought), but rather (2) the Registrar's certificate that is
> > supplied to the Pledge in the initial handshake.
>
> Can you explain "later on" here?
With 'later on' I meant the moment of the first distribution of a new domain
certificate to Pledge, as part of a bootstrap process. That is, the phase
immediately following the phase of sending the voucher to the Pledge -
typically done using EST.
> The Registrar's TLS Server Certificate could be a different PKI hierarchy
> than the resulting PKI.
So the interpretation (1) above must be incorrect, as it would force EST to use
the same PKI hierarchy, with the pinned domain cert always somewhere in the
hierarchy of the EST-issued domain cert.
The piece of text in RFC 8366 inside the "leaf pinned-domain-cert { ... }" YANG
is confusing me because most mentions of "domain certificate" in the RFC refer
to the certificate that is being pinned by the voucher. (E.g. 4, 5.3, 7.3)
Called the 'pinned domain certificate' or 'domain certificate' for short.
But in this particular text "domain certificate" refers to the Registrar's
certificate - and the term "this certificate" refers to the pinned domain
certificate.
If a different PKI hierarchy is used by the EST server (i.e. the
pinned-domain-cert will *not* be in the cert chain of the cert that the EST
server issues), that seems to imply that the EST server can assign the Pledge
to an arbitrary domain, even the domain of another customer.
That seems weird, since the Registrar authenticates itself to MASA as "I'm in
domain X / customer X" and then the same Registrar in its EST server role
assigns the Pledge to "domain / customer Y". And the MASA doesn't know about
this; it logs the Pledge to "domain X".
Esko
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: Friday, April 10, 2020 02:21
To: Esko Dijk <esko.d...@iotconsultancy.nl>
Cc: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt
Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> The new text looks good now. I was still wondering about the pg 12
> requirement in RFC 8366 ; which amounts to:
> The [domain certificate supplied to the pledge separately by the
> bootstrapping protocol] MUST have [pinned-domain-cert] somewhere in its
> chain of certificates.
> It looks like the "domain certificate" here is then not meant as (1)
> the EE certificate that the EST server will hand to the Pledge later on
> (as I thought), but rather (2) the Registrar's certificate that is
> supplied to the Pledge in the initial handshake.
Can you explain "later on" here?
The Registrar's TLS Server Certificate could be a different PKI hierarchy
than the resulting PKI.
> If one interprets it like (1) then BRSKI may violate the requirement;
> if one interprets it to be (2) then all is fine.
> A few remaining nits found during reading:
Thanks. I have updated my copy of the XML, and I'll pass this on to the
RFC-editor.
Nothing is going forward until the ACP LC ends and the IESG does it's reviews.
--
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
