cert-request: allow directoryName in SAN extension

[frasertweedale]

Allow directoryName in SAN extension if the value matches the
subject principal's DN in the IPA directory.

Fixes: https://fedorahosted.org/freeipa/ticket/6112

---

A bit of commentary about this feature: it was just a drive-by case
of "hey I could implement this in a way that I think makes sense".
Noone actually asked for it (yet).

Also, there is not agreement that using directoryName to carry the
DN of the subject is valid. On my part, I think it is obviously
valid, but see the original review thread for discussion:
https://www.redhat.com/archives/freeipa-devel/2016-August/msg00714.html

I had to rebase this commit and resolve conflicts, so now it is a PR
and it can age in oak on GitHub instead of the mailing list :)

[tkrizek]

As I have understood from the mailing list discussion, we have two options:

1. We use this patch as is. That means Subject Alternative Name (SAN) DN always has to be the same as the Subject DN. Is there any use case for this? To me this seems like a duplicate info. Isn't the purpose of SAN to provide an alternative name?

2. We extend the validation to allow any existing principal. Are there any use cases for this?

Perhaps I'm missing something, but the first option doesn't seem very useful and I don't know if the second one is a valid and needed use case.

[frasertweedale]

@tomaskrizek

1. The SAN DN is permitted if it matches the IPA principal's full DN in LDAP. The certificate subject DN need not match the LDAP DN. In fact, by the current behaviour of ipa cert-request it cannot, because we expect to see the user name in the CN in the CSR subject DN, whereas in LDAP we use uid=alice,cn=users,.... So it is not duplicate info - it names the subject's LDAP DN.

2. In this patch, DirectoryName SAN is accepted for all principal types (as long as it matches their LDAP DN). Existing rules for other SAN name types are not changed (e.g., DNSName is still allowed only for host and service principals).

[HonzaCholasta]

@frasertweedale, if the subject DN need not match the LDAP DN, then DN SANs need not match it as well - both the subject DN and DN SANs are supposed to identify the subject in the directory, and for us the directory is LDAP. There should be no special casing one way or the other, if something is allowed for the subject DN it must be allowed for DN SANs and vice-versa (with the exception of the special handling of the most specific CN in subject DN of server certificates). The fact that we currently require a non-LDAP subject DN in cert-request is a different issue. All I'm asking for is consistency. If we first allowed the subject DN to match the LDAP DN I would be perfectly happy with this PR.

[frasertweedale]

@jcholast OK. Let's put this PR on ice for now... I may well take up your suggestion to allow subject DN to match LDAP DN, but I don't have the cycles for it right now.

Thanks for your feedback.

[tiran]

@jcholast I'm not familiar with any standard that mandates that a X.509 Subject DN should identify a subject in a directory. Which standard mandates the relationship? RFC 5280 only requires that the Subject DN must be unique for each entity. A CA is allowed to issue multiple certs with the same Subject DN for the same entity. https://tools.ietf.org/html/rfc5280#section-4.1.2.6

[HonzaCholasta]

@tiran, could you please stay on topic? I haven't said anything about it being mandatory, and it's not the point anyway (consistency between subject DN and DN SAN validation is). About CA being allowed to issue multiple certs with the same subject DN, thanks for stating the obvious, but again, not the point here.

[tiran]

I'm on topic and I'm trying to understand your point. Why do you see a relationship between the subject DN of a X.509 and the directoryName general name in SAN X.509v3 extension? It doesn't make sense to me. The subject follows different rules, e.g. a disjunct set of RDN attributes. Attributes like DC, UID etc. are not commonly found in a X.509 cert's subject.

Further more a CA usually imposes some policies and requires the certificate's subject to have fixed C, O, OU etc values. With multiple SubCAs (e.g. for VPN, client cert auth, host certs) we end up with different subject DNs but with the same directoryName GN SAN entry. The directoryName is designed to hold a LDAP DN.

By the way, I was quoting the RFC to give some context. With X.509 there is no such thing as an obvious thing. In fact multiple certs with the same Subject DN is very relevant and important for this topic. A certificate's Subject DN is not really a distinguishing name in the sense of a unique identifier.

[tkrizek]

@frasertweedale Oh, I didn't realize the DN in SAN matches the LDAP DN, while the Subject DN does not.

In that case, this PR makes sense to me as is. I also don't see the need to validate Subject DN and SAN DN the same way, since they use different representation (subject is a more generic identifier, as @tiran pointed out; while SAN DN should be the unique LDAP DN identifier).

[HonzaCholasta]

Ok,

Why do you see a relationship between the subject DN of a X.509 and the directoryName general name in SAN X.509v3 extension?

According to RFC 5280 section 4.1.2.6 the subject DN and SANs are equivallent in terms of identifying the subject entity:

The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY be
carried in the subject field and/or the subjectAltName extension.

Compare how the subject DN is defined in RFC 5280 section 4.1.2.6:

Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity.

... with how the DN SAN is defined in RFC 5280 section 4.2.1.6:

When the subjectAltName extension contains a DN in the directoryName,
the encoding rules are the same as those specified for the issuer
field in Section 4.1.2.4. The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity.

See that there is no mention of any semantical difference between them as means of identifying the subject entity.

Further specifications such as the name constraints extension also treat them equally. RFC 5280 section 4.2.1.10:

Restrictions of the form directoryName MUST be applied to the subject
field in the certificate (when the certificate includes a non-empty
subject field) and to any names of type directoryName in the
subjectAltName extension.

The subject follows different rules, e.g. a disjunct set of RDN attributes.

I could not find any mention of this in RFC 5280 nor the X.500 series of standards. I'm assuming it's because it's not there.

Attributes like DC, UID etc. are not commonly found in a X.509 cert's subject.

Neither RFC 5280 nor the X.500 series of standards impose any restrictions on the attributes used. However, RFC 5280 section 4.1.2.4 says:

In addition, implementations of this specification MUST be prepared
to receive the domainComponent attribute, as defined in [RFC4519].

With multiple SubCAs (e.g. for VPN, client cert auth, host certs) we end up with different subject DNs but with the same directoryName GN SAN entry.

Currently we in fact end up with the same subject DN. Which is just fine, as they refer to the same subject entity.

The directoryName is designed to hold a LDAP DN.

I don't think that's true, as there is no mention of this in the directoryName SAN specification (see above).

A certificate's Subject DN is not really a distinguishing name in the sense of a unique identifier.

Let me quote RFC 5280 section 4.1.2.6 again:

Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity.

[frasertweedale]

I'm closing this PR (and associated ticket).

I felt it was an uncontroversial change (and tbh it looks like there are numbers
on my side), but noone is specifically asking for this (it was just a drive-by "hey I could
implement this now"), so let's not waste any more time arguing about it.

[tiran]

@frasertweedale I still think it's a useful and uncontroversial improvement. In a matter of fact I don't understand why this simple and obvious change resulted in a lengthy discussion.