[Freeipa-devel] V4/RFC 2818 review

[Alexander Bokovoy]

On Thu, 21 Apr 2016, Fraser Tweedale wrote:
>On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote:
>> Christian Heimes wrote:
>> >Hi Fraser,
>> >
>> >and now to the review of your design doc for RFC 2818-compliant subject
>> >alternative names in certs,
>> >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance
>> >
>> >
>> >1) RFC 2818 vs. RFC 6125
>> >
>> >First I like to address a more general topic. Your design mentions RFC
>> >6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname
>> >verification and we should follow the rules in RFC 6125, whenever 2818
>> >lacks specification or there is a conflict between both RFCs. I can tell
>> >you some horror stories from Python's ssl module related to both RFCs.
>> >
>> >https://tools.ietf.org/html/rfc2818, HTTP Over TLS
>> >
>> >https://tools.ietf.org/html/rfc6125, Representation and Verification of
>> >Domain-Based Application Service Identity within Internet Public Key
>> >Infrastructure Using X.509 (PKIX) Certificates in the Context of
>> >Transport Layer Security (TLS)
>> >
>> >As far as I'm familiar with RFC 6125, your proposal doesn't conflict
>> >with the more modern RFC. It also makes sense to name the design after
>> >the RFC, which has deprecated CN. I still like to check your design
>> >against RFC 6125.
>> >
>> >Fraser, do you agree?
>> >
>> >
>> >2) SAN validation in ipa cert-request
>> >
>> >In the paragraph "ipa cert-request changes" you write that the plugin
>> >"[...] ensure that one element of the DNS names list matches the
>> >principal name". Shouldn't the plugin validate *all* DNS names and
>> >verify that the principal is allowed to request a cert for all fields in
>> >SAN?
>>
>> Are there plans for any other SAN types? IP address or other oddball types
>> like MS UPN?
>>
>We support almost all of them in Dogtag, and only support a few
>types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN).
>
>We should work out what we can do with IP address; I recall it is
>needed (or wanted) for some cloud/IaaS use cases.
Yes, some of Openstack code expects IP address in the certificates.

>DirectoryName would be simple to support (just check that it matches
>DN of target principal).  I wonder if there is a use case for it, or
>for any other SAN types...
dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT
Kerberos for host-based principals. id-pkinit-san is also in use for
mapping of the principal in general. 

In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate and
allows to match them by the matching rules -- id-pkinit-san goes to list
of principals, id-ms-san-upn goes to the list of UPNs which are then
merged together and can be addressed with <SAN> keyword in the matching
rule.

This allows very flexible matching:
                pkinit_cert_match = ||<SUBJECT>.*DoE.*<SAN>.*@EXAMPLE.COM
                pkinit_cert_match = &&<EKU>msScLogin,clientAuth<ISSUER>.*DoE.*
                pkinit_cert_match = <EKU>msScLogin,clientAuth<KU>digitalSignature



>> >
>> >3) Should FreeIPA deprecate cert request without SAN or at least warn
>> >the user?
>> >
>> >IMHO it makes sense to deprecate CN only cert requests.
>>
>> I'd mark it as deprecated over at least a major release in order to handle
>> older versions that may still make requests without a SAN.
>>
>We have to be careful here.  CN is depreated for DNS name checking
>in HTTP (or other network protocols using TLS).  Fine - but there
>could be other certificate use cases that require CN, e.g. user
>certs where Subject DN corresponds to a directory name.
Yes. pkinit_cert_match's <SUBJECT> rule is using Subject DN for checks.


>We can deprecate it and eventually reject requests that include CN -
>but only for service cert profile(s).  (This would require a new
>profile component designed for this purpose).
Please do not do it. There are known uses for it at least with Kerberos.
Of course, most of them are rather for user certificates but in reality
Kerberos does not require you to have service principals always as DNS
names.

-- 
/ Alexander Bokovoy