Yeah, I agree I don’t think it was intended. But now that I am aware of the
issue, I think the crossing workaround per EKU is actually a good thing for
people to be doing. Unless someone can point out why it's bad ...
Might want to give people a little more time to plan and adapt to that
On Sat, Jul 14, 2018 at 2:16 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Dear Wayne,
> >
> >Those programs for checking
On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear Wayne,
>
>Those programs for checking field of ToBeSign SSL certificate are
> online on June 22.
>
>We suggest that CA "in principle" must comply with the string
Agreed that old cross-certificates will not be impacted, but this does impact
new cross-certificates. I assume the work around would be to just issue more
than one cross-certificate with different EKUs, but I don't assume that was
intended by this policy change.
Bruce.
On Friday, July 13,
Doesn't the "created after January 1, 2019" mean that there is no problem with
old crosses? It would just be a new policy for new crosses as of next year?
-Tim
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
>
On 2018-07-13 12:02, lcchen.ci...@gmail.com wrote:
We suggest that CA "in principle" must comply with the string length limit
of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a
certificate. But if it is necessary after verification to express an organization’s
Dear Wayne,
Those programs for checking field of ToBeSign SSL certificate are online on
June 22.
We suggest that CA "in principle" must comply with the string length limit
of RFC 5280 for organizationalUnitName or organizationName filed in Subject of
a certificate. But if it is
7 matches
Mail list logo
