Re: [Pki-devel] [Freeipa-devel] Design review request: RFC 2818 certificate compliance

On Fri, Mar 11, 2016 at 10:20:49AM -0800, Christina Fu wrote: > Hi Fraser, > > I think the general idea looks good. If tested to work, I actually think > you should have it replace the current caServerCert.cfg and make it the > default server cert profile for Dogtag. So I'd suggest you name things more > generically. > Thanks Christina for the feedback. W.r.t naming, can you clarify what you think should be more generic and why?

> Just for your reference, there is an implementation that injects SAN(s) into > server certs at time of Dogtag instance creation. It also allows one to put > multiple SANs in one ssl server cert: > https://fedorahosted.org/pki/ticket/1316#comment:14 > again, it's only limited to pkispawn option so it serves a different > purpose. > > Christina > > On 03/10/2016 05:06 PM, Fraser Tweedale wrote: >> On Mon, Mar 07, 2016 at 07:33:52AM +0100, Jan Cholasta wrote: >>> Hi, >>> >>> On 29.2.2016 07:59, Fraser Tweedale wrote: >>>> Hi all (especially those interested in certificates), >>>> >>>> Please provide early review of my design for RFC 2818 compliance >>>> which will address the following tickets: >>>> >>>> - #4970 Server certificate profile should always include a Subject Alternate name for the host >>>> - #5706 [RFE] Support SAN-only certificates >>>> >>>> http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance >>>> >>>> The design is a WIP and there is no code for it yet. Looking for >>>> feedback and (hopefully) validation of the approach before >>>> committing cycles to implementing new profile components in Dogtag. >>> 1) Do wildcard certificates need special handling? There is no mention of >>> them in the design doc. >>> >> No special handling of wildcard certs is needed but I've added some >> commentary to the design page. >> >>> 2) Should we accept invalid CSR where CN length is greater than 64? I >>> wouldn't be surprised if these existed in the wild. >>> >> Good question. I agree such CSRs probably exist. There are various >> ways to handle them: >> >> a) Reject request (with useful message; instruction to issue >> SAN-only request instead) >> >> b) Issue non-compliant cert with overlong CN. It will be helpful to >> find out how important clients handle such certs. >> >> c) Accept the CSR but "promote" the overlong CN from CSR into a SAN >> dnsName, and issue a SAN-only cert. Some clients may not handle >> such certs very well. >> >> Personally I like (c), because the user intent is clear but we still >> issue a valid cert, however, I expect there are clients out there >> (particularly in "enterprise" environments?) that will not handle it >> well. >> >> I've copied pki-devel@ to solicit additional insights here :) >> >>> 3) Sometimes it is not clear which parts belong to Dogtag and which to IPA >>> itself. For example the upgrade section - I assume Dogtag should update >>> registry.cfg and IPA caIPAserviceCert profile, but it is not clearly stated >>> anywhere. >>> >> Thanks, I've added clarifying remarks. In brief: yes Dogtag should >> update registry.cfg, but FreeIPA should update the profile. >> >> Thank you for your feedback, Jan. >> Fraser >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -- > 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