From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5708.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc5708.txt (limited to 'doc/rfc/rfc5708.txt') 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, . + +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] + -- cgit v1.2.3