LDAP Controls for Reply Signatures
draft-salzr-ldap-repsig-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Rich Salz | ||
| Last updated | 2000-05-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In many environments the final step of certificate issuance is publishing the certificate to a repository. Unfortunately, there is no way for a Certification Authority (CA) to have a secure application-level acknowledgement that the proper repository did, in fact, receive the certificate. This issue is of greater concern when considering the publication of Certificate Revocation Lists (CRLs) -- if an adversary manages to interpose itself between the CA and its intended repository, then clients could end up relying on outdated revocation lists. This document defines a set of controls so that an LDAP client, such as a CA, can receive a cryptographically secure acknowledgement that an LDAP server has received a request, and that the integrity of the server's reply has not been compromised. Whenever possible, the definitions here use mechanisms and datatypes defined by the IETF PKIX working group. This document references RFC 2459 [RFC2459]. Knowledge of the RFC is required for proper implementation of this document, although it should be possible to understand this document without much knowledge of that RFC. It is expected that future versions of this document will reference 2459's successor(s).
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)