On 18/01/17 15:31, Kurt Roeckx wrote:
> And I would like to see that as a requirement in the audit report,
> which CA are actually checked.
https://github.com/mozilla/pkipolicy/issues/50 .
Gerv
___
dev-security-policy mailing list
On 18/01/2017 16:20, Gervase Markham wrote:
On 17/01/17 23:27, Jakob Bohm wrote:
Notes on the text in that branched section (other than the actual
change discussed here):
This paranthesis indicates none of these are in scope for this
particular issue, just something that might be their own
On Wed, Jan 18, 2017 at 07:23:35AM -0800, Peter Bowen wrote:
>
> > On Jan 18, 2017, at 7:18 AM, Gervase Markham wrote:
> >
> > On 17/01/17 23:33, Jakob Bohm wrote:
> >> How about "_and versions and strong (>= 256 bits) hashes_",
> >
> > Do people think we need to go this far?
> On Jan 18, 2017, at 7:18 AM, Gervase Markham wrote:
>
> On 17/01/17 23:33, Jakob Bohm wrote:
>> How about "_and versions and strong (>= 256 bits) hashes_",
>
> Do people think we need to go this far?
>
> If we do, we'll need them to specify filenames, not just document
>
On 17/01/17 23:27, Jakob Bohm wrote:
> Notes on the text in that branched section (other than the actual
> change discussed here):
>
> - It does not include some other changes under discussion (such as the
> new version of the BRs). This may need to be manually reapplied after
> merging in the
On 17/01/17 23:33, Jakob Bohm wrote:
> How about "_and versions and strong (>= 256 bits) hashes_",
Do people think we need to go this far?
If we do, we'll need them to specify filenames, not just document
titles. Otherwise, one wouldn't know if the hash was a .doc, a .pdf, or
what.
Gerv
On 18/01/2017 01:12, Nick Lamb wrote:
On Tuesday, 17 January 2017 23:34:20 UTC, Jakob Bohm wrote:
How about "_and versions and strong (>= 256 bits) hashes_",
Frankly any _cryptographic_ hash should be adequate for this purpose. Even for
the most creaky crypto hashes I can think of (e.g.
On Tuesday, 17 January 2017 23:34:20 UTC, Jakob Bohm wrote:
> How about "_and versions and strong (>= 256 bits) hashes_",
Frankly any _cryptographic_ hash should be adequate for this purpose. Even for
the most creaky crypto hashes I can think of (e.g. MD4) pre-image attacks are
theoretical
On 16/01/2017 12:31, Gervase Markham wrote:
On 13/01/17 02:00, Ryan Sleevi wrote:
Suggestion: "List of CA policy documents _and versions_"
Yes, good idea.
Gerv
How about "_and versions and strong (>= 256 bits) hashes_",
given recent confusion about CP/CPS translation change procedures at
On 12/01/2017 18:12, Gervase Markham wrote:
The current CA policy does not specify when audit reports are due to
Mozilla relative to the end date of the audit period. It only says that
CAs much provide the reports to Mozilla within 30 days of receiving the
report from their auditor.
Peter Bowen
On 13/01/17 02:00, Ryan Sleevi wrote:
> Suggestion: "List of CA policy documents _and versions_"
Yes, good idea.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Suggestion: "List of CA policy documents _and versions_"
Having seen audits that simply say "CPS at [URL]" leaves it ambiguous
as to which version was audited. It also raises concerns of a CA
forgetting to update their public CP/CPS with whatever the auditor
examined.
On Thu, Jan 12, 2017 at
The current CA policy does not specify when audit reports are due to
Mozilla relative to the end date of the audit period. It only says that
CAs much provide the reports to Mozilla within 30 days of receiving the
report from their auditor.
Peter Bowen proposed some revised and more specific
13 matches
Mail list logo