On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
>
> Actually, I agree with this, and that goes along with how our PEM
> routines work (specifically, PEM_X509_INFO_read_bio()), it just
> treats the data as an octet string and hands it down to a d2i routine
> of choice, with a pointer to w
On St, 2016-11-23 at 00:03 +0100, Richard Levitte wrote:
> In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp
> .akamai.com> on Tue, 22 Nov 2016 18:03:31 +, "Salz, Rich" akamai.com> said:
>
> rsalz> It is already possible to write a utility library that tries
> rsalz> every
In message <1479889418.8937.54.ca...@infradead.org> on Wed, 23 Nov 2016
08:23:38 +, David Woodhouse said:
dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
dwmw2> >
dwmw2> > Actually, I agree with this, and that goes along with how our PEM
dwmw2> > routines work (specifically
On Wed, 2016-11-23 at 09:39 +0100, Tomas Mraz wrote:
>
> I also would not be too much worried - the API call should not be
> completely universal - the application should know whether it is
> loading a certificate or private key. It should just be able to use a
> single call to load a certificate
On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
>
>
> dwmw2> So maybe it's just "content types" that we have handlers for, each with
> dwmw2> an optional PEM tag for matching, *and* an optional match function
> dwmw2> which is given the parsed ASN.1 and checks if it's a match.
>
> I'm
In message <1479894913.8937.58.ca...@infradead.org> on Wed, 23 Nov 2016
09:55:13 +, David Woodhouse said:
dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
dwmw2> >
dwmw2> >
dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for,
each with
dwmw2> > dwm
On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
>
> Right...
>
> But then, embedding everything in an OCTET STRING isn't exactly a
> novel idea either. How do we discern a DER encoded TSS KEY BLOB from
> whatever else that had the same "novel" idea? An OCTET STRING is an
> OCTET STRING
There is at least one real life HSM engine, that encodes numerical identifiers
as "pseudo prime
numbers", you end up with a
RSA private key that has 1 and 2 prime numbers?
No new ASN.1
Best
On 11/23/2016 11:47 AM, Richard Levitte wrote:
> In message <1479894913.8937.58.ca...@infradead.org> on
On Tue, 2016-11-22 at 15:26 -0500, Thomas Francis, Jr. wrote:
> On 11/22/16 2:37 PM, David Woodhouse 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 product
> Uh... the d2i functions are already both in one. Are you saying they
> should be split in two, one part that does all the checking and the other that
> just decodes, trusting that all checks are already done? What you're gonna
> do there is double part of the work.
Well, not double, but
In message
on Wed,
23 Nov 2016 13:13:05 +, "Salz, Rich" said:
rsalz>
rsalz> > Uh... the d2i functions are already both in one. Are you saying
they
rsalz> > should be split in two, one part that does all the checking and the
other that
rsalz> > just decodes, trusting that all check
On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
> > But, what I get from you is "what if a octet stream matches two different
> > ASN.1 types? Is that it?
>
> Yes among others. How do you know it will *never* happen?
Because if anyone tries to invent yet *another* ASN.1 form for storing
ke
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 ment
> Why is it different if we do exactly that in libcrypto?
Because *we* are not guessing. We are telling the application "we think it's a
FOO" and then letting the application decide what to do.
Security libraries *should not guess.*
--
openssl-dev mailing list
To unsubscribe: https://mta.open
On Wed, 2016-11-23 at 14:26 +0100, Richard Levitte wrote:
>
> Quite frankly, that's a though that should go back to David and his
> demand of automatic detection. If anyone would *ever* create a raw
> DER file holding a tss OCTET STRING, then the file spec *will* have to
> have an indication of w
In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016
13:33:45 +, David Woodhouse said:
dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
dwmw2> > > But, what I get from you is "what if a octet stream matches two
different
dwmw2> > > ASN.1 types? Is that it?
dwm
In message
<2360f57bb7504a328e5517ac92e19...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed,
23 Nov 2016 13:51:03 +, "Salz, Rich" said:
rsalz>
rsalz> > Why is it different if we do exactly that in libcrypto?
rsalz>
rsalz> Because *we* are not guessing. We are telling the application
rsalz>
> Essentially, you're suggesting that we split out the matching part of the d2i
> functions and put that to good use. Or do you have some other idea, along
> the lines if magic?
NO. I am suggesting add one new routine that tries varies "convert to native"
and returns which conversion worked.
On 11/23/2016 02:33 PM, David Woodhouse wrote:
> If I make a new object type which looks like a PKCS#1 RSA key but is
> actually something completely different, it's *already* likely that
> OpenSSL will load that new object as if it was an RSA key in some
> cases.
>
An exemple used by the 'gem' en
On Wed, 2016-11-23 at 15:21 +0100, Richard Levitte wrote:
> In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016
> 13:33:45 +, David Woodhouse said:
>
> dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
> dwmw2> > > But, what I get from you is "what if a octet st
On Wed, 2016-11-23 at 10:53 +, David Woodhouse wrote:
> On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> >
> > Right...
> >
> > But then, embedding everything in an OCTET STRING isn't exactly a
> > novel idea either. How do we discern a DER encoded TSS KEY BLOB
> > from whatever
[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.
On Wed, 2016-11-23 at 14:41 +, Peter Sylvester Edelweb wrote:
>
> An exemple used by the 'gem' engine.
>
> openssl rsa -in key.pem -text
> Private-Key: (4096 bit)
> modulus:
> 00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
> 01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
>
> 95:69
> FWIW I am perfectly content for applications *not* to automatically work
> with such keys. Making the user jump through extra hoops to use them
> would be perfectly fine in my book.
oh I see. "Users shouldn't care, it should just work" But only for some keys.
Part of my I am opposed to guess
On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
>
> > FWIW I am perfectly content for applications *not* to automatically work
> > with such keys. Making the user jump through extra hoops to use them
> > would be perfectly fine in my book.
>
> oh I see. "Users shouldn't care, it should just
> On Tue, 2016-11-22 at 15:49 +, David Woodhouse wrote:
>> 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 mor
David Woodhouse skrev: (23 november 2016 19:42:29 CET)
>On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
>>
>> > FWIW I am perfectly content for applications *not* to automatically
>work
>> > with such keys. Making the user jump through extra hoops to use
>them
>> > would be perfectly fine
Richard Levitte skrev: (23 november 2016 22:23:18 CET)
>
>
>David Woodhouse skrev: (23 november 2016 19:42:29
>CET)
>>On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
>>>
>>> > FWIW I am perfectly content for applications *not* to
>automatically
>>work
>>> > with such keys. Making the user
28 matches
Mail list logo
