Home » Eclipse Projects » Eclipse Titan » COER encoding issue with EtsiTs102941Data(COER ASN.1 extensions codec)
COER encoding issue with EtsiTs102941Data [message #1860911] |
Fri, 08 September 2023 05:47  |
Eclipse User |
|
|
|
Hello,
I got an issue perhaps different than the one raised here: https://www.eclipse.org/forums/index.php/t/1113558/
It is on the way to encode the following ASN.1 structure:
EtsiTs102941Data {
version = 1
content {
butterflyAuthorizationResponse {
version = 2
generationTime = 621249036
currentI = 452
requestHash = 3bd81de27a6f8539
nextDlTime = 621249156
}
}
}
With TITAN, I got: 018E1400022507820C01C43BD81DE27A6F853925078284
On another side (Microsec), I have:
018F140002250783A101C4F2D936DD86BFA83A25078419
I have attached a project to illustrate it: this is the test TC_coer_decoding_issue_etsi_ts_102941_data
Command:
Many thanks in advance for your support,
BR \Yann Garcia
FSCOM
|
|
|
Re: COER encoding issue with EtsiTs102941Data [message #1861159 is a reply to message #1860911] |
Mon, 25 September 2023 08:23   |
Eclipse User |
|
|
|
Dear Support,
I have an additional information: it seems this bug is linked with the encoding of extended fields of the EtsiTs102941DataContent data structure(butterflyCertificateRequest...):
EtsiTs102941Data::= SEQUENCE {
version Version (v1),
content EtsiTs102941DataContent
}
EtsiTs102941DataContent ::= CHOICE {
enrolmentRequest InnerEcRequestSignedForPop,
enrolmentResponse InnerEcResponse,
authorizationRequest InnerAtRequest,
authorizationResponse InnerAtResponse,
certificateRevocationList ToBeSignedCrl,
certificateTrustListTlm ToBeSignedTlmCtl,
certificateTrustListRca ToBeSignedRcaCtl,
authorizationValidationRequest AuthorizationValidationRequest,
authorizationValidationResponse AuthorizationValidationResponse,
caCertificateRequest CaCertificateRequest,
...,
linkCertificateTlm ToBeSignedLinkCertificateTlm,
singleSignedLinkCertificateRca ToBeSignedLinkCertificateRca,
doubleSignedlinkCertificateRca RcaSingleSignedLinkCertificateMessage,
/* Extension for butterfly key provisioning */
[[butterflyAuthorizationRequest EeRaCertRequest,
butterflyAuthorizationResponse RaEeCertInfo,
butterflyCertificateRequest RaAcaCertRequest,
butterflyCertificateResponse AcaRaCertResponse,
butterflyAtDownloadRequest EeRaDownloadRequest]]
}
Do you have any hint to help me?
Many thanks in advance,
BR\Yann Garcia
|
|
|
Re: COER encoding issue with EtsiTs102941Data [message #1861391 is a reply to message #1861159] |
Tue, 10 October 2023 12:14   |
Eclipse User |
|
|
|
Hi Yann,
I tried to figure out this issue. Are you sure that your other side (Microsec) works properly?
Here is my solution for the encoding taking into account the ASN.1 definition of the EtsiTs102941Data:
Automatic tagging is applied, but this would be the definition with explicit tagging according to my understanding:
EtsiTs102941DataContent ::= CHOICE {
enrolmentRequest [0] InnerEcRequestSignedForPop,
enrolmentResponse [1] InnerEcResponse,
authorizationRequest [2] InnerAtRequest,
authorizationResponse [3] InnerAtResponse,
certificateRevocationList [4] ToBeSignedCrl,
certificateTrustListTlm [5] ToBeSignedTlmCtl,
certificateTrustListRca [6] ToBeSignedRcaCtl,
authorizationValidationRequest [7] AuthorizationValidationRequest,
authorizationValidationResponse [8] AuthorizationValidationResponse,
caCertificateRequest [9] CaCertificateRequest,
...,
linkCertificateTlm [10] ToBeSignedLinkCertificateTlm,
singleSignedLinkCertificateRca [11] ToBeSignedLinkCertificateRca,
doubleSignedlinkCertificateRca [12] RcaSingleSignedLinkCertificateMessage,
/* Extension for butterfly key provisioning */
[[butterflyAuthorizationRequest [13] EeRaCertRequest,
butterflyAuthorizationResponse [14] RaEeCertInfo,
butterflyCertificateRequest [15] RaAcaCertRequest,
butterflyCertificateResponse [16] AcaRaCertResponse,
butterflyAtDownloadRequest [17] EeRaDownloadRequest]]
}
Therefore the tag for butterflyAuthorizationResponse is 14. (At this point, I am not 100% sure that the tag value is 14 due to the extension additions, nevertheless the continuous numbering seems logical.) This is encoded into '8E'O ('10001110'B). Here, the first 2 bits ('10'B) means that this is a context specific tag and the other 6 bits ('001110'B) means the tag value that is 14.
The decoded value of the tag provided by Microsec is 15 ('8F'O -> '10'B + '001111'B), thus Titan assumes during the decoding that this is a butterflyCertificateRequest and tries to decode the remaining part accordingly.
In my opinion, this behavior seems fine and is conform with the encoding rules.
[Updated on: Tue, 10 October 2023 12:15] by Moderator
|
|
| | | |
Goto Forum:
Current Time: Sat Jul 05 17:09:07 EDT 2025
Powered by FUDForum. Page generated in 0.05852 seconds
|