Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 08/03/2017 06:27, Ryan Sleevi wrote:

On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I saw nothing in Gervs posting suggesting that banning all kinds of
RA/DTP relationships was the intended effect.



But would you also acknowledge that your originally stated "The point is
NOT to prohibit RAs" is similarly not provided?

I highlight this, because I want to make sure you're not prematurely
dismissing policy suggestions because you disagree.



I am simply going by the wording in Gervs posting not stating what you
stated.  I presume that if Gerv wanted to complete eliminate the DTP
concept for Mozilla trusted CAs, then that's what he would have written.




As to the rest of your message, you describe what have historically been

called RAs/DTPs. You have not, however, answered my question - which is
what impact, if any, do you believe would happen if Mozilla considers the
policy I suggested: That is, to require that anything which 'historically'
was considered an RA be treated as an externally operated sub-CA.



For the kind of RA that is a combined reseller/control everything
related to issuing (the Symantec case), there would be no significant
change in burden for the RA.

For the kind of RA that only does specific relevant parts of validation
(a "traditional" RA), the suggested policy as written would "simply"
require the CA to set up and maintain one (set of) subCAs for each of
their RAs, while your rephrasing as a ban on RA/DTP relationships would
impose the full cost of a formal WebTrust (etc.) audit on RAs that only
perform a specific limited function that could be audited much cheaper,
provided the CA systems were set up to have little dependency on
certificate specific activities and security at the RAs.



This misunderstands Policy 1 then, and is perhaps the substance of our
unintentional disagreement.

if a CA sets up and maintains one (set of) sub CAs for each RA, then each
of those subCAs would need to be audited. This is no different than the
existing requirements, within the Baseline Requirements, that each DTP be
audited. I would highlight Section 8 of the Baseline Requirements for you,
and ask that you clarify where, under the existing policies (e.g. ignoring
any policy proposal) you believe there is any provision for allowing a DTP
to be "audited much cheaper".

If you believe such a thing is possible (I would argue incorrectly so, but
hear me out), then what we're effectively saying is that a set of
Principles and Criteria are not examined by the audit, because the
operation and majority of the controls are managed by the "Issuing CA" - at
least, within the world today of CA/RA relationships. If we believe such a
thing is accepted (and again, not supported by the Baseline Requirements,
and to the extent of my interactions with various auditor/practitioners, I
do not believe currently supported by WebTrust), then I hope you can also
see that we can use that self-same logic to conclude that a DTP operating
as a externally operated sub-CA - but one in which the "Issuing CA" handles
the operation and majority of controls for - is effectively the same thing.

Do you agree with that logic? Can you clarify where and why you disagree
with the analysis above?



Having not fully studied the exact wording of the BRs, I operate under
the assumption that the longer phrasing "... an audit report, issued
under the auditing standards that underlie the accepted audit schemes
found in Section 8.1 ..." as quoted from section 8.4 in earlier
discussion of the Symantec case was intentionally so phrased to
indicate that the audit of a DTP would not be the same as a full
WebTrust CA audit, but would only cover those aspects of those criteria
which would be applicable to the performance of the particular DTP role.

If that quote is indeed from the relevant part of the BRs, then I
would posit that if the BR authors had wanted all kinds of DTPs to be
subject to a full WebTrust audit, they would not have used this more
complex phrase.




For example, an RA whose sole involvement is to receive a daily list of
company name/idno/address/authorized signatory for pending
applications, go down to the state hall of records and report back
which ones match/do not match official company records (to support EV
certification for that state) would only need auditing of that activity
and the security of the system used to exchange that list and report
with the CAs central validation team.



Please provide a citation to the Baseline Requirements or Mozilla policy to
support this statement. I would suggest Section 8.4 provides
counter-evidence to this claim, and as such, because the argument rests on
this claim, needs to be addressed before we might make further progress.



I refer to the earlier quote ostensibly from section 8.4 itself.


Worse, I chose the precise term of "Delegated Third Party" to avoid
confusion with the explicitly-called out 

Re: Symantec: Next Steps

[Peter Bowen via dev-security-policy]

On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy
 wrote:
> On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
]>
>> For example, an RA whose sole involvement is to receive a daily list of
>> company name/idno/address/authorized signatory for pending
>> applications, go down to the state hall of records and report back
>> which ones match/do not match official company records (to support EV
>> certification for that state) would only need auditing of that activity
>> and the security of the system used to exchange that list and report
>> with the CAs central validation team.
>
>
> Please provide a citation to the Baseline Requirements or Mozilla policy to
> support this statement. I would suggest Section 8.4 provides
> counter-evidence to this claim, and as such, because the argument rests on
> this claim, needs to be addressed before we might make further progress.

Section 8.4 says: " If the CA is not using one of the above procedures
and the Delegated Third Party is not an Enterprise RA, then the
CA SHALL obtain an audit report, issued under the auditing standards
that underlie the accepted audit schemes
found in Section 8.1, that provides an opinion whether the Delegated
Third Party’s performance complies with
either the Delegated Third Party’s practice statement or the CA’s
Certificate Policy and/or Certification Practice
Statement."

If the DTP is only performing the functions that Jakob lists, then
they only need an auditor's opinion covering those functions. In fact
there is no way for an auditor to audit functions that don't exist.
For example, consider the WebTrust for CA criteria called "Subordinate
CA Certificate Life Cycle Management".  If the only CA in scope for
the audit does not issue Subordinate CA Certificates, then that
criteria is not applicable.  Depending on the auditor, it might be
that the CA needs to write in some policy (public or private) "the CA
does not issue Subordinate CA Certificates."

Many auditors vary how much they charge for their work based on the
expected effort required to compete the work.  I believe Jakob's point
is that an audit where all the criteria are just "we do not do X" is
very quick -- for example a DTP that does not have a HSM and does not
digitally sign things is going to be a much cheaper audit than one
that does have a HSM and signs things under multi-person control.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I saw nothing in Gervs posting suggesting that banning all kinds of
> RA/DTP relationships was the intended effect.


But would you also acknowledge that your originally stated "The point is
NOT to prohibit RAs" is similarly not provided?

I highlight this, because I want to make sure you're not prematurely
dismissing policy suggestions because you disagree.


> As to the rest of your message, you describe what have historically been
>> called RAs/DTPs. You have not, however, answered my question - which is
>> what impact, if any, do you believe would happen if Mozilla considers the
>> policy I suggested: That is, to require that anything which 'historically'
>> was considered an RA be treated as an externally operated sub-CA.
>>
>
> For the kind of RA that is a combined reseller/control everything
> related to issuing (the Symantec case), there would be no significant
> change in burden for the RA.
>
> For the kind of RA that only does specific relevant parts of validation
> (a "traditional" RA), the suggested policy as written would "simply"
> require the CA to set up and maintain one (set of) subCAs for each of
> their RAs, while your rephrasing as a ban on RA/DTP relationships would
> impose the full cost of a formal WebTrust (etc.) audit on RAs that only
> perform a specific limited function that could be audited much cheaper,
> provided the CA systems were set up to have little dependency on
> certificate specific activities and security at the RAs.
>

This misunderstands Policy 1 then, and is perhaps the substance of our
unintentional disagreement.

if a CA sets up and maintains one (set of) sub CAs for each RA, then each
of those subCAs would need to be audited. This is no different than the
existing requirements, within the Baseline Requirements, that each DTP be
audited. I would highlight Section 8 of the Baseline Requirements for you,
and ask that you clarify where, under the existing policies (e.g. ignoring
any policy proposal) you believe there is any provision for allowing a DTP
to be "audited much cheaper".

If you believe such a thing is possible (I would argue incorrectly so, but
hear me out), then what we're effectively saying is that a set of
Principles and Criteria are not examined by the audit, because the
operation and majority of the controls are managed by the "Issuing CA" - at
least, within the world today of CA/RA relationships. If we believe such a
thing is accepted (and again, not supported by the Baseline Requirements,
and to the extent of my interactions with various auditor/practitioners, I
do not believe currently supported by WebTrust), then I hope you can also
see that we can use that self-same logic to conclude that a DTP operating
as a externally operated sub-CA - but one in which the "Issuing CA" handles
the operation and majority of controls for - is effectively the same thing.

Do you agree with that logic? Can you clarify where and why you disagree
with the analysis above?


> For example, an RA whose sole involvement is to receive a daily list of
> company name/idno/address/authorized signatory for pending
> applications, go down to the state hall of records and report back
> which ones match/do not match official company records (to support EV
> certification for that state) would only need auditing of that activity
> and the security of the system used to exchange that list and report
> with the CAs central validation team.


Please provide a citation to the Baseline Requirements or Mozilla policy to
support this statement. I would suggest Section 8.4 provides
counter-evidence to this claim, and as such, because the argument rests on
this claim, needs to be addressed before we might make further progress.


> They should not need to pay a
> local WebTrust auditor to certify that the many activities done
> centrally at the CA (in a different country altogether) meet any
> particular requirements, as that should be in scope only for the actual
> auditing of the central CA (which should include auditing of the
> presence and compliance of the RA audit reports).
>
> For the "Enterprise customer" "DTP" case, I think subjecting each
> Enterprise that has a "cheaply issue certs for subnames" account to any
> kind of special audit would be as mindbogglingly onerous as requiring
> every shop that accepts credit cards via a 3rd party such as Google to
> go through and comply with full PCI certification for systems that
> never see credit card numbers, only the shopping cart.

For this case, the only thing that needs auditing is that the CA itself
> has properly validated that the Enterprise customer has the full
> authority to decide and state which of the acceptable subnames are who
> they say they are (as per DNS zone delegations for DNSnames, per mail
> domain ownership as per e-mail names etc.).  In other words the only
> thing the Enterprise customer 

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 08/03/2017 04:21, Ryan Sleevi wrote:

On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I contradicted you in saying that RAs (or DTP as you now want to call
them) were not supposed to be banned by the policy change.



DTPs are the terms from the Baseline Requirements. All responsibilities and
expectations are associated with that term.

As to the statement "were not supposed to be banned by the policy change",
I don't believe Gerv stated that, so it would be useful to understand why
you've stated that. These were a variety of policy proposals - all of which
are meant to change and/or clarify requirements - so I don't think we can
state that simply removing the concept is off the table.



I saw nothing in Gervs posting suggesting that banning all kinds of
RA/DTP relationships was the intended effect.


As to the rest of your message, you describe what have historically been
called RAs/DTPs. You have not, however, answered my question - which is
what impact, if any, do you believe would happen if Mozilla considers the
policy I suggested: That is, to require that anything which 'historically'
was considered an RA be treated as an externally operated sub-CA.


For the kind of RA that is a combined reseller/control everything
related to issuing (the Symantec case), there would be no significant
change in burden for the RA.

For the kind of RA that only does specific relevant parts of validation
(a "traditional" RA), the suggested policy as written would "simply"
require the CA to set up and maintain one (set of) subCAs for each of
their RAs, while your rephrasing as a ban on RA/DTP relationships would
impose the full cost of a formal WebTrust (etc.) audit on RAs that only
perform a specific limited function that could be audited much cheaper,
provided the CA systems were set up to have little dependency on
certificate specific activities and security at the RAs.

For example, an RA whose sole involvement is to receive a daily list of
company name/idno/address/authorized signatory for pending
applications, go down to the state hall of records and report back
which ones match/do not match official company records (to support EV
certification for that state) would only need auditing of that activity
and the security of the system used to exchange that list and report
with the CAs central validation team.  They should not need to pay a
local WebTrust auditor to certify that the many activities done
centrally at the CA (in a different country altogether) meet any
particular requirements, as that should be in scope only for the actual
auditing of the central CA (which should include auditing of the
presence and compliance of the RA audit reports).

For the "Enterprise customer" "DTP" case, I think subjecting each
Enterprise that has a "cheaply issue certs for subnames" account to any
kind of special audit would be as mindbogglingly onerous as requiring
every shop that accepts credit cards via a 3rd party such as Google to
go through and comply with full PCI certification for systems that
never see credit card numbers, only the shopping cart.

For this case, the only thing that needs auditing is that the CA itself
has properly validated that the Enterprise customer has the full
authority to decide and state which of the acceptable subnames are who
they say they are (as per DNS zone delegations for DNSnames, per mail
domain ownership as per e-mail names etc.).  In other words the only
thing the Enterprise customer is delegated to validate is those things
for which the Enterprise customer is the ultimate authority anyway.




I assert that there remains functional equivalence in role and
capabilities, but greater clarity as to expectations and audits. It would
be useful if, for example, you could highlight how such a policy would
create any form of new burden or requirement beyond the desired attributes
- technical capability to revoke and greater assurance of compliance
through public disclosure. Set aside the terminology question - and just
focus on the practical impact, if any.

Again, I assert, there is no negative impact, and any impact is the desired
degree of clarification for which Delegated Third Parties are already
nominally expected to be.

As a practical matter regarding audits, there's no supporting evidence for
the claim that RAs/Delegated Third Parties are allowed to be subject to
less audit requirements than CAs. I'd be curious if you could provide any
evidence in the Baseline Requirements or Mozilla Inclusion Policy to
support this claim, since it would seem to me this is the crux of your
objection.

In short, I'm hoping you can help me understand
* Why you believe it was not intended to 'eliminate' (though the functional
role remains) Delegated Third Parties
* Why you believe that Delegated Third Parties are subject to any less
audit requirement than Externally-Operated Subordinate CAs

You've stated what you believe, but I 

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

Im trying to keep score here but am having difficulties. Can someone 
confirm if the following statements are correct:- Google has acquired 
2 root certificates from GMO GlobalSign but not the ‎company itself. GMO 
GlobalSign will continue to own other roots and will use only those other roots 
for the various products and services they choose to offer.- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.- No disclosure has been made regarding what 
specific items were acquired, including such things as: private key 
material (HSMs and whatnot); computer equipment used as web 
servers, OCSP responders, etc.; domain names, IP addresses, and other 
infrastructure used in the operations and maintenance of the acquired roots; 
data such as subscriber lists, server logs, payment details and histories, 
certificate issuance activities and histories, etc.; and any access rights to 
physical space such as offices, data centers, development and test facilities, 
and so forth.- The scope of impact to existing GlobalSign customers 
is not known. Neither GMO GlobalSign nor Google have notified any existing 
clients of the acquisition.- The GlobalSign web site has no mention 
of this acquisition for reasons which are unknown. Further, the web site does 
not make their CP/CPS documents readily available limiting the ability for 
current subscribers and relying parties to decide if continued use of a cert 
chaining up to these roots is acceptable for them.- A relying party 
who actually takes the initiative to review a certificate chain will see that 
it is anchored (or verified by) GlobalSign. No mention of Google 
will be made anywhere.- Google has acquired these roots in order to 
better serve their subscribers, which are organizations (not 
people) throughout the many Google companies. Relying parties are not affected 
positively or negatively by this acquisition. - Mozilla granted 
Googles request to keep the acquisition confidential based on statements 
made by Google and Googles auditor EY. GlobalSign nor their auditors 
offered any opinion on this matter.Iapos;m trying to keep 
score here but am having difficulties. Can someone confirm if the following 
statements are correct:br/br/- Google has acquired 2 root 
certificates from GMO GlobalSign but not the ‎company itself. GMO GlobalSign 
will continue to own other roots and will use only those other roots for the 
various products and services they choose to offer.br/br/- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.br/br/- No disclosure has been made 
regarding what specific items were acquired, including such things as: 
quot;private key materialquot; (HSMapos;s and whatnot); computer 
equipment used as web servers, OCSP responders, etc.; domain names, IP 
addresses, and other infrastructure used in the operations and maintenance of 
the acquired roots; data such as subscriber lists, server logs, payment details 
and histories, certificate issuance activities and histories, etc.; and any 
access rights to physical space such as offices, data centers, development and 
test facilities, and so forth.br/br/- The scope of impact to 
existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google 
have notified any existing clients of the acquisition.br/br/- 
The GlobalSign web site has no mention of this acquisition for reasons which 
are unknown. Further, the web site does not make their CP/CPS documents readily 
available limiting the ability for current subscribers and relying parties to 
decide if continued use of a cert chaining up to these roots is acceptable for 
them.br/br/- A relying party who actually takes the initiative 
to review a certificate chain will see that it is anchored (or 
quot;verified byquot;) GlobalSign. No mention of Google will be made 
anywhere.br/br/- Google has acquired these roots in order to 
quot;better servequot; their subscribers, which are organizations 
(not people) throughout the many Google companies. Relying parties are not 
affected positively or negatively by this acquisition. br/br/- 
Mozilla granted Googleapos;s request to keep the acquisition confidential 
based on statements made by Google and Googleapos;s auditor Eamp;Y. 
GlobalSign nor their auditors offered any opinion on this 
matter.br/br/br/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I contradicted you in saying that RAs (or DTP as you now want to call
> them) were not supposed to be banned by the policy change.
>

DTPs are the terms from the Baseline Requirements. All responsibilities and
expectations are associated with that term.

As to the statement "were not supposed to be banned by the policy change",
I don't believe Gerv stated that, so it would be useful to understand why
you've stated that. These were a variety of policy proposals - all of which
are meant to change and/or clarify requirements - so I don't think we can
state that simply removing the concept is off the table.

As to the rest of your message, you describe what have historically been
called RAs/DTPs. You have not, however, answered my question - which is
what impact, if any, do you believe would happen if Mozilla considers the
policy I suggested: That is, to require that anything which 'historically'
was considered an RA be treated as an externally operated sub-CA.

I assert that there remains functional equivalence in role and
capabilities, but greater clarity as to expectations and audits. It would
be useful if, for example, you could highlight how such a policy would
create any form of new burden or requirement beyond the desired attributes
- technical capability to revoke and greater assurance of compliance
through public disclosure. Set aside the terminology question - and just
focus on the practical impact, if any.

Again, I assert, there is no negative impact, and any impact is the desired
degree of clarification for which Delegated Third Parties are already
nominally expected to be.

As a practical matter regarding audits, there's no supporting evidence for
the claim that RAs/Delegated Third Parties are allowed to be subject to
less audit requirements than CAs. I'd be curious if you could provide any
evidence in the Baseline Requirements or Mozilla Inclusion Policy to
support this claim, since it would seem to me this is the crux of your
objection.

In short, I'm hoping you can help me understand
* Why you believe it was not intended to 'eliminate' (though the functional
role remains) Delegated Third Parties
* Why you believe that Delegated Third Parties are subject to any less
audit requirement than Externally-Operated Subordinate CAs

You've stated what you believe, but I cannot find evidence to support
either claim.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 08/03/2017 01:40, Ryan Sleevi wrote:

On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 07/03/2017 21:37, Ryan Sleevi wrote:


To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third Parties from participating in the issuance process? This would be
effectively the same, in as much as the only capability to allow a
third-party to participate in issuance is to operate a subordinate CA.

I think it's procedurally identical to Policy Proposal 1, but it clarifies
more explicitly that RAs are forbidden, and that all participants in the
issuance ecosystem have a specific set of obligations.



The point is NOT to prohibit RAs (which are a good thing if done
right), but to allow revocation of certificates validated by a rogue RA.

The setup under policy 1 would be that the actual CA holds the key and
issuance systems in its own right and under its own security audits,
while the RA only deals with the actual verification steps (such as
checking that Foo Inc is actually incorporated in country X with
official address on Bar Avenue 123 in Baz City according to official
records in the local language).

Policy 1 is also intended for the reseller-RA combination seen in the
Symantec case, where the reseller-RA does other steps that could/should
be done by the CA directly (such as domain validation and suspicious
case double checking).

Policy 1 may still be a problem for the truly local RA scenario where a
large number of similar RAs handle in-person verification steps for a
small geographic area (such as schemes where each city hall handles
checking photo ID of applicants as part of validation at better
than EV level).



Jakob,

You basically restated what I said, except still kept the term "RA". Note
that my proposal would not have eliminated the conceptual role you're
describing - this is still facilitated - but it's explicitly called out as
an externally operated subordinate CA, with all the attendant
responsibility and audit criteria. The fact that one or more pieces of
infrastructure is offered by the issuing CA is nothing new, in practice,
and so the ecosystem already deals with (or fails to deal with) this case.

So perhaps it's useful if you can explain why "Delegated Third Party"
(since RA is overloaded to include the pre-validated domain case of an
Enteprise RA, as well as to cover the case where an RA does not perform
domain validation) is a useful concept to support, versus simply treating
it as the well-understood role of externally-operated subordinate CA?



I contradicted you in saying that RAs (or DTP as you now want to call
them) were not supposed to be banned by the policy change.

The point of a general-purpose RA (such as the ones that failed in the
Symantec case) is that they are supposed to explicitly perform fewer
functions and be subject to corresponding reduced requirements
(especially if properly setup from the CA end), and are to be audited
accordingly (without duplicated pseudo audit statements about the
nature of the CA hosted infrastructure).

Another type of true RA in the traditional sense is an office that
performs specific limited parts of the validation, with the main CA
doing the rest.  For example the RA would check things that cannot be
checked from wherever the CA is located (in person identification,
access to local official records in local language etc.), while the CA
would do all the checks that don't depend on local knowledge, such as
domain checks, BR enforcement etc.  These would be subject to even less
audit requirements compared to a subCA, since they perform an even more
limited subset of CA functions.

A type of Delegated Third Party that isn't an RA in the traditional
sense (but may fall under some RA definitions) would be a pre-validated
Enterprise authorized to request certificates for entities that are
fully nested under its validated name spaces (domains, distinguished
names), with the CA reusing (under the 39 month rule) validations of
those name spaces as being under full control of the enterprise.  Those
enterprises could in fact be considered as being mere subscribers
rather than delegated third parties.

Except for the proposed new special policy (which serves only to
provide a centralized way for Mozilla to revoke all certificates issued
through a specific RA, and only in cases where the CA is somehow
unwilling to revoke those certificates itself while Mozilla is
unwilling to revoke the CA trust), there is nothing that
should conflate the DTP and CA roles.




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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/03/2017 21:37, Ryan Sleevi wrote:
>>
>> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
>> Third Parties from participating in the issuance process? This would be
>> effectively the same, in as much as the only capability to allow a
>> third-party to participate in issuance is to operate a subordinate CA.
>>
>> I think it's procedurally identical to Policy Proposal 1, but it clarifies
>> more explicitly that RAs are forbidden, and that all participants in the
>> issuance ecosystem have a specific set of obligations.
>>
>>
> The point is NOT to prohibit RAs (which are a good thing if done
> right), but to allow revocation of certificates validated by a rogue RA.
>
> The setup under policy 1 would be that the actual CA holds the key and
> issuance systems in its own right and under its own security audits,
> while the RA only deals with the actual verification steps (such as
> checking that Foo Inc is actually incorporated in country X with
> official address on Bar Avenue 123 in Baz City according to official
> records in the local language).
>
> Policy 1 is also intended for the reseller-RA combination seen in the
> Symantec case, where the reseller-RA does other steps that could/should
> be done by the CA directly (such as domain validation and suspicious
> case double checking).
>
> Policy 1 may still be a problem for the truly local RA scenario where a
> large number of similar RAs handle in-person verification steps for a
> small geographic area (such as schemes where each city hall handles
> checking photo ID of applicants as part of validation at better
> than EV level).
>

Jakob,

You basically restated what I said, except still kept the term "RA". Note
that my proposal would not have eliminated the conceptual role you're
describing - this is still facilitated - but it's explicitly called out as
an externally operated subordinate CA, with all the attendant
responsibility and audit criteria. The fact that one or more pieces of
infrastructure is offered by the issuing CA is nothing new, in practice,
and so the ecosystem already deals with (or fails to deal with) this case.

So perhaps it's useful if you can explain why "Delegated Third Party"
(since RA is overloaded to include the pre-validated domain case of an
Enteprise RA, as well as to cover the case where an RA does not perform
domain validation) is a useful concept to support, versus simply treating
it as the well-understood role of externally-operated subordinate CA?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Include Renewed Kamu SM root certificate

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 6:01 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 1) Domain Validation Methods
> For the CA, I recommend reviewing section 3.2.2.4 of version 1.4.1 of the
> CA/Browser Forum’s Baseline Requirements, because many of the relevant
> subsections are currently redacted in version 1.4.2 due to ongoing
> discussions in the CAB Forum. Nevertheless, the CA can review version 1.4.1
> to further bolster their domain validation policies and practices.
>
> I am hoping that the CAB Forum will resolve the issues that caused the
> redaction of some sections of the BRs, such that a new version will be
> published by the end of March that has the same level of information about
> domain validation as version 1.4.1 of the BRs.
>
> Gerv and I plan to send a CA Communication around the end of March, and
> plan for one of the action items to require that CAs update their CP/CPS,
> because it should be updated annually. And also to update their domain
> validation practices and policies.
>

While this applies to the overall process of domain validation, I was
calling this specific matter out as it was the original motivation for the
work presented three years ago, in part due to the security concerns Google
raised to the Forum regarding it. That is, the practical demonstration of
control for the server is one of the non-redacted/placeholder versions, so
the description of file-based control should at least be reformed to this
degree of 3.2.2.4.6, since it's hard to justify any other file-based
control meets the equivalent level of security under 3.2.2.4.11


> 2) Qualified audit statement listing serial number generation deficiencies
> for the time period from September 30, 2016 to when it was fixed by the CA.
>
> There is a lag between when a BR is updated/adopted, and when the audit
> principles/criteria are adopted. So, I am not convinced that an audit
> during that time period would cover that particular control, and list it as
> an exception in the audit statement.
>

Correct, while it's unlikely that a specific illustrative control and/or
new principle will be introduced on this regard, even when the WebTrust for
CAs - SSL Baseline Requirements are updated to incorporate that version of
the Baseline Requirements, it is a failure with respect to the CA's
statement that the policies and practices outlined in the latest published
version of the Baseline Requirements supercede that of the CP/CPS , which
is where the qualification would be derived from.

That is, CAs are expected to conform to the Baseline Requirements as
they're updated/adopted, but there may not be auditable controls attached
to them until one or two years after the passage, depending on the WebTrust
TF or ETSI meeting to incorporate such requirements explicitly. However,
they are all normative implicitly, per the stated adherence to the Baseline
Requirements.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 07/03/2017 21:37, Ryan Sleevi wrote:

On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Policy Proposal 1: require all CAs to arrange it so that certs validated
by an RA are issued from one or more intermediates dedicated solely to
that RA, with such intermediates clearly labelled with the name of the
RA in the Subject.

If we enact Policy Proposal 1, that allows RAs to be cut off, and also
provides a natural point for the CP/CPS and audits of the RA to be
monitored in the CCADB, because they would be attached by the CA to the
issuing intermediate for that RA.

Symantec's oversight of their RAs was clearly inadequate; various forms
of misissuance were not detected.



To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third Parties from participating in the issuance process? This would be
effectively the same, in as much as the only capability to allow a
third-party to participate in issuance is to operate a subordinate CA.

I think it's procedurally identical to Policy Proposal 1, but it clarifies
more explicitly that RAs are forbidden, and that all participants in the
issuance ecosystem have a specific set of obligations.



The point is NOT to prohibit RAs (which are a good thing if done
right), but to allow revocation of certificates validated by a rogue RA.

The setup under policy 1 would be that the actual CA holds the key and
issuance systems in its own right and under its own security audits,
while the RA only deals with the actual verification steps (such as
checking that Foo Inc is actually incorporated in country X with
official address on Bar Avenue 123 in Baz City according to official
records in the local language).

Policy 1 is also intended for the reseller-RA combination seen in the
Symantec case, where the reseller-RA does other steps that could/should
be done by the CA directly (such as domain validation and suspicious
case double checking).

Policy 1 may still be a problem for the truly local RA scenario where a
large number of similar RAs handle in-person verification steps for a
small geographic area (such as schemes where each city hall handles
checking photo ID of applicants as part of validation at better
than EV level).


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Include Renewed Kamu SM root certificate

[Kathleen Wilson via dev-security-policy]

Thank you Andrew and Ryan for your feedback on this request to include the 
"TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable 
the Websites trust bit.

Note that the new SHA-256 root certificate will replace the SHA1 “TÜBİTAK UEKAE 
Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3” root certificate that is currently 
included, but expires on August 21, 2017. So, this CA will greatly appreciate 
prompt feedback from everyone.

I have attached the updated version of the CPS (v1.0.1) to the bug:
https://bug1262809.bmoattachments.org/attachment.cgi?id=8844549

Of course, all of this CA’s CPS changes will need to be propagated back to the 
Turkish version of the CPS, and to the CA's website. But let's see if there is 
any further feedback first.

Andrew, does the updated CPS fully address your questions/concerns?

Ryan, in regards to your feedback:

1) Domain Validation Methods
For the CA, I recommend reviewing section 3.2.2.4 of version 1.4.1 of the 
CA/Browser Forum’s Baseline Requirements, because many of the relevant 
subsections are currently redacted in version 1.4.2 due to ongoing discussions 
in the CAB Forum. Nevertheless, the CA can review version 1.4.1 to further 
bolster their domain validation policies and practices.

I am hoping that the CAB Forum will resolve the issues that caused the 
redaction of some sections of the BRs, such that a new version will be 
published by the end of March that has the same level of information about 
domain validation as version 1.4.1 of the BRs.

Gerv and I plan to send a CA Communication around the end of March, and plan 
for one of the action items to require that CAs update their CP/CPS, because it 
should be updated annually. And also to update their domain validation 
practices and policies.


2) Qualified audit statement listing serial number generation deficiencies for 
the time period from September 30, 2016 to when it was fixed by the CA.

There is a lag between when a BR is updated/adopted, and when the audit 
principles/criteria are adopted. So, I am not convinced that an audit during 
that time period would cover that particular control, and list it as an 
exception in the audit statement.

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

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Policy Proposal 1: require all CAs to arrange it so that certs validated
> by an RA are issued from one or more intermediates dedicated solely to
> that RA, with such intermediates clearly labelled with the name of the
> RA in the Subject.
>
> If we enact Policy Proposal 1, that allows RAs to be cut off, and also
> provides a natural point for the CP/CPS and audits of the RA to be
> monitored in the CCADB, because they would be attached by the CA to the
> issuing intermediate for that RA.
>
> Symantec's oversight of their RAs was clearly inadequate; various forms
> of misissuance were not detected.
>
>
To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third Parties from participating in the issuance process? This would be
effectively the same, in as much as the only capability to allow a
third-party to participate in issuance is to operate a subordinate CA.

I think it's procedurally identical to Policy Proposal 1, but it clarifies
more explicitly that RAs are forbidden, and that all participants in the
issuance ecosystem have a specific set of obligations.


>
>
> Failures
> 
>
> As noted by module peer Ryan Sleevi, this is not the first time Symantec
> has had difficulties with misissued "test" certificates. It is
> disappointing that investigations related to the last incident did not
> turn up the problems which have now been discovered. Various forms of
> investigation and remediation were not, apparently, applied to
> Symantec's RA network in the same way they were supposedly applied at
> Symantec.
>
> It seems to me that Symantec's claim is of lack of knowledge - that they
> contracted and trained CrossCert to do the right things, and the
> auditors said that they were, and they had no evidence that they were
> not, and so they assumed everything was fine. The question is whether
> that lack of knowledge amounts to negligence.
>
> Comments on this topic, with careful justification, are invited.
>
> [The alleged audit failures, as opposed to alleged failures by Symantec,
> will be discussed in a separate process.]
>

Gerv,

have you examined the most recent set of audits? Do you, in your capacity
as CA Certificate policy peer, believe the audits were correct for their
capability and role? Note that several of them were "WebTrust for CAs" -
not "WebTrust for CAs - SSL BR and Network Security". Do you believe that
complies with letter of the Baseline Requirements?

Similarly, do you believe Symantec had an obligation to ensure the proper
licensing status of auditors, prior to accepting such audits?

I think these may represent important questions for Mozilla to determine,
in order to evaluate the fullness of the claim you have summarized, and I
think would equally apply if we were discussing externally-operated
subordinate CAs, correct?

Considering the capability afforded to these RAs - full certificate
issuance through independent domain validation - I'm curious whether you
believe this materially represents a practical distinction from the
issuance of an unconstrained subordinate CA, and how responsible the
issuing CA is for overseeing those operations.

How would Mozilla respond if in every case of "RA", it was replaced with
"Sub-CA"? That seems to be the guiding principle here, since they're
functionally indistinguishable in this case, except the RA brought with it
even greater risk, and lacked sufficient audit controls or technical
mitigations to prevent unauthorized access or ensure adequate logging.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

On 07/03/2017 18:29, Ryan Hurst wrote:

pzb: I appreciate you finally sending responses.  I hope you appreciate



that they are clearly not adequate, in my opinion.  Please see the



comments inline.


Again, sorry for the delay in responding, I will be more prompt moving
forward.


pzb: This does not resolve the concern.  The BRs require an "an unbroken



sequence of audit periods".  Given that GlobalSign clearly cannot make



any assertion about the roots after 11 August 2016, you would have a



gap from 11 August 2016 to 30 September 2016 in your sequence of audit



periods if your next report runs 1 October 2016 to 30 September 2017.



I understand your point but this is not entirely accurate. Our strategy, to
ensure a smooth transition, which was reviewed with the auditors and root
program administrators was that we take possession of the root key material
and manage it offline, in accordance with our existing WebTrust audit and
the “Key Storage, Backup and Recovery Criterion”.  It was our, and EY's
opinion that the existing controls and ongoing WebTrust audits were
sufficient given this plan and scope.

As such, during the period in question, the existing audits provide an
un-broken sequence of audit periods.

That said, we will follow-up with our auditors to see if it is possible to
extend the scope of our 2017 audit to also cover this interval to ensure
the community has further assurances of continuity.


pzb: Based on my personal experience, it is possible to negotiate a deal



and set a closing date in the future.  This is standard for many



acquisitions; you frequently see purchases announced with a closing



date in the future for all kinds of deals.  The gap between signing



the deal and closing gives acquirers the opportunity to complete the



steps in B.


As I stated, I think that moving forward this could be a good policy
change, I am hesitant to see any user agent adopt policies that are overly
prescriptive of commercial terms between two independent parties.



Could a reasonably condition be that decision authority, actual and
physical control for a root are not moved until proper root program
coordination has been done (an action which may occur after/before the
commercial conclusion of a transaction).  From a business perspective
this could be comparable to similar requirements imposed on some
physical objects that can have public interest implications.




pzb: You appear to be confusing things here.  "Subordinate CA Certificate



Life Cycle Management" is the portion of the WebTrust criteria that



covers the controls around issuing certificates with the cA component



of the basicConstraints extension set to true.  It has nothing to do



with operating a subordinate CA.


I am familiar with the "Subordinate CA Certificate Life Cycle Management"
controls

I just should have been more explicit in my earlier response.

These keys were generated and stored in accordance with Asset
Classification and Management Criterion, and Key Storage, Backup and
Recovery Criterion.

Before utilizing the associated keys in any activity covered by the
“Subordinate CA

Certificate Life Cycle Management” criterion all associated policies and
procedures were

created, tested and then reviewed by our auditors. Additionally, those
auditors were

present during the associated ceremony. All such activities which will be
covered under

our 2017 audit.

This is similar to how a CA can, and does, revise and extend their policies
between

audits to cover new products and services.

This is consistent with the approach we discussed, and had approved with
the various root program administrators.



pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the



applicable CPS for your _root CAs_ between 11 August 2016 and 8



December 2016.  The Google CPS makes these statements.  Therefore, you



are stating that the roots (not just GIA G2) were only permitted to



issue Certificates to Google and Google Affiliates.


Correct, these roots were not used to issue certificates at all until last
week and when one was used, it was used to issue a subordinate CA
certificate to Google.

Though we do not have a product or service to announce currently, we can
say we will expand the  use of GTS beyond GIAG2, at which time policies,
procedures, CP and CPS will be updated accordingly. This progression makes
sense as we're moving from a constrained intermediate to a Root.


Mozilla has consistently taken the position that roots that exclusively

issue to a


single company are not acceptable in the root program.


Google and its affiliate companies are more than a single company.

Additionally, clearly the intent of this rule is to prevent thousands of
organizations issuing a handful of certificates polluting the root store.

In the case of Google and its Affiliate companies, we operate products and
services for our

customers. This is similar to how Amazon and a number of other root

Re: Include Renewed Kamu SM root certificate

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 9:14 AM, tuubaonder--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This section states "WHOIS records pertinent to domain name specified in
> the certificate application shall be verified via 'www.nic.tr'". It would
> be useful to have more detail on the validation method. See section 3.2.2.4
> of the Baseline Requirements.
> -   We realized that domain name ownership control via nic.tr is not
> written in detailed. So, we updated related part in CPS. Please see 3.2.2
> part in CPS.
> •   To summarize, Domain Name Registrar is called by phone and contact
> information of domain name registrant is checked whether it is same with
> written in application form. If it is correct, Kamu SM requested an
> agreed-upon change to information found on an online web page identified by
> a uniform resource identifier containing the full domain name. So,
> verification of domain name ownership is made by nic.tr.
>

Note, as of adoption of Ballots 169 and 181 of the Baseline Requirements,
this no longer meets the sufficient bar for validation of control.

Please examine Section 3.2.2.4.6 of the Baseline Requirements.


> 10.3 End Entity SSL Certificate Template
>
> For Serial Number, a unique number is insufficient, per BRs "CAs SHALL
> generate non‐sequential Certificate serial numbers greater than zero (0)
> containing at least 64 bits of output from a CSPRNG."
>
> -Our random generator was not generating 64 bit number. Now, we changed
> the procedure for creating serial number as: 64 bit random number is
> generated by CSPRNG and concatenated with the number generated by sequence.
> Our new test ssl certificate in https://testssl.kamusm.gov.tr/ was
> created with such a serial number


As of Ballot 164 for the Baseline Requirements, this has been required for
all publicly trusted CAs since 30 September 2016.

It is reasonable to expect this to be a qualification on the matter of
opinion during the next annual audit that covers the period of time between
30 September 2016 until now.


Given these two issues above, please ensure that the current Baseline
Requirements v1.4.2, are reviewed by your CP/CPS team, and that all
practices Kamu SM employs are consistent with these requirements. Please
further ensure that any deviations from such requirements are acknowledged,
either on this list or in the bug, and then sufficiently called out within
the next audit period.

Kathleen, might I suggest that we delay further progress until Kamu SM has
had the opportunity to complete such a review and disclose any further
inconsistencies to Mozilla, so that Mozilla may evaluate whether or not
they represent blocking concerns towards the inclusion of this certificate,
and to review with Kamu SM the proposed remediation steps?

I think Kamu SM has shown a good faith effort to respond to the concerns
raised, but I'm concerned that both of these recent developments within the
CA/Browser Forum were overlooked, thus it may be best to hold onto
proceeding until that comparison is done and disclosed, allowing the
community sufficient information to respond - much as we see with the
recent misissuance reports from existing trusted CAs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> pzb: I appreciate you finally sending responses.  I hope you appreciate

> that they are clearly not adequate, in my opinion.  Please see the

> comments inline.

Again, sorry for the delay in responding, I will be more prompt moving
forward.

> pzb: This does not resolve the concern.  The BRs require an "an unbroken

> sequence of audit periods".  Given that GlobalSign clearly cannot make

> any assertion about the roots after 11 August 2016, you would have a

> gap from 11 August 2016 to 30 September 2016 in your sequence of audit

> periods if your next report runs 1 October 2016 to 30 September 2017.


I understand your point but this is not entirely accurate. Our strategy, to
ensure a smooth transition, which was reviewed with the auditors and root
program administrators was that we take possession of the root key material
and manage it offline, in accordance with our existing WebTrust audit and
the “Key Storage, Backup and Recovery Criterion”.  It was our, and EY's
opinion that the existing controls and ongoing WebTrust audits were
sufficient given this plan and scope.

As such, during the period in question, the existing audits provide an
un-broken sequence of audit periods.

That said, we will follow-up with our auditors to see if it is possible to
extend the scope of our 2017 audit to also cover this interval to ensure
the community has further assurances of continuity.

> pzb: Based on my personal experience, it is possible to negotiate a deal

> and set a closing date in the future.  This is standard for many

> acquisitions; you frequently see purchases announced with a closing

> date in the future for all kinds of deals.  The gap between signing

> the deal and closing gives acquirers the opportunity to complete the

> steps in B.

As I stated, I think that moving forward this could be a good policy
change, I am hesitant to see any user agent adopt policies that are overly
prescriptive of commercial terms between two independent parties.


> pzb: You appear to be confusing things here.  "Subordinate CA Certificate

> Life Cycle Management" is the portion of the WebTrust criteria that

> covers the controls around issuing certificates with the cA component

> of the basicConstraints extension set to true.  It has nothing to do

> with operating a subordinate CA.

I am familiar with the "Subordinate CA Certificate Life Cycle Management"
controls

I just should have been more explicit in my earlier response.

These keys were generated and stored in accordance with Asset
Classification and Management Criterion, and Key Storage, Backup and
Recovery Criterion.

Before utilizing the associated keys in any activity covered by the
“Subordinate CA

Certificate Life Cycle Management” criterion all associated policies and
procedures were

created, tested and then reviewed by our auditors. Additionally, those
auditors were

present during the associated ceremony. All such activities which will be
covered under

our 2017 audit.

This is similar to how a CA can, and does, revise and extend their policies
between

audits to cover new products and services.

This is consistent with the approach we discussed, and had approved with
the various root program administrators.


> pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the

> applicable CPS for your _root CAs_ between 11 August 2016 and 8

> December 2016.  The Google CPS makes these statements.  Therefore, you

> are stating that the roots (not just GIA G2) were only permitted to

> issue Certificates to Google and Google Affiliates.

Correct, these roots were not used to issue certificates at all until last
week and when one was used, it was used to issue a subordinate CA
certificate to Google.

Though we do not have a product or service to announce currently, we can
say we will expand the  use of GTS beyond GIAG2, at which time policies,
procedures, CP and CPS will be updated accordingly. This progression makes
sense as we're moving from a constrained intermediate to a Root.

> Mozilla has consistently taken the position that roots that exclusively
issue to a

> single company are not acceptable in the root program.

Google and its affiliate companies are more than a single company.

Additionally, clearly the intent of this rule is to prevent thousands of
organizations issuing a handful of certificates polluting the root store.

In the case of Google and its Affiliate companies, we operate products and
services for our

customers. This is similar to how Amazon and a number of other root
operators operate

products and services for their customers, the core difference being the
breadth of user

facing products we have.

> This does not address the question.  The Google CPS clearly states

> that it only covers the GIA G2 CA.  You have stated that the Google

> CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_

> between 11 August 2016 and 8 December 2016.  This puts your statement

> at adds with what is written in 

Re: Include Renewed Kamu SM root certificate

[tuubaonder--- via dev-security-policy]

Hi Andrew and Kathleen,

Thanks Andrew for reviewing our CPS document. We have updated the CPS document 
by the direction of your indications. Also you can find our replies below:

1.2 Document Name and Identification

Document version number is 3, but the front page and headers say version
1.  Please clarify.

-   Just misspelled. In fact it was 1.0.0. It is corrected and version 
history table is added and after theese changes it is updated as 1.0.1. 
Please see, 1.2 section of CPS.


3.1.5   Uniqueness of Names

-   Yes, usage of common name is Deprecated (Discouraged, but not 
prohibited) in CAB BR. Also, it is specified as “If present, this field MUST 
contain a single IP address or Fully‐Qualified Domain Name that is one of the 
values contained in the Certificate’s subjectAltName extension”. Firstly we 
want to indicate that we follow this rule and it can be checked via our test 
ssl certificate deployed on https://testssl.kamusm.gov.tr/. Also, we started 
work to remove common name in certificates and plan to complete it as soon as 
possible.


3.2.2 Authentication of Organization Identity

This section states "WHOIS records pertinent to domain name specified in
the certificate application shall be verified via 'www.nic.tr'". It would
be useful to have more detail on the validation method. See section 3.2.2.4
of the Baseline Requirements.
-   We realized that domain name ownership control via nic.tr is not 
written in detailed. So, we updated related part in CPS. Please see 3.2.2 part 
in CPS. 
•   To summarize, Domain Name Registrar is called by phone and contact 
information of domain name registrant is checked whether it is same with 
written in application form. If it is correct, Kamu SM requested an agreed-upon 
change to information found on an online web page identified by a uniform 
resource identifier containing the full domain name. So, verification of domain 
name ownership is made by nic.tr.



4.9.3 Procedure for Revocation Request

The Baseline Requirements for this section state: "The CA SHALL provide
Subscribers, Relying Parties, Application Software Suppliers, and other
third parties with clear instructions for reporting suspected Private Key
Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to Certificates.
The CA SHALL publicly disclose the instructions through a readily
accessible online means."
-   We have written the procedure of revocation in this section. However, 
as you said, how to apply for revocation should also be written. For this, we 
updated this section in CPS with the reference to “SSL Certificate Revocation 
Form” which you can find in our web page in this link: 
(http://www.kamusm.gov.tr/dosyalar/formlar/FORM-001-009%20GUVENLI%20SUNUCU%20SERTIFIKASI%20(SSL)%20IPTAL%20BASVURU%20FORMU.doc
  ) and all the instructions are in that form. The form is in Turkish, sorry 
for that, but our all applicants are Turkish government agencies as you know. 

As such instructions aren't included in the CP/CPS, could you point to
where they can be found?


6.5.1 Specific Computer Security Technical Requirements

Please make sure use of anti virus is properly risk managed. There have
been a worrying number of high severity bugs in popular anti virus
software, including privileged remote code execution.
-   We updated that section by adding that we keep the updateness of our 
virus detection systems and cleaning agents. 
Also, we can mention about our anti-virus security solutions. In our 
organization, host intrusion detection system is used besides antivirus 
security solutions for server and end user computers in the scope of security 
solutions. Security vulnerabilities of antivirus software are monitored and 
regular updates are made. In addition, the host intrusion detection system 
keeps track of user transactions under policies and informs the information 
security team by creating alarms for critical file movements, unauthorized 
access and abnormal movements.

7.2.2 CRL and CRL Entry Extensions

Though optional, CRL reason codes are encouraged.

-   We was following the rule in section 5.3.1 of RFC 5280. Which indicates 
that  the reason code CRL entry extension SHOULD be absent instead of using the 
unspecified (0) reasonCode value.
In fact we use reason code but the related entry in CRL profile was left 
optional accidentally. 
You can check an example CRL containing reason code from 
http://depo.kamusm.gov.tr/ssl/SSLSIL.S1.crl
Also we updated the CPS section and removed optional. 
 


9.4.3 Information Not Deemed Private

The contents of publicly trusted certificates should always be treated as
public even if such a an agreement or contract is in place.

-   We updated that section, remove the condition. Now, we indicate The 
contents of publicly trusted certificates are not confidential.

10.3 End Entity SSL Certificate Template

For Serial Number, a unique 

Re: Mozilla Root Store Policy 2.4.1

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 7, 2017 at 5:09 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > 1.1 Scope
> >   Item 2:
> > Bullet 1: This would allow the anyEKU to be considered 'out of
> scope'.
> > Is that intentional? (notwithstanding Section 5.3.1)
> > Bullet 2: This potentially leads to confusion as to what it means to
> > 'not allow' such types, given that nameConstraints only apply to the type
> > for which they're present. That is, the absence of an iPAddress
> > nameConstraint means there's no restriction, while the presence has to be
> > constructed in a way to exclude all IP addresses in the excludedSubtrees.
> > Similarly, as captured during the SRVName discussions in the CA/Browser
> > Forum, there's uncertainty as to how to capture such an exclusion with an
> > SRVName nameConstraint.
> >
> >   I don't know how best to suggest rephrasing this, other than I think
> the
> > scope may need to forward-reference a subsequent section that defines the
> > technical means for that scope. I suspect you were trying to avoid this,
> > but I think that to avoid ambiguity as to what the scope is, you'll want
> to
> > ensure a precise technical definition is linked to the prosaic goal.
> >
> >   Item 3: Similar to above, this allows excluding the anyEKU from scope
> > (notwithstanding Section 5.3.1)
>
> Are these issues also present in 2.4?
>

Ish? I can't quite decide whether or not, hence why I raised it.

For example, Inclusion, Item 9 describes what it takes for something to be
technically constrained, which explicitly excludes anyExtendedKeyUsage and
then further refines the definition (with a forward declaration to the BRs)
for id-kp-serverAuth.

So overall, I can't see an explicit prohibition on anyExtendedKeyUsage
within the existing Mozilla Policy, and all requirements (particularly
audits) flow down.


> 3
> >   - As you reformat this, perhaps it's worth borrowing the Microsoft of
> > approach of mapping trust bits to criteria
>
> Can you link to an example?
>

I did in my 4.1.2 notes - but http://aka.ms/auditreqs and more specifically
https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx#Conventional_CA_Audit_Standards


I think 4.1.2 is the appropriate place for such a mapping, but I
highlighted it because Section 3.3 leaves some confusion relative to 4.1.2,
so perhaps it may be worth
 c

Small 3.3 nit: Replace "Below" with "The following list" ? "Below" leaves
it uncertain if 'every conflict in Section 3.3 + onwards is intentiona' ;)

>
> > 4.1.2
> >   - You link to the "Baseline Requirements" document, but don't define
> what
> > a BR audit is. While 4.1.1 lists audit criteria, this ambiguity may be
> > undesirable. As with my immediately preceeding section, it may be worth
> > mapping "trust bits" to "accepted audits", e.g. "For CA certificates
> which
> > have the SSL trust bit set, we expect the following audits ..."
> >- Similarly, when two audit schemes are interchangable, it may be
> worth
> > clarifying. For example, would Mozilla accept an ETSI TS 102 042 audit to
> > the DVCP profile along with a WebTrust for cAs - 2.0 audit? My hope would
> > be 'no', but the proposal leaves this ambiguous.
> https://aka.ms/auditreqs
> > gives a clearer idea of what I'm thinking.
>
> I've added lists of acceptable criteria beside each audit requirement.
>
> Should we simply say that a given root (and I say root, as opposed to
> 'CA') has to be covered by all-WebTrust or all-ETSI auditing?
>

I think your new wording is still fairly unclear, and had quite a bit of
time parsing it.

For example, 4.1.1 (7) leaves it ambiguous what "appropriate for the trust
bit(s) being applied for". 4.1.1 (4) suggests QCP is appropriate for TLS
(it isn't; it's accepted for email though?)

Your new wording still suggests a mix and match approach, so I'd suggest:

4.1.2 Required Audits

(Do all sub-CAs need to use the same scheme as the parent CA? I would
presume yes, but not clear)

4.1.2.1 WebTrust

If being audited to the criteria developed by the WebTrust Task Force of
AICPA (or is it just CPA Canada? I think it's still AICPA), the following
audits are required:

* For the SSL trust bit, a CA and all subordinate CAs technically capable
of issuing server certificates [ref] must have all of the following:
  * WebTrust for CAs - v2.0
  * WebTrust for CAs - SSL Baseline with Network Security - v2.0
  * If applying for EV recognition, a WebTrust for CAs - EV SSL v.1.4.5+
* For the email trust bit, a CA and all subordinate CAs technically capable
of issuing email certificates [ref] must have all of the following:
  * WebTrust for CAs - v2.0

4.1.2.2 ETSI

If being audited ...

* For the SSL trust bit, a CA and all subordinate CAs ... must have all of
the following:
  * ETSI TS 102 042 v.2.3.1 DVCP, OVCP, PTC-BR  [note: This will shortly be
disallowed and replaced with