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.
>
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, 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
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
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
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 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
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
>
> 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 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
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 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
14 matches
Mail list logo