Hi Jim,
thanks for the comments. See my reactions below.
Jim Schaad schreef op 2018-03-10 22:15:
I agree with Hannes, this version of the document is much cleaner and
much
clearer. I think that it has solved most of the problems that I
initially
had with the draft. It is not ready to progress as there are still
sections
that are marked as TODO. But it is much closer to finishing that it
was.
That sounds hopeful. Agree about the TODOs
I still have a couple of comments from a quick read through of the
document.
In section 2 - There will be a problem in that the port format
extension is
being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and
1.3
section for clarity.
You mean for backward compatibility?
In section 3- Should we be looking at the use of COSE rather than CMS
for
encryption of key services?
That is a question that needs some discussion by others.
In the recent draft-richardson-anima-ace-constrained-voucher-03, we
encrypt the CBOR serialized voucher with either CMS or COSE, as signaled
in the content format.
Also there is a new draft draft-selander-ace-coap-est-oscore-00 that
discusses the use of OSCORE for est over coap
Introduction of COSE in est-coaps draft may need alignment with the
other drafts.
You suggest to use COSE for server key generation only to better protect
the keys, and all other services to be encrypted with CMS?
* Do you have the option to additionally support the long name for the
service as well as the short name? MUST have short name MAY have long
name?
Agree, should work that out in more detail.
* In section 6- All proxies are required by CoAP blocking to
re-assemble
the entire message at the proxy. It can re-block things going to the
next
proxy. While there is no requirement that the proxy get the entire
message
before sending on pieces, this should be common practice and would be
required for a CoAP/HTTP proxy.
Agree fully, we need to clarify that.
* Should probably add a note in section 6 that any proxy that
terminates the
DTLS connection is going to be required to act as an RA. RAs are
required
to have the entire request for adding authentication as necessary.
This is visible in the figure of section 6, but needs elaboration in the
text.
Jim
Many thanks, this helps to get our text more concrete and complete.
Peter
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
