[Freeipa-devel] V4/RFC 2818 review

[Fraser Tweedale]

On Thu, Apr 21, 2016 at 10:22:33AM +0300, Alexander Bokovoy wrote:
> 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
> 
Thank you for the information!

> 
> 
> >>>
> >>>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.
> 
There is the option of implementing the component that prohibits CN.
I was by no means suggesting it should be used for all profiles.
Customers can use it on a custom profile if they want.  We could use
it on the default service cert profile if we want.

Cheers,
Fraser