draft-ietf-cose-cbor-encoded-cert-02.txt   draft-ietf-cose-cbor-encoded-cert-03.txt 
Network Working Group J. Preuss Mattsson Network Working Group J. Preuß Mattsson
Internet-Draft G. Selander Internet-Draft G. Selander
Intended status: Standards Track Ericsson AB Intended status: Standards Track Ericsson AB
Expires: January 13, 2022 S. Raza Expires: 14 July 2022 S. Raza
J. Hoeglund J. Höglund
RISE AB RISE AB
M. Furuhed M. Furuhed
Nexus Group Nexus Group
July 12, 2021 10 January 2022
CBOR Encoded X.509 Certificates (C509 Certificates) CBOR Encoded X.509 Certificates (C509 Certificates)
draft-ietf-cose-cbor-encoded-cert-02 draft-ietf-cose-cbor-encoded-cert-03
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 all certificates encoding supports a large subset of RFC 5280 and all certificates
compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
eUICC, and CA/Browser Forum Baseline Requirements profiles. When eUICC, and CA/Browser Forum Baseline Requirements profiles. When
used to re-encode DER encoded X.509 certificates, the CBOR encoding used to re-encode DER encoded X.509 certificates, the CBOR encoding
can in many cases reduce the size of RFC 7925 profiled certificates can in many cases reduce the size of RFC 7925 profiled certificates
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 13, 2022. This Internet-Draft will expire on 14 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised 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. C509 Certificate . . . . . . . . . . . . . . . . . . . . . . 5 3. C509 Certificate . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5
3.2. Encoding of subjectPublicKey and issuerSignatureValue . . 8 3.2. Encoding of subjectPublicKey and issuerSignatureValue . . 9
3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9 3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9
4. C509 Certificate Signing Request . . . . . . . . . . . . . . 14 4. C509 Certificate Signing Request . . . . . . . . . . . . . . 14
5. C509 Certificate Revocation List . . . . . . . . . . . . . . 15 5. C509 Certificate Revocation List . . . . . . . . . . . . . . 15
6. C509 Online Certificate Status Protocol . . . . . . . . . . . 16 6. C509 Online Certificate Status Protocol . . . . . . . . . . . 16
7. C509 Processing and Certificate Issuance . . . . . . . . . . 16 7. C509 Processing and Certificate Issuance . . . . . . . . . . 16
8. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 17 8. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 17
9. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 17 9. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. C509 Certificate Types Registry . . . . . . . . . . . . 19 11.1. C509 Certificate Types Registry . . . . . . . . . . . . 19
11.2. C509 Attributes Registry . . . . . . . . . . . . . . . . 20 11.2. C509 Attributes Registry . . . . . . . . . . . . . . . . 20
11.3. C509 Extensions Registry . . . . . . . . . . . . . . . . 23 11.3. C509 Extensions Registry . . . . . . . . . . . . . . . . 23
11.4. C509 Certificate Policies Registry . . . . . . . . . . . 26 11.4. C509 Certificate Policies Registry . . . . . . . . . . . 27
11.5. C509 Policies Qualifiers Registry . . . . . . . . . . . 29 11.5. C509 Policies Qualifiers Registry . . . . . . . . . . . 29
11.6. C509 Information Access Registry . . . . . . . . . . . . 29 11.6. C509 Information Access Registry . . . . . . . . . . . . 30
11.7. C509 Extended Key Usages Registry . . . . . . . . . . . 32 11.7. C509 Extended Key Usages Registry . . . . . . . . . . . 32
11.8. C509 General Names Registry . . . . . . . . . . . . . . 33 11.8. C509 General Names Registry . . . . . . . . . . . . . . 33
11.9. C509 Signature Algorithms Registry . . . . . . . . . . . 35 11.9. C509 Signature Algorithms Registry . . . . . . . . . . . 35
11.10. C509 Public Key Algorithms Registry . . . . . . . . . . 38 11.10. C509 Public Key Algorithms Registry . . . . . . . . . . 38
11.11. COSE Header Parameters Registry . . . . . . . . . . . . 41 11.11. COSE Header Parameters Registry . . . . . . . . . . . . 41
11.12. TLS Certificate Types Registry . . . . . . . . . . . . . 42 11.12. TLS Certificate Types Registry . . . . . . . . . . . . . 42
11.13. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 43 11.13. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example C509 Certificates . . . . . . . . . . . . . 47 Appendix A. Example C509 Certificates . . . . . . . . . . . . . 47
A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 47 A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 47
A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 50 A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 50
A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 50 A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 50
A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 54 A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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
skipping to change at page 5, line 42 skipping to change at page 5, line 45
SEQUENCE or SET in the DER encoding. SEQUENCE or SET in the DER encoding.
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 * version. The 'version' field is encoded in the
'c509CertificateType' CBOR int. The field 'c509CertificateType' '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
(c509CertificateType = 0) or a CBOR re-encoded X.509 v3 DER (c509CertificateType = 0) or a CBOR re-encoded X.509 v3 DER
certificate (c509CertificateType = 1), see Section 11.1. certificate (c509CertificateType = 1), see Section 11.1.
o serialNumber. The 'serialNumber' INTEGER value field is encoded * 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 * 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 * 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 7) encodes the attribute type and the sign is used to Figure 7) 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. The Attribute Email Address is negative for PrintableString. The Attribute Email Address is
always an IA5String. In natively signed C509 certificates all always an IA5String. In natively signed C509 certificates all
skipping to change at page 6, line 36 skipping to change at page 6, line 39
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
string contains an EUI-64 of the form "HH-HH-HH-HH-HH-HH-HH-HH" string contains an EUI-64 of the form "HH-HH-HH-HH-HH-HH-HH-HH"
where 'H' is one of the symbols '0'-'9' or 'A'-'F' it is encoded where 'H' is one of the symbols '0'-'9' or 'A'-'F' it is encoded
as a CBOR byte string of length 8 instead. EUI-64 mapped from a as a CBOR byte string of length 8 instead. EUI-64 mapped from a
48-bit MAC address (i.e., of the form "HH-HH-HH-FF-FE-HH-HH-HH) is 48-bit MAC address (i.e., of the form "HH-HH-HH-FF-FE-HH-HH-HH) is
encoded as a CBOR byte string of length 6. encoded as a CBOR byte string of length 6.
o validity. The 'notBefore' and 'notAfter' fields are encoded as * validity. The 'notBefore' and 'notAfter' fields are encoded as
unwrapped CBOR epoch-based date/time (~time) where the tag content unwrapped CBOR epoch-based date/time (~time) where the tag content
is an unsigned integer. In POSIX time, leap seconds are ignored, is an unsigned integer. In POSIX time, leap seconds are ignored,
with a leap second having the same POSIX time as the second before with a leap second having the same POSIX time as the second before
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. * subject. The 'subject' is encoded exactly like issuer.
o subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including * subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including
parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm' parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm'
(see Section 11.10) or as an array with an unwrapped CBOR OID tag (see Section 11.10) or as an array with an unwrapped CBOR OID tag
[I-D.ietf-cbor-tags-oid] optionally followed by the parameters [RFC9090] optionally followed by the parameters encoded as a CBOR
encoded as a CBOR byte string. In general, the 'subjectPublicKey' byte string. In general, the 'subjectPublicKey' BIT STRING value
BIT STRING value field is encoded as a CBOR byte string. This field is encoded as a CBOR byte string. This specification
specification assumes the BIT STRING has zero unused bits and the assumes the BIT STRING has zero unused bits and the unused bits
unused bits byte is omitted. For rsaEncryption and id- byte is omitted. For rsaEncryption and id-ecPublicKey, the
ecPublicKey, the encoding of subjectPublicKey is further optimized encoding of subjectPublicKey is further optimized as described in
as described in Section 3.2. Section 3.2.
o issuerUniqueID. Not supported. * issuerUniqueID. Not supported.
o subjectUniqueID. Not supported. * subjectUniqueID. Not supported.
o extensions. The 'extensions' field is encoded as a CBOR array * extensions. The 'extensions' field is encoded as a CBOR array
where each extension is encoded as either a CBOR int (see where each extension is encoded as either a CBOR int (see
Section 11.3) followed by an optional CBOR item of any type or an Section 11.3) followed by an optional CBOR item of any type or an
unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid] followed by a CBOR unwrapped CBOR OID tag [RFC9090] followed by a CBOR bool encoding
bool encoding 'critical' and the DER encoded value of the 'critical' and the DER encoded value of the 'extnValue' encoded as
'extnValue' encoded as a CBOR byte string. If the array contains a CBOR byte string. If the array contains exactly two ints and
exactly two ints and the absolute value of the first int is 2 the absolute value of the first int is 2 (corresponding to
(corresponding to keyUsage), the array is omitted and the keyUsage), the array is omitted and the extensions is encoded as a
extensions is encoded as a single CBOR int with the absolute value single CBOR int with the absolute value of the second int and the
of the second int and the sign of the first int. Extensions are sign of the first int. Extensions are encoded as specified in
encoded as specified in Section 3.3. The extensions mandated to Section 3.3. The extensions mandated to be supported by [RFC7925]
be supported by [RFC7925] and [IEEE-802.1AR] are given special and [IEEE-802.1AR] are given special treatment. An omitted
treatment. An omitted 'extensions' field is encoded as an empty 'extensions' field is encoded as an empty CBOR array.
CBOR array.
o signatureAlgorithm. The 'signatureAlgorithm' field including * signatureAlgorithm. The 'signatureAlgorithm' field including
parameters is encoded as a CBOR int (see Section 11.9) or as an parameters is encoded as a CBOR int (see Section 11.9) or as an
array with an unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid] array with an unwrapped CBOR OID tag [RFC9090] optionally followed
optionally followed by the parameters encoded as a CBOR byte by the parameters encoded as a CBOR byte string.
string.
o signatureValue. In general, the 'signatureValue' BIT STRING value * 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 The following Concise Data Definition Language (CDDL) defines the
CBOR array C509Certificate and the CBOR sequence [RFC8742] CBOR array C509Certificate and the CBOR sequence [RFC8742]
skipping to change at page 9, line 43 skipping to change at page 9, line 51
non-critical extensions are encoded with a positive sign. non-critical extensions are encoded with a positive sign.
The 'extnValue' OCTET STRING value field is encoded as the CBOR byte The 'extnValue' OCTET STRING value field is encoded as the CBOR byte
string 'extensionValue' except for the extensions specified below. string 'extensionValue' except for the extensions specified below.
For some extensions, only commonly used parts are supported by the For some extensions, only commonly used parts are supported by the
CBOR encoding. If unsupported parts are used, the CBOR encoding CBOR encoding. If unsupported parts are used, the CBOR encoding
cannot be used. cannot be used.
CBOR encoding of the following extension values are fully supported: CBOR encoding of the following extension values are fully supported:
o Subject Key Identifier (subjectKeyIdentifier). The extensionValue * Subject Key Identifier (subjectKeyIdentifier). The extensionValue
is encoded as follows: is encoded as follows:
KeyIdentifier = bytes KeyIdentifier = bytes
SubjectKeyIdentifier = KeyIdentifier SubjectKeyIdentifier = KeyIdentifier
o Key Usage (keyUsage). The 'KeyUsage' BIT STRING is interpreted as * Key Usage (keyUsage). The 'KeyUsage' BIT STRING is interpreted as
an unsigned integer in network byte order and encoded as a CBOR an unsigned integer in network byte order and encoded as a CBOR
int. See Section 3.1 for special encoding in case keyUsage is the int. See Section 3.1 for special encoding in case keyUsage is the
only extension present. only extension present.
KeyUsage = int KeyUsage = int
o Policy Mappings (policyMappings). extensionValue is encoded as * Policy Mappings (policyMappings). extensionValue is encoded as
follows: follows:
PolicyMappings = [ PolicyMappings = [
+ (issuerDomainPolicy: ~oid, subjectDomainPolicy: ~oid) + (issuerDomainPolicy: ~oid, subjectDomainPolicy: ~oid)
] ]
o Basic Constraints (basicConstraints). If 'cA' = false then * Basic Constraints (basicConstraints). If 'cA' = false then
extensionValue = -2, if 'cA' = true and 'pathLenConstraint' is not extensionValue = -2, if 'cA' = true and 'pathLenConstraint' is not
present then extensionValue = -1, and if 'cA' = true and present then extensionValue = -1, and if 'cA' = true and
'pathLenConstraint' is present then extensionValue = 'pathLenConstraint' is present then extensionValue =
pathLenConstraint. pathLenConstraint.
BasicConstraints = int BasicConstraints = int
o Policy Constraints (policyConstraints). extensionValue is encoded * Policy Constraints (policyConstraints). extensionValue is encoded
as follows: as follows:
PolicyConstraints = [ PolicyConstraints = [
requireExplicitPolicy: uint / null, requireExplicitPolicy: uint / null,
inhibitPolicyMapping: uint / null, inhibitPolicyMapping: uint / null,
] ]
o Extended Key Usage (extKeyUsage). extensionValue is encoded as an * Extended Key Usage (extKeyUsage). extensionValue is encoded as an
array of CBOR ints (see Section 11.7 or unwrapped CBOR OID tags array of CBOR ints (see Section 11.7 or unwrapped CBOR OID tags
[I-D.ietf-cbor-tags-oid] where each int or OID tag encodes a key [RFC9090] where each int or OID tag encodes a key usage purpose.
usage purpose. If the array contains a single KeyPurposeId, the If the array contains a single KeyPurposeId, the array is omitted.
array is omitted.
KeyPurposeId = int / ~oid KeyPurposeId = int / ~oid
ExtKeyUsageSyntax = [ 2* KeyPurposeId ] / KeyPurposeId ExtKeyUsageSyntax = [ 2* KeyPurposeId ] / KeyPurposeId
o Inhibit anyPolicy (inhibitAnyPolicy). extensionValue is encoded as * Inhibit anyPolicy (inhibitAnyPolicy). extensionValue is encoded as
follows: follows:
InhibitAnyPolicy = uint InhibitAnyPolicy = uint
CBOR encoding of the following extension values are partly supported: CBOR encoding of the following extension values are partly supported:
o Subject Alternative Name (subjectAltName). If the subject * Subject Alternative Name (subjectAltName). If the subject
alternative name only contains general names registered in alternative name only contains general names registered in
Section 11.8 the extension value can be CBOR encoded. Section 11.8 the extension value can be CBOR encoded.
extensionValue is encoded as an array of (int, any) pairs where extensionValue is encoded as an array of (int, any) pairs where
each pair encodes a general name (see Section 11.8). If each pair encodes a general name (see Section 11.8). If
subjectAltName contains exactly one dNSName, the array and the int subjectAltName contains exactly one dNSName, the array and the int
are omitted and extensionValue is the dNSName encoded as a CBOR are omitted and extensionValue is the dNSName encoded as a CBOR
text string. In addition to the general names defined in text string. In addition to the general names defined in
[RFC5280], the hardwareModuleName type of otherName has been given [RFC5280], the hardwareModuleName type of otherName has been given
its own int due to its mandatory use in IEEE 802.1AR. When its own int due to its mandatory use in IEEE 802.1AR. When
'otherName + hardwareModuleName' is used, then [ oid, bytes ] is 'otherName + hardwareModuleName' is used, then [ oid, bytes ] is
used to identify the pair ( hwType, hwSerialEntries ) directly as used to identify the pair ( hwType, hwSerialEntries ) directly as
specified in [RFC4108]. Only the general names in Section 11.8 specified in [RFC4108]. Only the general names in Section 11.8
are supported. are supported.
GeneralName = ( GeneralNameType : int, GeneralNameValue : any ) GeneralName = ( GeneralNameType : int, GeneralNameValue : any )
GeneralNames = [ + GeneralName ] GeneralNames = [ + GeneralName ]
SubjectAltName = GeneralNames / text SubjectAltName = GeneralNames / text
o Issuer Alternative Name (issuerAltName). extensionValue is encoded * Issuer Alternative Name (issuerAltName). extensionValue is encoded
exactly like subjectAltName. exactly like subjectAltName.
IssuerAltName = GeneralNames / text IssuerAltName = GeneralNames / text
o CRL Distribution Points (cRLDistributionPoints). If the CRL * CRL Distribution Points (cRLDistributionPoints). If the CRL
Distribution Points is a sequence of DistributionPointName, where Distribution Points is a sequence of DistributionPointName, where
each DistributionPointName only contains each DistributionPointName only contains
uniformResourceIdentifiers, the extension value can be CBOR uniformResourceIdentifiers, the extension value can be CBOR
encoded. extensionValue is encoded as follows: encoded. extensionValue is encoded as follows:
DistributionPointName = [ 2* text ] / text DistributionPointName = [ 2* text ] / text
CRLDistributionPoints = [ + DistributionPointName ] CRLDistributionPoints = [ + DistributionPointName ]
o Freshest CRL (freshestCRL). extensionValue is encoded exactly like * Freshest CRL (freshestCRL). extensionValue is encoded exactly like
cRLDistributionPoints. cRLDistributionPoints.
FreshestCRL = CRLDistributionPoints FreshestCRL = CRLDistributionPoints
o Authority Information Access (authorityInfoAccess). If all the * Authority Information Access (authorityInfoAccess). If all the
GeneralNames in authorityInfoAccess are of type GeneralNames in authorityInfoAccess are of type
uniformResourceIdentifier, the extension value can be CBOR uniformResourceIdentifier, the extension value can be CBOR
encoded. Each accessMethod is encoded as an CBOR ints (see encoded. Each accessMethod is encoded as an CBOR ints (see
Section 11.6) or unwrapped CBOR OID tags [I-D.ietf-cbor-tags-oid]. Section 11.6) or unwrapped CBOR OID tags [RFC9090]. The
The uniformResourceIdentifiers are encoded as CBOR text strings. uniformResourceIdentifiers are encoded as CBOR text strings.
AccessDescription = ( accessMethod: int / ~oid , uri: text ) AccessDescription = ( accessMethod: int / ~oid , uri: text )
AuthorityInfoAccessSyntax = [ + AccessDescription ] AuthorityInfoAccessSyntax = [ + AccessDescription ]
o Subject Information Access (subjectInfoAccess). Encoded exactly * Subject Information Access (subjectInfoAccess). Encoded exactly
like authorityInfoAccess. like authorityInfoAccess.
SubjectInfoAccessSyntax = AuthorityInfoAccessSyntax SubjectInfoAccessSyntax = AuthorityInfoAccessSyntax
o Authority Key Identifier (authorityKeyIdentifier). If the * Authority Key Identifier (authorityKeyIdentifier). If the
authority key identifier contains all of keyIdentifier, authority key identifier contains all of keyIdentifier,
certIssuer, and certSerialNumberm or if only keyIdentifier is certIssuer, and certSerialNumberm or if only keyIdentifier is
present the extension value can be CBOR encoded. If all three are present the extension value can be CBOR encoded. If all three are
present a CBOR array is used, if only keyIdentifier is present, present a CBOR array is used, if only keyIdentifier is present,
the array is omitted: the array is omitted:
KeyIdentifierArray = [ KeyIdentifierArray = [
keyIdentifier: KeyIdentifier, keyIdentifier: KeyIdentifier,
authorityCertIssuer: GeneralNames, authorityCertIssuer: GeneralNames,
authorityCertSerialNumber: CertificateSerialNumber authorityCertSerialNumber: CertificateSerialNumber
] ]
AuthorityKeyIdentifier = KeyIdentifierArray / KeyIdentifier AuthorityKeyIdentifier = KeyIdentifierArray / KeyIdentifier
o Certificate Policies (certificatePolicies). If noticeRef is not * Certificate Policies (certificatePolicies). If noticeRef is not
used and any explicitText are encoded as UTF8String, the extension used and any explicitText are encoded as UTF8String, the extension
value can be CBOR encoded. OIDs registered in Section 11.4 are value can be CBOR encoded. OIDs registered in Section 11.4 are
encoded as an int. The policyQualifierId is encoded as an CBOR encoded as an int. The policyQualifierId is encoded as an CBOR
int (see Section 11.5) or an unwrapped CBOR OID tag int (see Section 11.5) or an unwrapped CBOR OID tag [RFC9090].
[I-D.ietf-cbor-tags-oid].
PolicyIdentifier = int / ~oid PolicyIdentifier = int / ~oid
PolicyQualifierInfo = ( PolicyQualifierInfo = (
policyQualifierId: int / ~oid, policyQualifierId: int / ~oid,
qualifier: text, qualifier: text,
) )
CertificatePolicies = [ CertificatePolicies = [
+ ( PolicyIdentifier, ? [ + PolicyQualifierInfo ] ) + ( PolicyIdentifier, ? [ + PolicyQualifierInfo ] )
] ]
o Name Constraints (nameConstraints). If the name constraints only * Name Constraints (nameConstraints). If the name constraints only
contains general names registered in Section 11.8 the extension contains general names registered in Section 11.8 the extension
value can be CBOR encoded. value can be CBOR encoded.
GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ] GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ]
NameConstraints = [ NameConstraints = [
permittedSubtrees: GeneralSubtree, permittedSubtrees: GeneralSubtree,
excludedSubtrees: GeneralSubtree, excludedSubtrees: GeneralSubtree,
] ]
o Subject Directory Attributes (subjectDirectoryAttributes). * Subject Directory Attributes (subjectDirectoryAttributes).
Encoded as attributes in issuer and subject with the difference Encoded as attributes in issuer and subject with the difference
that there can be more than one attributeValue. that there can be more than one attributeValue.
Attributes = ( attributeType: int, attributeValue: [+text] ) // Attributes = ( attributeType: int, attributeValue: [+text] ) //
( attributeType: ~oid, attributeValue: [+bytes] ) ( attributeType: ~oid, attributeValue: [+bytes] )
SubjectDirectoryAttributes = Attributes SubjectDirectoryAttributes = Attributes
o AS Resources (autonomousSysIds). If rdi is not present, the * AS Resources (autonomousSysIds). If rdi is not present, the
extension value can be CBOR encoded. Each ASId is encoded as an extension value can be CBOR encoded. Each ASId is encoded as an
uint. With the exception of the first ASId, the ASid is encoded uint. With the exception of the first ASId, the ASid is encoded
as the difference to the previous ASid. as the difference to the previous ASid.
AsIdsOrRanges = uint / [uint, uint] AsIdsOrRanges = uint / [uint, uint]
ASIdentifiers = [ + AsIdsOrRanges ] / null ASIdentifiers = [ + AsIdsOrRanges ] / null
o AS Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like * AS Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like
autonomousSysIds. autonomousSysIds.
o IP Resources (id-pe-ipAddrBlocks). If rdi and SAFI is not * IP Resources (id-pe-ipAddrBlocks). If rdi and SAFI is not
present, the extension value can be CBOR encoded. Each present, the extension value can be CBOR encoded. Each
AddressPrefix is encoded as a CBOR bytes string (without the AddressPrefix is encoded as a CBOR bytes string (without the
unused bits octet) followed by the number of unused bits encoded unused bits octet) followed by the number of unused bits encoded
as a CBOR uint. Each AddressRange is encoded as an array of two as a CBOR uint. Each AddressRange is encoded as an array of two
CBOR byte strings. The unused bits for min and max are omitted, CBOR byte strings. The unused bits for min and max are omitted,
but the unused bits in max IPAddress is set to ones. With the but the unused bits in max IPAddress is set to ones. With the
exception of the first Address, if the byte string has the same exception of the first Address, if the byte string has the same
length as the previous ASid, the Addess is encoded as an uint with length as the previous ASid, the Addess is encoded as an uint with
the the difference to the previous Addess. the the difference to the previous Addess.
Address = bytes / uint, Address = bytes / uint,
AddressPrefix = (Address, unusedBits: uint) AddressPrefix = (Address, unusedBits: uint)
AddressRange = [Address, Address] AddressRange = [Address, Address]
IPAddressOrRange = AddressPrefix / AddressRange IPAddressOrRange = AddressPrefix / AddressRange
IPAddressChoice = [ + IPAddressOrRange ] / null IPAddressChoice = [ + IPAddressOrRange ] / null
IPAddrBlocks = [ AFI: uint, IPAddressChoice ] IPAddrBlocks = [ AFI: uint, IPAddressChoice ]
o IP Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like id- * IP Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like id-
pe-ipAddrBlocks. pe-ipAddrBlocks.
o Signed Certificate Timestamp. If all the SCTs are version 1, and * Signed Certificate Timestamp. If all the SCTs are version 1, and
there are no SCT extensions, the extension value can be CBOR there are no SCT extensions, the extension value can be CBOR
encoded. LogIDs are encoded as CBOR byte strings, the timestamp encoded. LogIDs are encoded as CBOR byte strings, the timestamp
is encoded as and CBOR int (milliseconds since validityNotBefore), is encoded as and CBOR int (milliseconds since validityNotBefore),
and the signature is encoded with an (AlgorithmIdentifier, any) and the signature is encoded with an (AlgorithmIdentifier, any)
pair in the same way as issuerSignatureAlgorithm and pair in the same way as issuerSignatureAlgorithm and
issuerSignatureValue. issuerSignatureValue.
SignedCerticateTimestamp = ( SignedCerticateTimestamp = (
logID: bytes, logID: bytes,
timestamp: int, timestamp: int,
sigAlg: AlgorithmIdentifier, sigAlg: AlgorithmIdentifier,
sigValue: any, sigValue: any,
) )
SignedCertificateTimestamps = [ + SignedCerticateTimestamp ] SignedCertificateTimestamps = [ + SignedCerticateTimestamp ]
3.3.1. Example Encoding of Extensions 3.3.1. Example Encoding of Extensions
The examples below use values from Section 11.3, Section 11.7, and The examples below use values from Section 11.3, Section 11.7, and
Section 11.8: Section 11.8:
o A critical basicConstraints ('cA' = true) without * A critical basicConstraints ('cA' = true) without
pathLenConstraint is encoded as the two CBOR ints -4, -1. pathLenConstraint is encoded as the two CBOR ints -4, -1.
o A non-critical keyUsage with digitalSignature and keyAgreement * 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- * A non-critical extKeyUsage containing id-kp-codeSigning and id-kp-
OCSPSigning is encoded as the CBOR int 8 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 * A non-critical subjectAltName containing only the dNSName
example.com is encoded as the CBOR int 3 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 [ -4, -1, 2, 17, 8, [ 3, 6 ], 3, "example.com" ]. array [ -4, -1, 2, 17, 8, [ 3, 6 ], 3, "example.com" ].
4. C509 Certificate Signing Request 4. C509 Certificate Signing Request
The section defines the C509 Certificate Signing Request (CSR) format The section defines the C509 Certificate Signing Request (CSR) format
skipping to change at page 18, line 17 skipping to change at page 18, line 21
+---------------------------------------+-----------+-----------+ +---------------------------------------+-----------+-----------+
| | COSE_X509 | COSE_C509 | | | COSE_X509 | COSE_C509 |
+---------------------------------------+-----------+-----------+ +---------------------------------------+-----------+-----------+
| RFC 7925 profiled IoT Certificate (1) | 317 | 139 | | RFC 7925 profiled IoT Certificate (1) | 317 | 139 |
+---------------------------------------+-----------+-----------+ +---------------------------------------+-----------+-----------+
| ECDSA HTTPS Certificate Chain (2) | 2193 | 1394 | | ECDSA HTTPS Certificate Chain (2) | 2193 | 1394 |
+---------------------------------------+-----------+-----------+ +---------------------------------------+-----------+-----------+
| RSA HTTPS Certificate Chain (4) | 5175 | 3934 | | RSA HTTPS Certificate Chain (4) | 5175 | 3934 |
+---------------------------------------+-----------+-----------+ +---------------------------------------+-----------+-----------+
Figure 4: Comparing Sizes of Certificate Chains in COSE. Number of Figure 4: Comparing Sizes of Certificate Chains in COSE. Number
bytes (length of certificate chain). of bytes (length of certificate chain).
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| | X509 | X509 + Brotli | C509 | C509 + Brotli | | | X509 | X509 + Brotli | C509 | C509 + Brotli |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| RFC 7925 Cert (1) | 327 | 324 | 151 | 167 | | RFC 7925 Cert (1) | 327 | 324 | 151 | 167 |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| RPKI Cert (1) | 20991 | 9134 | 8660 | 5668 | | RPKI Cert (1) | 20991 | 9134 | 8660 | 5668 |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| HTTPS Chain (2) | 2204 | 1455 | 1414 | 1063 | | HTTPS Chain (2) | 2204 | 1455 | 1414 | 1063 |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| HTTPS Chain (4) | 5190 | 3244 | 3958 | 2845 | | HTTPS Chain (4) | 5190 | 3244 | 3958 | 2845 |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
| HTTPS Bag (8) | 11578 | 3979 | 8882 | 3519 | | HTTPS Bag (8) | 11578 | 3979 | 8882 | 3519 |
+-------------------+-------+---------------+------+---------------+ +-------------------+-------+---------------+------+---------------+
Figure 5: Comparing Sizes of Certificate Chains with TLS. Number of Figure 5: Comparing Sizes of Certificate Chains with TLS. Number
bytes (length of certificate chain). X509 and C509 are Certificate of bytes (length of certificate chain). X509 and C509 are
messages. X509 + Brotli and C509 + Brotli are CompressedCertificate Certificate messages. X509 + Brotli and C509 + Brotli are
messages. CompressedCertificate messages.
10. Security Considerations 10. 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 19, line 49 skipping to change at page 20, line 4
all other values the registration procedure is "Expert Review". The all other values the registration procedure is "Expert Review". The
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 6: C509 Certificate Types
Figure 6: C509 Certificate Types
11.2. C509 Attributes Registry 11.2. C509 Attributes Registry
IANA has created a new registry titled "C509 Attributes" under the IANA has created a new registry titled "C509 Attributes" under the
new heading "CBOR Encoded X509 Certificates (C509 Certificates)". new heading "CBOR Encoded X509 Certificates (C509 Certificates)".
The columns of the registry are Value, Name, Identifiers, OID, DER, The columns of the registry are Value, Name, Identifiers, OID, DER,
Comments, and Reference, where Value is an non-negative integer, and Comments, and Reference, where Value is an non-negative integer, and
the other columns are text strings. For values in the interval [0, the other columns are text strings. For values in the interval [0,
23] the registration procedure is "IETF Review" and "Expert Review". 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".
skipping to change at page 31, line 51 skipping to change at page 31, line 51
| | DER: 06 08 2B 06 01 05 05 07 30 0B | | | DER: 06 08 2B 06 01 05 05 07 30 0B |
| | Comments: RFC 6487 | | | Comments: RFC 6487 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 13 | Name: RPKI Notify | | 13 | Name: RPKI Notify |
| | Identifiers: id-ad-rpkiNotify | | | Identifiers: id-ad-rpkiNotify |
| | OID: 1.3.6.1.5.5.7.48.13 | | | OID: 1.3.6.1.5.5.7.48.13 |
| | DER: 06 08 2B 06 01 05 05 07 30 0D | | | DER: 06 08 2B 06 01 05 05 07 30 0D |
| | Comments: RFC 8182 | | | Comments: RFC 8182 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 11: C509 Information Accesses Figure 11: C509 Information Accesses
11.7. C509 Extended Key Usages Registry 11.7. C509 Extended Key Usages Registry
IANA has created a new registry titled "C509 Extended Key Usages IANA has created a new registry titled "C509 Extended Key Usages
Registry" under the new heading "CBOR Encoded X509 Certificates (C509 Registry" under the new heading "CBOR Encoded X509 Certificates (C509
Certificates)". The columns of the registry are Value, Name, Certificates)". The columns of the registry are Value, Name,
Identifiers, OID, DER, Comments, and Reference, where Value is an Identifiers, OID, DER, Comments, 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
skipping to change at page 38, line 30 skipping to change at page 38, line 30
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 44 | Name: XMSS^MT | | 44 | Name: XMSS^MT |
| | Identifiers: id_alg_xmssmt | | | Identifiers: id_alg_xmssmt |
| | 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 14: C509 Signature Algorithms Figure 14: C509 Signature Algorithms
11.10. C509 Public Key Algorithms Registry 11.10. C509 Public Key Algorithms Registry
IANA has created a new registry titled "C509 Public Key Algorithms" IANA has created a new registry titled "C509 Public Key Algorithms"
under the new heading "CBOR Encoded X509 Certificates (C509 under the new heading "CBOR Encoded X509 Certificates (C509
Certificates)". The columns of the registry are Value, Name, Certificates)". The columns of the registry are Value, Name,
Identifiers, OID, Parameters, DER, Comments, and Reference, where Identifiers, OID, Parameters, 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". T The initial contents of the registry procedure is "Expert Review". T The initial contents of the registry
are: are:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | X.509 Public Key Algorithms | | Value | X.509 Public Key Algorithms |
+=======+===========================================================+ +=======+===========================================================+
| 0 | Name: RSA | | 0 | Name: RSA |
| | Identifiers: rsaEncryption | | | Identifiers: rsaEncryption |
| | OID: 1.2.840.113549.1.1.1 | | | OID: 1.2.840.113549.1.1.1 |
| | Parameters: NULL | | | Parameters: NULL |
| | DER: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 | | | DER: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 |
| | Comments: Compressed subjectPublicKey | | | Comments: Compressed subjectPublicKey |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | Name: EC Public Key (Weierstrass) with secp256r1 | | 1 | Name: EC Public Key (Weierstraß) with secp256r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = secp256r1 (1.2.840.10045.3.1.7) | | | Parameters: namedCurve = secp256r1 (1.2.840.10045.3.1.7) |
| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 | | | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 |
| | 48 CE 3D 03 01 07 | | | 48 CE 3D 03 01 07 |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
| | Also known as P-256, ansip256r1, prime256v1 | | | Also known as P-256, ansip256r1, prime256v1 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 2 | Name: EC Public Key (Weierstrass) with secp384r1 | | 2 | Name: EC Public Key (Weierstraß) with secp384r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = secp384r1 (1.3.132.0.34) | | | Parameters: namedCurve = secp384r1 (1.3.132.0.34) |
| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 | | | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |
| | 04 00 22 | | | 04 00 22 |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
| | Also known as P-384, ansip384r1 | | | Also known as P-384, ansip384r1 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 3 | Name: EC Public Key (Weierstrass) with secp521r1 | | 3 | Name: EC Public Key (Weierstraß) with secp521r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = secp521r1 (1.3.132.0.35) | | | Parameters: namedCurve = secp521r1 (1.3.132.0.35) |
| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 | | | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |
| | 04 00 23 | | | 04 00 23 |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
| | Also known as P-521, ansip521r1 | | | Also known as P-521, ansip521r1 |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 8 | Name: X25519 (Montgomery) | | 8 | Name: X25519 (Montgomery) |
| | Identifiers: id-X25519 | | | Identifiers: id-X25519 |
| | OID: 1.3.101.110 | | | OID: 1.3.101.110 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 05 06 03 2B 65 6E | | | DER: 30 05 06 03 2B 65 6E |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 9 | Name: X448 (Montgomery) | | 9 | Name: X448 (Montgomery) |
| | Identifiers: id-X448 | | | Identifiers: id-X448 |
| | OID: 1.3.101.111 | | | OID: 1.3.101.111 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 05 06 03 2B 65 6F | | | DER: 30 05 06 03 2B 65 6F |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 10 | Name: Ed25519 (Twisted Edwards) | | 10 | Name: Ed25519 (Twisted Edwards) |
| | Identifiers: id-Ed25519, id-EdDSA25519 | | | Identifiers: id-Ed25519, id-EdDSA25519 |
| | OID: 1.3.101.112 | | | OID: 1.3.101.112 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 05 06 03 2B 65 70 | | | DER: 30 05 06 03 2B 65 70 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 11 | Name: Ed448 (Edwards) | | 11 | Name: Ed448 (Edwards) |
| | Identifiers: id-Ed448, id-EdDSA448 | | | Identifiers: id-Ed448, id-EdDSA448 |
| | OID: 1.3.101.113 | | | OID: 1.3.101.113 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 05 06 03 2B 65 71 | | | DER: 30 05 06 03 2B 65 71 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 16 | Name: HSS / LMS | | 16 | Name: HSS / LMS |
| | Identifiers: id-alg-hss-lms-hashsig, id-alg-mts-hashsig | | | Identifiers: id-alg-hss-lms-hashsig, id-alg-mts-hashsig |
| | OID: 1.2.840.113549.1.9.16.3.17 | | | OID: 1.2.840.113549.1.9.16.3.17 |
| | Parameters: Absent | | | Parameters: Absent |
| | DER: 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 11 | | | DER: 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 11 |
| | Comments: | | | Comments: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 17 | Name: XMSS | | 17 | Name: XMSS |
| | Identifiers: id_alg_xmss | | | Identifiers: id_alg_xmss |
| | OID: 0.4.0.127.0.15.1.1.13.0 | | | OID: 0.4.0.127.0.15.1.1.13.0 |
| | Parameters: Absent | | | Parameters: Absent |
| | 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 |
| | Identifiers: id_alg_xmssmt | | | Identifiers: id_alg_xmssmt |
| | 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: |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 24 | Name: EC Public Key (Weierstrass) with | | 24 | Name: EC Public Key (Weierstraß) with |
| | brainpoolP256r1 | | | brainpoolP256r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = brainpoolP256r1 | | | Parameters: namedCurve = brainpoolP256r1 |
| | (1.3.36.3.3.2.8.1.1.7) | | | (1.3.36.3.3.2.8.1.1.7) |
| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 | | | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
| | 03 03 02 08 01 01 07 | | | 03 03 02 08 01 01 07 |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 25 | Name: EC Public Key (Weierstrass) with | | 25 | Name: EC Public Key (Weierstraß) with |
| | brainpoolP384r1 | | | brainpoolP384r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = brainpoolP384r1 | | | Parameters: namedCurve = brainpoolP384r1 |
| | (1.3.36.3.3.2.8.1.1.11) | | | (1.3.36.3.3.2.8.1.1.11) |
| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 | | | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
| | 03 03 02 08 01 01 0B | | | 03 03 02 08 01 01 0B |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 26 | Name: EC Public Key (Weierstrass) with | | 26 | Name: EC Public Key (Weierstraß) with |
| | brainpoolP512r1 | | | brainpoolP512r1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = brainpoolP512r1 | | | Parameters: namedCurve = brainpoolP512r1 |
| | (1.3.36.3.3.2.8.1.1.13) | | | (1.3.36.3.3.2.8.1.1.13) |
| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 | | | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
| | 03 03 02 08 01 01 0D | | | 03 03 02 08 01 01 0D |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 27 | Name: EC Public Key (Weierstrass) with | | 27 | Name: EC Public Key (Weierstraß) with |
| | FRP256v1 | | | FRP256v1 |
| | Identifiers: ecPublicKey, id-ecPublicKey | | | Identifiers: ecPublicKey, id-ecPublicKey |
| | OID: 1.2.840.10045.2.1 | | | OID: 1.2.840.10045.2.1 |
| | Parameters: namedCurve = FRP256v1 | | | Parameters: namedCurve = FRP256v1 |
| | (1.2.250.1.223.101.256.1) | | | (1.2.250.1.223.101.256.1) |
| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 0A 2A 81 | | | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 0A 2A 81 |
| | 7A 01 81 5F 65 82 00 01 | | | 7A 01 81 5F 65 82 00 01 |
| | Comments: Point compressed subjectPublicKey | | | Comments: Point compressed subjectPublicKey |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Figure 15: C509 Public Key Algorithms Figure 15: C509 Public Key Algorithms
11.11. COSE Header Parameters Registry 11.11. COSE Header Parameters Registry
EDITORS NOTE: The text should be moved a section and not be in the EDITORS NOTE: The text should 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
skipping to change at page 43, line 23 skipping to change at page 43, line 23
+======+============================================================+ +======+============================================================+
| TDB6 | Data Item: COSE_C509 | | 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 |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-cbor-tags-oid]
Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", draft-ietf-cbor-tags-oid-06
(work in progress), March 2021.
[I-D.ietf-cose-x509] [I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509 Header parameters for carrying and referencing X.509
certificates", draft-ietf-cose-x509-08 (work in progress), certificates", Work in Progress, Internet-Draft, draft-
December 2020. ietf-cose-x509-08, 14 December 2020,
<https://www.ietf.org/internet-drafts/draft-ietf-cose-
x509-08.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 44, line 34 skipping to change at page 44, line 28
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", RFC 9090,
DOI 10.17487/RFC9090, July 2021,
<https://www.rfc-editor.org/info/rfc9090>.
[SECG] "Elliptic Curve Cryptography, Standards for Efficient [SECG] "Elliptic Curve Cryptography, Standards for Efficient
Cryptography Group, ver. 2", 2009, Cryptography Group, ver. 2", 2009,
<https://secg.org/sec1-v2.pdf>. <https://secg.org/sec1-v2.pdf>.
12.2. Informative References 12.2. Informative References
[CAB-Code] [CAB-Code] 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 Code Signing Certificates Version 2.3"", May 2021, Trusted Code Signing Certificates Version 2.3"", May 2021,
<https://cabforum.org/baseline-requirements-code- <https://cabforum.org/baseline-requirements-code-
signing/>. signing/>.
[CAB-TLS] CA/Browser Forum, ., "CA/Browser Forum, "Baseline [CAB-TLS] 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.6"", June 2021, Trusted Certificates Version 1.7.6"", June 2021,
<https://cabforum.org/baseline-requirements-documents/>. <https://cabforum.org/baseline-requirements-documents/>.
[CborMe] Bormann, C., "CBOR Playground", May 2018, [CborMe] Bormann, C., "CBOR Playground", May 2018,
<http://cbor.me/>. <http://cbor.me/>.
[GSMA-eUICC] [GSMA-eUICC]
GSMA, ., "GSMA eUICC PKI Certificate Policy Version 2.1", GSMA, ., "GSMA eUICC PKI Certificate Policy Version 2.1",
February 2021, <https://www.gsma.com/esim/wp- February 2021, <https://www.gsma.com/esim/wp-
content/uploads/2021/02/SGP.14-v2.1.pdf>. content/uploads/2021/02/SGP.14-v2.1.pdf>.
[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
(EAP-TLS 1.3)", draft-ietf-emu-eap-tls13-18 (work in (EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft-
progress), July 2021. ietf-emu-eap-tls13-21, 20 October 2021,
<https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-
tls13-21.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-
November 2020. emu-eaptlscert-08, 20 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-emu-
eaptlscert-08.txt>.
[I-D.ietf-lake-edhoc] [I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini, Selander, G., Mattsson, J. P., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-ietf- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
lake-edhoc-06 (work in progress), April 2021. Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20
October 2021, <https://www.ietf.org/archive/id/draft-ietf-
lake-edhoc-12.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-tls-
2020. ctls-04, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-ctls-
04.txt>.
[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-43 (work in progress), April 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
2021. dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>.
[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", Work in Progress, Internet-Draft,
profile-01 (work in progress), February 2021. draft-ietf-uta-tls13-iot-profile-03, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-
profile-03.txt>.
[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
Secure Device Identity", IEEE Standard 802.1AR-2018 , networks–Secure Device Identity", IEEE Standard
August 2018, 802.1AR-2018 , August 2018,
<https://standards.ieee.org/standard/802_1AR-2018.html>. <https://standards.ieee.org/standard/802_1AR-2018.html>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
skipping to change at page 50, line 30 skipping to change at page 50, line 30
A.1.3. Example: Additonal Keys for the Example Certificates A.1.3. Example: Additonal Keys for the Example Certificates
Below are the issuer key pair and the subject private key belonging Below are the issuer key pair and the subject private key belonging
to the above example certificates. The private keys are encoded as to the above example certificates. The private keys are encoded as
in COSE [RFC8152]. These issuer key pair can be used to sign or in COSE [RFC8152]. These issuer key pair can be used to sign or
verify the example certificates and the subject private key allows verify the example certificates and the subject private key allows
the example certificates to be used in test vectors for other the example certificates to be used in test vectors for other
protocols like EDHOC. protocols like EDHOC.
issuerPublicKeyAlgorithm : issuerPublicKeyAlgorithm :
1 (EC Public Key (Weierstrass) with secp256r1) 1 (EC Public Key (Weierstraß) with secp256r1)
issuerPublicKey : issuerPublicKey :
h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E' h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E'
issuerPrivateKey : issuerPrivateKey :
h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2' h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2'
subjectPrivateKey : subjectPrivateKey :
h'D718111F3F9BD91B92FF6877F386BDBFCEA7154268FD7F2FB56EE17D99EA16D4' h'D718111F3F9BD91B92FF6877F386BDBFCEA7154268FD7F2FB56EE17D99EA16D4'
skipping to change at page 57, line 21 skipping to change at page 56, line 36
The authors want to thank Henk Birkholz, Carsten Bormann, Russ The authors want to thank Henk Birkholz, Carsten Bormann, Russ
Housley, Olle Johansson, Benjamin Kaduk, Ilari Liusvaara, Laurence Housley, Olle Johansson, Benjamin Kaduk, Ilari Liusvaara, Laurence
Lundblade, Francesca Palombinini, Thomas Peterson, Michael Lundblade, Francesca Palombinini, Thomas Peterson, Michael
Richardson, Maik Reichert, Stefan Santesson, Jim Schaad, Fraser Richardson, Maik Reichert, Stefan Santesson, Jim Schaad, Fraser
Tweedale, and Rene Struik for reviewing and commenting on Tweedale, and Rene Struik for reviewing and commenting on
intermediate versions of the draft and helping with GitHub. intermediate versions of the draft and helping with GitHub.
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuß Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Goeran Selander Göran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Shahid Raza Shahid Raza
RISE AB RISE AB
Email: shahid.raza@ri.se Email: shahid.raza@ri.se
Joel Höglund
Joel Hoeglund
RISE AB RISE AB
Email: joel.hoglund@ri.se Email: joel.hoglund@ri.se
Martin Furuhed Martin Furuhed
Nexus Group Nexus Group
Email: martin.furuhed@nexusgroup.com Email: martin.furuhed@nexusgroup.com
 End of changes. 76 change blocks. 
252 lines changed or deleted 257 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/