Internet DRAFT - draft-ford-m2mcertificate

draft-ford-m2mcertificate



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]