I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document extends COSE (RFC 8152) by specifying a syntax for the inclusion of X.509 certificates. The only thing the security community might find vaguely controversial is the mandate (on page 5) for support of the SHA-256 hash algorithm "for interoperability" (along optionally with other hash algorithms). The document correctly notes that what is specified does not guarantee interoperability. Minor suggestions: Page 3: "If the application cannot establish trust in the certificate, that certificate cannot be used." I would say ...cannot be used to establish trust in the key. An untrusted certificate might still be used for other purposes, like forwarding it to some other entity that might be able to establish trust in it. It also might be worth noting (here or under security considerations) that certificates only establish trustworthiness of a key to the extent that the entity named in the certificate is trusted. Page 4: (This language appears under both x5bag and x5chain): "The presence of a self-signed certificate in the parameter MUST NOT be used as a signal to modify the set of trust anchors." I would say "...MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation." This requirement should also apply to certificates that are not self-signed. Page 6: "As this header parameter implies a trust relationship, the attribute MUST be in the protected attribute bucket." This seems inconsistent with the other categories. Why does this form of specification imply a trust relationship which the other three do not? Page 6: "The URI provided MUST provide integrity protection and server authentication." This makes sense if the certificate is to some degree trusted by virtue of where it came from, but it's not obvious why it is necessary otherwise. Page 6: "If the certificate does not chain to an existing trust anchor, the certificate MUST NOT be trusted unless 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." These two sentences appear inconsistent. Are self-signed certificates to be trusted if they come from a server configured as trusted to provide new trust anchors? Note that most trust anchors are self-signed. Page 6: You might want x5u or perhaps some new attribute to be able to reference a bag or chain of certificates by URL. Page 8: "A new self-signed certificate appearing on the client cannot be a trigger to modify the set of trust anchors, because a well defined trust-establishment process is required." I agree with the intent, but this statement may be too strong. Page 6 implies that a server may be configured as a source of trust anchors, in which case I assume you intend that a certificate appearing on the client because it was downloaded from such a server should modify the set of trust anchors. Also, while adding a new trust anchor must require a well defined trust-establishment process likely involving some administrative approval, there is nothing wrong with that process being "triggered" by the appearance of a new self-signed certificate. Page 8: "The use of unvalidated keys can lead either to loss of security or excessive consumption of resources (for example using a 200K RSA key)." Great catch!! I wish more specs included that reminder! Typos: Page 2: "ad" -> "and" page 2: "wher prestented" -> "were presented" page 3: "process of X.509" -> "process X.509" page 3: "configured use" -> "configured to use" page 5: "remove the following paragraphs" -> "remove the following two paragraphs" --Charlie Sent from Outlook