ASN1.js
ASN1.js copied to clipboard
compareSchema returns `false` for constructed OctetString
ASN1.js module uses strict verification for isConstructed property in schema. How can I create a schema which supports both cases for OCTET STRING type?
const raw = new Uint8Array([0x24, 0x80, 0x00, 0x00]); // [0x40, 0x00]
const { result } = asn1.fromBER(raw.buffer);
const schema = new asn1.OctetString();
// schema.idBlock.isConstructed = true;
const { verified } = asn1.compareSchema(result, result, schema);
assert.strictEqual(verified, true);
Use Choice.
RFC 5652 seys that eContent is OCTET STRING.
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
I know that it's possible to use CHOICE for that case. But it doesn't match to ASN1 schema. You are suggesting to implement something like that
EncapsulatedContent ::= CHOICE {
simple OCTET STRING,
constructed OCTET STRING}
What if don't throw validation error for objects which allow subitems and use isConstructed field
OctetString {
isConstructed: true,
items: [
OctetString {
isConstructed: false,
value: // array buffer
},
OctetString {
isConstructed: false,
value: // array buffer
},
...
]
}
And it would be nice if constructed OctetString could normalize items and return concatenated arrays without ASN tags
The ASN1js introduced a difference between constricted and simple form of OCTET STRING, as well as BINARY STRING. In fact since schema comparison function count them as a different types then, accordingly to ASN.1 standard in ASN.1 schema we need to have CHOICE. So no violations of ASN.1 standard here at all.
Not sure I understood your sentence about "allow subitems and use isConstructed field" - it is already done in ASN1js. What you describing could be made in ASN1js using REPEATED special class, check PKIjs for examples.
As for "return concatenated arrays": you could use this block of code for this purpose. As far I as remember it is the only place in entire PKI which requires to have "concatenated arrays". Making a special API function for this one case is really a bad idea.
Oh, just got into my mind: accordingly to ASN.1 standard the "value" of constructed OCTET STRING could be another constructed OCTET STRING. Just for your information.