[Freeipa-devel] V4/RFC 2818 review

[Fraser Tweedale]

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
>