INTERNET DRAFT Thierry Moreau Document: draft-moreau-pkix-takrem-01.txt CONNOTECH Category: Informational September, 2005 Expires: March, 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 . . . . . . . . . . . . . . . . . 6 4. Renewal Message Processing by Relying Systems . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . . 10 9. Revision history . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 11 Derivative Works Limitation . . . . . . . . . . . . . . . . . . 11 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 11 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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. In here, an issuer of an initial self-signed certificate is called a "self-certifying CA". 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 { iso(1) identified-organization(3) 6 1 4 1 23742 2}. 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 self-certifying CA 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 self-certifying CA SHALL establish anticipated key pairs ##, ##, ... ##, ... ## for #1<=i<=n# (#n# is defined in the previous document subsection). For each key pair ##, the self-certifying CA 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, i.e. the same algorithm object identifier. A separate MASH (Modular Arithmetic Secure Hash) instance #H[i]# is created for each #R[i]#. That is, the self-certifying CA 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 self-certifying CA 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 self-certifying CA 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 MASH-2. Moreau Informational [page 4] Internet-Draft TAKREM-X.509 July, 2005 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 { [1] IMPLICIT SEQUENCE { -- #R[i]# same as type as -- SubjectPublicKeyInfo per RFC 2459 SEQUENCE { -- AlgorithmIdentifier in RFC2459 algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }, subjectPublicKey BIT STRING -- public key encoded as a "subjectPublicKey" per -- RFC 2459, or per encoding rules for the subject -- public key algorithm }, [2] IMPLICIT 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 self-certifying CA 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 self- certifying CA 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 self-certifying CA MAY distribute the data tuple ##, optionally Moreau Informational [page 5] Internet-Draft TAKREM-X.509 July, 2005 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 details are outside the scope of the present document. Nonetheless, it is recommended that the renewal message syntax be specified with ASN.1 and contain a data element of the type TakremX509MashInput and an optional data element of the type of the type Certificate defined in [RFC2459] holding #Cert'[i]#. In addition, it is recommended that the renewal message contain a data element of the type AuthorityKeyIdentifier defined in [RFC2459] identifying the relevant self-signed certificate, and an integer data element holding the value #i#. 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 self-certifying CA to use the public key #R[i]# in a PKI environment different from the one initially anticipated. 4. Renewal Message Processing by Relying Systems By the time a relying system receives a renewal message as specified in section 3, it may have been configured with one or more self-signed certificates with a TAKREM certificate extension. If the relying system trusts some of these self-signed certificates, it MAY implement a message receipt capability expecting a trust anchor key renewal message and processing it according to the present section. A relying system processes renewal messages with the following sequence of operations: o renewal message recognition, o preliminary renewal message validation, o matching the renewal message to a digest #D[i]# o cryptographic validation, o security certificate enablement. The recognition of a trust anchor renewal message is out of scope for the present document. However, a renewal message might hold the TAKREM-specific data elements ## (or ##) and optionally #Cert'[i]# (e.g. in ASN.1 data elements of the types TakremX509MashInput and Certificate), in which case the relying system SHOULD proceed with the next processing steps. The relying party SHOULD validate the TAKREM-specific portions of Moreau Informational [page 6] Internet-Draft TAKREM-X.509 July, 2005 the trust anchor key renewal message, applying the following semantic validations: o If the two certificates #Cert[i]# and #Cert'[i]# are received, the two should have the same public key value. o If no #Cert[i]# is received in the renewal message, the public key value in #Cert'[i]# must be #R[i]#. Moreover, The relying party SHALL verify the self-signed certificates #Cert[i]# and/or #Cert'[i]#. From the data elements ## (or ##), the relying system is in a position to recompute the alleged digest #D'[i]#, as #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])#, where #H[i]()# is a MASH-2 function instance defined by the large composite modulus number #N[i]# and the prime number #p[i]#. The relying system SHOULD attempt to match the renewal message to a digest #D[i]=D'[i]# and to the initial self-signed certificate holding #D[i]#. If the renewal message contains a data element of the type AuthorityKeyIdentifier, and an integer data element holding the value #i#, they may be used to facilitate the matching process. A successful match completes the cryptographic validation step. Conversely, a relying system SHOULD ignore the renewal message as a bogus one if it fails the matching and cryptographic validation steps. Upon successful completion of the preceding steps, a relying system MAY accept #Cert'[i]#, or #Cert[i]# if #Cert'[i]# is absent, as a trusted certificate. 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. 5. Usage Rationale vs Long Term Trust Anchor Digest Validity This document section is informational. The traditional view of cryptographic key renewal is that a new key is generated when it is needed, i.e. shortly before its actual period of use so that it can Moreau Informational [page 7] Internet-Draft TAKREM-X.509 July, 2005 be distributed to relying parties. In the case of a trust anchor key, the distribution of a renewed key is a difficult problem. With the TAKREM proposal, en estimate of the lifetime of a trust anchor key application should be made (i.e. a conservative estimate of the end of usage for the last renewed trust anchor key before the application becomes totally obsolete). Then, a renewal period should be determined, plus an incident count estimation for emergency trust anchor renewal. This gives a reasonable upper limit on the number of trust anchor keys that will be needed for the life of the application secured by the trust anchor. With the proposed TAKREM, this number of public/private key pairs should be generated at once, pre-announced in the proprietary certificate extension, and safely set aside in a storage arrangement allowing the retrieval of public/private key pair data one at a time by custodians of the trusted organization. On a long-term perspective, this arrangement replaces the need to maintain a secure key generation system (e.g. evaluated with the Common Criteria, [CC1], [CC2], [CC3]) with the need to securely store key material which was generated at once. With this change, the key generation can be seen as a design and manufacturing process for security object (i.e. the bar code printout for the key material), in which case "process assurance" is substituted to a more comprehensive Common Criteria evaluation. 6. 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 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. The security principles behind the present mechanism suggest the Moreau Informational [page 8] 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 security or MASH parameter selection should follow the guidelines from normative reference [ISO10118-4]. 7. IANA Considerations This document has no actions for IANA. 8. References 8.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" 8.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 [CC1] Common Criteria Project Sponsoring Organizations, "Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model", January 2004, Version 2.2, Revision 256 [CC2] Common Criteria Project Sponsoring Organizations, "Common Criteria for Information Technology Security Evaluation, Part 2: Security functional requirements", January 2004, Version 2.2, Revision 256 Moreau Informational [page 9] Internet-Draft TAKREM-X.509 July, 2005 [CC3] Common Criteria Project Sponsoring Organizations, "Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements", January 2004, Version 2.2, Revision 256 9. Revision history >From version -00 to -01: o The public key in the TakremX509MashInput now includes the domain parameters - technical correction. o Some hints given for the use of ASN.1 format of renewal messages. o Defined the private extension OID. o Section 4 reorganized. o Added the explanation section 5. o Deleted text from the security considerations. o Miscellaneous editorial corrections. 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 Moreau Informational [page 10] Internet-Draft TAKREM-X.509 July, 2005 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. 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 11]