Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

Oh, one other reason I found - apparently RIM, at least in the past, has
been telling CA's that they need to pay mad bux for the Certicom ECC
patents. So that's another reason why most certs are still using RSA.


On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn <mike@plan99.net> wrote:

> On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@cypherspace.org> wrote:
>
>> Maybe its time to explore raw ECDSA signed message based certs.
>>
>
> If you want to create and run a new CA, by all means. But I bet you don't.
> So we're stuck with the current system for now.
>
>
>> btw I dont think its quite 4kB.  eg bitpay's looks to be about 1.5kB in
>> der
>> format.  And they contain a 2048-bit RSA server key, and 2048-bit RSA
>> signatures (256byte each right there = 512bytes).  And even 2048 is weaker
>> than 256-bit ECDSA.
>
>
> But you have to chain up to the root.
>
> The only reason more certs aren't ECC is backwards compatibility. Some old
> browsers don't know how to handle them. It wasn't so long ago that Fedora
> and Android were deleting ECC code from upstream libraries before shipping
> them, either for patent reasons for disk space saving measures.
>
> But it's possible to get ECC certs if you want. For example, Entrust is
> starting to sell them:
>
> http://www.entrust.net/ecc-certs/index.htm
>
> But their intermediate cert is still RSA. My understanding is that ECC
> roots for many CA's have been submitted and are now included, but of course
> "give up compatibility with lots of users" vs "save a bit of cpu time and a
> handful of bytes" is no real competition so it will be a long time until
> most websites are using ECC certs.
>
> Regardless, it's all irrelevant. Who knows when we might want to add
> another feature that uses some bytes into PaymentRequests. Stuffing them
> into a QR code will never make much sense IMO - it's far more sensible to
> just use Bluetooth where the data size constraints are so much easier.
>

[-- Attachment #2: Type: text/html, Size: 3114 bytes --]