On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote:
> Hi Rick,
>
> I don't see a "May 4th post". Where was it posted? Not here it seems.
It's above--it links to
https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
>
> Also it's reasonable that
In addition to requesting disclosure of intermediates that have been (even if
not currently are) able to issue server certs, and the catchall, both of which
seem excellent, I encourage Mozilla to consider asking these questions as part
of an implemented remedy plan.
That is, put in motion
On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote:
> I think it might be appropriate to have a further round of questions to
> Symantec from Mozilla, to try and get some clarity on some outstanding
> and concerning issues. Here are some _proposed_ questions; feel free to
> suggest
Hi Gerv,
I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs
based on the discussion we started last month. I understand the BR requirement
if the CA can issue server auth certificates, this was discussed here:
It may be necessary to expand that definition to intermediates that were
capable of issuing certificates within the past year (or longer).
On Monday, May 8, 2017 at 9:31:21 AM UTC-4, Alex Gaynor wrote:
> I'm not the best way to phrase this, so please forgive the bluntness, but I
> think it'd be
Thanks Kurt.
Alex
On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2017-05-08 15:31, Alex Gaynor wrote:
>
>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> I
>> think it'd be appropriate to
I'm not the best way to phrase this, so please forgive the bluntness, but I
think it'd be appropriate to ask at this point if Symantec has disclosed
all necessary intermediates (I believe this would be defined as: chain to
their roots in our trust store, are not expired, are not revoked, and are
Hi Rick,
Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?
If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
many of
It makes perfect sense if the game plan is to force continued delays of
decisions on the part of root programs! Which appears to be exactly what is
happening. After all, wait long enough, and it can be claimed that all possibly
bad things would be expired, so don't distrust us, m'ok.
I think
On 2017-05-08 14:24, Gervase Markham wrote:
1) Did any of the RAs in your program (CrossCert and co.) have the
technical ability to independently issue EV certificates? If they did
not not, given that they had issuance capability from intermediates
which chained up to EV-enabled roots, what
I think it might be appropriate to have a further round of questions to
Symantec from Mozilla, to try and get some clarity on some outstanding
and concerning issues. Here are some _proposed_ questions; feel free to
suggest modifications or other questions, and I will decide what to send
officially
Hi Rick,
I don't see a "May 4th post". Where was it posted? Not here it seems.
Also it's reasonable that Symantec wants to "address impact to their customers"
but what about impact to all of the browsers users? It may be a good idea to
try and address (in your proposals) that to.
So far I
On 8/5/2017 1:18 μμ, Gervase Markham wrote:
On 05/05/17 19:44, Dimitris Zacharopoulos wrote:
* MUST include an EKU that has the id-kp-emailProtection value AND
* MUST include a nameConstraints extension with
o a permittedSubtrees with
+ rfc822Name entries scoped in the
On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote:
One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?
Or put another way, would your proposed language force an organization
wanting to run
On 05/05/17 19:44, Dimitris Zacharopoulos wrote:
> * MUST include an EKU that has the id-kp-emailProtection value AND
> * MUST include a nameConstraints extension with
> o a permittedSubtrees with
> + rfc822Name entries scoped in the Domain (@example.com) or
>Domain
On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.
I believe this was made the case for some mix of the following reasons:
a) the CA did not want to reveal every customer it had;
b) this
On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
Is that what you meant, Peter?
You cannot set up a CNAME without configuring Salesforce, since they
would not
17 matches
Mail list logo
