M2M public key certificate

In public-key cryptography, a public-key certificate is a data structure that delivers a public key to a user. An explicit certificate contains a copy of the public key and identification data and a digital signature over those fields signed by a trusted third party. An implicit certificate is a variant of a public key certificate that has no copy of the public key or digital signature but has a field that allows the public key to be securely reconstructed.

The main standard for explicit certificates is X.509 as defined in IETF RFC 5280. It is a very broad standard but the certificate encoding overhead can be a burden, especially when used with short-field cryptographic algorithms, notably elliptic curve cryptography (ECC).

The Machine-to-Machine (M2M) certificate format is an alternative format to X.509 which is better suited for machine-to-machine applications that are bandwidth restricted or employ devices with limited memory and use ECC.  An M2M certificate is significantly smaller than the equivalent X.509 certificate and can represent both explicit and implicit certificates.

The M2M certificate format is used by near field communication and is specified in the NFC Forum Signature Record Type Definition using ASN.1 notation. However, this certificate format is not limited to NFC but is a general purpose structure which can be used as a replacement for X.509 in any application that employs public key cryptography.  It supports various cryptographic algorithms including ECDSA, RSA and Elliptic Curve Qu-Vanstone (ECQV).

The M2M format is being standardized in the Standards for Efficient Cryptography Group (SECG). The specification is in the document SEC4 Draft Version 1.2. 

An Open Source Java Implementation is available from TrustPoint Innovation.

Restrictions on X.509 certificate model

The M2M certificate model is essentially a subset of X.509 which requires many fewer bytes than X.509 but also has the flexibility to include commonly used fields and other optional fields that applications might likely require. With the M2M format the X.509 model is restricted (or subsetted) as follows:

1. Certificate issuer and certificate subject names are encoded in X.509 using a very complex structure called Directory Name (DN). M2M uses only a subset of the DN model requiring a name to comprise a sequence of up to four (attribute, value) pairs.  The attributes available are:  country, organization, organizational unit, distinguished name, qualifier, state or province name, common name, serial number, locality, and domain component, plus two new options that are particularly useful for M2M applications: an Object Identifier (OID) option and an OCTET STRING option.
2. The value field of each name attribute is encoded in one fixed data type, usually the ASN.1 UTF8String type.  Each attribute also defines a (modest) maximum length for its values.
3. Criticality flags for extensions are eliminated.  Criticality may be implied by the semantics of the particular extension.
4. The following built-in extensions are defined for end-entity certificates:  issuer key id, subject key id, key usage (first seven bits only), certificate policies (one OID, no qualifiers), subject  alternative name, issuer alternative name, extended key usage (one OID), authority information access (URI for Online Certificate Status Protocol OCSP responder).
5. The following additional built-in extension is defined for certification authority (CA) certificates: basic constraints
6. 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.

Other size reductions

An optional feature called parameter inheritance is also provided.  For applications where a certificate is always accompanied in its transmission by its superior certificate, the issuer field can be eliminated 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 the use of Unix time (rather than ASN.1 time types) to represent validity period.  It also makes sundry miscellaneous size reductions, including dropping the redundant algorithm identifier from the X.509 certificate outer structure.

Certificate size examples

Some examples of size reductions in certificates for M2M compared with X.509 were presented by Ford and Poeluev at the 2015 NIST Workshop on Elliptic Curve Cryptography Standards and published in the proceedings of that workshop.  The comparisons used various example certificates considered typical for M2M applications.  They assumed 224-bit elliptic curve cryptography and both ECDSA and ECQV were considered.

The results calculated a standalone M2M ECDSA end entity certificate to be roughly 140-to-220 bytes (compare 240-to-360 bytes for X.509) and a two-certificate ECDSA chain to be roughly 340-to-420 bytes (compare 570-to-690 bytes for X.509). This indicates that an M2M ECDSA certificate is roughly 40% smaller than the equivalent X.509 certificate.

A standalone M2M ECQV end entity certificate is roughly 70-to-150 bytes (compare 170-to-300 bytes for X.509) and a two-certificate ECQV chain is roughly 200-to-290 bytes (compare 450-to-570 bytes for X.509).  This indicates that an M2M ECQV certificate is roughly 50% smaller than the equivalent X.509 certificate.