< draft-raza-ace-cbor-certificates-01.txt   draft-raza-ace-cbor-certificates-02.txt >
ACE Working Group S. Raza ACE 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: September 12, 2019 G. Selander Expires: December 26, 2019 G. Selander
J. Mattsson J. Mattsson
Ericsson AB Ericsson AB
M. Furuhed M. Furuhed
Nexus Group Nexus Group
March 11, 2019 June 24, 2019
CBOR Profile of X.509 Certificates CBOR Profile of X.509 Certificates
draft-raza-ace-cbor-certificates-01 draft-raza-ace-cbor-certificates-02
Abstract Abstract
This document specifies a CBOR encoding and profiling of X.509 public This document specifies a CBOR encoding and profiling of X.509 public
key certificate suitable for Internet of Things (IoT) deployments. key certificate suitable for Internet of Things (IoT) deployments.
The full X.509 public key certificate format and commonly used ASN.1 The full X.509 public key certificate format and commonly used ASN.1
encoding is overly verbose for constrained IoT environments. encoding is overly verbose for constrained IoT environments.
Profiling together with CBOR encoding reduces the certificate size Profiling together with CBOR encoding reduces the certificate size
significantly with associated known performance benefits. significantly with associated known performance benefits.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 September 12, 2019. This Internet-Draft will expire on December 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. X.509 Certificate Profile . . . . . . . . . . . . . . . . . . 4 2. X.509 Certificate Profile . . . . . . . . . . . . . . . . . . 4
3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 6 4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 6
5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 7 5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 7
6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 7 6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. CBOR Certificate, CDDL . . . . . . . . . . . . . . . 10 Appendix A. CBOR Certificate, CDDL . . . . . . . . . . . . . . . 10
Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 10 Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 10
Appendix C. Certificate Example . . . . . . . . . . . . . . . . 11 Appendix C. Certificate Example . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 encoding of (PKI) for the Internet of Things (IoT) is the size and encoding of
X.509 public key certificates, since those are not optimized for X.509 public key certificates, since those are not optimized for
constrained environments [RFC7228]. More compact certificate constrained environments [RFC7228]. More compact certificate
representations are desirable. Due to the current PKI usage of X.509 representations are desirable. Due to the current PKI usage of X.509
certificates, keeping X.509 compatibility is necessary at least for a certificates, keeping X.509 compatibility is necessary at least for a
transition period. However, the use of a more compact encoding with transition period. However, the use of a more compact encoding with
the Concise Binary Object Representation (CBOR) the Concise Binary Object Representation (CBOR)
[I-D.ietf-cbor-7049bis] reduces the certificate size significantly [I-D.ietf-cbor-7049bis] reduces the certificate size significantly
which has known performance benefits in terms of decreased which has known performance benefits in terms of decreased
communication overhead, power consumption, latency, storage, etc. communication overhead, power consumption, latency, 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) [I-D.ietf-cbor-cddl] provides a way to express Language (CDDL) [RFC8610] provides a way to express structures for
structures for protocol messages and APIs that use CBOR. protocol messages and APIs that use CBOR. [RFC8610] also extends the
[I-D.ietf-cbor-cddl] 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 and text strings (tstr), CBOR also supports arrays of data items and
maps of pairs of data items. For a complete specification and maps of pairs of data items. For a complete specification and
examples, see [I-D.ietf-cbor-7049bis] and [I-D.ietf-cbor-cddl]. examples, see [I-D.ietf-cbor-7049bis] and [RFC8610].
This document specifies the CBOR certificate profile, which is a CBOR This document specifies the CBOR certificate profile, which is a CBOR
based encoding and compression of the X.509 certificate format. The based encoding and compression of the X.509 certificate format. The
profile is based on previous work on profiling of X.509 certificates profile is based on previous work on profiling of X.509 certificates
for Internet of Things deployments [X.509-IoT] which retains for Internet of Things deployments [X.509-IoT] which retains
backwards compatibility with X.509, and can be applied for backwards compatibility with X.509, and can be applied for
lightweight certificate based authentication with e.g. DTLS lightweight certificate based authentication with e.g. DTLS
[RFC6347] or EDHOC [I-D.selander-ace-cose-ecdhe]. The same profile [RFC6347] or EDHOC [I-D.selander-ace-cose-ecdhe]. The same profile
can be used for "native" CBOR encoded certificates, which further can be used for "native" CBOR encoded certificates, which further
optimizes the performance in constrained environments but are not optimizes the performance in constrained environments but are not
skipping to change at page 4, line 27 skipping to change at page 4, line 27
since 2008. With the introduction of certificate extensions new since 2008. With the introduction of certificate extensions new
certificate fields can be added without breaking the format, certificate fields can be added without breaking the format,
making version changes less likely. Therefore this profile fixes making version changes less likely. Therefore this profile fixes
the version number to 3. the version number to 3.
o Serial number. The serial number together with the identity of o Serial number. The serial number together with the identity of
the CA is the unique identifier of a certificate. The serial the CA is the unique identifier of a certificate. The serial
number MUST be an unsigned integer. number MUST be an unsigned integer.
o Signature algorithm. For the CBOR profile, the signature o Signature algorithm. For the CBOR profile, the signature
algorithm is fixed to ECDSA with SHA256. algorithm is by default assumed to be ECDSA with SHA256.
o Issuer. Used to identify the issuing CA through a sequence of o Issuer. Used to identify the issuing CA through a sequence of
name-value pairs. This profile is restricting this to one pair, name-value pairs. This profile is restricting this to one pair,
common name and associated string value. The common name MUST common name and associated string value. The common name MUST
uniquely identify the CA. Other fields MUST NOT be used. uniquely identify the CA. Other fields MUST NOT be used.
o Validity. The following representation MUST be used: UTCTime- o Validity. The following representation MUST be used: UTCTime-
format, YYMMDDhhmmss. This is the most compact format allowed by format, YYMMDDhhmmss. This is the most compact format allowed by
the X.509 standard. the X.509 standard.
o Subject. The subject section has the same format as the issuer, o Subject. The subject section has the same format as the issuer,
identifying the receiver of the public key through a sequence of identifying the receiver of the public key through a sequence of
name-value pairs. This sequence is in the profile restricted to a name-value pairs. This sequence is in the profile restricted to a
single pair, subject name and associated (unique) value. For an single pair, subject name and associated (unique) value. For an
IoT-device, the MAC-derived EUI-64 serves this purpose well. IoT-device, the MAC-derived EUI-64 serves this purpose well.
o Subject public key info. For the IoT devices, elliptic curve o Subject public key info. For the IoT devices, elliptic curve
cryptography based algorithms have clear advantages. For the IoT cryptography based algorithms have clear advantages. For the IoT
profile the public key algorithm is fixed to prime256v1. profile the public key algorithm is by default assumed to be
prime256v1.
o Issuer Unique ID and Subject Unique ID. These fields are optional o Issuer Unique ID and Subject Unique ID. These fields are optional
in X.509 and MUST NOT be used with the CBOR profile. in X.509 and MUST NOT be used with the CBOR profile.
o Extensions. Extensions consist of three parts; an OID, a boolean o Extensions. Extensions consist of three parts; an OID, a boolean
telling if it is critical or not, and the value. To maintain telling if it is critical or not, and the value. To maintain
forward compatibility, the CBOR profile does not restrict the use forward compatibility, the CBOR profile does not restrict the use
of extensions. By the X.509-standard, any device must be able to of extensions. By the X.509-standard, any device must be able to
process eight extensions types. Since only four of them are process eight extensions types. Since only four of them are
critical for IoT, this profile is making the other four optional. critical for IoT, this profile is making the other four optional.
skipping to change at page 5, line 19 skipping to change at page 5, line 22
* Key Usage * Key Usage
* Subject Alternative Name * Subject Alternative Name
* Basic Constraints * Basic Constraints
* Extended Key Usage * Extended Key Usage
o Certificate signature algorithm. This field duplicates the info o Certificate signature algorithm. This field duplicates the info
present in the signature algorithm field. Fixed to ECDSA with present in the signature algorithm field. By default assumed to
SHA256. be ECDSA with SHA256.
o Certificate Signature. The field corresponds to the signature o Certificate Signature. The field corresponds to the signature
done by the CA private key. For the CBOR profile, this is done by the CA private key. For the CBOR profile, this is
restricted to ECDSA type signatures with a signature length of 64 restricted to ECDSA type signatures with a signature length of 64
bits. bits.
3. CBOR Encoding 3. CBOR Encoding
This section specifies the CBOR certificates, which are the result of This section specifies the CBOR certificates, which are the result of
the CBOR encoding and lossless compression of the X.509 certificate the CBOR encoding and lossless compression of the X.509 certificate
skipping to change at page 5, line 47 skipping to change at page 5, line 50
encodings and associated savings are listed below. Combining these encodings and associated savings are listed below. Combining these
different components reduces the certificate size significantly, see different components reduces the certificate size significantly, see
Figure 1. Figure 1.
o Version number. The version number field is omitted in the o Version number. The version number field is omitted in the
encoding. This saves 5 bytes. encoding. This saves 5 bytes.
o Serial number. The serial number is encoded as an unsigned o Serial number. The serial number is encoded as an unsigned
integer. Encoding overhead is reduced by one byte. integer. Encoding overhead is reduced by one byte.
o Signature algorithm. The signature algorithm is known from the o Signature algorithm. If the signature algorithm is the default it
profile and is omitted in the ecoding. This saves 12 bytes. is omitted in the encoding, otherwise encoded as a one byte COSE
identifier. This saves 11 or 12 bytes.
o Issuer. Since the profile only allows the common name type, the o Issuer. Since the profile only allows the common name type, the
common name type specifier is omitted. In total, the issuer field common name type specifier is omitted. In total, the issuer field
encoding overhead goes from 13 bytes to one byte. encoding overhead goes from 13 bytes to one byte.
o Validity. The time is encoded as UnixTime in integer format. The o Validity. The time is encoded as UnixTime in integer format. The
validity is represented as a 'not before'-'not after' pair of validity is represented as a 'not before'-'not after' pair of
integer. This reduces the size from 32 to 11 bytes. integer. This reduces the size from 32 to 11 bytes.
o Subject. An IoT subject is identified by a EUI-64, in turn based o Subject. An IoT subject is identified by a EUI-64, in turn based
on a 48bit unique MAC id. This is encoded using only 7 bytes on a 48bit unique MAC id. This is encoded using only 7 bytes
using CBOR. This is a reduction down from 36 bytes for the using CBOR. This is a reduction down from 36 bytes for the
corresponding ASN.1 encoding. corresponding ASN.1 encoding.
o Subject public key info. The algorithm identifier is known from o Subject public key info. If the algorithm identifier is the
the profile restrictions and is omitted. One of the public key default, it is omitted, otherwise encoded as a one byte COSE
identifier. For the allowed ECC type keys, one of the public key
ECC curve point elements can be calculated from the other, hence ECC curve point elements can be calculated from the other, hence
only one of the curve points is needed (point compression, see only one of the curve points is needed (point compression, see
[PointCompression]). These actions together reduce size from 91 [PointCompression]). These actions together, for the default
to 35 bytes. algorithm, reduce size from 91 to 35 bytes.
o Extensions. Minor savings are achieved by the compact CBOR o Extensions. Minor savings are achieved by the compact CBOR
encoding. In addition, the relevant X.509 extension OIDs always encoding. In addition, the relevant X.509 extension OIDs always
start with 0x551D, hence these two bytes can be omitted. start with 0x551D, hence these two bytes can be omitted.
o Certificate signature algorithm. The signature algorithm is known o Certificate signature algorithm. This algorithm field is always
from the profile and is omitted in the ecoding. the same as the above signature algorithm, and is omitted in the
encoding.
o Signature. Since the signature algorithm and resulting signature o Signature. Since the signature algorithm and resulting signature
length are known, padding and extra length fields which are length are known, padding and extra length fields which are
present in the ASN.1 encoding are omitted. The overhead for present in the ASN.1 encoding are omitted. The overhead for
encoding the 64-bit signature value is reduced from 11 to 2 bytes. encoding the 64-bit signature value is reduced from 11 to 2 bytes.
4. Deployment settings 4. Deployment settings
CBOR certificates can be deployed with legacy X.509 certificates and CBOR certificates can be deployed with legacy X.509 certificates and
CA infrastructure. In order to verify the signature, the CBOR CA infrastructure. In order to verify the signature, the CBOR
skipping to change at page 7, line 15 skipping to change at page 7, line 16
reduced communication overhead. reduced communication overhead.
For the setting with constrained server and server-only For the setting with constrained server and server-only
authentication, the server only needs to be provisioned with the CBOR authentication, the server only needs to be provisioned with the CBOR
certificate and does not perform the conversion to X.509. This certificate and does not perform the conversion to X.509. This
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 DTLS v1.3, because certificates are encrypted, the proposed For DTLS v1.3, because certificates are encrypted, the proposed
encoding needs to be done fully end-to-end, through adding the encoding needs to be done fully end-to-end, through adding the
endcoding/decoding functionality to the server. A new certificate encoding/decoding functionality to the server. A new certificate
format or new certificate compression scheme needs to be added. format or new certificate compression scheme needs to be added.
While that requires changes on the server side, we believe it to be While that requires changes on the server side, we believe it to be
in line with other proposals utilizing cbor encoding for in line with other proposals utilizing cbor encoding for
communication with resource constrained devices. communication with resource constrained devices.
5. Expected Certificate Sizes 5. Expected Certificate Sizes
The profiling size saving mainly comes from enforcing removal of The profiling size saving mainly comes from enforcing removal of
issuer and subject info fields besides the common name. The encoding issuer and subject info fields besides the common name. The encoding
savings are presented above in Section 3, for a sample certificate savings are presented above in Section 3, for a sample certificate
given in Appendix C resulting in the numbers shown in Figure 1. given in Appendix C resulting in the numbers shown in Figure 1.
+---------------------------------------------------+ After profiling, all duplicated information has been removed, and
| | X.509 Profiled | CBOR Encoded | remaining text strings are minimal in size. Therefore no further
+---------------------------------------------------+ size reduction can be reached with general compression mechanisms.
| Certificate Size | 342 | 164 | (In practice the size might even grow slightly due to the compression
+---------------------------------------------------+ encoding information, as illustrated in the table below.)
+---------------------------------------------------+
| | X.509 Profiled | CBOR Encoded |
+---------------------------------------------------+
| Certificate Size | 313 | 144 |
+---------------------------------------------------+
+-----------------------------------------------------------------+
| | X.509 Profiled | CBOR Encoded | Zlib |
+-----------------------------------------------------------------+
| Certificate Size | 313 | 144 | 319 |
+-----------------------------------------------------------------+
Figure 1: Comparing Sizes of Certificates (bytes) Figure 1: Comparing Sizes of Certificates (bytes)
6. Native CBOR Certificates 6. Native CBOR Certificates
Further performance improvements can be achieved with the use of Further performance improvements can be achieved with the use of
native CBOR certificates. In this case the signature is calculated native CBOR certificates. In this case the signature is calculated
over the CBOR encoded structure rather than the ASN.1 encoded over the CBOR encoded structure rather than the ASN.1 encoded
structure. This removes entirely the need for ASN.1 and reduces the structure. This removes entirely the need for ASN.1 and reduces the
processing in the authenticating devices. processing in the authenticating devices.
skipping to change at page 8, line 33 skipping to change at page 8, line 48
information compared to X.509. information compared to X.509.
Because of difference in size, it will be possible to detect that Because of difference in size, it will be possible to detect that
this profile is used. this profile is used.
The gateway solution described in Section 4 requires unencrypted The gateway solution described in Section 4 requires unencrypted
certificates. certificates.
9. IANA Considerations 9. IANA Considerations
None. This document registers a compression algorithm in the registry
entitled "Certificate Compression Algorithm IDs", under the
"Transport Layer Security (TLS) Extensions" heading (see
[I-D.ietf-tls-certificate-compression]).
+------------------+--------------------------+
| Algorithm Number | Description |
+------------------+--------------------------+
| TBD | cbor-iot |
+------------------+--------------------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-cbor-7049bis] [I-D.ietf-cbor-7049bis]
Bormann, C. and P. Hoffman, "Concise Binary Object Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", draft-ietf-cbor-7049bis-05 (work Representation (CBOR)", draft-ietf-cbor-7049bis-05 (work
in progress), January 2019. in progress), January 2019.
[I-D.ietf-cbor-cddl] [I-D.ietf-tls-certificate-compression]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Ghedini, A. and V. Vasiliev, "TLS Certificate
definition language (CDDL): a notational convention to Compression", draft-ietf-tls-certificate-compression-05
express CBOR and JSON data structures", draft-ietf-cbor- (work in progress), April 2019.
cddl-07 (work in progress), February 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
10.2. Informative References 10.2. Informative References
[I-D.selander-ace-cose-ecdhe] [I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-12 (work in progress), February 2019. cose-ecdhe-13 (work in progress), March 2019.
[PointCompression] [PointCompression]
Miller, V., "Use of Elliptic Curves in Cryptography.", Miller, V., "Use of Elliptic Curves in Cryptography.",
Springer, Cham. Lecture Notes of the Institute for Springer, Cham. Lecture Notes of the Institute for
Computer Sciences, Social Informatics and Computer Sciences, Social Informatics and
Telecommunications Engineering, vol 218., 1986, Telecommunications Engineering, vol 218., 1986,
<https://doi.org/10.1007/3-540-39799-X_31>. <https://doi.org/10.1007/3-540-39799-X_31>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
skipping to change at page 10, line 15 skipping to change at page 10, line 38
Appendix A. CBOR Certificate, CDDL Appendix A. CBOR Certificate, CDDL
certificate = [ certificate = [
serial_number : uint, serial_number : uint,
issuer : text, issuer : text,
validity : [notBefore: int, notAfter: int], validity : [notBefore: int, notAfter: int],
subject : text / bytes subject : text / bytes
public_key : bytes public_key : bytes
? extensions : [+ extension], ? extensions : [+ extension],
signature : bytes signature : bytes
? signature_alg + public_key_info : bytes
] ]
extension = [ extension = [
oid : int, oid : int,
? critical : bool, ? critical : bool,
value : bytes value : bytes
] ]
Appendix B. X.509 Certificate Profile, ASN.1 Appendix B. X.509 Certificate Profile, ASN.1
 End of changes. 23 change blocks. 
38 lines changed or deleted 69 lines changed or added

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