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

[Alan DeKok <[e-mail]>]

On Sep 20, 2016, at 12:06 PM, David Woodhouse <[e-mail]> wrote:
>> https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00
> 
> That looks like a layer above what I'm talking about. My goal is that
> we should be able to refer to certificates in a simple consistent way.
> 
> If the certificate is in a system store then applications should allow
> it to be used by means of a consistent identifier string (which is
> defined by RFC7512 for PKCS#11, and may be different for OSX/Windows
> system certificate stores).

  I think that the two solutions complement each other.

> Looking at the proposal above, I see there is some attempt to handle
> certificate encodings — it the CertEncodingEnum has values of PEM, DER,
> and P12.
> 
> This looks a lot like the problematic applications we need to fix...
> for PKCS#1 and PKCS#8 you have to manually specify whether it's PEM or
> DER file even though the software could work that out for itself. And
> for PKCS#12 you *don't* have to specify; it's going to assume DER. All
> very suboptimal.

  I agree.

> My assertion is that applications shouldn't *need* that nonsense, and
> should just take the filename and deal with the contents. Please don't
> entrench that horridness further.

  I understand, but... that's easier than scanning the file to see if it's one of N possible unknown formats.  And likely more secure.

> It also seems that the proposal you reference doesn't have any kind of
> support for using keys from hardware. If the key I want to use is
> identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this
> format?

  The proposal would need updating to handle that.

  Alan DeKok.