internet-dra...@ietf.org wrote:
> A new version of I-D, draft-ietf-anima-constrained-voucher-02.txt has
> been successfully submitted by Michael Richardson and posted to the
> IETF repository.
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-02
Hi, we tried to act on many of the suggestions, particularly by Esko Dijk.
In issue #18, at:
https://github.com/anima-wg/constrained-voucher/issues/18
Esko asks:
Yes, this is a very useful feature and should be explained more. Also,
the current draft states the 'pinned-domain-subject-public-key-info' is
the Raw Public Key of the Registrar. This is not necessarily the
case. It could be also the raw public key of the Domain CA. This lets
the Pledge trust the entire Domain it is enrolled into. Then the Pledge
can also use this as the trust basis for its operational certificate
that it obtains via EST, which has a cert chain that leads back to the
Domain CA. See RFC 8366 Section 5.3 that explains this a bit more.
(in case of a self-signed Registrar, the current text is right -
Registrar public key equals Domain CA public key)
and we added some text to explain some more, but we felt that there was
perhaps more to be explained.
Then I re-read the suggestion above that the MASA could pin the Registrar's
Domain CA key, and I became confused. The only way this becomes useful is
if the pledge has PKI code that can evaluate certificates signed by this
DomainCA. If that is the case, then pinned-domain-cert can just be used.
Further, in BRSKI, we go from trusting the key presented as the
TLSServerCertificate
(and pinned in the voucher), so trusting the entire domain by having the
pledge ask for the list of CA anchors. (It's a standard part of EST)
Again, that requires PKI code on the pledge to be done meaningfully, and the
raw-public-key method described in the constrained-voucher process is for a
pledge that has no space for PKI code.
It probably does *not* enroll a new key using EST.
It establishes a trust relationship with the Registrar, which can later be
leveraged into an initial trust relationship for use in an ACE RS/AS
relationship. In such a situation, connection to other devices would
be mediated by authorization by ACE-OAuth, rather than just authentication
by PKI.
It should be clear that the non-PKI enrolling uses of constrained BRSKI
and constrained vouchers fall outside of the goals of the ANIMA WG.
ps: while "pinned-domain-subject-public-key-info" is a mouthful, thanks
to SID encoding, it's mapped to a 1-byte code when represented in CBOR.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
