Draft: draft-schaad-cose-x509

Commentary: Add text to deal w/ static - static DH
This document defines the headers and usage for referring to and
transporting X.509 certificates in the CBOR Encoded Message (COSE)
Syntax.
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.
In the process of writing RFCXXXX I-D.ietf-cose-msg discussions where
held on the question of X.509 certificates RFC5280 and if there were
needed.  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 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.
Some of the constrainted device situations are being used where an
X.509 PKI is already installed.  One of these situations is the 6tish
environment for enrollment of devices where the certificates are
installed at the factory.  The I-D.selander-ace-cose-ecdhe draft was
also written with the idea that long term certificates could be used
to provide for authentication of devices and uses them to establish
session keys.  A final scenario is the use of COSE as a messaging
application where long term existence of keys can be used along with
a central authentication authority.  The use of certificates in this
scenario allows for key managment to be used which is well
understood.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC2119.
When the words appear in lower case, their natural language meaning
is used.
Some of the constrained device situations are being used where an
X.509 PKI is already installed.  One of these situations is the 6tish
environment for enrollment of devices where the certificates are
installed at the factory.  The I-D.selander-ace-cose-ecdhe draft was
also written with the idea that long term certificates could be used
to provide for authentication of devices and uses them to establish
session keys.  A final scenario is the use of COSE as a messaging
application where long term existence of keys can be used along with
a central authentication authority.  The use of certificates in this
scenario allows for key management to be used which is well
understood.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
The use of X.509 certificates allows for an existing trust
infrastructure to be used with COSE.  This includes the full suite of
enrollment protocols, trust anchors, trust chaining and revocation
checking that have been defined over time by the IETF and other
organizations.  The key structures that have been defined in COSE
currently do not support all of these properties although some may be
found in COSE Web Tokens (CWT) I-D.ietf-ace-cbor-web-token.
It is not necessarily expected that constrainted devices will fully
support the evalaluation and processing of X.509 certificates, it is
perfectly reasonable for a certificate to be assigned to a device
which it can then provide to a relying party along with a signature
or encrypted message, the relying party not being a constrained
device.
The use of X.509 certificates allows for an existing trust
infrastructure to be used with COSE.  This includes the full suite of
enrollment protocols, trust anchors, trust chaining and revocation
checking that have been defined over time by the IETF and other
organizations.  The key structures that have been defined in COSE
currently do not support all of these properties although some may be
found in COSE Web Tokens (CWT) RFC8392.
It is not necessarily expected that constrained devices will fully
support the evaluation and processing of X.509 certificates, it is
perfectly reasonable for a certificate to be assigned to a device
which it can then provide to a relying party along with a signature
or encrypted message, the relying party not being a constrained
device.
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.  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 identity of the server MUST be configured as
trusted to provide new trust anchors.  This will normally be the
situation when self-signed certificates are used.
COSE_recipient object, in this object they identify the key used
by the sender for static-static key agreement algorithms.  They
would be used in place either XXXX or YYYY.
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.
COSE_recipient objects, in this location they may be used to
identify the certificate for the recipient of the message.
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.