On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The practice of revoking non-issued certificates would therefore lead to
> CRL growth which would further make reliable revocation checking on
> bandwidth constrained clients more
> The CRL question is not about it being a requirement, but rather the fact
> that it could / would lead to disparate treatment between CRL and OCSP for
> the same certificate, which does not feel right.
The CRL would only grow if the (pre-cert || cert) needed to be revoke for any
reason. CRLs on
The CRL question is not about it being a requirement, but rather the fact
that it could / would lead to disparate treatment between CRL and OCSP for
the same certificate, which does not feel right.
On the CT quorum issue, we use a mix of the most available sharded logs and
that is the failure rate
On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy
wrote:
>
> 1. The new text added to the Mozilla Recommended and Required Practices for
> this topic states only OCSP status is required for precertificates. Many CAs
> provide both CRLs and OCSP services and it would
The last thing we intended was for our prior mail to be interpreted as negative
and without substance. That said, it is clear our mail was not received in the
light in which it was intended.
We would like to rectify that. We have been closely monitoring this thread and
as it began to converge
On 2019-09-23 5:00 μ.μ., Ryan Sleevi via dev-security-policy wrote:
No. That’s the more dangerous approach which I’ve tried repeatedly to
dissuade. You should produce, and distribute, the Good response with the
pre-certificate.
Understood. Thank you for the clear guidance.
Dimitris.
Heh--my bad, I read that as "cabforum.org". I'll correct it there as well, but
Kathleen or Wayne would have to handle the CCADB pages, methinks.
Kathleen/Wayne: I did get confirmation from Mike at Microsoft that those are
the correct URLs for their sites. :)
--
Jos Purvis (jopur...@cisco.com
On Mon, Sep 23, 2019 at 8:50 AM Dimitris Zacharopoulos
wrote:
>
>
> On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
>
> It would be useful to identify whether there’s an objective to the
> questions, since that might help us cut down things quicker:
> - Are you running a 5019 responder or a 6960 resp
Thanks for pointing that out! I'll confirm those quickly with Microsoft and
then fix up the links.
Cheers,
Jos
--
Jos Purvis (jopur...@cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 |
On 9/22/19, 11:16 PM, "dev-security-policy on behalf of Mathew H
On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos
mailto:ji...@it.auth.gr>> wrote:
[...]
Doesn't this break compatibility with older clients? It is older
clients
that need to see "revoked" which is equivalent to "not good"
On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos
wrote:
>
>
> On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
> > dev-security-policy wrote:
> >
> >> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> >>> On Fr
On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:
On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
mailto:ji...@it.auth.gr>> wrote:
On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> > On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
> > mailto:ji...@it.auth.gr>> wrote:
> >
> >
> >
> > Using the following practice as described i
On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
mailto:ji...@it.auth.gr>> wrote:
Using the following practice as described in RFC 6960 should not
be a violation of the BRs. That is, answering revoked where a
pre-certificate h
14 matches
Mail list logo