[Freeipa-devel] V4/RFC 2818 review

Tue May 10 14:23:38 UTC 2016

Greetings!
I've received the information from Milan who was UQE reviewer for this design document - ACK on the current version.
Have a nice day,
 - alich -

----- Original Message -----
> From: "Fraser Tweedale" <ftweedal at redhat.com>
> To: "Alexander Bokovoy" <abokovoy at redhat.com>
> Cc: "freeipa-devel" <freeipa-devel at redhat.com>
> Sent: Thursday, April 21, 2016 9:34:51 AM
> Subject: Re: [Freeipa-devel] V4/RFC 2818 review
> 
> 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
> 
> --
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
>