Re: New Blog Post on 398-Day Certificate Lifetimes

[Christian Felsing via dev-security-policy]

Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:

https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/


Hi,

blog post should clarify if this is valid for certificates issued by 
preinstalled root CAs only or also for CAs installed by user.



regards
Christian
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Chema Lopez via dev-security-policy]

>From my point of view, the arguments at
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13642.html
are
as incontestable as the ones stated by Corey Bonnell here:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13541.html
.


RFC5280 and RFC6960 have to be considered and thus, a certificate without
KU digitalSignature is not an OCSP Responder. We can not choose what to
comply with or what is mandatory or if a RFC is mandatory but BR "profiles"
the RFC. And when I say "we" I mean all the players, especially the ones in
the CA / Browser forum.


And yes, relying parties need to check this. For its own benefit, relying
parties need to understand how a proper OCSP response is made and check it
properly.


It is astonishing how what looks like a bad practice of (some) relying
parties has mutated into a security risk at CAs side.


It is not only a matter of CA's leading the solution of a, at least
questionable security risk. It is a matter of working all together.


It is not a secret that CA /B Forum is not living its better moments, in
part, due to unilateral decisions of (again, some) browsers against the
democratic (in terms of CA/B Forum bylaws) decision of a ballot.


It is time to collaborate again between CAs and Browsers instead of the
latelly usual (some) Browsers slapping CAs. For transparency sake, I think
that it would be a nice initiative from Browsers to disclose their
practices regarding the validation of OCSP Responses and working all
together, improve or even design practices on this to be followed,
although following RFC 5280 and RFC 6960 should be sufficient.


Thanks,

Chema.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 398 Cert Life span 1Sep2020

[marc reynolds via dev-security-policy]

Really appreciate advise and inputs Mark , thank you …

Does beg the question will they change the browser checks and how would we know

M

From: Mark Goodwin 
Date: Tuesday, 7 July 2020 at 14:54
To: "marc.rn...@gmail.com" 
Cc: "mozilla-dev-security-pol...@lists.mozilla.org" 

Subject: Re: 398 Cert Life span 1Sep2020

Hi,

I can't answer for any of the vendors but I've read around this a bit; perhaps 
the following will be of some use:

The Apple announcement states that the change affects "only TLS server 
certificates issued from the Root CAs preinstalled with iOS" - therefore, I 
think it's safe to assume locally added roots (from Internal CAs) will be 
unaffected.

The Chromium change also appears to only apply to certs from known roots ( 
https://source.chromium.org/chromium/chromium/src/+/master:net/cert/cert_verify_proc.cc;l=682?q=HasTooLongValidity&ss=chromium
 ) so Chrome, Edge and other Chromium based browsers look to be the same story.

Kind regards,

Mark


On Mon, 6 Jul 2020 at 15:07, marc.rnlds--- via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
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
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Nicholas Knight via dev-security-policy]

It seems exceptionally strange to me that what, from all appearances, is a 4 
year old advocacy body for auditors could be considered an authoritative 
source. ACAB’c does not seem to have done anything at all to acquire the 
extremely high level of credibility such a source needs.

The idea that an association of auditors can’t keep its website and charter up 
to date does nothing to dispel doubt, and is in fact evidence that ACAB’c is 
not capable of its claimed functions.

I see no browsers or anyone else can rely on ACAB’c, or should. It was not 
formed for that purpose and there is no evidence it even understands that 
purpose. I suggest that if they intend to perform this function, it is 
necessary to start over with a new organization with a new charter and new 
leadership.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[clemens.wanko--- via dev-security-policy]

Hi Ryan,
thanks for your post. And certainly yes: it’s our first goal to serve the needs 
of our actual consumers. The browsers belong to those in the front row. We are 
aware of that as we are aware that there is space for improvement for the 
council.

With regard to your statement to our webpage and the EN 319403 in our 
documented rules, we are updating that, to be fully clear on entry conditions 
for our accredited CAB as well as for the requirements an guidelines we follow 
throughout our audit work. But just to be clear on that: all ACAB’c members 
were and will be checked to be accredited according ETSI EN 319403 as well.

What I like to encourage the browsers to do is, to keep on staying in touch 
with us and share your demands, concerns and ideas with us. We shall be more 
than happy to discuss those with you in order to strengthen the trust as you 
are saying it. Please feel free to use me personally as entry point in the 
meanwhile as we at ACAB’c are about to migrate our technical infrastructure to 
a new platform which may cause additional delays otherwise. I will share the 
communication we are having amongst the member CABs and come up with a response.

All the best 
Clemens @ the ACAB council
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy