Re: [Anima] My comments about draft-richardson-anima-registrar-considerations-02:

[Michael Richardson <[e-mail]>]

"Xialiang (Frank, Network Standard & Patent Dept)" wrote:
    > pg 6:

    > with CoAP/EDHOC, then a
    > plain CoAP interface is used, and the security (EDHOC and OSCORE)
    > lives above CoAP. For CoAP/DTLS (CoAPS) then there is DTLS layer
    > below the CoAP layer.


    > comment:
    > The first sentence can cover the last sentence.

I don't quite agree.
To an observer, either port 5683 (CoAP + EDHOC), or port 5684 (DTLS + CoAP)
is used.  This occurs through the Join Proxy.  I am rewritting.
See:
https://github.com/mcr/registrar-operational-considerations/commit/9e7461a567deb58a56d791202e8910fcd6c853bf



    > pg 6:

    > The Pledge Inteface does not require a public IP address, nor does it
    > have have to run on port 443.

    > comment:
    > use its link-local ipv6 address？how about port?

The port is announced within an ACP by GRASP AN_Proxy announcement.
When outside of an ACP context (such as with friel-anima-brski-cloud), use of
port 443 is optional as a full URL will generally be communicated.
Changes at:
https://github.com/mcr/registrar-operational-considerations/commit/26ada19df4f2178647c52fbfec537e2f2e830509


    > pg 6:

    > Outside of the ACP context, running the Pledge interface on an IP
    > address that has a FQDN that resolves to that IP address (if only
    > internally), and operating it on port 443 may have operational
    > advantages.


    > comment:
    > this paragraph is confusing, please reword

Reworded with above.


    > pg 7:

    > if the Registrar will also be providing for
    > renewal of certificates using EST, then it SHOULD announce itself
    > inside the ACP using GRASP. Unless made impossible due to loading
    > concerns, it is RECOMMENDED that all Registrar instances offer
    > certificate renewal services in this fashion.


    > comment:
    > announce itself as the EST server?

Yes.  ACP section 6.1.5.1.


    > pg 10:
    > Incidental keys for internal operations,
    > and for the BRSKI-EST server certificate can be done with this single
    > intermediate CA.



    > comment:
    > ? - I guess the question is, what are "incidental keys"

For instance, if an operator has a ticket system or a MRTG monitor,
smokeping, or other operational systems that need HTTPS certificates.
Such systems are usually not visible from the outside, and installing the
enterprise CA into desktop browsers makes sense.


    > pg 12:

    > The presentation tier
    > MUST accept all Client Certificates, many of which might it might not
    > have anchors for.


    > comment:
    > ? - I guess that more explanation is required.

I might prefer that we expand {{I-D.bdc-something-something-certificate}} to
say more!   TLS termination hardware (HTTPS Load balancers) will do the
entire TLS operation, providing HTTP to the next layer of server.  To do so,
they need to process any client side certificates.  The problem is that many
only support verifying known CAs.  In order to work in a Registrar scenario,
they need to accept any certificate chain, and to pass it onwards to the
application server.

I'm not sure how to explain this better.


    > pg 13:
    > In addition to hosting a PKI root, the Registrar needs several other
    > key pairs. They are:


    > comment:
    > It's not clear about what is the PKI root for? for MASA?

The Registrar either runs a Certificate Authority, or connects securely to one.
After onboarding, the Registrar issues an LDevID to each device from the PKI
that it runs/interfaces to.

    > pg 15:
    > The certificate used to sign the voucher-request MUST be the same as
    > the one that is used for the TLS Server Connection. This implies
    > that the signed voucher-request MUST be constructed on the same
    > machine that terminates the BRSKI-EST MASA connection.



    > comment:
    > NIT: BRSKI-EST MASA connection?

fixed.

I will post a new version after I look through some other sets of comments.


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