Internet-Draft W. Ford Intended status: Standards Track TrustPoint Innovation Technologies Expires: September 2015 Y. Poeluev TrustPoint Innovation Technologies March 23, 2015 The Machine-to-Machine (M2M) Public Key Certificate Format draft-ford-m2mcertificate-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 23, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ford & Poeluev Expires September 23, 2015 [Page 1] Internet-Draft The M2M Public Key Certificate Format March 2015 Abstract The X.509 public key certificate format is overly verbose for Internet-of-Things (IoT) constrained environments, where nodes with limited memory and networks with limited bandwidth are not uncommon. The Machine-to-Machine (M2M) certificate format is a pruned down and encoding-optimized replacement for X.509, which reuses much of the X.509 semantics but reduces certificate sizes by typically 40%. We are proposing that IETF recognize the M2M format as an optional replacement for X.509 in Internet applications including, but not limited to, TLS and DTLS. Table of Contents 1. Introduction...................................................2 2. Restrictions Applied to the X.509 Model........................3 3. Other Optimizations............................................4 4. Certificate Size Estimates.....................................4 5. Certificate Format.............................................5 6. Rules for Omitting Algorithm Fields............................8 6.1. Algorithm Fields in CA Certificates.......................9 6.2. Algorithm Fields in End Entity Certificates...............9 7. Security Considerations........................................9 8. IANA Considerations............................................9 9. Conclusions....................................................9 10. References...................................................10 10.1. Normative References....................................10 10.2. Informative References..................................10 11. Acknowledgments..............................................10 Appendix A. Certificate Field Size Breakdown Tables..............11 A.1. EE Small Case............................................11 A.2. EE Medium Case...........................................12 A.3. CA Certificate Case......................................13 1. Introduction The predominant public key certificate format has for many years been the X.509 format [RFC5280]. X.509 was designed to be extremely flexible and open-ended, in an environment of RSA and DSA signature technologies. X.509 is not, however, a good certificate format for Internet-of-Things constrained environments, where nodes with limited memory and networks with limited bandwidth are not uncommon. With RSA and DSA technologies, overheads in the certificate format were comparatively inconsequential because the large key and signature fields were the dominant certificate components size-wise. However, with the much more efficient ECC technology used today, the certificate format overheads become a very important factor in making Ford & Poeluev Expires September 23, 2015 [Page 2] Internet-Draft The M2M Public Key Certificate Format March 2015 certificates efficient enough for low bandwidth constrained applications. In essence, the X.509 certificate format is too verbose for these applications. There is a clear need for a more efficient certificate format than X.509. Because many fields are inherently variable-length, it still makes sense to use ASN.1 notation and encoding for this new format, allowing us to borrow heavily from the X.509 model and to reuse much of the X.509 semantics and some software. The Machine-to-Machine (M2M) certificate format was designed to satisfy the above objectives. What was done was to strip down the X.509 format to eliminate features that are not needed today, while optimizing the encoding. The result is a certificate format that typically reduces certificate size by about 40% compared with X.509. The M2M format supports various digital signature technologies including ECDSA, RSA, and Elliptic Curve Qu-Vanstone (ECQV) [SEC4]. No particular technology is required by this specification and we use ECDSA as the baseline for comparative certificate size calculations. The M2M certificate format has been adopted by the NFC Forum for Near Field Communications signatures, and published by that organization [NFC-SIG]. However it is a general purpose design which is equally applicable to Internet-of-Things applications. We are proposing that IETF recognize the M2M format as an optional replacement for X.509 in Internet applications including, but not limited to, TLS and DTLS. A companion Internet-Draft addresses the use of the M2M format with TLS and DTLS [TLS-M2M]. 2. Restrictions Applied to the X.509 Model The M2M certificate model restricts the X.509 model as follows: o Directory Name (DN) names are limited to using the RFC 5280 mandatory attributes plus other attributes in common use, namely: country, organization, organizational unit, distinguished name qualifier, state or province name, common name, serial number, locality, domain component. There can be only one of each, no more than 4 total, and no multi-level names. M2M has also added an Object Identifier (OID) option (may prove a useful identifier for CAs) and an OCTET STRING option (may prove an efficient option for device identifiers). o DN character encodings are limited to one string type, usually UTF8String (which a profile might limit to IA5 characters). Ford & Poeluev Expires September 23, 2015 [Page 3] Internet-Draft The M2M Public Key Certificate Format March 2015 o Modest length constraints are defined for all DN attributes. o Criticality flags for extensions are eliminated (criticality may be implied by semantics). o The following built-in extensions are defined for end-entity certificates: issuer key id, subject key id, key usage (first 7 bits only), certificate policies (one OID, no qualifiers), subject alternative name, issuer alternative name, extended key usage (one OID), authority information access (URI for OCSP responder only). o The following additional built-in extension is defined for CA- certificates: basic constraints o While it is not anticipated that applications will require extensions other than the built-in extensions noted above, there is a catch-all to optionally permit any standard X.509 extension from RFC 5280 to be included. 3. Other Optimizations An optional optimization known as "parameter inheritance" is also provided. For applications where a certificate is always accompanied in its transmission by its superior certificate, we can eliminate the issuer field from the transmitted form of the certificate (it is still included for signature generation and verification purposes). Issuer name can be inherited from the subject field of the superior certificate. Therefore, this field is made optional in the syntax in order to allow two variants of every certificate: the full (to-be- signed) form and the transmitted form. In addition the M2M format adopts from SEC4 MES the use of Unix time (rather than ASN.1 time types) to represent validity period. It also drops the redundant algorithm identifier from the certificate outer structure and makes sundry miscellaneous optimizations. 4. Certificate Size Estimates Below are exemplary certificate size estimates for each of the formats M2M and X.509 (we include SEC4 MES for the one case where it applies). All sizes are for 224-bit ECC. We have used the following example cases (note EE=end-entity certificate): o EE Small case: ECDSA minimal data, one-component 8-character names and 7-bit key usage extension. Ford & Poeluev Expires September 23, 2015 [Page 4] Internet-Draft The M2M Public Key Certificate Format March 2015 o EE Medium case: ECDSA more general example, with two-component 16- character names and these extensions: 7-bit key usage, certificate policy OID, 20-character OCSP URL, 10-character subject alternate name. o CA Certificate case: A certificate for an ECDSA Sub-CA ECDSA- signed by a root CA. Two-component 16-character names and extensions: 7-bit key usage, basic constraints, 20-character OCSP URL. +-------------+-----------+----------+----------+ | | M2M with | M2M | X.509 | | | parameter | | | | |inheritance| | | +-------------+-----------+----------+----------+ |EE Small | 136 | 155 | 241 | |EE Medium | 189 | 218 | 364 | |CA Cert | N/A | 207 | 338 | +-------------+-----------+----------+----------+ Figure 1 Certificate Sizes in Bytes In summary, a standalone M2M EE certificate is roughly 140-to-220 bytes (compare 240-to-360 for X.509) and a two-certificate ECDSA chain is roughly 340-to-420 bytes (compare 570-to-690 for X.509). We assume Algorithm OIDs of the form 1.3.11111.1.1 (5 octets value field) with no algorithm parameters and certificate serial numbers of 8 octets. For more detail of the calculations leading to the above size comparisons see Appendix A. 5. Certificate Format The M2M certificate format is defined using Abstract Syntax Notation One (ASN.1) [X.680]. -- Machine-to-Machine certificate format -- M2M-Certificate-Definition {1 3 186 asn1-modules (5) m2m-certificate (0)} -- Structure MUST be DER encoded DEFINITIONS AUTOMATIC TAGS ::= BEGIN Ford & Poeluev Expires September 23, 2015 [Page 5] Internet-Draft The M2M Public Key Certificate Format March 2015 Certificate ::= [APPLICATION 20] IMPLICIT SEQUENCE { tbsCertificate TBSCertificate, -- To be signed certificate cACalcValue OCTET STRING -- Contains signature for a signed -- certificate or public key derivation value -- for an ECQV certificate } -- The APPLICATION 20 tag is intended to make the M2M format -- apparent by inspecting the first byte of the encoding TBSCertificate ::= SEQUENCE { version INTEGER {v1(0) } DEFAULT v1, serialNumber OCTET STRING (SIZE (1..20)), cAAlgorithm OBJECT IDENTIFIER OPTIONAL, -- Identifies CA -- algorithm, hash function & optionally -- other required parameters (e.g., for ECC the -- curve). -- Required for signature verification but may -- be omitted from the transmitted cert and -- filled in from the pKAlgorithm of the -- superior cert (provided not root cert) -- prior to signature verification cAAlgParams OCTET STRING OPTIONAL, -- Identifies CA algorithm parameters. -- This specification does not provide for -- omitting this field in transmission and -- subsequently replacing it from the superior -- certificate for signature verification issuer Name OPTIONAL, -- Required for signature -- verification but may be omitted from the -- transmitted cert and filled in from the -- subject field of the superior cert (provided -- not root cert) prior to signature verification validFrom OCTET STRING (SIZE (4..5)) OPTIONAL, -- Unix time. If omitted no validity specified validDuration OCTET STRING (SIZE (1..4)) OPTIONAL, -- # of seconds. If omitted no expiry specified subject Name, pKAlgorithm OBJECT IDENTIFIER OPTIONAL, -- Default is same as cAAlgorithm in this -- certificate Ford & Poeluev Expires September 23, 2015 [Page 6] Internet-Draft The M2M Public Key Certificate Format March 2015 pKAlgParams OCTET STRING OPTIONAL, pubKey OCTET STRING OPTIONAL, -- Omit for an ECQV cert authKeyId AuthKeyId OPTIONAL, subjKeyId OCTET STRING OPTIONAL, keyUsage OCTET STRING (SIZE (1)) OPTIONAL, -- Critical -- One byte containing a bit string, as described below. basicConstraints INTEGER (0..7) OPTIONAL, -- If absent this -- is an end-entity cert; max intermed path length for CA cert certificatePolicy OBJECT IDENTIFIER OPTIONAL, subjectAltName GeneralName OPTIONAL, issuerAltName GeneralName OPTIONAL, extendedKeyUsage OBJECT IDENTIFIER OPTIONAL, authInfoAccessOCSP IA5String OPTIONAL, -- OCSP responder URI cRLDistribPointURI IA5String OPTIONAL, -- CRL distribution point URI x509extensions X509Extensions OPTIONAL, ... } Name ::= SEQUENCE SIZE (1..4) OF AttributeValue AttributeValue ::= CHOICE { country PrintableString (SIZE (2)), organization UTF8String (SIZE (1..32)), organizationalUnit UTF8String (SIZE (1..32)), distinguishedNameQualifier PrintableString (SIZE (1..32)), stateOrProvince UTF8String (SIZE (1..4)), locality UTF8String (SIZE (1..32)), commonName UTF8String (SIZE (1..32)), serialNumber PrintableString (SIZE (1..32)), domainComponent IA5String (SIZE (1..32)), registeredId OBJECT IDENTIFIER, octetsName OCTET STRING (SIZE (1..8)) } AuthKeyId ::= SEQUENCE { keyIdentifier OCTET STRING OPTIONAL, authCertIssuer GeneralName OPTIONAL, authCertSerialNum OCTET STRING (SIZE(1..20)) OPTIONAL } X509Extensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE { Ford & Poeluev Expires September 23, 2015 [Page 7] Internet-Draft The M2M Public Key Certificate Format March 2015 extnID OBJECT IDENTIFIER, criticality BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } GeneralName ::= CHOICE { rfc822Name IA5String (SIZE (1..128)), dNSName IA5String (SIZE (1..128)), directoryName Name, uniformResourceIdentifier IA5String (SIZE (1..128)), iPAddress OCTET STRING (SIZE (1..16)), --4 octets for IPV4, 16 octets for IPV6 registeredID OBJECT IDENTIFIER } -- Notes: -- * The times are represented using Unix time, i.e. # of seconds -- since the Unix epoch: http://en.wikipedia.org/wiki/Unix_time -- The validFrom field permits 40-bit values to avoid problems in -- 2038 (when 32-bit values won't be enough). -- -- The keyUsage field conveys a single octet equal to the -- second octet of the DER encoding of the following BIT STRING -- KeyUsage ::= BIT STRING { -- digitalSignature (0), -- nonRepudiation (1), -- keyEncipherment (2), -- dataEncipherment (3), -- keyAgreement (4), -- keyCertSign (5), -- Use keyCertSign also for an ECQV certificate issuer -- cRLSign (6) -- the last bit in the byte is always zero (7) END 6. Rules for Omitting Algorithm Fields Following are the rules defining when and how omitting algorithm fields is allowed. Ford & Poeluev Expires September 23, 2015 [Page 8] Internet-Draft The M2M Public Key Certificate Format March 2015 6.1. Algorithm Fields in CA Certificates cAAlgorithm: Omitting is only allowed when pKAlgorithm (or cAAlgorithm if pKAlgorithm is omitted in a superior certificate) of a superior certificate fully specifies the signature algorithm and its parameters (i.e. signature and hash algorithms plus any required parameters, e.g. in the case of ECC, the curve). pKAlgorithm: If omitted in a CA certificate, cAAlgorithm specifies the signature and hash algorithms and any required parameters (e.g. curve) for pubKey Algorithm fields in End Entity Certificates. 6.2. Algorithm Fields in End Entity Certificates cAAlgorithm: Omitting is only allowed when pKAlgorithm (or cAAlgorithm if pKAlgorithm is omitted in a superior certificate) of a superior certificate fully specifies the signature algorithm and its parameters (i.e. signature and hash algorithms plus any required parameters, e,g, in the case of ECC, the curve). pKAlgorithm: If omitted in an end entity certificate, cAAlgorithm specifies the required parameters (e.g. curve and optionally signature & hash algorithms) for pubKey. 7. Security Considerations The M2M Certificate Format is believed by the authors to have the same security characteristics as the X.509 certificate format. 8. IANA Considerations None known. 9. Conclusions The IETF and applicable Working Groups are encouraged to adopt the M2M certificate format as an optional alternative to the X.509 format in all applications in the Internet-of-Things space. There are significant size and bandwidth savings and no significant loss of features of practical importance. Ford & Poeluev Expires September 23, 2015 [Page 9] Internet-Draft The M2M Public Key Certificate Format March 2015 10. References 10.1. Normative References [RFC5280] Cooper, D., et al, "Internet Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [SEC4] Standards for Efficient Cryptography Group (SECG), SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificates, January 2013. [NFC-SIG] NFC Forum, Signature Record Type Definition, Technical Specification, V2.0, 2014. http://nfc-forum.org/our- work/specifications-and-application- documents/specifications/nfc-forum-technical- specifications/ [X.690] ITU-T Recommendation X.690: ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 2002. 10.2. Informative References [TLS-M2M] Poeluev, Y., et al, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authentication Using M2M Certificates", draft-ypoeluev-tls-m2m-certs- 00.txt (work in progress), February 2015. 11. Acknowledgments Recognition is due to Rob Lambert and Jeremy Rowley for their critical reviews of the specification, and to the development team of TrustPoint Innovation Technologies for proving the specification works in practical implementations. This document was prepared using 2-Word-v2.0.template.dot. Ford & Poeluev Expires September 23, 2015 [Page 10] Internet-Draft The M2M Public Key Certificate Format March 2015 Appendix A. Certificate Field Size Breakdown Tables This Appendix lists the certificate field sizes used in arriving at the certificate sizes in Figure 1. Use this to check our numbers and also to see where M2M saves the bytes. A.1. EE Small Case +------------------------+-----------+----------+----------+ | | M2M with | M2M | X.509 | | | parameter | | | | |inheritance| | | +------------------------+-----------+----------+----------+ |Basic envelope | 4 | 4 | 4 | |Outside algorithm id | 0 | 0 | 9 | |Outside algorithm params| 0 | 0 | 0 | |Signature/CA calc value | 65 | 65 | 66 | |Version | 0 | 0 | 5 | |Serial number | 10 | 10 | 10 | |Inside algorithm id | 0 | 7 | 9 | |Algorithm parameters | 0 | 0 | 0 | |Issuer | 0 | 12 | 23 | |Validity | 11 | 11 | 32 | |Subject | 12 | 12 | 23 | |Subject algorithm | 0 | 0 | 11 | |Subject parameters | 0 | 0 | 0 | |Subject public key | 31 | 31 | 32 | |Extensions envelope | 0 | 0 | 4 | |Key usage 7-bit extn | 3 | 3 | 13 | |Basic constraints extn | 0 | 0 | 0 | |Cert policies extn | 0 | 0 | 0 | |OCSP URL extn 20-char | 0 | 0 | 0 | |Subject alt name 10-char| 0 | 0 | 0 | |TOTAL | 136 | 155 | 241 | +------------------------+-----------+----------+----------+ Figure 2 EE Small Case Field Sizes in Bytes Ford & Poeluev Expires September 23, 2015 [Page 11] Internet-Draft The M2M Public Key Certificate Format March 2015 A.2. EE Medium Case +------------------------+-----------+----------+----------+ | | M2M with | M2M | X.509 | | | parameter | | | | |inheritance| | | +------------------------+-----------+----------+----------+ |Basic envelope | 4 | 4 | 4 | |Outside algorithm id | 0 | 0 | 9 | |Outside algorithm params| 0 | 0 | 0 | |Signature/CA calc value | 65 | 65 | 66 | |Version | 0 | 0 | 5 | |Serial number | 10 | 10 | 10 | |Inside algorithm id | 0 | 7 | 9 | |Algorithm parameters | 0 | 0 | 0 | |Issuer | 0 | 22 | 42 | |Validity | 11 | 11 | 32 | |Subject | 22 | 22 | 42 | |Subject algorithm | 0 | 0 | 11 | |Subject parameters | 0 | 0 | 0 | |Subject public key | 31 | 31 | 32 | |Extensions envelope | 0 | 0 | 4 | |Key usage 7-bit extn | 3 | 3 | 13 | |Basic constraints extn | 0 | 0 | 0 | |Cert policies extn | 7 | 7 | 20 | |OCSP URL extn 20-char | 22 | 22 | 42 | |Subject alt name 10-char| 14 | 14 | 23 | |TOTAL | 189 | 218 | 364 | +------------------------+-----------+----------+----------+ Figure 3 EE Medium Case Field Sizes in Bytes Ford & Poeluev Expires September 23, 2015 [Page 12] Internet-Draft The M2M Public Key Certificate Format March 2015 A.3. CA Certificate Case +------------------------+-----------+----------+----------+ | | M2M with | M2M | X.509 | | | parameter | | | | |inheritance| | | +------------------------+-----------+----------+----------+ |Basic envelope | N/A | 4 | 4 | |Outside algorithm id | | 0 | 9 | |Outside algorithm params| | 0 | 0 | |Signature/CA calc value | | 65 | 66 | |Version | | 0 | 5 | |Serial number | | 10 | 10 | |Inside algorithm id | | 7 | 9 | |Algorithm parameters | | 0 | 0 | |Issuer | | 22 | 42 | |Validity | | 11 | 32 | |Subject | | 22 | 42 | |Subject algorithm | | 7 | 11 | |Subject parameters | | 0 | 0 | |Subject public key | | 31 | 32 | |Extensions envelope | | 0 | 4 | |Key usage 7-bit extn | | 3 | 13 | |Basic constraints extn | | 3 | 17 | |Cert policies extn | | 0 | 0 | |OCSP URL extn 20-char | | 22 | 42 | |Subject alt name 10-char| | 0 | 0 | |TOTAL | | 207 | 338 | +------------------------+-----------+----------+----------+ Figure 4 CA Certificate Case Field Sizes in Bytes Authors' Addresses Warwick Ford TrustPoint Innovation Technologies, Ltd. 700 S Monarch St Unit 203, Aspen, CO 81611 Email: wford@wyltan.com Ford & Poeluev Expires September 23, 2015 [Page 13] Internet-Draft The M2M Public Key Certificate Format March 2015 Yuri Poeluev TrustPoint Innovation Technologies, Ltd. 450 Phillip St., Suite 101 Waterloo, ON, Canada, N2L 5J2 Email: ypoeluev@trustpointinnovation.com Ford & Poeluev Expires September 23, 2015 [Page 14]