Add ber tag factory to parser to allow custom tag creation. #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
We are dealing with an errornous ber tlv data that is defined by GlobalPlatform.
GlobalPlatform used 'B0' and 'F0' tags for primitive tlv however since their contructed bit is set,
ber-tlv rightfully fails to parse them. Since Globalplatform decided to not to fix them, we need a way to handle these tags. I thought, if ber-tlv parser takes a tag factory, then we can write a custom tag factory to handle them. Therefore I added an interface and a default factory. Could you please review it and if it is OK for you, could you please add it to the project? Currently, there is no way to override the parsing behaviour.
This may help to cope with data that was designed errornously such as
GlobalPlatform public key data which has 'B0' and 'F0' tags which are
not valid. Explanation from document [1] - Table 3-8:
GlobalPlatform acknowledges as an error that values 'B0' and 'F0' in the table above are not
valid ASN.1 tag values. This mistake was introduced in previous versions of this specification.
Although this may be a problem for standard tools used to edit or display certificates and ASN.1
structures in general, it’s been decided, for the moment at least, to keep such values to preserve
backward compatibility with existing implementations already coping with such errors.
[1] https://globalplatform.org/wp-content/uploads/2019/07/GPC_2.3_A_ConfidentialCardContentMgmt_v1.2_PublicRelease-replacement.pdf