Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Section 2. Where is the uri (CCDL) syntax/format/data type (used by x5u and x5u-sender) defined? Is this covered by CBOR tag=32?
I would like to recognize Jim Schaad’s tremendous contribution to the IETF as author, implementer, mentor and leader. Thank you to the Charlie Kaufman for the SECDIR review. This review proposes and poses a few places where clarifying text would be helpful. Please respond to it. ** Section 1. Per the github pointer with examples: -- please add this url as a reference, not an inline url -- which exact set of references are relevant to this draft? It isn’t clear how this collection of examples applies. ** Section 2. Recommend precision on the string vs. integer algorithm identifier. OLD The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier. The algorithm is registered in the "COSE Algorithms" registry NEW The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier corresponding to either the Value (integer) or Name (string) column of the algorithm registered in the "COSE Algorithms" registry. ** Table 1. To line up with the column names of COSE Headers Parameters registry with this table, s/Type/Value Type/ ** Section 5. Recommend pointing to Section 7 of RFC3986 to cover security considerations of URI. ** Section 5. Per “On the other hand, an oracle can potentially be built based on detecting the network resources which is only done if the signature validation passes.”, I didn’t follow what this means. ** Editorial Nits -- Section 1. Editorial. Multiple typos. OLD In the process of writing [RFC8152] the working group discussed X.509 certificates [RFC5280] ad decided that no use cases wher prestented that showed a need to support certificates NEW In the process of writing [RFC8152], the working group discussed X.509 certificates [RFC5280] and found that that no use cases were presented that showed a need to support certificates -- Section 1. Editorial. OLD for example, in the 6TiSCH environment [I-D.richardson-enrollment-roadmap], describes a device enrollment solution that relies on the presence in the device of a factory-installed certificate. NEW for example, in the 6TiSCH environment, [I-D.richardson-enrollment-roadmap] describes a device enrollment solution that relies on the presence of a factory-installed certificate on the device. -- Section 2. Editorial. s/be configured use a/be configured to us a/ -- Section 2. There appears to be a missing transition from describing x5u and Table 1 which applies to all the preceding text.
I think the topic should be fairly easily to resolve one way or another. However, even after having read the reply to Marin's comment I don't think this document is published with the right status. - The document defines new CBOR attributes, that is standard track work as it comes out as consensus document from a IETF WG. - It does not define or document crypto algorithm just refer to existing ones. - The charter item might have been reasonable as informational if existing attributes could have been used. With the choice to define new attributes I think this has entered standards track. - The status of the document I think will also affect the value that IANA might assign to these COSE Header Parameters. If there are additional considerations I am happy to learn about them. Else, I would propose a change of status to proposed standard and redo the IETF last call.
It's still hard to believe we've lost Jim. Thank you for taking up the mantle to finish this work. As Roman noted already, the secdir review had some good points (and perhaps also some that do not require changes to the text), which deserves a response. [The missing examples in the linked github repo have already been noted a few times so I have nothing further to say about it.] It's interesting that JOSE does not have an 'x5bag' parameter, though I don't think that there is a need for this document to do anything in that regard. Abstract The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parts of keys as needed. The COSE (nit) I'm not sure that "parts of keys" covers all cases; the boundary between a "key" and various attributes or parameters associated with it can be fuzzy at times. Perhaps something like "parameters relating to keys" would be more encompassing? Section 2 required certificate evaluation and processing. It is also reasonable that a constrained device would have the hash of a certificate associated with a public key and be configured use a public key for that thumbprint, but without performing the certificate evaluation or even having the entire certificate. This implies that the constrained device is not doing the required revocation checking, which probably merits some form of caveat (a management system that monitors revocation and updates the device if needed?). This is particularly poingnant given the following paragraphs admonition that "[c]ertificates [...] MUST still be validated". a chain length of one as well as longer chains. If the application cannot establish trust in the certificate, that certificate cannot be used. The secdir review already noted some potential issues with the blanket "cannot be used"; another possible rewording would be "the public key contained in the certificate cannot be used for cryptographic operations". x5chain: This header parameter contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate which signed it and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate the missing certificates. This means that the relying Are the missing certificates required to be contiguous and contain the root? That is, is it okay to leave a gap in the middle of the chain? [still x5chain] This header parameter allows for a single X.509 certificate or a chain of X.509 certificates to be carried in the message. It's slightly surprising that the "chain" structure allows for a single certificate not in an array container; it might be intuitively more simple to just always use the array encoding for a chain, even a one-element chain. But I'm sure there's some reason to allow it, too, just not one that I thought of right away. x5t: This header parameter provides the ability to identify an X.509 certificate by a hash value. The attribute is an array of two I suggest using the word "thumbprint" somewhere to motivate the 't' in "x5t". Also, we may want to make a pass to check for consistent usage of "attribute", "parameter", etc. -- I think this is the first time we say "the attribute is". For interoperability, applications which use this header parameter MUST support the hash algorithm 'SHA-256', but can use other hash algorithms. In light of the following notes, perhaps we should add another sentence along the lines of "This requirement allows for different implementations to be configured to use an interoperable algorithm, but does not preclude the use (by prior agreement) of other algorithms." x5u: This header parameter provides the ability to identify an X.509 [...] As this header parameter implies a trust relationship, the attribute MUST be in the protected attribute bucket. In light of the secdir reviewer's comments, perhaps "a trust relationship between the party generating the x5u parameter and the party hosting the referred-to resource" would help? The URI provided MUST provide integrity protection and server authentication. For example, an HTTP or CoAP GET request to retrieve a certificate MUST use TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13]. If the certificate does not chain to an existing trust anchor, the certificate MUST NOT be trusted unless I think we should probably clarify that it is the "received" or "retrieved" certificate (as opposed to the certificate used to authenticate the (D)TLS connection used to dereference the URI). the server is configured as trusted to provide new trust anchors. In particular, self-signed certificates MUST NOT be trusted without an out-of-band confirmation. I agree with the secdir reviewer that some rewording/clarification is in order here. +---------+-------+---------------+---------------------+ | x5u | TBD2 | uri | URI pointing to an | | | | | X.509 certificate | +---------+-------+---------------+---------------------+ I agree with Roman that a more explicit statement of where the uri type is defined (or inline definition) is needed. The header parameters are used in the following locations: [...] I guess draft-ietf-cose-countersign is on the hook for specifying anything needed about the X.509-related parameter usage? It looks like COSE_Countersignature reuses the COSE_Signature sturcture, but I would not (naively) expect that to also inherit the ability to use these parameters. COSE_Countersignature0 does not have any place to stow metadata, so I guess these parameters are not useful at all there. In Table 2, I think all the "AES192KW" and "AES256KW" should be "A192KW" and "A256KW", respectively. Section 5 I think we need to explicitly pull in (by reference) the security considerations from RFC 3986, arguably with specific call-out to the "reliability and consistency" portions. We might also mention that path validation is an important part of establishing trust in a certificate and point to RFC 5280. I don't feel a huge need to also mention the possibility of constructing alternative chains, though we could do that as well if desired. We should probably also have some pro-forma mention of the strength of the hash used for a certificate thumbprint being a factor in the security of the system. Section 6.2 I feel like RFC 8152 (or the bis) ought to be present as a normative reference; you cannot implement these new parameters outside the context of a broader COSE implementation.
Thanks for taking this on. Please respond to the Gen-ART review. May Jim rest in peace.
I see that it's in the charter as such, but I have no idea why this is otherwise an Informational RFC, as it extends a Standard RFC and has some normative language in it for interoperability. I am not a fan of the passive voice in Section 2: "Certificates obtained from any of these methods MUST still be validated." Who has to validate it? It sounds like we are not requiring constrained devices to do this validation, so the document really ought to pin the responsibility on the system.
[[ nits ]] [ section 1 ] * "ad decided" -> "and decided" * "wher prestented" -> "were presented" [ section 2 ] * "evaluate and process of X.509 certificates" -> "evaluate and process X.509 certificates" * "configured use" -> "configured to use" * "registry The" -> "registry. The"
I would like to add my thanks to Jim Schaad for this document, and for all of his other contributions to the IETF. -- Section 1 includes a GitHub URL where the reader can find examples. Is this acceptable as a permanent reference? Section 2: * "... will evaluate and process of X.509 certificates ..." -- remove "of"? * "... and be configured use ..." -- add "to"? * The first paragraph of the "x5t" bullet seems to have a couple of sentences smashed together at the end. * Has the note about the AD Review comments in this section been resolved?
Strange feeling to review this Jim Schaad's document... Thank you Carsten for the IoT directorate review at: https://datatracker.ietf.org/doc/review-ietf-cose-x509-07-iotdir-telechat-bormann-2020-10-19/ The major issue found by Carsten (missing files in the github repo) should be resolved before publication. -éric
I would like to thank Jim Schaad for this document and all his other work at IETF. My only minor comment is that I was surprised by the name "x5bag", which in computing terms I generally understand to be defined as a data structure that is like a set but it can contain duplicate values (also known as a multiset). It wasn't clear to me that was the intended purpose here, but I seem to recall that 'bag' might take a slightly different meaning in security circles? Either way, it might be helpful to specify both for the x5bag and x5chain whether or not duplicate certificates are allowed to be present. Regards, Rob