Recommendations for applications using X.509 client certificates
draft-woodhouse-cert-best-practice-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | David Woodhouse , Nikos Mavrogiannopoulos | ||
| Last updated | 2024-01-26 (Latest revision 2023-07-25) | ||
| 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
X.509 certificates are widely used for client authentication in many protocols, especially in conjunction with Transport Layer Security ([RFC5246]) and Datagram Transport Layer Security ([RFC6347]. There exist a multitude of forms in which certificates and especially their corresponding private keys may be stored or referenced. Applications have historically been massively inconsistent in which subset of these forms have been supported, and what knowledge is demanded of the user. This memo sets out best practice for applications in the interest of usability and consistency.
Authors
David Woodhouse
Nikos Mavrogiannopoulos
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)