<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 03/12/2016 11:51 PM, Fraser Tweedale wrote: </div> <blockquote cite="mid:20160313075117.GD12127@dhcp-40-8.bne.redhat.com" type="cite"> <pre wrap="">On Fri, Mar 11, 2016 at 10:20:49AM -0800, Christina Fu wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Thanks Christina for the feedback. W.r.t naming, can you clarify what you think should be more generic and why?</pre> </blockquote> Actually it was more of a preemptive comment that was not specifically directed towards anything in your current design. I just took a closer look, and I think your new profile plugin name (<code>SubjectAltNameCopyCNDefault</code>) sounds good. About replacing existing caServerCert.cfg, consider keeping it, but 1. name the new profile something like caServerSANCert.cfg 2. make caServerSANCert.cfg default (enable it), and disable caServerCert.cfg by default Anyway, you get the idea. The point is that I think we should fundamentally adhere to the standard in Dogtag, so such a fix should be part of the Dogtag default. thanks, Christina <blockquote cite="mid:20160313075117.GD12127@dhcp-40-8.bne.redhat.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/pki/ticket/1316#comment:14">https://fedorahosted.org/pki/ticket/1316#comment:14</a> 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: </pre> <blockquote type="cite"> <pre wrap="">On Mon, Mar 07, 2016 at 07:33:52AM +0100, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, On 29.2.2016 07:59, Fraser Tweedale wrote: </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance">http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance</a> 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. </pre> </blockquote> <pre wrap="">1) Do wildcard certificates need special handling? There is no mention of them in the design doc. </pre> </blockquote> <pre wrap="">No special handling of wildcard certs is needed but I've added some commentary to the design page. </pre> <blockquote type="cite"> <pre wrap="">2) Should we accept invalid CSR where CN length is greater than 64? I wouldn't be surprised if these existed in the wild. </pre> </blockquote> <pre wrap="">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 :) </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a> </pre> </blockquote> <pre wrap=""> -- Manage your subscription for the Freeipa-devel mailing list: <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a> Contribute to FreeIPA: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/Contribute/Code">http://www.freeipa.org/page/Contribute/Code</a> </pre> </blockquote> </blockquote> </body> </html>