RFC 6042: Transport Layer Security (TLS) Authorization Using KeyNote
In plain English — editorial summary, not part of the RFC
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.
Document record
- Document ID
- RFC6042
- Published
- October 2010
- Authors
- A. Keromytis
- Status
- INFORMATIONAL
- Stream
- INDEPENDENT
- Area
- —
- Pages
- 7
- Also known as
- —
- Updated by:
- RFC 8996
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9200Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)Current
August 2022
- RFC 9201Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)Current
August 2022
- RFC 9203The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) FrameworkCurrent
August 2022
- RFC 9548Generating Transport Key Containers (PFX) Using the GOST AlgorithmsCurrent
May 2024
- RFC 6024Trust Anchor Management RequirementsCurrent
October 2010
- RFC 6010Cryptographic Message Syntax (CMS) Content Constraints ExtensionCurrent
September 2010
- RFC 5849The OAuth 1.0 ProtocolObsoleted
April 2010
- RFC 5779Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter ServerCurrent
February 2010
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?