An RFC7169 use case (!)

[Thierry Moreau <[e-mail]>]

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