"Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Quynh Dang, 19-Jun-08. ( bytes)
This document supplements RFC 3279. It specifies 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).
"Elliptic Curve Cryptography Subject Public Key Information", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 22-Sep-08. ( bytes)
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5, 3, and 5 of RFC 3279.
"New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 10-Jul-08. ( 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, 1-May-08. ( 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 with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature 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, 4-Jun-08. ( 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 protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs).
"Trust Anchor Management Requirements", Raksha Reddy, Carl Wallace, 3-Oct-08. ( 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 protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered.
"PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 2-Jul-08. ( 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-Sep-08. ( 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.
"Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08. ( bytes)
This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints X.509 certificate extension. This extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a protected content. In particular, the CMS content constraints certificate extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this certificate extension indicates the content types that the certified public key is authorized to validate. If the authorization check is successful, the CMS content constraints certificate extension also provides default values for absent attributes.
"Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08. ( bytes)
This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented 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 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 and for use within the context of the Trust Anchor Management Protocol (TAMP).
"Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08. ( 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.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.