On 23/3/2018 9:44 μμ, Wayne Thayer via dev-security-policy wrote:
> Therefore, the only action I plan to take on this is
> to ask the WebTrust Task Force for their opinion on "wind-down" audits, and
> also to ask them if it is possible for a CA to obtain a period-of-time
> audit for a hierarchy
Given that TURKTRUST has stated that the "TÜRKTRUST Elektronik Sertifika
Hizmet Sağlayıcısı H5" root is no longer being audited or complying with
new policies, I believe there is consensus that it should be removed from
the Mozilla root store. Kathleen will file a bug for that action.
Ryan
On 20/03/2018 20:55, Tim Hollebeek wrote:
The BRs already cover this. The point is that once a CA stops
auditing, there's an issue about ensuring conformance.
Actually, they don't. They have an empty placeholder section for wind down
procedures. Surely one could blindly apply the full BRs
On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I think it's not going to be productive to spend a lot of time on the list
> debating whether or not a CA can opt out of full BR compliance by simply
> saying "we're winding
On Tue, Mar 20, 2018 at 3:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 20/03/2018 18:49, Ryan Sleevi wrote:
>
>> On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Are
On 20/03/2018 18:49, Ryan Sleevi wrote:
On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Are you suggesting that the BRs be modified so a CA that has ceased
issuance can obtain a clean audit report without meeting all current
On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Are you suggesting that the BRs be modified so a CA that has ceased
>> issuance can obtain a clean audit report without meeting all current BR
>> requirements?
>>
>>
> I am
On 20/03/2018 17:39, Wayne Thayer wrote:
Jakob,
On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 17/03/2018 01:23, Wayne Thayer wrote:
Note, that if it is reasonably certain/validated that the only activity
is maintaining
Jakob,
On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 17/03/2018 01:23, Wayne Thayer wrote:
>
> Note, that if it is reasonably certain/validated that the only activity
> is maintaining CRLs/OCSP for the remaining unexpired
On 17/03/2018 01:23, Wayne Thayer wrote:
TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity
Unsurpisingly, I agree with this proposed course of action, and would go
further to suggest utilizing OneCRL to ensure the prompt and widespread
removal of trust, in addition to removing from NSS.
On Sat, Mar 17, 2018 at 2:26 AM Eric Mill via dev-security-policy <
In TurkTrust's 2016 email noting that they were suspending their TLS
certificate business, they noted it stemmed mainly from not being accepted
to all major root stores (Apple did not accept them).
Therefore, the sites using these certificates are not trusted by some major
client bases, which is
TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity certificates signed by this root [2]. The
13 matches
Mail list logo
