[Freeipa-devel] V4/RFC 2818 review

[Fraser Tweedale]

On Tue, Apr 19, 2016 at 04:14:01PM +0200, 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?
> 
The scope of RFC 6125 seems much larger than RFC 2818, e.g. moving
toward support for SRVName and uniformResourceIdentifier, and
deprecating wildcard certs.

It absolutely makes sense to check my design against RFC 6125 but I
don't think it makes sense to indicate that the design aspires to
"RFC 6125 compliance" (it does not).

I think I will leave the design name and scope as-is but I will
update the design to mention RFC 6125 and the need to comply with
relevant aspects thereof.

> 
> 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?
> 
The preceding point states:

     For each dNSName in the subjectAltName extension, in addition
     to the existing checks, append the value to the list of DNS
     names.

These existing checks ensure that each dnsName matches a principal
that is "managed by" the nominated subject principal (nb: each
host/service manages itself).

The final point ensure that one of the dnsNames does actually
correspond to the subject principal.  i.e. you can't issue
containing dnsNames managed by the subject principal, yet omit a
dnsName for the subject principal itself.  I will expand the wording
of the design to (try to) clarify this.

> 
> 3) Should FreeIPA deprecate cert request without SAN or at least warn
> the user?
> 
> IMHO it makes sense to deprecate CN only cert requests.
> 
See my response to Rob's reply.

> 
> 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'
> 
Yes, good idea.

Thanks for the review!
Fraser