Last Call Review of draft-ietf-cose-x509-07
review-ietf-cose-x509-07-secdir-lc-kaufman-2020-10-01-00

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<http://aka.ms/weboutlook>