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