RDN representation in CERTs

[rapropos]

I don't know near enough of the details of how x509 and ASN.1 are supposed to work, but I am having a problem with subject and issuer names in certificates built in PKI.js not being read properly by other x509 parsers (specifically, golang's). When more than one attribute is added to the RDN object in the subject or issuer, using the syntax recommended in your documentation:

       cert.subject.types_and_values.push(new pkijs.org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
            type: "2.5.4.6", // countryCode
            value: new pkijs.org.pkijs.asn1.PRINTABLESTRING({value: 'JP'})
        }));
        cert.subject.types_and_values.push(new pkijs.org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
            type: "2.5.4.3", // commonName
            value: new pkijs.org.pkijs.asn1.UTF8STRING({value: cn})
        }));

On the receiving end, only the countryCode is visible. The commonName is not. If I reverse the order of the pushes, the commonName becomes visible and we lose the countryCode.

Again, apologies if I mess up the terminology here, but as I understand it, you are generating a SEQUENCE containing a single SET value that in turn contains all of the attribute/value pairs (as embedded SEQUENCEs). If I look at other certificates generated by CAs, I see instead that a subject or issuer is a SEQUENCE of SETs, each SET containing a single attribute/value pair. BouncyCastle also seems to be expecting a subject or issuer to be an array of RDN objects, not a single one with multiple attributes in a SET. So, in order to get things to interoperate, I changed RDN's toSchema function as follows:

var output_array = new Array();
                var setelem;

                for (var i = 0; i < this.types_and_values.length; i++) {
                    setelem = new in_window.org.pkijs.asn1.SET({value: [this.types_and_values[i].toSchema()]});
                    output_array.push(setelem);
                }

                return (new in_window.org.pkijs.asn1.SEQUENCE({
                    value: output_array
                }));

This makes both attributes visible on the other side. I do not know if this is a bug in PKI.js, a problem with the way I am building the certificate, or merely an inconsistency in the way PKI.js and other x509 implementations handle distinguished names, in which case I have no idea what the right answer is. If anybody else is having trouble with parsing out names from PKI.js-generated certificates in other implementations, maybe this will help.

[YuryStrozhevsky]

I think you should report a bug for golang :) It is because PKIjs certificates work fine for either Windows CryptoAPI or OpenSSL. Also no problems with our certificates during signing Adobe PDF documents.

If I look at other certificates generated by CAs, I see instead that a subject or issuer is a SEQUENCE of SETs, each SET containing a single attribute/value pair.

The problem with other libs that they do not support the case when all attributes are inside one SET, as you correctly stated. From my point of view making SET with only one element is a kind of "insufficient usage" for the SET type.

[fniel]

As I understand it the distinguished name allows a hierarchy of relative distinguished names. You will usually have one attribute (type and value pair) for each level in the hierarchy (like C=DE, O=Example Organization, CN=Ulysses Unique). But you may have a case where one attribute is not enough to distinguish between two entities on one level. If you have two John Does in your organization you may add their email addresses as attributes: C=DE, O=Example Organization, CN=John Doe+emailAddress=doe2@example.com (emailAddress is considered deprecated in DNs, this is just an example.)

In this case CN and emailAddress are on the same level, in the same SET, (in the same RDN,) while C and O are in different SETs in the same SEQUENCE that is the DN. So it would be nice to be able to create certificates and PKCS10-requests that allow both multiple RDNs and multiple type and value pairs inside a single RDN.

@YuryStrozhevsky, I see your point about "insufficient usage" for the SET type. But don't you think that the SEQUENCE with just one big SET is "insufficient usage" for the SEQUENCE type? ;-)

[YuryStrozhevsky]

In fact PKIjs (and ASN1js) is very flexible. And if you wish to have RDN with multiple SETs then you could re-implement "in_window.org.pkijs.simpl.RDN.prototype.toSchema" function and get what you want.