Re: [Secdispatch] Best practices for applications using X.509 client certificates

[Michael Richardson <[e-mail]>]

David Woodhouse <[e-mail]> wrote:
    > There is a distinct lack of consistency across applications which use
    > client certificates for authentication. It confuses users and hurts
    > adoption of more secure methods of key storage, especially TPMs and
    > hardware/software tokens accessed via PKCS#11.

    > Following a discussion on the SAAG list in 2016, I drafted a document
    > describing "best practices" for applications:

    > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

Will you submit your XML to the datatracker?

    > The gist of it is, "this stuff should Just Work". Whatever form I get

I sure like that simple summary.

    > my cert+key in from the baroque outdated corporate infrastructure that
    > issues them — as long as it's not *completely* unreasonably insane — I
    > should just be able to give that to *any* application and expect it to
    > work.

Yeah, except for use of EKUs that I really find silly for client
certificates. It's hard enough getting indivuals and enterprises to pay the
client side certificate tax, it seems like we ought to maximize the investment.

    > That goes for files containing PKCS#1, PKCS#8, PKCS#12 or even TPM-
    > wrapped keys. And in place of a filename I should be able to pass a
    > reference like a RFC7512 PKCS#11 URI (or similar identifiers for system
    > key stores or TPM internal storage) and *that* should just work too.

Do we need a standard for which URI scheme to use?
You write:

} There are a number of forms which a certificate identifier might
} take. Applications MAY require that the user explicitly disambiguate
} between an inline data blob as discussed in Section 4.2, and an identifier
} which is merely a reference to the location of the object, such as a
} filename or other identifier addressed in the other subsections below.

and we have did:, ni:, file: and also data:

    > We've had a little bit of success over the years in making life better
    > for users. It's now more common for applications to automatically
    > accept a PKCS#11 URI in place of a filename, for example, and we've
    > defined a standard file format for TPMv2.0 key storage which is
    > interoperable between the two OpenSSL provider/engines and GnuTLS
    > implementations.

That's awesome.

    > I've just updated the above draft to reference the TPMv2 support, and
    > I'd like work out what it would take to submit it as an actual I-D. As
    > noted by Ted Lemon last time, the challenge would be socializing it to
    > the people who need to read it. Publishing it through the IETF as an
    > informational RFC would certainly be better than sticking it on my own
    > web page in draft form.

The IETF is definitely a good place to start.
Standards Track RFC can be cited as performance specifications in RFP
(according to many trade treaties).  That's relevant because it allows an
entity (typically, a government) to be very clear about what they want.
That might also get things like OpenSSL fixed, (section 7/7.1).

I suggest that your document should be standards track.
Or BCP, which can also have force of law, while Informational does not.
(Not that trade agreement lawyers understand the distinction, but still)

    > There's plenty of technical heckling to be done on the content, for
    > sure, but also a process question there.

So, I would rewrite the document slightly, for each place where we have
options, I suggest that we have a list of things that application SHOULD
accept, and where multiple options exist, about what they SHOULD emit by
default.

    > I posted this again to the SAAG list today for further feedback, and
    > Rich Salz suggested I bring it to the SECDISPATCH WG for a view on next
    > steps. Thus...

A trip through secdispatch is probably worthwhile and inline with current
practices, but I would dispatch it to LAMPS.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*