Hi Brian, > Since I won't be in Prague, I'd like to express strong support > for this work. Thank you. > 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. > That sound for me like a valid use case which we can also state in the next version. Honestly, I was thinking on use cases, which lack the technical capability to alway stay online like the once stated in the draft. But yes, policy driven isolation is another perfectly fine use case. Thank you for bringing that up.
Best regards Steffen > 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
