[openssl-users] Strictness of comparing distinguished names
Jakob Bohm
jb-openssl at wisemo.com
Fri Oct 2 14:56:13 UTC 2015
On 02/10/2015 16:20, Jeffrey Walton wrote:
>> So I am wondering what the officially correct behavior is
>> when verifying such a case. Should the
>> SignerInfo.issuerAndSerialNumber.issuer be treated as
>> matching or as not matching a certificate in which an
>> otherwise identical string is tagged differently but
>> represents the same textual value (because it uses only
>> the common subset of the two string encodings)?
> DN's are required to be encoded with UTF8String since RFC 3280 (circa 2004).
>
> RFC 4158,
>
> Certification Path Building, tells us some agents may not handle
> encodings well, like BMPString. I think you may have found a few
> examples.
Detailed testing (before my post) showed that both implementations
handle both encodings on their own, and that neither implementation
is restricted to the PKIX subset in this regard.
Thus the issue is this:
Suppose an actual, trusted CA certificate (and thus all the
certificates issued under it) encodes an element of the CA
distinguished name using the T61STRING type permitted by the
original ITU standards.
An end-entity holding such an issued certificate then uses a
signing tool which "canonicalizes" the issuer name to its PKIX
UTF8STRING equivalent before outputting the
SignerInfo.issuerAndSerialNumber.issuer element of the
signature.
Now the question is who is at fault here:
- CMS implementations that refuse to accept the signature
because a part of the SignerInfo.issuerAndSerialNumber.issuer
value uses a different option from the relevant ASN.1 CHOICE,
thus causing its purely DER-normalized form to be binary
different from the purely DER-normalized form of the same
distinguished name found during certificate chain building.
- The signing tool that changed this aspect of the
distinguished name when generating the signature.
At least one of the tools involved is buggy, question is
which one.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
More information about the openssl-users
mailing list