RFC 5636: Traceable Anonymous Certificate
In plain English — editorial summary, not part of the RFC
This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community.
Document record
- Document ID
- RFC5636
- Published
- August 2009
- Authors
- S. Park; H. Park; Y. Won; J. Lee; S. Kent
- Status
- EXPERIMENTAL
- Stream
- IETF
- Area
- sec
- Pages
- 31
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5913Clearance Attribute and Authority Clearance Constraints Certificate ExtensionCurrent
June 2010
- RFC 5924Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 CertificatesCurrent
June 2010
- RFC 5652Cryptographic Message Syntax (CMS)Updated
September 2009
- RFC 5653Generic Security Service API Version 2: Java Bindings UpdateObsoleted
August 2009
- RFC 5660IPsec Channels: Connection LatchingCurrent
October 2009
- RFC 5607Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) ManagementCurrent
July 2009
- RFC 5588Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated CredentialsCurrent
July 2009
- RFC 5587Extended Generic Security Service Mechanism Inquiry APIsCurrent
July 2009
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?