On Monday, May 22, 2017 at 4:46:16 PM UTC, Gervase Markham wrote:
> On 21/05/17 19:37, userwithuid wrote:
> > With the new proposal, the "minimal disruption" solution for Firefox
> > will require keeping the legacy stuff around for another 3.5-4 years
> > and better solutions will now be a lot hard
On 23/05/17 04:18, Peter Kurrasch wrote:
> I think the term "industry best practices" is too nebulous. For
> example, if I patch some of my systems but not all of them I could
> still make a claim that I am following best practices even though my
> network has plenty of other holes in it.
I'm not
On 19/05/17 14:12, Gervase Markham wrote:
> Updated language:
>
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on rfc822Name, with at least one name in permittedSubtrees,
> each such name havi
On Mon, May 22, 2017 at 9:34 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I even concede that that alone does create a potential for compatibility
> issues should a need arise to make a global web pki-wide change to
> certificate issuance (say, for
On 22/05/2017 19:41, Matthew Hardeman wrote:
On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote:
So your proposal is that technical requirements should be enforced
in-product rather than in-policy, and so effectively there's no need for
policy for the EE certs under a TCSC.
Th
Hi Doug,
On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints. Do
> these need to be audited?
>
> I'm looking at this:
> https://github.com/mozilla/pkipolicy/blob/master/root
On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> * TCSCs can, by their existing definition, be programmatically
> recognized by certificate validation code e.g. in browsers and other
> clients.
>
In theory, true.
In practice,
On 23/05/2017 16:22, Ryan Sleevi wrote:
On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
* TCSCs can, by their existing definition, be programmatically
recognized by certificate validation code e.g. in browsers and other
cli
On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Note as this is about a proposed future policy, this is about validation
> code updated if and when such a policy is enacted. Current validation
> code has no reason to check a
On Tuesday, May 23, 2017 at 10:53:03 AM UTC-5, Jakob Bohm wrote:
>
> Or could this be solved by require such "TCSC light" SubCA certs to
> carry a specific CAB/F policy OID with CT-based community enforcement
> that all SubCA certs with this policy OID comply with the more stringent
> non-computa
On 23/05/2017 18:18, Ryan Sleevi wrote:
On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Note as this is about a proposed future policy, this is about validation
code updated if and when such a policy is enacted. Current valid
On Tue, May 23, 2017 at 12:33 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I just think there's no need to concern themselves if someone quite clever
> (whatever that means) decides to ASN.1 encode a Trollface GIF and roll that
> into an EE cert su
On Sat, May 20, 2017 at 11:12 AM, Michael Casadevall via
dev-security-policy wrote:
> On 05/19/2017 05:43 PM, Kurt Roeckx wrote:
> >>From the mail about Chrome's plan, I understand that Chrome's plan
> > is to only allow certificates from the old PKI if they qualify for
> > their CT requirements.
On Mon, May 22, 2017 at 12:33 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 19/05/17 21:04, Kathleen Wilson wrote:
> > - I'm not sold on the idea of requiring Symantec to use third-party
> > CAs to perform validation/issuance on Symantec's behalf.
On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote:
> Setting aside even the 'damage' aspect, consider the ecosystem impact.
> Assume a wildwest - we would not have been able to effectively curtail and
> sunset SHA-1. We would not have been able to deploy and require Certificate
> Tr
On Tue, May 23, 2017 at 3:45 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote:
>
> > Setting aside even the 'damage' aspect, consider the ecosystem impact.
> > Assume a wildwest - we would
16 matches
Mail list logo