W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2012

Re: MintChip launched by Royal Canadian Mint

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 15 Apr 2012 17:51:04 -0400
Message-ID: <4F8B42C8.3020302@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
CC: Fabio Barone <holon.earth@gmail.com>
On 04/15/2012 01:29 PM, Fabio Barone wrote:
> Someone (apparently crypto expert) commented like this:
>
> "This is a step in the right direction, but there is a problem: it
> uses https".

What is it about HTTPS that is problematic?

> "The transaction request is digitally signed by the agent according
> to the Request Signature Algorithm using a private key associated
> with the public key that was previously registered with the authority
> according to the Vendor Registration Algorithm."

This is true.

> "The transaction request is sent to the authority of the agent via an
> HTTPS connection. The HTTPS protocol MUST be used for transmission of
> the request and retrieval of the response to prevent replay
> attacks."

This is also true. Keep in mind that the request is digitally signed by
the requester, which includes a timestamp and potentially a nonce
(although, that's not in the current algorithm because we believe that
HTTPS will provide replay protection against the message). Even in the
event that the message is compromised via HTTPS, the damage is
time-fenced to plus-or-minus X seconds from the timestamp (so the danger
of a replay attack is only possible for a certain number of seconds). If
we wanted to include a nonce, we could, but then we'd be duplicating
what HTTPS already does.

> " Ug. Dead. you can't expect HTTPS to protect your transaction
> integrity, the tx must stand alone"s?

This is where I lose the commenter's train of thought. I don't know what
the commenter means by "protect your transaction integrity" and "the tx
must stand alone". Is there any chance that we could get clarification
on the definitions the commenter is making?

PaySwarm /transaction requests/ depend on HTTPS to prevent replay
attacks when there is a danger of one. However, the transaction itself
is digitally signed from end-to-end. Also, keep in mind that this is for
automatic purchases. The commenter may be referring to the problem that
'network perspectives' solves, but I can't be sure until they say that
they're concerned about rogue certificate signing authorities.

PaySwarm transactions do "stand alone" in the sense that once they're
signed by the PaySwarm Authority, they can be verified by anyone. It
just so happens that we're using HTTP and HTTPS as the transport
mechanism, however, any other secure transport mechanism will work as well.

> Thoughts?

Is this person Chris Cook? We had a brief exchange on Twitter:

@cjenscook: "Payswarm: generic micropayments. My guru on matters crypto
says "Can't expect HTTPS to protect transaction integrity." payswarm.com"
@manusporny: "@cjenscook PaySwarm doesn't depend on HTTPS to protect
integrity - it uses digital signatures: http://ow.ly/agqGG #payswarm"

Link to the conversation:
    https://twitter.com/#!/manusporny/status/190842511764365312

In any case, it would be good if that commenter could raise the issue
publicly - as if this is truly a security vulnerability, we will change
the spec in a heartbeat to ensure that we're not doing something stupid. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Sunday, 15 April 2012 21:51:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC