On 2017-05-17 14:40, Rob Stradling wrote:
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV reports that Mozilla
publishes.
Rob: do you think you could enhance
https://crt.sh/mozilla-disclosures#undisclosed to give the number of
days a certificate has been on the list?
Rob,
Hi Kurt.
Could you also split the "Technically Constrained", into those that
are really technically constrained, and those that are out of scope
for the CCADB?
What's your definition of "really technically constrained"?
For instance https://crt.sh/?id=12729339 is out of scope because it's
code signing. https://crt.sh/?id=8951039 because it's client / email.
They're out of scope because they're Technically Constrained in
accordance with Section 5.3.1 of the Mozilla Root Store Policy v2.4.1 [1]
Or maybe it just needs to be renamed?
I'm really not sure what "it" you'd like to see categorized differently.
I seem to have been confused. For some reason I was under the impression
that only those that can be used for server auth were required to be
disclosed when I was reading it last week. It didn't really make sense
to me at the time, and now I can't find anything that suggests that.
And it seem that only an EKU is needed with the current policy for email
and code signing to be considered constrained. But you could argue that
for email you can't say for sure that it's constrained or not, which I
guess is why we have https://github.com/mozilla/pkipolicy/issues/69
I guess with code signing we have the situation that Mozilla doesn't
care about it, but requires you to disclose them anyway.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
