📅 Original date posted:2015-02-03
📝 Original message:>
> TREZOR like devices with BIP70 support and third party cosigning services
> are a solution I really like the sound of. I suppose though that adding
> BIP70 request signature validation and adding certificate revocation
> support starts to balloon the scope of what is supposed to be a very simple
> device though.
>
Yes, X.509 is ....... unfortunate. We'll have to wait and see how the
TREZOR team get on with implementing it. TREZOR doesn't have any OS at all
at the moment, so an implementation of PKIX will probably end up being
larger than their existing codebase.
That said, X.509 parsing is so security critical that the existing
codebases for it are by now pretty robust. Touch wood. So just having a
super stripped down OpenSSL implementation is probably good enough.
W.R.T revocation, BIP70 doesn't support this. If your private key leaks
you're currently hosed, identity wise, until the certificate expires. This
is obviously suboptimal. In a world where we all have infinite time and
resources the right fix will be to piggy back on an X.509 extension being
proposed in the browser world called "Must Staple". It's a bit in the
certificate flags that tell the client to expect a stapled OCSP response
and to hard-fail if none is provided. By requesting the CA set this flag
when you get your certificate issued, you sign up for more pain but more
security.
An OCSP stapling extension to BIP70 would probably not be very hard to
implement, but it'd be pointless today because the client has no idea
whether to expect it or not. The absence of a certificate changes the UI by
showing you a random Bitcoin address instead of a human readable name, but
the absence of stapled OCSP would not result in any UI change.
> Regardless, I think a standard for passing partially signed transactions
> around might make sense
>
I'm hoping that the hardware wallet world just standardises on the TREZOR
protocol. It's well designed and these devices all have fairly similar
capabilities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/c48adbc9/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:29:32
in reply to nevent1q…yqh3
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:29:32Event JSON
{
"id": "7c460783ee08c98c69d56918c01e29f493121fdfa60afdc1a44b465b2d1d4270",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151772,
"kind": 1,
"tags": [
[
"e",
"4a6f0574e60dd94083ee2c44a33058d163eecce8fa7924cda65c1a095dfabb8a",
"",
"root"
],
[
"e",
"da833717c7b57948059df1f3d267d5e8c3edf7bd0a571b4cb1d288112e9719e1",
"",
"reply"
],
[
"p",
"5f57805600aff24704ce401a57e78ba1631be95f18e62e28fb3168e3be1ea5c5"
]
],
"content": "📅 Original date posted:2015-02-03\n📝 Original message:\u003e\n\u003e TREZOR like devices with BIP70 support and third party cosigning services\n\u003e are a solution I really like the sound of. I suppose though that adding\n\u003e BIP70 request signature validation and adding certificate revocation\n\u003e support starts to balloon the scope of what is supposed to be a very simple\n\u003e device though.\n\u003e\n\nYes, X.509 is ....... unfortunate. We'll have to wait and see how the\nTREZOR team get on with implementing it. TREZOR doesn't have any OS at all\nat the moment, so an implementation of PKIX will probably end up being\nlarger than their existing codebase.\n\nThat said, X.509 parsing is so security critical that the existing\ncodebases for it are by now pretty robust. Touch wood. So just having a\nsuper stripped down OpenSSL implementation is probably good enough.\n\nW.R.T revocation, BIP70 doesn't support this. If your private key leaks\nyou're currently hosed, identity wise, until the certificate expires. This\nis obviously suboptimal. In a world where we all have infinite time and\nresources the right fix will be to piggy back on an X.509 extension being\nproposed in the browser world called \"Must Staple\". It's a bit in the\ncertificate flags that tell the client to expect a stapled OCSP response\nand to hard-fail if none is provided. By requesting the CA set this flag\nwhen you get your certificate issued, you sign up for more pain but more\nsecurity.\n\nAn OCSP stapling extension to BIP70 would probably not be very hard to\nimplement, but it'd be pointless today because the client has no idea\nwhether to expect it or not. The absence of a certificate changes the UI by\nshowing you a random Bitcoin address instead of a human readable name, but\nthe absence of stapled OCSP would not result in any UI change.\n\n\n\u003e Regardless, I think a standard for passing partially signed transactions\n\u003e around might make sense\n\u003e\n\nI'm hoping that the hardware wallet world just standardises on the TREZOR\nprotocol. It's well designed and these devices all have fairly similar\ncapabilities.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/c48adbc9/attachment.html\u003e",
"sig": "b4e5796d7e68cf65c24e25bd0f8ee412713ac99d87494370285c83ffee40036e917e7bf949da1eb8834e06ce009c40d8c49485a87756c1fb6c2a6f01cacce639"
}