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]