Draft: draft-ietf-cose-x509

Commentary: Change versions of xml2rfc vocabulary Address some comments from Sean .
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.
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
Key structure is used for transporting keys outside of COSE messages.
This document extends the way that keys can be identified and
transported by providing attributes that refer to or contain X.509
certificates.
Should we define an extended key usage?
Are there any special certificate valiation text to be added?
Specific security considerations issues.
Revocation info?
Ties to a COSE_Key?
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 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 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 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.
COSE_Signature and COSE_Sign0 objects, in these objects they
identify the key that was used for generating signature.
COSE_recipient objects, in this location they may be used to
identify the certificate for the recipient of the message.
Below is an equivalent CDDL I-D.ietf-cbor-cddl description of the
text above.
Below is an equivalent CDDL RFC8610 description of the text above.
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'.
Establishing trust in a certificate is a vital part of processing.
Trust cannot be assumed whenever a new self-signed certificate
appears on the client, instead a well defined process is required.
One common way for a new trust anchor to be added (or removed) from a
device is by doing a new firmware upgrade.
In constrained systems, there is a trade-off between the order of
checking the signature and checking the certificate for validity.
Validating certificates can require that network resources be
accessed in order to get revocation information or retrieve
certificates during path building.  Doing the network access can
consume resources dealing with power and network bandwidth.  On the
other hand, an oracle can potentially be built based on if the
network resources are only accessed if the signature validation
passes.  In any event, both the signature and certificate validation
MUST be checked before acting on any requests.
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at TBD.  Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the COSE mailing list.
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
cose-wg/X509> Editorial changes can be managed in GitHub, but any
substantial issues need to be discussed on the COSE mailing list.
The CBOR Object Signing and Encryption (COSE) syntax does not define
any direct methods for the use of hash algorithms.  It also does not
define a structure syntax that is used to encode a digested object
structure along the lines of the DigestedData ASN.1 structure in
RFC5652.  This omission was intentional as a structure consisting of
jut a digest identifier, the content, and a digest value does not by
itself provide any strong security service.  Additional, an
application is going to be better off defining this type of structure
so that it can add any additional data that needs to be hashed as
well as methods of obtaining the data.
The CBOR Object Signing and Encryption (COSE) syntax does not define
any direct methods for the use of hash algorithms.  It also does not
define a structure syntax that is used to encode a digested object
structure along the lines of the DigestedData ASN.1 structure in
RFC5652.  This omission was intentional as a structure consisting of
just a digest identifier, the content, and a digest value does not by
itself provide any strong security service.  Additionally, an
application is going to be better off defining this type of structure
so that it can include add any additional data that needs to be
hashed, as well as methods of obtaining the data.
The SHA-1 hash algorithm RFC3174 wsa designed by the United States
National Security Agenciy and published in 1995.  Since that time a
large amount of cryptographic analysis has been applied to this
algorithm and a successful collision attack has been created (SHA-
1-collision).  The IETF formally started discouraging the use of
SHA-1 with the publishing of RFC6194.
Dispite the above, there are still times where SHA-1 needs to be used
and therefore it makes sense to assign a point for the use of this
hash algorithm.  Some of these situations are with historic HSMs
where only SHA-1 is implemented or where the SHA-1 value is used for
the purpose of filtering and thus the collision resistance property
is not needed.
RFC Editor: Please remove this section before publishing.
As noted in the previous section, hash functions can be used for a
variety of purposes.  Some of these purposes require that a hash
function be cryptographically strong, these include direct and
indirect signatures.  That is, using the hash as part of the
signature or using the hash as part of the body to be signed.  Other
uses of hash functions do not require the same level of strength.
This document contains some hash functions that are not designed to
be used for cryptographic operations.  An application that is using a
hash function needs to carefully evaluate exactly what hash
properties are needed and which hash functions are going to provide
them.  Applications should also make sure that the ability to change
hash functions is part of the base design as cryptographic advances
are sure to reduce strength of a hash function.
A hash function is a map from a large bit string to a smaller bit
string.  There are going to be collisions by a hash function, the
trick is to make sure that it is difficult to find two values that
are going to map to the same output value.  The standard "Collision
Attack" is one where an attacker can find two different messages that
have the same hash value.  If a collision attack exists, then the
function SHOULD NOT be used for a cryptographic purpose.  The only
reason why such a hash function is used is when there is absolutely
no other choice (e.g. a HSM that cannot be replaced), and only after
looking at the possible security issues.  Cryptographic purposes
would include creation of signatures or the use of hashes for
indirect signatures.  These functions may still be usable for non-
cryptographic purposes.
An example of a non-cryptographic use of a hash is for filtering from
a collection of values to find possible candidates that can later be
checked to see if they are the correct one.  A simple example of this
is the classic thumbprint of a certificate.  If the thumbprint is
used to verify that it is the correct certificate, then that usage is
subject to a collision attack as above.  If however, the thumbprint
is used to sort through a collection of certificates to find those
that might be used for the purpose of verifying a signature, a simple
filter capability is sufficient.  In this case, one still needs to
validate that the public key validates the signature (and the
certificate is trusted), and all certificates that don't contain a
key that validates the signature can be discarded as false positives.
To distinguish between these two cases, a new value in the
recommended column of the COSE Algorithms registry is to be added.
"Filter Only" indicates that the only purpose of a hash function
should be to filter results and not those which require collision
resistance.
An example of a structure which permits all of the above fields to
exist would look like the following.  There is no definition here of
what goes into the 'any' value and how it would be included in the
computed hash value.
The SHA-1 hash algorithm RFC3174 was designed by the United States
National Security Agency and published in 1995.  Since that time a
large amount of cryptographic analysis has been applied to this
algorithm and a successful collision attack has been created (SHA-
1-collision).  The IETF formally started discouraging the use of
SHA-1 with the publishing of RFC6194.
Despite the above, there are still times where SHA-1 needs to be used
and therefore it makes sense to assign a point for the use of this
hash algorithm.  Some of these situations are with historic HSMs
where only SHA-1 is implemented or where the SHA-1 value is used for
the purpose of filtering and thus the collision resistance property
is not needed.
Because of the known issues for SHA-1 and the fact that is should no
longer be used, the algorithm will be registered with the
recommendation of "Depreciated".
Because of the known issues for SHA-1 and the fact that is should no
longer be used, the algorithm will be registered with the
recommendation of "Filter Only".
The SHA-3 hash algorithms have a significantly different structure
than the SHA-3 hash algorithms.  One of the benefits of this
differences is that when computing a truncated SHAKE hash value, the
value is not a prefix of a longer version of the same value.
MAYBE TEXT: Might not need to define truncated versions of this hash
algorithm because the length of the resulting value is always going
to generate a unique value since you cannot just truncate it like you
can with SHA-1 and SHA-2.
The SHA-3 hash algorithms have a significantly different structure
than the SHA-2 hash algorithms.  One of the benefits of this
differences is that when computing a shorter SHAKE hash value, the
value is not a prefix of the result of computing the longer hash.
Unlike the SHA-2 hash functions, no algorithm identifier is created
for shorter lengths.  Applications can specify what the minimum
length for a hash function for the protocol.  A validator can infer
the actual length from the hash value in these cases.
In addition, IANA is to add the value of 'Filter Only' to the set of
legal values for the 'Recommended' column.  This value is only to be
used for hash functions and indicates that it is not to be used for
purposes which require collision resistance.