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

[Michael Richardson <[e-mail]>]

Alexey Melnikov via Datatracker <[e-mail]> wrote:
    > 1) In Section 5:

    >    o In the language of [RFC6125] this provides for a SERIALNUM-ID
    > category of identifier that can be included in a certificate and
    > therefore that can also be used for matching purposes.  The
    > SERIALNUM-ID whitelist is collated according to manufacturer trust
    > anchor since serial numbers are not globally unique.

    > I think now you are just inventing things. Please define what exactly
    > SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

https://github.com/anima-wg/anima-bootstrap/issues/132
I've asked Max to respond to this issue.

    > 2) In 5.6:

    >    assertion: The method used to verify assertion.  See Section 5.5.5.

    > Section 5.5.5 doesn't define syntax of this field in enough details to
    > implement. Can it contain one of the allowed values (like C enum)?

I agree. We seem to have lost the definition.
We insert an new section after 5.5.5 that explains this.
https://github.com/anima-wg/anima-bootstrap/issues/133

    > 3) In 5.8

    >    This is done with an HTTP GET using the operation path value of
    > "/.well-known/est/requestauditlog".

    > Here you say to use HTTP GET.

    >    The registrar SHOULD HTTP POST the same registrar voucher-request as

    > But you only define how to use POST. I think the first "GET" is
    > supposed to be "POST".

Fixed.

    > 4) In 5.8.1:

    > Format of different fields is not defined, so this is not
    > interoperable.

We think that they are, as they are either repeats of what was in the
voucher, or are integers.  I guess we should resort to CDDL, which, since we
started this document, is now a thing.
https://github.com/anima-wg/anima-bootstrap/issues/134

    > 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.

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > The first mention of HTTP 1.1 needs a Normative reference.

Added.

    > 1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices

    >    Upon successfully validating a voucher artiface, a status telemetry
    > MUST be returned.  See Section 5.7.

    > "artiface" is an unfortunate typo. I think you meant "artifact" here.

Already fixed.

    > In 2.3.2:

    >    As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
    > this extension, including the scheme, iauthority, and ipath.  As a
    > consideration to constrained systems, this MAY be reduced to only the
    > iauthority, in which case a scheme of "https://" and ipath of
    > "/.well-known/est" is to be assumed, as explained in section Section 5.

    > This is not a problem per se, but mixing absolute URIs and iauthority
    > in the same field makes me rather uncomfortable. Maybe you can define
    > ABNF for this field to make it crystally clear what is allowed
    > here. This would also avoid the need to use SHOULD and MAY above.

Adam complained that we were using IRI inappropriately, so I'll wait for his
response before changing this part.  I don't think we need ABNF.  Our goal is
to put as short a thing in the certificate as possible.
hostname:port is enough as the rest can be defaulted by the JRC.
However, we observe the need to override the entire thing, particularly when
doing interop testing, and so we want to be able to put the entire URL/IRI
in.

    > In 2.3.2: "https" URI scheme needs a Normative reference.

added reference to 7230, section 2.7.3

    > 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?

    > 4.  Proxying details (Pledge - Proxy - Registrar)

    >    In order to permit the proxy functionality to be implemented on the
    > maximum variety of devices the chosen mechanism SHOULD use the minimum
    > amount of state on the proxy device.

    > What does this mean? How can compliance with this SHOULD be evaluated?
    > I think you want to use lower case "should" here.

Agreed.

    > In 5.7 (and a similar issue elsewhere):

    >    { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail"

    > This is not valid JSON, this is not even valid pseudo-JSON. Please move
    > the comment:

Already fixed, please see changes at:
   https://tinyurl.com/y2ex324x

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-