> On 15/12/17 16:02, Ryan Hurst wrote: > > So I have read this thread in its entirety now and I think it makes sense for it > to reset to first principles, specifically: > > > > What are the technological and business goals trying to be achieved, > > What are the requirements derived from those goals, What are the > > negative consequences of those goals. > > > > My feeling is there is simply an abstract desire to allow for the CA, on behalf > of the subject, to generate the keys but we have not sufficiently articulated a > business case for this. > > I think I'm in exactly this position also; thank you for articulating it. One might > also add: > > * What are the inevitable technical consequences of a scheme which meets > these goals? (E.g. "use of PKCS#12 for key transport" might be one answer to > that question.)
I actually agree with Ryan, too. I think it's more of an issue of what sort of future we want, and we have time. I'm actually far less interested in the PKCS#12 use case, and more interested with things like RFC 7030, which keep popping up in the IoT space. Also, in response to Ryan's other comments on PKCS#12, replacing it with something more modern for the use cases where it is currently common (e.g. client certificates, email certificates) would also be a huge improvement. -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
