Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt

[Esko Dijk <[e-mail]>]

>      > 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 <[e-mail]> 
Sent: Friday, April 10, 2020 02:21
To: Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt


Esko Dijk <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-