Thank you for the continued updates, and for relaying the deadline by which
these will be revoked.
On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> >
On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > > > On Aug 17, 2017, at 14:24, identrust--- via
On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 31/08/2017 22:26, Ryan Sleevi wrote:
>
>> Agreed. But in general, in order to maintain interoperability, there's a
>> process for building consensus, and repurposing extensions
On 31/08/2017 22:26, Ryan Sleevi wrote:
On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am aware that this was the original specification. However like many
other parts of PKIX it may not be as good in 20/20 hindsight.
On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am aware that this was the original specification. However like many
> other parts of PKIX it may not be as good in 20/20 hindsight.
Agreed. But in general, in order to
On 31/08/2017 21:49, Ryan Sleevi wrote:
On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Would it be beneficial to Mozilla in particular and the larger PKI
community in general if the following was added to implementations:
On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Would it be beneficial to Mozilla in particular and the larger PKI
> community in general if the following was added to implementations:
>
Hi Jakob,
This was rather extensively
Kurt, I think both the past experiences of m.d.s.policy with incidents that
went undetected by auditors, and my own personal experience (not as part of the
Web PKI) with professional audit firms is that they're not strong on the sort
of technical requirements that we've seen here.
If the rule
El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer escribió:
> Hi David,
>
> If you use the cert at https://crt.sh/?id=1616324 as issuer (the root
> itself) and run this command:
>
> openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101
> -url
Over the past many months, a few situations have arisen where SubCAs
intended to be constrained were not constrained according to the rules,
because they lacked "exclude all" name constraints for name types they
were not supposed to issue at all.
Would it be beneficial to Mozilla in particular
On 2017-08-29 14:47, Paul Kehrer wrote:
I've recently completed a scan of OCSP responders with a focus on checking
whether they are compliant with BR section 4.9.10's requirement: "Effective
1 August 2013, OCSP responders for CAs which are not Technically
Constrained in line with Section 7.1.5
On 31/08/2017 07:24, Peter Miškovič wrote:
Hi Paul,
we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed
it yesterday afternoon.
Problem with OCSP response for RootCA will be fixed to the end of next week.
They are offline and there is no real possibility to issue a
I have updated the list below to try to capture all the information
provided in this thread about which responders have been fixed (and
verified using another random serial number), which ones have a date, and
removed the ones that are actually under technical constraint that I missed.
I have
13 matches
Mail list logo
