Hi, Since I won't be in Prague, I'd like to express strong support for this work. I do have one question. Is the following use case also valid? (I see the "Building automation" case as a subset of this case, not to mention all kinds of industrial control systems.)
3.2.5. Infrastructure isolation policy This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI resources will be allowed in carefully controlled short periods of time, for example when a batch of new devices are deployed, but impossible at other times. Regards Brian Carpenter On 11-Mar-19 22:52, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Support of asynchronous Enrollment in BRSKI > Authors : Steffen Fries > Hendrik Brockhaus > Eliot Lear > Filename : draft-fries-anima-brski-async-enroll-00.txt > Pages : 18 > Date : 2019-03-11 > > Abstract: > This document discusses the enhancement of automated bootstrapping of > a remote secure key infrastructure (BRSKI) to operate in domains > featuring no or only timely limited connectivity to backend services > offering enrollment functionality like a Public Key Infrastructure > (PKI). In the context of deploying new devices the design of BRSKI > allows for online (synchronous object exchange) and offline > interactions (asynchronous object exchange) with a manufacturer's > authorization service. It utilizes a self-contained voucher to > transport the domain credentials as a signed object to establish an > initial trust between the pledge and the deployment domain. The > currently supported enrollment protocol for request and distribution > of deployment domain specific device certificates provides only > limited support for asynchronous PKI interactions. This memo > motivates support of self-contained objects also for certificate > management by using an abstract notation to allow off-site operation > of PKI services, with only limited connectivity to the pledge > deployment domain. This addresses specifically scenarios, in which > the deployment domain of a pledge does not perform the final > authorization of a certification request and rather delegates this > decision to an operator backend. The goal is to enable the usage of > existing and potentially new PKI protocols supporting self- > containment for certificate management. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-fries-anima-brski-async-enroll-00 > https://datatracker.ietf.org/doc/html/draft-fries-anima-brski-async-enroll-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
