Thanks for sharing this Jeremy. I'm still reading through it myself but one
thing that jumps out at me is the implicit(?) allowing for the same key to be
used for SSL and code signing.
From a security standpoint that's a horrible idea. I'll elaborate if desired,
but I first wanted to find out
Good point. I don't think we spell it out, but I don't think anyone wants
people using the same keys for both SSL and code signing. CAs are prohibited
from using the same intermediate for both SSL and code signing, but we should
also add something that requires the Subscriber to use separate
On Fri, August 29, 2014 8:04 am, Jeremy Rowley wrote:
Good point. I don't think we spell it out, but I don't think anyone wants
people using the same keys for both SSL and code signing. CAs are
prohibited from using the same intermediate for both SSL and code signing,
but we should also
Agreed. Enforcing a rule like this would be limited, so here's what I'm hoping
to see:
1) Strong, clear, unambiguous wording in the specs so that we can take away the
I didn't know argument. Nobody should ever think it's okay to use the same
key in multiple ways.
2) Policies and checks put in
On 8/28/14, 8:01 PM, Eric Mill wrote:
I hadn't caught the wiki update -- that's terrific! Thanks for pointing it
out.
I had planned to say something about the change in the wiki page in this
discussion forum, but just hadn't gotten around to it yet. So, I
appreciated the reminder.
I can
Right - about the only thing the guidelines can do is require that CAs include
it as a contractual representation in their subscriber agreement, which is what
I was thinking of doing. There isn't a way to monitor whether key was used for
multiple purposes.
Fun note - one version of the draft
6 matches
Mail list logo
