Thanks Michael for this update,
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.
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:
"as an trust anchor" -> as a trust anchor
"how a the MASA"
"impementations" -> implementations
"identifies a Registrar by the "pinned-domain-cert" -> missing full stop
(period) at end of sentence.
"described in [I-D.ietf-anima-autonomic-control-plane]" -> missing full stop
(period) at end of sentence.
Best regards
Esko
-----Original Message-----
From: Anima <[email protected]> On Behalf Of [email protected]
Sent: Thursday, April 2, 2020 22:09
To: [email protected]
Cc: [email protected]
Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and
Approach WG of the IETF.
Title : Bootstrapping Remote Secure Key Infrastructures
(BRSKI)
Authors : Max Pritikin
Michael C. Richardson
Toerless Eckert
Michael H. Behringer
Kent Watsen
Filename : draft-ietf-anima-bootstrapping-keyinfra-40.txt
Pages : 122
Date : 2020-04-02
Abstract:
This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a
cloud service, or using only link-local connectivity, or on limited/
disconnected networks. Support for deployment models with less
stringent security requirements is included. Bootstrapping is
complete when the cryptographic identity of the new key
infrastructure is successfully deployed to the device. The
established secure connection can be used to deploy a locally issued
certificate to the device as well.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-40
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-40
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-40
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
