Draft: draft-ietf-cose-x509

Commentary: Separate hash draft from x509 draft Updates to x509 draft add more hash functions
The CBOR Encoded Message (COSE) structure syntax uses the COSE Key
structure for placing keys in a message.  This document extends the
way that keys can be identified and transported by providing
parameters that refer to or contain X.509 certificates in messages
and in the COSE Key structure.
This document defines a set of hash algorithms for COSE.  These
algorithms are needed in order to have X.509 certificates referred to
by a thumbprint.
The CBOR Signing And Encrypted Message (COSE) structure syntax uses
the COSE Key structure for placing keys in a message.  This document
extends the way that keys can be identified and transported by
providing attributes that refer to or contain X.509 certificates.
In the process of writing RFC8152 discussions where held on the
question of X.509 certificates RFC5280 and if there was a needed to
provide for them.  At the time there were no use cases presented that
appeared to have a sufficient set of support to include these
headers.  Since that time a number of cases where X.509 certificate
support is necessary have been defined.  This document provides a set
of headers that will allow applications to transport and refer to
X.509 certificates in a consistent manner.
In the process of writing RFC8152 discussions where held on the
question of X.509 certificates RFC5280 and if there was a needed to
provide for them.  At the time there were no use cases presented that
appeared to have a sufficient need for these attributes.  Since that
time a number of cases where X.509 certificate support is necessary
have been defined.  This document provides a set of attributes that
will allow applications to transport and refer to X.509 certificates
in a consistent manner.
When RFC8152 was written, there were no requirements for hash
algorithms to be included in the algorithm registry.  The use of
thumbprints to refer to X.509 certificates is defined in this
document which requires the use of hash algorithms.  There have also
been other working groups in the IETF that have expressed a
requirement for hash algorithms to do have sections of content be
provided by reference rather than including it in the main message.
This document defines a set of hash algorithms for both of these
purposes.
Example COSE messages for the various headers defined below can be
found at https://github.com/cose-wg/Examples.  THIS IS NOT YET DONE
BUT SHOULD BE COMING NOT LONG AFTER THE F2F MEETING.
List of other hash algorithms to be added.
Revocation info?
Ties to a COSE_Key?
This header parameters contains a bag of X.509 certificates.  The
set of certificates in this header are unordered and may contain
self-signed certificates.  The certificate bag can contain
certificates which are completely extraneous to the message.  (An
example of this would be to carry a certificate with a key
agreement key usage in a signed message.)  As the certificates are
unordered, the party evaluating the signature will need to do the
necessary path building.  Certificates needed for any particular
chain to be built may be absent from the bag.
This header attributes contains a bag of X.509 certificates.  The
set of certificates in this header are unordered and may contain
self-signed certificates.  The certificate bag can contain
certificates which are completely extraneous to the message.  (An
example of this would be to carry a certificate with a key
agreement key usage in a signed message.)  As the certificates are
unordered, the party evaluating the signature will need to do the
necessary path building.  Certificates needed for any particular
chain to be built may be absent from the bag.
This header attribute allows for a single or a bag of X.509
certificates to be carried in the message.
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 will already have it.
This header attribute 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 will already have it.
This means that the relying party is still required to do path
building, but that a candidate path is proposed in this attribute.
This header attribute allows for a single or a chain of X.509
certificates to be carried in the message.
This header parameter provides the ability to identify an X.509
certificate by a hash value.  The parameter is an array of two
elements.  The first element is an algorithm identifier which is a
signed integer or a string containing the hash algorithm
identifier.  The second element is a binary string containing the
hash value.
As this header element does not provide any trust, the header
parameter can be in either a protected or unprotected header bag.
For interoperability, applications which use this header parameter
MUST support the hash algorithm 'sha256', but can use other hash
algorithms.
This header attribute provides the ability to identify an X.509
certificate by a hash value.  The attribute is an array of two
elements.  The first element is an algorithm identifier which is
an integer or a string containing the hash algorithm identifier.
The second element is a binary string containing the hash value.
As this header element does not provide any trust, the header
attribute can be in either a protected or unprotected header
attribute.
For interoperability, applications which use this header attribute
MUST support the hash algorithm 'sha256', but can use other hash
algorithms.
As this header element implies a trust relationship, the header
parameter MUST be in the protected header bag.
The URL provided MUST provide integrity protection and server
authentication.  For example, an HTTP or CoAP GET request to
retrieve a certificate MUST use TLS RFC5246 or DTLS.  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.  This will normally be the
situation when self-signed certificates are used.
As this header attribute implies a trust relationship, the
attribute MUST be in the protected attributes.
The URL 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 the server is
configured as trusted to provide new trust anchors.  This will
normally be the situation when self-signed certificates are used.
The header parameters defined in the previous section are used to
identify the recipient certificates for the ECDH key agreement
algorithms.  In this section we define the algorithm specific
parameters that are used for identifying or transporting the senders
key for static-static key agreement algorithms.
The core COSE document did have a need for a standalone hash
algorithm, and thus did not define any.  In this document, two hash
algorithms are defined for use with the 'x5t' header parameter.
Define an algorithm identifier for SHA-256.
Certificate validation before using the key will imply that more
network traffic may be required in order to fetch certificates and
do revocation checking.
Certificate validation after using the key means that bad keys can
be used and, if not carefully checked, the result may be used
prior to completing the certificate validation.  Using unvalidated
keys can expose the device to more timing and oracle attacks as
the attacker would be able to see if the key operation succeeded
or failed as no network traffic to validate the certificate would
ensue.
IANA is requested to register the following algorithms in the "COSE
Algorithms" registry.
The header attributes defined in the previous section are used to
identify the recipient certificates for the ECDH key agreement
algorithms.  In this section we define the algorithm specific
parameters that are used for identifying or transporting the senders
key for static-static key agreement algorithms.
These attributes are defined analogously to those in the previous
section.  There is no definition for the certificate bag as the same
attribute would be used for both the sender and recipient
certificates.
This header attribute contains the chain of certificates starting
with the sender's key exchange certificate.  The structure is the
same as 'x5bag'.
This header attribute contains the hash value for the sender's key
exchange certificate.  The structure is the same as 'x5t'.
This header attribute contains a URL for the sender's key exchange
certificate.  The structure and processing are the same as 'x5u'.