[RFC 1/2] Add support for openssl engine based keys

[Blumenthal, Uri - 0553 - MITLL]

I hear you (finally).

Do you know why TCG moved towards what I consider a regress, i.e., reducing the number of on-board keys?

As for loading keys onto PKCS#11 tokens – for PIV and such OpenSC served me just fine. ;)
Not that I really used that capability a lot…
--
Regards,
Uri Blumenthal

On 11/3/17, 14:53, "James Bottomley" <James.Bottomley at HansenPartnership.com> wrote:

    On Fri, 2017-11-03 at 16:49 +0000, Blumenthal, Uri - 0553 - MITLL
    wrote:
    > What I’m saying is that TPM should be able to behave like a PKCS#11
    > token. Loading TPM keys is similar to provisioning a PKCS#11 token
    > (and hopefully needs to be done as rarely). The normal use of a TPM
    > seems to be operating on the keys already installed – rather than
    > loading keys in every time you need to do something.
    
    I believe I've said several times now: TPM 1.2 can because it can store
    keys internally, so can act like a token if you load it up.  TPM 2
    cannot because its internal key space is very limited so the key has to
    be loaded used and immediately unloaded then reloaded on the next use.
     Thus for TPM2 you *always* require the file representation.
    
    Even for TPM1.2, the file use case is better because it allows infinite
    scaling of the engine and allows use by many users.  Even for TPM 1.2
    there are a finite number of keys you can load and once it's full, no-
    one else can use it in the PKCS11 model, so it doesn't scale to cloud
    use cases.
    
    It's probably helpful if you think of TPM as an engine.  TPM 1.2,
    thanks to a reasonable amount of RAM, is an engine that can behave like
    a token, but TPM 2 can only behave like and engine.
    
    > TPM, like other hardware tokens, was designed for storing things
    > (keys) internally.
    
    No, it definitely wasn't: that's actually partly why the TCG
    deliberately reduced the key capacity to render this impossible in TPM
    2.
    
    >  And you can load keys onto PKCS#11 tokens (if you configure them so
    > – that’s a policy issue rather than a technological limitation).
    
    It's a technological limitation because there are no general tools for
    doing so: The API covers it but in a very piecemeal way which is why
    no-one can write a general tool.
    
    James
    
    
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171103/b38adcbb/attachment-0001.p7s>