INTERNET DRAFT Thierry Moreau Document: draft-moreau-pkix-takrem-00.txt CONNOTECH Category: Informational July, 2005 Expires: January, 2006 Trust Anchor Key Renewal Method Applied to X.509 Self-signed Certificates (TAKREM-X.509) Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2005). IPR Disclosure Acknowledgment By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract In the Internet PKI, trust anchor keys are distributed as self- signed X.509 security certificates. This document specifies a trust anchor key renewal mechanism that leverages the confidence in the initial certificate distribution. A non-critical X.509 certificate extension holds a sequence of opaque octet strings. The trust anchor renewal operation occurs upon receipt of a message that hashes to one of those octet strings. Moreau Informational [page 1] Internet-Draft TAKREM-X.509 July, 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Initial Self-signed X.509 Certificate Extension . . . . . . . . . 3 2.1 Interoperability Considerations . . . . . . . . . . . . . . 3 2.2 Security Processing . . . . . . . . . . . . . . . . . . . . 4 3. Trust Anchor Key Renewal Message . . . . . . . . . . . . . . . . . 5 4. Renewal Message Processing by Relying Systems . . . . . . . . . . 6 4.1 Interoperability Considerations . . . . . . . . . . . . . . 6 4.2 Security Processing . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 7.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 9 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 9 Derivative Works Limitation . . . . . . . . . . . . . . . . . . 9 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 9 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A Certification Authority (CA) may issue a self-signed X.509 public key certificate to announce its public key to a community of relying parties, see normative reference [RFC2459]. This public key is called a "trust anchor" key because it is the end of a chain of security certificates. This document describes a mechanism for the renewal of a trust anchor key. Although it is conceivable to renew a self-signed certificate without renewing the CA public key, the present document addresses the simultaneous renewal of both the CA public key and the self-signed certificate. The suggested acronym for the renewal mechanism is TAKREM for Trust Anchor Key REnewal Method. We thus distinguish the initial self-signed X.509 certificate from the renewed self-signed X.509 certificate. The mechanism uses an innocuous (i.e. non-critical) certificate extension in the initial self-signed certificate. This is explained in section 2. A trust anchor key renewal message is defined in section 3. A system Moreau Informational [page 2] Internet-Draft TAKREM-X.509 July, 2005 configured with a self-signed certificate MAY process this renewal message in the manner specified in section 4, and thus complete the renewal operation. The cryptographic bound between the certificate extension value elements and the renewal message rests on the MASH (Modular Arithmetic Secure Hash) primitive, defined in the normative reference [ISO10118-4]. This secure hash primitive specification allows the selection of a hash function instance within a hash function family. Moreover, the MASH parameter selection provides flexibility in cryptographic parameter size selection, hence flexibility in cryptographic strength decisions. Operating principles are further explained in informational reference [CONNOTECH]. The present document focuses on the interoperability aspects of the renewal mechanism in the context of Internet X.508 PKI. 2. Initial Self-signed X.509 Certificate Extension 2.1 Interoperability Considerations This document defines the TAKREM X.509 security certificate extension. Security certificate extensions are explained in section 4.2 of [RFC2459]. o The object identifier (OID) value referring to the TAKREM extension is {[ToBeDetermined]/**/}. o The TAKREM extension is non-critical. o The octet string extension value is a sequence of opaque octet strings, each of a size least 160 bits: SEQUENCE SIZE (1..MAX) OF OCTET STRING SIZE (20..MAX) In the next document subsection, we use the notation #n# for the number of opaque octet strings actually present in the TAKREM certificate extension field. The recommended procedure for filling the extension value is specified in the next document subsection. Moreau Informational [page 3] Internet-Draft TAKREM-X.509 July, 2005 2.2 Security Processing The [[issuer of an initial self-signed certificate]] SHALL follow the procedure described herein for the generation of the TAKREM certificate extension. We use the notation ## for the key pair comprising the public key #R[i]# and the private key counterpart #r[i]#. Prior to digitally signing the initial self-signed certificate, the [[issuer of an initial self-signed certificate]] SHALL establishes anticipated key pairs ##, ##, ... ##, ... ## for #1<=i<=n# (#n# is defined in the previous document subsection). For each key pair ##, the [[issuer of an initial self- signed certificate]] MAY prepare an anticipated self-signed certificate #Cert[i]#, reflecting the intended usage context for the public key #R[i]#. The key pairs for which no such certificate Cert[i] is prepared SHALL be generated for the subject public key algorithm indicated in the initial self-signed certificate. A separate MASH (Modular Arithmetic Secure Hash) instance #H[i]# is created for each #R[i]#. That is, the [[issuer of an initial self- signed certificate]] SHALL select a large composite modulus number #N[i]# used in the MASH round function and a prime number #p[i]# used in the MASH final reduction function, in compliance with normative reference [ISO10118-4]. Each prime number #p[i]# SHALL have an octet-aligned size no less than 160 bits, i.e. #2^(8j-1)=20#. The [[issuer of an initial self-signed certificate]] SHALL also select a random octet string of the same length as the final hash- code output in the MASH specification, notation salt field #s[i]#. Then, the [[issuer of an initial self-signed certificate]] SHALL compute a hash value, giving the digest #D[i]# : #D[i]=H[i](s[i]|R[i]|N[i]|p[i])#, or #D[i]=H[i](s[i]|Cert[i]|N[i]|p[i])#, if an anticipated self-signed certificate #Cert[i]# has been prepared. The MASH variant used in this computation SHALL be Moreau Informational [page 4] Internet-Draft TAKREM-X.509 July, 2005 MASH-2. For the above hash value computation, the input string SHALL be the DER encoding for a value of the ASN.1 type TakremX509MashInput defined as: TakremX509MashInput ::= SEQUENCE { OCTET STRING SIZE(20..MAX), -- #s[i]# IMPLICIT CHOICE { BIT STRING, -- #R[i]# encoded as a "subjectPublicKey" per -- RFC 2459, or per encoding rules for the subject -- public key algorithm Certificate -- #Cert[i]# encoded per rfc2459 }, INTEGER, -- #N[i]# INTEGER -- #p[i]# } The TAKREM certificate extension value SHALL hold the digests #D[1], D[2], ..., D[n]# as a sequence of opaque octet strings. The digest #D[i]# is like an advanced notice of future trust anchor key #R[i]#. As soon as the initial self-signed certificate is prepared, the issuer SHOULD conceal every data tuple ## (or ##) until the key pair ## needs activation. 3. Trust Anchor Key Renewal Message Some time after distributing an initial self-signed certificate, the [[issuer of an initial self-signed certificate]] might wish to activate a key pair ## for which the public key #R[i]# is hashed into a digest #D[i]# held in the initial certificate. In this case and if the public key #R[i]# was hashed directly into the digest #D[i]# (i.e. not through a #Cert[i]#), the [[issuer of an initial self-signed certificate]] MAY distribute the data tuple ## along with a self-signed certificate for #R[i]#, notation #Cert'[i]#. Likewise, if the public key #R[i]# was hashed into the digest #D[i]# through the #Cert[i]#, the [[issuer of an initial self-signed certificate]] MAY distribute the data tuple ##, optionally with a new self-signed certificate #Cert'[i]# for #R[i]#. This data element distribution occurs in a trust anchor key renewal message whose format and protocol encapsulation is outside the scope of the present document. Moreau Informational [page 5] Internet-Draft TAKREM-X.509 July, 2005 When both self-signed certificates #Cert[i]# and #Cert'[i]# are present in a trust anchor key renewal message, the contents of the later takes precedence. This allows the [[issuer of an initial self-signed certificate]] to use the public key #R[i]# in a PKI environment different from the one initially anticipated. 4. Renewal Message Processing by Relying Systems 4.1 Interoperability Considerations A relying system that trusts one or more self-signed certificates with a TAKREM certificate extension MAY implement a message receipt capability expecting a trust anchor key renewal message. The matching process between a renewal message and a digest #D[i]# (and the initial self-signed certificate holding it) falls outside the scope of the present document. Upon receipt of a renewal message for which a value of the ASN.1 type TakremX509MashInput can be isolated or reconstructed for a given digest #D[i]#, a relying system MAY accept #Cert'[i]#, or #Cert[i]# if #Cert'[i]# is absent, as a trusted certificate. It SHOULD NOT do so unless the data validation and cryptographic integrity checks are performed according to the next document subsection. 4.2 Security Processing A relying system that trusts a self-signed certificate with a TAKREM certificate extension MAY trust the digest values #D[i]# beyond the validity period of the self-signed certificate holding them. The relying party SHALL validate the trust anchor key renewal message contents against the provisions of the present document. This includes the following semantic validations: o If the two certificates #Cert[i]# and #Cert'[i]# are received, the two should have the same subject public key value and algorithm identifier. o If no #Cert[i]# is received in the renewal message, the subject public key value in #Cert'[i]# must be #R[i]#. Moreau Informational [page 6] Internet-Draft TAKREM-X.509 July, 2005 The relying party SHALL verify the self-signed certificates #Cert[i]# and/or #Cert'[i]#. Once the relying party matched the renewal message with a digest #D[i]# and the initial self-signed certificate holding it, it SHALL perform the following validation and cryptographic integrity check: o If no #Cert[i]# is received in the renewal message, the subject public key algorithm identifier must be the same in #Cert'[i]# as in the initial self-signed certificate. o The digest #D[i]# must be verified with the renewal message contents. 5. Security Considerations The technology described in the present document, if properly used, is meant to improve the confidence in trust anchor keys in relying systems in a PKI scenario. Irrespective of the use of the TAKREM mechanism, the initial distribution of a trust anchor key should be authenticated by an out-of-band mechanism. The message processing specified in section 4 should be implemented with strict compliance to the message integrity validation specifications, i.e. an implementation should avoid lax acceptance of a security certificate. On a broader perspective, the relying system trust anchor certificate configuration should be protected against malignant modification attempts. The uninterrupted integrity protection of trust anchor key configuration is important to prevent spoofing attacks on relying systems. It can be assumed that most adversaries targeting relying systems are motivated by short-term benefits, i.e. an attack completion time much shorter than a trust anchor key renewal period. If this is a proper assessment of threats to key configuration integrity, the integrity protection requirements are no more demanding with the use of the TAKREM mechanism. As usual with public key cryptography, the compromise of a CA private key should be prevented by very robust technological, administrative and personnel means. The security principles behind the present mechanism suggest the Moreau Informational [page 7] Internet-Draft TAKREM-X.509 July, 2005 concealment of each public key for the duration between its generation and its period of use. This is to prevent brute force attacks on public keys, which might be possible if a very powerful adversary was given the public key long in advance of its period of use. The source of entropy used by a certification authority in its key pair and self-signed certificate generation process should be reliable and secure. The security or MASH parameter selection should follow the guidelines from normative reference [ISO10118-4]. 6. IANA Considerations This document has no actions for IANA. 7. References 7.1 Normative References [RFC2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999 [ISO10118-4] International standard document ISO/IEC 10118-4:1998, "Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic" 7.2 Informative References [CONNOTECH] Thierry Moreau, "A Note About Trust Anchor Key Distribution", CONNOTECH Experts-conseils inc., Document Number C003444, 2005/07/05, http://www.connotech.com/takrem.pdf Moreau Informational [page 8] Internet-Draft TAKREM-X.509 July, 2005 Author's Address Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc, Canada Tel.: +1-514-385-5691 e-mail: thierry.moreau@connotech.com IPR Notices Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Derivative Works Limitation This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Moreau Informational [page 9] Internet-Draft TAKREM-X.509 July, 2005 Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Moreau Informational [page 10]