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-de...@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

-- 
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

Reply via email to