Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Ben,
Thank you again for the additional feedback.
The changes are summarized in the git issue
https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-535065314 I
mostly made all the suggested text changes, summarized our discussion about
extended-master-secret. I also made a change in Fig 2 and Fig 3 to address the
issue you caught with the /128 blocks.
The diff is here
https://github.com/SanKumar2015/EST-coaps/commit/d16c53d3360430b5587021dc1a2d31f668c0c0fe
. And a minor nit fix in
https://github.com/SanKumar2015/EST-coaps/commit/ff5b303781231e34571352cb07fb895d5ecab791
I will reupload early next week. Please check out the issue in case you have
further comments.
Panos
-Original Message-
From: Ace On Behalf Of Benjamin Kaduk
Sent: Monday, September 23, 2019 6:48 PM
To: Panos Kampanakis (pkampana)
Cc: Peter van der Stok ; Jim Schaad
; draft-ietf-ace-coap-est@ietf.org; Michael
Richardson ; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Panos,
Sorry for the slow response here -- I was in telechat-prep mode last week.
This is in pretty good shape, and I wanted to especially thank you for the
presentation in the github issue -- that format was extremely helpful for me.
I think we will probably need to upload one more minor revision before I
initiate the IETF LC; please seem my comments below.
In Section 4, I think we need to put the "for" back in "requests for a trusted
certificate list".
Also, refresh my memory: did we decide that there's no need to explicitly
mandate the use of the "extended_master_secret" TLS extension?
I'd also change the note about supported_groups vs. Supported Elliptic Curves
to read "In addition, in DTLS 1.3 the Supported Elliptic Curves extension has
been renamed to Supported Groups."
I think we can move /csrattrs to the bottom of Table 2 (thank you for changing
Table 1!).
With the changes to the example in Figure 3, can you walk me through the
block-size negotiation? Quoting:
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
|
... Immediate response when certificate is ready ...
|
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}
So the ACK to the final fragment of the POST includes (2:0/1/256), or the first
fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second fragment of
a 128-byte-fragmented version of the response. Is that just going to be the
last 128 bytes of the thing it already got from the server? If so, is that
something it would actually do (e.g., if it had to drop part of the server's
response due to a buffer-size limitation) or is it not possible to only have
part of a fragment (so it would need to either ask for (2:0/0/128) or
(2:2/0/128)?
It looks like you removed the text about "[the two representations] do not have
to be in a particular order since each representation is preceded by its
Content-Format ID" based on my remark about core-multipart-ct; that document
has since been approved by the IESG and is explicitly confirming that there is
no specific ordering requirement (in contrast to multipart/mixed), so we could
put that clause back in this document if desired.
I consider it more likely than not that a directorate reviewer will want to
tweak the added language at the end of Section 5.8 explaining our divergence
from RFC 7030; if you want to preemptively reword, my suggestion would be
"Although [RFC7030] strongly recommends that clients request the use of CMS
encryption on top of the TLS channel's protection, this document does not make
such a recommendation; CMS encryption can still be used when mandated by the
use case."
Thanks!
-Ben
On Mon, Sep 16, 2019 at 05:38:59PM +, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
>
> I think we have now addressed all your feedback from the AD review. A big
> chunk of the changes were agreed upon in the list emails threads.
>
> The iteration that we are planning to upload that includes all the
> changes is at
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
>
> The summary of all your comments and what went into the text is in the
> git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To
> break it down
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has
> most of the changes agreed on the list.
> -
> https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807
> has an answer to your question about addressing the tls-unique issue in a new
> draft.
>
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Panos,
Sorry for the slow response here -- I was in telechat-prep mode last week.
This is in pretty good shape, and I wanted to especially thank you for the
presentation in the github issue -- that format was extremely helpful for
me.
I think we will probably need to upload one more minor revision before I
initiate the IETF LC; please seem my comments below.
In Section 4, I think we need to put the "for" back in "requests for a
trusted certificate list".
Also, refresh my memory: did we decide that there's no need to
explicitly mandate the use of the "extended_master_secret" TLS
extension?
I'd also change the note about supported_groups vs. Supported Elliptic
Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves
extension has been renamed to Supported Groups."
I think we can move /csrattrs to the bottom of Table 2 (thank you for
changing Table 1!).
With the changes to the example in Figure 3, can you walk me through the
block-size negotiation? Quoting:
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
|
... Immediate response when certificate is ready ...
|
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}
So the ACK to the final fragment of the POST includes (2:0/1/256), or
the first fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second
fragment of a 128-byte-fragmented version of the response. Is that just
going to be the last 128 bytes of the thing it already got from the
server? If so, is that something it would actually do (e.g., if it had
to drop part of the server's response due to a buffer-size limitation)
or is it not possible to only have part of a fragment (so it would need
to either ask for (2:0/0/128) or (2:2/0/128)?
It looks like you removed the text about "[the two representations] do
not have to be in a particular order since each representation is
preceded by its Content-Format ID" based on my remark about
core-multipart-ct; that document has since been approved by the IESG and
is explicitly confirming that there is no specific ordering requirement
(in contrast to multipart/mixed), so we could put that clause back in
this document if desired.
I consider it more likely than not that a directorate reviewer will want
to tweak the added language at the end of Section 5.8 explaining our
divergence from RFC 7030; if you want to preemptively reword, my
suggestion would be "Although [RFC7030] strongly recommends that clients
request the use of CMS encryption on top of the TLS channel's
protection, this document does not make such a recommendation; CMS
encryption can still be used when mandated by the use case."
Thanks!
-Ben
On Mon, Sep 16, 2019 at 05:38:59PM +, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
>
> I think we have now addressed all your feedback from the AD review. A big
> chunk of the changes were agreed upon in the list emails threads.
>
> The iteration that we are planning to upload that includes all the changes is
> at
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
>
>
> The summary of all your comments and what went into the text is in the git
> issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has
> most of the changes agreed on the list.
> -
> https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807
> has an answer to your question about addressing the tls-unique issue in a new
> draft.
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281
> has the last changes in response to your feedback that went into the draft
> after Peter uploade the -13 iteration.
>
> Two places to pay attention to is that I removed the
> > It is strongly RECOMMENDED that the clients request that the returned
> > private key be afforded the additional security of the Cryptographic
> > Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
> > security to protect against unauthorized disclosure."
> and the
> > The corresponding longer URIs from [RFC7030] MAY be supported."
> The rationale behind that is in the git issue.
>
> Please have a look and let us know if there is anything missing. Otherwise we
> will upload at the end of the week.
>
> Rgs,
> Panos
>
>
> -Original Message-
> From: Ace On Behalf Of Panos Kampanakis (pkampana)
> Sent: Tuesday, September 10, 2019 12:18 AM
> To: Jim Schaad ; 'Mic
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Ben, I think we have now addressed all your feedback from the AD review. A big chunk of the changes were agreed upon in the list emails threads. The iteration that we are planning to upload that includes all the changes is at https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt The summary of all your comments and what went into the text is in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most of the changes agreed on the list. - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 has an answer to your question about addressing the tls-unique issue in a new draft. - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 has the last changes in response to your feedback that went into the draft after Peter uploade the -13 iteration. Two places to pay attention to is that I removed the > It is strongly RECOMMENDED that the clients request that the returned > private key be afforded the additional security of the Cryptographic > Message Syntax (CMS) EnvelopedData in addition to the TLS-provided > security to protect against unauthorized disclosure." and the > The corresponding longer URIs from [RFC7030] MAY be supported." The rationale behind that is in the git issue. Please have a look and let us know if there is anything missing. Otherwise we will upload at the end of the week. Rgs, Panos -Original Message- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, September 10, 2019 12:18 AM To: Jim Schaad ; 'Michael Richardson' Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Hi Jim, We are tracking all of Ben's feedback here https://github.com/SanKumar2015/EST-coaps/issues/150 The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. Panos -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Monday, September 09, 2019 11:34 PM To: 'Michael Richardson' Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Authors, Are we ready to produce a new draft that addresses most, if not all, of Ben's comments? Do we have a pull request to deal with this that we can point to? Jim -Original Message- From: Jim Schaad Sent: Monday, September 9, 2019 1:17 PM To: 'Michael Richardson' ; 'Benjamin Kaduk' Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 -Original Message- From: Michael Richardson Sent: Monday, September 9, 2019 9:38 AM To: Benjamin Kaduk Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that the DecryptKeyIdentifier must be present. This will provide the EST server a method to identify the correct key and the correct symmetric encryption algorithm. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Jim, We are tracking all of Ben's feedback here https://github.com/SanKumar2015/EST-coaps/issues/150 The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. Panos -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Monday, September 09, 2019 11:34 PM To: 'Michael Richardson' Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Authors, Are we ready to produce a new draft that addresses most, if not all, of Ben's comments? Do we have a pull request to deal with this that we can point to? Jim -Original Message- From: Jim Schaad Sent: Monday, September 9, 2019 1:17 PM To: 'Michael Richardson' ; 'Benjamin Kaduk' Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 -Original Message- From: Michael Richardson Sent: Monday, September 9, 2019 9:38 AM To: Benjamin Kaduk Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that the DecryptKeyIdentifier must be present. This will provide the EST server a method to identify the correct key and the correct symmetric encryption algorithm. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ 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] AD review of draft-ietf-ace-coap-est-12 part 2
Authors, Are we ready to produce a new draft that addresses most, if not all, of Ben's comments? Do we have a pull request to deal with this that we can point to? Jim -Original Message- From: Jim Schaad Sent: Monday, September 9, 2019 1:17 PM To: 'Michael Richardson' ; 'Benjamin Kaduk' Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 -Original Message- From: Michael Richardson Sent: Monday, September 9, 2019 9:38 AM To: Benjamin Kaduk Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that the DecryptKeyIdentifier must be present. This will provide the EST server a method to identify the correct key and the correct symmetric encryption algorithm. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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] AD review of draft-ietf-ace-coap-est-12 part 2
-Original Message- From: Michael Richardson Sent: Monday, September 9, 2019 9:38 AM To: Benjamin Kaduk Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that the DecryptKeyIdentifier must be present. This will provide the EST server a method to identify the correct key and the correct symmetric encryption algorithm. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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] AD review of draft-ietf-ace-coap-est-12 part 2
On Mon, Sep 09, 2019 at 05:38:23PM +0100, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> I think that we could go to TLS Exporter right now, but it would take > >> some work. > > > I'd rather have both classic-EST and coap-EST benefit than just > > coap-EST. > > So you'd agree to deferring this to a document (maybe in LAMPS?) that would > Updates: 7030 and this document. Right. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. >> 2) You are saying that we should replace tls-unique (RFC5929) with a >> TLS Exporter. But RFC7030 didn't reference RFC5705. You are >> suggesting that we update ourselves to use RFC5705. That would seem >> to require that we change some PKIX things in CSR. > From a crypto perspective, we should do that. From a > protocol-specification perspective, we should retain parity with > classic EST and only update when it does. So we should probably mostly > ignore this other than trying to kick off work on classic EST, and > mandating extended-master-secret. okay, good. >> 3) I'm wondering if we need to have a clear response/error code for >> the case where the tls-unique does not match. At least, from the >> HTTPS-EST server to the COAPS-EST "proxy" that might be valuable, even >> if the code it not sent back to the client. > [I didn't think much about whether this would give an attacker leverage > from which to execute new attacks] An HTTPS-EST server that responses to the COAPS-EST with such an error is probably mis-configured for that end point. It probably does not believe that the CoAPS-EST proxy is authorized to speak for the end point. Both are already trusted. The end point is probably already also trusted btw. The major use case that we had for server-generating keys is for updating keys for existing installations. Such as moving from 10yr old 1024RSA keys that were manually deployed (at the factory) to 256bit ECDSA keys, etc. >> +--+---++ >> | HTTP Media-Type | ID | Reference | >> +--+---++ >> | application/pkcs7-mime; | 280 | [THISDOCUMENT] | | >> smime-type=server-generated- | | | | key | | | | >> application/pkcs7-mime; | 281 | [THISDOCUMENT] | | >> smime-type=certs-only | | | | application/pkcs8 | 284 | [THISDOCUMENT] >> - | >> | | || >> | application/csrattrs | 285 | [THISDOCUMENT] | | application/pkcs10 | >> 286 | [THISDOCUMENT] | >> | | || >> | application/pkix-cert | TBD28 | [THISDOCUMENT] | | | 7 | | >> +--+---++ > No, I was thinking we should add "[THISDOCUMENT]" to the existing > entries, not replace them. got it. >> I think that 3SHAKE requires session resumption to be supported. I'm >> not sure that using session resumption is the best thing in a >> constrained client system. I think that whenever we get to doing a >> new operation, that we actually need a new session setup at that point >> anyway. > Hmm, but we perhaps cannot guarantee that this will hold universally > for all devices implementing coap-est. I do think that we can mandate > other aspects that make 3SHAKE impossible (like > extended-master-secret), though. okay. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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] AD review of draft-ietf-ace-coap-est-12 part 2
On Mon, Sep 09, 2019 at 12:54:12PM +0100, Michael Richardson wrote: > > Peter van der Stok wrote: > > . if the SignedData is not the outermost container, then we don't > > care what the relevant Content-Format for it is; we only care about the > > Content-Format for the EnvelopedData. > > > > > > s/ SignedData is signed/SignedData, placed in the outermost container, > > is signed/ > > > s/ The SignedData is further protected by placing it inside of a CMS > > EnvelopedData/ > > > SignedData placed within the Enveloped Data does not need additional > > signing/ > > > > > > Also, did we explicitly consider and reject AuthEnvelopedData? > > > > > > Not sure about this > > Jim Schaad wrote: > > [JLS] As a CMS person, I would consider the use of EnvelopedData and > > AuthEnvelopedData to be equivalent. Which of these is used is totally > > dependent on what algorithm is used for encryption. If one requires > > the use of AES-GCM or AES-CCM then one has no choice but to use > > AuthEnvelopedData. If one wants to use AES-CCM ten one has no choice > > but to use EnvelopedData. Everybody is slowly moving from > > EnvelopedData to AuthEnvelopedData just because everybody is changing > > algorithms. I do not remember any discussions about this, but > > AuthEnvelopeData is generally going to be the more correct value here. > > I will also note that there is a space between Enveloped and Data which > > is not CMS. > > > > So, on a constrained device, I'd like to know what to expect (what to code > for). While I do'nt particularly care for server-generated keys, it should > probably be specified correctly. I see that the complexity of sorting this > means that I think that Content-Format 284 (unprotected) will get used most > often. Your constrained device is probably only going to implement one cipher [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; otherwise, classic EnvelopedData. > Is there a good reference that would let us rip out more of this paragraph? We seem to have dropped enough quoting that there's not any paragraph here that's in the current document :) > > This carefully says nothing about recommendations for use, only for > > software support. Are we letting 7030's recommendation for use of > > encryption stand? It's probably worth being explicit, either way. > > Server-side key generation is optional, but when used, I agree that the > question of which mechanism the server should use to return the key is > completely open. The client can indicate what it supports via CoAP Accept > "header". https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/ > might be useful here. That seems like a good point. > > I did not find any recommendation for use in RFC7030 apart the > > responsibility of the server for generating random numbers. The > > recommendations at the top of section 5.8 of the draft seem adequate in > > my opinion. The alternative is classifying the applications; unless you > > see a better way to do this. > > > > > > Why OPTIONAL? (Also, nit: OPTIONALLY isn't a 2119 keyword; only > > OPTIONAL.) > > >client. For example, it could be configured to accept POP linking > > information that does not match the current TLS session because the > > authenticated EST client Registrar has verified this information when > > acting as an EST server. > > > This is close enough to a literal quote that we might think about > > actually quoting and using quotation marks. nit: s/POP/PoP/ if we > > don't do the literal quote. > > > > > > Hope my co-authors will react to this > > > [JLS] I would disagree with the nit. > > > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think > > that it ought to be at least a SHOULD if not a MUST for the use of > > COAPS as it is terminating the connection. The only exception would be > > in there is internal authentication for the EST request. > > > > > > Okay, I'm seeing three things here. > 1) tls-unique can't be used across the proxy, and we need additional >configuration. I don't think we should quote literally, I think the >point is to hammer the point home. > > 2) You are saying that we should replace tls-unique (RFC5929) with a TLS >Exporter. But RFC7030 didn't reference RFC5705. >You are suggesting that we update ourselves to use RFC5705. >That would seem to require that we change some PKIX things in CSR. >From a crypto perspective, we should do that. From a protocol-specification perspective, we should retain parity with classic EST and only update when it does. So we should probably mostly ignore this other than trying to kick off work on classic EST, and mandating extended-master-secret. > 3) I'm wondering if we need to have a clear
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Peter van der Stok wrote: > . if the SignedData is not the outermost container, then we don't > care what the relevant Content-Format for it is; we only care about the > Content-Format for the EnvelopedData. > > s/ SignedData is signed/SignedData, placed in the outermost container, > is signed/ > s/ The SignedData is further protected by placing it inside of a CMS > EnvelopedData/ > SignedData placed within the Enveloped Data does not need additional > signing/ > > Also, did we explicitly consider and reject AuthEnvelopedData? > > Not sure about this Jim Schaad wrote: > [JLS] As a CMS person, I would consider the use of EnvelopedData and > AuthEnvelopedData to be equivalent. Which of these is used is totally > dependent on what algorithm is used for encryption. If one requires > the use of AES-GCM or AES-CCM then one has no choice but to use > AuthEnvelopedData. If one wants to use AES-CCM ten one has no choice > but to use EnvelopedData. Everybody is slowly moving from > EnvelopedData to AuthEnvelopedData just because everybody is changing > algorithms. I do not remember any discussions about this, but > AuthEnvelopeData is generally going to be the more correct value here. > I will also note that there is a space between Enveloped and Data which > is not CMS. > So, on a constrained device, I'd like to know what to expect (what to code for). While I do'nt particularly care for server-generated keys, it should probably be specified correctly. I see that the complexity of sorting this means that I think that Content-Format 284 (unprotected) will get used most often. Is there a good reference that would let us rip out more of this paragraph? > This carefully says nothing about recommendations for use, only for > software support. Are we letting 7030's recommendation for use of > encryption stand? It's probably worth being explicit, either way. Server-side key generation is optional, but when used, I agree that the question of which mechanism the server should use to return the key is completely open. The client can indicate what it supports via CoAP Accept "header". https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/ might be useful here. > I did not find any recommendation for use in RFC7030 apart the > responsibility of the server for generating random numbers. The > recommendations at the top of section 5.8 of the draft seem adequate in > my opinion. The alternative is classifying the applications; unless you > see a better way to do this. > > Why OPTIONAL? (Also, nit: OPTIONALLY isn't a 2119 keyword; only > OPTIONAL.) >client. For example, it could be configured to accept POP linking > information that does not match the current TLS session because the > authenticated EST client Registrar has verified this information when > acting as an EST server. > This is close enough to a literal quote that we might think about > actually quoting and using quotation marks. nit: s/POP/PoP/ if we > don't do the literal quote. > > Hope my co-authors will react to this > [JLS] I would disagree with the nit. > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think > that it ought to be at least a SHOULD if not a MUST for the use of > COAPS as it is terminating the connection. The only exception would be > in there is internal authentication for the EST request. > Okay, I'm seeing three things here. 1) tls-unique can't be used across the proxy, and we need additional configuration. I don't think we should quote literally, I think the point is to hammer the point home. 2) You are saying that we should replace tls-unique (RFC5929) with a TLS Exporter. But RFC7030 didn't reference RFC5705. You are suggesting that we update ourselves to use RFC5705. That would seem to require that we change some PKIX things in CSR. 3) I'm wondering if we need to have a clear response/error code for the case where the tls-unique does not match. At least, from the HTTPS-EST server to the COAPS-EST "proxy" that might be valuable, even if the code it not sent back to the client. > Section 9.1 > I think we probably need this document as a reference for all the > allocations; as the document effectuating the registration, we are > still of interest even if most details of content encoding lie > elsewhere. > [JLS] No response from Peter? Is Ben suggesting that the table should say: +--+---++ | HTTP Media-Type |ID | Reference | +--+---++ | application/pkcs7-mime; | 280 | [THISDOCUMENT] | | smime-type=server-generated-
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
[trimming] On Tue, Sep 03, 2019 at 02:18:22PM +0200, Peter van der Stok wrote: > >[RFC7030] recommends the use of additional encryption of the returned >private key. For the context of this specification, clients and >servers that choose to support server-side key generation MUST >support unprotected (PKCS#8) private keys (Content-Format 284). >Symmetric or asymmetric encryption of the private key (CMS >EnvelopedData, Content-Format 280) SHOULD be supported for >deployments where end-to-end encryption needs to be provided between >the client and a server. Such cases could include architectures >where an entity between the client and the CA terminates the DTLS >connection (Registrar in Figure 4). > > This carefully says nothing about recommendations for use, only for > software support. Are we letting 7030's recommendation for use of > encryption stand? It's probably worth being explicit, either way. > > I did not find any recommendation for use in RFC7030 apart the > responsibility of the server for generating random numbers. The > recommendations at the top of section 5.8 of the draft seem adequate in > my opinion. The alternative is classifying the applications; unless you > see a better way to do this. I think the 7030 text I was thinking of is this: It is strongly RECOMMENDED that the clients request that the returned private key be afforded the additional security of the Cryptographic Message Syntax (CMS) EnvelopedData in addition to the TLS-provided security to protect against unauthorized disclosure. > > > [...] > >It is recommended, based on experiments, to follow the default CoAP >configuration parameters ([RFC7252]). However, depending on the >implementation scenario, retransmissions and timeouts can also occur >on other networking layers, governed by other configuration >parameters. A change in a server parameter MUST ensure the adjusted >value is also available to all the endpoints with which these >adjusted values are to be used to communicate. > > I don't understand who this is a normative requirement upon. Is it the > network operator's, to propagate configuration changes? Or is there > supposed to be some automated protocol that makes adjusted values > available? > > > > It is meant as reminder to anyone doing the configuration of a given > installation; you want to suppress the text? I don't want to suppress it, no. Maybe "A configuration change in a server parameter MUST be coordinated with all the endpoints with which these adjusted values are to be used to communicate"? Though I guess "coordinate" does not necessarily force the other endpoint to be using the identical value, just to know about it. > > [...] > > Appendix A.1 > > Option (Uri-Port) > Option Delta = 0x4 (option# 3+4=7) > Option Length = 0x4 > Option Value = 9085 > Option (Uri-Path) > Option Delta = 0x4 (option# 7+4=11) > Option Length = 0x5 > Option Value = "est" > > This is more for my own edification than the document's sake, so thank > you for your time, but what accounts for the "extra" length here? The > "est" is three bytes, and what makes up for the other two? Also, I > assume that the port value of 9805 is the decimal value, which gets > CBOR encoded into two bytes of integer encoding plus the byte with > additional information 25 to indicate the two-byte integer, and another > byte that I need help accounting for. > > > > Many thanks; an old misreading of an example in 7252. > > For the option length of URI-Path we included the quotations as well; > That is WRONG. > > Repaired it everywhere. > > Options are not CBOR encoded. Well, now I'm glad I asked -- thanks! > > > Appendix A.2 > > Do we want to say anything about the IDevID in the CSR/cert? > I note that the breakdown in Appendix C.2 (looks like openssl output) > does not decode the otherName (though asn1parse can be convinced to do > so). > > > > What do you suggest for IDevID? If we were going to add something (which remains unclear to me), it could be after the sentence "[...] the CSR contains a ChallengePassword which is used for POP linking (Section 4).", and be something like "This CSR also contains an RFC 7299 id-on-hardwareModuleName hardware identifier to customize the returned certificate to the requesting device." (The actual identifier here is the same one mentioned in https://www.mail-archive.com/anima@ietf.org/msg00938.html, from Bob Moskowitz's OID arc.) > Actually openssl was used extensively for generating the examples. > > Will be happy to learn about otherName otherName is an OID-indexed generic name container for the cert; it's a form of subjectAltName. What I did here was: ~$ unhex|openssl asn1parse -inform der 3082018b30820131020100305c310b3009060355040613025553310b3009
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
On Wed, Sep 04, 2019 at 09:02:06AM +0200, Peter van der Stok wrote: > I concluded on the pruned . > > Peter > Jim Schaad schreef op 2019-09-03 20:48: > > > I have pruned and tossed in a few [JLS] comments. > > > > Jim > > > > FROM: Peter van der Stok > > SENT: Tuesday, September 3, 2019 5:18 AM > > TO: Benjamin Kaduk > > CC: Jim Schaad ; > > draft-ietf-ace-coap-est@ietf.org; consulta...@vanderstok.org; > > ace@ietf.org > > SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > Hi Ben, > > > > the last part of the responses to your thorough review. > > Apart from nits you found some "nice" mistakes. > > > > the openssl example make me worry a bit. > > > > See below. > > > > Peter > > ___ > > > > SignedData is signed by the party that generated the private key, > > which may be the EST server or the EST CA. The SignedData is further > > protected by placing it inside of a CMS EnvelopedData as explained in > > Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted > > > > if the SignedData is not the outermost container, then we don't care > > what the relevant Content-Format for it is; we only care about the > > Content-Format for the EnvelopedData. > > > > > > > > s/ SignedData is signed/SignedData, placed in the outermost container, is > > signed/ > > > > s/ The SignedData is further protected by placing it inside of a CMS > > EnvelopedData/ > > > > SignedData placed within the Enveloped Data does not need additional > > signing/ > > > > > > > > Also, did we explicitly consider and reject AuthEnvelopedData? > > > > > > > > Not sure about this > > > > [JLS] As a CMS person, I would consider the use of EnvelopedData and > > AuthEnvelopedData to be equivalent. Which of these is used is totally > > dependent on what algorithm is used for encryption. If one requires the > > use of AES-GCM or AES-CCM then one has no choice but to use > > AuthEnvelopedData. If one wants to use AES-CCM ten one has no choice but > > to use EnvelopedData. Everybody is slowly moving from EnvelopedData to > > AuthEnvelopedData just because everybody is changing algorithms. I do not > > remember any discussions about this, but AuthEnvelopeData is generally > > going to be the more correct value here. I will also note that there is a > > space between Enveloped and Data which is not CMS. > > > > > > I don't do anything here > > I was reading Jim as suggesting to make a change here (though exactly what change, I'm not sure). > > > > > > encryptedKey attribute in a KeyTransRecipientInfo structure. > > Finally, if the asymmetric encryption key is suitable for key > > agreement, the generated private key is encrypted with a symmetric > > key which is encrypted by the client defined (in the CSR) asymmetric > > > > In the key-agreement case, the symmetric key-encryption key is the > > result of the key-agreement operation, no? In which case it is not > > itself encrypted, but rather the server's ephemeral public value is > > sent. > > > > > > > > In RFC7030 the text says: the EnvelopedData content is encrypted using a > > randomly > > > > generated symmetric encryption key (that means ephemeral I assume). The > > cryptographic strength of > > > > the symmetric encryption key SHOULD be equivalent to the clientspecified > > > > asymmetric key. > > > > However, I see no explicit relation with the ephemeral public value. > > > > I don't know what to do here; probably insert the 7030 text. > > > > [JLS] Ben, you do not have the correct view of the key-agreement case. It > > does a key agreement -> KDF -> KeyWrap -> Content. There is always a key > > wrap step between the key agreement and the content encryption key. > > > > Also here I see no room for improvement then. > > > > > > > > > > public key and is carried in an recipientEncryptedKeys attribute in a > > KeyAgreeRecipientInfo. > > > > [RFC7030] recommends the use of additional encryption of the returned > > private key. For the context of this specification, clients and > > servers that choose to support server-side key generation MUST > > support unprotected (PKCS#8) private keys (Content-Format 28
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Jim, Thanks for taking a closer look. It's been a long week, so I'm not sure if you're saying that I was doing the decoding wrong, expecting the wrong structure, or both. -Ben On Wed, Sep 04, 2019 at 11:02:31AM -0700, Jim Schaad wrote: > Let me draw back and re-address the comment from Ben about the private key in > appendix A.3 > > > > If I take > > > > 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 > > 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 > > 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 > > 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 > > cd33f3c1846e304f1717f8123f1a284cc99f > > > > and decode it I get (with comments from me) > > > > SEQUENCE (3 elem)-- OneAsymmetricKey (replacement of PKCS #8) > > INTEGER 0 -- Version = v1 > > SEQUENCE (2 elem) -- privateKeyAlgorithm > > OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key > type) -- Alg ID > > OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named > elliptic curve) – Parameters == P256 > > OCTET STRING (1 elem) – Private Key > > SEQUENCE (3 elem) – ECPrivate Key [RFC 5915] > > INTEGER 1 – Version – ecPrivkeyVer1 > > OCTET STRING (32 byte) > 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 – Private > Key value > > [1] (1 elem) – Public key value > > BIT STRING (520 bit) > 01011011101110001101000100010000100101101001100011… > > > > > > This looks correct to me. > > > > Jim > > > > > > > > > > From: Peter van der Stok > Sent: Wednesday, September 4, 2019 12:02 AM > To: Jim Schaad > Cc: consulta...@vanderstok.org; 'Benjamin Kaduk' ; > draft-ietf-ace-coap-est@ietf.org; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > I concluded on the pruned . > > Peter > > Jim Schaad schreef op 2019-09-03 20:48: > > I have pruned and tossed in a few [JLS] comments. > > > > Jim > > > > > > From: Peter van der Stok mailto:stokc...@bbhmail.nl> > > Sent: Tuesday, September 3, 2019 5:18 AM > To: Benjamin Kaduk mailto:ka...@mit.edu> > > Cc: Jim Schaad mailto:i...@augustcellars.com> >; > draft-ietf-ace-coap-est@ietf.org > <mailto:draft-ietf-ace-coap-est@ietf.org> ; consulta...@vanderstok.org > <mailto:consulta...@vanderstok.org> ; ace@ietf.org <mailto:ace@ietf.org> > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > Hi Ben, > > the last part of the responses to your thorough review. > Apart from nits you found some "nice" mistakes. > > the openssl example make me worry a bit. > > See below. > > Peter > ___ > > >SignedData is signed by the party that generated the private key, >which may be the EST server or the EST CA. The SignedData is further >protected by placing it inside of a CMS EnvelopedData as explained in >Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted > > if the SignedData is not the outermost container, then we don't care > what the relevant Content-Format for it is; we only care about the > Content-Format for the EnvelopedData. > > > > s/ SignedData is signed/SignedData, placed in the outermost container, is > signed/ > > s/ The SignedData is further protected by placing it inside of a CMS > EnvelopedData/ > > SignedData placed within the Enveloped Data does not need additional signing/ > > > > Also, did we explicitly consider and reject AuthEnvelopedData? > > > > Not sure about this > > [JLS] As a CMS person, I would consider the use of EnvelopedData and > AuthEnvelopedData to be equivalent. Which of these is used is totally > dependent on what algorithm is used for encryption. If one requires the use > of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData. > If one wants to use AES-CCM ten one has no choice but to use EnvelopedData. > Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just > because everybody is changing algorithms. I do not remember any discussions > about this, but AuthEnvelopeData is generally going to be the more correct > value here. I will also note that there is a space between Enveloped and > Data which is not CMS. > > > I don't do anything here > > > > > > &g
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Jim, I removed the passwd from the example, and did the disassembly as Ben proposed. That seems to work correctly for me. 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7 679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc 494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95 cf75f602f9152618f816a2b23b5638e59fd9 Peter Jim Schaad schreef op 2019-09-04 20:02: > Let me draw back and re-address the comment from Ben about the private key in > appendix A.3 > > If I take > > 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 > > 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 > > 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 > > 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 > > cd33f3c1846e304f1717f8123f1a284cc99f > > and decode it I get (with comments from me) > > SEQUENCE (3 elem)-- OneAsymmetricKey (replacement of PKCS #8) > > INTEGER 0 -- Version = v1 > > SEQUENCE (2 elem) -- privateKeyAlgorithm > > OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type) > -- Alg ID > > OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic > curve) - Parameters == P256 > > OCTET STRING (1 elem) - Private Key > > SEQUENCE (3 elem) - ECPrivate Key [RFC 5915] > > INTEGER 1 - Version - ecPrivkeyVer1 > > OCTET STRING (32 byte) > 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 - Private > Key value > > [1] (1 elem) - Public key value > > BIT STRING (520 bit) > 01011011101110001101000100010000100101101001100011... > > This looks correct to me. > > Jim > > FROM: Peter van der Stok > SENT: Wednesday, September 4, 2019 12:02 AM > TO: Jim Schaad > CC: consulta...@vanderstok.org; 'Benjamin Kaduk' ; > draft-ietf-ace-coap-est@ietf.org; ace@ietf.org > SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > I concluded on the pruned . > > Peter > > Jim Schaad schreef op 2019-09-03 20:48: > >> I have pruned and tossed in a few [JLS] comments. >> >> Jim >> >> FROM: Peter van der Stok >> SENT: Tuesday, September 3, 2019 5:18 AM >> TO: Benjamin Kaduk >> CC: Jim Schaad ; >> draft-ietf-ace-coap-est@ietf.org; consulta...@vanderstok.org; >> ace@ietf.org >> SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 >> >> Hi Ben, >> >> the last part of the responses to your thorough review. >> Apart from nits you found some "nice" mistakes. >> >> the openssl example make me worry a bit. >> >> See below. >> >> Peter >> ___ >> >> SignedData is signed by the party that generated the private key, >> which may be the EST server or the EST CA. The SignedData is further >> protected by placing it inside of a CMS EnvelopedData as explained in >> Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted >> >> if the SignedData is not the outermost container, then we don't care >> what the relevant Content-Format for it is; we only care about the >> Content-Format for the EnvelopedData. >> >> >> >> s/ SignedData is signed/SignedData, placed in the outermost container, is >> signed/ >> >> s/ The SignedData is further protected by placing it inside of a CMS >> EnvelopedData/ >> >> SignedData placed within the Enveloped Data does not need additional >> signing/ >> >> >> >> Also, did we explicitly consider and reject AuthEnvelopedData? >> >> >> >> Not sure about this >> >> [JLS] As a CMS person, I would consider the use of EnvelopedData and >> AuthEnvelopedData to be equivalent. Which of these is used is totally >> dependent on what algorithm is used for encryption. If one requires the use >> of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData. >> If one wants to use AES-CCM ten one has no choice but to use EnvelopedData. >> Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just >> because everybody is changing algorithms. I do not remember any discussions >> about this, but AuthEnvelopeData is generally going to be the more correct >> value here. I will also note that there is a space between Enveloped and >> Data which is not CMS. >> >> >> I don't do anything here >> >&g
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
I concluded on the pruned . Peter Jim Schaad schreef op 2019-09-03 20:48: > I have pruned and tossed in a few [JLS] comments. > > Jim > > FROM: Peter van der Stok > SENT: Tuesday, September 3, 2019 5:18 AM > TO: Benjamin Kaduk > CC: Jim Schaad ; > draft-ietf-ace-coap-est@ietf.org; consulta...@vanderstok.org; ace@ietf.org > SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > Hi Ben, > > the last part of the responses to your thorough review. > Apart from nits you found some "nice" mistakes. > > the openssl example make me worry a bit. > > See below. > > Peter > ___ > > SignedData is signed by the party that generated the private key, > which may be the EST server or the EST CA. The SignedData is further > protected by placing it inside of a CMS EnvelopedData as explained in > Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted > > if the SignedData is not the outermost container, then we don't care > what the relevant Content-Format for it is; we only care about the > Content-Format for the EnvelopedData. > > > > s/ SignedData is signed/SignedData, placed in the outermost container, is > signed/ > > s/ The SignedData is further protected by placing it inside of a CMS > EnvelopedData/ > > SignedData placed within the Enveloped Data does not need additional signing/ > > > > Also, did we explicitly consider and reject AuthEnvelopedData? > > > > Not sure about this > > [JLS] As a CMS person, I would consider the use of EnvelopedData and > AuthEnvelopedData to be equivalent. Which of these is used is totally > dependent on what algorithm is used for encryption. If one requires the use > of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData. > If one wants to use AES-CCM ten one has no choice but to use EnvelopedData. > Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just > because everybody is changing algorithms. I do not remember any discussions > about this, but AuthEnvelopeData is generally going to be the more correct > value here. I will also note that there is a space between Enveloped and > Data which is not CMS. > > > I don't do anything here > > > > > encryptedKey attribute in a KeyTransRecipientInfo structure. > Finally, if the asymmetric encryption key is suitable for key > agreement, the generated private key is encrypted with a symmetric > key which is encrypted by the client defined (in the CSR) asymmetric > > In the key-agreement case, the symmetric key-encryption key is the > result of the key-agreement operation, no? In which case it is not > itself encrypted, but rather the server's ephemeral public value is > sent. > > > > In RFC7030 the text says: the EnvelopedData content is encrypted using a > randomly > > generated symmetric encryption key (that means ephemeral I assume). The > cryptographic strength of > > the symmetric encryption key SHOULD be equivalent to the clientspecified > > asymmetric key. > > However, I see no explicit relation with the ephemeral public value. > > I don't know what to do here; probably insert the 7030 text. > > [JLS] Ben, you do not have the correct view of the key-agreement case. It > does a key agreement -> KDF -> KeyWrap -> Content. There is always a key > wrap step between the key agreement and the content encryption key. > > Also here I see no room for improvement then. > > > > > public key and is carried in an recipientEncryptedKeys attribute in a > KeyAgreeRecipientInfo. > > [RFC7030] recommends the use of additional encryption of the returned > private key. For the context of this specification, clients and > servers that choose to support server-side key generation MUST > support unprotected (PKCS#8) private keys (Content-Format 284). > Symmetric or asymmetric encryption of the private key (CMS > EnvelopedData, Content-Format 280) SHOULD be supported for > deployments where end-to-end encryption needs to be provided between > the client and a server. Such cases could include architectures > where an entity between the client and the CA terminates the DTLS > connection (Registrar in Figure 4). > > This carefully says nothing about recommendations for use, only for > software support. Are we letting 7030's recommendation for use of > encryption stand? It's probably worth being explicit, either way. > > I did not find any recommendation for use in RFC7030 apart the > responsibility of the server for generating random num
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
I have pruned and tossed in a few [JLS] comments. Jim From: Peter van der Stok Sent: Tuesday, September 3, 2019 5:18 AM To: Benjamin Kaduk Cc: Jim Schaad ; draft-ietf-ace-coap-est@ietf.org; consulta...@vanderstok.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Hi Ben, the last part of the responses to your thorough review. Apart from nits you found some "nice" mistakes. the openssl example make me worry a bit. See below. Peter ___ SignedData is signed by the party that generated the private key, which may be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted . if the SignedData is not the outermost container, then we don't care what the relevant Content-Format for it is; we only care about the Content-Format for the EnvelopedData. s/ SignedData is signed/SignedData, placed in the outermost container, is signed/ s/ The SignedData is further protected by placing it inside of a CMS EnvelopedData/ SignedData placed within the Enveloped Data does not need additional signing/ Also, did we explicitly consider and reject AuthEnvelopedData? Not sure about this [JLS] As a CMS person, I would consider the use of EnvelopedData and AuthEnvelopedData to be equivalent. Which of these is used is totally dependent on what algorithm is used for encryption. If one requires the use of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData. If one wants to use AES-CCM ten one has no choice but to use EnvelopedData. Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just because everybody is changing algorithms. I do not remember any discussions about this, but AuthEnvelopeData is generally going to be the more correct value here. I will also note that there is a space between Enveloped and Data which is not CMS. encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric In the key-agreement case, the symmetric key-encryption key is the result of the key-agreement operation, no? In which case it is not itself encrypted, but rather the server's ephemeral public value is sent. In RFC7030 the text says: the EnvelopedData content is encrypted using a randomly generated symmetric encryption key (that means ephemeral I assume). The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the clientspecified asymmetric key. However, I see no explicit relation with the ephemeral public value. I don’t know what to do here; probably insert the 7030 text. [JLS] Ben, you do not have the correct view of the key-agreement case. It does a key agreement -> KDF -> KeyWrap -> Content. There is always a key wrap step between the key agreement and the content encryption key. public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for deployments where end-to-end encryption needs to be provided between the client and a server. Such cases could include architectures where an entity between the client and the CA terminates the DTLS connection (Registrar in Figure 4). This carefully says nothing about recommendations for use, only for software support. Are we letting 7030's recommendation for use of encryption stand? It's probably worth being explicit, either way. I did not find any recommendation for use in RFC7030 apart the responsibility of the server for generating random numbers. The recommendations at the top of section 5.8 of the draft seem adequate in my opinion. The alternative is classifying the applications; unless you see a better way to do this. Why OPTIONAL? (Also, nit: OPTIONALLY isn't a 2119 keyword; only OPTIONAL.) client. For example, it could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST client Registrar has verified this information when acting as an EST server. This is close enough to a literal quote that we might think about actually quoting and using quotation marks. nit: s/POP/PoP/ if we don't do the literal quote. Hope my co-authors will react to
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Hi Ben, the last part of the responses to your thorough review. Apart from nits you found some "nice" mistakes. the openssl example make me worry a bit. See below. Peter ___ When requesting server-side key generation, the client asks for the server or proxy to generate the private key and the certificate which are transferred back to the client in the server-side key generation response. In all respects, the server SHOULD treat the CSR as it would treat any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests. We need to reword this; the SHOULD is in conflict with the MUST. Removed the SHOULD -> "…the server treats the CSR …" certificate and a private key. The private key Content-Format requested by the client is depicted in the PKCS#10 CSR request. If nit: I suggest s/depicted/indicated/ done (Section 5.3) . The two representations (each consisting of two CBOR array items) do not have to be in a particular order since each s/do not have to be in a particular order since each representation is/ are/ [side note: core-multipart-ct is looking to land on "multipart/mixed" semantics to resolve my outstanding Discuss point; RFC 2046 is pretty clear about the component parts "need[ing] to be in a particular order", which this is in conflict with] representation is preceded by its Content-Format ID. The private key can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or protected inside of CMS SignedData (Content-Format 280). The Phrasing it like this makes it soun like the server can just spontaneously decide that it wants to sign the key content, as opposed to having it be dependant on the CSR's contents. Also... /The private key/ Dependent on the contents of the CSR, the private key/ SignedData is signed by the party that generated the private key, which may be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted . if the SignedData is not the outermost container, then we don't care what the relevant Content-Format for it is; we only care about the Content-Format for the EnvelopedData. s/ SignedData is signed/SignedData, placed in the outermost container, is signed/ s/ The SignedData is further protected by placing it inside of a CMS EnvelopedData/ SignedData placed within the Enveloped Data does not need additional signing/ Also, did we explicitly consider and reject AuthEnvelopedData? Not sure about this key is included in the encryptedKey attribute in a KEKRecipientInfo structure. In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an nit: hyphenate "client-defined" done encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric In the key-agreement case, the symmetric key-encryption key is the result of the key-agreement operation, no? In which case it is not itself encrypted, but rather the server's ephemeral public value is sent. In RFC7030 the text says: the EnvelopedData content is encrypted using a randomly generated symmetric encryption key (that means ephemeral I assume). The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the clientspecified asymmetric key. However, I see no explicit relation with the ephemeral public value. I don't know what to do here; probably insert the 7030 text. public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for deployments where end-to-end encryption needs to be provided between the client and a server. Such cases could include architectures where an entity between the client and the CA terminates the DTLS connection (Registrar in Figure 4). This carefully says nothing about recommendations for use, only for
