NAME

Crypt::Perl::X509::Name - Representation of Distinguished Name

SYNOPSIS

    #This encodes each key/value into separate
    #RelativeDistinguishedName structures, as OpenSSL does by default.
    #Unless you know otherwise, this is probably what you want.
    #(See ENCODING below for more details.)
    my $name = Crypt::Perl::X509::Name->new(
        streetAddress => '...',     #keys are short OID names
        localityName => '...',
        #...
    );
    my $der = $name->encode();

DISCUSSION

This is useful to represent the Subject and Issuer parts of an X.509 (i.e., SSL/TLS) certificate as well as the name portion of a PCKS #10 Certificate Signing Request (CSR).

ENCODING

RFC 5280 §4.1.2.4 <https://tools.ietf.org/html/rfc5280#section-4.1.2.4> defines the "Name" type as an ordered "SEQUENCE" of unordered "SET"s —"RelativeDistinguishedName" objects, or “RDN”s—of key/value pairs. OpenSSL defaults to having each RDN contain only one key/value pair. (You can also have it create “multi-value RDNs”. <http://openssl.6102.n7.nabble.com/Multi-value-RDNs-and-openssl-cnf-format-td7925.html>) I’m unclear as to why this is, but I suspect it has to do with ease of matching up "Name" values; since the RDNs are unordered, to compare one multi-value RDN against another takes more work than to compare two ordered lists of single-value RDNs, which can be done with a simple text equality check. (cf. RFC 5280 §7.1 <http://tools.ietf.org/html/rfc5280#section-7.1>)

If you need a multi-value RDN, it can be gotten by grouping key/value pairs in an array reference, thus:

    my $name = Crypt::Perl::X509::Name->new(
        #a multi-value RDN
        [ streetAddress => '...', localityName => '...' ],
        #regular key/value pair becomes its own single-value RDN
        stateOrProvinceName => '...',
    );

ABOUT "commonName"

Note that "commonName" is deprecated (cf. RFC 6125 §2.3 <https://tools.ietf.org/html/rfc6125#section-2.3>, CA Browser Forum Baseline Requirements §7.1.4.2.2 <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf>) for use in X.509 certificates, but many CAs still require it as of December 2016.