DDSSEC12 — How are 'subject_name' fields compared?

In 9.4.1.3.2 Grant Section, the spec states:

"A permissions [sic, should be grant] Section with a subject name that does not match the subject name given in the corresponding Authorization certificate shall be ignored."

It is not clear what algorithm should be applied to determine if two subject_names "match"; and this has interoperability implications.

A 'simple' approach would be a simple string comparison.

A 'complex' approach would be to do the following:

1) parse each subject_name as a series of name=value pairs,
2) check that all name's exist in each subject_name
3) check that for each name, the corresponding 'value' matches, using regex (for example fnmatch(), or similar) processing.

The more complex approach might be beneficial, because it could support using a 'wildcard' Common Name. For example, in the permissions file, use a Subject Name like this:

      <subject_name>/C=US/ST=CO/O=Twin Oaks Computing/CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com</subject_name>

Then, the Identity Cert's could be constructed with a more specific Subject Name, like "CN=participant1.twinoakscomputing.com", and it would match.

Specify format of subject name and rules for comparison

The string format of the subject name should be specified. The proposal is to follow IETF RFC 4514 (https://datatracker.ietf.org/doc/html/rfc4514#section-3), that is a ","-separated sequence of <name>=<value> pairs. For example:

"C=US, ST=CO, O=Twin Oaks, Computing, CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com"

The matching of subject names should check the list of names is the same and the corresponding values match using the fnmatch() function (POSIX 1003.2-1992, Section B.6)

The order of the names does not impact the matching.

Note that "," may be present in the value part. Likely we do not want to constrain this as it is generated from tools like openssl which may put those commas based on user input.
However this can be unabiguously parsed making the following assumptions.

• The character '=' is reserved. it can only appear to separate the name v. value pair.
• Whitespace surrounding the "=" is ignored/removed for the purposes of comparison
• The name can;t have whitespace. and can;' have ","
• The value starts after the '=' skipping any whistapce that immediately follows the '=' abd ectends to the last "," before the next "="