X.509 Key and Signature Encoding for the KeyNote Trust Management System
How KeyNote credentials can name an X.509 certificate as a key, and which hash functions their signatures may use.
Keromytis, A., "X.509 Key and Signature Encoding for the KeyNote Trust Management System", RFC 5708, DOI 10.17487/RFC5708, January 2010, <https://www.rfc-editor.org/info/rfc5708>.
@misc{rfc5708,
series = {Request for Comments},
number = 5708,
howpublished = {RFC 5708},
publisher = {RFC Editor},
doi = {10.17487/RFC5708},
url = {https://www.rfc-editor.org/info/rfc5708},
author = {A. Keromytis},
title = {{X.509 Key and Signature Encoding for the KeyNote Trust Management System}},
pagetotal = 6,
year = 2010,
month = jan,
} RFC text
Contents
Independent Submission A. Keromytis
Request for Comments: 5708 Columbia University
Category: Informational January 2010
ISSN: 2070-1721
X.509 Key and Signature Encoding for the
KeyNote Trust Management System
Abstract
This memo describes X.509 key identifiers and signature encoding for
version 2 of the KeyNote trust-management system (RFC 2704). X.509
certificates (RFC 5280) can be directly used in the Authorizer or
Licensees field (or in both fields) in a KeyNote assertion, allowing
for easy integration with protocols that already use X.509
certificates for authentication.
In addition, the document defines additional signature types that use
other hash functions (beyond the MD5 and SHA1 hash functions that are
defined in RFC 2792).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5708.
Copyright Notice
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.
1. Introduction
KeyNote is a simple and flexible trust-management system designed to
work well for a variety of large- and small-scale, Internet-based
applications. It provides a single, unified language for both local
policies and credentials. KeyNote policies and credentials, called
'assertions', contain predicates that describe the trusted actions
permitted by the holders of specific public keys. KeyNote assertions
are essentially small, highly structured programs. A signed
assertion, which can be sent over an untrusted network, is also
called a 'credential assertion'. Credential assertions, which also
serve the role of certificates, have the same syntax as policy
assertions but are also signed by the principal delegating the trust.
Note that only one principal may sign a credential assertion, but
trust may be delegated to multiple principals. The credential
assertion may delegate trust to each of these principals separately
or to groups of principals required to act together. For more
details on KeyNote, see [KEYNOTE]. This document assumes reader
familiarity with the KeyNote system.
Cryptographic keys may be used in KeyNote to identify principals. To
facilitate interoperation between different implementations and to
allow for maximal flexibility, keys must be converted to a normalized
canonical form (dependent on the public key algorithm used) for the
purposes of any internal comparisons between keys. For example, an
RSA key may be encoded in base64 [RFC4648] ASCII in one credential
and in hexadecimal ASCII in another. A KeyNote implementation must
internally convert the two encodings to a normalized form that allows
for comparison between them. Furthermore, the internal structure of
an encoded key must be known for an implementation to correctly
decode it. [RFC2792] describes the RSA and DSA (Digital Signature
Algorithm) key identifier and signature encodings for use in KeyNote
assertions. This document specifies a new key identifier, allowing
X.509 certificates [RFC5280] to be used as a key substitute wherever
an RSA or DSA key may be used in KeyNote. Specifically, KeyNote will
use the key associated with the subject of an X.509 certificate. In
addition, this document defines a corresponding signature encoding,
to be used in conjunction with X.509 key identifiers. Finally, this
document defines new signature encodings that use new hash functions
beyond the MD5 and SHA1 functions defined in RFC 2792, and which in
recent years have been found to be vulnerable to attack.
1.1. Conventions
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 RFC 2119 [RFC2119].
2. X.509 Key Identifier Encoding
X.509 key identifiers in KeyNote are encoded as an ASN1 Distinguished
Encoding Rules (DER) encoding of the whole X.509 certificate, as
defined in Section 4 of [RFC5280].
For use in KeyNote credentials, the ASN1 DER-encoded object is then
ASCII-encoded (e.g., as a string of hex digits or base64 characters).
X.509 keys encoded in this way in KeyNote must be identified by the
"x509-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
"base64"). Other ASCII encoding schemes may be defined in the
future.
3. X.509 Key Identifier Normalized Forms
For comparison purposes, the Subject public key in X.509 certificates
is used in the normalized form described in Section 2 of [RFC2792].
The resulting RSA or DSA key is then used for comparing, per
[RFC2792]. All X.509 key comparisons in KeyNote occur between
normalized forms. Note that this allows for comparison between a
directly encoded RSA or DSA key (as specified in RFC 2792) and the
same key when contained in an X.509 certificate.
4. X.509 Signature Computation and Encoding
X.509 key identifier signatures are defined for historical reasons.
Implementers are encouraged to use the RSA- or DSA-based signature
encodings instead.
X.509 key identifier signatures in KeyNote are identical to RSA- or
DSA-based signatures [RFC2792]. The only difference is that the
public key corresponding to the private key that generated the
signatures is encoded in an X.509 certificate in the Authorizer field
of the signed credential assertion. However, an RSA- or DSA-based
signature encoding (depending on the Subject key contained in the
X.509 certificate itself) may be used instead.
X.509 key identifier signatures in KeyNote are computed over the
assertion body (starting from the beginning of the first keyword, up
to and including the newline character immediately before the
"Signature:" keyword) and the signature algorithm name (including the
trailing colon character, e.g., "sig-x509-sha512-base64:")
X.509 key identifier signatures are encoded as an ASN1 OCTET STRING
object, containing the signature value.
For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-
encoded (as a string of hex digits or base64 characters).
X.509 key identifier signatures encoded in this way in KeyNote must
be identified by the "sig-x509-XXX-YYY:" algorithm name, where XXX is
a hash function name (see Section 5 and Section 7 of this document)
and YYY is an ASCII encoding ("hex" or "base64").
5. Hash Functions For RSA, DSA, and X.509 Key Identifier Signatures
For historical reasons (backward compatibility), X.509 key identifier
signatures SHOULD support SHA1 as the hash function, using the "sha1"
keyword. In addition, SHA256, SHA512, and RIPEMD160 ([SHA256+],
[SHA2-2], [RIPEMD-160]) signatures MUST be supported for use with
X.509 key identifier signatures, by using the "sha256", "sha512", and
"ripemd160" keywords, respectively (see Section 7).
In addition, SHA256, SHA512, and RIPEMD160 signature identifiers are
defined for RSA signatures, using the "sha256", "sha512", and
"ripemd160" keywords, respectively (see Section 7).
6. Security Considerations
This document discusses the format of X.509 keys and signatures as
used in KeyNote. The security of KeyNote credentials utilizing such
keys and credentials is directly dependent on the strength of the
related public key algorithms. On the security of KeyNote itself,
see [KEYNOTE]. Furthermore, it is the responsibility of the
application developer to ensure that X.509 certificates are valid
(signed by a trusted authority, not expired, and not revoked).
The use of SHA1 as part of signatures and key identifiers is
discouraged, because of the various weaknesses in the algorithm that
have been identified in recent years.
7. IANA Considerations
Per [RFC2792], IANA has provided a registry of reserved algorithm
identifiers. The following are reserved by this document as KeyNote
public key format identifiers:
- "x509-hex"
- "x509-base64"
The following are reserved by this document as KeyNote signature
algorithm identifiers:
- "sig-x509-sha1-hex"
- "sig-x509-sha1-base64"
- "sig-x509-sha256-hex"
- "sig-x509-sha256-base64"
- "sig-x509-sha512-hex"
- "sig-x509-sha512-base64"
- "sig-x509-ripemd160-hex"
- "sig-x509-ripemd160-base64"
- "sig-rsa-sha256-hex"
- "sig-rsa-sha256-base64"
- "sig-rsa-sha512-hex"
- "sig-rsa-sha512-base64"
- "sig-rsa-ripemd160-hex"
- "sig-rsa-ripemd160-base64"
Note that the double quotes are not part of the algorithm
identifiers.
8. References
8.1. Normative References
[SHA256+] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
8.2. Informative References
[KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and A.
Keromytis, "The KeyNote Trust-Management System Version
2", RFC 2704, September 1999.
[RFC2792] Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA
Key and Signature Encoding for the KeyNote Trust
Management System", RFC 2792, March 2000.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RIPEMD-160] 3.ISO/IEC 10118-3:1998, "Information technology -
Security techniques - Hash-functions - Part 3: Dedicated
hash-functions," International Organization for
Standardization, Geneva, Switzerland, 1998.
[SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
May 2001, <http://csrc.nist.gov/publications/fips/
fips180-3/fips180-3_final.pdf>.
9. Acknowledgements
The author would like to thank Jim Schaad for his review and comments
on earlier versions of this document.
Author's Address
Angelos D. Keromytis
Department of Computer Science
Columbia University
Mail Code 0401
1214 Amsterdam Avenue
New York, New York 1007
USA
EMail: angelos@cs.columbia.edu
AI ELI5
On this page
§1Why KeyNote Needs X.509 Keys
KeyNote is a trust-management system built around assertions: small, highly structured programs that say which actions the holders of specific public keys are allowed to perform. A signed assertion, called a credential assertion, can be sent over an untrusted network and plays the role of a certificate. See RFC 2704 for KeyNote itself; this RFC assumes the reader already knows it.
Keys in KeyNote identify principals, and implementations must convert them to a normalized form before comparing them. RFC 2792 covers RSA and DSA keys. This RFC adds a key identifier so that an X.509 certificate (RFC 5280) can be used wherever an RSA or DSA key could be, and it defines signature encodings that go with it. It also adds signature types using hash functions beyond MD5 and SHA1, which have been found vulnerable to attack in recent years.
KeyNote rules say which keys may do which jobs. This document lets a digital ID card stand in for a key, so systems that already use ID cards can talk to KeyNote.
§2Encoding and Comparing X.509 Keys
An X.509 key identifier is the ASN.1 Distinguished Encoding Rules (DER) encoding of the whole certificate, as defined in Section 4 of RFC 5280. For use in a KeyNote credential, that binary object is turned into ASCII text, either hex digits or base64 characters. The algorithm name written in front of it is x509-hex: or x509-base64:. Other ASCII encodings may be defined in the future.
For comparison, KeyNote takes the Subject public key out of the certificate and uses it in the normalized form from Section 2 of RFC 2792. All X.509 key comparisons happen between normalized forms. A directly encoded RSA or DSA key and the same key inside an X.509 certificate therefore compare as equal.
The whole ID card is turned into a long string of letters and numbers. When KeyNote compares two cards, it only looks at the key printed on them, so a card and a bare key can still match.
§3Signatures and Hash Functions
X.509 key identifier signatures are computed just like RSA or DSA signatures from RFC 2792. The difference is that the signer's public key is carried in an X.509 certificate in the Authorizer field. The RFC says these signatures exist for historical reasons and that implementers are encouraged to use the RSA- or DSA-based encodings instead.
The signature covers the assertion body, from the first keyword up to and including the newline before Signature:, plus the signature algorithm name including its trailing colon, such as sig-x509-sha512-base64:. It is encoded as an ASN.1 OCTET STRING and then written as hex or base64. The algorithm name has the form sig-x509-XXX-YYY:, where XXX is the hash function and YYY is hex or base64.
On hashes, X.509 signatures SHOULD support sha1 for backward compatibility. They MUST support sha256, sha512 and ripemd160. The same three hash keywords are also defined for RSA signatures.
A signature is a seal on the rule. The seal can be made with several different fingerprint recipes. The old SHA1 recipe is still allowed for old systems, but newer, stronger recipes are required.
§4Registered Identifiers
Following RFC 2792, IANA keeps a registry of reserved algorithm identifiers. This RFC reserves two public key format identifiers, x509-hex and x509-base64.
It also reserves fourteen signature algorithm identifiers: sha1, sha256, sha512 and ripemd160 variants of sig-x509- in both hex and base64 forms, plus sha256, sha512 and ripemd160 variants of sig-rsa- in both forms. The double quotes shown in the list are not part of the identifiers.
The document puts new names on an official list so everyone uses the same labels for the same recipes.
- x509-hexKey format — DER-encoded X.509 certificate written as hex digits.
- x509-base64Key format — DER-encoded X.509 certificate written as base64.
- sig-x509-XXX-YYYX.509 signature — XXX is sha1, sha256, sha512 or ripemd160; YYY is hex or base64.
- sig-rsa-XXX-YYYRSA signature — XXX is sha256, sha512 or ripemd160; YYY is hex or base64.
§5Security Considerations
The security of credentials that use these keys depends directly on the strength of the public key algorithms involved. For the security of KeyNote itself, the RFC points to RFC 2704.
Validity of the certificate is not handled by KeyNote here: the application developer is responsible for ensuring that X.509 certificates are signed by a trusted authority, not expired, and not revoked. The use of SHA1 in signatures and key identifiers is discouraged because of weaknesses found in the algorithm in recent years.
An ID card is only as good as the check you make on it. The program using it must make sure the card is real, current and not cancelled, and should avoid the old, weak fingerprint recipe.