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

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 20:28:24 -0500

On Tue, Sep 20, 2016 at 08:29:51PM -0400, Michael Richardson wrote:
> David Woodhouse <[email-masked]> wrote:
>     > And looking beyond files: if I go and purchase a hardware crypto device
>     > like a Yubikey, and plug it into my system. I install the OpenSC
>     > package which has a PKCS#11 provider module for it, and provision a key
>     > in it.... now, how do I use it?

That's what RFC7512 is for!  But you knew this :)

>     > The answer should be simple. I determine a RFC7512 identifier for the
>     > key I want to use (e.g. 'pkcs11:manufacturer=piv_II;id=%01') and then
>     > every application in the system SHOULD just accept that identifier in
>     > place of a filename.
> 
> yes, that would be great. Maybe we need to register the pkcs11: URI, such
> that we can then say it's a URI, and file:// would also naturally work.

Did you mean "register the PKCS#11 URI _scheme_"?  That's what RFC7512
does.

Incidentally, PKCS#11 works reasonably well for these things, even
though there isn't an exact mapping to PIV cards.  This affects token
selection, which is a problem because if you pick the wrong token you
might end up locking it out.

If multi-seat, multi-user systems were still common, the token selection
problem would be even more relevant.  Fortunately multi-seat is mostly a
thing the past.  Though those could come back.

Even without multi-seat in the picture there can be multiple tokens on a
system:

 - a TPM
 - some other non-removable token
 - one or more removable tokens (a user might have more than one)
 - soft tokens

Token selection is a non-trivial task.

I've seen a fair amount of variability by token.  Problems that make the
token selection harder:

 - tokens that have useless labels
 - tokens that also have no public objects (or none with user
   identifying data, such as certs)

To a large degree PKCS#11 URIs help address this: you write a URI for
the token and object(s) you want to use.  Of course, that is still deep
magic for many users and admins...  They really should not have to.  But
there are many tokens that must be used via their own PKCS#11 providers,
so PKCS#11 URIs are pretty much the only way to bridge the gap.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 20:44:15 -0500

On Thu, Sep 22, 2016 at 08:01:05PM +0100, David Woodhouse wrote:
> Is that what you were after? I did consider writing that one down too,
> but figured it was a little too esoteric. And perhaps we should have
> exposed the TPM via a PKCS#11 provider in the first place anyway.

PKCS#11 all the way please.  It's a clunky API, sure, but it is the one
that's most widely implemented, both in terms of apps and providers.

And we absolutely need a few decent PKCS#11 URI implementations.

> > [...]
> 
> I absolutely agree that applications MUST NOT rely on having access to
> the actual private key material. They need to support using opaque keys
> from hardware and software tokens. But I was envisaging that PKCS#11
> would be the vehicle for that.

Yes.  PKCS#11 pls.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 20:45:19 -0500

On Thu, Sep 22, 2016 at 03:26:10PM -0400, Ted Lemon wrote:
> Well, here is the reason that I carefully said "not a security expert"
> earlier.   I suspect that PKCS#11 is a better answer than a shim.   Thanks
> for the clue stick!

PKCS#11 *is* a shim.  But one with a standard API.

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 20:50:46 -0500

On Tue, Sep 27, 2016 at 10:15:56AM +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse <[email-masked]> wrote:
> >> This is surprising, because RFC 7512 Section 4.1. registers it as a
> >> permanent URI scheme in the Permanent URI Schemes Registry. =:-O
> >>
> >> I thought that the whole point of a document called "The PKCS #11 URI
> >> Scheme" would be to make PKCS #11 items accessible in URI protocol
> >> slots, and conversely, to make URI protocol slots useful to PKCS
> >> #11-consuming applications (in addition to other URI items such as http:
> >> , ldap: , data: , etc.).
> > Perhaps that was the intent; we would have to ask its authors. I cannot
> > tell. But it doesn't seem stunningly useful in that form to me.,

That was absolutely the intent: to make it possible to write PKCS#11
applications that can be "configured" in a common manner.  (I was
involved in the review process, as well as early on before any I-Ds were
submitted.)  In particular, it's nice to have a string that can be
cut-n-pasted and written into config files, passed into command-lines,
...

> I am not one of the authors, but I participated in the drafting of
> that document. The intent was to provide a consistent way for
> applications to access objects stored in PKCS#11 tokens. A URI (a
> string of characters identifying a resource) seemed the appropriate
> way to do it.

> >>URIs are meant for Internet-accessing things
> 
> Not the PKCS#11 URI.

Nor file: URIs.

Anyone who doesn't like this can say that PKCS#11 URIs aren't, that they
are something else that looks and smells like a URI.

Though, you know, there are "PKCS#11 agents" for accessing remote
tokens.  Of course, to the application the resource still looks local.
But to the user it is remote.  This makes the PKCS#11 URI scheme a
rather reasonable thing to has as a URI scheme.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 17 Apr 2017 02:18:58 +0000

>And we absolutely need a few decent PKCS#11 URI implementations.

That was going to be my response to your previous message, pointing to a spec
that nothing seems to implement isn't terribly useful.  Is there any
freely/publicly-available implementation that supports it?  More to the point,
are there several of them so I generalise their usage to see how to apply it
to typical devices in the field?

Peter.

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 22:44:57 -0500

On Mon, Apr 17, 2017 at 02:18:58AM +0000, Peter Gutmann wrote:
> That was going to be my response to your previous message, pointing to
> a spec that nothing seems to implement isn't terribly useful.  Is
> there any freely/publicly-available implementation that supports it?
> More to the point, are there several of them so I generalise their
> usage to see how to apply it to typical devices in the field?

There appear to be a number of implementations.

A few minutes searching turned up a few things.  Most aren't standalone
PKCS#11 URI implementations, rather they are embedded in larger
projects:

 - p11-kit (https://github.com/p11-glue/p11-kit) (BSD 3-clause, no advertising clause)

 - NSS?
    - http://www.mail-archive.com/[email-masked]/msg12633.html
    - https://github.com/varunnaganathan/nss

 - http://arunnsblog.com/tag/native-pkcs11/

 - GnuTLS?
    - http://man7.org/linux/man-pages/man1/p11tool.1.html
    - https://www.gnu.org/software/gnutls/clang/report-sQaOHg.html

 - libcryptoutil (Illumos) (this one is standalone, and is CDDL'ed)
   http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libcryptoutil/

 - http://www.pkcs11interop.net/extensions/uri/

And a few others.

So it seems there's at least a few implementations, and at least one
standalone one.

Now, we should probably talk (maybe not here though, right?) about what
a PKCS#11 URI implementation really entails.  The bare minimum would be
this:

 - parse(URI) -> parsed form

 - open(URI) -> PKCS#11 module handle, session handle, object handle

   (May require interaction to prompt for PIN.)

 - search(partial URI) -> set of {module, [session], [object]} handles?

Ideally also:

 - a "guru" UI for constructing and inspecting URIs

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 22:50:45 -0500

On Tue, Sep 20, 2016 at 12:36:01PM -0400, Alan DeKok wrote:
> On Sep 20, 2016, at 12:06 PM, David Woodhouse <[email-masked]> wrote:
> > 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.

We really need to push PKCS#11 URIs.  It's the only hope we have to make
sense of the configuration mess.

Got private keys lying around in whatever format?  Use a softtoken.

Got private keys in a TPM or other HW?  Use an appropriate PKCS#11
provider.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Apr 2017 22:57:45 -0500

On Mon, Sep 26, 2016 at 11:43:41PM +0100, David Woodhouse wrote:
> On Mon, 2016-09-26 at 14:55 -0700, Sean Leonard wrote:
> > When I use cryptographic tokens such as smart cards, the private key 
> > never leaves the token. So, there is no password: it's irrelevant. 
> > Sometimes the token is configured with a PIN, but the PIN is not the 
> > subject of this PKCS #8 EncryptedPrivateKeyInfo discussion.
> 
> Well... looking a bit further back in the thread (or indeed at
> $SUBJECT), this was about application best practice. And I probably
> *do* need to look at what to do with non-ASCII PINs and C_Login().

_That_ you have to take to OASIS.  Consensus _here_ is nice, but it's
needed _there_.

There's basically these choices:

 - applications apply some sort of normalization, possibly just a
   conversion to Unicode (if needed) and a Unicode NF

   We might need to go this route if OASIS doesn't want to specify this.

 - providers apply some sort of normalization -- whatever they want

   Obviously they can do whatever they want.  But they do need to know
   what codeset the input is encoded in.

 - both do

 - neither does -- wish the user luck

> And again, I think the recommendation there needs to be the same as
> PKCs#8: By all means *try* the local character set of the current
> system, but make sure you also try UTF-8. I'll update my draft.

Oh?  And in what form?  NF(K)C?  NF(K)D?

Nico
--

---

From: David Woodhouse <[email-masked]>
Date: Mon, 17 Apr 2017 20:18:48 +0100

> > there any freely/publicly-available implementation that supports it?

It's not *that* unimplemented. The Fedora packaging guidelines say that
any application packaged for Fedora which can take a key/cert from a
file SHOULD also accept a PKCS#11 URI transparently in place of a
filename. And although compliance isn't ubiquitous, there are plenty of
packages which do comply.

They're even building curl against something other than NSS in the
upcoming release, which means we can close *that* bug too.

>     - https://github.com/varunnaganathan/nss

Those are the same, FWIW. That's the GSoC project I mentored last year.

>  - http://www.pkcs11interop.net/extensions/uri/

Including in the OpenSSL PKCS#11 engine. Although I'd like to ditch
that and just use p11-kit's.