Re: [Ace] WGLC for draft-ietf-ace-coap-est
> -Original Message-
> From: Ace On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Tuesday, March 5, 2019 8:34 AM
> To: Klaus Hartke
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
>
> Thanks Klaus.
>
> OK about waiting for confirmation on ports returned in discovery and
> RFC6690.
RFC 6690 references to 3986 for URI-reference
RFC 3986 defines the following ABNF
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
URI-reference = URI / relative-ref
authority = [ userinfo "@" ] host [ ":" port ]
Thus yes port is just fine to include
Jim
>
> > wouldn't it also be possible to configure the client with the whole URI
> containing the three parts directly?
>
> Yes, that is perfectly possible. I don't think the draft is forbidding the
whole
> URL being configured instead of a host:port:ArbitraryLabel tuple.
>
> > I really don't see why the EST-coaps specification needs to provide
> examples for basic CoAP features that don't play a crucial role in the
> application.
>
> Understood what you meant. I removed the normative "MUST" and
> replaced the language to more explicitly state the "RECOMMENDED" for
> implementers.
>
> > Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value
of an
> option is intended to be this default value, the option SHOULD NOT be
> included in the message." [1] So your example actually violates this
'SHOULD
> NOT'...
>
> For consistency we now use FQDNs in all our /crt examples, so I think the
A.1
> is more justified.
>
> If you want to check the updated draft use
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-
> coap-est.txt
>
> Rgs,
> Panos
>
>
> -Original Message-
> From: Klaus Hartke
> Sent: Tuesday, March 05, 2019 8:45 AM
> To: Panos Kampanakis (pkampana)
> Cc: ace@ietf.org; Jim Schaad
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
>
> Panos Kampanakis wrote:
> > > But can't the client just be configured out-of-band with the URIs
directly?
> >
> > That is right. We could mandate only .well-known URIs. But I think we
> > ought to let a deployment use non-default URIs. [...]
>
> I was aiming at something different, but, re-reading my question, my
> question wasn't very clear. Let me try again.
>
> In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it
needs to
> know the host name (or IP address) and port number of a CoAP server. It
> then constructs the URI and then
> gets a list of links to the EST resources. The host name and port number
must
> come from somewhere -- e.g., from configuration or from some other
> discovery process. I'm quite happy with this.
>
> Then you were saying that, in some cases, this discovery step is
> unnecessary/wasteful. A client would instead need to know the host name
> (or IP address) and port number of a CoAP server as well as an
> ArbitraryLabel. It would then construct the URI
known/est/{ArbitraryLabel}/sen> and could immediately start interacting
> with that resource. Again, the host name, port number and ArbitraryLabel
> must come from somewhere. You were saying that they come from
> configuration.
>
> My question is: If host name, port number and ArbitraryLabel can come from
> configuration, from which the client constructs
known/est/{ArbitraryLabel}/sen>, wouldn't it also be possible to configure
> the client with the whole URI containing the three parts directly?
>
> > > 5.1 "Discoverable port numbers can be returned in the response
> payload." -- Now I'm wondering if that's actually permitted by RFC 6690...
> >
> > [...] but I think the example is OK to include the port.
>
> I'm not sure. RFC 6690 is really weird. Let me get back to you on this.
>
> > > 5.4 "All EST-coaps request messages expect an acknowledgement (with a
> response payload); EST-coaps requests are confirmable CON CoAP
> messages." -- This seems to be a matter of implementation quality and
> should not be a requirement for interoperability. I suggest to remove
this.
> >
> > We want to make use of Delayed responses. There are cases where the CA
> takes time to generate the cert/keypair, and in that case it needs to
signal
> the delay with a Max-Age or Empty ACK. That is why we use CON. The text
> justification does not explain explicitly, but we didn't want t
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Thanks Klaus. OK about waiting for confirmation on ports returned in discovery and RFC6690. > wouldn't it also be possible to configure the client with the whole URI > containing the three parts directly? Yes, that is perfectly possible. I don't think the draft is forbidding the whole URL being configured instead of a host:port:ArbitraryLabel tuple. > I really don't see why the EST-coaps specification needs to provide examples > for basic CoAP features that don't play a crucial role in the application. Understood what you meant. I removed the normative "MUST" and replaced the language to more explicitly state the "RECOMMENDED" for implementers. > Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of > an option is intended to be this default value, the option SHOULD NOT be > included in the message." [1] So your example actually violates this 'SHOULD > NOT'... For consistency we now use FQDNs in all our /crt examples, so I think the A.1 is more justified. If you want to check the updated draft use https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt Rgs, Panos -Original Message- From: Klaus Hartke Sent: Tuesday, March 05, 2019 8:45 AM To: Panos Kampanakis (pkampana) Cc: ace@ietf.org; Jim Schaad Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis wrote: > > But can't the client just be configured out-of-band with the URIs directly? > > That is right. We could mandate only .well-known URIs. But I think we > ought to let a deployment use non-default URIs. [...] I was aiming at something different, but, re-reading my question, my question wasn't very clear. Let me try again. In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to know the host name (or IP address) and port number of a CoAP server. It then constructs the URI and then gets a list of links to the EST resources. The host name and port number must come from somewhere -- e.g., from configuration or from some other discovery process. I'm quite happy with this. Then you were saying that, in some cases, this discovery step is unnecessary/wasteful. A client would instead need to know the host name (or IP address) and port number of a CoAP server as well as an ArbitraryLabel. It would then construct the URI and could immediately start interacting with that resource. Again, the host name, port number and ArbitraryLabel must come from somewhere. You were saying that they come from configuration. My question is: If host name, port number and ArbitraryLabel can come from configuration, from which the client constructs , wouldn't it also be possible to configure the client with the whole URI containing the three parts directly? > > 5.1 "Discoverable port numbers can be returned in the response payload." -- > > Now I'm wondering if that's actually permitted by RFC 6690... > > [...] but I think the example is OK to include the port. I'm not sure. RFC 6690 is really weird. Let me get back to you on this. > > 5.4 "All EST-coaps request messages expect an acknowledgement (with a > > response payload); EST-coaps requests are confirmable CON CoAP messages." > > -- This seems to be a matter of implementation quality and should not be a > > requirement for interoperability. I suggest to remove this. > > We want to make use of Delayed responses. There are cases where the CA takes > time to generate the cert/keypair, and in that case it needs to signal the > delay with a Max-Age or Empty ACK. That is why we use CON. The text > justification does not explain explicitly, but we didn't want to clutter the > wording, so we kept it simple. You're mixing up protocol specification and implementation guidance. On the protocol specification side, both clients and servers are free to choose if they want to use confirmable or non-confirmable messages. And an application should not make any restrictions on that. On the implementation guidance side, I think it makes a lot of sense to choose delayed responses here. But implementation guidance should be clearly marked as such, as not to create the impression that implementations can only use certain messages types or can rely on only certain messages types being used. > > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't > > in this example. Since it's not important for the example, maybe just > > remove Uri-Host and Uri-Port from the example and also this paragraph? > > I wanted to keep it in there. We explain that it can be assumed from DTLS if > omitted, but I think it is worth to show how the option would be included. I > had trouble finding a COAP Uri-H
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Panos Kampanakis wrote: > > But can't the client just be configured out-of-band with the URIs directly? > > That is right. We could mandate only .well-known URIs. But I think we ought > to let a deployment use non-default URIs. [...] I was aiming at something different, but, re-reading my question, my question wasn't very clear. Let me try again. In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to know the host name (or IP address) and port number of a CoAP server. It then constructs the URI and then gets a list of links to the EST resources. The host name and port number must come from somewhere -- e.g., from configuration or from some other discovery process. I'm quite happy with this. Then you were saying that, in some cases, this discovery step is unnecessary/wasteful. A client would instead need to know the host name (or IP address) and port number of a CoAP server as well as an ArbitraryLabel. It would then construct the URI and could immediately start interacting with that resource. Again, the host name, port number and ArbitraryLabel must come from somewhere. You were saying that they come from configuration. My question is: If host name, port number and ArbitraryLabel can come from configuration, from which the client constructs , wouldn't it also be possible to configure the client with the whole URI containing the three parts directly? > > 5.1 "Discoverable port numbers can be returned in the response payload." -- > > Now I'm wondering if that's actually permitted by RFC 6690... > > [...] but I think the example is OK to include the port. I'm not sure. RFC 6690 is really weird. Let me get back to you on this. > > 5.4 "All EST-coaps request messages expect an acknowledgement (with a > > response payload); EST-coaps requests are confirmable CON CoAP messages." > > -- This seems to be a matter of implementation quality and should not be a > > requirement for interoperability. I suggest to remove this. > > We want to make use of Delayed responses. There are cases where the CA takes > time to generate the cert/keypair, and in that case it needs to signal the > delay with a Max-Age or Empty ACK. That is why we use CON. The text > justification does not explain explicitly, but we didn't want to clutter the > wording, so we kept it simple. You're mixing up protocol specification and implementation guidance. On the protocol specification side, both clients and servers are free to choose if they want to use confirmable or non-confirmable messages. And an application should not make any restrictions on that. On the implementation guidance side, I think it makes a lot of sense to choose delayed responses here. But implementation guidance should be clearly marked as such, as not to create the impression that implementations can only use certain messages types or can rely on only certain messages types being used. > > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't > > in this example. Since it's not important for the example, maybe just > > remove Uri-Host and Uri-Port from the example and also this paragraph? > > I wanted to keep it in there. We explain that it can be assumed from DTLS if > omitted, but I think it is worth to show how the option would be included. I > had trouble finding a COAP Uri-Host and port example online when I was > searching and thus this is useful as a reference as well. Yes, having more examples for reference is really nice. And I really like that you, the authors, spent quite obviously a lot of time making sure that EST-coaps is actually implementable and figuring out the best ways to implement it. But, as I said above, you're mixing up protocol specification and implementation guidance too much for my taste. I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application. Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'... Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.4.4 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Panos Kampanakis (pkampana) wrote: >> But can't the client just be configured out-of-band with the URIs directly? > That is right. We could mandate only .well-known URIs. But I think we > ought to let a deployment use non-default URIs. For example some > usecase might not want to send the .well-known in the URI to save > transmission bytes and thus use a custom short URI. If the URI change > takes place after deployment client will find that out with a > discovery. Similarly, a usecase might initially not support one of the > optional requests like server-side keygen. If the server adds support > sometime in the future, the client could find out using discovery. And > we ought to let the client be able to recover in case the well-known > request URI fails for some reason and he wants to see what is supported > by the server.That is why we thought it is still worth to keep the > .well-known URIs along with the discovery. also, EST-COAP is a building block for draft-ietf-anima-constrained-voucher (containing constrained BRSKI) so preconfiguration won't work. While constrained BRSKI can operate on .well-known the LDevID renewal might occur with a different server, and so discovery might be worthwhile. There are two reasons for doing the resource discovery: 1) to get a multicast response when looking for a registrar. 2) to get a shorter name to save some bytes. I think that (2) contributes negatively to code-complexity, and so if not for (1), I'd prefer to live on /.well-known only. But, I don't object to having shorter URLs available for those that want to spend the code. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Thanks again Klaus. We addressed your 2nd WGLC review comments in https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=%22Klaus+WGLC+review+2%2F27%2F2019%22 I think that is all of them. The latest version of the text is https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt We are planning to reupload this week, please let us know if there is more feedback. Below I am addressing the rest of your questions or things I didn't think needed an update in the draft. > But can't the client just be configured out-of-band with the URIs directly? That is right. We could mandate only .well-known URIs. But I think we ought to let a deployment use non-default URIs. For example some usecase might not want to send the .well-known in the URI to save transmission bytes and thus use a custom short URI. If the URI change takes place after deployment client will find that out with a discovery. Similarly, a usecase might initially not support one of the optional requests like server-side keygen. If the server adds support sometime in the future, the client could find out using discovery. And we ought to let the client be able to recover in case the well-known request URI fails for some reason and he wants to see what is supported by the server.That is why we thought it is still worth to keep the .well-known URIs along with the discovery. > 5.1 "The first three lines of the discovery response above MUST be returned > if the server supports resource discovery." -- ...if it supports EST? I mean, > if a server has a /.well-known/core resource and implements a draft, is there > a reason why it wouldn't include the EST resources in the /.well-known/core > representation? If it doesn't want to offer two sets of paths, it can simply > return this: > ;rt="ace.est.crts", > ;rt="ace.est.sen", > ;rt="ace.est.sren", > ;rt="ace.est.att", > ;rt="ace.est.skg", > ;rt="ace.est.skc" Yes. The point of the "MUST" is that since crts, sen and sren are mandatory you are supposed to give them out when you support resource discovery for EST-coaps. If you are asking why don't we just support discovery and not the default ./well-known path, the reason that there might be cases where discovery is wasteful in terms of transmission and client code to parse the responses. These cases will never discover anything, they will just use the well-known path. > 5.1 "Discoverable port numbers can be returned in the response payload." -- > Now I'm wondering if that's actually permitted by RFC 6690... I saw <http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="describedby in a couple of examples in RFC6690. I also saw it in https://tools.ietf.org/html/draft-ietf-core-resource-directory that shows "Res: 2.05 Content ;rt="temperature"; anchor="coap://[2001:db8:3::123]:61616" Jim suggested the anchor is not needed, but I think the example is OK to include the port. > 5.4 "All EST-coaps request messages expect an acknowledgement (with a > response payload); EST-coaps requests are confirmable CON CoAP messages." -- > This seems to be a matter of implementation quality and should not be a > requirement for interoperability. I suggest to remove this. We want to make use of Delayed responses. There are cases where the CA takes time to generate the cert/keypair, and in that case it needs to signal the delay with a Max-Age or Empty ACK. That is why we use CON. The text justification does not explain explicitly, but we didn't want to clutter the wording, so we kept it simple. > 7. "Parameters" -- This section should be a non-normative implementation note > or removed altogether. Yes, we removed all normative language from this section. > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't in > this example. Since it's not important for the example, maybe just remove > Uri-Host and Uri-Port from the example and also this paragraph? I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and port example online when I was searching and thus this is useful as a reference as well. Rgs, Panos -Original Message- From: Klaus Hartke Sent: Wednesday, February 27, 2019 11:39 AM To: Panos Kampanakis (pkampana) Cc: ace@ietf.org; Jim Schaad Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est Hi Panos, thanks for addressing all issues so thoroughly. I've performed another quick review of draft-ietf-ace-coap-est-09. 5.1. The discovery looks much better now! I think you had
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Hi Panos,
thanks for addressing all issues so thoroughly. I've performed another
quick review of draft-ietf-ace-coap-est-09.
5.1. The discovery looks much better now! I think you had 5 or 6 ways
for a client to construct or discover the URIs of an EST deployment.
Now it seems there are only two:
Either (A) the client is configured out-of-band with host name/IP
address, port, and optionally an ArbitraryLabel and constructs a URI
of the form coaps://{hostname]:{port}/.well-known/est/{optionally an
ArbitraryLabel}/{one of the suffixes}.
Or (B) the client is configured out-of-band with host name/IP address
and port, constructs a URI of the form
coaps://{hostname}:{port}/.well-known/core, performs a look up on that
URI, and looks for a link in the response with a resource type of the
form "ace.est.{one of the suffixes}".
But can't the client just be configured out-of-band with the URIs directly?
5.1 "The ArbitraryLabel path-segment, if used, SHOULD be of the
shortest length possible" -- So if someone decides to use an
ArbitraryLabel path-segment consisting of more than 0 characters
(which is the shortest length possible), then it's a protocol
violation? This seems to be a matter of implementation quality to me,
not a requirement for interoperability.
5.1 "(Sections 3.1 and 3.2.2 of [RFC7030]." -- Missing )
5.1 "The EST-coaps server URIs, obtained through discovery of the
EST-coaps root resource(s) as shown below, are of the form:" -- There
is no longer a 'root resource' if a client discovers the full paths.
For example, implementers are free to send the following
/.well-known/core if they want:
;rt="ace.est.crts",
;rt="ace.est.sen",
;rt="ace.est.sren",
;rt="ace.est.att",
;rt="ace.est.skg",
;rt="ace.est.skc"
5.1 "The first three lines of the discovery response above MUST be
returned if the server supports resource discovery." -- ...if it
supports EST? I mean, if a server has a /.well-known/core resource and
implements a draft, is there a reason why it wouldn't include the EST
resources in the /.well-known/core representation? If it doesn't want
to offer two sets of paths, it can simply return this:
;rt="ace.est.crts",
;rt="ace.est.sen",
;rt="ace.est.sren",
;rt="ace.est.att",
;rt="ace.est.skg",
;rt="ace.est.skc"
5.1 "The Content-Formats in the response allow the client to request
one that is supported by the server." -- Maybe state explicitly that
these are the values accepted by the server in the Accept option?
5.1 "Discoverable port numbers can be returned in the response
payload." -- Now I'm wondering if that's actually permitted by RFC
6690...
5.1 " The client SHOULD use resource discovery when /.well-known/est
fails" -- But if /.well-known/est fails, then the server clearly
doesn't support EST because of "The server MUST support the default
/.well-known/est root resource.", right?
5.1 "It is up to the implementation to choose its root resource;" --
As above, there is no root resource.
5.4 "All EST-coaps request messages expect an acknowledgement (with a
response payload); EST-coaps requests are confirmable CON CoAP
messages." -- This seems to be a matter of implementation quality and
should not be a requirement for interoperability. I suggest to remove
this.
7. "Parameters" -- This section should be a non-normative
implementation note or removed altogether.
A. "These examples assume a short root resource path of "/est"." -- As
above, there is no root resource. Maybe the very first example in this
section should be a look up of /.well-known/core for the URIs used in
the following subsections?
A.1 "Option Length = 0x9 Option Value = est-coaps.example.org" -- The
value of 0x9 does not match the length of "est-coaps.example.org".
Also in other examples and for other options.
A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they
aren't in this example. Since it's not important for the example,
maybe just remove Uri-Host and Uri-Port from the example and also this
paragraph?
A.2 "POST [2001:db8::2:1]:61616/est/sen" -- We don't have a standard
format for CoAP examples, but this line uses a different format than
section A.1. It might be good to make this consistent.
Klaus
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Thanks Ben.
I addressed your content-format order comment in the next iteration of the
draft by saying
> The two representations (each consisting of two CBOR array items) do
> not have to be in a particular order since each representation is
> preceeded by its Content-Format ID.
Panos
-Original Message-
From: Benjamin Kaduk
Sent: Sunday, February 24, 2019 7:08 PM
To: Panos Kampanakis (pkampana)
Cc: Klaus Hartke ; Jim Schaad ;
ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
On Fri, Feb 22, 2019 at 09:00:05PM +, Panos Kampanakis (pkampana) wrote:
> Hi Klaus,
>
> Thanks for the thorough review.
>
> All your issues identified are tracked here
> https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3
> Aissue+%22Klaus+WGLC%22 . We tried to address all of them. The fixes
> we are putting in are spelled out in the github issues themselves. The
> actual latest version of the draft is
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
>
> After proof reading the draft one more time we will upload early next week.
>
> Below I am answering some of the questions you asked in your review.
>
> > 4. -- Is this section about the generated certificates or the DTLS
> > connection between the client and the server? If the latter, this section
> > is weird, because RFC 7252 already does define MTI cipher suites and
> > extensions, and I see no reason why an application layered on top of CoAP
> > needs to restate all of that.
>
> This section describes how the (D)TLS profile defined in RFC7925 is used by
> EST-coaps. It was asked by the original ACE co-chair to show conformance with
> ACE profiles. It touches on the client server authentication, the tunnel
> ciphersuites. It explains how the EST-coaps data exchange is secured thereby
> preventing eavesdropping, tampering, and message forgery. We wanted to spell
> out for implementers which parts of RFC7925 they should take into
> consideration instead of just pointing them to RFC7925 or RFC7252 etc.
>
> > 4. "The authentication of the EST-coaps client MUST be with a client
> > certificate in the DTLS handshake." -- Why? Why can't a client communicate
> > with a server using any other secure mechanism with client authentication?
> > Or is this just the MTI mechansim?
>
> The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert
> auth. HTTP Auth is not defined for COAP application as far as we know. So,
> for EST-coaps, the only viable authentication method is mutual cert auth.
> Other client auth methods could be defined, but are outside the scope of this
> draft.
I think there is enough flexibility in our specifying a "new transport for EST"
that we do not need to be strictly bound to the EST-mandated authentication
mechanisms. That said, I'm not sure I have any other options handy than mutual
cert auth...
> > 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to
> > route client requests to the appropriate certificate profile." -- I assume
> > that a client needs to construct URIs from the well-known path
> > "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a
> > client determine which Arbitrary Label to use?
>
> That is configured on the client out of band depending on the CA that
> generates the certs. It is outside the scope of EST or EST-coaps.
>
> > 5.1. "The EST-coaps server URIs, obtained through discovery of the
> > EST-coaps root resource(s) as shown below, are of the form:" -- If a client
> > discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts",
> > "ace.est.sen", etc.), is this table 1 still needed? If not, I would
> > recommend that only the 'rt' values are standardized ("ace.est.crts",
> > "ace.est.sen", etc.) and all paths are left to the implementation, in
> > accordance with BCP 190.
>
> We intend to require /.well-known URIs so that resource discovery is not
> mandatory for pre-configured client deployments. Discovery is optional when
> non-default URIs are needed to save URI space. Feel free to check the text in
> https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the
> resource discovery text to make it clearer.
>
> > 5.1. "Discoverable port numbers MAY be returned in the of the
> > payload [I-D.ietf-core-resource-directory]." -- What does this mean?
> > And what does Resource Directory have to do with EST?
>
> We needed a way to be able tell the client that the resource is hoste
Re: [Ace] WGLC for draft-ietf-ace-coap-est
added a > reference to the discovery section. > > > 5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit > > difficult to see what TBD287 and 281 mean without scrolling all the way > > down and scrolling back up. Maybe include the table here to make the > > section easier to read? > > I don't think that is necessary as we are stating that TBD287 and 281 "to > carry a single certificate instead of a PKCS#7 container in a /crts, /sen, > /sren or /skg response ". Also there is a reference to the IANA section in > the paragraph above. > > > 5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR > > to the server." -- Just for my understanding: Does the submission of a > > specific CSR always lead to the same output, or can it happen (e.g., if the > > client submits an identical CSR weeks or months later) that the client > > would get a different output? > > Submitting the same CSR will likely give the client a different output. The > reason is that the server cert profile may have changed, but more importantly > the issued certificate will have a different lifetime and thus signature > value. > > > 5.7. "... or the client abandons for other reasons." -- Does the client > > need to signal in some way when it wants to abandon? > > When the server asks the client to come back in x amount of time, it does not > keep state of the client and thus will not care if he returns or not. So, we > don't need to require the client to signal that he is giving up. > > > 5.8. "containing a CBOR array with four items Section 5.3" -- Do the two > > representations (each consisting of two CBOR array items) have to be in a > > particular order or can they appear in any order? > > Any order is fine, since the you can tell what format each representation > carries. This sort of detail is good to have stated clearly in the document. -Ben > > 6. "In a constrained CoAP environment, endpoints can't always afford to > > establish a DTLS connection for every EST transaction." -- I'm not aware of > > any requirement that says CoAP clients must establish a new DTLS connection > > for every request... > > EST mandates using a new truststore after a cacerts request which most > usually means a new TLS connection. We can't always require the client to do > that in a constrained environment and thus this text. > > > I didn't review the appendices. > > Pity, we are sure you could still uncover nits in there. > > Rgs, > Panos > > > > -Original Message- > From: Ace On Behalf Of Klaus Hartke > Sent: Tuesday, February 12, 2019 12:38 PM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est > > Jim Schaad wrote: > > The chairs believe that the EST over CoAP draft is nearing the point > > it should be sent to the IESG for publication. We are therefore going > > to have a Working Group Last Call on this document. WGLC will until > > 29th of this month. Please review the document and send comments both > > positive and negative to the list about its state. > > I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for being > late to the party. > > 2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP [RFC7252] and > UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP." > -- Is there a technical reason why EST could not be done over CoAP over TCP, > TLS, WebSockets, or SMS? > > I understand that it was fashionable at some point to fork a protocol like > HTTP, layer some stuff on top of it and call it a new protocol. > However, I would strongly recommend that EST-coaps is presented as an > application that is strictly layered on top of CoAP and doesn't define its > own custom protocol stack. > > 4. -- Is this section about the generated certificates or the DTLS connection > between the client and the server? If the latter, this section is weird, > because RFC 7252 already does define MTI cipher suites and extensions, and I > see no reason why an application layered on top of CoAP needs to restate all > of that. > > 4. "The authentication of the EST-coaps client MUST be with a client > certificate in the DTLS handshake." -- Why? Why can't a client communicate > with a server using any other secure mechanism with client authentication? Or > is this just the MTI mechansim? > > 5.1. The use of the well-known path "/.well-known/est" seems to follow the > letter of BCP 190 but not the spirit. I
Re: [Ace] WGLC for draft-ietf-ace-coap-est
g: Does the submission of a specific
> CSR always lead to the same output, or can it happen (e.g., if the client
> submits an identical CSR weeks or months later) that the client would get a
> different output?
Submitting the same CSR will likely give the client a different output. The
reason is that the server cert profile may have changed, but more importantly
the issued certificate will have a different lifetime and thus signature value.
> 5.7. "... or the client abandons for other reasons." -- Does the client need
> to signal in some way when it wants to abandon?
When the server asks the client to come back in x amount of time, it does not
keep state of the client and thus will not care if he returns or not. So, we
don't need to require the client to signal that he is giving up.
> 5.8. "containing a CBOR array with four items Section 5.3" -- Do the two
> representations (each consisting of two CBOR array items) have to be in a
> particular order or can they appear in any order?
Any order is fine, since the you can tell what format each representation
carries.
> 6. "In a constrained CoAP environment, endpoints can't always afford to
> establish a DTLS connection for every EST transaction." -- I'm not aware of
> any requirement that says CoAP clients must establish a new DTLS connection
> for every request...
EST mandates using a new truststore after a cacerts request which most usually
means a new TLS connection. We can't always require the client to do that in a
constrained environment and thus this text.
> I didn't review the appendices.
Pity, we are sure you could still uncover nits in there.
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 12:38 PM
To: Jim Schaad
Cc: ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
Jim Schaad wrote:
> The chairs believe that the EST over CoAP draft is nearing the point
> it should be sent to the IESG for publication. We are therefore going
> to have a Working Group Last Call on this document. WGLC will until
> 29th of this month. Please review the document and send comments both
> positive and negative to the list about its state.
I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for being
late to the party.
2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP [RFC7252] and
UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP."
-- Is there a technical reason why EST could not be done over CoAP over TCP,
TLS, WebSockets, or SMS?
I understand that it was fashionable at some point to fork a protocol like
HTTP, layer some stuff on top of it and call it a new protocol.
However, I would strongly recommend that EST-coaps is presented as an
application that is strictly layered on top of CoAP and doesn't define its own
custom protocol stack.
4. -- Is this section about the generated certificates or the DTLS connection
between the client and the server? If the latter, this section is weird,
because RFC 7252 already does define MTI cipher suites and extensions, and I
see no reason why an application layered on top of CoAP needs to restate all of
that.
4. "The authentication of the EST-coaps client MUST be with a client
certificate in the DTLS handshake." -- Why? Why can't a client communicate with
a server using any other secure mechanism with client authentication? Or is
this just the MTI mechansim?
5.1. The use of the well-known path "/.well-known/est" seems to follow the
letter of BCP 190 but not the spirit. I don't see any reason why a well-known
path is needed here. In fact, as the section emphasizes, short paths are
important and an implementation will there likely want to do the
"/.well-known/core"-based discovery of URIs. I would recommend that the entire
use of "/.well-known/est" is dropped.
5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to
route client requests to the appropriate certificate profile." -- I assume that
a client needs to construct URIs from the well-known path "/.well-known/est",
the Arbitrary Label and one of the suffixes. How does a client determine which
Arbitrary Label to use?
5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps
root resource(s) as shown below, are of the form:" -- If a client discovers the
URIs from "/.well-known/core" (annotated with "ace.est.crts", "ace.est.sen",
etc.), is this table 1 still needed? If not, I would recommend that only the
'rt' values are standardized ("ace.est.crts", "ace.est.sen", etc.) and all
paths are left to the implementation, in accordance with BCP 190.
5.1. "Clients and servers MUST support the short resource U
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Jim Schaad wrote:
> The chairs believe that the EST over CoAP draft is nearing the point it
> should be sent to the IESG for publication. We are therefore going to have
> a Working Group Last Call on this document. WGLC will until 29th of this
> month. Please review the document and send comments both positive and
> negative to the list about its state.
I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for
being late to the party.
2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP
[RFC7252] and UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP."
-- Is there a technical reason why EST could not be done over CoAP
over TCP, TLS, WebSockets, or SMS?
I understand that it was fashionable at some point to fork a protocol
like HTTP, layer some stuff on top of it and call it a new protocol.
However, I would strongly recommend that EST-coaps is presented as an
application that is strictly layered on top of CoAP and doesn't define
its own custom protocol stack.
4. -- Is this section about the generated certificates or the DTLS
connection between the client and the server? If the latter, this
section is weird, because RFC 7252 already does define MTI cipher
suites and extensions, and I see no reason why an application layered
on top of CoAP needs to restate all of that.
4. "The authentication of the EST-coaps client MUST be with a client
certificate in the DTLS handshake." -- Why? Why can't a client
communicate with a server using any other secure mechanism with client
authentication? Or is this just the MTI mechansim?
5.1. The use of the well-known path "/.well-known/est" seems to follow
the letter of BCP 190 but not the spirit. I don't see any reason why a
well-known path is needed here. In fact, as the section emphasizes,
short paths are important and an implementation will there likely want
to do the "/.well-known/core"-based discovery of URIs. I would
recommend that the entire use of "/.well-known/est" is dropped.
5.1. "Arbitrary Labels are usually defined and used by EST CAs in
order to route client requests to the appropriate certificate
profile." -- I assume that a client needs to construct URIs from the
well-known path "/.well-known/est", the Arbitrary Label and one of the
suffixes. How does a client determine which Arbitrary Label to use?
5.1. "The EST-coaps server URIs, obtained through discovery of the
EST-coaps root resource(s) as shown below, are of the form:" -- If a
client discovers the URIs from "/.well-known/core" (annotated with
"ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If
not, I would recommend that only the 'rt' values are standardized
("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the
implementation, in accordance with BCP 190.
5.1. "Clients and servers MUST support the short resource URIs. The
corresponding longer URIs from [RFC7030] MAY be supported." -- Does
this provide any benefit or is it just to annoy implementers? Like, we
can have short paths, we can have long paths, we cannot decide, so
let's have ALL OF THEM!
5.1. "In the context of CoAP, the presence and location of (path to)
the management data are discovered by sending a GET request to
"/.well-known/core" including a resource type (RT) parameter with the
value "ace.est" -- I understand that EST defines the operations on the
resources labeled with annotated with "ace.est.crts", "ace.est.sen",
etc. but I don't understand what I can do with a resource that is
annotated with "ace.est".
5.1. "The first line of the discovery response above MUST be included.
The five consecutive lines after the first MAY be included." -- When
would I include what?
5.1. "The return of the content types allows the client to choose the
most appropriate one." -- Does the example actually match what a
server returns? E.g., does ct="62 280 284 281 TBD287" mean that a
server actually returns a TBD287 representation or would it always be
a 62 (multipart) representation that happens to contain a TBD287
representation?
5.1. "Port numbers, not returned in the example, are assumed to be the
default numbers 5683 and 5684 for CoAP and CoAPS respectively" -- No
need to make any assumptions. This is exactly what RFC 7252 specifies.
Please don't make any normative statements that just repeat (or
contradict) what RFC 7252 says.
5.1. "Discoverable port numbers MAY be returned in the of the
payload [I-D.ietf-core-resource-directory]." -- What does this mean?
And what does Resource Directory have to do with EST?
5.1. " The server MUST support the default /.well-known/est server
root resource and port 5684." -- As said above, I would drop this
entirely.
5.1. "Resource discovery is necessary when the IP address of the
server is unknown to the client." -- Assuming that "resource
directory" refers to "/.well-known/core"-based discovery of URIs, then
this is wrong. If the IP address of a server is not known, then a
client cannot retrieve the "/.well-known/core" of that server.
5.2. "Ta
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Hi all, The -08 version of the draft https://tools.ietf.org/html/draft-ietf-ace-coap-est-08 addresses all comments we received so far in the WGLC. It also simplifies parts of the text to make easier to read, moves a couple of sections in more suitable order and fixes nits and typos. Thanks to everyone that provided feedback and mostly Jim and Esko for their thorough reviews. For a summary of the issues received in WGLC and how they were addressed, refer to https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+WGLC Let us know if there is more feedback. Rgs, Panos -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Tuesday, January 29, 2019 12:59 AM To: ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est This message concludes the last call for this document. The authors are requested to create and post a new document addressing the issues that were raised. Jim > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Sunday, January 13, 2019 8:03 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-coap-est > > The chairs believe that the EST over CoAP draft is nearing the point > it should > be sent to the IESG for publication. We are therefore going to have a > Working Group Last Call on this document. WGLC will until 29th of > this month. Please review the document and send comments both > positive and negative to the list about its state. > > Jim & Roman > > > ___ > 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
I believe that I already said yes. Jim > -Original Message- > From: Michael Richardson > Sent: Saturday, February 2, 2019 12:27 PM > To: Jim Schaad > Cc: 'Esko Dijk' ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Jim Schaad wrote: > > Of anybody on the mailing list believes that the document should not > > add a new CoAP content type for "application/pkix-cert" please speak up > > before next Monday. > > Can we go ahead with this request now? :-) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Jim Schaad wrote: > Of anybody on the mailing list believes that the document should not > add a new CoAP content type for "application/pkix-cert" please speak up > before next Monday. Can we go ahead with this request now? :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
This message concludes the last call for this document. The authors are requested to create and post a new document addressing the issues that were raised. Jim > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Sunday, January 13, 2019 8:03 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-coap-est > > The chairs believe that the EST over CoAP draft is nearing the point it should > be sent to the IESG for publication. We are therefore going to have a > Working Group Last Call on this document. WGLC will until 29th of this > month. Please review the document and send comments both positive and > negative to the list about its state. > > Jim & Roman > > > ___ > 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
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
As ACE co-chair, Of anybody on the mailing list believes that the document should not add a new CoAP content type for "application/pkix-cert" please speak up before next Monday. Jim > -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Thursday, January 24, 2019 8:01 AM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > So to reduce code size for embedded implementations it would be very > > beneficial if the EST Server would support an additional content > > format: > > application/pkix-cert (see RFC 5280) > > So, to implement this in the specification, we need an additional Content- > Type value to be allocated. > > If we have WG Consensus to add this, then we can spin the document and > ask for another early allocation. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Esko Dijk wrote: > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) So, to implement this in the specification, we need an additional Content-Type value to be allocated. If we have WG Consensus to add this, then we can spin the document and ask for another early allocation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
> There is no signature for this CMS signed message format. It only contains > the certificates and CRLs that are passed back. I would still think that > this is a fine idea as long as you are only going to return the leaf > certificate and not returning a bag of certificates or any CRLs. That's right, only the leaf certificate is returned and no CRLs; in this embedded case. Any other required certificates are already obtained from the prior DTLS handshake process. I agree that using draft-birkholz-core-coid-01 could be used in the future as an alternative format instead of an X.509 certificate. Ideally, it would become an update of RFC-EST-over-coaps and an enrolling client can indicate it uses the new formats by using e.g. CoAP Content-Format and Accept Options, or by different URI paths. Best regards Esko -Original Message- From: Jim Schaad Sent: Thursday, January 24, 2019 06:05 To: 'Michael Richardson' ; Esko Dijk Cc: ace@ietf.org Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices > -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Wednesday, January 23, 2019 6:27 PM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > My main comment on this draft is based on recent experience with an > > embedded implementation. In the draft, the content format > > "application/pkcs7-mime;smime-type=certs-only" is used to > transport a > > single certificate back to the client. However, in the embedded > > implementation crypto library there is no support for parsing this > > format, but there is support for parsing X.509v3 > > (application/pkix-cert). See > > e.g. https://tls.mbed.org/api/group__x509__module.html for an > embedded > > API that can parse CSR and certs, but not PKCS#7. > > > Therefore the X.509 format seems better to use; also given that > > 1) the signing of data that the PKCS#7 S/MIME envelope provides > is useless because the DTLS session is already end-to-end protected > and the certificate is already signed; and There is no signature for this CMS signed message format. It only contains the certificates and CRLs that are passed back. I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs. > > 2) RFC 7030 requires that only one certificate, the generated > one, is > > carried in the /simple(re)enroll response so that a container format > > for multiple certificates is not really needed here. > > > So to reduce code size for embedded implementations it would be very > > beneficial if the EST Server would support an additional content > > format: > > application/pkix-cert (see RFC 5280) > > I think that this is a reasonable thing to do. > The client can easily say what it wants and I think the two formats > are relatively easy to swap. > > What about if we went further, and went to: > Concise Identities > draft-birkholz-core-coid-01 Given that it would be a blocking factor, I would think about this as maybe something in the future. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
> -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Wednesday, January 23, 2019 6:27 PM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > My main comment on this draft is based on recent experience with an > > embedded implementation. In the draft, the content format > > "application/pkcs7-mime;smime-type=certs-only" is used to transport a > > single certificate back to the client. However, in the embedded > > implementation crypto library there is no support for parsing this > > format, but there is support for parsing X.509v3 > > (application/pkix-cert). See > > e.g. https://tls.mbed.org/api/group__x509__module.html for an > embedded > > API that can parse CSR and certs, but not PKCS#7. > > > Therefore the X.509 format seems better to use; also given that > > 1) the signing of data that the PKCS#7 S/MIME envelope provides is > useless because the DTLS session is already end-to-end protected and the > certificate is already signed; and There is no signature for this CMS signed message format. It only contains the certificates and CRLs that are passed back. I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs. > > 2) RFC 7030 requires that only one certificate, the generated one, is > > carried in the /simple(re)enroll response so that a container format > > for multiple certificates is not really needed here. > > > So to reduce code size for embedded implementations it would be very > > beneficial if the EST Server would support an additional content > > format: > > application/pkix-cert (see RFC 5280) > > I think that this is a reasonable thing to do. > The client can easily say what it wants and I think the two formats are > relatively easy to swap. > > What about if we went further, and went to: > Concise Identities > draft-birkholz-core-coid-01 Given that it would be a blocking factor, I would think about this as maybe something in the future. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Esko Dijk wrote: > My main comment on this draft is based on recent experience with an > embedded implementation. In the draft, the content format > "application/pkcs7-mime;smime-type=certs-only" is used to transport a > single certificate back to the client. However, in the embedded > implementation crypto library there is no support for parsing this > format, but there is support for parsing X.509v3 > (application/pkix-cert). See > e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded > API that can parse CSR and certs, but not PKCS#7. > Therefore the X.509 format seems better to use; also given that > 1) the signing of data that the PKCS#7 S/MIME envelope provides is useless because the DTLS session is already end-to-end protected and the certificate is already signed; and > 2) RFC 7030 requires that only one certificate, the generated one, is > carried in the /simple(re)enroll response so that a container format > for multiple certificates is not really needed here. > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) I think that this is a reasonable thing to do. The client can easily say what it wants and I think the two formats are relatively easy to swap. What about if we went further, and went to: Concise Identities draft-birkholz-core-coid-01 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Dear ACE WG & authors, My main comment on this draft is based on recent experience with an embedded implementation. In the draft, the content format "application/pkcs7-mime;smime-type=certs-only" is used to transport a single certificate back to the client. However, in the embedded implementation crypto library there is no support for parsing this format, but there is support for parsing X.509v3 (application/pkix-cert). See e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded API that can parse CSR and certs, but not PKCS#7. Therefore the X.509 format seems better to use; also given that 1) the signing of data that the PKCS#7 S/MIME envelope provides is useless because the DTLS session is already end-to-end protected and the certificate is already signed; and 2) RFC 7030 requires that only one certificate, the generated one, is carried in the /simple(re)enroll response so that a container format for multiple certificates is not really needed here. So to reduce code size for embedded implementations it would be very beneficial if the EST Server would support an additional content format: application/pkix-cert (see RFC 5280) The client can request this format using the CoAP Accept Option; by default if no Accept Option given the EST server would return application/pkcs7-mime;smime-type=certs-only. What do you think about this addition? I believe that adding this would make the EST-over-Coaps protocol an ideal fit to common embedded SW stacks. Furthmore I found these two issues that need to be addressed: Section 5.4: "The equivalent CoAP error code to use in an EST-coaps responses are 2.04 ..." -> 2.04 is a success code, not an error. Section 5.6: "According to section 5.2.2 of [RFC7252], a slow server can acknowledge the request with a 2.31 code" -> 2.31 is not specified in RFC 7252. Best regards Esko Dijk -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Monday, January 14, 2019 05:03 To: ace@ietf.org Subject: [Ace] WGLC for draft-ietf-ace-coap-est The chairs believe that the EST over CoAP draft is nearing the point it should be sent to the IESG for publication. We are therefore going to have a Working Group Last Call on this document. WGLC will until 29th of this month. Please review the document and send comments both positive and negative to the list about its state. Jim & Roman ___ 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
