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