compareSchema returns false for constructed OctetString

[microshine]

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);

[YuryStrozhevsky]

Use Choice.

[microshine]

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

[YuryStrozhevsky]

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.

[YuryStrozhevsky]

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.