Thanks for reporting this, David.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1522975 to track
both discussion and remediation.
It would be useful if you can add to the timeline both the changes you've
made in response and when you anticipate the remaining remediation steps to
be
Summary
During a signing ceremony in October 2018, Google Trust Services generated OCSP
responses for five of its subordinate CAs and published them afterwards. On 11
January 2019 it was discovered that one of these responses was not created
accurately.
The incorrect OCSP response did not have
On 25/01/2019 19:23, Buschart, Rufus wrote:
Hello Jakob!
-Ursprüngliche Nachricht-
Von: dev-security-policy Im
Auftrag von Jakob Bohm via dev-security-policy
Gesendet: Freitag, 25. Januar 2019 18:47
Example, if the subscriber fills out the human readable order form like
this:
On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus
wrote:
> > Von: Ryan Sleevi
> >
> > The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>
> Sorry to be picky, but this check only proofs that a label is a valid IDNA
> label but not that it is _not_ a weird server name.
>
Picky is
On Fri, Jan 25, 2019 at 10:40 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I mean, it's using an ACE label. That's where Ballot 202 would have
> clarified and required more explicit validation of the ACE labels to
> address the SHOULD NOT from
> Von: Ryan Sleevi
>
> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
Sorry to be picky, but this check only proofs that a label is a valid IDNA
label but not that it is _not_ a weird server name.
With best regards,
Rufus Buschart
On Fri, Jan 25, 2019 at 1:24 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If a CA receives such a list and creates the CSR for the customer (how
> does the CA this without access to the customers private key?), they have
> of course to perform an
Hello Jakob!
> -Ursprüngliche Nachricht-
> Von: dev-security-policy Im
> Auftrag von Jakob Bohm via dev-security-policy
> Gesendet: Freitag, 25. Januar 2019 18:47
>
> Example, if the subscriber fills out the human readable order form like
> this:
>www.example.com
>
On 25/01/2019 16:06, Tim Hollebeek wrote:
>
>> On 2019-01-24 20:19, Tim Hollebeek wrote:
>>> I think the assertion that the commonName has anything to do with what
>>> the user would type and expect to see is unsupported by any of the
>>> relevant standards, and as Rob noted, having it be
在 2019年1月25日星期五 UTC+8上午3:19:42，Tim Hollebeek写道：
> I think the assertion that the commonName has anything to do with what the
> user would type and expect to see is unsupported by any of the relevant
> standards, and as Rob noted, having it be different from the SAN strings is
> not in compliance
> On 2019-01-24 20:19, Tim Hollebeek wrote:
> > I think the assertion that the commonName has anything to do with what
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in
On Thu, 24 Jan 2019 10:04:00 +0100
Kurt Roeckx via dev-security-policy
wrote:
> Will you fill something in in the commonName? I think what is
> expected in the commonName is what the user would type and expect to
> see, I don't think the commonName should contain
> xn--gau-7ka.siemens.de. If you
On 2019-01-24 20:19, Tim Hollebeek wrote:
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the
13 matches
Mail list logo
