Just on this text:

In Section 10.3 the following text exists:

   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
      upon seeing a manufacturer's trust anchor for the first time, and
      then the trust anchor would be installed to the trusted store.
      There are risks with this; even if the key to name is validated
      using something like the WebPKI, there remains the possibility
      that the name is a look alike: e.g, c1sco.com, ..

First, this isn’t REALLY Trust-On-First-Use, and I would prefer that the term 
be replaced with something like "out-of-band approval".  This would also be a 
good area for certification services to step in to indicate the trustworthiness 
of a manufacturer.

Eliot

> On 21 May 2019, at 23:21, The IESG <[email protected]> wrote:
> 
> 
> The IESG has received a request from the Autonomic Networking Integrated
> Model and Approach WG (anima) to consider the following document: -
> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
>  <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard
> 
> This is a second Last Call. IoT Directorate review was done after the ANIMA
> WG Last Call and consensus to request the publication, and that review 
> resulted
> in substantial changes to the document.
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email protected] mailing lists by 2019-06-04. Exceptionally, comments may be
> sent to [email protected] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document specifies automated bootstrapping of an Autonomic
>   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
>   is created using manufacturer installed X.509 certificate, in
>   combination with a manufacturer's authorizing service, both online
>   and offline.  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 lower security
>   models, including devices with minimal identity, is described for
>   legacy reasons but not encouraged.  Bootstrapping is complete when
>   the cryptographic identity of the new key infrastructure is
>   successfully deployed to the device but the established secure
>   connection can be used to deploy a locally issued certificate to the
>   device as well.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
> 
> The following IPR Declarations may be related to this I-D:
> 
>   https://datatracker.ietf.org/ipr/2816/
>   https://datatracker.ietf.org/ipr/3233/
>   https://datatracker.ietf.org/ipr/2463/
> 
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>    rfc8368: Using an Autonomic Control Plane for Stable Connectivity of 
> Network Operations, Administration, and Maintenance (OAM) (Informational - 
> IETF stream)
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to