summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5708.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5708.txt')
-rw-r--r--doc/rfc/rfc5708.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc5708.txt b/doc/rfc/rfc5708.txt
new file mode 100644
index 0000000..22d7774
--- /dev/null
+++ b/doc/rfc/rfc5708.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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.
+
+
+
+Keromytis Informational [Page 1]
+
+RFC 5708 X.509 Encoding for KeyNote January 2010
+
+
+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].
+
+
+
+
+Keromytis Informational [Page 2]
+
+RFC 5708 X.509 Encoding for KeyNote January 2010
+
+
+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.
+
+
+
+
+
+Keromytis Informational [Page 3]
+
+RFC 5708 X.509 Encoding for KeyNote January 2010
+
+
+ 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:
+
+
+
+
+
+Keromytis Informational [Page 4]
+
+RFC 5708 X.509 Encoding for KeyNote January 2010
+
+
+ - "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.
+
+
+
+
+
+
+Keromytis Informational [Page 5]
+
+RFC 5708 X.509 Encoding for KeyNote January 2010
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keromytis Informational [Page 6]
+