6

I'm looking at BIP0070 and also this forum thread which is locked for some reason; so I'll post here.

When it comes to validating a certificate for the purpose of a Bitcoin payment, each certificate is "authoritative" for different things, such as SSL or S/MIME. Some certificates also have something called a "Basic Constraints" set so an end entity isn't marked as a CA... thus confusing the CA validation framework Bitcoin is using.

Question

  • What are the Extended Certificate rights that are required for use with Bitcoin? I would assume something with "server authentication" allows for "domain.com" payments, versus a valid email which is "user@domain.com" for SMIME.

  • Does the breadth of certificate validation types allow for unnecessary spoofing?

  • Is there going to be a visual distinction for different certificates (Those with "all purposes", are expired, for Server Auth, or email?)

  • Finally, can there be a requirement for DNSSec validation when communicating with a server?

  • Edit: Will certificates be validated in a "normal" manner such as validating the Basic Constraints? (I'm pretty sure OpenSSL will do this for you in a platform consistent way)

1

What are the Extended Certificate rights that are required for use with Bitcoin? I would assume something with "server authentication" allows for "domain.com" payments, versus a valid email which is "user @ domain com" for SMIME.

answer: item - Each certificate is a DER [ITU.X690.1994] PKIX certificate value. The certificate containing the public key of the entity that digitally signed the PaymentRequest must be the first certificate. This MUST be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one, up to (but not including) a trusted root authority. The trusted root authority MAY be included. The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs.

Trusted root certificates may be obtained from the operating system; if validation is done on a device without an operating system, the Mozilla root store is recommended."

''I understood that digital signature is done locally, only after it is sent to the payment system and blockchain.''

font: [1];

Does the breadth of certificate validation types allow for unnecessary spoofing?

answer: the RFC5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

already provides as digital signature has to be made, the support has to be by the software and or browser, according to RFC5280. font: RFC5280 - version - May 2008

Is there going to be a visual distinction for different certificates (Those with "all purposes", are expired, for Server Auth, or email?) answer:: this information does not appear in the BIP, it is only stated that the compatibility with x509 with the Root certificate will be verified. to then provide the signature and payment.

Finally, can there be a requirement for DNSSec validation when communicating with a server? answer:: I think there was some confusion on your part, the scope is only for ''This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.'' It does not leave the bitcoin p2p network. font: [1];

Will certificates be validated in a "normal" manner such as validating the Basic Constraints? (I'm pretty sure OpenSSL will do this for you in a platform consistent way): answer:: yes, but BTCCore does not use OPSSL as default: according: bitcoin-core. "On Bitcoin Core <0.12, you can start the bitcoind RPC server directly with SSL:" other font integral content BIP 0070

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.