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

[Sean Leonard <[e-mail]>]

On 9/26/2016 2:17 AM, David Woodhouse wrote:
> On Sun, 2016-09-25 at 18:48 -0700, Sean Leonard wrote:
>> Hello David:
>>
>> draft-seantek-certspec “Textual Specification for Certificates” is
>> exactly what you’re looking for.
>>
>> https://tools.ietf.org/html/draft-seantek-certspec-09
> Thanks; that's very interesting. I'm not sure it covers exactly the
> same use case, but it's very closely related.

Great!

>
>> That is for certificates. And yes, it handles pkcs11 just like
>> everything else.
> ... but not like RFC7512 does, I note. Is it worth trying to achieve
> some better consistency there? After all, I can *already* refer to the
> certificate in my crypto token consistently as
>
> 	'pkcs11:manufacturer=piv_II;id=%01'
>
> in a variety of applications using different crypto libraries. And in
> fact on my operating system of choice I can file a bug for any
> application which *doesn't* accept that string, when it would have
> taken a filename. So I'd definitely like to see your draft make
> explicit reference to RFC7512 in some form or other.

I can do that...although the value of doing so may be a bit lost on me. 
The general syntax would be:

URI:pkcs11:manufacturer=piv_II;id=%01

The syntax of "URI:uri" (with URI: prepended) has a long and tumultuous 
history. You can look at the draft history to see why.

Applications for draft-seantek-certspec are hunting for certificates on 
the order of sub-milliseconds: looking up a certificate could be done in 
a blocking operation. This would be the case, for example, when a TLS 
server (web server, IMAP server, etc.) or client boots up and needs the 
certificate before starting its first TLS connection. As a general 
matter, URIs strongly imply network access; therefore they are not as 
important as the other types of specs.

Any application that plans on using a certificate with its corresponding 
private key should obviously have the certificate on-hand and 
at-the-ready. Even if the private key is unavailable (e.g., the hardware 
token is not in the slot), some pointer that shows that a private key is 
known to be around, has to be immediately available. That way the UI can 
prompt the user for the right device.

A distinguishing feature of URIs is that it is limited in its repertoire 
of characters to a strict subset of ASCII, with % percent-encoding. This 
means that LDAP strings are going to look very convoluted, with a lot of 
%20, %2F, %3B, etc. throughout. If you want to permit users to specify 
strings without double or triple % encoding and \ escaping and whatnot, 
then I can buy an argument to promote "p11:" or similar to the top of a 
certspec, and not buried into the "URI:" spec type. There is precedent 
for this because there are already BASE64 and HEX specs, which duplicate 
URI:data: in functionality, but are demonstrably easier to use.

By the way, RFC 7512 contains a serious bug: the | character is not 
valid in URI [RFC3986]. I don't know how that character snuck through 
the RFC process, but it's not a valid URI.

RFC 7512 contains a second, less serious bug: "The URI scheme does not 
use the fragment component." Well that may or may not be good advice. I 
don't see why a PKCS #11 token can't return a blob that is plain text 
(text/plain), in which case, fragment would be defined by RFC 5147. 
Furthermore, PKCS #11 is actually Internet media type-aware: see 
CKA_MIME_TYPES, for example, in that standard.

>
>> ***
>>
>> Private keys are another matter. The approach could easily be
>> extended to handle private keys. They are just identifiers, after
>> all. However, by definition secure private keys are a “local matter”.
>> I do not see the value of standardizing an identifier for private
>> keying materials when the implementations are all different and are
>> not supposed to communicate with each other.
> Ah, but that is *precisely* the matter I was most concerned about. It's
> not so much about implementations communicating with each other; it's
> about consistency and (hence) usability.
>
> Not very long ago, in order to use that key in the crypto token I
> mentioned above, I had to do something *different* for fairly much
> every application:
>
>   • for OpenVPN, I had to manually specifier the PKCS#11 provider
>     module and use one form of identifier string.
>   • for OpenConnect, RFC7512 identifiers Just Worked, and it used
>     the PKCS#11 providers indicated by the system configuration. (Yay!)
>   • for Curl (if built with NSS) I needed to manually edit configuration
>     files to make it load the right module, and then refer to the
>     object by a *third* form of identifier string.
>   • for wpa_supplicant I had to manually configure it to use an OpenSSL
>     "Engine", specify the provider in yet *another* different manner
>     because that also ignored the system configuration, and then give
>     the certificate ID in a *fourth* different form.
>
> And that was just for the applications which *could* use PKCS#11. Many
> just couldn't do it at all. And for some, they needed to be configured
> differently depending on which crypto library they'd been built
> against.
>
> It made me kind of sad. FWIW I have all of the above just taking
> PKCS#11 URIs according to RFC7512 now, without any of the additional
> configuration nonsense like loading engines and specifying provider
> modules.

That is indeed a list of horribles.

But for applications that are PKCS #11 based, one could easily write a 
script that takes a pkcs11: URI as input and outputs the right flips, 
switches, config files, and API calls to do what the pkcs11: URI is 
saying to do. Probably would take less than a day.

For applications that are *not* PKCS #11 based (macOS Keychain Services, 
Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't know 
of a better way to put it.

>
> Now, *part* of that is addressed by your draft (although it's already
> addressed by RFC7512 in the case of PKCS#11, and the conflicts there
> want resolving). But other parts are not — and I'm not sure you really
> want to expand your scope to cover them. They include:
>
>   • Using the system configuration for which PKCS#11 providers to load.
>   • The search algorithm, identifying when to log in to a token to
>     attempt to find a certificate with CKA_PRIVATE and how to locate
>     the key corresponding to a given certificate, etc.
>   • The requirement that opaque private keys without access to the
>     corresponding public key SHALL work.
>
> That's just for PKCS#11. of course. For files there are a different set
> of issues — mostly the fact that every application on the system will
> currently support a *different* subset of private key file formats. So
> a user with a certificate+key provisioned through her organisation's
> proprietary scripting will find that it works with *some* applications
> and not others, for reasons which are entirely intractable, such as:
>
>   • It uses the non-standard OpenSSL 'encrypted PEM' format.
>   • It uses a SHA256 HMAC which isn't universally supported.
>   • It is encrypted with DES-MD5, which isn't universally supported.
>   • It is in DER form, which applications need to jump through hoops
>     to cope with loading because crypto libraries hate us all.
>
> The idea of my draft is to give a set of "best practice" guidelines for
> applications so that the user *can* just use the same certificate and
> key with any well-behaved application, with exactly the same
> identifier, and it will Just Work.
>
> It's not *just* about the identifier though, and in fact I've mostly
> tried to make it *not* about the identifier. I just defer to RFC7512
> and obviously to filenames. For the system certificate stores I just
> say that if a convention exists, it should be supported — and it sounds
> like your draft would be the ideal solution to fill that gap.
>
> So while there is certainly an overlap with your draft, there's also a
> lot to cope with that *isn't* already the primary target of your draft.

Okay. Yes, the primary target of the draft is identifying certificates 
(uniquely and unambiguously), and providing associated attributes with 
the certspec. Interestingly, one of those "associated attributes" could 
very well be: "hint or directive about where to find the private key". 
So that is a point of extension that we could collaborate on, whether in 
draft-seantek-certspec or in a related draft.

For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo 
(as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are 
standardized, widely-supported, and algorithm-agile. They are also 
simple enough that even if a crypto stack doesn't support them directly, 
"adapters" can be built that shoehorn the data into other container 
formats, such as PKCS #12, OpenSSL's proprietary formats, and so on. 
(Note that I worked on the registrations for both application/pkcs12 and 
application/pkcs8-encrypted.)

> If you want, I'm happy to work with you to *make* your draft cover
> this. But I suspect there would be sufficient conflict in our use cases
> that it's best just to ensure that they complement each other to
> achieve their respective goals. What do you think?

I am happy to make draft-seantek-certspec more useful to different 
constituents!

The focus needs to remain on uniquely identifying cryptographic data 
items, rather than as a generalized querying format. (Discussed in 
draft.) However, I like the idea of a standardized attribute that points 
to the location of a private key. Such an attribute could also be 
conveniently serialized into other formats, e.g., as attributes in PKCS 
#11 and PKCS #12, and as Certificate Properties in Microsoft CryptoAPI. 
That is exactly how crypto stacks operate anyway: they tag a certificate 
with a little pointer that points to where to find the private key, if 
one exists.

>
> For reference, the current version of my nascent draft is at
> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html and
> it's also at https://github.com/dwmw2/ietf-cert-best-practice

Thanks, I read it.

>
>> You can, of course, always refer to a private key indirectly, by
>> referencing an associated certificate. It is very plausible to
>> identify a certificate stored in a local file (that does not need to
>> be encrypted), and then to look up the associated private key on a
>> token that has a lot more protection around the key, by using the
>> certificate or its metadata as the dbkey/index.
> Yes, there is lots of fun to be had here. Lots of reasonable heuristics
> for how to find a key given the certificates — and thus lots of scope
> for applications to be inconsistent and for users to complain "it works
> in XXX, so why doesn't exactly the same cert work in YYY?".
>
> I've attempted to address this with the search algorithm for PKCS#11.
> For files there's not a lot you can do although I do mention that if
> the cert has extension '.crt' and doesn't actually contain the private
> key, you might look for a corresponding file with extension 'key'.
>
> There are probably more improvements that can be made in this area,
> especially when it comes to the system stores on Windows and OSX.

Okay.

>> [The aforementioned paragraph is also responsive to Ted Lemon’s
>> concern: “one concern I have about it is that we actually really
>> don't want applications to have access to private keys.”]
> Yes, we absolutely need to support and encourage that use case. That is
> part of my motivation for pushing to have PKCS#11 supported
> consistently across applications on platforms where that's the best
> answer.

Good.

Regards,

Sean