We have been producing X.509 certificates with your software for years. Recently a customer has rejected one, as they have moved to some new 3rd party software. That software requires that any certificate element which has a DEFAULT value, must not be included in the certificate.

I feel that they have misinterpreted the ITU specs for ASN1 encoding, which state that DEFAULT values may be included, but don't have to be.

Anyway, when creating an X.509 certificate and including extensions such as key usage, they require that the OID is present and correct, and that the list of usage bits is present, but the boolean flag that indicates 'critical=false' is not present at all in the certificate (rather than being present, and set to the default value of false).

Indeed the flag is written always. RFC 5280 in section 4.2 says "An extension includes the boolean critical, with a default value of FALSE."

The RFC doesn't state "may include" or "should omit default" or anything similar. Moreover, for some extensions the RFC says " Conforming CAs MUST mark this extension as non-critical" which (for me) sounds like "the Critical flag must be present and must be set to false".

So I would stress the customer's software compatibility and standard compliance rather than implement a feature which would [help] violate the standard in favor of one software title.

8.9.3
The encoding of a data value may, but need not, be present for a type which was referenced with the keyword OPTIONAL or the keyword DEFAULT. If present, it shall appear in the encoding at the point corresponding to the appearance of the type in the ASN.1 definition.

which explicitly (the second sentence) allows presence of data which has default values.

1) There seems to be a misinterpretation of the RFC on the user side. On DER level if you have a set or sequence declaration with an element marked as DEFAULT, the requirement can make sense. However there's no such declaration in RFC 5280. The only statement that is present in the RFC is that by default Critical field should be assumed to have a value of false. So strictly speaking Critical field is not DEFAULT in ASN.1 sense.

2) In presence of conflicting statements smart software should support both variants until the conflict is resolved in the standards.

3) this is the first case in 12 years when such problem appeared. So if the maker of that software wants to stand out of line in terms of [in]compatibility - so be it.

To sum it up, we will consider making some option in future, we can't make an immediate change as it seems to contradict common sense.

Whilst I would agree that their approach is short-sighted, the 3rd party supplier is a huge multi-national, and all their customers will experience this issue with your certificates as they migrate onto newer software versions from that supplier. Hence more of your customers will experience this incompatibility as well.

The issue seems to be related to the fact that with your software the actual signature within the certificate is over all the fields that are present (including the default ones). Their software recalculates the signature over the fields which they believe should be present (excluding the default ones), and hence the signatures do not match.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.