On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > I think this bears expansion because I don't think it's been clearly
> > documented what flow you believe is currently permitted today that will
> be
> > prevented tomorrow
> I must admit, I'm confused. Based on your concerns as I understand them,
> either the scenario you're describing is already prohibited today (and thus
> no change from existing policy), or its already permitted today and would
> continue to be permitted with this change. I'm hoping you can
On Wed, May 15, 2019 at 11:52 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I believe the case where Google requests a certificate from the CA is
> accommodated but not the case where SAAS requests a certificate from the CA
> based on the authentication
On Wednesday, May 15, 2019 at 10:36:00 AM UTC-7, Ryan Sleevi wrote:
> On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy <
\> > Specifically where Wayne suggested:
> > "CAs MUST NOT delegate validation of the domain name part of an email
> > address to a 3rd party."
> >
> > Are you
On Wed, May 15, 2019 at 9:28 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Pedro,
>
> That scenario is addressed by Wayne proposed change.
>
> That same change does not allow for applications that use GMail or there
> federated authentication providers to
> I think this bears expansion because I don't think it's been clearly
> documented what flow you believe is currently permitted today that will be
> prevented tomorrow with this change.
To be clear, In that statement was referring to that scenario being allowed
under the proposed change
Thank you for sharing this information Scott.
On Wed, May 15, 2019 at 2:49 AM Scott Rea wrote:
>
> Please advise if additional information relating to this change is
> required.
>
>
As pointed out in earlier discussions about DarkMatter's QuoVadis-signed
intermediates [1], and the policy 2.7
On Wed, May 15, 2019 at 2:10 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Thanks. I think this is desirable to forbid, as it is insecure, and I
> > believe it's already forbidden, because the process of step (4) is
> relying
> > on GMAIL to act as a
I have the feeling that this going to something over-complicated...
Let's think in a simple case, which is, I think, the most common scenario where
there's some delegation:
1. A company needs MPKI service for its employees, who use email addresses in
one or more domains owned by the company
2.
G’day Folks,
As previously discussed on this thread, the DarkMatter Trust Services practice
(including DarkMatter CAs) has been operated in a separate entity to the DM
Group, that entity is Digital Trust – Sole Proprietorship L.L.C.
(“DigitalTrust”) which was established in the United Arab
Pedro,
That scenario is addressed by Wayne proposed change.
That same change does not allow for applications that use GMail or there
federated authentication providers to use client certificates without sending
each user to the CA.
Ryan
___
11 matches
Mail list logo
