"Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP", Amit Kapoor, Ronald Tshalar, Tomi Kause, Martin Peylo, 30-Jul-09. ( bytes)

This document describes how to layer Certificate Management Protocols over various transport protocols.

"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", Denis Pinkas, 6-Feb-09. ( bytes)

This document describes the format of a request sent to a Time Stamping Unit (TSU) in order to get a time-stamp token and of the response that is returned. It also establishes several security- relevant requirements for the operation of a time-stamping service, with regards to processing requests to generate responses.

"Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Quynh Dang, 4-Aug-09. ( bytes)

This document updates RFC 3279 [RFC 3279] to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists(CRLs).

"New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 6-Apr-09. ( bytes)

The PKIX certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.

"Update for RSAES-OAEP Algorithm Parameters", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 9-Mar-09. ( bytes)

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field.

"Traceable Anonymous Certificate", Sanghwan Park, Haeryong Park, Yoojae Won, Jaeil Lee, Stephen Kent, 26-May-09. ( bytes)

Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers(e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. 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 [3]and CMC[4]. 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).

"Trust Anchor Management Requirements", Raksha Reddy, Carl Wallace, 4-Mar-09. ( bytes)

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.

"PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 13-May-09. ( bytes)

One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols.

"Other Certificates Extension", Stephen Farrell, 29-May-09. ( bytes)

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates belonging to the same end entity that can safely be considered to be equivalent for the purposes of referencing that application state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.

"Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 26-May-09. ( bytes)

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements.

"Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl Wallace, 20-Apr-09. ( bytes)

This document describes a transport independent protocol for the management of trust anchors and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate or TrustAnchorInfo objects.

"An Internet Attribute Certificate Profile for Authorization", Russ Housley, Stephen Farrell, Sean Turner, 27-Apr-09. ( bytes)

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281.

"Clearance Attribute and Authority Clearance Constraints Certificate Extension", Santosh Chokhani, Sean Turner, 26-Mar-09. ( bytes)

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject.

"OCSP Algorithm Agility", Phillip Hallam-Baker, Stefan Santesson, 31-Jul-09. ( bytes)

The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported.

"Internet X.509 Public Key Infrastructure: Certificate Image", Stefan Santesson, Russ Housley, Siddharth Bajaj, Leonard Rosenthol, 14-May-09. ( bytes)

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a [RFC5280] public key certificate by defining a new otherLogos image type according to [RFC3709].

"ASN.1 Translation", Carl Wallace, Charles Gardiner, 26-May-09. ( bytes)

Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF security area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules written using one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF security area specifications with focus on items that vary with the ASN.1 version.

Return to Internet-Draft directory.

Return to IETF home page.