RISE-V2G/RISE-V2G-Certificates/signature-creation-testdata
Marc Mültin 09a3f30123
Update README.md
Minor editorial changes
2019-03-08 09:00:41 +01:00
..
CertificateInstallationRes-MsgBody-namespace.xml Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
CertificateInstallationRes-empty-namespace.xml Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
README.md Update README.md 2019-03-08 09:00:41 +01:00
contractCert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
cpsCertChain.p12 Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
cpsLeaf.key Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
cpsLeafCert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
cpsSubCA1Cert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
cpsSubCA2Cert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
moCertChain.p12 Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
moSubCA1Cert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
moSubCA2Cert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
oemProvCert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00
v2gRootCACert.pem Updated content of folder signature-creation-testdata and corrected an error in the README.md file which stated that the signature for the CertificateInstallationRes message would be created with the private key of the MO sub-CA 2. Correct is that the signature is created with the private key of the CPS (certificate provisioning service) sub-CA 2. 2018-08-15 17:08:32 +02:00

README.md

Test Data To Verify Your CertificateInstallationRes Signature

This file provides test data needed to reproduce the same digest and signature values for a CertificateInstallationRes. This test data is provided for your convenience to verify that your implementation of creating and verifying digital XML-based signatures is correct.

Further explanation is given in the ISO 15118 Manual in section 3.12.3 "Test Data To Verify Your CertificateInstallationRes". For further explanation why the different usage of XML namespace matters with regards to the resulting digest and signature values, have a look at section 3.12.4 "Pitfalls with Signatures And XML Namespaces" in the ISO 15118 Manual.

TEST DATA SETUP

Private key for signature creation

The private key used to create the signature for the CertificateInstallationRes is the one belonging to the Sub-CA 2 of the certificate provisioning service (CPS). See file cpsSubCA2.key.

169FE1CBCE6CED08391F3235FD530DB84430F165E474117C0AC587D6554F581C

Public key for signature verification

The public key used to verify the signature of the CertificateInstallationRes is part of the Sub-CA 2 certificate of the certificate provisioning service (CPS). The 64 bytes represent a point on the elliptic curve, thus the raw x-coordinate and y-coordinate. The public key has an additional byte 0x04 in the beginning to represent the uncompressed form as demanded by the ISO 15118-2, resulting in 65 bytes in total.

0491CAA2FE68797277C9FEADEC61DC7AE7DC334DA59DD82D82290327AF105771F7307B9573870A8DA09CA4CE2F293B23D9F8AEED3AE49A9C177C6F710C55089CE4

ContractSignatureCertChain

The certificate chain provided by the Mobility Operator (MO) comprises the contract certificate and the intermediate sub-CA certificates. All MO certificates are packaged in the PKCS#12 container file moCertChain.p12. But you can also access every single certificate by its own, if you want: the contractCert, moSubCA2, and moSubCA1 (each provided in .pem and .der format). Be aware that the order in which the certificates are placed in the SubCertificates element is important. The first element is the Sub-CA 2 certificate, followed by the Sub-CA 1 certificate. Also, the certificates' validity period might already have expired by the time you use this test data. But that is not a problem for this issue.

ContractSignatureEncryptedPrivateKey

This field holds the encrypted private key that belongs to the contract certificate as well as a so-called initialization vector (IV) of 16 bytes length that is needed for the AES cipher. The IV is represented by the first (also known as most significant) 16 bytes of this field. Use this hexadecimal representation of a ContractSignatureEncryptedPrivateKey to get the same results.

803340C03FEFBC0CF47613E50D74C660EF471D2104C2EB1C1EAE39BAE700EAB0DC9AE909CE234FF2619DD3A721C60AA0

DHpublickey

The DHpublickey is the public key of a generated elliptic curve Diffie-Hellman key pair. The key pair is used to create the session key with which the private key that belongs to the contract certificate is encrypted. Again, with an additional byte 0x04 prepended as demanded by ISO 15118-2 to represent the uncompressed form of a public key. Use this hexadecimal representation of a DHpublickey to get the same results.

04BE426A534EBCD5444476C0809425F9A593875AA7A4C2A2167C8A295B2B9069E054AD61801552FAB1F7C710D9506890120354C763800891DA595A1619E06254E9

eMAID

Let's use the following eMAID for this test case: DEABCC123ABC56

SAProvisioningCertificateChain

The signature is built over the four fields mentioned above. The Certificate Provisioning Service's (CPS) certificate chain is not part of the signature. However, the CPS's Sub-CA 2 certificate holds the public key (printed further above in hexadecimal notation for your convenience) with which you need to verify the signature. If you also want to validate the CPS's chain of certificates all the way up to the V2G root certificate, then use the PKCS#12 container file cpsCertChain.p12 and the v2gRootCA.pem or v2gRootCA.der file. All certificates in cpsCertChain.p12 are also provided as single certificates in this folder.

XML REFERENCE ELEMENT GENERATION WITH CORRECT XML NAMESPACE "urn:iso:15118:2:2013:MsgBody"

The following values are created using the XML namespace "urn:iso:15118:2:2013:MsgBody".

ContractSignatureCertChain

EXI: 8021015A590C4D703308201D33082017AA00302010202023039300906072A8648CE3D0401304F3111300F06035504030C084D4F53756243413231193017060355040A0C1052495345205632472050726F6A656374310B300906035504061302444531123010060A0992268993F22C64011916024D4F301E170D3138303831353132333433355A170D3230303831343132333433355A30573119301706035504030C1044452D4142432D43313233414243353631193017060355040A0C1052495345205632472050726F6A656374310B300906035504061302444531123010060A0992268993F22C64011916024D4F3059301306072A8648CE3D020106082A8648CE3D0301070342000473FEBA248E8E0D246F4ECC79D46E57184BF86ACBC01644F7AE453D8C721B8AF9442723892948A6E48A6E81229363DFBAEF37F4631FC3592E868BEF2E5884185EA33F303D300C0603551D130101FF04023000300E0603551D0F0101FF0404030203E8301D0603551D0E0416041446EC52B4D9BFC688275F5B0A872DD47D6960448A300906072A8648CE3D04010348003045022100E97C0514FAE75296B5951D06EAC507922167C725780951869AA5E3DF43E618F5022059F81CAFEDDA35B5C73DF80EA1522C53951EF2361232E35442B16D6B77909D8A06A81984100E8984100BC50018100810101181C98048303954324671E82009827988898078301AA8201860426A7A9BAB121A098988C980B8301AA820506082924A9A2902B192390283937B532B1BA188598048301AA82030981222298891808030504C91344C9F91632008C8B0126A7980F0B86989C181C189A9899199A199AAD0B869919181C189A1899199A199AAD1827988898078301AA8201860426A7A9BAB121A099188C980B8301AA820506082924A9A2902B192390283937B532B1BA188598048301AA82030981222298891808030504C91344C9F91632008C8B0126A7982C98098303954324671E81008304154324671E81808381A100024A1FD0FC8C3F56A5E5CFC49A0FDF110400AAD7E8C8B33AC646EF0B93A4C74CA034FEDAB0900313607E24849385E45905DDB22B5DD9E88A9C1076CEFC266A848F51A2982198090301AA8E898080FF820418030080FF81008018070301AA8E878080FF8202018100E3180E8301AA8E87020B020A256D0F08428AADE1FB88C3BF4C1E7E8EE606C1D118048303954324671E820081A40018228110151FDB8466FA92DB3E5AE0AC81B4BC3AAB7C18FF1CA54DD7CDB4E18C0CAAE8BD8110806ABF339E3F7C85EAD2FAA175F61DDBE6E015876FD8BFE225B04169563377128D86B01984100E9184100BC50018100810101181C98048303954324671E82009827988898078301AA8201860426A7A937B7BA21A0988C980B8301AA820506082924A9A2902B192390283937B532B1BA188598048301AA82030981222298891808030504C91344C9F91632008C8B0126A7980F0B86989C181C189A9899199A199AAD0B869919181C189A1899199A199AAD1827988898078301AA8201860426A7A9BAB121A098988C980B8301AA820506082924A9A2902B192390283937B532B1BA188598048301AA82030981222298891808030504C91344C9F91632008C8B0126A7982C98098303954324671E81008304154324671E81808381A1000262BE27D8CCBAA40F456878995C3E34CDE5EF3C4B435FC84C4A57B6F84212FCCFC195290B3B265255BC4CF067A3294E73516D54B255838C9C35F67F5F77B64EE6D1A2982198090301AA8E898080FF820418030080FF81008098070301AA8E878080FF820201810083180E8301AA8E87020B020A6876F21C15AB68AE79919AF9807C85B49B1DD2C718048303954324671E820081A48018230110806656378B705F6308BDA5749D1CC6AAB30FC93390A01E608C8C99DE16D0DF09430110807B4806A1E2B9B762C65B7C8783321E83B185CD00FA57EEAC334A27965CF6B9D817A00

SHA-256: 8EFA2B8D3BDED68CF6F4DF02D80BADCC4036AEA8F2D4E4124CA69A64DBC192B0

Base64 encoded SHA-256: jvorjTve1oz29N8C2AutzEA2rqjy1OQSTKaaZNvBkrA=

ContractSignatureEncryptedPrivateKey

EXI: 802202B4B2190C200CD0300FFBEF033D1D84F9435D31983BD1C7484130BAC707AB8E6EB9C03AAC3726BA427388D3FC986774E9C87182A81E80

SHA-256: 5F0EEDE44720B6AE9F7A4EC27E49C8F28C5F0A31FDAE012FE4E3C8FCEEC231F2

Base64 encoded SHA-256: Xw7t5Ecgtq6fek7CfknI8oxfCjH9rgEv5OPI/O7CMfI=

DHpublickey

EXI: 802D02B4B21990412F909A94D3AF3551111DB02025097E6964E1D6A9E930A8859F228A56CAE41A78152B58600554BEAC7DF1C436541A240480D531D8E0022476965685867818953A5E80

SHA-256: 02003E52F83579B57A72D4C9514B1480956D71B5C669A63CD633B309B040CE78

Base64 encoded SHA-256: AgA+Uvg1ebV6ctTJUUsUgJVtcbXGaaY81jOzCbBAzng=

eMAID

EXI: 80EC0202B4B21A40041111505090D0CC4C8CD05090CD4DBD3D00

SHA-256: 939AF54F14396EC0D827F753C896AC0762AE1E00ACAB57E19AF100243CDD5A6B

Base64 encoded SHA-256: k5r1TxQ5bsDYJ/dTyJasB2KuHgCsq1fhmvEAJDzdWms=

SIGNATURE GENERATION WITH CORRECT XML NAMESPACE "urn:iso:15118:2:2013:MsgBody"

EXI: 808112B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A1AB43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B63239B4B396B6B7B93291B2B1B239B096B9B430991A9B220623696432025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C840BE1DDBC88E416D5D3EF49D84FC9391E518BE1463FB5C025FC9C791F9DD8463E408188DA590C4095A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD214B43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B632B73191B9B430991A9B210477D15C69DEF6B467B7A6F816C05D6E6201B5754796A720926534D326DE0C958020623696434025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C8412735EA9E2872DD81B04FEEA7912D580EC55C3C015956AFC335E2004879BAB4D608188DA590CC095A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD214B43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B632B73191B9B430991A9B21001001F297C1ABCDABD396A64A8A58A404AB6B8DAE334D31E6B19D984D820673C0DC

The signature value will never be the same because ECDSA always uses a random seed to generate the signature. Therefore, it does not make sense to provide a signature value here for comparison. HINT: Do not make the mistake to hash the EXI binary stream before you run ECDSA on it. ECDSA already performs a SHA-256 hashing operation!

XML REFERENCE ELEMENT GENERATION WITH INCORRECT XML NAMESPACE ""

There was a discussion going on whether the XML elements for a CertificateInstallationRes/CertificateUpdateRes need to be created using the namespace "urn:iso:15118:2:2013:MsgBody" or if using no namespace (the same as using the empty namespace "") is also a possible solution. The ISO 15118 User Group issue #72 further elaborates on that and makes clear that the namespace "urn:iso:15118:2:2013:MsgBody" shall be used. Using the empty namespace would NOT conform to the standard's requirements. However, just to show the difference in the EXI encoding result as well as the difference in message size, the following values are created using the empty XML namespace "". As you can see, those EXI encoding results are bigger in size. This is due to a so-called schema deviation encoding for those message elements.

ContractSignatureCertChain

EXI: 80F311B436F6E74726163745369676E617475726543657274436861696E4C028006070052056964312E00109805000C7EC089A92928460F4868682B0E2CE82EE928482CE92869A88D6EE86A2B29096DEB492F4D4608A82A884A09AA48AEE88EEB288ACA2A2888882D09CA8629C62B2D69C849AD48AB49A84C68E8262AA8A86CEEEA2AAD6D8A8A4A684AE9AD6C6CEAA9094ECC2DAACD4C8888A989A82D68E8262AA8A84D09A86A48AAAF08AD482A284CEDE94D6D2C294D65E92E6B4828AB48CCE949CA8F482CA8CEE60F09E8882689AA8AAF09AD49A609AF4ACC28CEE60F29A8882689AA8A2F09AD49A609AF4ACC29A8CC6F08EA882B084CE9CAC84829A9A8A8AA48C98AA8C86A2F262889AA892F4A2AA94889CA8B2F08EA882B084CE9CAC8482DE9A8A8C9494AA60AACEACD49490928C84F2C464E0D8B266A2F086F4829484CE9CAC8482B2A882D6A48C9AA492EE8A82B29686B492DAD2B4A0F2988EA2848EA4B286A8AA70EEAEA882A884CEC6E2D0D6D49EA0A2928484CECEE2D0D6D49EA0A29A8484EE9C868282A4F45EE4DED6D4DE689C948E729EF490DCAAC4D8C6B2A65ED0E2F27082AEA4A0CAEAA4A8649AC6D0EA9656AAA2DC9268D6E0A696C4D6D2DA6C8492E09CD4666EE4EC9C5EA4D490709CB498DEC2986EF26AB2D084D0CADEF470EEA0A8829A84CE9CAC90A49A8482CC708A82D482829A82688E8262AAC888EE8A845EEEA28A82EE92886C8882C884CE9CAC90A2688A8CCEA2AAA4EAF0A6E89CDA5EF0DECEDCB062E696D0F266AACCAED8CEA492DEEE86A2B29096DEB492F4D4608A82A29C928288848C82D28A826CB0EE8C8CA0E4DCAAE0C262D8A4608E6CE6AA90D6D28CDCF0F2AC6886AC8E8EDAE2B0D46660A0DA8EA0AA86928CDC6890965EE864D4AE62F0F4666888E28CA6988C9EAC90EC92648AD498D4AC8A96F0C4AEE866D69464968E01169805000C2E00114C0280063F6044D494942305443434158696741774942416749434D446B77435159484B6F5A497A6A3045415442504D52457744775944565151444441684E54314E31596B4E424D54455A4D4263474131554543677751556B6C54525342574D6B636755484A76616D566A6444454C4D416B474131554542684D4352455578456A415142676F4A6B69614A6B2F49735A41455A46674A4E547A4165467730784F4441344D5455784D6A4D304D7A5661467730794D6A41344D5451784D6A4D304D7A56614D4538784554415042674E5642414D4D4345315055335669513045794D526B77467759445651514B4442425353564E464946597952794251636D39715A574E304D517377435159445651514745774A45525445534D42414743676D534A6F6D543869786B41526B57416B31504D466B77457759484B6F5A497A6A3043415159494B6F5A497A6A304441516344516741456C442B682B52682B7255764C6E346B304837346943414656723947525A6E574D6A6434584A306D4F6D5542702F6256684941596D7750784A4353634C794C494C753252577537505246546767375A3334544E554A48714E464D454D7745675944565230544151482F42416777426745422F7749424144414F42674E56485138424166384542414D4341635977485159445652304F4242594546457261486843464656764439784748667067382F52334D44594F694D416B4742797147534D34394241454453414177525149674B6A2B33434D33314A625A387463465A41326C34645662344D663435537075766D326E4447426C563058734349514456666D633866766B4C31615831517576734F37664E7743734F3337462F7845746767744B735A75346C47773D3D470008A60140031FB0226A4A4A1183521A1A0AC34B3A0BBA4A120B3A4A1A6A235BBA1A8ACA425B7AD24BD351822A0AA212826A922BBA23BACA22B28A8A22220B4272A18A53B3119A92228AA22AD26A131A3A098AAA2A1B3BBA8AAB5B62A2929A12BA6B5B1B3AAA4253B30B6AB35322222A626A0B5A3A098AAA2A13426A1A922AABC22B520A8A133B7A535B4B0A53597A4B9AD20A2AD2333A5272A3D20B2A33B983C27A2209A26AA2ABC26B5269826BD2B30A33B983CA6B5209A26AA28BC26B5269826BD2B30A6A29C3C22AA20A82133A72B2120A6A6A1A298A82A99AB34A89822BC26A935BBA33BACA22B28A8A5A2212129A9AB272324A32CBCA93CA128B1B69CB8AD2BA71826A8B9BBA1A8ACA22B28A8A3A2BBA522A92A22A9A6A120A3A1B3B6A9A537B6AA1C34BC35A0A935ABA0B598A826A335BBA2BBACA425B7AD24BD351821A0A8ACA4A5B7AD24BD35182220A8B1A228B3A0A2BC2C3C2839AD3618A9A11B25982822BCBAA43C38369C3B32B2A530A3BB1AA1ACB6259CBA1C24A8B615AD15A225B624ABB235BCB5B899B4AD1A269CA3AAB83D36B7BA38B82D25B9A423AA34391BA81B159B993CB23D30A72326A2A6BBA2B3ACA22B29182A20A8A417A120B3BBA133A2A117BBA4A120AA20A7A133A72B24289C2120B31C22A120A6A1A0A8ACBBA428ACA22B291827A1212CA2A327223A1AA233B92B3A23319C3CA6989C3BA21AA1993599279B2BA7A6A0B5A3A13CB8A3A9A69A1CA120A2A229A8A0BBA933A4B420A6BCB9B13C3133BB39ACA93298393827B536A72B2BACB335B6B1B428A23D2123A935BD3B2199343B3425A3A0B4A2A09CB820A7289C2B3D3139ABA6BA3B35A82136A89CA11926A636B3A418391C98ACAD3829282626373A319BA09EABE8

SHA-256: 8A624F06F7D29216B15462F188D4217A811E2D8D18EEB25CE2252004EFA0BC62

Base64 encoded SHA-256: imJPBvfSkhaxVGLxiNQheoEeLY0Y7rJc4iUgBO+gvGI=

ContractSignatureEncryptedPrivateKey

EXI: 80F3125436F6E74726163745369676E6174757265456E63727970746564507269766174654B65794C02800607005205696432684CE889C82EE885EECEC82F460C8D0A0D888B0A88EB29E729090A68A8AEEEAE6C690E2686AEAEAC6826CE488C6DAEAD694F4D29CA070DA8EC8606CC6D0F0CEE2CEFA00

SHA-256: 59B9F0CBF4E7D528A3E233EC55A3ED41C0971E032727704829E64ED56F2CC829

Base64 encoded SHA-256: Wbnwy/Tn1Sij4jPsVaPtQcCXHgMnJ3BIKeZO1W8syCk=

DHpublickey

EXI: 80F310C44487075626C69636B65794C028006070052056964336B484986A86C2D89C9EEC9CAC8AA490C482CE94A2D856C2AEA8D062E2DCE09A96D28CDCF29696ACE6E4D68EDCCEAC9662D0CE84ACA656E49066F0F088B4AA8ED2A28ACE9CAAF0649E82869490C2AEACDEAE8ECA84D2AC9ED67AFA00

SHA-256: 086D79FE8E5990F26ACC99ED0095B18156D4F1C221D1F72D3C7206B7D5514F81

Base64 encoded SHA-256: CG15/o5ZkPJqzJntAJWxgVbU8cIh0fctPHIGt9VRT4E=

eMAID

EXI: 80F3106654D4149444C02800607005205696434620888A828486866264668284866A6CFA00

SHA-256: 45CD81DFFD1A56BB5F4A796B804CA71721AF434587E0ED803A09EAEBADBB8479

Base64 encoded SHA-256: Rc2B3/0aVrtfSnlrgEynFyGvQ0WH4O2AOgnq6627hHk=

SIGNATURE GENERATION WITH INCORRECT XML NAMESPACE ""

EXI: 808112B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A1AB43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B63239B4B396B6B7B93291B2B1B239B096B9B430991A9B220623696432025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C840B373E197E9CFAA5147C467D8AB47DA83812E3C064E4EE09053CC9DAADE59905208188DA590C4095A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD214B43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B632B73191B9B430991A9B210453127837BE9490B58AA3178C46A10BD408F16C68C77592E7112900277D05E31020623696434025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C8408B9B03BFFA34AD76BE94F2D700994E2E435E868B0FC1DB007413D5D75B7708F208188DA590CC095A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD214B43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B632B73191B9B430991A9B2100436BCFF472CC87935664CF6804AD8C0AB6A78E110E8FB969E39035BEAA8A7C08DC

The signature value will never be the same because ECDSA always uses a random seed to generate the signature. Therefore, it does not make sense to provide a signature value here for comparison. HINT: Do not make the mistake to hash the EXI binary stream before you run ECDSA on it. ECDSA already performs a SHA-256 hashing operation!