Multiple Public Key (MPK)
Lein Harn1, Chen-Chi Lin2 and Chi-Sung Laih3, Member, IEEE.
One X.509 v3 certificate extension is defined in this letter and this extension supports
applications that frequently use two or more public keys. The Multiple Public Key (MPK)
certificate formed by the MPK certificate extension can not only speed up verification time but
also can compress space of certificate.
Introduction: Nowadays, public-key cryptography and certificates are popularly used to support
strong security for many Internet applications, such as Web-service, e-mail, VPN, etc. A publickey certificate is a digital document that binds a public key to a person, service, or an application
and is digitally signed by using the private key of a certificate authority (CA). In real world, the
Public Key Infrastructure (PKI) user has high probability to hold multiple certificates for some
applications, such as IPSEC [2] and TLS [3], that need to use two or more public keys. In one
example of the IPSEC, Alice needs to verify Bob’s signature with one of Bob’s public keys and to
encrypt the message for Bob with Bob’s second public key. In one example of the TLS, the PKIenabled software needs to authenticate Bob’s identity with one of Bob’s public keys and to
encipher one session key for Bob with Bob’s second public key.
X.509 certificate format [1, 6] does not particularly support the ability to put multiple public keys
in one certificate. This letter defines one private X.509 v3 certificate extension called MPK
certificate extension to support the function of containing multiple public keys in a single
certificate. If the Internet X.509 v3 MPK certificate formed by the private MPK certificate
extension is applied in above applications, it can not only save the cost of certificates; but also
can speed up verification time and attain compression of certificate space.
Review of X.509 public-key certificate: The widely accepted standard format for public-key
certificates is the ITU x.509 v3 [1] and IETF profiled X.509 v3 [6]. At the outmost level, X.509
certificate structure has three fields: the X.509 signed certificate unit, the signature algorithm
identifier, and the signature value. It was defined by the ASN.1 type definition [4], and part of the
definitions is shown in Table 1. The details of the X.509 ASN.1 format and encoding can be
referred to [1, 6]. In Table 1, the tbsCertificate field, the X.509 signed certificate unit, presents
all the basic certificate information. At a minimum, it contains six fields: the serial number, the
signature algorithm identifier, the issuer name, the validity period, the public key, and the subject
name. It may include four optional fields: the version number, two unique identifiers, and the
extensions. Theses optional fields appear only in version 2 and 3 certificates. The
signatureAlgorithm field, the signature algorithm identifier, identifies the signature algorithm
used by the certificate issuer to sign the certificate. The signatureValue field, the signature value,
contains the value of digital signature computed using the ASN.1 DER encoded signed certificate.
The structure of the MPK certificate: Typically, each public key of above multiple-public-key
applications has some common attributes, such as version, signature algorithm identifier, issuer
name, subject name, and unique identifiers in each X.509 v3 certificate. To simplify the certificate
management and meet the need of above applications, this letter defines one X.509 v3 private
certificate extension, called the MPK certificate extension, which consists of one or more
additional key units. Each additional key unit contains only one public key field and one optional
extensions field. The public key contained in the additional key unit of the MPK certificate
extension shares the common certificate information, such as serial number, validity period, issuer,
subject name, etc. with the X.509 signed certificate unit. However, each public key keeps its
specific attributes in the extensions field. The ASN.1 syntax for the MPK certificate extension is
showed in Table 1. It is recommended to mark “Not Critical” to avoid compatibility problems. In
this letter, the X.509 v3 MPK certificate is defined to consist of one X.509 signed certificate unit
and one private MPK certificate extension. In such design, the MPK certificate is not only to
retain the structure of X.509 v3 certificate; but also to minimize impacts on the PKI lifecycle
management.
Advantages of the MPK certificate: Basic certificate verification is performed on each certificate
in sequence [7]: checking certificate validity, certificate revocation, the certificate signature,
certificate policies, and name constraints. As mentioned above, each public key in the MPK
certificate shares the common certificate information. So, the certificate verification of MPK
certificate just needs to perform once in checking certificate validity, certificate revocation, the
certificate signature, and name constraints. Checking certificate policies is the only item that
needs to validate separately if each public key in the MPK format has the extensions field. From
the above discussion, if the user or the web server uses this MPK certificate to contain n public
keys, instead of using n X.509 certificates, it saves the verification time up to maximal (n-1)
times. As we know, it will take 15 ms or more [5] to send one certificate and to be verified by CA
through the Internet. Thus, using MPK certificate can significantly improve the performance of
multiple-public-key enabled services.
The compression of the certificate space is a bonus benefit because all public keys in the MPK
certificate structure share one common certificate information. In the following example, we
compare the compression capability between application of using n public keys in one MPK
certificate and application of using n public keys in n X.509 v3 certificate. The value of the
ASN.1 DER encoded X.509 v3 certificates can be denoted as
{PUB, X, Sig(h((PUB, X))),
where PUB is the subject’s public key value, X is the value of the signed certificate unit except
the subject’s public key value, h() is the one-way hash function, Sig is the digital signature
process, and Sig(h((PUB, X)) is equal to the value of the signature algorithm identifier and the
signature. The value of the ASN.1 DER encoded MPK certificate containing n public keys PUB1
to PUBn can be represented as:
{PUB1 . . PUBn , Y, Sig(h(PUB1 . . PUBn, Y))),
where Y represents X added to (n-1) times of extensions value if extensions field appears. Assume
that the value of Sig(h(PUB1 . . PUBn, Y)) is equal to the value of Sig(h(PUB, X)). So, the space
reduction is up to (n-1) times of (X + Sig(h(PUB, X)) if the extensions value is negligible.
Conclusion: The MPK certificate is not only backward compatible with X.509 certificate but also
extend the capability of X.509 certificates in some specific circumstances. Moreover, it is
beneficial to save the cost of certificate, speed up certificate verification and reduce certificate
space for some multiple-public-key applications.
Reference
[1] “Information Technology – Open Systems Interconnections – The Directory: Authentication
Framework”, ISO/IEC International Standard 9594-8 | ITU-T Recommendation X.509 (1997)
[2] Security Architecture for
notes/rfc/files/rfc2401.txt
the
Internet
Protocol,
http://info.internet.isi.edu:80/in-
[3] The TLS Protocol Version 1.0, http://www.consensus.com/ietf-tls/tls-protocol-03.txt
[4] ITU-T Recommendation X.660 Information technology – Abstract Syntax Notation One
(ASN.1) encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER), 1997.
[5] Apostolopoulous G.; Peris V; Pradhan P.; Saha D “ Secure Electronic Commerce: Reducing
the SSL Overhead”, IEEE Network July/August 2000, P 8-16.
[6] RFC 3280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, 2002.
[7] Russ Housley and Tim Polk, Planning for PKI, Wiley &Sons, Inc, 2001.
Authors’ affiliations:
1
Department of Computer Networking, University of Missouri – Kansas City. MO, 64110,
USA,
Email: HarnL@umkc.edu
2
3
Cryptography & Network Security Lab., Department of Electrical Engineering, Cheng Kung
University, Tainan, Taiwan ( *Note: the corresponding author)
E-mail: lchenchi@chtti.com.tw
Cryptography & Network Security Lab., Department of Electrical Engineering, Cheng Kung
University, Tainan, Taiwan
E-mail: laihcs@eembox.ee.ncku.edu.tw
Table captions:
Table 1. The format of X.509 v3 certificate and MPK certificate extension
Table 1.
X.509 v3 certificate
Certificate ::= Sequence {
tbsCertificate TBSCertificate ,
signatureAlgorithm AlgorithmIdentifier,
signatureValue
BIT STRING }
TBSCertificate ::= SEQUENCE {
version
[0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber ,
signature
AlgorithmIdentifier ,
issuer
Name ,
validity
Validity ,
subject
Name ,
subjectPublicKeyInfo SubjectPublicInfo ,
issuerUniqueID [1] IMPLICT UniqueIdentifier OPTIONAL ,
subjectUniqueID [2] IMPLICT UniqueIdentifier OPTIONAL ,
extensions
[3] EXPLICT Extensions OPTIONAL }
X.509 V3 private MPK certificate extension
MPKcertificates ::= SEQUENCE SIZE (1.. MAX) OF
Additioncertificate
/ - - additional key unit- -/
Additionalcertificate ::= SEQUENCE {
subjectPublicKeyInfo SubjectPublicInfo ,
extensions
[0] EXPLICT Extensions OPTIONAL }