EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol
RFC 9148
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
Alvaro Retana No Objection
Roman Danyliw No Objection
* Section 4. Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I think the text means that some EST messages are more likely to occur one after another. It would be worth being clearer what these would be. * Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does Table 1 imply that when using EST-coaps the “longer names” from RFC7030 wouldn’t be valid? * Section 5.2 Per “The latter ones are deemed to expensive …”, was difficult to parse as the sentence prior has three things (instead of two). Is this sentence referring to the “not specified functions” only? * Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite this metric, please do. * Section 5.8. Per “In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in a server-side key generation scenario, where is the client getting the key to decrypt the server computed key material? Should the DecryptKeyIdentifier/ AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections 4.4.1.1/4.4.1.2 of RFC7030? * Section 10.1. Per “When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925].”, is the “security protocols” referenced here anything beyond DTLS? * Section 10.1. Per “In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to ensure that the client is to be trusted.” -- does this text suggest that expired+revoked certificates should not be used? -- to word-smith: s/for the server to ensure that the client is to be trusted/for the server to raise its confidence that the client can be trusted/ * Section 10.1. Per “More information about recommendations of TLS and DTLS are included in [BCP195]”, thanks for referencing BCP195. Could you please clarify with normative language if these recommendations SHOULD/MUST be followed? * Editorial - Section 4. Per “Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth”, I’m not sure this sentence is needed. Technically, “authenticating and negotiating DTLS keys requires resources” on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, NEW: Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is …/Such scenarios apply when it is …/ - Section 5.8. s/ client, or when the resources/client, when the resources/ - Section 5.8. s/Then the private key/The private key/
Warren Kumari No Objection
(Benjamin Kaduk; former steering group member) Yes
(Adam Roach; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss and comments!
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
Thank you for this well written document. And thank you for addressing my points in github. A remaining comment (which might or might not have been resolved): 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST?
(Alissa Cooper; former steering group member) No Objection
Section 10.1: "It is also RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication." This strikes me as a slightly odd use of normative language (what are the exception cases when the trust anchor database should not be carefully managed?).
(Barry Leiba; former steering group member) No Objection
Thanks for this — a useful document. I have a bunch of comments, but they’re all editorial. Please consider them, but there’s not a need to give a detailed reply.
-- Section 4 --
In that case, the
server MAY want to authenticate a client certificate against its
trust store although the certificate is expired (Section 10).
Total nit: Why "want to"? Why not "server MAY authenticate"?
As described in Section 2.1 of [RFC5272] proof-of-identity refers to
a value that can be used to prove that the private key corresponding
to the certified public key is in the possession of and can be used
by an end-entity or client.
I find the passive voice to be quite awkward here, and suggest making it active:
NEW
As described in Section 2.1 of [RFC5272], proof-of-identity refers
to a value that can be used to prove that an end-entity or client is
in possession of and can use the private key corresponding to the
certified public key.
END
the event of handshake message fragmentation, the Hash of the
handshake messages used in the MAC calculation of the Finished
message must be computed as if each handshake message had been sent
as a single fragment (Section 4.2.6 of [RFC6347]).
I know this wording is directly from 6347, but I think it's unclear and would like to suggest an alternative. The "as a single fragment" part is odd, because I think what it's really saying is that it's computed as if it had not been fragmented. My suggestion is to change it thus (and similarly for the next paragraph after):
NEW
the event of handshake message fragmentation, the Hash of the
handshake messages used in the MAC calculation of the Finished
message must be computed on each reassembled message, as if
each handshake message had not been fragmented (Section 4.2.6
of [RFC6347]).
END
If that's not correct, please take that as further evidence that it's unclear, and adjust accordingly.
To alleviate this
situation, an EST-coaps DTLS connection MAY remain open for
sequential EST transactions which was not the case with [RFC7030].
For example, an EST csrattrs request that is followed by a
simpleenroll request can use the same authenticated DTLS connection.
Two total nits:
a. Comma before "which", please.
b. The "for example" needs some rewording to make it work:
NEW
For example, if an EST csrattrs request is followed by a
simpleenroll request, both can use the same authenticated
DTLS connection.
END
-- Section 5.1 --
EST-coaps is targeted for low-resource networks with small packets.
Two types of installations are possible (1) rigid ones where the
address and the supported functions of the EST server(s) are known,
and (2) flexible one where the EST server and it supported functions
need to be discovered.
This needs a colon (:) after "possible", a comma after "rigid ones", "a" before "flexible one", another comma after "flexible one", and make it "its supported".
-- Section 5.5 --
Similarly, 2.04
is used in successfull response to EST-coaps POST requests (/sen,
/sren, /skg, /skc).
There's odd spacing here; please fix it. And "successful" is misspelled.
-- Section 5.7 --
If the server is very slow (i.e., minutes) in providing the response
(i.e., when a manual intervention is needed),
I think you mean "e.g." for both of those, evidence for my general aversion to using Latin abbreviations that many people don't fully understand. It also feels odd to have the two examples separated in this way. I suggest this:
NEW
If the server is very slow in providing the response (for example,
manual intervention is required and it could take minutes for it
to respond),
END
it SHOULD respond with
an ACK containing response code 5.03 (Service unavailable) and a Max-
Age Option to indicate the time the client SHOULD wait to request the
content later.
Perhaps, "to indicate the time the client SHOULD wait before sending another request to obtain the content." ?
After a delay of Max-Age, the client SHOULD resend
the identical CSR to the server. As long as the server responds with
response code 5.03 (Service Unavailable) with a Max-Age Option, the
client SHOULD keep resending the enrollment request until the server
responds with the certificate or the client abandons the request for
other reasons.
That last sentence reads very strangely to me. It SHOULD keep resending the request until it decides to stop? What does that actually mean?
Maybe what you're really trying to say is something like this?:
NEW
As long as the server continues responding with
response code 5.03 (Service Unavailable) with a Max-Age Option, the
client will continue to delay for Max-Age and then resend the
enrollment request until the server responds with the certificate or
the client abandons the request for policy or other reasons.
END
-- Section 5.8 --
In scenarios where it is desirable that the server generates the
private key, server-side key generation is available.
This seems like a content-free sentence. Maybe this?:
NEW
Private keys can be generated on the server. Scenarios where
that makes sense include those where it is considered more
secure...
END
Of course, that does not eliminate the
need for proper random numbers in various protocols like (D)TLS
(Section 10.1).
May I suggest this?:
NEW
As always, it is necessary to use proper random numbers in
various protocols such as (D)TLS (Section 10.1).
END
server or proxy to generate the private key and the certificate which
are transferred back to the client
Needs a comma before "which".
or the asymmetric keypair establishment method is out of scope of the
specification.
"of this specification".
[I-D.ietf-core-multipart-ct] containing a CBOR array with four items
(Section 5.3)
. The two representations
More odd spacing.
Dependent on the request, the
private key can be in unprotected PKCS#8 [RFC5958] format
"Depending upon the request"
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 encryptedKey attribute in
a KeyTransRecipientInfo structure.
Long sentence that needs punctuation: comma after "operations", comma before "which", comma before "and". Also, I would move "(in the CSR)" a few words later, after "public key".
-- Section 7 --
It is recommended, based on experiments,
to follow the default CoAP configuration parameters ([RFC7252]).
Odd spacing, again. But "it is recommended to follow" is also odd English. I suggest making this active, rather than passive, thus:
NEW
Implementations should follow the default CoAP configuration
parameters ([RFC7252]).
END
I don't think the "based on experiments" bit adds anything, but if you want to keep it you can prepend "Experiments have shown that" to my suggestion.
-- Section 9.1 --
Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" just a flag to remind people that it hadn't been formally allocated yet?
— Section 10.1 —
It is important to note that sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs are
not available on many constrained devices, such as mouse movement,
timing of keystrokes, or air turbulence on the movement of hard drive
heads, as pointed out in [PsQs].
The sentence order is wrong here. For example, mouse movement is not a constrained device. The correct order is more like this:
NEW
It is important to note that, as pointed out in [PsQs], sources
contributing to the randomness pool used to generate random
numbers on laptops or desktop PCs, such as mouse movement,
timing of keystrokes, or air turbulence on the movement of hard
drive heads, are not available on many constrained devices.
END
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
Thanks for resolving my Discuss in the upcoming version.
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection