Subject: Re: [Anima] I-D Action: draft-fries-anima-brski-async-enroll-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Mar 2019 10:24:36 +1300

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-masked] 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-masked]
> 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
>

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 13 Mar 2019 09:56:44 +0000

Hi Brian,

> for this work.
Thank you. 
> I do have one question. Is the following use
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 

> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima