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 defines the Name type as an ordered SEQUENCE of unordered SETs —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”.) 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)

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, CA Browser Forum Baseline Requirements §7.1.4.2.2) for use in X.509 certificates, but many CAs still require it as of December 2016.