On Mon, Mar 14, 2016 at 09:29:37AM -0700, Christina Fu wrote: > > > On 03/12/2016 11:51 PM, Fraser Tweedale wrote: > >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? > 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 > (|SubjectAltNameCopyCNDefault|) 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 > Understood; thanks. I'll file a ticket for the Dogtag profile change.
> > > >>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 > >>>[email protected] > >>>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 > _______________________________________________ Pki-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/pki-devel
