draft-ietf-cose-cbor-encoded-cert-00.txt   draft-ietf-cose-cbor-encoded-cert-01.txt 
Network Working Group S. Raza Network Working Group S. Raza
Internet-Draft J. Hoeglund Internet-Draft J. Hoeglund
Intended status: Standards Track RISE AB Intended status: Standards Track RISE AB
Expires: October 30, 2021 G. Selander Expires: November 26, 2021 G. Selander
J. Mattsson J. Preuss Mattsson
Ericsson AB Ericsson AB
M. Furuhed M. Furuhed
Nexus Group Nexus Group
April 28, 2021 May 25, 2021
CBOR Encoded X.509 Certificates (C509 Certificates) CBOR Encoded X.509 Certificates (C509 Certificates)
draft-ietf-cose-cbor-encoded-cert-00 draft-ietf-cose-cbor-encoded-cert-01
Abstract Abstract
This document specifies a CBOR encoding of X.509 certificates. The This document specifies a CBOR encoding of X.509 certificates. The
resulting certificates are called C509 Certificates. The CBOR resulting certificates are called C509 Certificates. The CBOR
encoding supports a large subset of RFC 5280 and significantly encoding supports a large subset of RFC 5280 and all certificates
reduces the size of certificates compatible with e.g. RFC 7925, IEEE compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, and CA/
802.1AR (DevID), CNSA, and CA/Browser Forum Baseline Requirements. Browser Forum Baseline Requirements profiles. When used to re-encode
When used to re-encode DER encoded X.509 certificates, the CBOR DER encoded X.509 certificates, the CBOR encoding can in many cases
encoding can in many cases reduce the size of RFC 7925 profiled reduce the size of RFC 7925 profiled certificates with over 50%. The
certificates with over 50%. The CBOR encoded structure can CBOR encoded structure can alternatively be signed directly
alternatively be signed directly ("natively signed"), which does not ("natively signed"), which does not require re-encoding for the
require re-encoding for the signature to be verified. The document signature to be verified. The document also specifies COSE headers
also specifies COSE headers as well as a TLS certificate type for as well as a TLS certificate type for C509 certificates.
C509 certificates.
NOTE: "C509" is a placeholder, name to be decided by the COSE WG.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2021. This Internet-Draft will expire on November 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5
3.2. Encoding of subjectPublicKey and issuerSingatureValue . . 8 3.2. Encoding of subjectPublicKey and issuerSingatureValue . . 8
3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9 3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9
4. Compliance Requirements for Constrained IoT . . . . . . . . . 11 4. Compliance Requirements for Constrained IoT . . . . . . . . . 12
5. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 12
6. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 12 6. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. C509 Certificate Types Registry . . . . . . . . . . . . . 13 8.1. C509 Certificate Types Registry . . . . . . . . . . . . . 14
8.2. C509 Certificate Attributes Registry . . . . . . . . . . 13 8.2. C509 Certificate Attributes Registry . . . . . . . . . . 15
8.3. C509 Certificate Extensions Registry . . . . . . . . . . 16 8.3. C509 Certificate Extensions Registry . . . . . . . . . . 17
8.4. C509 Certificate Extended Key Usages Registry . . . . . . 18 8.4. C509 Certificate Certificate Policies Registry . . . . . 19
8.5. C509 Certificate General Names Registry . . . . . . . . . 19 8.5. C509 Certificate Extended Key Usages Registry . . . . . . 20
8.6. C509 Certificate Signature Algorithms Registry . . . . . 20 8.6. C509 Certificate General Names Registry . . . . . . . . . 21
8.7. C509 Certificate Public Key Algorithms Registry . . . . . 23 8.7. C509 Certificate Signature Algorithms Registry . . . . . 22
8.8. COSE Header Parameters Registry . . . . . . . . . . . . . 25 8.8. C509 Certificate Public Key Algorithms Registry . . . . . 25
8.9. TLS Certificate Types Registry . . . . . . . . . . . . . 26 8.9. COSE Header Parameters Registry . . . . . . . . . . . . . 27
8.10. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 27 8.10. TLS Certificate Types Registry . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.11. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Example C509 Certificates . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 30
A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 30 Appendix A. Example C509 Certificates . . . . . . . . . . . . . 32
A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 34 A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 32
A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 34 A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 36
A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 36 A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
One of the challenges with deploying a Public Key Infrastructure One of the challenges with deploying a Public Key Infrastructure
(PKI) for the Internet of Things (IoT) is the size and parsing of (PKI) for the Internet of Things (IoT) is the size and parsing of
X.509 public key certificates [RFC5280], since those are not X.509 public key certificates [RFC5280], since those are not
optimized for constrained environments [RFC7228]. Large certificate optimized for constrained environments [RFC7228]. Large certificate
chains are also problematic in non-constrained protocols such as EAP- chains are also problematic in non-constrained protocols such as EAP-
TLS [I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eaptlscert] where TLS [I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eaptlscert] where
authenticators typically drop an EAP session after only 40 - 50 authenticators typically drop an EAP session after only 40 - 50
round-trips and QUIC [I-D.ietf-quic-transport] where the latency round-trips and QUIC [I-D.ietf-quic-transport] where the latency
increases significantly unless the server only send less than three increases significantly unless the server sends less than three times
times as many bytes as received prior to validating the client as many bytes as received prior to validating the client address.
address. More compact certificate representations are therefore More compact certificate representations are therefore desirable in
desirable in many use cases. Due to the current PKI usage of DER many use cases. Due to the current PKI usage of DER encoded X.509
encoded X.509 certificates, keeping compatibility with DER encoded certificates, keeping compatibility with DER encoded X.509 is
X.509 is necessary at least for a transition period. However, the necessary at least for a transition period. However, the use of a
use of a more compact encoding with the Concise Binary Object more compact encoding with the Concise Binary Object Representation
Representation (CBOR) [RFC8949] reduces the certificate size (CBOR) [RFC8949] reduces the certificate size significantly which has
significantly which has known performance benefits in terms of known performance benefits in terms of decreased communication
decreased communication overhead, power consumption, latency, overhead, power consumption, latency, storage, etc.
storage, etc.
CBOR is a data format designed for small code size and small message CBOR is a data format designed for small code size and small message
size. CBOR builds on the JSON data model but extends it by e.g. size. CBOR builds on the JSON data model but extends it by e.g.
encoding binary data directly without base64 conversion. In addition encoding binary data directly without base64 conversion. In addition
to the binary CBOR encoding, CBOR also has a diagnostic notation that to the binary CBOR encoding, CBOR also has a diagnostic notation that
is readable and editable by humans. The Concise Data Definition is readable and editable by humans. The Concise Data Definition
Language (CDDL) [RFC8610] provides a way to express structures for Language (CDDL) [RFC8610] provides a way to express structures for
protocol messages and APIs that use CBOR. [RFC8610] also extends the protocol messages and APIs that use CBOR. [RFC8610] also extends the
diagnostic notation. diagnostic notation.
CBOR data items are encoded to or decoded from byte strings using a CBOR data items are encoded to or decoded from byte strings using a
type-length-value encoding scheme, where the three highest order bits type-length-value encoding scheme, where the three highest order bits
of the initial byte contain information about the major type. CBOR of the initial byte contain information about the major type. CBOR
supports several different types of data items, in addition to supports several different types of data items, in addition to
integers (int, uint), simple values (e.g. null), byte strings (bstr), integers (int, uint), simple values (e.g. null), byte strings (bstr),
and text strings (tstr), CBOR also supports arrays [] of data items, and text strings (tstr), CBOR also supports arrays [] of data items,
maps {} of pairs of data items, and sequences of data items. For a maps {} of pairs of data items, and sequences of data items. For a
complete specification and examples, see [RFC8949], [RFC8610], and complete specification and examples, see [RFC8949], [RFC8610], and
[RFC8742]. [RFC8742]. We recommend implementors to get used to CBOR by using
the CBOR playground [CborMe].
CAB Baseline Requirements [CAB-Baseline], RFC 7925 [RFC7925], IEEE CAB Baseline Requirements [CAB-Baseline], RFC 7925 [RFC7925], IEEE
802.1AR [IEEE-802.1AR], and CNSA [RFC8603] specify certificate 802.1AR [IEEE-802.1AR], and CNSA [RFC8603] specify certificate
profiles which can be applied to certificate based authentication profiles which can be applied to certificate based authentication
with, e.g., TLS [RFC8446], QUIC [I-D.ietf-quic-transport], DTLS with, e.g., TLS [RFC8446], QUIC [I-D.ietf-quic-transport], DTLS
[I-D.ietf-tls-dtls13], COSE [RFC8152], EDHOC [I-D.ietf-lake-edhoc], [I-D.ietf-tls-dtls13], COSE [RFC8152], EDHOC [I-D.ietf-lake-edhoc],
or Compact TLS 1.3 [I-D.ietf-tls-ctls]. RFC 7925 [RFC7925], or Compact TLS 1.3 [I-D.ietf-tls-ctls]. RFC 7925 [RFC7925],
RFC7925bis [I-D.ietf-uta-tls13-iot-profile], and IEEE 802.1AR RFC7925bis [I-D.ietf-uta-tls13-iot-profile], and IEEE 802.1AR
[IEEE-802.1AR] specifically target Internet of Things deployments. [IEEE-802.1AR] specifically target Internet of Things deployments.
This document specifies a CBOR encoding based on [X.509-IoT], which This document specifies a CBOR encoding based on [X.509-IoT], which
can support large parts of [RFC5280]. The encoding support all can support large parts of [RFC5280]. The encoding support all
[RFC7925] and IEEE 802.1AR [IEEE-802.1AR] and CAB Baseline [RFC7925] and IEEE 802.1AR [IEEE-802.1AR] and CAB Baseline
[CAB-Baseline] profiled X.509 certificates. The resulting [CAB-Baseline] profiled X.509 certificates. The resulting
certificates are called C509 Certificates. Two variants are defined certificates are called C509 Certificates. Two variants are defined
using the same CBOR encoding and differing only in what is being using the same CBOR encoding and differing only in what is being
signed: signed:
1. An invertible CBOR re-encoding of DER encoded X.509 certificates 1. An invertible CBOR re-encoding of DER encoded X.509 certificates
skipping to change at page 4, line 31 skipping to change at page 4, line 32
parsing and the associated complexity but they are not backwards parsing and the associated complexity but they are not backwards
compatible with implementations requiring DER encoded X.509. compatible with implementations requiring DER encoded X.509.
Natively signed C509 certificates can be applied in devices that are Natively signed C509 certificates can be applied in devices that are
only required to authenticate to natively signed C509 certificate only required to authenticate to natively signed C509 certificate
compatible servers, which is not a major restriction for many IoT compatible servers, which is not a major restriction for many IoT
deployments where the parties issuing and verifying certificates can deployments where the parties issuing and verifying certificates can
be a restricted ecosystem. be a restricted ecosystem.
This document specifies COSE headers for use of the C509 certificates This document specifies COSE headers for use of the C509 certificates
with COSE, see Section 8.8. The document also specifies a TLS with COSE, see Section 8.9. The document also specifies a TLS
certificate type for use of the C509 certificates with TLS and QUIC certificate type for use of the C509 certificates with TLS and QUIC
(with or without additional TLS certificate compression), see (with or without additional TLS certificate compression), see
Section 8.9. Section 8.10.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification makes use of the terminology in [RFC5280], This specification makes use of the terminology in [RFC5280],
skipping to change at page 5, line 15 skipping to change at page 5, line 15
3. CBOR Encoding 3. CBOR Encoding
This section specifies the content and encoding for C509 This section specifies the content and encoding for C509
certificates, with the overall objective to produce a very compact certificates, with the overall objective to produce a very compact
representation supporting large parts of [RFC5280], and everything in representation supporting large parts of [RFC5280], and everything in
[RFC7925], [IEEE-802.1AR], and CAB Baseline [CAB-Baseline]. In the [RFC7925], [IEEE-802.1AR], and CAB Baseline [CAB-Baseline]. In the
CBOR encoding, static fields are elided, elliptic curve points and CBOR encoding, static fields are elided, elliptic curve points and
time values are compressed, OID are replaced with short integers, and time values are compressed, OID are replaced with short integers, and
redundant encoding is removed. Combining these different components redundant encoding is removed. Combining these different components
reduces the certificate size significantly, which is not possible reduces the certificate size significantly, which is not possible
with general purpose compression algorithms, see Figure 2. with general purpose compression algorithms, see Figure 3.
The C509 certificate can be either a CBOR re-encoding of a DER The C509 certificate can be either a CBOR re-encoding of a DER
encoded X.509 certificate, in which case the signature is calculated encoded X.509 certificate, in which case the signature is calculated
on the DER encoded ASN.1 data in the X.509 certificate, or a natively on the DER encoded ASN.1 data in the X.509 certificate, or a natively
signed C509 certificate, in which case the signature is calculated signed C509 certificate, in which case the signature is calculated
directly on the CBOR encoded data. In both cases the certificate directly on the CBOR encoded data. In both cases the certificate
content is adhering to the restrictions given by [RFC5280]. The re- content is adhering to the restrictions given by [RFC5280]. The re-
encoding is known to work with DER encoded certificates but might encoding is known to work with DER encoded certificates but might
work with other canonical encodings. The re-encoding does not work work with other canonical encodings. The re-encoding does not work
for BER encoded certificates. for BER encoded certificates.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
3.1. Message Fields 3.1. Message Fields
The X.509 fields and their CBOR encodings are listed below, and used The X.509 fields and their CBOR encodings are listed below, and used
in the definition of C509 certificates, see Figure 1. in the definition of C509 certificates, see Figure 1.
C509 certificates are defined in terms of DER encoded [RFC5280] X.509 C509 certificates are defined in terms of DER encoded [RFC5280] X.509
certificates: certificates:
o version. The 'version' field is encoded in the o version. The 'version' field is encoded in the
'cborCertificateType' CBOR int. The field 'cborCertificateType' 'c509CertificateType' CBOR int. The field 'c509CertificateType'
also indicates the type of the C509 certificate. Currently, the also indicates the type of the C509 certificate. Currently, the
type can be a natively signed C509 certificate following X.509 v3 type can be a natively signed C509 certificate following X.509 v3
(cborCertificateType = 0) or a CBOR re-encoded X.509 v3 DER (c509CertificateType = 0) or a CBOR re-encoded X.509 v3 DER
certificate (cborCertificateType = 1), see Section 8.1. certificate (c509CertificateType = 1), see Section 8.1.
o serialNumber. The 'serialNumber' INTEGER value field is encoded o serialNumber. The 'serialNumber' INTEGER value field is encoded
as the unwrapped CBOR unsigned bignum (~biguint) as the unwrapped CBOR unsigned bignum (~biguint)
'certificateSerialNumber'. Any leading 0x00 byte (to indicate 'certificateSerialNumber'. Any leading 0x00 byte (to indicate
that the number is not negative) is therefore omitted. that the number is not negative) is therefore omitted.
o signature. The 'signature' field is always the same as the o signature. The 'signature' field is always the same as the
'signatureAlgorithm' field and therefore omitted from the CBOR 'signatureAlgorithm' field and therefore omitted from the CBOR
encoding. encoding.
o issuer. In the general case, the sequence of o issuer. In the general case, the sequence of
'RelativeDistinguishedName' is encoded as a CBOR array of CBOR 'RelativeDistinguishedName' is encoded as a CBOR array of CBOR
arrays of Attributes. Typically each RelativeDistinguishedName arrays of Attributes. Typically each RelativeDistinguishedName
only contains a single attribute and the sequence is then encoded only contains a single attribute and the sequence is then encoded
as a CBOR array of Attributes. Each Attribute is encoded as a as a CBOR array of Attributes. Each Attribute is encoded as a
(CBOR int, CBOR text string) pair or as a (unwrapped CBOR OID, (CBOR int, CBOR text string) pair or as a (unwrapped CBOR OID,
CBOR bytes) pair. The absolute value of the CBOR int (see CBOR bytes) pair. The absolute value of the CBOR int (see
Figure 4) encodes the attribute type and the sign is used to Figure 5) encodes the attribute type and the sign is used to
represent the character string type; positive for Utf8String, represent the character string type; positive for Utf8String,
negative for PrintableString. In natively signed C509 negative for PrintableString. In natively signed C509
certificates all text strings are UTF-8 encoded and all attributes certificates all text strings are UTF-8 encoded and all attributes
SHALL have a positive sign. Text strings SHALL still adhere to SHALL have a positive sign. Text strings SHALL still adhere to
any X.509 restrictions, i.e. serialNumber SHALL only contain the any X.509 restrictions, i.e. serialNumber SHALL only contain the
74 character subset of ASCII allowed by PrintableString and 74 character subset of ASCII allowed by PrintableString and
countryName SHALL have length 2. The string types teletexString, countryName SHALL have length 2. The string types teletexString,
universalString, and bmpString are not supported. If Name universalString, and bmpString are not supported. If Name
contains a single Attribute containing an utf8String encoded contains a single Attribute containing an utf8String encoded
'common name' it is encoded as a CBOR text string. If the text 'common name' it is encoded as a CBOR text string. If the text
skipping to change at page 6, line 47 skipping to change at page 6, line 47
it. Compression of X.509 certificates with the time 23:59:60 UTC it. Compression of X.509 certificates with the time 23:59:60 UTC
is therefore not supported. Note that RFC 5280 mandates encoding is therefore not supported. Note that RFC 5280 mandates encoding
of dates through the year 2049 as UTCTime, and later dates as of dates through the year 2049 as UTCTime, and later dates as
GeneralizedTime. The value "99991231235959Z" (no expiration date) GeneralizedTime. The value "99991231235959Z" (no expiration date)
is encoded as CBOR null. is encoded as CBOR null.
o subject. The 'subject' is encoded exactly like issuer. o subject. The 'subject' is encoded exactly like issuer.
o subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including o subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including
parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm' parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm'
(see Section 8.7) or as an array with an unwrapped CBOR OID tag (see Section 8.8) or as an array with an unwrapped CBOR OID tag
[I-D.ietf-cbor-tags-oid] optionally followed by the parameters [I-D.ietf-cbor-tags-oid] optionally followed by the parameters
encoded as a CBOR byte string. In general, the 'subjectPublicKey' encoded as a CBOR byte string. In general, the 'subjectPublicKey'
BIT STRING value field is encoded as a CBOR byte string. This BIT STRING value field is encoded as a CBOR byte string. This
specification assumes the BIT STRING has zero unused bits and the specification assumes the BIT STRING has zero unused bits and the
unused bits byte is omitted. For rsaEncryption and id- unused bits byte is omitted. For rsaEncryption and id-
ecPublicKey, the encoding of subjectPublicKey is further optimized ecPublicKey, the encoding of subjectPublicKey is further optimized
as described in Section 3.2. as described in Section 3.2.
o issuerUniqueID. Not supported. o issuerUniqueID. Not supported.
skipping to change at page 7, line 26 skipping to change at page 7, line 26
'extnValue' encoded as a CBOR byte string. If the array contains 'extnValue' encoded as a CBOR byte string. If the array contains
exactly two ints and the absolute value of the first int is 2, the exactly two ints and the absolute value of the first int is 2, the
array is omitted and the extensions is encoded as a single CBOR array is omitted and the extensions is encoded as a single CBOR
int with the absolute value of the second int and the sign of the int with the absolute value of the second int and the sign of the
first int. Extensions are encoded as specified in Section 3.3. first int. Extensions are encoded as specified in Section 3.3.
The extensions mandated to be supported by [RFC7925] and The extensions mandated to be supported by [RFC7925] and
[IEEE-802.1AR] are given special treatment. An omitted [IEEE-802.1AR] are given special treatment. An omitted
'extensions' field is encoded as an empty CBOR array. 'extensions' field is encoded as an empty CBOR array.
o signatureAlgorithm. The 'signatureAlgorithm' field including o signatureAlgorithm. The 'signatureAlgorithm' field including
parameters is encoded as a CBOR int (see Section 8.6) or as an parameters is encoded as a CBOR int (see Section 8.7) or as an
array with an unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid] array with an unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid]
optionally followed by the parameters encoded as a CBOR byte optionally followed by the parameters encoded as a CBOR byte
string. string.
o signatureValue. In general, the 'signatureValue' BIT STRING value o signatureValue. In general, the 'signatureValue' BIT STRING value
field is encoded as the CBOR byte string issuerSignatureValue. field is encoded as the CBOR byte string issuerSignatureValue.
This specification assumes the BIT STRING has zero unused bits and This specification assumes the BIT STRING has zero unused bits and
the unused bits byte is omitted. For natively signed C509 the unused bits byte is omitted. For natively signed C509
certificates the signatureValue is calculated over the CBOR certificates the signatureValue is calculated over the CBOR
sequence TBSCertificate. For ECDSA, the encoding of sequence TBSCertificate. For ECDSA, the encoding of
issuerSignatureValue is further optimized as described in issuerSignatureValue is further optimized as described in
Section 3.2 Section 3.2
The following Concise Data Definition Language (CDDL) defines The following Concise Data Definition Language (CDDL) defines the
CBORCertificate and TBSCertificate, which are encoded as CBOR CBOR array C509Certificate and the CBOR sequence [RFC8742]
Sequences [RFC8742]. The member names therefore only have TBSCertificate. The member names therefore only have documentary
documentary value. value. Applications not requiring a CBOR item MAY represent C509
certificates with the CBOR sequence ~C509Certificate (unwrapped
C509Certificate).
; The elements of the following group are to be used in a CBOR Sequence: C509Certificate = [
CBORCertificate = (
TBSCertificate, TBSCertificate,
issuerSignatureValue : any, issuerSignatureValue : any,
) ]
; The elements of the following group are to be used in a CBOR Sequence:
TBSCertificate = ( TBSCertificate = (
cborCertificateType: int, c509CertificateType: int,
certificateSerialNumber: CertificateSerialNumber, certificateSerialNumber: CertificateSerialNumber,
issuer: Name, issuer: Name,
validityNotBefore: Time, validityNotBefore: Time,
validityNotAfter: Time, validityNotAfter: Time,
subject: Name, subject: Name,
subjectPublicKeyAlgorithm: AlgorithmIdentifier, subjectPublicKeyAlgorithm: AlgorithmIdentifier,
subjectPublicKey: any, subjectPublicKey: any,
extensions: Extensions, extensions: Extensions,
issuerSignatureAlgorithm: AlgorithmIdentifier, issuerSignatureAlgorithm: AlgorithmIdentifier,
) )
skipping to change at page 8, line 35 skipping to change at page 8, line 35
Name = [ * RelativeDistinguishedName ] / text / bytes Name = [ * RelativeDistinguishedName ] / text / bytes
RelativeDistinguishedName = Attribute / [ 2* Attribute ] RelativeDistinguishedName = Attribute / [ 2* Attribute ]
Attribute = ( attributeType: int, attributeValue: text ) // Attribute = ( attributeType: int, attributeValue: text ) //
( attributeType: ~oid, attributeValue: bytes ) ( attributeType: ~oid, attributeValue: bytes )
Time = ~time / null Time = ~time / null
AlgorithmIdentifier = int / [ algorithm: ~oid, ? parameters: bytes ] AlgorithmIdentifier = int / ~oid / [ algorithm: ~oid, parameters: bytes ]
Extensions = [ * Extension ] / int Extensions = [ * Extension ] / int
Extension = ( extensionID: int, extensionValue: any ) // Extension = ( extensionID: int, extensionValue: any ) //
( extensionID: ~oid, critical: bool, extensionValue: bytes ) ( extensionID: ~oid, ? critical: true, extensionValue: bytes )
)
Figure 1: CDDL for CBORCertificate. Figure 1: CDDL for C509Certificate.
3.2. Encoding of subjectPublicKey and issuerSingatureValue 3.2. Encoding of subjectPublicKey and issuerSingatureValue
3.2.1. Encoding of subjectPublicKey 3.2.1. Encoding of subjectPublicKey
For RSA public keys (rsaEncryption), the SEQUENCE and INTEGER type For RSA public keys (rsaEncryption), the SEQUENCE and INTEGER type
and length fields are omitted and the two INTEGER value fields and length fields are omitted and the two INTEGER value fields
(modulus, exponent) are encoded as an array of two unwrapped CBOR (modulus, exponent) are encoded as an array of two unwrapped CBOR
unsigned bignum (~biguint), i.e. [ modulus : ~biguint, exponent : unsigned bignum (~biguint), i.e. [ modulus : ~biguint, exponent :
~biguint ]. If the exponent is 65537, the array and the exponent is ~biguint ]. If the exponent is 65537, the array and the exponent is
omitted and subjectPublicKey consist of only the modulus encoded as omitted and subjectPublicKey consist of only the modulus encoded as
an unwrapped CBOR unsigned bignum (~biguint). an unwrapped CBOR unsigned bignum (~biguint).
For elliptic curve public keys in Weierstrass form (id-ecPublicKey), For elliptic curve public keys in Weierstrass form (id-ecPublicKey),
uncompressed keys are point compressed as defined in Section 2.3.3 of uncompressed keys are point compressed as defined in Section 2.3.3 of
[SECG]. If a DER encoded certificate with a point compressed public [SECG]. If a DER encoded certificate with a point compressed public
key of type id-ecPublicKey is CBOR encoded, the octets 0xfe and 0xfd key of type id-ecPublicKey is CBOR encoded, the octets 0xfe and 0xfd
are used instead of 0x02 and 0x03 in the CBOR encoding to represent are used instead of 0x02 and 0x03 in the CBOR encoding to represent
even and odd y-coordinate, respectively. even and odd y-coordinate, respectively.
skipping to change at page 9, line 29 skipping to change at page 9, line 27
as well as the any leading 0x00 byte (to indicate that the number is as well as the any leading 0x00 byte (to indicate that the number is
not negative) are omitted. If the two INTEGER value fields have not negative) are omitted. If the two INTEGER value fields have
different lengths, the shortest INTEGER value field is padded with different lengths, the shortest INTEGER value field is padded with
zeroes so that the two fields have the same length. The resulting zeroes so that the two fields have the same length. The resulting
byte string is encoded as a CBOR byte string. byte string is encoded as a CBOR byte string.
3.3. Encoding of Extensions 3.3. Encoding of Extensions
This section details the encoding of the 'extensions' field. The This section details the encoding of the 'extensions' field. The
'extensions' field is encoded as a CBOR array where each extensionID 'extensions' field is encoded as a CBOR array where each extensionID
is encoded as either a CBOR int or a CBOR OID tag. If 'extensionID' is encoded as either a CBOR int or an unwrapped CBOR OID tag. If
is encoded an int (see Section 8.3),the sign is used to encode if the 'extensionID' is encoded an int (see Section 8.3), the sign is used
extension is critical and the 'critical' field is omitted. Critical to encode if the extension is critical and the 'critical' field is
extensions are encoded with a positive sign and non-critical omitted. Critical extensions are encoded with a negative sign and
extensions are encoded with a negative sign. non-critical extensions are encoded with a positive sign.
The 'extnValue' OCTET STREAM value field is encoded as the CBOR byte The 'extnValue' OCTET STREAM value field is encoded as the CBOR byte
string 'extensionValue' except for the extensions specified below. string 'extensionValue' except for the extensions mandated to be
The 'extensionValue' for the extensions mandated to be supported by supported by [RFC7925], [IEEE-802.1AR], and [CAB-Baseline] which are
[RFC7925], [IEEE-802.1AR], and [CAB-Baseline] are encoded as follows: encoded as specified below. For some extensions, only commonly used
parts are supported by the CBOR encoding. If unsupported parts are
used, the CBOR encoding cannot be used.
o keyUsage. The 'KeyUsage' BIT STRING is interpreted as an unsigned CBOR encoding of the following extension values are fully supported:
integer n in network byte order and encoded as a CBOR int.
o subjectAltName. extensionValue is encoded as an array of (int, o subjectKeyIdentifier. extensionValue is the value of the
any) pairs where each pair encodes a general name (see 'keyIdentifier' field encoded as a CBOR byte string.
Section 8.5). If subjectAltName contains exactly one dNSName, the
array and the int are omitted and extensionValue is the dNSName
encoded as a CBOR text string. In addition to the general names
defined in [RFC5280], the hardwareModuleName type of otherName has
been given its own int due to its mandatory use in IEEE 802.1AR.
When 'otherName + hardwareModuleName' is used, then [ oid, bytes ]
is used to identify the pair ( hwType, hwSerialEntries ) directly
as specified in [RFC4108].
GeneralNames = [ + GeneralName ] / text o keyUsage. The 'KeyUsage' BIT STRING is interpreted as an unsigned
GeneralName = ( GeneralNameType : int, GeneralNameValue : any ) integer in network byte order and encoded as a CBOR int.
o basicConstraints. If 'cA' = false then extensionValue = -2, if o basicConstraints. If 'cA' = false then extensionValue = -2, if
'cA' = true and 'pathLenConstraint' is not present then 'cA' = true and 'pathLenConstraint' is not present then
extensionValue = -1, and if 'cA' = true and 'pathLenConstraint' is extensionValue = -1, and if 'cA' = true and 'pathLenConstraint' is
present then extensionValue = pathLenConstraint. present then extensionValue = pathLenConstraint.
o extKeyUsage. extensionValue is encoded as an array of CBOR ints o extKeyUsage. extensionValue is encoded as an array of CBOR ints
(see Section 8.4) or unwrapped CBOR OID tags (see Section 8.5) or unwrapped CBOR OID tags
[I-D.ietf-cbor-tags-oid] where each int or OID tag encodes a key [I-D.ietf-cbor-tags-oid] where each int or OID tag encodes a key
usage purpose. If the array contains a single int, the array is usage purpose. If the array contains a single int, the array is
omitted. omitted.
ExtValueEKU = [ + int / ~oid ] / int ExtValueEKU = [ + int / ~oid ] / int
o subjectKeyIdentifier. extensionValue is the value of the CBOR encoding of the following extension values are partly supported:
'keyIdentifier' field encoded as a CBOR byte string.
o authorityKeyIdentifier. extensionValue is encoded as an array o subjectAltName. If the subject alternatice name only contains
where the value of the 'keyIdentifier' is encoded as a CBOR byte general names registered in Section 8.6 the extension value can be
string, 'GeneralNames' is encoded like in subjectAltName, and CBOR encoded. extensionValue is encoded as an array of (int, any)
'AuthorityCertSerialNumber' is encoded as ~biguint exactly like pairs where each pair encodes a general name (see Section 8.6).
certificateSerialNumber. Omitted values are encoded as CBOR null. If subjectAltName contains exactly one dNSName, the array and the
int are omitted and extensionValue is the dNSName encoded as a
CBOR text string. In addition to the general names defined in
[RFC5280], the hardwareModuleName type of otherName has been given
its own int due to its mandatory use in IEEE 802.1AR. When
'otherName + hardwareModuleName' is used, then [ oid, bytes ] is
used to identify the pair ( hwType, hwSerialEntries ) directly as
specified in [RFC4108]. Only the general names in Section 8.6 are
supported.
ExtValueAKI = [ keyIdentifier: bytes / null, ExtValueSAN = [ + GeneralName ] / text
certIssuer: GeneralNames / null, GeneralName = ( GeneralNameType : int, GeneralNameValue : any )
certSerialNumber: CertificateSerialNumber / null ]
/ bytes
o cRLDistributionPoints. If the cRLDistributionPoints is a sequence o cRLDistributionPoints. If the CRL Distribution Points is a
of DistributionPointName, it is encoded like subjectAltName, with sequence of DistributionPointName, where each
the difference that if cRLDistributionPoints contains exactly one DistributionPointName contains a single uniformResourceIdentifier,
uniformResourceIdentifier, the array and the int are omitted and the extension value can be CBOR encoded. The extensionValue is
extensionValue is the uniformResourceIdentifier encoded as a CBOR encoded as an array of CBOR text strings where each CBOR text
text string. string encodes a uniformResourceIdentifier. If the array contains
exactly one text string, the array is omitted.
o authorityInfoAccess. If authorityInfoAccess consist of only ExtValueCDP = [ 2* text ] / text
uniformResourceIdentifiers it is encoded as an array of uris.
ExtValueAIA = [ + ( ocsp : 1 // caIssuers : 2 , uri : text ) ] o certificatePolicies. If each PolicyInformation contains at most
one PolicyQualifierInfo, where all present policyQualifierId are
of type id-qt-cps and all present qualifiers are of type cPSuri,
the extension value can be CBOR encoded. OIDs registered in
Section 8.4 are encoded as an int.
ExtValueCP = [ + ( CertPolicyId: oid / int, ? CPSuri: text ) ]
o authorityKeyIdentifier. If the authority key identifier contains
all of keyIdentifier, certIssuer, and certSerialNumberm or if only
keyIdentifier is present the extension value can be CBOR encoded.
If all three are present a CBOR array is used, if only
keyIdentifier is present a CBOR byte string is used.
ExtValueAKI = [ keyIdentifier: bytes,
certIssuer: GeneralNames,
certSerialNumber: CertificateSerialNumber ]
/ bytes
o authorityInfoAccess. If all the GeneralNames in
authorityInfoAccess are of type uniformResourceIdentifier, the
extension value can be CBOR encoded. The accessMethod is encoded
as an CBOR int (1 for ocsp and 2 for caIssuers). The
uniformResourceIdentifiers are encoded as CBOR text strings.
ExtValueAIA = [ + ( accessMethod : 1 / 2 , uri : text ) ]
o signedCertificateTimestamp. If all the SCTs are version 1, and
there are no SCT extensions, the extension value can be CBOR
encoded. LogIDs are encoded as CBOR byte strings, the timestamp
is encoded as and CBOR int (milliseconds since validityNotBefore),
and the signature is encoded with an (AlgorithmIdentifier, any)
pair in the same way as issuerSignatureAlgorithm and
issuerSignatureValue.
ExtValueSCT = [ + ( LogID : bstr, timestamp : int,
alg : AlgorithmIdentifier, signature : any ) ]
3.3.1. Example Encoding of Extensions 3.3.1. Example Encoding of Extensions
The examples below use values from Section 8.3, Section 8.4, and The examples below use values from Section 8.3, Section 8.5, and
Section 8.5: Section 8.6:
o A critical basicConstraints ('cA' = true) without o A critical basicConstraints ('cA' = true) without
pathLenConstraint is encoded as the two CBOR ints -1, -1. pathLenConstraint is encoded as the two CBOR ints -4, -1.
o A non-critical keyUsage with digitalSignature and keyAgreement o A non-critical keyUsage with digitalSignature and keyAgreement
asserted is encoded as the two CBOR ints 2, 17 (2^0 + 2^4 = 17). asserted is encoded as the two CBOR ints 2, 17 (2^0 + 2^4 = 17).
o A non-critical extKeyUsage containing id-kp-codeSigning and id-kp- o A non-critical extKeyUsage containing id-kp-codeSigning and id-kp-
OCSPSigning is encoded as the CBOR int 3 followed by the CBOR OCSPSigning is encoded as the CBOR int 8 followed by the CBOR
array [ 3, 6 ]. array [ 3, 6 ].
o A non-critical subjectAltName containing only the dNSName o A non-critical subjectAltName containing only the dNSName
example.com is encoded as the CBOR int 4 followed by the CBOR text example.com is encoded as the CBOR int 3 followed by the CBOR text
string "example.com". string "example.com".
Thus, the extension field of a certificate containing all of the Thus, the extension field of a certificate containing all of the
above extensions in the given order would be encoded as the CBOR above extensions in the given order would be encoded as the CBOR
array [ -1, -1, 2, 17, 3, [ 3, 6 ], 4, "example.com" ]. array [ -4, -1, 2, 17, 8, [ 3, 6 ], 3, "example.com" ].
4. Compliance Requirements for Constrained IoT 4. Compliance Requirements for Constrained IoT
For general purpose applications, the normative requirements of For general purpose applications, the normative requirements of
[RFC5280] applies. This section describes the mandatory to implement [RFC5280] applies. This section describes the mandatory to implement
algorithms and OIDs for constrained IoT application; the values of algorithms and OIDs for constrained IoT application; the values of
the OIDs including certificate fields and extensions, time format, the OIDs including certificate fields and extensions, time format,
attributes in distinguished names, etc. attributes in distinguished names, etc.
TODO: Write this section TODO: Write this section
skipping to change at page 12, line 15 skipping to change at page 12, line 50
option is viable when client authentication can be asserted by other option is viable when client authentication can be asserted by other
means. means.
For protocols like IKEv2, TLS/DTLS 1.3, and EDHOC, where certificates For protocols like IKEv2, TLS/DTLS 1.3, and EDHOC, where certificates
are encrypted, the proposed encoding needs to be done fully end-to- are encrypted, the proposed encoding needs to be done fully end-to-
end, through adding the encoding/decoding functionality to the end, through adding the encoding/decoding functionality to the
server. server.
6. Expected Certificate Sizes 6. Expected Certificate Sizes
The CBOR encoding of the sample certificate given in Appendix A The CBOR encoding of the sample certificate chains given in
results in the numbers shown in Figure 2. After [RFC7925] profiling, Appendix A results in the numbers shown in Figure 2 and Figure 3.
most duplicated information has been removed, and the remaining text After [RFC7925] profiling, most duplicated information has been
strings are minimal in size. Therefore, the further size reduction removed, and the remaining text strings are minimal in size.
reached with general compression mechanisms will be small, mainly Therefore, the further size reduction reached with general
corresponding to making the ASN.1 encoding more compact. For Brtoli compression mechanisms such as Brotli will be small, mainly
[RFC7932], the brotli command line tool 1.09 was used with the corresponding to making the ASN.1 encoding more compact. CBOR
default best compression level. encoding can however significantly compress RFC 7925 profiled
certificates. For the example HTTPS certificate chains (www.ietf.org
and tools.ietf.org) both C509 and Brotli perform well complementing
each other. C509 use dedicated information to compress individual
certificates, while Brotli can compress duplicate information in the
entire chain. For Brotli [RFC7932], the Rust crate Brotli 3.3.0 was
used with compression level 11 and window size 22.
+------------------+--------------+------------+--------------------+ +---------------------------------------+-----------+-----------+
| | RFC 7925 | Brotli | C509 Certificate | | | COSE_X509 | COSE_C509 |
+------------------+---------------------------+--------------------+ +---------------------------------------+-----------+-----------+
| Certificate Size | 314 | 303 | 138 | | RFC 7925 profiled IoT Certificate | 317 | 139 |
+------------------+--------------+------------+--------------------+ +---------------------------------------+-----------+-----------+
| ECDSA HTTPS Certificate Chain | 2193 | 1394 |
+---------------------------------------+-----------+-----------+
| RSA HTTPS Certificate Chain | 5175 | 3934 |
+---------------------------------------+-----------+-----------+
Figure 2: Comparing Sizes of Certificates (bytes) Figure 2: Comparing Sizes of Certificate Chains in COSE (bytes)
+-------------------+------+---------------+------+---------------+
| | X509 | X509 + Brotli | C509 | C509 + Brotli |
+-------------------+------+---------------+------+---------------+
| RFC 7925 Cert | 327 | 324 | 151 | 167 |
+-------------------+------+---------------+------+---------------+
| ECDSA HTTPS Chain | 2204 | 1455 | 1409 | 1058 |
+-------------------+------+---------------+------+---------------+
| RSA HTTPS Chain | 5190 | 3244 | 3957 | 2841 |
+-------------------+------+---------------+------+---------------+
Figure 3: Comparing Sizes of Certificate Chains TLS (bytes)
7. Security Considerations 7. Security Considerations
The CBOR profiling of X.509 certificates does not change the security The CBOR profiling of X.509 certificates does not change the security
assumptions needed when deploying standard X.509 certificates but assumptions needed when deploying standard X.509 certificates but
decreases the number of fields transmitted, which reduces the risk decreases the number of fields transmitted, which reduces the risk
for implementation errors. for implementation errors.
The use of natively signed C509 certificates removes the need for The use of natively signed C509 certificates removes the need for
ASN.1 encoding, which is a rich source of security vulnerabilities. ASN.1 encoding, which is a rich source of security vulnerabilities.
skipping to change at page 13, line 44 skipping to change at page 14, line 50
initial contents of the registry are: initial contents of the registry are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+=======+===========================================================+ +=======+===========================================================+
| 0 | Natively Signed C509 Certificate following X.509 v3 | | 0 | Natively Signed C509 Certificate following X.509 v3 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | CBOR re-encoding of X.509 v3 Certificate | | 1 | CBOR re-encoding of X.509 v3 Certificate |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 3: C509 Certificate Types Figure 4: C509 Certificate Types
8.2. C509 Certificate Attributes Registry 8.2. C509 Certificate Attributes Registry
IANA has created a new registry titled "C509 Certificate Attributes" IANA has created a new registry titled "C509 Certificate Attributes"
under the new heading "C509 Certificate". The columns of the under the new heading "C509 Certificate". The columns of the
registry are Value, Name, OID, DER, Comments, and Reference, where registry are Value, Name, OID, DER, Comments, and Reference, where
Value is an integer, and the other columns are text strings. Only Value is an positive integer, and the other columns are text strings.
non-negative values can be registered. For values in the interval For values in the interval [1, 23] the registration procedure is
"IETF Review" and "Expert Review". For all other values the
[0, 23] the registration procedure is "IETF Review" and "Expert registration procedure is "Expert Review". The initial contents of
Review". For all other values the registration procedure is "Expert the registry are:
Review". The initial contents of the registry are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Attribute | | Value | Attribute |
+=======+===========================================================+ +=======+===========================================================+
| 1 | Name: Common Name | | 1 | Name: Common Name |
| | OID: 2.5.4.3 | | | OID: 2.5.4.3 |
| | DER: 06 03 55 04 03 | | | DER: 06 03 55 04 03 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 2 | Name: Surname | | 2 | Name: Surname |
skipping to change at page 15, line 49 skipping to change at page 17, line 8
| | OID: 2.5.4.65 | | | OID: 2.5.4.65 |
| | DER: 06 03 55 04 41 | | | DER: 06 03 55 04 41 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 17 | Name: Organization Identifier | | 17 | Name: Organization Identifier |
| | OID: 2.5.4.97 | | | OID: 2.5.4.97 |
| | DER: 06 03 55 04 61 | | | DER: 06 03 55 04 61 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 4: C509 Certificate Attributes Figure 5: C509 Certificate Attributes
8.3. C509 Certificate Extensions Registry 8.3. C509 Certificate Extensions Registry
IANA has created a new registry titled "C509 Certificate Extensions" IANA has created a new registry titled "C509 Certificate Extensions"
under the new heading "C509 Certificate". The columns of the under the new heading "C509 Certificate". The columns of the
registry are Value, Name, OID, DER, Comments, extensionValue, and registry are Value, Name, OID, DER, Comments, extensionValue, and
Reference, where Value is an integer, and the other columns are text Reference, where Value is an positive integer, and the other columns
strings. Only non-negative values can be registered. For values in are text strings. For values in the interval [1, 23] the
the interval [0, 23] the registration procedure is "IETF Review" and registration procedure is "IETF Review" and "Expert Review". For all
"Expert Review". For all other values the registration procedure is other values the registration procedure is "Expert Review". The
"Expert Review". The initial contents of the registry are: initial contents of the registry are:
+-------+-----------------------------------------------------------+
| Value | Extension |
+=======+===========================================================+
| 1 | Name: Subject Key Identifier |
| | OID: 2.5.29.14 |
| | DER: 06 03 55 1D 0E |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 2 | Name: Key Usage |
| | OID: 2.5.29.15 |
| | DER: 06 03 55 1D 0F |
| | Comments: |
| | AttributeValue: int |
+-------+-----------------------------------------------------------+
| 3 | Name: Subject Alternative Name |
| | OID: 2.5.29.17 |
| | DER: 06 03 55 1D 11 |
| | Comments: |
| | extensionValue: ExtValueSAN |
+-------+-----------------------------------------------------------+
| 4 | Name: Basic Constraints |
| | OID: 2.5.29.19 |
| | DER: 06 03 55 1D 13 |
| | Comments: |
| | extensionValue: int |
+-------+------------------------------------------er-----------------+
| 5 | Name: CRL Distribution Points |
| | OID: 2.5.29.31 |
| | DER: 06 03 55 1D 1F |
| | Comments: |
| | extensionValue: ExtValueCDP |
+-------+-----------------------------------------------------------+
| 6 | Name: Certificate Policies |
| | OID: 2.5.29.32 |
| | DER: 06 03 55 1D 20 |
| | Comments: |
| | extensionValue: ExtValueCP |
+-------+-----------------------------------------------------------+
| 7 | Name: Authority Key Identifier |
| | OID: 2.5.29.35 |
| | DER: 06 03 55 1D 23 |
| | Comments: |
| | extensionValue: ExtValueAKI |
+-------+-----------------------------------------------------------+
| 8 | Name: Extended Key Usage |
| | OID: 2.5.29.37 |
| | DER: 06 03 55 1D 25 |
| | Comments: |
| | extensionValue: ExtValueEKU |
+-------+-----------------------------------------------------------+
| 9 | Name: Authority Information Access |
| | OID: 1.3.6.1.5.5.7.1.1 |
| | DER: 06 08 2B 06 01 05 05 07 01 01 |
| | Comments: |
| | extensionValue: ExtValueAIA |
+-------+-----------------------------------------------------------+
| 10 | Name: Signed Certificate Timestamp List |
| | OID: 1.3.6.1.4.1.11129.2.4.2 |
| | DER: 06 0A 2B 06 01 04 01 D6 79 02 04 02 |
| | Comments: |
| | extensionValue: ExtValueSCT |
+-------+-----------------------------------------------------------+
| 24 | Name: Subject Directory Attributes |
| | OID: 2.5.29.9 |
| | DER: 06 03 55 1D 09 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 25 | Name: Issuer Alternative Name |
| | OID: 2.5.29.18 |
| | DER: 06 03 55 1D 12 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 26 | Name: Name Constraints |
| | OID: 2.5.29.30 |
| | DER: 06 03 55 1D 1E |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 27 | Name: Policy Mappings |
| | OID: 2.5.29.33 |
| | DER: 06 03 55 1D 21 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 28 | Name: Policy Constraints |
| | OID: 2.5.29.36 |
| | DER: 06 03 55 1D 24 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 29 | Name: Freshest CRL |
| | OID: 2.5.29.46 |
| | DER: 06 03 55 1D 2E |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 30 | Name: Inhibit anyPolicy |
| | OID: 2.5.29.54 |
| | DER: 06 03 55 1D 36 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 31 | Name: Subject Information Access |
| | OID: 1.3.6.1.5.5.7.1.11 |
| | DER: 06 08 2B 06 01 05 05 07 01 0B |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
Figure 6: C509 Certificate Extensions
8.4. C509 Certificate Certificate Policies Registry
IANA has created a new registry titled "C509 Certificate Certificate
Policies" under the new heading "C509 Certificate". The columns of
the registry are Value, Name, OID, DER, Comments, and Reference,
where Value is an integer, and the other columns are text strings.
For values in the interval [-24, 23] the registration procedure is
"IETF Review" and "Expert Review". For all other values the
registration procedure is "Expert Review". The initial contents of
the registry are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Extension | | Value | Certificate Policy |
+=======+===========================================================+ +=======+===========================================================+
| 0 | Name: Subject Key Identifier | | 1 | Name: Domain Validation (DV) |
| | OID: 2.5.29.14 | | | OID: 2.23.140.1.2.1 |
| | DER: 06 03 55 1D 0E | | | DER: 06 06 67 81 0C 01 02 01 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 1 | Name: Key Usage |
| | OID: 2.5.29.15 |
| | DER: 06 03 55 1D 0F |
| | Comments: |
| | AttributeValue: int |
+-------+-----------------------------------------------------------+
| 2 | Name: Subject Alternative Name |
| | OID: 2.5.29.17 |
| | DER: 06 03 55 1D 11 |
| | Comments: |
| | extensionValue: [ + ( int, any ) ] / text |
+-------+-----------------------------------------------------------+
| 3 | Name: Basic Constraints |
| | OID: 2.5.29.19 |
| | DER: 06 03 55 1D 13 |
| | Comments: |
| | extensionValue: int |
+-------+-----------------------------------------------------------+
| 4 | Name: CRL Distribution Points |
| | OID: 2.5.29.31 |
| | DER: 06 03 55 1D 1F |
| | Comments: |
| | extensionValue: [ + ( int, any ) ] / text |
+-------+-----------------------------------------------------------+
| 5 | Name: Certificate Policies |
| | OID: 2.5.29.32 |
| | DER: 06 03 55 1D 20 |
| | Comments: |
| | extensionValue: [ + ( oid, ? text ) ] |
+-------+-----------------------------------------------------------+
| 6 | Name: Authority Key Identifier |
| | OID: 2.5.29.35 |
| | DER: 06 03 55 1D 23 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 7 | Name: Extended Key Usage |
| | OID: 2.5.29.37 |
| | DER: 06 03 55 1D 25 |
| | Comments: |
| | extensionValue: int |
+-------+-----------------------------------------------------------+
| 8 | Name: Authority Information Access |
| | OID: 1.3.6.1.5.5.7.1.1 |
| | DER: 06 08 2B 06 01 05 05 07 01 01 |
| | Comments: |
| | extensionValue: [ + ( 1 / 2 , text ) ] |
+-------+-----------------------------------------------------------+
| 9 | Name: Signed Certificate Timestamp List |
| | OID: 1.3.6.1.4.1.11129.2.4.2 |
| | DER: 06 0A 2B 06 01 04 01 D6 79 02 04 02 |
| | Comments: |
| | extensionValue: [ bytes, ~biguint, |
| | AlgorithmIdentifier, bytes] |
+-------+-----------------------------------------------------------+
| 24 | Name: Subject Directory Attributes |
| | OID: 2.5.29.9 |
| | DER: 06 03 55 1D 09 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 25 | Name: Issuer Alternative Name |
| | OID: 2.5.29.18 |
| | DER: 06 03 55 1D 12 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 26 | Name: Name Constraints |
| | OID: 2.5.29.30 |
| | DER: 06 03 55 1D 1E |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 27 | Name: Policy Mappings |
| | OID: 2.5.29.33 |
| | DER: 06 03 55 1D 21 |
| | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+
| 28 | Name: Policy Constraints |
| | OID: 2.5.29.36 |
| | DER: 06 03 55 1D 24 |
| | Comments: | | | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 29 | Name: Freshest CRL | | 2 | Name: Organization Validation (OV) |
| | OID: 2.5.29.46 | | | OID: 2.23.140.1.2.2 |
| | DER: 06 03 55 1D 2E | | | DER: 06 06 67 81 0C 01 02 02 |
| | Comments: | | | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 30 | Name: Inhibit anyPolicy | | 3 | Name: Individual Validation (IV) |
| | OID: 2.5.29.54 | | | OID: 2.23.140.1.2.3 |
| | DER: 06 03 55 1D 36 | | | DER: 06 06 67 81 0C 01 02 03 |
| | Comments: | | | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 31 | Name: Subject Information Access | | 4 | Name: Extended Validation (EV) |
| | OID: 1.3.6.1.5.5.7.1.11 | | | OID: 2.23.140.1.1 |
| | DER: 06 08 2B 06 01 05 05 07 01 0B | | | DER: 06 05 67 81 0C 01 01 |
| | Comments: | | | Comments: |
| | extensionValue: bytes |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 5: C509 Certificate Extensions Figure 7: C509 Certificate Certificate Policies
8.4. C509 Certificate Extended Key Usages Registry 8.5. C509 Certificate Extended Key Usages Registry
IANA has created a new registry titled "C509 Certificate Extended Key IANA has created a new registry titled "C509 Certificate Extended Key
Usages" under the new heading "C509 Certificate". The columns of the Usages" under the new heading "C509 Certificate". The columns of the
registry are Value, Name, OID, DER, Comments, and Reference, where registry are Value, Name, OID, DER, Comments, and Reference, where
Value is an integer, and the other columns are text strings. For Value is an integer, and the other columns are text strings. For
values in the interval [-24, 23] the registration procedure is "IETF values in the interval [-24, 23] the registration procedure is "IETF
Review" and "Expert Review". For all other values the registration Review" and "Expert Review". For all other values the registration
procedure is "Expert Review". The initial contents of the registry procedure is "Expert Review". The initial contents of the registry
are: are:
skipping to change at page 19, line 39 skipping to change at page 21, line 39
| | OID: 1.3.6.1.5.5.7.3.8 | | | OID: 1.3.6.1.5.5.7.3.8 |
| | DER: 06 08 2B 06 01 05 05 07 03 08 | | | DER: 06 08 2B 06 01 05 05 07 03 08 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 9 | Name: OCSP Signing | | 9 | Name: OCSP Signing |
| | OID: 1.3.6.1.5.5.7.3.9 | | | OID: 1.3.6.1.5.5.7.3.9 |
| | DER: 06 08 2B 06 01 05 05 07 03 09 | | | DER: 06 08 2B 06 01 05 05 07 03 09 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 6: C509 Certificate Extended Key Usages Figure 8: C509 Certificate Extended Key Usages
8.5. C509 Certificate General Names Registry 8.6. C509 Certificate General Names Registry
IANA has created a new registry titled "C509 Certificate General IANA has created a new registry titled "C509 Certificate General
Names" under the new heading "C509 Certificate". The columns of the Names" under the new heading "C509 Certificate". The columns of the
registry are Value, General Name, and Reference, where Value is an registry are Value, General Name, and Reference, where Value is an
integer, and the other columns are text strings. For values in the integer, and the other columns are text strings. For values in the
interval [-24, 23] the registration procedure is "IETF Review" and interval [-24, 23] the registration procedure is "IETF Review" and
"Expert Review". For all other values the registration procedure is "Expert Review". For all other values the registration procedure is
"Expert Review". The initial contents of the registry are: "Expert Review". The initial contents of the registry are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
skipping to change at page 20, line 41 skipping to change at page 22, line 41
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 7 | Name: iPAddress | | 7 | Name: iPAddress |
| | Comments: | | | Comments: |
| | Value: bytes | | | Value: bytes |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 8 | Name: registeredID | | 8 | Name: registeredID |
| | Comments: | | | Comments: |
| | Value: ~oid | | | Value: ~oid |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 7: C509 Certificate General Names Figure 9: C509 Certificate General Names
8.6. C509 Certificate Signature Algorithms Registry 8.7. C509 Certificate Signature Algorithms Registry
IANA has created a new registry titled "C509 Certificate Signature IANA has created a new registry titled "C509 Certificate Signature
Algorithms" under the new heading "C509 Certificate". The columns of Algorithms" under the new heading "C509 Certificate". The columns of
the registry are Value, Name, OID, Parameters, DER, Comments, and the registry are Value, Name, OID, Parameters, DER, Comments, and
Reference, where Value is an integer, and the other columns are text Reference, where Value is an integer, and the other columns are text
strings. For values in the interval [-24, 23] the registration strings. For values in the interval [-24, 23] the registration
procedure is "IETF Review" and "Expert Review". For all other values procedure is "IETF Review" and "Expert Review". For all other values
the registration procedure is "Expert Review". The initial contents the registration procedure is "Expert Review". The initial contents
of the registry are: of the registry are:
skipping to change at page 23, line 44 skipping to change at page 25, line 44
| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 | | | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 44 | Name: XMSS^MT | | 44 | Name: XMSS^MT |
| | OID: 0.4.0.127.0.15.1.1.14.0 | | | OID: 0.4.0.127.0.15.1.1.14.0 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 | | | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 8: C509 Certificate Signature Algorithms Figure 10: C509 Certificate Signature Algorithms
8.7. C509 Certificate Public Key Algorithms Registry 8.8. C509 Certificate Public Key Algorithms Registry
IANA has created a new registry titled "C509 Certificate Public Key IANA has created a new registry titled "C509 Certificate Public Key
Algorithms" under the new heading "C509 Certificate". The columns of Algorithms" under the new heading "C509 Certificate". The columns of
the registry are Value, Name, OID, Parameters, DER, Comments, and the registry are Value, Name, OID, Parameters, DER, Comments, and
Reference, where Value is an integer, and the other columns are text Reference, where Value is an integer, and the other columns are text
strings. For values in the interval [-24, 23] the registration strings. For values in the interval [-24, 23] the registration
procedure is "IETF Review" and "Expert Review". For all other values procedure is "IETF Review" and "Expert Review". For all other values
the registration procedure is "Expert Review". T The initial the registration procedure is "Expert Review". T The initial
contents of the registry are: contents of the registry are:
skipping to change at page 25, line 34 skipping to change at page 27, line 34
| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 | | | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 18 | Name: XMSS^MT | | 18 | Name: XMSS^MT |
| | OID: 0.4.0.127.0.15.1.1.14.0 | | | OID: 0.4.0.127.0.15.1.1.14.0 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 | | | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 9: C509 Certificate Public Key Algorithms Figure 11: C509 Certificate Public Key Algorithms
8.8. COSE Header Parameters Registry 8.9. COSE Header Parameters Registry
EDITORS NOTE: Should x5u refer to a bag or a chain? The text should EDITORS NOTE: The text should be moved a section and not be in the
be moved a section and not be in the IANA Section. IANA Section.
This document registers the following entries in the "COSE Header This document registers the following entries in the "COSE Header
Parameters" registry under the "CBOR Object Signing and Encryption Parameters" registry under the "CBOR Object Signing and Encryption
(COSE)" heading. The formatting and processing for c5b, c5c, and (COSE)" heading. The formatting and processing for c5b, c5c, and
c5t, and c5u are similar to x5bag, x5chain, x5t, x5u defined in c5t, and c5u are similar to x5bag, x5chain, x5t, x5u defined in
[I-D.ietf-cose-x509] except that the certificates are CBOR encoded [I-D.ietf-cose-x509] except that the certificates are C509 instead of
instead of DER encoded, uses a COSE_C5 structure instead of DER encoded X.509 and uses a COSE_C509 structure instead of
COSE_X509, and that c5t MUST refer to an end-entity certificate. c5u COSE_X509. c5u provides an alternative way to identify an untrusted
provides an alternative way to identify an untrusted certificate bag/ certificate bag/chain by reference with a URI. The content is a
chain by reference with a URI. The content is a COSE_C5 item served COSE_C509 item served with the application/cbor content format. The
with the application/cbor content format. The COSE_C5 structure used COSE_C509 structure used in c5b, c5c, and c5u is defined as:
in c5b, c5c, and c5u is defined as:
COSE_C5 = [ + CBORCertificate ] COSE_C509 = C509Certificate / [ 2* C509Certificate ]
As the contents of c5bag, c5chain, c5t, and c5u are untrusted input, As the contents of c5bag, c5chain, c5t, and c5u are untrusted input,
the header parameters can be in either the protected or unprotected the header parameters can be in either the protected or unprotected
header bucket. The trust mechanism MUST process any certificates in header bucket. The trust mechanism MUST process any certificates in
the c5b, c5c, and c5u parameters as untrusted input. The presence of the c5b, c5c, and c5u parameters as untrusted input. The presence of
a self-signed certificate in the parameter MUST NOT cause the update a self-signed certificate in the parameter MUST NOT cause the update
of the set of trust anchors without some out-of-band confirmation. of the set of trust anchors without some out-of-band confirmation.
Note that certificates can also be identified with a 'kid' header Note that certificates can also be identified with a 'kid' header
parameter by storing 'kid' and the associated bag or chain in a parameter by storing 'kid' and the associated bag or chain in a
dictionary. dictionary.
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+------------------------------+
| Name | Label | Value Type | Description | | Name | Label | Value Type | Description |
+===========+=======+================+==============================+ +===========+=======+================+==============================+
| c5b | TBD1 | COSE_C5 | An unordered bag of C509 | | c5b | TBD1 | COSE_C509 | An unordered bag of C509 |
| | | | certificates | | | | | certificates |
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+------------------------------+
| c5c | TBD2 | COSE_C5 | An ordered chain of C509 | | c5c | TBD2 | COSE_C509 | An ordered chain of C509 |
| | | | certificates | | | | | certificates |
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+------------------------------+
| c5t | TBD3 | COSE_CertHash | Hash of a C509 certificate | | c5t | TBD3 | COSE_CertHash | Hash of a C509Certificate |
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+------------------------------+
| c5u | TBD4 | uri | URI pointing to a COSE_C5 | | c5u | TBD4 | uri | URI pointing to a COSE_C509 |
| | | | containing a ordered chain | | | | | containing a ordered chain |
| | | | of certificates | | | | | of certificates |
+-----------+-------+----------------+------------------------------+ +-----------+-------+----------------+------------------------------+
8.9. TLS Certificate Types Registry 8.10. TLS Certificate Types Registry
This document registers the following entry in the "TLS Certificate This document registers the following entry in the "TLS Certificate
Types" registry under the "Transport Layer Security (TLS) Extensions" Types" registry under the "Transport Layer Security (TLS) Extensions"
heading. The new certificate type can be used with additional TLS heading. The new certificate type can be used with additional TLS
certificate compression [RFC8879]. certificate compression [RFC8879]. C509 is defined in the same way
as as X509, but uses a different value and instead of DER-encoded
X.509 certificate, opaque cert_data<1..2^24-1> contains a the CBOR
sequence ~C509Certificate (an unwrapped C509Certificate).
EDITOR'S NOTE: The TLS registrations should be discussed and approved EDITOR'S NOTE: The TLS registrations should be discussed and approved
by the TLS WG at a later stage. When COSE WG has adopted work on by the TLS WG at a later stage. When COSE WG has adopted work on
C509 certificates, it could perhaps be presented in the TLS WG. The C509 certificates, it could perhaps be presented in the TLS WG. The
TLS WG might e.g. want a separate draft in the TLS WG. TLS WG might e.g. want a separate draft in the TLS WG.
+-------+------------------+-------------+--------------------------+ +-------+------------------+-------------+--------------------------+
| Value | Name | Recommended | Comment | | Value | Name | Recommended | Comment |
+=======+==================+=============+==========================+ +=======+==================+=============+==========================+
| TBD5 | C509 Certificate | Y | | | TBD5 | C509 Certificate | Y | |
+-------+------------------+-------------+--------------------------+ +-------+------------------+-------------+--------------------------+
8.10. CBOR Tags Registry 8.11. CBOR Tags Registry
This document registers the following entries in the "CBOR Tags" This document registers the following entries in the "CBOR Tags"
registry under the "Concise Binary Object Representation (CBOR) Tags" registry under the "Concise Binary Object Representation (CBOR) Tags"
heading. heading.
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Tag | X.509 Public Key Algorithms | | Tag | X.509 Public Key Algorithms |
+======+============================================================+ +======+============================================================+
| TDB6 | Data Item: COSE_C5 | | TDB6 | Data Item: COSE_C509 |
| | Semantics: An ordered chain of C509 certificates | | | Semantics: An ordered chain of C509 certificates |
| | Reference: This document | | | Reference: This document |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-cbor-tags-oid] [I-D.ietf-cbor-tags-oid]
Bormann, C., "Concise Binary Object Representation (CBOR) Bormann, C., "Concise Binary Object Representation (CBOR)
skipping to change at page 28, line 36 skipping to change at page 30, line 46
<https://secg.org/sec1-v2.pdf>. <https://secg.org/sec1-v2.pdf>.
9.2. Informative References 9.2. Informative References
[CAB-Baseline] [CAB-Baseline]
CA/Browser Forum, ., "CA/Browser Forum, "Baseline CA/Browser Forum, ., "CA/Browser Forum, "Baseline
Requirements for the Issuance and Management of Publicly- Requirements for the Issuance and Management of Publicly-
Trusted Certificates Version 1.7.3", October 2020, Trusted Certificates Version 1.7.3", October 2020,
<https://cabforum.org/baseline-requirements-documents/>. <https://cabforum.org/baseline-requirements-documents/>.
[CborMe] Bormann, C., "CBOR Playground", May 2018,
<http://cbor.me/>.
[I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eap-tls13]
Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
draft-ietf-emu-eap-tls13-14 (work in progress), February draft-ietf-emu-eap-tls13-15 (work in progress), May 2021.
2021.
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-08 (work in progress), Methods", draft-ietf-emu-eaptlscert-08 (work in progress),
November 2020. November 2020.
[I-D.ietf-lake-edhoc] [I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Selander, G., Mattsson, J. P., and F. Palombini,
Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-ietf-
edhoc-06 (work in progress), April 2021. lake-edhoc-06 (work in progress), April 2021.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-34 (work and Secure Transport", draft-ietf-quic-transport-34 (work
in progress), January 2021. in progress), January 2021.
[I-D.ietf-tls-ctls] [I-D.ietf-tls-ctls]
Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
1.3", draft-ietf-tls-ctls-01 (work in progress), November 1.3", draft-ietf-tls-ctls-01 (work in progress), November
2020. 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-40 (work in progress), January 1.3", draft-ietf-tls-dtls13-43 (work in progress), April
2021. 2021.
[I-D.ietf-uta-tls13-iot-profile] [I-D.ietf-uta-tls13-iot-profile]
Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for
the Internet of Things", draft-ietf-uta-tls13-iot- the Internet of Things", draft-ietf-uta-tls13-iot-
profile-01 (work in progress), February 2021. profile-01 (work in progress), February 2021.
[IEEE-802.1AR] [IEEE-802.1AR]
Institute of Electrical and Electronics Engineers, ., Institute of Electrical and Electronics Engineers, .,
"IEEE Standard for Local and metropolitan area networks- "IEEE Standard for Local and metropolitan area networks-
skipping to change at page 32, line 7 skipping to change at page 34, line 7
69 3F 16 21 3A 04 52 5E D4 44 50 B1 01 9C 2D FD 38 38 AB AC 4E 14 D8 69 3F 16 21 3A 04 52 5E D4 44 50 B1 01 9C 2D FD 38 38 AB AC 4E 14 D8
6C 09 83 ED 5E 9E EF 24 48 C6 86 1C C4 06 54 71 77 E6 02 60 30 D0 51 6C 09 83 ED 5E 9E EF 24 48 C6 86 1C C4 06 54 71 77 E6 02 60 30 D0 51
F7 79 2A C2 06 A3 0F 30 0D 30 0B 06 03 55 1D 0F 04 04 03 02 07 80 30 F7 79 2A C2 06 A3 0F 30 0D 30 0B 06 03 55 1D 0F 04 04 03 02 07 80 30
0A 06 08 2A 86 48 CE 3D 04 03 02 03 47 00 30 44 02 20 44 5D 79 8C 90 0A 06 08 2A 86 48 CE 3D 04 03 02 03 47 00 30 44 02 20 44 5D 79 8C 90
E7 F5 00 DC 74 7A 65 4C EC 6C FA 6F 03 72 76 E1 4E 52 ED 07 FC 16 29 E7 F5 00 DC 74 7A 65 4C EC 6C FA 6F 03 72 76 E1 4E 52 ED 07 FC 16 29
4C 84 66 0D 02 20 5A 33 98 5D FB D4 BF DD 6D 4A CF 38 04 C3 D4 6E BF 4C 84 66 0D 02 20 5A 33 98 5D FB D4 BF DD 6D 4A CF 38 04 C3 D4 6E BF
3B 7F A6 26 40 67 4F C0 35 4F A0 56 DB AE A6 3B 7F A6 26 40 67 4F C0 35 4F A0 56 DB AE A6
A.1.1. Example C509 Certificate Encoding A.1.1. Example C509 Certificate Encoding
The CBOR encoding of the same X.509 certificate is shown below in The CBOR encoding (~C509Certificate) of the same X.509 certificate is
CBOR diagnostic format. shown below in CBOR diagnostic format.
/This defines a CBOR Sequence (RFC 8742):/ /This defines a CBOR Sequence (RFC 8742):/
1, 1,
h'01f50d', h'01f50d',
"RFC test CA", "RFC test CA",
1577836800, 1577836800,
1612224000, 1612224000,
h'0123456789AB', h'0123456789AB',
1, 1,
skipping to change at page 32, line 47 skipping to change at page 34, line 47
5E D4 44 50 B1 01 9C 2D FD 38 38 AB 5E D4 44 50 B1 01 9C 2D FD 38 38 AB
01 01
00 00
58 40 44 5D 79 8C 90 E7 F5 00 DC 74 7A 65 4C EC 6C FA 6F 03 72 76 E1 58 40 44 5D 79 8C 90 E7 F5 00 DC 74 7A 65 4C EC 6C FA 6F 03 72 76 E1
4E 52 ED 07 FC 16 29 4C 84 66 0D 5A 33 98 5D FB D4 BF DD 6D 4A CF 38 4E 52 ED 07 FC 16 29 4C 84 66 0D 5A 33 98 5D FB D4 BF DD 6D 4A CF 38
04 C3 D4 6E BF 3B 7F A6 26 40 67 4F C0 35 4F A0 56 DB AE A6 04 C3 D4 6E BF 3B 7F A6 26 40 67 4F C0 35 4F A0 56 DB AE A6
A.1.2. Example: Natively Signed C509 Certificate A.1.2. Example: Natively Signed C509 Certificate
The corresponding natively signed C509 certificate in CBOR diagnostic The corresponding natively signed C509 certificate in CBOR diagnostic
format is identical, except for cborCertificateType and format is identical, except for c509CertificateType and
signatureValue. signatureValue.
/This defines a CBOR Sequence (RFC 8742):/ /This defines a CBOR Sequence (RFC 8742):/
0, 0,
h'01f50d', h'01f50d',
"RFC test CA", "RFC test CA",
1577836800, 1577836800,
1612224000, 1612224000,
h'0123456789AB', h'0123456789AB',
skipping to change at page 35, line 34 skipping to change at page 37, line 34
97 bf b0 e3 d3 0c b6 ce e6 0d 94 c3 c7 5f d1 17 53 36 93 11 08 d8 98 97 bf b0 e3 d3 0c b6 ce e6 0d 94 c3 c7 5f d1 17 53 36 93 11 08 d8 98
12 d4 d2 9d 81 d0 02 21 00 a1 59 d1 6c 46 47 d1 48 37 57 fc d6 ce 4e 12 d4 d2 9d 81 d0 02 21 00 a1 59 d1 6c 46 47 d1 48 37 57 fc d6 ce 4e
75 ec 7b 5e f6 57 ef e0 28 f8 e5 cc 47 92 68 2d ac 43 30 0a 06 08 2a 75 ec 7b 5e f6 57 ef e0 28 f8 e5 cc 47 92 68 2d ac 43 30 0a 06 08 2a
86 48 ce 3d 04 03 02 03 49 00 30 46 02 21 00 bd 63 cf 4f 7e 5c fe 6c 86 48 ce 3d 04 03 02 03 49 00 30 46 02 21 00 bd 63 cf 4f 7e 5c fe 6c
29 38 5e a7 1c fb fc 1e 3f 7b 1c d0 72 51 a2 21 f7 77 69 c0 f4 71 df 29 38 5e a7 1c fb fc 1e 3f 7b 1c d0 72 51 a2 21 f7 77 69 c0 f4 71 df
ea 02 21 00 b5 c0 6c c4 58 54 fa 30 b2 82 88 b1 d3 bb 9a 66 61 ed 50 ea 02 21 00 b5 c0 6c c4 58 54 fa 30 b2 82 88 b1 d3 bb 9a 66 61 ed 50
31 72 5b 1a 82 02 e0 da 5b 59 f9 54 02 31 72 5b 1a 82 02 e0 da 5b 59 f9 54 02
A.3.1. Example C509 Certificate Encoding A.3.1. Example C509 Certificate Encoding
The CBOR encoding of the first X.509 certificate is shown below in The CBOR encoding (~C509Certificate) of the first X.509 certificate
CBOR diagnostic format. is shown below in CBOR diagnostic format.
/This defines a CBOR Sequence (RFC 8742):/ /This defines a CBOR Sequence (RFC 8742):/
1, 1,
h'047FA1E31928EE403BA0B83A395673FC', h'047FA1E31928EE403BA0B83A395673FC',
[ [
-4, "IE", -4, "US",
-8, "Baltimore", -8, "Cloudflare, Inc.",
-9, "CyberTrust", -1, "Cloudflare Inc ECC CA-3"
-1, "Baltimore CyberTrust Root" ],
], 1595980800,
1595980800, 1627560000,
1627560000, [
[ -4, "US",
-4, "US", -6, "CA",
-6, "CA", -5, "San Francisco",
-5, "San Francisco", -8, "Cloudflare, Inc.",
-8, "Cloudflare, Inc.", -1, "sni.cloudflaressl.com"
-1, "sni.cloudflaressl.com" ],
], 1,
1, h'03963ECDD84DCD1B93A1CF432D1A7217D6C63BDE3355A02F8CFB5AD8994CD44E20',
h'03963ECDD84DCD1B93A1CF432D1A7217D6C63BDE3355A02F8CFB5AD8994CD44E20', [
[ 7, h'A5CE37EAEBB0750E946788B445FAD9241087961F',
6, h'A5CE37EAEBB0750E946788B445FAD9241087961F', 1, h'CC0B50E7D837DBF243F3853D4860F53B39BE9B2A',
0, h'CC0B50E7D837DBF243F3853D4860F53B39BE9B2A', 3, [2, "sni.cloudflaressl.com", 2, "www.ietf.org"],
2, [2, "sni.cloudflaressl.com", 2, "www.ietf.org"], -2, 1,
-1, 1, 8, [1, 2],
7, [1, 2], 5, ["http://crl3.digicert.com/CloudflareIncECCCA-3.crl",
4, ["http://crl3.digicert.com/CloudflareIncECCCA-3.crl", "http://crl4.digicert.com/CloudflareIncECCCA-3.crl"],
"http://crl4.digicert.com/CloudflareIncECCCA-3.crl"], 6, [h'6086480186FD6C0101', "https://www.digicert.com/CPS", 2],
5, [h'6086480186FD6C0101', "https://www.digicert.com/CPS", 2], 9, [1, "http://ocsp.digicert.com",
8, [1, "http://ocsp.digicert.com", 2, "http://cacerts.digicert.com/CloudflareIncECCCA-3.crt"],
2, "http://cacerts.digicert.com/CloudflareIncECCCA-3.crt"], -4, -2,
-3, -2, 10, [
9, ... h'F65C942FD1773022145418083094568EE34D131933BFDF0C2F200BCC4EF164E3',
], 77922190,
0, 0,
h'BD63CF4F7E5CFE6C29385EA71CFBFC1E3F7B1CD07251A221F77769C0F471DFEA h'F8D1B4A93D2F0D4C4176DFB488BCC73B86443D7DE00E6AC8174D8948A8843668
B5C06CC45854FA30B28288B1D3BB9A6661ED5031725B1A8202E0DA5B59F95402' 29FF5A34068A240C69502788E8EE25AB7ED2CBCF686ECE7B5F96B431A90702FA',
h'5CDC4392FEE6AB4544B15E9AD456E61037FBD5FA47DCA17394B25EE6F6C70ECA',
77922238,
0,
h'E891C197BFB0E3D30CB6CEE60D94C3C75FD1175336931108D89812D4D29D81D0
A159D16C4647D1483757FCD6CE4E75EC7B5EF657EFE028F8E5CC4792682DAC43'
]
],
0,
h'BD63CF4F7E5CFE6C29385EA71CFBFC1E3F7B1CD07251A221F77769C0F471DFEA
B5C06CC45854FA30B28288B1D3BB9A6661ED5031725B1A8202E0DA5B59F95402'
The size of the CBOR encoding (CBOR sequence) is 781 bytes.
A.4. Example CAB Baseline RSA HTTPS X.509 Certificate A.4. Example CAB Baseline RSA HTTPS X.509 Certificate
The tools.ietf.org HTTPS server replies with a certificate message The tools.ietf.org HTTPS server replies with a certificate message
with 4 certificates. The DER encoding of the first certificate is with 4 certificates. The DER encoding of the first certificate is
1647 bytes. 1647 bytes.
30 82 06 6b 30 82 05 53 a0 03 02 01 02 02 09 00 a6 a5 5c 87 0e 39 b4 30 82 06 6b 30 82 05 53 a0 03 02 01 02 02 09 00 a6 a5 5c 87 0e 39 b4
0e 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 81 c6 31 0b 30 09 0e 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 81 c6 31 0b 30 09
06 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 55 04 08 13 07 41 72 69 06 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 55 04 08 13 07 41 72 69
skipping to change at page 38, line 28 skipping to change at page 40, line 39
69 cc 79 37 ce e3 97 f7 dc f3 95 88 ed 81 03 29 00 d2 a2 c7 ba ab d6 69 cc 79 37 ce e3 97 f7 dc f3 95 88 ed 81 03 29 00 d2 a2 c7 ba ab d6
3a 8e ca 09 0b d9 fb 39 26 4b ff 03 d8 8e 2d 3f 6b 21 ca 8a 7d d8 5f 3a 8e ca 09 0b d9 fb 39 26 4b ff 03 d8 8e 2d 3f 6b 21 ca 8a 7d d8 5f
fb 94 ba 83 de 9c fc 15 8d 61 fa 67 2d b0 c7 db 3d 25 0a 41 4a 85 d3 fb 94 ba 83 de 9c fc 15 8d 61 fa 67 2d b0 c7 db 3d 25 0a 41 4a 85 d3
7f 49 46 37 3c f4 b1 75 d0 52 f3 dd c7 66 f1 4b fd aa 00 ed bf e4 7e 7f 49 46 37 3c f4 b1 75 d0 52 f3 dd c7 66 f1 4b fd aa 00 ed bf e4 7e
ed 01 ec 7b e4 f6 46 fc 31 fd 72 fe 03 d2 f2 65 af 4d 7e e2 81 9b 7a ed 01 ec 7b e4 f6 46 fc 31 fd 72 fe 03 d2 f2 65 af 4d 7e e2 81 9b 7a
fd 30 3c f5 52 f4 05 34 a0 8a 3e 19 41 58 c8 a8 e0 51 71 84 09 15 ae fd 30 3c f5 52 f4 05 34 a0 8a 3e 19 41 58 c8 a8 e0 51 71 84 09 15 ae
ec a5 77 75 fa 18 f7 d5 77 d5 31 cc c7 2d ec a5 77 75 fa 18 f7 d5 77 d5 31 cc c7 2d
A.4.1. Example C509 Certificate Encoding A.4.1. Example C509 Certificate Encoding
The CBOR encoding of the first X.509 certificate is shown below in The CBOR encoding (~C509Certificate) of the first X.509 certificate
CBOR diagnostic format. is shown below in CBOR diagnostic format.
/This defines a CBOR Sequence (RFC 8742):/ /This defines a CBOR Sequence (RFC 8742):/
1, 1,
h'A6A55C870E39B40E', h'A6A55C870E39B40E',
[ [
-4, "US", -4, "US",
-6, "Arizona", -6, "Arizona",
-5, "Scottsdale", -5, "Scottsdale",
-8, "Starfield Technologies, Inc.", -8, "Starfield Technologies, Inc.",
skipping to change at page 39, line 11 skipping to change at page 41, line 22
0, 0,
h'B1E137E8EB82D689FADBF5C24B77F02C4ADE726E3E1360D1A8661EC4AD3D3260 h'B1E137E8EB82D689FADBF5C24B77F02C4ADE726E3E1360D1A8661EC4AD3D3260
E5F099B5F47A7A485521EE0E3912F9CE0DCAF56961C704ED6E0F1D3B1E508879 E5F099B5F47A7A485521EE0E3912F9CE0DCAF56961C704ED6E0F1D3B1E508879
3A0E314116F1B1026468A5CDF54A0ACA99963508C37E275DD0A9CFF3E728AF37 3A0E314116F1B1026468A5CDF54A0ACA99963508C37E275DD0A9CFF3E728AF37
D8B67BDDF37EAE6E977FF7CA694ECCD006DF5D279B3B12E7E6FE086B527B8211 D8B67BDDF37EAE6E977FF7CA694ECCD006DF5D279B3B12E7E6FE086B527B8211
7C72B346EBC1E878B80FCBE1EBBD064458DC8350B2A0625BDC81B836E39E7C79 7C72B346EBC1E878B80FCBE1EBBD064458DC8350B2A0625BDC81B836E39E7C79
B2A9538AE00BC94A2A13393113BD2CCFA870CF8C8D3D01A388AE1200361D1E24 B2A9538AE00BC94A2A13393113BD2CCFA870CF8C8D3D01A388AE1200361D1E24
2BDD79D8530126ED284FC98694834EC8E1142E85B3AFD46EDD6946AF41250E7A 2BDD79D8530126ED284FC98694834EC8E1142E85B3AFD46EDD6946AF41250E7A
AD8BF292CA79D97B324FF777E8F9B44F235CD45C03AED8AB3ACA135F5D5D5DA1', AD8BF292CA79D97B324FF777E8F9B44F235CD45C03AED8AB3ACA135F5D5D5DA1',
[ [
-3, -2, -4, -2,
7, [ 1, 2 ], 8, [ 1, 2 ],
-1, 5, -2, 5,
4, "http://crl.starfieldtech.com/sfig2s1-242.crl", 5, "http://crl.starfieldtech.com/sfig2s1-242.crl",
5, [ h'6086480186fd6e01071701', 6, [ h'6086480186fd6e01071701',
"http://certificates.starfieldtech.com/repository/", 1 ], "http://certificates.starfieldtech.com/repository/", 1 ],
8, [ 1, "http://ocsp.starfieldtech.com/", 9, [ 1, "http://ocsp.starfieldtech.com/",
2, "http://certificates.starfieldtech.com/repository/sfig2.crt" ], 2, "http://certificates.starfieldtech.com/repository/sfig2.crt" ],
6, h'254581685026383D3B2D2CBECD6AD9B63DB36663', 7, h'254581685026383D3B2D2CBECD6AD9B63DB36663',
2, [ 2, "*.tools.ietf.org", 2, "tools.ietf.org" ], 3, [ 2, "*.tools.ietf.org", 2, "tools.ietf.org" ],
0, h'AD8AB41C0751D7928907B0B784622F36557A5F4D', 1, h'AD8AB41C0751D7928907B0B784622F36557A5F4D',
9, [ 10, [
h'F65C942FD1773022145418083094568EE34D131933BFDF0C2F200BCC4EF164E3', h'F65C942FD1773022145418083094568EE34D131933BFDF0C2F200BCC4EF164E3',
1715, 1715,
1, 0,
h'8CF54852CE5635433911CF10CDB91F52B33639223AD138A41DECA6FEDE1FE90F h'8CF54852CE5635433911CF10CDB91F52B33639223AD138A41DECA6FEDE1FE90F
BCA2254366C19A2691C47A00B5B653ABBD44C2F8BAAEF4D2DAF2527CE6454995', BCA2254366C19A2691C47A00B5B653ABBD44C2F8BAAEF4D2DAF2527CE6454995',
h'5CDC4392FEE6AB4544B15E9AD456E61037FBD5FA47DCA17394B25EE6F6C70ECA', h'5CDC4392FEE6AB4544B15E9AD456E61037FBD5FA47DCA17394B25EE6F6C70ECA',
2012, 2012,
1, 0,
h'A5E0906E63E91D4FDDEFFF0352B91E50896007564B448A3828F596DC6B28726D h'A5E0906E63E91D4FDDEFFF0352B91E50896007564B448A3828F596DC6B28726D
FC91EAED02168866054EE18A2E5346C4CC51FEB3FA10A91D2EDBF99125F86CE6' FC91EAED02168866054EE18A2E5346C4CC51FEB3FA10A91D2EDBF99125F86CE6'
] ]
], ],
23, 23,
h'14043FA0BED2EE3FA86E3A1F788EA04C35530F11061FFF60A16D0B83E9D92ADB h'14043FA0BED2EE3FA86E3A1F788EA04C35530F11061FFF60A16D0B83E9D92ADB
B33F9DB3D7E0594C19A8E419A50CA770727763D5FE64510AD27AD650A58A9238 B33F9DB3D7E0594C19A8E419A50CA770727763D5FE64510AD27AD650A58A9238
ECCB2F0F5AC064584D5C06B9736368278B8934DC79C71D3AFD345F8314415849 ECCB2F0F5AC064584D5C06B9736368278B8934DC79C71D3AFD345F8314415849
80682980398A867269CC7937CEE397F7DCF39588ED81032900D2A2C7BAABD63A 80682980398A867269CC7937CEE397F7DCF39588ED81032900D2A2C7BAABD63A
8ECA090BD9FB39264BFF03D88E2D3F6B21CA8A7DD85FFB94BA83DE9CFC158D61 8ECA090BD9FB39264BFF03D88E2D3F6B21CA8A7DD85FFB94BA83DE9CFC158D61
 End of changes. 96 change blocks. 
344 lines changed or deleted 448 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/