On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote:
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.
The impression you were under is correct.
Any intermediate that is EKU-constrained to not permit serverAuth, or
that permits serverAuth but is appropriately name-constrained, is
considered to be "Technically Constrained" and is therefore not subject
to the current disclosure requirement.
And it seem that only an EKU is needed with the current policy for email
and code signing to be considered constrained.
Correct.
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
Correct.
See also https://github.com/mozilla/pkipolicy/issues/73, which proposes
that even Technically Constrained intermediates should fall under the
disclosure requirement.
I guess with code signing we have the situation that Mozilla doesn't
care about it, but requires you to disclose them anyway.
Where does it say that code signing intermediates need to be disclosed?
That's not my understanding of section 5.3.1 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
