[Bitcoin-development] BIP70 extension to allow for identity delegation

[Bitcoin-development] BIP70 extension to allow for identity delegation

[Mike Hearn]

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

Now we're starting to see the first companies deploy BIP70, we're
encountering a need for identity delegation. This need was long foreseen by
the way: it's not in BIP70 because, well, we had to draw the line for v1
somewhere, and this is an issue that mostly affects payment processors. But
I figured I'd start a thread anyway because people keep asking me about it
:)

*Objective*

Identity delegation means that a payment request can be signed by someone
who is not holding the certified private key. The most obvious use case for
this is payment processors like BitPay and Coinbase who currently have to
sign payment requests as themselves. Other use cases might involve
untrusted sales agents who want to be able to accept payment as their
employer, but cannot be trusted with a long-term valuable secret, e.g.
because they take their phone into areas with high crime rates.

The lack of this is ok for v1 but not great, because:

1) It requires the name of the *actual* recipient to be put in the memo
field, otherwise you don't have the nice receipt-like properties. The memo
field is just plain text though, it doesn't have any exploitable structure.

2) It gives a confusing UI, the user thinks they're paying e.g. Overstock
but their wallet UI tells them they're paying Coinbase

3) Whilst these payment processors currently verify merchants so the
security risk is low, in future a lighter-weight model or competing sites
that allow open signups would give a weak security situation:  a hacker who
compromised your computer could sign up for some popular payment processor
under a false identity (or no identity), and wait until you use your hacked
computer to make a payment to someone else using the same payment
processor. They could then do an identity swap of the real payment request
for one of their own, and your Trezor would still look the same. Avoiding
this is a major motivation for the entire system!

Also it just looks more professional if the name you see in the wallet UI
is correct.

*Proposed implementation*

We can fix this with a simple extension:

enum KeyType {
  SECP256K1 = 1
}

message ExtensionCert {
  required bytes signature = 1;
  required bytes public_key = 2;
  required KeyType key_type = 3;
  required uint32 expiry_time = 4;
  optional string memo = 5;
}

// modification
message X509Certificates {
  repeated bytes certificate = 1;
  repeated ExtensionCert extended_certs = 2;
}

message PaymentRequest {
  // new field
  optional bytes extended_signature = 6;
}

This allow us to define a so-called *extended certificate*, which is
conceptually the same as an X.509 certificate except simpler and Bitcoin
specific. To create one, you just format a ExtensionCert message with an
ECDSA public key from the payment processor (PP), set signature to an empty
array and then sign it using your SSL private key. Obviously the resulting
(most likely RSA) signature then goes into the signature field of the
ExtensionCert. The memo field could optionally indicate the purpose of this
cert, like "Delegation to BitPay" but I don't think it'd ever appear in the
UI, rather, it should be there for debugging purposes.

The new ExtensionCert can then be provided back to the PP who adds it to
the X509Certificates message. In the PaymentRequest, there are now
*two* signature
fields (this is for backwards compatibility). Because of how the mechanism
is designed they should not interfere with each other - old implementations
that don't understand the new extended_signature field will drop it during
reserialization to set signature to the empty array, and thus signature
should not cover that field. On the other hand, extended_signature would
cover signature. Thus, for full backwards compatibility, you would:

1) Sign the payment request using the PP's SSL cert, i.e. sign as
coinbase.com

2) Then sign again using the PP's delegated ECDSA key, i.e. sign as the
merchant

The finished protobuf would show up in old clients as signed by
coinbase.comand by new clients as signed by
overstock.com even though Overstock did not provide their SSL key to
coinbase.

If you have *only* an ExtensionCert and not any X.509 cert of your own,
then you cannot of course make backwards compatible signatures in this way,
and in that case you would miss out the signature field and set the
pki_type to a new value:  "x509+sha256+excert". Old wallets would see that
they don't understand this pki_type and treat the request as unverified.

For maximum security the merchant may choose to set very short expiry times
(like, a day) and then have a cron job that uploads a new ExtensionCert at
the end of each expiry period. This means in the case of PP compromise, the
system reseals very fast.

*Alternatives considered*

We could always use a new pki_type and not bother with the two signature
fields. However, this means old wallets will show payment requests as
untrusted during the transition period. Some signing is still better than
none, security-wise.

We could attempt to fix the above by introducing a use of User-Agent field
to the case where a payment request is fetched via HTTP, so the server can
customise the PaymentRequest according to the capabilities of the client.
However, sometimes payment requests are not fetched via HTTP, for example,
they may be attached to an email, sent via an IM network or sent over a
Bluetooth socket. Nonetheless this may be a useful thing to consider for
future cases where the protocol may not be extended in a backwards
compatible manner.

We could create the extension cert as an X.509 cert, rather than a custom
type. However most CA's set path length constraints on their intermediate
certs that forbid this kind of extension (I forgot why, possibly some kind
of anti-DoS mitigation). Also re-using X.509 for the extension cert would
open up the risk of it being accepted by a bogus SSL stack that didn't
check the key usage constraints extension, and that would allow for SSL
delegation as well. It seems safer to just use a different format that
definitely won't be accepted.



Feedback welcome.

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

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Jeremy Spilman]

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

On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn <mike@plan99.net> wrote:

> 3) Whilst these payment processors currently verify merchants so the  
> security risk is low, in future a lighter-weight model or competing  
> sites that >allow open signups would give a weak security situation: a  
> hacker who compromised your computer could sign up for some popular  
> payment >processor under a false identity (or no identity), and wait  
> until you use your hacked computer to make a payment to someone else  
> using the same >payment processor. They could then do an identity swap  
> of the real payment request for one of their own, and your Trezor would  
> still look the same. >Avoiding this is a major motivation for the entire  
> system!

Let me restate that, it's a huge problem...

Alice's system is compromised,
Mallory intercepts a payment request being sent to Alice from payment  
processor X on behaf of merchant X.
Mallory regenerates a spoof payment request which pays to M, from the same  
payment processor
Alice can't tell Mallory's spoofed PR apart from Merchant X's and thinks  
she's paying Merchant X

It might be a bit challenging for M to generate the new PR on-the-fly  
without being noticed, but that's not a security guarantee.

Perhaps the UI just isn't expressive enough currently to expose this  
situation in any way, let alone reliably alert the user to the issue,  
because there's no way for the payment processor to get authenticated  
fields other than memo into the UI.

Today the only solution is for the payment processor to strictly control  
the 'memo' field so Mallory wouldn't be able to make his own PR that  
looked exactly like merchant Y's. But maybe it's too subtle to make  
payment processors embed that kind of information.

So is the main goal is to provide a structured way to embed this  
information in the PR and expect that user interfaces will display them to  
end users? If that's the case, I don't think we need an entirely secondary  
certificate, or cross signing from a secondary ECDSA key.

A poor solution: If the UI included some sort of certificate viewer, even  
just tied to the OS certificate viewer, and made the cert available for  
inspection, at least the merchant would have a chance to put some fields  
in there which a very advanced user might actually find. But this was  
discussed a while ago and I think the primary problem is the difficulty in  
getting a CA to let you embed any additional fields in your certificate in  
the first place, plus you don't want to generate a new cert for each  
merchant.

A somewhat better option: Some additional fields defined in an extension  
which are reliably shown in the UI. We could try to define specific  
fields, like 'DelegateCN' which would possibly override the primary CN...  
As an aside, I think you can never allow actually overriding the CN  
displayed in the UI directly, the most you can do is add another field in  
the UI to show this string. First I need to know it's from Payment  
Processor X, and then maybe we can let the payment processor make some  
additional claim, like yes you are paying irs.gov. You can't give the  
impression that Payment Processor X is not actually man-in-the-middle.

Maybe the simplest would be a single field expected to contain a delimited  
key/value string (of course JSON) which could be shown as additional lines  
of labeled text in the UI. I don't want to give the "merchant" too much  
dynamic control over what the user's screen will display, but making it  
somewhat dynamic might add some future proofing.

I think any additional extension fields should be hashed using the hash  
function specified in pki_type and signed by X509Certificates.certifcate  
private key. No extended_certs required -- I'm thinking something like;

message PaymentRequest {
// new field
  optional bytes extended_properties = 6;
  optional bytes extended_properties_sig = 7;
}


Thanks,
Jeremy

[-- Attachment #2.1: Type: text/html, Size: 4521 bytes --]

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Mike Hearn]

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

>
> Perhaps the UI just isn't expressive enough currently to expose this
> situation in any way, let alone reliably alert the user to the issue,
> because there's no way for the payment processor to get authenticated
> fields other than memo into the UI.
>

I think for now as long as payment processors include the merchant name in
the memo, that's good - as long as hardware devices or second factor
wallets display the memo as well! Trezor has a small screen, I don't know
how feasible displaying the whole memo is there though - hence an interest
in something better. For now we can probably muddle through.


> A poor solution: If the UI included some sort of certificate viewer, even
> just tied to the OS certificate viewer, and made the cert available for
> inspection, at least the merchant would have a chance to put some fields in
> there which a very advanced user might actually find.
>

Not really interested in solutions that only help very advanced users.
Besides, my understanding is that most PKI CA's will not sign certs that
include arbitrary data they don't understand for I guess the obvious
security reasons (generally signing things you don't understand is a bad
idea). But I've never actually tried it.

We don't want anyone to have to go back to their CA anyway, especially not
with special requests.

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

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Kevin Greene]

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

Another example use-case to back up devrandom's point is using a twitter
handle as the "merchant name". In that example, a 3rd party service hosts
and signs the PaymentRequest, but when someone opens that PaymentRequest in
their wallet, they should know that they are paying the specified twitter
user.


On Sat, Mar 1, 2014 at 12:07 PM, Dev Random <c1.devrandom@niftybox.net>wrote:

> This looks like a good solution of the delegation use case for
> medium/large businesses.
>
> I'm wondering about the small business case.  A small business or an
> individual might not have the technical expertise to perform the
> delegation signature.  Normally the X509 keys are squirreled away on the
> merchant's web server and are not accessible through ordinary means.
> And actually, the merchant might not even have a standalone web
> presence.
>
> Do you think it makes sense to have another scheme where a merchant can
> be name spaced under the payment processor?  This would require just one
> additional field - the merchant identifier.  In effect, the PP would
> certify that "PP / merchant-id" generated this invoice directly on the
> PP system.
>
> On Fri, 2014-02-28 at 12:46 +0100, Mike Hearn wrote:
> > Now we're starting to see the first companies deploy BIP70, we're
> > encountering a need for identity delegation. This need was long
> > foreseen by the way: it's not in BIP70 because, well, we had to draw
> > the line for v1 somewhere, and this is an issue that mostly affects
> > payment processors. But I figured I'd start a thread anyway because
> > people keep asking me about it :)
> >
> >
> > Objective
> >
> >
> > Identity delegation means that a payment request can be signed by
> > someone who is not holding the certified private key. The most obvious
> > use case for this is payment processors like BitPay and Coinbase who
> > currently have to sign payment requests as themselves. Other use cases
> > might involve untrusted sales agents who want to be able to accept
> > payment as their employer, but cannot be trusted with a long-term
> > valuable secret, e.g. because they take their phone into areas with
> > high crime rates.
> >
> >
> > The lack of this is ok for v1 but not great, because:
> >
> >
> > 1) It requires the name of the *actual* recipient to be put in the
> > memo field, otherwise you don't have the nice receipt-like properties.
> > The memo field is just plain text though, it doesn't have any
> > exploitable structure.
> >
> >
> > 2) It gives a confusing UI, the user thinks they're paying e.g.
> > Overstock but their wallet UI tells them they're paying Coinbase
> >
> >
> > 3) Whilst these payment processors currently verify merchants so the
> > security risk is low, in future a lighter-weight model or competing
> > sites that allow open signups would give a weak security situation:  a
> > hacker who compromised your computer could sign up for some popular
> > payment processor under a false identity (or no identity), and wait
> > until you use your hacked computer to make a payment to someone else
> > using the same payment processor. They could then do an identity swap
> > of the real payment request for one of their own, and your Trezor
> > would still look the same. Avoiding this is a major motivation for the
> > entire system!
> >
> >
> > Also it just looks more professional if the name you see in the wallet
> > UI is correct.
> >
> >
> > Proposed implementation
> >
> >
> > We can fix this with a simple extension:
> >
> >
> > enum KeyType {
> >   SECP256K1 = 1
> > }
> >
> >
> > message ExtensionCert {
> >   required bytes signature = 1;
> >   required bytes public_key = 2;
> >   required KeyType key_type = 3;
> >   required uint32 expiry_time = 4;
> >   optional string memo = 5;
> > }
> >
> >
> > // modification
> > message X509Certificates {
> >   repeated bytes certificate = 1;
> >   repeated ExtensionCert extended_certs = 2;
> > }
> >
> >
> > message PaymentRequest {
> >   // new field
> >   optional bytes extended_signature = 6;
> > }
> >
> >
> > This allow us to define a so-called extended certificate, which is
> > conceptually the same as an X.509 certificate except simpler and
> > Bitcoin specific. To create one, you just format a ExtensionCert
> > message with an ECDSA public key from the payment processor (PP), set
> > signature to an empty array and then sign it using your SSL private
> > key. Obviously the resulting (most likely RSA) signature then goes
> > into the signature field of the ExtensionCert. The memo field could
> > optionally indicate the purpose of this cert, like "Delegation to
> > BitPay" but I don't think it'd ever appear in the UI, rather, it
> > should be there for debugging purposes.
> >
> >
> > The new ExtensionCert can then be provided back to the PP who adds it
> > to the X509Certificates message. In the PaymentRequest, there are now
> > two signature fields (this is for backwards compatibility). Because of
> > how the mechanism is designed they should not interfere with each
> > other - old implementations that don't understand the new
> > extended_signature field will drop it during reserialization to set
> > signature to the empty array, and thus signature should not cover that
> > field. On the other hand, extended_signature would cover signature.
> > Thus, for full backwards compatibility, you would:
> >
> >
> > 1) Sign the payment request using the PP's SSL cert, i.e. sign as
> > coinbase.com
> >
> >
> > 2) Then sign again using the PP's delegated ECDSA key, i.e. sign as
> > the merchant
> >
> >
> > The finished protobuf would show up in old clients as signed by
> > coinbase.com and by new clients as signed by overstock.com even though
> > Overstock did not provide their SSL key to coinbase.
> >
> >
> > If you have only an ExtensionCert and not any X.509 cert of your own,
> > then you cannot of course make backwards compatible signatures in this
> > way, and in that case you would miss out the signature field and set
> > the pki_type to a new value:  "x509+sha256+excert". Old wallets would
> > see that they don't understand this pki_type and treat the request as
> > unverified.
> >
> >
> > For maximum security the merchant may choose to set very short expiry
> > times (like, a day) and then have a cron job that uploads a new
> > ExtensionCert at the end of each expiry period. This means in the case
> > of PP compromise, the system reseals very fast.
> >
> >
> > Alternatives considered
> >
> >
> > We could always use a new pki_type and not bother with the two
> > signature fields. However, this means old wallets will show payment
> > requests as untrusted during the transition period. Some signing is
> > still better than none, security-wise.
> >
> >
> > We could attempt to fix the above by introducing a use of User-Agent
> > field to the case where a payment request is fetched via HTTP, so the
> > server can customise the PaymentRequest according to the capabilities
> > of the client. However, sometimes payment requests are not fetched via
> > HTTP, for example, they may be attached to an email, sent via an IM
> > network or sent over a Bluetooth socket. Nonetheless this may be a
> > useful thing to consider for future cases where the protocol may not
> > be extended in a backwards compatible manner.
> >
> >
> > We could create the extension cert as an X.509 cert, rather than a
> > custom type. However most CA's set path length constraints on their
> > intermediate certs that forbid this kind of extension (I forgot why,
> > possibly some kind of anti-DoS mitigation). Also re-using X.509 for
> > the extension cert would open up the risk of it being accepted by a
> > bogus SSL stack that didn't check the key usage constraints extension,
> > and that would allow for SSL delegation as well. It seems safer to
> > just use a different format that definitely won't be accepted.
> >
> >
> >
> >
> >
> >
> > Feedback welcome.
> >
> ------------------------------------------------------------------------------
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> --
> Miron
>
>
>
>

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

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Mike Hearn]

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

On Sat, Mar 1, 2014 at 9:07 PM, Dev Random <c1.devrandom@niftybox.net>wrote:

> I'm wondering about the small business case.  A small business or an
> individual might not have the technical expertise to perform the
> delegation signature.


If they take delivery of an SSL cert from the CA themselves, I don't see
why it'd be an issue. A simple GUI app can be produced that let's you open
the CA cert files and spits out the ExtendedCert file, which you then send
to the PP.

However, for small businesses like local shops, yes we don't expect them to
have a CA cert at the moment. Many of them do have small websites but for
those that don't, I don't think any great solutions exist yet. A virgin
market waiting to be tapped, perhaps ...


> Do you think it makes sense to have another scheme where a merchant can
> be name spaced under the payment processor?  This would require just one
> additional field - the merchant identifier.
>

What is "the merchant identifier" exactly, and what does it mean? If this
question is left unresolved, then it doesn't mean anything and as such it's
equivalent to putting the merchant name in the memo field, which is fine
and what I expect to happen for now.

If it's resolved, then it makes payment processors into certificate
authorities themselves. I think such a solution would be spiffy, but it can
be done within the same framework we have today by just having wallets add
some Bitcoin specific roots to their trust store before PKI verification.
For example, BitPay could become their own CA that doesn't issue SSL certs
but rather "local business certs" that contain a verified street address.
Indeed X.509 certs include X.520 names, that's one reason they're so damn
complicated, and that's already got ways to express organisation names.

Actually setting such a scheme up requires real work though. If we want a
wallet to display something like:

   "Pay to:  Room 77, Graefestraße 77, Berlin"

then the question is, how is that verified and what does it mean when a
payment processor issues a cert containing it? Did someone physically visit
them? Did they just check on Google Maps? Does it mean it's a real
incorporated business or could it just be the address of a childs lemonade
stand?

My inclination would be to say that the ID requirements should be low and
cheap; for our primary use case of making hardware wallets secure, you
don't need robust ID verification, you just need to ensure a MITM can't
issue themselves duplicated ID's on the fly. Just posting a postcard with a
nonce on it would be sufficient IMO (or making a phone call to a number
obtained from a previously verified business listing).

Alternatively, a bitcoin payment processor CA could make visiting a
business, gathering photo evidence and issuing a cert into a kind of
microwork task with the PP/CA acting as a broker.

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

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Andreas Schildbach]

I somehow think that it is too early for this heavy kind of extension,
given that the first version of BIP70 isn't even deployed widely let
alone *used*.

By reading your proposal I get the idea that the current spec doesn't
allow two (or three) different PKIs at once -- we would want this for
migration purposes as you wrote and also because different people prefer
different kinds of PKIs. And that's perhaps something we want to fix in
the current (version 1) spec to prevent us running into a wall and be
doomed to patch around the spec. Note I assume a potential PGP or
Bitcoin-based infrastructure would also be called 'PKI'.

I would prefer if your fix would stay local to X.509 (and thus only
change X.509 specific structs rather than the top-level PaymentRequest).
And for a future PKI we would implement identity delegation in a
straight forward, non-kludgy way.


On 02/28/2014 12:46 PM, Mike Hearn wrote:

> Now we're starting to see the first companies deploy BIP70, we're
> encountering a need for identity delegation. This need was long foreseen
> by the way: it's not in BIP70 because, well, we had to draw the line for
> v1 somewhere, and this is an issue that mostly affects payment
> processors. But I figured I'd start a thread anyway because people keep
> asking me about it :)
> 
> *_Objective_*
> 
> Identity delegation means that a payment request can be signed by
> someone who is not holding the certified private key. The most obvious
> use case for this is payment processors like BitPay and Coinbase who
> currently have to sign payment requests as themselves. Other use cases
> might involve untrusted sales agents who want to be able to accept
> payment as their employer, but cannot be trusted with a long-term
> valuable secret, e.g. because they take their phone into areas with high
> crime rates. 
> 
> The lack of this is ok for v1 but not great, because:
> 
> 1) It requires the name of the *actual* recipient to be put in the memo
> field, otherwise you don't have the nice receipt-like properties. The
> memo field is just plain text though, it doesn't have any exploitable
> structure.
> 
> 2) It gives a confusing UI, the user thinks they're paying e.g.
> Overstock but their wallet UI tells them they're paying Coinbase
> 
> 3) Whilst these payment processors currently verify merchants so the
> security risk is low, in future a lighter-weight model or competing
> sites that allow open signups would give a weak security situation:  a
> hacker who compromised your computer could sign up for some popular
> payment processor under a false identity (or no identity), and wait
> until you use your hacked computer to make a payment to someone else
> using the same payment processor. They could then do an identity swap of
> the real payment request for one of their own, and your Trezor would
> still look the same. Avoiding this is a major motivation for the entire
> system!
> 
> Also it just looks more professional if the name you see in the wallet
> UI is correct.
> 
> *_Proposed implementation_*
> 
> We can fix this with a simple extension:
> 
> enum KeyType {
>   SECP256K1 = 1
> }
> 
> message ExtensionCert {
>   required bytes signature = 1;
>   required bytes public_key = 2;
>   required KeyType key_type = 3;
>   required uint32 expiry_time = 4;
>   optional string memo = 5;
> }
> 
> // modification
> message X509Certificates {
>   repeated bytes certificate = 1;
>   repeated ExtensionCert extended_certs = 2;
> }
> 
> message PaymentRequest {
>   // new field
>   optional bytes extended_signature = 6;
> }
> 
> This allow us to define a so-called /extended certificate/, which is
> conceptually the same as an X.509 certificate except simpler and Bitcoin
> specific. To create one, you just format a ExtensionCert message with an
> ECDSA public key from the payment processor (PP), set signature to an
> empty array and then sign it using your SSL private key. Obviously the
> resulting (most likely RSA) signature then goes into the signature field
> of the ExtensionCert. The memo field could optionally indicate the
> purpose of this cert, like "Delegation to BitPay" but I don't think it'd
> ever appear in the UI, rather, it should be there for debugging purposes.
> 
> The new ExtensionCert can then be provided back to the PP who adds it to
> the X509Certificates message. In the PaymentRequest, there are now
> /two/ signature fields (this is for backwards compatibility). Because of
> how the mechanism is designed they should not interfere with each other
> - old implementations that don't understand the new extended_signature
> field will drop it during reserialization to set signature to the empty
> array, and thus signature should not cover that field. On the other
> hand, extended_signature would cover signature. Thus, for full backwards
> compatibility, you would:
> 
> 1) Sign the payment request using the PP's SSL cert, i.e. sign as
> coinbase.com <http://coinbase.com>
> 
> 2) Then sign again using the PP's delegated ECDSA key, i.e. sign as the
> merchant
> 
> The finished protobuf would show up in old clients as signed by
> coinbase.com <http://coinbase.com> and by new clients as signed by
> overstock.com <http://overstock.com> even though Overstock did not
> provide their SSL key to coinbase.
> 
> If you have /only/ an ExtensionCert and not any X.509 cert of your own,
> then you cannot of course make backwards compatible signatures in this
> way, and in that case you would miss out the signature field and set the
> pki_type to a new value:  "x509+sha256+excert". Old wallets would see
> that they don't understand this pki_type and treat the request as
> unverified.
> 
> For maximum security the merchant may choose to set very short expiry
> times (like, a day) and then have a cron job that uploads a new
> ExtensionCert at the end of each expiry period. This means in the case
> of PP compromise, the system reseals very fast.
> 
> *_Alternatives considered_*
> *_
> _*
> We could always use a new pki_type and not bother with the two signature
> fields. However, this means old wallets will show payment requests as
> untrusted during the transition period. Some signing is still better
> than none, security-wise.
> 
> We could attempt to fix the above by introducing a use of User-Agent
> field to the case where a payment request is fetched via HTTP, so the
> server can customise the PaymentRequest according to the capabilities of
> the client. However, sometimes payment requests are not fetched via
> HTTP, for example, they may be attached to an email, sent via an IM
> network or sent over a Bluetooth socket. Nonetheless this may be a
> useful thing to consider for future cases where the protocol may not be
> extended in a backwards compatible manner.
> 
> We could create the extension cert as an X.509 cert, rather than a
> custom type. However most CA's set path length constraints on their
> intermediate certs that forbid this kind of extension (I forgot why,
> possibly some kind of anti-DoS mitigation). Also re-using X.509 for the
> extension cert would open up the risk of it being accepted by a bogus
> SSL stack that didn't check the key usage constraints extension, and
> that would allow for SSL delegation as well. It seems safer to just use
> a different format that definitely won't be accepted.
> 
> 
> 
> Feedback welcome.
> 
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

[Mike Hearn]

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

On Sun, Mar 2, 2014 at 4:20 PM, Andreas Schildbach <andreas@schildbach.de>wrote:

> I somehow think that it is too early for this heavy kind of extension,
> given that the first version of BIP70 isn't even deployed widely let
> alone *used*.
>

Definitely agree - like I said, I publish this only because I keep getting
asked about it.


> By reading your proposal I get the idea that the current spec doesn't
> allow two (or three) different PKIs at once


That's right. There's little point in having multiple PKI's simultaneously,
that's why it doesn't allow it.

This one is a special case because it doesn't replace but rather
specialises and extends the existing PKI. Old clients that don't understand
it would still show something useful and by upgrading you get better
output. Actually you get closer to the output you're supposed to get.

That's going to be rare though, I think. Generally you wouldn't want to
have multiple PKIs in use simultaneously for the same payment request.


> I would prefer if your fix would stay local to X.509 (and thus only
> change X.509 specific structs rather than the top-level PaymentRequest).
>

It can be done but only by sacrificing backwards compatibility, which
doesn't seem worth it to me. It's hardly a big deal to have two signature
fields. The rest is all localised to the X509 parts.

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