X.509 Key and Signature Encoding for the KeyNote Trust Management System
RFC 5708
|
| Document |
Type |
|
RFC - Informational
(January 2010; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5708 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Tim Polk
|
|
Send notices to |
|
rfc-editor@rfc-editor.org
|
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.
Show full document text