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. 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... > > > >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. 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). > > > >4) update "Issue New Certificate for Host" dialog and documentation > > > >The web UI has an update "Issue New Certificate for Host" dialog which > >explains how to create a CSR with certutil. This dialog should be > >updated to explain how to add a SAN DNS field. The option for SAN DNS is > >'-8 fqdn' or '--extSAN dns:fqdn', e.g. > > > >Create a CSR with subject CN=<hostname>,O=<realm>, for example: > ># certutil -R -d <database path> -a -g <key size> -s > >'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' > > rob > -- 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