In message <1479839148.2376.31.ca...@hansenpartnership.com> on Tue, 22 Nov 2016
10:25:48 -0800, James Bottomley said:
James.Bottomley> On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote:
James.Bottomley> > > > It does this by trying to interpret the blob against
known ASN.1
James.Bottomley> >
In message
<021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue,
22 Nov 2016 18:03:31 +, "Salz, Rich" said:
rsalz> It is already possible to write a utility library that tries
rsalz> everything in turn, and returns an enumeration that says "seems
rsalz> to be an X50
On 11/22/16 2:37 PM, David Woodhouse wrote:
On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:
And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.
PEM should be ASCII; in practice it is not necessarily ASCII. There are
several products that produce
On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:
> > That's not the proposal. The proposal is to use PEM form because we can
> > make it uniquely self describing using the guard tags which obviates the
> > problem above.
>
> Well that's what you want. David wants more than that :)
S'true :)
James.Bottomley> Yes, that's right. When any SSL program sees a TPM
wrapped key, it
James.Bottomley> should just do the right thing if it has the engine
capability without
James.Bottomley> needing the user to add any options to the command line.
Mm... I'm not sure I agree w
> That's not the proposal. The proposal is to use PEM form because we can
> make it uniquely self describing using the guard tags which obviates the
> problem above.
Well that's what you want. David wants more than that :)
> On the larger issue of non-self describing formats like ASN.1: if you
On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote:
> > > It does this by trying to interpret the blob against known ASN.1
> > > definitions, and will only succeed when there's a complete match.
> > > I'm
> > > not terribly worried...
>
> I am. With locales and UTF8, the old simple days of tex
> > It does this by trying to interpret the blob against known ASN.1
> > definitions, and will only succeed when there's a complete match. I'm
> > not terribly worried...
I am. With locales and UTF8, the old simple days of text/binary are probably
long gone. And if any ASN.1 definition has ext
On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote:
> In message
> <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on
> Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich" said:
>
> rsalz> > The more interesting part is when it tries to load files it guesses
> are raw DE
In message
<489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue,
22 Nov 2016 17:40:54 +, "Salz, Rich" said:
rsalz> > The more interesting part is when it tries to load files it guesses
are raw DER.
rsalz>
rsalz> And this part worries me. I do not think a "securit
> The more interesting part is when it tries to load files it guesses are raw
> DER.
And this part worries me. I do not think a "security library" should be
guessing.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
In message <1479833048.2376.21.ca...@hansenpartnership.com> on Tue, 22 Nov 2016
08:44:08 -0800, James Bottomley said:
James.Bottomley> On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote:
James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
James.Bottomley> > >
Jame
On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote:
> On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> >
> > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
> > else is
> > dwmw2> redundant anyway.
> >
> > Oh! Ok, that makes things much simpler (at least in a
On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
>
> dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
> dwmw2> redundant anyway.
>
> Oh! Ok, that makes things much simpler (at least in a way)
Kind of. But then again, there's an argument that it was none of yo
In message <1479830167.8937.43.ca...@infradead.org> on Tue, 22 Nov 2016
15:56:07 +, David Woodhouse said:
dwmw2> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
dwmw2> > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov
2016 11:57:42 +, David Woodhouse said:
On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote:
>
> I'm sorry, I have obviously had you a bit confused. What I'm
> currently interested in is decoding the content of a 'TSS KEY BLOB'
> PEM file, and I assume that's a TssBlob type, yeah?
No, it's not. (Sorry!)
--
dwmw2
smime.p7s
Desc
In message <1479829450.2376.10.ca...@hansenpartnership.com> on Tue, 22 Nov 2016
07:44:10 -0800, James Bottomley said:
James.Bottomley> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1479815862.8937.22.ca...@infradead.org> on Tue,
22 Nov
James.Bottomley>
On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote:
>
> > I'm just having a look at the spec (page 151 in
> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> > a_A-final.pdf), and am a bit confused by the TssBlobType type. Which
> > is it in practice, an ENUMERATED
On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016
> 11:57:42 +, David Woodhouse said:
>
> dwmw2> Besides, it requires files in the form described by the Portable Data
> dwmw2> section of the TSS (1.2) spec. Tha
On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote:
> In message
> on
> Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich" said:
>
> rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
> rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
> The more interesting part is when it tries to load files it guesses
> are raw DER. It's currently only trying a few chosen content types,
> I'm happy to add more as time goes. However, I suspect that nothing
> in your test suite will tri
On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov
> 2016 11:57:42 +, David Woodhouse said:
>
> dwmw2> Besides, it requires files in the form described by the
> Portable Data
> dwmw2> section of the TSS (1.2) spec. Th
In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016
11:57:42 +, David Woodhouse said:
dwmw2> Besides, it requires files in the form described by the Portable Data
dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
dwmw2> (which is mostly redundant as
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 so
In message
on Tue,
22 Nov 2016 14:42:35 +, "Salz, Rich" said:
rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
rsalz>
rsalz> I disagree with this approach, but that's just my opini
> dwmw2> It should work out what the contents are for *itself*. Whether
> dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
I disagree with this approach, but that's just my opinion. I am worried about
"keep trying something until it works" because you'll get strange errors y
On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
>
> Just let me shamelessly mention my STORE effort again ;-)
> Among others, it does attempt to solve that very problem (in the
> 'file' scheme handler).
Neat. Note that I have a ready-made test suite for you in OpenConnect:
http://git.in
On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote:
> In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016
> 13:12:14 +, David Woodhouse said:
>
> dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> dwmw2> >
> dwmw2> > Not sure I follow... 'file=/foo
In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016
13:12:14 +, David Woodhouse said:
dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
dwmw2> >
dwmw2> > Not sure I follow... 'file=/foo/bar/key.pem' is just a path /
dwmw2> > parameter that the 'tpmkey' ha
In message <1479820158.8937.29.ca...@infradead.org> on Tue, 22 Nov 2016
13:09:18 +, David Woodhouse said:
dwmw2> On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote:
dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is
dwmw2> > > tought to recognise 'BEGIN TSS KEY BLO
On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
>
> Not sure I follow... 'file=/foo/bar/key.pem' is just a path /
> parameter that the 'tpmkey' handler is free to interpret in whatever
> way it sees fit. For me as a user, it's just a string. For all I
> care, the URI could just as wel
On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote:
> > would much rather have seen a patch where OpenSSL's PEM module is
> > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it,
> > securing
>
> Yes, that would be much more consistent with the existing OpenSSL
> code which -- li
In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016
11:57:42 +, David Woodhouse said:
dwmw2> On Mon, 2016-11-21 at 13:50 +, Blumenthal, Uri - 0553 - MITLL
dwmw2> wrote:
dwmw2> > Frankly, I think this approach of specially-encoded PEM or DER files
dwmw2> > telling the
> would much rather have seen a patch where OpenSSL's PEM module is
> tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
Yes, that would be much more consistent with the existing OpenSSL code which --
like it or not -- works that way.
> My vote goes to a URI based spec
On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote:
> Mm... I'm not sure I agree with the method, passing a BIO for the
> key_id. I would much rather have seen a patch where OpenSSL's PEM
> module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
> from it, securing it somehow
In message <1479744347.2309.21.ca...@hansenpartnership.com> on Mon, 21 Nov 2016
08:05:47 -0800, James Bottomley said:
James.Bottomley> On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote:
James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
James.Bottomley> > >
Jame
On Mon, 2016-11-21 at 13:50 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Frankly, I think this approach of specially-encoded PEM or DER files
> telling the app what key to ask from the engine is madness, compared
> to the straightforward URI approach (no pun intended :).
Right. There are two sep
37 matches
Mail list logo