doc: Add RFC documents

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]
+