Network Working Group D. McGrew Internet-Draft M. Pritikin Intended status: Informational Cisco Systems Expires: November 12, 2010 May 11, 2010 The Compressed X.509 Certificate Format draft-pritikin-comp-x509-00 Abstract This note defines the Compressed X.509 Format (CXF), a compact format for X.509 certificates and CRLs, and a way to translate between the compact format and standard X.509 encoding. The translation consists of the lossless compression algorithm DEFLATE with a particular predefined dictionary. Protocol bindings for TLS and IKE are designated. This format is useful in a constrained environment, where bandwidth and/or storage is low, and it preserves interoperability with standards-compliant X.509 certificates and the systems for certificate processing, issuance, and management. Status of this Memo This Internet-Draft is submitted to IETF 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 November 12, 2010. Copyright Notice McGrew & Pritikin Expires November 12, 2010 [Page 1] Internet-Draft Compressed X.509 May 2010 Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. Compressed X.509 Format (CXF) . . . . . . . . . . . . . . . . 4 2.1. The CXF Dictionary . . . . . . . . . . . . . . . . . . . . 4 2.2. Other Considerations . . . . . . . . . . . . . . . . . . . 5 3. Usage in TLS . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Usage in IKE . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Other uses . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Background: Compression and Certificates . . . . . . . . . . . 6 6.1. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Open Questions . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. The construction of the CXF dictionary . . . . . . . 11 Appendix B. Experimental results . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 McGrew & Pritikin Expires November 12, 2010 [Page 2] Internet-Draft Compressed X.509 May 2010 1. Introduction X.509 certificates and Certificate Revocation Lists (CRLs) are commonly used in the industry in general and in IETF protocols in particular [RFC5280]. These certificates use the ASN.1 encoding, which provides great flexibility, but which is verbose. Certificates are often several kilobytes long, even though the cryptographic data that they carry is often no more than 512 bytes, and can be as low as 64 bytes. There is considerable interest in the use of standard communication protocols on low-power, low-speed, and low-cost devices. For example, Smart Grid networks are anticipated to use 802.15.4, where the maximum packet size is 108 bytes [RFC4944] and data rates are as low as 20 kbit/sec. While it is highly desirable to use digital certificates on these devices, and to use common standards like X.509 and PKIX [RFC5280], it is also desirable to avoid verbose encodings that take up storage space and bandwidth. With CXF, both of these goals can be met. In this note we define a compact format for X.509 certificates, CRLs, and structured data containing X.509 certificates, and we define methods to translate between the compact format and the standard X.509-based encodings. The DEFLATE algorithm [RFC1951] is used, with a predefined CXF-specific dictionary; translation to the compressed format uses the compression algorithm, and the translation back to standard X.509 uses the decompression algorithm. The predefined dictionary used in the compressor/decompressor has been chosen to contain substrings that are typical for X.509 and PKIX . The use of this dictionary makes DEFLATE efficient even when it is applied to a single X.509 certificate. The background to this approach is discussed in Section 6. One important certificate profile, in which compactness is desirable, is defined by the IEEE 802.1AR Secure Device Identity standard [802.1AR]. This X.509 profile is used for manufacturer-installed certificates, and it aims to be compact by requiring only the certificate fields that are vital in that function. 1.1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. McGrew & Pritikin Expires November 12, 2010 [Page 3] Internet-Draft Compressed X.509 May 2010 2. Compressed X.509 Format (CXF) This section defines the Compressed X.509 Format (CXF). A CXF certificate corresponds to an X.509 certificate in Distinguished Encoding Rules (DER) form. A DER certificate is converted into a CXF certificate by applying the DEFLATE compression algorithm, using the CXF "preset dictionary" (in the terms of [RFC1951]) that is defined in the following subsection. A CXF certificate is converted into a DER certificate by applying the DEFLATE decompression algorithm, using the CXF dictionary. CXF can be applied to individual certificates, as described above, or to any sequence of X.509 certificates, such as a certificate chain, or any ASN.1 encoded data containing X.509 certificates. In this note we define the application of CXF to: individual X.509 Signature Certificates, a sequence of X.509 certificates that are concatenated together, with no delimiters or other encoding (as in the TLS certificate_list [RFC5246]), PKCS #7 wrapped X.509 certificate(s) (as used in IKE [RFC4306]) a CertificateBundle (as defined in IKE [RFC4306]) In each of the above cases, translation to and from compressed format uses the DEFLATE algorithm with the CXF dictionary. 2.1. The CXF Dictionary DEFLATE compression algorithm allows the use of a "preset dictionary" to make compression more efficacious for particular applications; it it especially benefits the compression of shorter inputs. When a preset dictionary is used in the compression algorithm, the dictionary is fed into the compressor, and no output is produced while the dictionary is processed, but the compressor state is updated and maintained; after that, the data input is compressed. Decompression with a preset dictionary works similarly; data that is compressed with a particular preset dictionary must be decompressed with the same preset dictionary, or the output of the decompressor will not match the input of the compressor. CXF uses a particular dictionary that has been selected to provide good compression on X.509 formatted certificates and CRLs. The details of how the dictionary was constructed are presented in Appendix A. McGrew & Pritikin Expires November 12, 2010 [Page 4] Internet-Draft Compressed X.509 May 2010 2.2. Other Considerations In many cases, X.509 certificates are much larger than the cryptographic data that they carry because they include an abundance of optional fields. A certificate issuer can significantly reduce the size of a certificate by omitting non-essential fields. This is a valuable strategy that SHOULD be used whenever CXF is used. 3. Usage in TLS It is possible to use CXF certificates in place of X.509 certificates whenever all communicating parties are aware of the format. One important use case is the TLS protocol [RFC5246]. The TLS "cert_type" extension [RFC5081] allows the negotiation of a certificate format. Section 9 defines the cert_type value that is used to indicate the use of CXF in TLS, which is called a CXFCertificate. Recall that a TLS Certificate is defined as a sequence (chain) of X.509v3 certificates: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; A CXFCertificate is a Certificate, as defined above, which has been compressed as described in Section 2. 4. Usage in IKE Another important usage is IKE [RFC4306]. The IKE Certificate Payload can carry certificate data in one of several different formats, and it indicates the format via its Certificate Encoding field. These formats include X.509 Signature Certificate and PKCS #7 wrapped X.509 certificate(s). Section 9 defines the Certificate Encoding values is used to indicate the use of CXF with these formats in IKE. 5. Other uses One potentially interesting usage for CXF is the distribution of Certificate Revocation Lists (CRLs) and Delta CRLs as indicated by McGrew & Pritikin Expires November 12, 2010 [Page 5] Internet-Draft Compressed X.509 May 2010 the CRL Distribution Point (CDP) extension recommended in [RFC5280], Section 4.2.1.13. In this section, we consider some possible applications of CXF to CRLs, but the complete definition of such mechanisms is outside the scope of this note. CXF could be applied to the following transport mechanisms: HTTP - in this case, the CDP URI refers to a single DER encoded CRL as specified in [RFC2585]. The use of the CXF format could be indicated by a new media type, e.g. "application/pkix-xcrl". FTP - a new file extension, e.g. ".xrl", could indicate that the CRL is in the CXF format. LDAP - The use of the CXF format could be indicated by a new ASN.1 attribute, e.g. compressedcertificateRevocationList. These encodings could apply equally well to delta-CRLs which are distinguished after decompression by checking the "delta CRL indicator" CRL extension [RFC5280] . 6. Background: Compression and Certificates The data inside of a certificate can be roughly classified as follows: Cryptographic data, which is encoded in ASN.1 BIT STRING fields. This data is incompressible. Object Identifiers (OIDs), encoded in ASN.1 OBJECT fields. This data is compressible, especially with a well-defined dictionary. Character strings, encoded in ASN.1 PRINTABLESTRING, IA5STRING, and OCTET STRING fields. This data is compressible, and can benefit from a well-defined dictionary. A dictionary that is tailored to a particular certificate profile can take advantage of substrings that are typical to the profile, such as "http://". Time and numbers, encoded as UTCTIME and INTEGER fields. This data is compressible, and can benefit from a well-defined dictionary. Encoding overhead. This data is compressible, especially with a well-defined dictionary. For example, the data classification for a particular RSA-1024 certificate issued by a commercial certificate provider is McGrew & Pritikin Expires November 12, 2010 [Page 6] Internet-Draft Compressed X.509 May 2010 Cryptographic data: 270 bytes Encoding overhead: 164 bytes OIDs: 75 bytes Character strings: 297 bytes Numbers and time: 28 bytes total length: 831 bytes The compression ratio of a CXF certificate is the length of that certificate divided by the length of the corresponding X.509 DER certificate. The compression ratio for the above certificate can be no lower than 0.32, considering the incompressible nature of the cryptographic data. 6.1. Efficiency Self-signed certificates contain a lot of redundant information because several fields will appear twice. The compression ratio on self-signed certificates will be lower (that is, better) than for typical certificates. A certificate chain also contains redundancy, similar to that of a self-signed certificate. CXF SHOULD applied to an entire chain of certificates, as a single atomic unit, as opposed to applying CXF individually to each of the certificates in a chain. Following the recommendation to apply CXF to the entire chain results in a more compact output, because the compression algorithm can take advantage of the redundancy. The protocol bindings defined in this note follow that recommendation. In a software implementation, the CXF dictionary, decompressor, and compressor take up storage space. Any use of CXF to save memory (as opposed to bandwidth) will need to balance the additional memory required by these functions against the memory savings gained by using CXF certificates instead of uncompressed X.509 certificates. 7. Rationale The general approach of defining a compact format for certificates by compressing X.509 is appealing in several ways. It reduces the data- encapsulation overhead of ASN.1 certificates without requiring changes to any ASN.1 encoder or decoder, thus addressing a major deficiency with ASN.1 while preserving the utility of the many applications that use it. Another appeal of this approach is the fact that compression is a relatively expensive operation, and decompression is relatively inexpensive. This disparity in cost is well matched for how certificates are used; compression can occur at the time that a certificate is created, and certificates can be McGrew & Pritikin Expires November 12, 2010 [Page 7] Internet-Draft Compressed X.509 May 2010 stored and carried in compressed form. For many uses of certificates, it is sufficient to use decompression but not compression. The DEFLATE algorithm is well-suited to compressing ASN.1 certificates, because it internally uses three compression modes: no compression, compressed with LZ77 then fixed Huffman codes, and compressed with LZ77 then dynamic Huffman codes. The DEFLATE compressor separates its input into logically distinct blocks, each block of which uses one of the three compression modes. The incompressible cryptographic data can use the "no compression" mode; this avoids the expansion that would otherwise occur when data with no redundancy is run through a compressor, and it avoids the pollution of the LZ77 and dynamic Huffman code dictionary with irrelevant data. The other compression methods are suitable for compressing ASN.1, especially when used with a predefined dictionary. OIDs and their type and length codes can appear in the dictionary, as well as other common type and length codes and typical character strings. Repeated fields in certificates, such as those in self- signed certificates, are efficiently compressed via LZ77. A DEFLATE encoder can use a "lazy matching" strategy, in which several different partitions of the input data into distinct blocks are tried, and the partition that leads to the most compact output is used. The DEFLATE algorithm is commonly used in the ZLIB Compressed Data Format [RFC1950]; this fact allows the implementers of CXF to take advantage of existing implementations of ZLIB. However, the ZLIB format is not used because the extensibility that it provides is not needed, and because of its data overhead. The DEFLATE algorithm is used by the Efficient XML Interchange (EXI) Format [W3C-EXI], which defines a compact representation for the Extensible Markup Language (XML). Thus, CXF is well suited for use in constrained environments that implement EXI, in which the DEFLATE algorithm will already be present. A compressed format for ASN.1 has been defined: the Packed Encoding Rules (PER) [X.691]. CXF does not use PER, because its use of DEFLATE with a predefined dictionary provides good compression that specifically targets X.509 certificates as they are typically used, and because ZLIB and DEFLATE are commonly available and are useful in applications other than CXF. PER is not widely used, and it requires that the decoder have the complete abstract syntax of the data structure to be decoded, which would be awkward for X.509. McGrew & Pritikin Expires November 12, 2010 [Page 8] Internet-Draft Compressed X.509 May 2010 7.1. Open Questions The CXF dictionary could be further refined in future versions of this document. It is an open question exactly what OIDs, and what PKCS7 specific strings, should be included. The dictionary is almost completely in valid ASN.1 DER format; we conjecture that the dictionary can be improved by deviating more from the DER format. (For example the current dictionary includes Subject Key Identifier and Authority Key Identifier strings.) This would enable the dictionary to contain the important typical substrings, without all of the associated ASN.1 data, thus enabling the dictionary to be smaller while producing the same compression ratios. 8. Security Considerations There are no security considerations inherent to the certificate format defined in this note. This is because there is a one-to-one mapping between certificates in X.509 DER format and certificates in compressed format. When an entity accepts a certificate from an untrusted source, the validity of the certificate is checked before any data from the certificate is accepted. This validation uses the digital signature in the certificate, and not the key in the certificate. If the compressed format is in use, and there was an error in the decompression algorithm, a mangled X.509 certificate would result, and the validation of the signature will fail. 9. IANA Considerations The TLS Certificate Type (defined by the cert_type extension) used to indicate the use of CXF in TLS is *TBD1*. The IKE Certificate Encoding value used to indicate the presence of a CXF-formatted X.509 Signature Certificate in an IKE Certificate Payload is *TBD2*. The IKE Certificate Encoding value used to indicate the presence of a CXF-formatted PKCS #7 wrapped X.509 certificate(s) in an IKE Certificate Payload is *TBD3*. The IKE Certificate Encoding registration procedures require expert review; the IPsec Maintenance and Extension (IPsec ME) Working Group is a suitable place to seek such review. The TLS Certificate Type registration procedure is by IETF Consensus. The TLS Working Group is a suitable place for the IESG to seek input on this prospective McGrew & Pritikin Expires November 12, 2010 [Page 9] Internet-Draft Compressed X.509 May 2010 assignment. This paragraph will not be needed after publication as an RFC, and it should be deleted by the RFC editor. 10. References 10.1. Normative References [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 10.2. Informative References [802.1AR] IEEE 802.1AR, "Secure Device Identity", IEEE SA-Standards Board LAN/MAN Standards Committee, 2009. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [W3C-EXI] World Wide Web Consortium (W3C), "Efficient XML Interchange (EXI) Format", Candidate Recommendation version 1.0, 2009. McGrew & Pritikin Expires November 12, 2010 [Page 10] Internet-Draft Compressed X.509 May 2010 [X.691] ITU-T Recommendation X.691, "Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)", SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI networking and system aspects - Abstract Syntax Notation One (ASN.1), 2002. Appendix A. The construction of the CXF dictionary The CXF dictionary was constructed to include data that are typical to X.509 and PKIX usage. In this section, we outline the data that were included in the dictionary, which can be categorized as encoding overhead, OIDs, character strings, and time. The OIDs that are included are X509v3 Authority Key Identifier X509v3 Basic Constraints X509v3 Subject Key Identifier emailAddress commonName countryName stateOrProvinceName organizationName organizationalUnitName rsaEncryption sha1WithRSAEncryption The character string that is included is "http://www.com" The time that is included is 99991231235959Z. The CXF dictionary has been produced using a rudimentary IEEE 802.1AR certificate that has been stripped of signatures and key data. The dictionary is in binary form and can still be said to be DER encoded, although it is no longer composed of valid [RFC5280] certificates. The CXF dictionary is defined as the following sequence of hexadecimal bytes; the elements are to be read from left to right and McGrew & Pritikin Expires November 12, 2010 [Page 11] Internet-Draft Compressed X.509 May 2010 top to bottom: 0x30, 0x82, 0x01, 0x39, 0x30, 0x82, 0x01, 0x23, 0xa0, 0x03, 0x02, 0x01, 0x02, 0x02, 0x01, 0x01, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x05, 0x05, 0x00, 0x30, 0x19, 0x31, 0x17, 0x30, 0x15, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x0e, 0x68, 0x74, 0x74, 0x70, 0x3a, 0x2f, 0x2f, 0x77, 0x77, 0x77, 0x2e, 0x63, 0x6f, 0x6d, 0x30, 0x1e, 0x17, 0x0d, 0x31, 0x30, 0x30, 0x35, 0x31, 0x31, 0x31, 0x39, 0x31, 0x33, 0x30, 0x33, 0x5a, 0x17, 0x0d, 0x31, 0x31, 0x30, 0x35, 0x31, 0x31, 0x31, 0x39, 0x31, 0x33, 0x30, 0x33, 0x5a, 0x30, 0x5f, 0x31, 0x10, 0x30, 0x0e, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x09, 0x01, 0x16, 0x01, 0x40, 0x31, 0x0a, 0x30, 0x08, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x01, 0x20, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x08, 0x13, 0x02, 0x57, 0x49, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x13, 0x02, 0x6f, 0x6e, 0x31, 0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x0b, 0x13, 0x03, 0x6f, 0x75, 0x6e, 0x31, 0x0a, 0x30, 0x08, 0x06, 0x03, 0x55, 0x04, 0x05, 0x13, 0x01, 0x20, 0x30, 0x1f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x0e, 0x00, 0x30, 0x0b, 0x02, 0x04, 0x6e, 0x86, 0xe5, 0x95, 0x02, 0x03, 0x01, 0x00, 0x01, 0xa3, 0x4d, 0x30, 0x4b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x1d, 0x13, 0x04, 0x02, 0x30, 0x00, 0x30, 0x1d, 0x06, 0x03, 0x55, 0x1d, 0x0e, 0x04, 0x16, 0x04, 0x14, 0x1d, 0x29, 0x0a, 0xe9, 0xbb, 0xac, 0x0b, 0x1c, 0x4a, 0xe8, 0xf2, 0xa9, 0x06, 0x52, 0xfd, 0xab, 0xc2, 0xb5, 0x99, 0xc4, 0x30, 0x1f, 0x06, 0x03, 0x55, 0x1d, 0x23, 0x04, 0x18, 0x30, 0x16, 0x80, 0x14, 0x9f, 0xba, 0xff, 0x0d, 0x53, 0x2e, 0x12, 0x92, 0xbd, 0x47, 0x1a, 0xb7, 0x9f, 0x28, 0x8b, 0x9a, 0x5d, 0x74, 0xfa, 0x74, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x05, 0x05, 0x00, 0x03, 0x01, 0x00 For easy reference the following is the dictionary in textual and PEM format: McGrew & Pritikin Expires November 12, 2010 [Page 12] Internet-Draft Compressed X.509 May 2010 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=http://www.com Validity Not Before: May 11 19:13:03 2010 GMT Not After : May 11 19:13:03 2011 GMT Subject: emailAddress=@, CN= , C=US, ST=WI, O=on, OU=oun/serialNumber= Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (31 bit) Modulus (31 bit): 1854334357 (0x6e86e595) Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 1D:29:0A:E9:BB:AC:0B:1C:4A:E8:F2:A9: 06:52:FD:AB:C2:B5:99:C4 X509v3 Authority Key Identifier: keyid:9F:BA:FF:0D:53:2E:12:92:BD:47: 1A:B7:9F:28:8B:9A:5D:74:FA:74 Signature Algorithm: sha1WithRSAEncryption -----BEGIN CERTIFICATE----- MIIBOTCCASOgAwIBAgIBATANBgkqhkiG9w0BAQUFADAZMRcwFQYDVQQDEw5odHRw Oi8vd3d3LmNvbTAeFw0xMDA1MTExOTEzMDNaFw0xMTA1MTExOTEzMDNaMF8xEDAO BgkqhkiG9w0BCQEWAUAxCjAIBgNVBAMTASAxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJXSTELMAkGA1UEChMCb24xDDAKBgNVBAsTA291bjEKMAgGA1UEBRMBIDAfMA0G CSqGSIb3DQEBAQUAAw4AMAsCBG6G5ZUCAwEAAaNNMEswCQYDVR0TBAIwADAdBgNV HQ4EFgQUHSkK6busCxxK6PKpBlL9q8K1mcQwHwYDVR0jBBgwFoAUn7r/DVMuEpK9 Rxq3nyiLml10+nQwDQYJKoZIhvcNAQEFBQADAQA= -----END CERTIFICATE----- Appendix B. Experimental results To validate the approach the following tests were performed. 802.1AR certificates were compressed using CXF, and also compressed using DEFLATE without a preset dictionary in order to provide a comparison. CXF was implemented using a modified version of zlib-1.2.4's gzip utility, using the deflateSetDictionary function to make use of the CXF dictionary. In both cases, the compressor was set for the best possible compression (equivalent to the "gzip -9"). The table shows the compression ratio; that is, the output file size divided by the McGrew & Pritikin Expires November 12, 2010 [Page 13] Internet-Draft Compressed X.509 May 2010 original file size. +----------------+------------------------+------------------+ | Input Data | DEFLATE w/o dictionary | CXF | +----------------+------------------------+------------------+ | RSA cert | 780/753 = 1.04 | 647/753 = 0.86 | | ECC cert | 369/355 = 1.04 | 258/355 = 0.73 | | RSA cert chain | 1395/1572 = 0.89 | 1277/1572 = 0.81 | +----------------+------------------------+------------------+ In both the RSA and ECC case the certificate size is reduced by about 100 bytes. The differences in the computed compression ratio reflect the differences in size of the original certificate. CXF is able to compress even 802.1AR certificates, which minimize the number of ASN.1 fields. The compression ratio is better for the certificate chain because of the duplicate fields in each certificate; it would also be better for self-signed certificates. In contrast, DEFLATE without a preset dictionary is unable to compress the certificates, and it under-performs CXF on certificate chains. The RSA certificate chain used in the experiment is: Certificate: Data: Version: 3 (0x2) Serial Number: 94:8c:34:15:cd:80:ee:f9 Signature Algorithm: sha256WithRSAEncryption Issuer: CN=http://www.com Validity Not Before: May 11 19:13:12 2010 GMT Not After : May 10 19:13:12 2020 GMT Subject: CN=http://www.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:aa:2b:8f:2a:6d:6e:fa:b1:de:ec:43:13:a5:03: 1d:67:00:2d:87:d6:07:4b:d8:bd:54:f6:72:cf:62: be:a7:73:b4:5b:81:a8:03:a1:7c:7d:ef:88:a2:2c: 61:26:be:f3:5c:ce:a9:1c:b0:67:3e:d0:7c:67:1d: 78:35:e6:1c:c6:ad:3b:8d:41:05:2c:04:34:39:ce: b1:5e:01:ce:c2:da:d7:cc:77:04:7c:02:7d:71:7b: 0c:3f:95:8d:35:8c:47:b2:0e:24:cd:4f:3b:ae:c3: 13:cf:a9:c3:55:24:35:7d:dc:f0:a8:c2:a0:52:83: ed:84:10:3c:95:c8:7b:c4:ed:df:b8:83:d5:3f:63: c5:39:33:e5:1f:58:3f:2b:f2:e6:b6:8e:87:65:51: 9e:46:c7:ba:f0:08:cf:85:e9:93:11:4f:a2:ec:da: McGrew & Pritikin Expires November 12, 2010 [Page 14] Internet-Draft Compressed X.509 May 2010 61:0e:1c:6b:3f:34:f8:40:10:8e:4c:8d:1f:5d:00: 10:c4:12:b2:fa:fa:3b:60:e9:d3:8c:19:3f:be:74: 6b:d0:cb:79:3e:12:18:b3:86:f5:ba:0b:f0:8a:e7: 56:be:d2:e5:49:53:26:bc:9f:6a:0c:f8:27:69:a5: ac:25:6c:da:af:55:d2:f4:02:b5:e5:ef:64:b8:85: 24:de:9c:95:05:80:96:96:23:94:0e:7b:b4:d3:b7: 66:8b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 1B:7E:0F:F8:41:75:16:D0:01:5C:53:11:FA: 05:BA:D8:B0:B1:94:63 X509v3 Authority Key Identifier: keyid:1B:7E:0F:F8:41:75:16:D0:01:5C:53: 11:FA:05:BA:D8:B0:B1:94:63 DirName:/CN=http://www.com serial:94:8C:34:15:CD:80:EE:F9 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 4b:94:46:36:a3:43:16:cc:2f:3d:7b:d2:8f:96:51:b1:93:43: 08:38:d7:3a:61:f6:09:d5:f9:aa:08:3c:7d:b2:4e:dc:24:e3: 2c:76:ca:16:d2:b0:ad:4e:1a:6e:92:77:e1:47:67:1b:c8:30: 1a:52:17:4e:91:61:09:99:5d:b0:de:ab:04:f6:b8:4e:49:47: 0e:df:af:f9:e1:be:a2:f0:8b:5b:38:33:d6:b5:b9:6c:be:15: eb:ec:58:7d:6b:88:ab:a0:c7:7c:a5:12:43:a0:8d:82:1e:6b: d2:a0:7a:e6:03:04:ad:2d:9f:73:be:5a:b3:9e:77:a9:a2:8c: 7a:a0:6e:1b:cb:f4:92:5a:32:b6:03:f8:6e:d0:e0:e0:6a:f1: 8a:52:3c:56:da:e1:40:cb:ea:2e:49:6f:d0:8c:d5:3f:6f:3f: 67:9f:a4:38:96:3e:d3:17:d4:09:55:6c:5c:3f:78:a3:06:73: dd:81:6b:54:89:1c:55:96:16:c9:5c:c3:b1:a4:57:8b:5c:24: 65:d1:8a:78:ec:1a:53:17:1a:7a:df:86:5e:af:0f:26:c5:7c: 51:da:bb:51:af:0d:1a:55:e2:23:3d:54:f2:1c:42:4a:1f:60: 89:13:4f:e1:d5:f9:e1:c0:0a:a3:17:b1:b9:b1:50:6b:b5:5e: 8c:1c:f0:f7 -----BEGIN CERTIFICATE----- MIIDLzCCAhegAwIBAgIJAJSMNBXNgO75MA0GCSqGSIb3DQEBCwUAMBkxFzAVBgNV BAMTDmh0dHA6Ly93d3cuY29tMB4XDTEwMDUxMTE5MTMxMloXDTIwMDUxMDE5MTMx MlowGTEXMBUGA1UEAxMOaHR0cDovL3d3dy5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCqK48qbW76sd7sQxOlAx1nAC2H1gdL2L1U9nLPYr6nc7Rb gagDoXx974iiLGEmvvNczqkcsGc+0HxnHXg15hzGrTuNQQUsBDQ5zrFeAc7C2tfM dwR8An1xeww/lY01jEeyDiTNTzuuwxPPqcNVJDV93PCowqBSg+2EEDyVyHvE7d+4 g9U/Y8U5M+UfWD8r8ua2jodlUZ5Gx7rwCM+F6ZMRT6Ls2mEOHGs/NPhAEI5MjR9d ABDEErL6+jtg6dOMGT++dGvQy3k+EhizhvW6C/CK51a+0uVJUya8n2oM+Cdppawl bNqvVdL0ArXl72S4hSTenJUFgJaWI5QOe7TTt2aLAgMBAAGjejB4MB0GA1UdDgQW BBQbfg/4QXUW0AFcUxH6BbrYsLGUYzBJBgNVHSMEQjBAgBQbfg/4QXUW0AFcUxH6 BbrYsLGUY6EdpBswGTEXMBUGA1UEAxMOaHR0cDovL3d3dy5jb22CCQCUjDQVzYDu McGrew & Pritikin Expires November 12, 2010 [Page 15] Internet-Draft Compressed X.509 May 2010 +TAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBLlEY2o0MWzC89e9KP llGxk0MIONc6YfYJ1fmqCDx9sk7cJOMsdsoW0rCtThpuknfhR2cbyDAaUhdOkWEJ mV2w3qsE9rhOSUcO36/54b6i8ItbODPWtblsvhXr7Fh9a4iroMd8pRJDoI2CHmvS oHrmAwStLZ9zvlqznnepoox6oG4by/SSWjK2A/hu0ODgavGKUjxW2uFAy+ouSW/Q jNU/bz9nn6Q4lj7TF9QJVWxcP3ijBnPdgWtUiRxVlhbJXMOxpFeLXCRl0Yp47BpT Fxp634Zerw8mxXxR2rtRrw0aVeIjPVTyHEJKH2CJE0/h1fnhwAqjF7G5sVBrtV6M HPD3 -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=http://www.com Validity Not Before: May 11 19:13:17 2010 GMT Not After : May 11 19:13:17 2011 GMT Subject: CN=3 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:da:cf:0c:80:4b:7b:5d:c6:05:83:21:6d:6f:34: c8:19:95:6a:74:0a:1b:26:fb:d4:35:7f:02:3d:47: c0:a3:13:2b:e1:b6:0b:d1:91:0e:79:cf:d1:93:a4: 07:d9:ce:de:e9:3d:be:a9:19:c6:52:03:96:57:c1: 93:e8:18:b9:06:e1:a8:14:8a:22:70:72:85:52:56: cd:d5:e3:e7:8c:22:b5:f3:ce:df:a2:67:59:7b:39: a8:f0:69:1f:3d:73:4b:ce:f0:00:27:a5:81:5d:e2: ba:26:3b:21:8a:74:11:d3:a3:23:fb:40:27:b2:0f: ac:61:63:31:13:cf:d0:27:47:4b:bf:d9:67:f5:29: 4b:a6:76:0a:28:dc:55:68:57:a2:de:be:6f:da:92: 24:1e:99:80:81:00:0d:47:c7:b7:98:c5:97:9f:ac: 7a:c4:bc:16:93:b8:9d:27:f9:5a:4f:63:b5:45:6a: b2:cb:26:71:b6:94:6b:65:ff:33:94:0f:da:7e:40: 74:19:ca:34:3e:3d:e0:b5:cc:d9:b9:e8:bc:0b:95: d4:9c:23:89:a0:6b:b3:7b:ef:8e:a5:79:6e:e6:9f: 6c:5d:1a:2f:39:b9:78:1a:bd:81:37:87:45:60:fb: d6:cb:94:33:c7:e3:06:60:9a:7a:f0:f2:b0:a7:cb: 6d:99 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: BB:A7:D8:EE:6D:EE:79:60:0D:AB:38:35:5C:0C: 7E:70:EA:C1:FF:6E X509v3 Authority Key Identifier: McGrew & Pritikin Expires November 12, 2010 [Page 16] Internet-Draft Compressed X.509 May 2010 keyid:1B:7E:0F:F8:41:75:16:D0:01:5C:53:11: FA:05:BA:D8:B0:B1:94:63 Signature Algorithm: sha1WithRSAEncryption 46:9b:5e:d5:ab:e7:66:4d:2c:d8:fd:44:67:08:87:5e:57:a7: 69:f4:f4:1b:46:39:61:b3:d5:f4:9c:11:b6:17:8c:a8:bc:10: 0b:43:13:b3:ab:a0:99:a8:67:5c:b1:82:df:54:44:46:89:70: d4:5d:0d:7c:16:8e:29:fa:c5:ae:2d:08:c4:65:b4:8e:ce:58: 04:f7:50:99:8f:c7:a3:bb:4d:da:64:72:99:a0:dd:c5:f5:fd: c8:a6:be:78:ce:96:19:a9:89:f0:01:1d:88:e0:56:6e:0e:16: d9:3a:2e:63:d4:07:54:9a:6d:b9:b5:e4:52:9c:ed:4d:6f:26: cd:8b:de:1e:b7:cb:cd:1c:76:e2:87:4e:9b:7b:3b:9d:5f:63: 3f:7f:2e:e7:ac:84:e9:3d:68:38:60:ae:85:b4:92:99:62:3c: 5d:50:b4:94:65:89:3b:42:30:16:68:0a:18:21:23:de:7b:83: 2b:df:1a:2c:5c:4d:19:94:3c:ba:be:76:eb:50:4c:b2:8f:bc: 3b:d9:6b:50:30:06:c7:c4:17:a0:1a:16:75:83:1e:f0:de:c2: 4f:da:2f:3a:a0:c6:d3:82:6a:10:7e:b7:ed:72:cd:ea:d2:de: 60:eb:57:6e:9b:ab:02:c1:09:04:c5:f8:a2:dd:59:70:69:d3: b7:b6:ae:91 -----BEGIN CERTIFICATE----- MIIC7TCCAdWgAwIBAgIBAzANBgkqhkiG9w0BAQUFADAZMRcwFQYDVQQDEw5odHRw Oi8vd3d3LmNvbTAeFw0xMDA1MTExOTEzMTdaFw0xMTA1MTExOTEzMTdaMAwxCjAI BgNVBAMTATMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDazwyAS3td xgWDIW1vNMgZlWp0Chsm+9Q1fwI9R8CjEyvhtgvRkQ55z9GTpAfZzt7pPb6pGcZS A5ZXwZPoGLkG4agUiiJwcoVSVs3V4+eMIrXzzt+iZ1l7OajwaR89c0vO8AAnpYFd 4romOyGKdBHToyP7QCeyD6xhYzETz9AnR0u/2Wf1KUumdgoo3FVoV6Levm/akiQe mYCBAA1Hx7eYxZefrHrEvBaTuJ0n+VpPY7VFarLLJnG2lGtl/zOUD9p+QHQZyjQ+ PeC1zNm56LwLldScI4mga7N7746leW7mn2xdGi85uXgavYE3h0Vg+9bLlDPH4wZg mnrw8rCny22ZAgMBAAGjTTBLMAkGA1UdEwQCMAAwHQYDVR0OBBYEFLun2O5t7nlg Das4NVwMfnDqwf9uMB8GA1UdIwQYMBaAFBt+D/hBdRbQAVxTEfoFutiwsZRjMA0G CSqGSIb3DQEBBQUAA4IBAQBGm17Vq+dmTSzY/URnCIdeV6dp9PQbRjlhs9X0nBG2 F4yovBALQxOzq6CZqGdcsYLfVERGiXDUXQ18Fo4p+sWuLQjEZbSOzlgE91CZj8ej u03aZHKZoN3F9f3Ipr54zpYZqYnwAR2I4FZuDhbZOi5j1AdUmm25teRSnO1NbybN i94et8vNHHbih06bezudX2M/fy7nrITpPWg4YK6FtJKZYjxdULSUZYk7QjAWaAoY ISPee4Mr3xosXE0ZlDy6vnbrUEyyj7w72WtQMAbHxBegGhZ1gx7w3sJP2i86oMbT gmoQfrftcs3q0t5g61dum6sCwQkExfii3VlwadO3tq6R -----END CERTIFICATE----- McGrew & Pritikin Expires November 12, 2010 [Page 17] Internet-Draft Compressed X.509 May 2010 Authors' Addresses David A. McGrew Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Phone: (408) 525 8651 Email: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm Max Pritikin Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Phone: (408) 424 5141 Email: pritikin@cisco.com McGrew & Pritikin Expires November 12, 2010 [Page 18]