What is the effect of turning strong constraint checking off?

If you turn off strong constraint checking by passing the NOCONSTRAIN flag to the runtime, then the PER encoder will allow values to be encoded/decoded provided that they meet basic requirements required by PER and the local type representations. For example, suppose you have the following, which means that Foo can have a value between 0 and 10 or between 20-25:

Foo ::= INTEGER (0..10 | 20..25)

With strong constraint checking the encoder/decoder would return an error if a value of, say, 15 were received. However, if strong constraint checking were turned off by passing NOCONSTRAIN, an error would not be reported for the value 15 in all the encoding rules supported (like BER/DER/CER/PER/UPER/XER/CXER/etc).

On the other hand, without strong constraint checking the encoder will always encode values correctly (just as with strict constraint checking), but it will not always catch certain invalid values that you might pass to it to encode, such as 15 in the above example. On the decoding side, the decoder would successfully decode a value such as 15 above, but would not detect that it is invalid, so your application would need to have stronger checking for such cases to ensure that the decoded data is indeed valid and does not violate the ASN.1 specification.

Note that even with strong constraint checking turned off the decoder will detect most common subtype constraint violations in PER/UPER. For example, in the above example, a value greater than 25 will be detected by the PER decoder even if you pass the NOCONSTRAIN flag to the runtime. Indeed, in most cases you will notice that subtype constraints are simpler than the above, and look more like:

Bar ::= INTEGER (0..10)

In such cases you gain nothing by having strong constraint checking if PER is in use, for the PER algorithm for encoding/decoding will result in a value greater than 10 being flagged as an error.

OSS provides this strong form of constraint checking to help our customers detect problems with the values they encode/decode much sooner than they otherwise would.

The same is true for trapping of memory violations at runtime. If your application is fully debugged then there is no benefit to trapping memory violations in production code or in doing strict constraint checking in the encoder in a program that is in production. On the decoding side the number of checks that you would need to add to your code for security would be few, for the PER algorithm for decoding values whose type have a subtype constraint will result in most constraint violations being detected without use of strong constraint checking.

The strong constraint checking is done before encoding and right after decoding internally by the encoder/decoder. So the strong constraint checking is far more vital to applications that use BER/DER/CER than for PER/UPER, for subtype constraints have no effect on the structure of BER/DER/CER encodings, and as such BER/CER/DER provides no means for the encoder/decoder to detect constraint violations while encoding/decoding, while in PER/UPER the encoder/decoder has the means due to the very nature of PER/UPER which is dependent on the constraints imposed in the ASN.1 specification.

---

The samples included with some of the Knowledge Center answers are meant for your general understanding of the OSS products. Different versions of the products might produce slightly different outputs. Consult the products documentation and samples for the most up-to-date products information and code examples.