Re: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl)

[David Woodhouse]

On Fri, 2016-12-02 at 14:04 +0100, Richard Levitte wrote:
> It does now for everything but PKCS#12 files.  Those are trickier, and
> I'm working on it.

Nice.

> Speaking of...  do you mind if I pilfer from that Makefile.am for our
> tests?

Not at all; please do. You're welcome to use anything in the test suite
under the OpenSSL licence. With the caveat/exception that bits of it
came from Nikos — but that was mostly the ocserv test harness which
isn't the bit you want.

I really will augment it with password/charset torture testing one of
these days...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl)

[Richard Levitte]

In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 
13:57:12 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)

It does now for everything but PKCS#12 files.  Those are trickier, and
I'm working on it.

Speaking of...  do you mind if I pilfer from that Makefile.am for our
tests?

dwmw2> (Yeah, I need to sort out the tpm emulator in the test environment,
dwmw2> then add some -BEGIN TSS KEY BLOB- files too :)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl)

[Richard Levitte]

[subject change]

In message 
<3d837eb338bb47a68938676967ed1...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 
23 Nov 2016 14:41:14 +, "Salz, Rich"  said:

rsalz> 
rsalz> > Essentially, you're suggesting that we split out the matching part of 
the d2i
rsalz> > functions and put that to good use.  Or do you have some other idea, 
along
rsalz> > the lines if magic?
rsalz> 
rsalz> NO.  I am suggesting add one new routine that tries varies
rsalz> "convert to native" and returns which conversion worked.  And
rsalz> then another new routine that takes that return value and calls
rsalz> that conversion routine directly.  The cost of doing this is
rsalz> one extra d2i.  By the application.  And that first routine
rsalz> should ideally return a bitmask of all functions that succeeded
rsalz> so that handling ambiguities are built-in to the API.

Ok, I hear you, and this can be done.  However, since this is in STORE
terms, it will have to be a STORE API thing.  Not all URIs will give
you a DER blob to fiddle with at your heart's content, some of them
will just give you a key referense (which is best stored in a
EVP_PKEY).  Engine keys stored in the engine device are the prime
example.

rsalz> > rsalz> Security libraries *should not guess.*
rsalz> > 
rsalz> > Isn't telling the application "we think it's a FOO" guessing?  What's 
the
rsalz> > application going to do, go "nh, methinks it's a BAR" and try to 
decode
rsalz> > the blob as that (and most probably fail) rather than FOO?
rsalz> 
rsalz> It might.  Or it might throw up its hands and give up.  Or it
rsalz> might check to see if the file is ambiguous and do something.
rsalz> The point is, it is not openssl that is doing that.

Speaking of ambiguity, I was thinking of having my 'file' scheme
loader try all d2i's and having it "throw up its hands" if it found
more than one matching.  STOREerr(..., STORE_R_MABIGUOUS_CONTENT) type
of thing...  The application or users would be left to give some extra
information in the URI.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl)

[Richard Levitte]

Change of subject, this part of the thread isn't so much TPM any more...

In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 
13:57:12 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)

Nope, not even for all the PEM files...  I'm seeing a number of them
(I noticed the PKCS#8 ones in particular) that don't return any data
at all.

I haven't look that deeply into PEM_X509_INFO_read_bio before, and it
seems to only cover a subset of all the types we recognise.
Considering it's undocumented, I'm wondering if that's the right
function to pursue.  The other option is to create a function in the
'file' scheme loader that does the same thing but with a table of
handlers.  I'm quite fine with that idea...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev