On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy
wrote:
As follow up to Dimitris comments I tested the scenario where a
sibling issuing CA [ICA 2] with the OCSP signing EKU (but without
digitalSignature KU) under [ROOT] would sign a revoked OCSP response for
[ICA] also
>
> Some tests were performed by Paul van Brouwershaven
> > https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d.
>
> As mentioned, those tests weren’t correct. I’ve provided sample test cases
> to several other browser vendors, and heard back or demonstrated that
> they’re
On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote:
I can understand wanting to wait to see what others do first, but
that’s not leadership.
This is a security community, and it is expected to see and learn from
others, which is equally good of proposing new things. I'm not sure what
you mean by
On 6/7/2020 11:03 π.μ., Ryan Sleevi via dev-security-policy wrote:
Yep. You have dismissed it but others may have not. If no other voices are
raised, then your argument prevails:)
I mean, it’s not a popularity contest:)
As others have highlighted already, there are times where people get
On Mon, Jul 6, 2020 at 1:12 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
> Ryan's response on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1649939#c8 seems
> unreasonably harsh (too much "bad faith" in affected CAs, even of these
> CA Certificates were operated by the Root
On Mon, Jul 6, 2020 at 3:38 AM Dimitris Zacharopoulos
wrote:
> On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote:
>
> I can understand wanting to wait to see what others do first, but that’s
> not leadership.
>
>
> This is a security community, and it is expected to see and learn from
> others, which is
Hi All,
How will internal CA's be affected.
If I issue or have issued 2 years certificates, how will the browsers treat
these certificates ?
Just after guidance ..
M
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Summary of some OCSP client tests:
- `Root` is self signed, and does not have any EKU's
- 'ICA' is signed by 'Root' with the EKU ServerAuth and ClientAuth
- 'ICA 2' is signed by 'Root' with the EKU ServerAuth, ClientAuth and
OCSPSigning
- 'Server certificate' is signed by `ICA`
On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote:
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via
dev-security-policy wrote:
> Hi,
>
> As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY
> include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which
> must then contain:
>
> > HTTP URL for the Subordinate CA's
Hi,
As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY
include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which
must then contain:
> HTTP URL for the Subordinate CA's Certification Practice Statement, Relying
> Party Agreement or other pointer to online information
On Mon, 6 Jul 2020 at 19:30, Ryan Sleevi wrote:
>
> On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy
> wrote:
>>
>> ...
>>
>> 1.) What was the reasoning behind not (also / specifically) allowing
>> an HTTPS url? Was there specific reasoning reasoning?
>
>
> Nope, no
On Mon, 6 Jul 2020 19:22:22 +0200
Matthias van de Meent via dev-security-policy
wrote:
> I notice that a lot of Subscriber Certificates contain https-based
> URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other
> http-based urls redirect directly to an https-based website (e.g.
>
14 matches
Mail list logo
