Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

["Alexey Melnikov" <[e-mail]>]

Hi Michael,

On Sun, Jul 14, 2019, at 12:52 AM, Michael Richardson wrote:
> Alexey Melnikov via Datatracker <[e-mail]> wrote:
>     > 5) In 8.1:
> 
>     >    This document extends the definitions of "est" (so far defined via
>     > RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
>     > well-known-uris.xhtml" registry as follows:
> 
>     >    o add /.well-known/est/requestvoucher (see Section 5.5 )
> 
>     >    o add /.well-known/est/requestauditlog (see Section 5.7)
> 
>     > The .well-known URIs IANA registry doesn't list anything below the
>     > first level (i.e. "est" in your case). So I think you really want to
>     > have 2 IANA actions here:
> 
>     > a) Add the reference to this document as another reference for "est".
> 
>     > b) create a new registry of "est" URIs and add your 2 URIs above to it
>     > and also populate other entries from the original EST RFC.
> 
> The advice we got from the .well-known expert was that we should have this
> document Updates: RFC7030, and that the /est entry in the registry
> should say "RFC7030, RFCXXXX".  Will this be enough rather than create
> a new registry?  We think that no other /.well-known has a registry.
> 
> Tell us which way to go.

I think the answer depends on whether you want to have an easy way of finding second level URI path components under "est". I personally prefer a new registry, but I understand that it might be a bit more work in the document.

>     > 2.7.  Cloud Registrar
> 
>     >    If the pledge uses a well known URI for contacting a cloud registrar
>     > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
>     > authenticate service as described in [RFC6125].
> 
>     > Just referencing RFC 6125 is not clear enough, as there are lots of
>     > parameters that need to be specified:
> 
>     >  a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards
>     > allowed in any of these?
> 
> We think it's up to the manufacturer to define a policy here.
> This section is an out for manufacturers that wish to provide some call-home
> mitigation for when the device is deployed where no ACP can be found.
> Maybe saying "well known URI" is causing a mis-understanding?

On a re-read, the current text looks Ok as is.

Best Regards,
Alexey