EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Not including ASN1 DEFAULT elements

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#30274
Posted: 08/12/2014 07:54:47
by Andy Calvert (Standard support level)
Joined: 11/07/2007
Posts: 16

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

Is this possible using PKIBlackBox ? I don't believe that it is .....

Thanks for any help.
#30298
Posted: 08/13/2014 05:42:26
by Eugene Mayevski (EldoS Corp.)

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.


Sincerely yours
Eugene Mayevski
#30299
Posted: 08/13/2014 05:45:34
by Eugene Mayevski (EldoS Corp.)

One more addition: the specification for ASN.1 ( http://www.itu.int/ITU-T/studygroups/...0-0207.pdf ) says:

Quote

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.


Sincerely yours
Eugene Mayevski
#30303
Posted: 08/13/2014 07:57:14
by Andy Calvert (Standard support level)
Joined: 11/07/2007
Posts: 16

Thanks Eugene, those were exactly the quotes that I have already used with the customer :) (Same paragraph number from the ITU spec).

I will try to get our customer to apply pressure to the 3rd party for them to fix their kit.

Andy
#30332
Posted: 08/14/2014 05:23:22
by Andy Calvert (Standard support level)
Joined: 11/07/2007
Posts: 16

The 3rd party supplier has pointed out a separate paragraph in the ITU spec.

Para 11.5 states that for DER encoding, "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."

So when we export certificates in DER format to a buffer using TElX509Certificate.SaveToBuffer(), the DEFAULT fields should in fact not be present.

Hmmm, they look as though they are correct, and SecureBlackBox certificates are non-conformant.
#30333
Posted: 08/14/2014 05:27:17
by Vsevolod Ievgiienko (EldoS Corp.)

Quote
set value or sequence value

But we are talking about simple BOOLEAN value, but not a SET or SEQUENCE.
#30334
Posted: 08/14/2014 05:34:29
by Eugene Mayevski (EldoS Corp.)

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.


Sincerely yours
Eugene Mayevski
#30336
Posted: 08/14/2014 06:06:10
by Andy Calvert (Standard support level)
Joined: 11/07/2007
Posts: 16

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.

RFC5280 does define the ASN.1 of a certificate extension as :

Extension::=SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}

so it is actually defined as DEFAULT.
#30339
Posted: 08/14/2014 06:12:14
by Eugene Mayevski (EldoS Corp.)

Quote
Andy Calvert wrote:
RFC5280 does define the ASN.1 of a certificate extension as :


Can you please specify where exactly you've found this?

Also, as I said, it's the first case in 12 years when some software complains. I am afraid that any changes can break compatibility with other software, which is more adequate.

So let me reiterate this - there will be no changes until at least SBB 13.


Sincerely yours
Eugene Mayevski
#30341
Posted: 08/14/2014 06:22:15
by Andy Calvert (Standard support level)
Joined: 11/07/2007
Posts: 16

The quote is from section 4.1 of the spec - entitled Basic Certificate Fields.

Andy
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

Topic viewed 1272 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!