Hi Michael,
This draft is useful for helping guy to get valuable guidance of deploying 
BRSKI Registrar entity, please see my current comments as below:

Similarily to the other document, let me put your comments into an email.

Again, many boxes were empty, so I don't know if I missed some thoughts.



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.



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?



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



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?



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"



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.



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?



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?



B.R.
Frank



This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
  • [Anima] My comments a... Xialiang (Frank, Network Standard & Patent Dept)

Reply via email to