Internet DRAFT - draft-moreau-pkix-takrem
draft-moreau-pkix-takrem
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 #<r[i],R[i]># 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
#<r[1],R[1]>#, #<r[2],R[2]>#, ... #<r[i],R[i]>#, ... #<r[n],R[n]>#
for #1<=i<=n# (#n# is defined in the previous document subsection).
For each key pair #<r[i],R[i]>#, 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)<p[i]<2^8j# for some
integer #j>=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 #<r[i],s[i],R[i],N[i],p[i]>#
(or #<r[i],s[i],Cert[i],N[i],p[i]>#) until the key pair
#<r[i],R[i]># 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
#<r[i],R[i]># 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 #<s[i],R[i],N[i],p[i]>#
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 #<s[i],Cert[i],N[i],p[i]>#, 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 #<s[i],R[i],N[i],p[i]># (or
#<s[i],Cert[i],N[i],p[i]>#) 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 #<s[i],R[i],N[i],p[i]># (or
#<s[i],Cert[i],N[i],p[i]>#), 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]
