An RFC7169 use case (!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear IETF'ers:

Notwithstanding the fact that the RFC7169 and the -02 revision to the Internet Draft draft-housley-pkix-oids are at face value April fool publications in the IETF tradition, the informational X.509 certificate extension does have a specific use case in the context of "first party certification" paradigm.

My purpose is neither to document the underlying trust arrangements and security mechanisms (as I did in the ill-fated draft-moreau-pkix-aixcm-00 or http://www.connotech.com/public-domain-aixcm-00.txt), neither to argue about their value, nor to propose an RFC7169bis draft that would fix the semantic deficiencies in the RFC7169 as published. My only purpose is to give notice to IETF'ers that RFC7169 does have an unintended usefulness.

Nonetheless, here is a high level description for the reader who would accept to offload the preconceived notions of PKI trust model. A TLS server in the "first party certification" paradigm accepts (or denies) a TLS client identity based on the sole client public key found in the TLS handshake (the server denies client access if an unknown public key is presented). Because bare client public keys are not well supported (if allowed at all) by the fielded TLS implementations, the TLS client has to package the public key in a so-called "client certificate." However, obtaining a proper PKI client certificate is an undertaking in the Internet era similar to the Peary and Scott treks to the North Pole in the nineteen century (neither of them were able to provide reliable evidence of their achievements). The first party certification paradigm relieves the client from the requirement for a proper client certificate. The remaining are implementation details. Self-signed client certificates has been proposed for this purpose (if I recall correctly some PKIX discussions a few years back). I proposed self-issued client certificates, which involves a "dummy certification authority," i.e. with a publicly breached signature key pair and for which the RFC7169 certificate extension applies. If the reader follows the reasoning, it becomes evident that anyone can act (sign security certificates) on behalf of the dummy CA, including the TLS client implementation (just like anyone can issue a self-signed certificate).

Thus I am grateful to the RFC7169 author and to the IETF for an official certificate extension in support of the first party certification paradigm, offering an RFC-compliant alternative to the client self-signed certificates.

It may me the first time that an April fool RFC is actually useful.

Regards,

-- Thierry Moreau





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]