Inline... Sent from my iPhone
> On 2 Apr 2015, at 17:35, Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > >> On Thu, Apr 2, 2015 at 11:05 AM, Kurt Roeckx <k...@roeckx.be> wrote: >>> On 2015-04-02 16:34, Phillip Hallam-Baker wrote: >>> >>> Further no private key should ever be in a network accessible device >>> unless the following apply: >>> >>> 1) There is a path length constraint that limits issue to EE certs. >>> 2) It is an end entity certificate. >> >> Why 1)? > > Can you state a use case that requires online issue of Key Signing Certs? Yes, we have one customer that has a client authentication requirement and they need DR processes with an ability to re-issue from their P/L 1, EKU and Name constrained CA within 12-24 hours. We offer good levels of service but this isn't possible for our offline ceremony processes. Creation of additional backup CA's was suggested, however this was not deemed suitable. We also have another customer that again issues from a P/L 1 Name and EKU constrained CA on a regular basis across multiple issuing CA's to support their captive portal lifecycle system and keep keys constantly cycling. These are the only two that need P/L 1 and we assessed that the Name and EKU constraints in the primary issuing CA are sufficient to protect the rest of the chain. FYI the 2nd customer has been operational with this business model for 5 plus years, the last 2 with constraints. I would not back the mandating of P/L =0 but would happily support it as best practice. Steve > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
