TURKTRUST Non-compliance

[Wayne Thayer]

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
audits for this root are either already expired (based on audit date) or
nearly expired (based on the ETSI certificate expiration date) [3] [4].

TURKTRUST announced the suspension of their SSL business in 2016 [5].

TURKTRUST failed to respond to the January 2018 CA Communication. After
repeated attempts, they did respond to my emails and posted a statement in
the bug [6] including the following:

The strategic decision mentioned above is actually suspending all SSL
> business supporting activities that incur direct costs for TURKTRUST,
> including suspending the ETSI and BR audits or OV and EV SSL related
> insurance policies. We have also ceased our investment and studies on CT
> and CAA requirements for the time being that are actually mandatory
> criteria set by the CA/Browser Forum.
>

TURKTRUST has chosen not to request removal of the root, but I believe this
is a clear case in which prompt removal of the root is necessary.

I would appreciate everyone's constructive input on what action should be
taken.

- Wayne

[1] https://crt.sh/?Identity=%25&iCAID=5766&exclude=expired
[2] https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired
<https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired>
[3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
[4]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf
<https://cabforum.org/pipermail/public/2016-September/008475.html>
[5] https://cabforum.org/pipermail/public/2016-September/008475.html
<https://cabforum.org/pipermail/public/2016-September/008475.html>
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127

[Eric Mill]

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 likely why some of the few existing sites that have
TurkTrust certificates, such as http://www.enpos.com.tr and
http://www.turktrust.com.tr/tr/, do not redirect clients to HTTPS. This
lack of reliance on using the certificates for HTTPS reduces the impact to
Mozilla's users of suspending trust in the remaining certificates.

Even if this were not the case, I would agree and recommend prompt removal
of this explicitly unmaintained, unaudited hierarchy to protect Mozilla's
users. The above only makes it even more obviously the right decision.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Ryan Sleevi]

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.

[Jakob Bohm]

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 certificates signed by this root [2]. The
> audits for this root are either already expired (based on audit date) or
> nearly expired (based on the ETSI certificate expiration date) [3] [4].
>

Note that 3 of those certificates are CA operational certificates, such
as for the required test URLs. Thus only 10 true end certificates
remain, all of which will expire in less than 12 months (last two expire
2019-03-18).

> TURKTRUST announced the suspension of their SSL business in 2016 [5].
>
> TURKTRUST failed to respond to the January 2018 CA Communication. After
> repeated attempts, they did respond to my emails and posted a statement in
> the bug [6] including the following:
>
> The strategic decision mentioned above is actually suspending all SSL
>> business supporting activities that incur direct costs for TURKTRUST,
>> including suspending the ETSI and BR audits or OV and EV SSL related
>> insurance policies. We have also ceased our investment and studies on CT
>> and CAA requirements for the time being that are actually mandatory
>> criteria set by the CA/Browser Forum.
>>
>

Note, that if it is reasonably certain/validated that the only activity
is maintaining CRLs/OCSP for the remaining unexpired certificates, then
most of the updated BR requirements (such as CAA, CT and stricter
validation methods) become noops, since no validations are being done,
no CAA strings are accepted, no new certificates are issued etc.

We may thus be looking at the 12 months of an orderly shutdown of a
CA, as per section 5.8 of the standard CPS template, and might
reasonably consider accepting the lack of normal activity levels for
such a situation. The BRs and Mozilla policy seem silent on the
subject,

The only critical thing that seems to be missing is a BR audit report to
confirm that no issuance is taking place and the revocation management
and CA private key protection is still being done properly.

> TURKTRUST has chosen not to request removal of the root, but I believe this
> is a clear case in which prompt removal of the root is necessary.
>
> I would appreciate everyone's constructive input on what action should be
> taken.
>
> - Wayne
>
> [1] https://crt.sh/?Identity=%25&iCAID=5766&exclude=expired
> [2] https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired
> <https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired>
> [3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
> [4]
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf
> <https://cabforum.org/pipermail/public/2016-September/008475.html>
> [5] https://cabforum.org/pipermail/public/2016-September/008475.html
> <https://cabforum.org/pipermail/public/2016-September/008475.html>
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Wayne Thayer]

Jakob,

On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
dev-secur...@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 certificates, then
> most of the updated BR requirements (such as CAA, CT and stricter
> validation methods) become noops, since no validations are being done,
> no CAA strings are accepted, no new certificates are issued etc.
>

> I agree in practice, but if a WebTrust audit were to be conducted it would
contain a number of qualifications, or as is the case here, no ETSI audit
statement would be issued.

We may thus be looking at the 12 months of an orderly shutdown of a
> CA, as per section 5.8 of the standard CPS template, and might
> reasonably consider accepting the lack of normal activity levels for
> such a situation. The BRs and Mozilla policy seem silent on the
> subject,
>

> Are you suggesting that we delay removal of this root until all leaf
certificates expire?

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?

The only critical thing that seems to be missing is a BR audit report to
> confirm that no issuance is taking place and the revocation management
> and CA private key protection is still being done properly.
>

> Continued audit reports are indeed critical to maintaining trust in a CA
even after it has ceased issuance.

- Wayne

[Jakob Bohm]

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-secur...@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 certificates, then
>> most of the updated BR requirements (such as CAA, CT and stricter
>> validation methods) become noops, since no validations are being done,
>> no CAA strings are accepted, no new certificates are issued etc.
>>
>> I agree in practice, but if a WebTrust audit were to be conducted it would
> contain a number of qualifications, or as is the case here, no ETSI audit
> statement would be issued.
>
> We may thus be looking at the 12 months of an orderly shutdown of a
>> CA, as per section 5.8 of the standard CPS template, and might
>> reasonably consider accepting the lack of normal activity levels for
>> such a situation. The BRs and Mozilla policy seem silent on the
>> subject,
>>
>> Are you suggesting that we delay removal of this root until all leaf
> certificates expire?
>
> 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 suggesting that we consider what policy should be applied to the
(required!) capability of keeping revocation running for max cert
lifetime after a CA ceases to operate.

For starters, a wind-down CA will not issue any more certificates (and
should probably be audited to that fact), and will thus not be
meaningfully subject to the various requirements associated with that
activity (such as validation procedures, contents of newly issued
certificates etc.). This alone should significantly reduce the scope of
requirements and audits.

Secondly, a wind-down CA (as opposed to a wind-down root key from an
otherwise active CA) is likely to be operating from a prepaid
contingency fond, set up before the wind down based on the bare-bones
cost of safely doing the wind down procedures by a qualified but not
stellar skeleton crew. Thus maybe it shouldn't be required to engage
in time consuming administrative procedures such as responding to
quarterly Mozilla surveys or diligently watching m.d.s.p for new
requirements.

From the perspective of keeping Mozilla users safe, there are simply a
lot less that could go wrong, and a reasonable expectation that they can
still access servers that haven't yet switched to a new CA, because the
old cert is not expired and has working CRL and OCSP servers confirming
its validity.

So on a general basis, future BRs and/or Mozilla policy could have an
explicit list of things that are (or not) required during shutdown. For
example, there would still be a requirement to revoke at 24 hours notice
and to keep CRL and OCSP servers running in accordance with the policy
requirements at time of last external end entity issuance. There would
also be a requirement to state, in both CCADB and at their own website,
that the CA is winding down but will try to keep previously issued
certificates valid until <date>. They would be required to fix security
bugs in their still operational systems (such as OCSP responders and CRL
download web servers), but would not be required to implement new
security measures.

On a more practical basis, under current policy, I guess a BR audit
would contain a lot of trivial sections such as "validation: Not
applicable", "CPS updates: Not applicable", "sampling of issued
certificates: No certificates were issued in the audit period", etc.

Also, some ad hoc leniency may be used as a temporary substitute for a
formal policy.

> The only critical thing that seems to be missing is a BR audit report to
>> confirm that no issuance is taking place and the revocation management
>> and CA private key protection is still being done properly.
>>
>> Continued audit reports are indeed critical to maintaining trust in a CA
> even after it has ceased issuance.
>
> - Wayne
>

[Ryan Sleevi]

On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-secur...@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 suggesting that we consider what policy should be applied to the
> (required!) capability of keeping revocation running for max cert
> lifetime after a CA ceases to operate.
>

The BRs already cover this. The point is that once a CA stops auditing,
there's an issue about ensuring conformance.

> For starters, a wind-down CA will not issue any more certificates (and
> should probably be audited to that fact), and will thus not be
> meaningfully subject to the various requirements associated with that
> activity (such as validation procedures, contents of newly issued
> certificates etc.). This alone should significantly reduce the scope of
> requirements and audits.
>

I strongly disagree with this framing. The notion of a "wind-down CA" is
not a concept that is part of the PKI. It remains a functional CA, with the
full capability of issuance, and thus all appropriate policies, procedures,
and protections apply.

> Secondly, a wind-down CA (as opposed to a wind-down root key from an
> otherwise active CA) is likely to be operating from a prepaid
> contingency fond, set up before the wind down based on the bare-bones
> cost of safely doing the wind down procedures by a qualified but not
> stellar skeleton crew. Thus maybe it shouldn't be required to engage
> in time consuming administrative procedures such as responding to
> quarterly Mozilla surveys or diligently watching m.d.s.p for new
> requirements.
>

I strongly disagree with this. If we believe these services are meaningful
for Mozilla users, it's absolutely relevant. Consider that the proposal
here fails to consider OCSP nonces, for example, as a prime example of why
this suggestion is inherently and fundamentally flawed.

> From the perspective of keeping Mozilla users safe, there are simply a
> lot less that could go wrong,

This is not true.

> Also, some ad hoc leniency may be used as a temporary substitute for a
> formal policy.
>

I do not think these suggestions are good nor do they ensure the safety of
users, nor offer the reliability or assurance.

CAs can make contingency plans to deprecate in an orderly fashion without
any of the issues Jakob raises. The failure to do so, and the resulting
distrust, is wholly in line with keeping users safe by default.

[Jakob Bohm]

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-secur...@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 suggesting that we consider what policy should be applied to the
>> (required!) capability of keeping revocation running for max cert
>> lifetime after a CA ceases to operate.
>>
>
> 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 to the
situation, which I am arguing against.

>
>> For starters, a wind-down CA will not issue any more certificates (and
>> should probably be audited to that fact), and will thus not be
>> meaningfully subject to the various requirements associated with that
>> activity (such as validation procedures, contents of newly issued
>> certificates etc.). This alone should significantly reduce the scope of
>> requirements and audits.
>>
>
> I strongly disagree with this framing. The notion of a "wind-down CA" is
> not a concept that is part of the PKI. It remains a functional CA, with the
> full capability of issuance, and thus all appropriate policies, procedures,
> and protections apply.
>

While the notion may not be in the BRs directly, there seems to be a
common policy expectation that any accepted CA has procedures (listed in
their CPS under 5.8) for the wind-down process.

>
>> Secondly, a wind-down CA (as opposed to a wind-down root key from an
>> otherwise active CA) is likely to be operating from a prepaid
>> contingency fond, set up before the wind down based on the bare-bones
>> cost of safely doing the wind down procedures by a qualified but not
>> stellar skeleton crew. Thus maybe it shouldn't be required to engage
>> in time consuming administrative procedures such as responding to
>> quarterly Mozilla surveys or diligently watching m.d.s.p for new
>> requirements.
>>
>
> I strongly disagree with this. If we believe these services are meaningful
> for Mozilla users, it's absolutely relevant. Consider that the proposal
> here fails to consider OCSP nonces, for example, as a prime example of why
> this suggestion is inherently and fundamentally flawed.
>

These services are meaningful because the CA was meaningful before the
wind down, and not all end entity certificates will be instantly
replaced once an orderly wind down (as opposed to a chaotic disaster) is
decided.

This is about the orderly and graceful shutdown of a previously vetted
and accepted CA, as the last part of that accepted use. It is not about
a catastrophically failed CA such as Diginotar(NL) or allowing in a
nearly useless new CA.

>
>> From the perspective of keeping Mozilla users safe, there are simply a
>> lot less that could go wrong,
>
>
> This is not true.
>

Note the fundamental requirement (stated above) that there should be
auditing that the issuance has been stopped, possibly even disabled.
Provided there is good auditing and other assurance that no new
certificates are issued (except, perhaps, scheduled reissue of OCSP
certs etc.), many of the things that have gone wrong with real world
operational CAs in the Mozilla store simply can't happen. For example,
if they can't issue, they can't misissue.

>
>> Also, some ad hoc leniency may be used as a temporary substitute for a
>> formal policy.
>>
>
> I do not think these suggestions are good nor do they ensure the safety of
> users, nor offer the reliability or assurance.
>
> CAs can make contingency plans to deprecate in an orderly fashion without
> any of the issues Jakob raises. The failure to do so, and the resulting
> distrust, is wholly in line with keeping users safe by default.
>

How would they do this, in practice? Remember that this is about the
scenario where the entire CA operation (not just some old roots) are
deprecated. Most CA-related economic activity ends, vetting specialists
and issuance systems are laid off / shut down. If the CA is not a
subsidiary of a continuing company, there will be no ongoing income to
fund the wind down. There should however be a planned amount to fund
the shutdown set aside in some kind of legally protected fund or trust,
based on the expected cost of running things in the wind down period.

Because such a wind down plan (preferably spelled out in the CPS before
the wind down) will need to be planned before it becomes a reality, the
funding for the plan may have to be deposited in a secure account or
trust before it happens. This in turn means that the funding cannot
take into account any requirements enacted later, hence my suggestion
that a wind down CA should typically be subject only to the root program
policies (including the BRs) that were in effect when they were still an
active CA organization.

From my skimming of the BRs, the skeleton close out crew could be as
small as 2 or 3 people (to satisfy the requirement that HSM access
requires this) who work in a small office next to the secured server
room while the rest of the building has been rented out to a different
use. Or maybe the HSM has been moved to a cage in a 3rd party data
center where only the required 2 people access is allowed in, while day
to day revocation management is done from a small rented office, so the
building that housed the full CA staff with vetting specialists,
marketing teams etc. has been put back on the real estate market.

Now I don't know which is the precise situation of Turktrust, but their
slowness in responding to the routine questionaire indicates that the
manpower has probably already been reduced to the minimum needed to keep
OCSP etc. running and handling the possibility of revocation requests
for the last 10+ certificates (which may represent servers accessed by
many more Mozilla users).

P.S.

Since Turktrust never participated in CT, the list of certificates on
crt.sh probably only reflects those that were discovered through various
forms of telemetry, thus there might be more than the 10 known
certificates still in existence (and issued with proper procedures and
audits, accepted by Mozilla at the time).

[Eric Mill]

On Tue, Mar 20, 2018 at 3:43 PM, Jakob Bohm via dev-security-policy <
dev-secur...@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-secur...@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 suggesting that we consider what policy should be applied to the
>>> (required!) capability of keeping revocation running for max cert
>>> lifetime after a CA ceases to operate.
>>>
>>>
>> 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 to the
> situation, which I am arguing against.
>

The BRs absolutely cover this. The empty placeholder section is there for
CAs to describe their specific wind-down procedures (the BRs are often used
as a starting point for CAs developing a CP, with the intent that CAs will
fill out each section with their specific controls), but that does not mean
that the BRs don't cover CAs that are winding down.

And the BRs *should* cover this, because all that matters to BR scope is
whether a CA is still technically capable of issuing certificates. Their
own stated commitment to no longer issuing certificates is immaterial.

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 down and won't issue certificates anymore". From
Mozilla's perspective, any root in their trust stores needs to be held to
the same standard.

-- Eric

[Wayne Thayer]

On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy <
dev-secur...@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 down and won't issue certificates anymore". From
> Mozilla's perspective, any root in their trust stores needs to be held to
> the same standard.
>

> I agree. The prerequisites for recognizing a "wind-down CA" mode are at
least:
- BR updates that enable auditors to issue a report stating that the CA is
fully compliant with a "wind-down" mode of operations.
- Mozilla/Firefox CT policy/enforcement that ensures the CA can't simply
back-date certs.

[Jakob Bohm]

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 to the situation,
>> which
>> I am arguing against.
>

> The reason the placeholder is there is because we discussed wind down
> procedures in the policy working group, and decided that all bets were off
> at that point and there wasn't anything useful one could say about the
> situation in general.
>
> A CA can have assurances about what it would do in such a situation, but
> smart individuals might intelligently question whether it would ever be
> possible to rely on such assurances, short of some sort of contractual
> obligation with the CA.
>
> And even in the event you have such a favorable contractual obligation,
> you're still likely to find yourself in a bad place.
>
> Basically, once the audits cease, all bets are off. One could speculate the
> same is probably true up to one year prior to cessation of audits.
>

Which is precisely why I suggested ongoing audits of compliance with
wind down procedures (such as maintaining private key protection and
some auditable technical mechanism to prevent/detect issuance).

But the auditing of issuance procedures when 0 certs issued would be
pretty trivial (audit that 0 were issued, and maybe add stub text saying
that 100% of 0 were proper and not misissued). Thus it would make sense
to have a simplified audit report template for this.

Similarly, other procedures can be simplified once there is audited
assurance that nothing will be issued. For example no need to answer
questions about issuance procedures.

From another post today, it seems that Turktrust's audit of no issuance
(technically a full audit) is overdue, which is clearly a problem.

[Wayne Thayer]

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 suggested that the root also be added to OneCRL. I don't believe that
the current circumstances provide a strong argument for doing this, so
unless there is additional discussion I will not proceed with this proposed
action.

It has been proposed that we modify Mozilla policy to account for a
"wind-down" mode of operations. The counterpoint has been made that a root
hierarchy that is capable of issuance is as much of a risk as a root that
is issuing certificates. In this case the CA has stated that the decision
to suspend audits was based on the cost of those audits. I have doubts that
"wind-down" audits sufficient to address the risks inherent in a
non-issuing CA would be significantly less costly, even if the BRs made
provisions for them. 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 that hasn't issued any certificates in the period. I
will appreciate any additional suggestions that could help to resolve this
issue.

- Wayne

[Dimitris Zacharopoulos]

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 that hasn't issued any certificates in the period. I
> will appreciate any additional suggestions that could help to resolve this
> issue.

Auditors check what is required according to their audit criteria. There
is no different "set of criteria" for "wind-down" CAs. Common sense
dictates that a Qualified Auditor will check all the requirements and
note down any divergence from the standards. Not issuing Certificates is
not a divergence but, for example, not Issuing CRLs at the proper
interval mentioned in the standards, is a non-conformance.

If a CA doesn't actively issue certificates makes the audit days
"possibly" fewer because the sampling verification is less compared to a
CA that actively issues Certificates. I think both WebTrust and ETSI
have a standard for Auditors to calculate audit days so there is an
absolute minimum for all the controls and then they add days according
to the CA's operations, locations and so on. In other words, an audit
for a "wind-down" CA might be cheaper compared to an actively issuing CA
but there is a baseline.

Dimitris.