I updated the OpenV2G to support the Big number of X509 SerialNumber based on the commit. (struct type)
But oddly the hash value was not match when communicating with other devices (These probably didn't use the OpenV2G library).
There's no issue between the EVCC and SECC which use the OpenV2G library.
I'm suspicious that the openV2G is adding 1byte more to handle positive & negative sign.
Is there any problem to handle the big number of X509 serial number?
Any advice is welcome.
Thanks.
Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have found an issue in the encoding. It indeed adds a byte because of the encoding on 7 bits and 1 bit more to indicate if the encoding is done or not.
For example, if the serial number is 9:
This is 0b00001001 in binary. So we need 4 bits to encode it. Then openv2g considers that we need a byte, then 8 bits. As the bits are encoded 7 by 7, openv2g considers that we need 2 bytes to encode this number. We have patched this and tested it sucessfully. We might share a fix proposal for this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you have an example XML (or EXI) message that you would like to encode and can point us to to where something goes wrong. Honestly I doubt that there is a problem since it is used for a very long time now without any issues.
Note: please also let us know what codec you are using (e.g. iso1) etc
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using iso1 codec.
The issue is not encoding/decoding directly but on computing the signature.
The payload is encoded and received by a server using exificient. When receiving the request, the server decodes successfully the request. Then it has to encode the payload (without the signature) to check if the signature is correct. So it encodes back the content to compute a hash.
That is when we face the issue because the payload is different (1 byte more for each root certificate) so the hash is different.
With the current version of openv2g I have this fragment as a result: 800f02a4a21896a0a61040562610404b140060402040410f240ff073c9aa05e60140c10550c919c7a08060460d4624460400c06aa08061832a6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a866232602e0c1413244d1327e458c802322c12a6eac48682645aa086621660120c06aa080c26048ca4603c2e1a6468606a646262666864646cb42e1a6472606a646062666864646ab460b0622c60280c06aa0806181a8ca4a8a4928aac606060606062621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a86622660220c1413244d1327e458c802322c069e8a9a621660120c06aa080c2604cce460b260260c0e550c919c7a04020c10550c919c7a06020e06840009776f6aa5d7a1541b8ab09d01d40a7420475965091c362e9fd2ed3050f70d1a1fca7f7e010a4ea1bcb4d18d117fd6be6d0c84f9b0d09fd01fd2e1f6797a09d5014703f26103ec60180c06aa3a260203fe08046000603e0c06aa3a460830602d0028a9bb3126beaace769e4243619ac3036cd9b5e4bc61032a0c06aa3a3e09031a61031461030f4103094103030cfed0e8e8e0745e5ec6e4d85ce8d6daced2e4ec5ccaee625cc2d2e65ae6e8ce60665cc2c6d8deeac85ccecadac2d8e8de5cc6deda7470605ec6e4d85ed2e6e6eacae45e869c7aa6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86589eaa7aa6a88e589e7a9e8a9a5a865888867aa6eac48682645aa08658867a8ca4603a0c06aa3a1c082c08280a4e0c91809d70d5435707b7677a8f1e19d1857e601c0c06aa3a1e0203fe08080604071060140c10550c919c7a080604068e006088044077c684f6d3fb247634f529b5049450b3572397c3e2d50cf75a072494473a77900440d50f1aee062f0366245a0fd60dd4b42e642790e126cbe4be1ea7089b279aa04a02544433d5632472c433d46522c4f3d4749524556452c434e3d563247526f6f7443412d420b0becf93e4f1d38887000089110cf5353cb10cf51948b13cf551c9a585b1bd9cb10d38f5353d49bdbdd10
With our patch, I get: 800f02a4a21896a0a61040562610404b140060402040410f240ff073c9aa05e60140c10550c919c7a08060460d4624460400c06aa08061832a6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a866232602e0c1413244d1327e458c802322c12a6eac48682645aa086621660120c06aa080c26048ca4603c2e1a6468606a646262666864646cb42e1a6472606a646062666864646ab460b0622c60280c06aa0806181a8ca4a8a4928aac606060606062621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a86622660220c1413244d1327e458c802322c069e8a9a621660120c06aa080c2604cce460b260260c0e550c919c7a04020c10550c919c7a06020e06840009776f6aa5d7a1541b8ab09d01d40a7420475965091c362e9fd2ed3050f70d1a1fca7f7e010a4ea1bcb4d18d117fd6be6d0c84f9b0d09fd01fd2e1f6797a09d5014703f26103ec60180c06aa3a260203fe08046000603e0c06aa3a460830602d0028a9bb3126beaace769e4243619ac3036cd9b5e4bc61032a0c06aa3a3e09031a61031461030f4103094103030cfed0e8e8e0745e5ec6e4d85ce8d6daced2e4ec5ccaee625cc2d2e65ae6e8ce60665cc2c6d8deeac85ccecadac2d8e8de5cc6deda7470605ec6e4d85ed2e6e6eacae45e869c7aa6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86589eaa7aa6a88e589e7a9e8a9a5a865888867aa6eac48682645aa08658867a8ca4603a0c06aa3a1c082c08280a4e0c91809d70d5435707b7677a8f1e19d1857e601c0c06aa3a1e0203fe08080604071060140c10550c919c7a080604068e006088044077c684f6d3fb247634f529b5049450b3572397c3e2d50cf75a072494473a77900440d50f1aee062f0366245a0fd60dd4b42e642790e126cbe4be1ea7089b279aa04a02544433d5632472c433d46522c4f3d4749524556452c434e3d563247526f6f7443412d420b0becf93e4f1d388070089110cf5353cb10cf51948b13cf551c9a585b1bd9cb10d38f5353d49bdbdd10d040245e80
Last edit: Jordan Sautreau 2024-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
I updated the OpenV2G to support the Big number of X509 SerialNumber based on the commit. (struct type)
But oddly the hash value was not match when communicating with other devices (These probably didn't use the OpenV2G library).
There's no issue between the EVCC and SECC which use the OpenV2G library.
I'm suspicious that the openV2G is adding 1byte more to handle positive & negative sign.
Is there any problem to handle the big number of X509 serial number?
Any advice is welcome.
Thanks.
Ben
Hi,
X509SerialNumber is of XML schema type "integer". Hence a signed value.
This means the transmission of a sign value in EXI is required.
Moreover, I am not aware of any issue with this behavior.
-- Daniel
Hello,
We have found an issue in the encoding. It indeed adds a byte because of the encoding on 7 bits and 1 bit more to indicate if the encoding is done or not.
For example, if the serial number is 9:
This is 0b00001001 in binary. So we need 4 bits to encode it. Then openv2g considers that we need a byte, then 8 bits. As the bits are encoded 7 by 7, openv2g considers that we need 2 bytes to encode this number. We have patched this and tested it sucessfully. We might share a fix proposal for this issue.
Do you have an example XML (or EXI) message that you would like to encode and can point us to to where something goes wrong. Honestly I doubt that there is a problem since it is used for a very long time now without any issues.
Note: please also let us know what codec you are using (e.g. iso1) etc
Thanks!
Hi Daniel,
I am using iso1 codec.
The issue is not encoding/decoding directly but on computing the signature.
The payload is encoded and received by a server using exificient. When receiving the request, the server decodes successfully the request. Then it has to encode the payload (without the signature) to check if the signature is correct. So it encodes back the content to compute a hash.
That is when we face the issue because the payload is different (1 byte more for each root certificate) so the hash is different.
Please find below an XML schema to be encoded.
With the current version of openv2g I have this fragment as a result:
800f02a4a21896a0a61040562610404b140060402040410f240ff073c9aa05e60140c10550c919c7a08060460d4624460400c06aa08061832a6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a866232602e0c1413244d1327e458c802322c12a6eac48682645aa086621660120c06aa080c26048ca4603c2e1a6468606a646262666864646cb42e1a6472606a646062666864646ab460b0622c60280c06aa0806181a8ca4a8a4928aac606060606062621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a86622660220c1413244d1327e458c802322c069e8a9a621660120c06aa080c2604cce460b260260c0e550c919c7a04020c10550c919c7a06020e06840009776f6aa5d7a1541b8ab09d01d40a7420475965091c362e9fd2ed3050f70d1a1fca7f7e010a4ea1bcb4d18d117fd6be6d0c84f9b0d09fd01fd2e1f6797a09d5014703f26103ec60180c06aa3a260203fe08046000603e0c06aa3a460830602d0028a9bb3126beaace769e4243619ac3036cd9b5e4bc61032a0c06aa3a3e09031a61031461030f4103094103030cfed0e8e8e0745e5ec6e4d85ce8d6daced2e4ec5ccaee625cc2d2e65ae6e8ce60665cc2c6d8deeac85ccecadac2d8e8de5cc6deda7470605ec6e4d85ed2e6e6eacae45e869c7aa6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86589eaa7aa6a88e589e7a9e8a9a5a865888867aa6eac48682645aa08658867a8ca4603a0c06aa3a1c082c08280a4e0c91809d70d5435707b7677a8f1e19d1857e601c0c06aa3a1e0203fe08080604071060140c10550c919c7a080604068e006088044077c684f6d3fb247634f529b5049450b3572397c3e2d50cf75a072494473a77900440d50f1aee062f0366245a0fd60dd4b42e642790e126cbe4be1ea7089b279aa04a02544433d5632472c433d46522c4f3d4749524556452c434e3d563247526f6f7443412d420b0becf93e4f1d38887000089110cf5353cb10cf51948b13cf551c9a585b1bd9cb10d38f5353d49bdbdd10With our patch, I get:
800f02a4a21896a0a61040562610404b140060402040410f240ff073c9aa05e60140c10550c919c7a08060460d4624460400c06aa08061832a6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a866232602e0c1413244d1327e458c802322c12a6eac48682645aa086621660120c06aa080c26048ca4603c2e1a6468606a646262666864646cb42e1a6472606a646062666864646ab460b0622c60280c06aa0806181a8ca4a8a4928aac606060606062621860140c06aa08161806a6a88e621c60180c06aa0814180a9e8a9a5a86622660220c1413244d1327e458c802322c069e8a9a621660120c06aa080c2604cce460b260260c0e550c919c7a04020c10550c919c7a06020e06840009776f6aa5d7a1541b8ab09d01d40a7420475965091c362e9fd2ed3050f70d1a1fca7f7e010a4ea1bcb4d18d117fd6be6d0c84f9b0d09fd01fd2e1f6797a09d5014703f26103ec60180c06aa3a260203fe08046000603e0c06aa3a460830602d0028a9bb3126beaace769e4243619ac3036cd9b5e4bc61032a0c06aa3a3e09031a61031461030f4103094103030cfed0e8e8e0745e5ec6e4d85ce8d6daced2e4ec5ccaee625cc2d2e65ae6e8ce60665cc2c6d8deeac85ccecadac2d8e8de5cc6deda7470605ec6e4d85ed2e6e6eacae45e869c7aa6eac48682645a845a9e8a9abe8cdee4bea0865a9e8a9a5a86589eaa7aa6a88e589e7a9e8a9a5a865888867aa6eac48682645aa08658867a8ca4603a0c06aa3a1c082c08280a4e0c91809d70d5435707b7677a8f1e19d1857e601c0c06aa3a1e0203fe08080604071060140c10550c919c7a080604068e006088044077c684f6d3fb247634f529b5049450b3572397c3e2d50cf75a072494473a77900440d50f1aee062f0366245a0fd60dd4b42e642790e126cbe4be1ea7089b279aa04a02544433d5632472c433d46522c4f3d4749524556452c434e3d563247526f6f7443412d420b0becf93e4f1d388070089110cf5353cb10cf51948b13cf551c9a585b1bd9cb10d38f5353d49bdbdd10d040245e80Last edit: Jordan Sautreau 2024-05-27