Thanks to Kathleen for suggesting/requesting this new crt.sh feature...
To facilitate compliance checking for the 3 test websites that BR 2.2
[1] requires for each root certificate, I've created this new report:
https://crt.sh/test-websites
Anything in red on this page represents either: a
Hi Rufus. I'm not aware of any root program or CABForum requirement
that supports your interpretation.
On 13/12/2018 12:26, Rufus Buschart wrote:
> Very nice! Are you sure, that this requirement is only valid for "Root
> CAs"? I was always under the impression, that such a test web site needs
On Wednesday, December 12, 2018 at 7:59:46 PM UTC-5, Jeremy Rowley wrote:
> Some systems look like they verify the email address/domain name at issuance
> and then never again for the same account. Other systems verify the email
> address and domain every 825 days. The last set verifies the email
2018. december 13., csütörtök 7:35:32 UTC+1 időpontban Dean Coclin a következőt
írta:
> My opinion:
> The CA/B Forum Baseline Requirements only apply to certificates which chain
> to publicly trusted roots. This is made clear in the preamble of the
> document:
>
> This document describes an
We do re-verify on every re-issuance and do not re-use verification
information. But we are probably not the most typical example, as all our
verification information are coming from HR systems.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Human Resources
PKI /
To expand: You would like to request removal and then it be treated as if
you’re already removed, correct?
I think for the reasons Wayne outlined, that would be detrimental to the
ecosystem as a whole. For example, the request for removal might actually
be denied (!!!) because of the outsize
On Sat, Dec 8, 2018 at 12:50 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> thanks for the suggestions.
>
> We are exploring the OCSP and CRL checks. It has potential.
>
> Have you determined if these applications perform revocations checks, or
if
Can we request removal of these roots now? This seems very similar to the
SHA1 situation where CAs requested root removal and then treated the root as
private, regardless of the trust in older platforms.
-Original Message-
From: dev-security-policy On
Behalf Of Wayne Thayer via
There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for
My main concern with this request is the misissued certificates identified
by linters that have not been revoked - I have included my comments and
links from the original message below.
It appears that DigiCert is not planning to remediate these certificates -
can a representative from DigiCert
(Same Pedro as before...it was another account)
>
> There's nothing that specifies the cert must be issued after the verifying
> control or that issuance can't be part of the verification process. Although
> this seems backwards, I still think it's compliant with the Mozilla policy.
>
Well..
This is one of the reasons I wanted to raise the issue. Issuing the cert and
delivering to the email seems like a pretty common way to verify email certs
(either you have access to the email or you don't), but this is backwards
from TLS. Is this particular process a violation of the Mozilla
I also don't think removing these roots is a good solution because:
* To Ryan's point, it's too late to actually get them removed on Mozilla's
current release cycle.
* Again echoing Ryan's comments, there are a lot of consumers of NSS and
abruptly yanking these roots to work around the ballot
Maybe we should set clear grounds on what is verified and how, not only in the
frequency.
For S/MIME capability itself, we are required to ensure that "the entity
submitting the request controls the email account associated with the email
address referenced in the certificate", so by merely
* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3],
most of which are not revoked.
- We can revoke these. I have no issue remediating them. I didn’t realize
these were an ongoing concern.
* DigiCert’s response in this bug states “We were under the impression
On Thu, Dec 13, 2018 at 10:53 AM pedro.wisekey--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Maybe we should set clear grounds on what is verified and how, not only in
> the frequency.
>
> I agree and think that creating piecemeal requirements is a bad idea. The
CAB
16 matches
Mail list logo
