Whoops, this one apparently got skipped over amid some other deluge in my
inbox; sorry.

On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote:
> Benjamin Kaduk <ka...@mit.edu> wrote:
>     > That specific construction would seem like an "optional feature" per
>     > 
> https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
>     > ...
> I re-read this, and this as to do with References, and so anything optional
> referenced in section 7 would still need to be a Normative Reference.
> The stickler I see right now is [I-D.ietf-netconf-keystore].
> I don't want to hang on MISREF on that document; it's just one of many that
> could be used, and I do not want to tell manufacturers that they have
> to use this specific protocol to update trust anchors.
> There are many other protocols that they presently support which they could
> use, in particular, a CLI interface would be fine.
> I think that this 7.4.3 section that creates a factory default which isn't
> the default from the factory should be worry people who care about remote
> attestation of software.
> Adam has been particularly vocal about the need to specify something
> normative that manufacturers have to provide in order to resale and operation
> with the availability of the MASA.
> It seems that we might need another round of discussion on this topic.
> I feel that we are being pushed to describe the entire security lifetime of
> the device; that we need to solve the entire management problem of devices in
> our document.  (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't
> understand what would be a reasonable answer, if what I've written is not 
> enough.
> Maybe a virtual interim discussion!   If so, please let me know.

I think I'm going to have to leave this one to Adam et al.

> ANIMA/Iot-Onboarding has some time booked already:
> https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01
> ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw)
>     >> section 9:
>     >> In recognition of this, some mechanisms are presented in
>     >> Section 7.2.  The manufacturer MUST provide at least one of the one-
>     >> touch mechanisms described that permit enrollment to be proceed
>     >> without availability of any manufacturer server (such as the MASA).
>     > ... but this is a somewhat different construction.  In isolation, it 
> looks
>     > more like "MUST do at least one of X, Y, Z" without condition on "wish 
> to
>     > do W", and if X, Y, and Z are all in the same place, that place seems
>     > normative to me.  (I will confess I've rather lost track of exactly why
>     > we're debating if this is normative or not; I guess it's just the
>     > disclaimer in Section 7 about "considered non-normative in the 
> generality
>     > of the protocol".)
> Yes, it's MUST do one of X,Y,Z.
> So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being 
> false.

If "ignore all of Section 7.2" is not an option, then at least some part of
it is normative.  "You just get to choose which part" :)


Anima mailing list

Reply via email to