Re: Include Renewed Kamu SM root certificate

2017-03-16 Thread Kathleen Wilson via dev-security-policy
On Wednesday, March 15, 2017 at 9:56:25 AM UTC-7, Kathleen Wilson wrote:
> Thanks to those of you who have reviewed and commented on this request from 
> the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include 
> the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and 
> enable the Websites trust bit.


Thanks again to those of you who have reviewed this request, and to those of 
you who have participated in this discussion.

I am now closing this discussion, and I will update the bug to recommend 
approval of this request.

All further follow-up on this request should be in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1262809

Thanks,
Kathleen
___
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

2017-03-15 Thread Kathleen Wilson via dev-security-policy
Thanks to those of you who have reviewed and commented on this request from the 
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include the 
"TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable 
the Websites trust bit.

I believe that all of the questions and concerns that have been raised in this 
discussion have been resolved.

If there are no further questions or concerns about this request, then I will 
close this discussion and recommend approval in the bug.

Thanks,
Kathleen

___
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

2017-03-14 Thread Ryan Sleevi via dev-security-policy
On Tue, Mar 14, 2017 at 5:10 PM, tugba onder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Upon your request, we re-examined the current version of CAB BR (v.1.4.2)
> with our CPS document that describes our way of doing business. We did this
> work under these main headings; Identity Proofing, Technologies, Life Cycle
> Management, Certificate Profiles and Auditing Requirements. We read all
> related titles in CPS and CAB Br 1.4.2. Besides, so as not to miss any
> amendment item stated in section 1.2.2 (Relevant Dates) of CAB BR v1.4.2.
> we have stated Kamu SM approach for each item. The table is in this link:
>
> https://drive.google.com/file/d/0B3Yp-DkgL_W-OTR3cWxuOE84bmM/view?usp=
> sharing
>
>
> As a result, we could not notice any major difference between our
> practices and CAB BR v.1.4.2. The minor differences stated in the table
> will be fixed as soon as possible and be ready for the next audit. We hope
> that our examination meets your request and if there exists any other point
> you want to know please do not hesitate to ask.
>

Fantastic! I really appreciate you taking a second look, and I'm glad the
extent of the misalignment was limited to the previously identified
sections. I think that should be sufficient information to proceed.
___
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

2017-03-14 Thread tugba onder via dev-security-policy

Hi Ryan,

>My request was one of just taking a few days / a week to re-examine what

>the current BRs are, using your knowledge of your policies and practices, 
>and make sure that all methods are consistent. For example, the 64-bits of 
>entropy, the aligned-with-3.2.2.4.6 method of domain validation, etc. That 
>your auditor did not flag these implies that your auditor did not do that 
>level of analysis, but that's also not surprising given the role/function 
>of auditors (some auditors do this as part of their engagements, some 
>auditors do not, and generally both are seen as complying with the 
>necessary level of professional duty; just the ones that do are better 
>auditors, and the ones that don't may miss stuff that finds them removed as 
>trusted auditors in the future) 

>Because we've seen some CAs argue that "You didn't explicitly say we had to 
>follow X in the BRs", I wanted to avoid that situation, by just making sure 
>Kamu SM warrants that "We've read the BRs 1.4.2, we've examined our 
>policies and practices, we believe they're consistent and apply" (or "We 
>identified items X, Y, Z that we are fixing by doing A, B, C")



Upon your request, we re-examined the current version of CAB BR (v.1.4.2) with 
our CPS document that describes our way of doing business. We did this work 
under these main headings; Identity Proofing, Technologies, Life Cycle 
Management, Certificate Profiles and Auditing Requirements. We read all related 
titles in CPS and CAB Br 1.4.2. Besides, so as not to miss any amendment item 
stated in section 1.2.2 (Relevant Dates) of CAB BR v1.4.2. we have stated Kamu 
SM approach for each item. The table is in this link:

https://drive.google.com/file/d/0B3Yp-DkgL_W-OTR3cWxuOE84bmM/view?usp=sharing  
 

As a result, we could not notice any major difference between our practices and 
CAB BR v.1.4.2. The minor differences stated in the table will be fixed as soon 
as possible and be ready for the next audit. We hope that our examination meets 
your request and if there exists any other point you want to know please do not 
hesitate to ask.


Best regards,
___
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

2017-03-09 Thread Ryan Sleevi via dev-security-policy
On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Here, the part that needs to be taken care is "validate using at least one
> of the methods listed". Although we mentioned it in our previous response,
> I guess you missed it; we do not make verification just with respect to
> 3.2.2.4.6. For the further satisfaction of 3.2.2.4, we first apply
> 3.2.2.4.1, then 3.2.2.4.3 or 3.2.2.4.4 and then 3.2.2.4.5. Therefore, even
> if we do not implement 3.2.2.4.6 at all, we satisfy the condition "validate
> using at least one of the methods listed" in 3.2.2.4.
>

You're right, I did miss it / misunderstand. It's the first case I've heard
of CAs applying multiple checks in an additive fashion; I've only ever
heard of multiple layers being applied :)


> While we are implementing 3.2.2.4.6, we generate the "Required Website
> Content" concept described in ballot 169, including only the information
> that uniquely identifies the subscriber without a random value or request
> token. This practice comes from item 6 of section 3.2.2.4 of BR v1.3.7. The
> important thing that should be noted here is, the use of random value or
> request token is coming with ballot 169. The effective date for ballot 169
> was 1 March 2017, and the date on which we have received our audit report
> was December 2016, before the effective date.
>

Right, this was less a concern for misissuance, and more a concern for what
we've seen a number of CAs do - which is fail to stay up to date relative
to the changes. Your description of your validation after March 1 was
inconsistent with 3.2.2.4.6, which is why I flagged it. If you've already
validated the domain using a different form permitted, and 3.2.2.4.6 is
just a secondary layer of validation, then I agree, it's no concern.

It's only if you use the process you describe as the primary validation -
if so, it must conform to 3.2.2.4.6, or you must use some other form of
primary validation.


> If you consider any other inconsistencies, please inform us, we will
> appreciate it.


My request was one of just taking a few days / a week to re-examine what
the current BRs are, using your knowledge of your policies and practices,
and make sure that all methods are consistent. For example, the 64-bits of
entropy, the aligned-with-3.2.2.4.6 method of domain validation, etc. That
your auditor did not flag these implies that your auditor did not do that
level of analysis, but that's also not surprising given the role/function
of auditors (some auditors do this as part of their engagements, some
auditors do not, and generally both are seen as complying with the
necessary level of professional duty; just the ones that do are better
auditors, and the ones that don't may miss stuff that finds them removed as
trusted auditors in the future)

Because we've seen some CAs argue that "You didn't explicitly say we had to
follow X in the BRs", I wanted to avoid that situation, by just making sure
Kamu SM warrants that "We've read the BRs 1.4.2, we've examined our
policies and practices, we believe they're consistent and apply" (or "We
identified items X, Y, Z that we are fixing by doing A, B, C")
___
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

2017-03-09 Thread tugba onder via dev-security-policy
Hi Ryan,
 
>Right, but the reason I highlighted this is that the audit noted 
>conformance to v1.4.1, but the process you described wasn't consistent with 
>v1.4.1. It's understandable that the auditable controls for 1.4.1 have not 
>been developed, so I'm not particularly surprised that this wouldn't have 
>been called out in the audit, but it did highlight a divergence between the 
>statement as to how you validate domains and the stated compliance.
 
 
- Yes, our annual audit report states that we are in compliance with CAB Forum 
1.4.1 and in CAB Forum v1.4.1 section 3.2.2.4 it states that: 
 
"The CA SHALL confirm that as of the date the Certificate issues, either the CA 
or a Delegated Third Party has validated each Fully-Qualified Domain Name 
(FQDN) listed in the Certificate using at least one of the methods listed 
below." 
 
Here, the part that needs to be taken care is "validate using at least one of 
the methods listed". Although we mentioned it in our previous response, I guess 
you missed it; we do not make verification just with respect to 3.2.2.4.6. For 
the further satisfaction of 3.2.2.4, we first apply 3.2.2.4.1, then 3.2.2.4.3 
or 3.2.2.4.4 and then 3.2.2.4.5. Therefore, even if we do not implement 
3.2.2.4.6 at all, we satisfy the condition "validate using at least one of the 
methods listed" in 3.2.2.4.
 
While we are implementing 3.2.2.4.6, we generate the "Required Website Content" 
concept described in ballot 169, including only the information that uniquely 
identifies the subscriber without a random value or request token. This 
practice comes from item 6 of section 3.2.2.4 of BR v1.3.7. The important thing 
that should be noted here is, the use of random value or request token is 
coming with ballot 169. The effective date for ballot 169 was 1 March 2017, and 
the date on which we have received our audit report was December 2016, before 
the effective date. 
 
Although we satisfy 3.2.2.4 by implementing multiple choices at the same time, 
we believe, not necessarily but additionally implemented current version of 
3.2.2.4.6, even if it is not fully consistent with the latest version, will 
bring more security than the case it was never implemented. But we will also 
fix it. 
 
Similarly, at the time audit report was produced, Section 10.3 ("End Entity 
SSL Certificate Template") was not consistent with Section 1 (current BRs). 
 
Throughout the Mozilla Root Certificate Program, we have tried to fulfill all 
requests with great appreciation. We believe this program, its partners, public 
reviewers and also CA communications serve in the name of ensuring the 
security, applicability, and interoperability by forcing CA/B Forum BR and make 
CAs' fix their inconsistencies, if there exists, according to the updated BRs'. 
We have considered Andrew's warning in this manner and deployed early 
implemented but not deployed 64-bit random number in serial instead of early 
deployed 32-bit. If you consider any other inconsistencies, please inform us, 
we will appreciate it.
___
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

2017-03-08 Thread Ryan Sleevi via dev-security-policy
On Wed, Mar 8, 2017 at 9:56 AM, tugba onder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 3.2.2.4.6: Applicant representative is requested to change a web page
> hosted in certificate requested domain. That change is done by serving the
> file which we sent for this purpose. This method means Request-upon-change
> for us but until the next audit, we plan to use the request token method
> which is indicated in CAB BR section 3.2.2.4.6.
>

Right, but the reason I highlighted this is that the audit noted
conformance to v1.4.1, but the process you described wasn't consistent with
v1.4.1. It's understandable that the auditable controls for 1.4.1 have not
been developed, so I'm not particularly surprised that this wouldn't have
been called out in the audit, but it did highlight a divergence between the
statement as to how you validate domains and the stated compliance.

To me, it signaled that there may be other places where the asserted
compliance is to v1.4.1, but the absence of audited criteria relative to
the changes in v.1.4.1 may not have actually been implemented. The serial
number is another example of that - where the practice and statement
diverged.

Here's another example: Section 2.2 of the Baseline Requirements requires
that the CA SHALL publicly give effect to these Requirements and represent
that it will adhere to the latest published version. (and then describes an
illustrative examples of fulfilling that obligation)

Rather than including that clause, Section 1 of your CPS states "Kamu SM
conforms to the updated versions of the standard ... and CA/Browser Forum
Baseline Requirements (BR) for the Issuance and Management of Publicly
Trusted Certificates". This is all perfectly fine and compliant with
Section 2.2 - you've made the statement and represented adherence.

However, the matters of both serial numbers and domain validation (as
described) are examples of non-adherence to that Section 1 of your CPS,
because the procedures used weren't consistent with Kamu SM conforming to
the updated version of the standard.

So that's why I suggested that you carefully examine the updated version
for any other divergences. For example, the Mozilla community would not
have been aware of the non-compliance to 3.2.2.4.6 had you not shared
details, which is why Andrew originally requested them. There's the
possibility of other areas of non-compliance, hence the similar request to
fully examine the Baseline Requirements and double check to make sure all
policies/processes are consistent - since Section 1 of your CPS says they
will be, but it was determined they weren't.

Once you've done that examination and identified any other issues, I was
suggesting sharing those. That way, the community can know that we're
"starting" from a good and compliant state, and then moving forward. It
also avoids any issues where, if three years down the road we find
something was overlooked, there's no way to excuse that - as there was the
opportunity now to examine and comply.

As it stands right now, Section 3.2.2 is in conflict with Section 1. I
think that needs to be fixed.



> Prior to CA/B BR v1.3.7, the certificate serial numbers are required to
> contain at least 20 bits of entropy. We were satisfying this condition by
> adding 32 bits entropy to the serial number. We had implemented the 64-bit
> entropy restriction beginning with v1.3.7 which went into effect on
> September 30th, but the system is left to add 32-bit entropy. As a result
> of Andrew's warnings, we have quickly deployed 64-bit random generator
> implementation and updated the test web page certificate to ensure this.
> There is no active certificate that we have issued since the process of our
> new root application has not been completed. Certificates that will issue
> after our application process is completed will provide this feature.
>

Similarly, at the time audit report was produced, Section 10.3 ("End Entity
SSL Certificate Template") was not consistent with Section 1 (current BRs).

With your current update, this is resolved, although the matter still
remains for Section 3.2.2 above.

Further, given these, I'm suggesting it would be good to review your
policies and practices for consistency with/adherence to Section 1 (or,
more aptly, to the Baseline Requirements), share if there are any further
inconsistencies identified, and then continue with the discussions :)
___
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

2017-03-08 Thread tugba onder via dev-security-policy
Hi Kathleen,

Our updated CP/CPS documents in Turkish and in English are now in our web page. 
Here are the related links:


http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf  

http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf 
___
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

2017-03-08 Thread tugba onder via dev-security-policy
Hi Ryan,

Firstly, thank you for spending time and reviewing our work. Our answer to the 
two points you have stated is the following.


1) Domain Validation Methods 

> 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. 

Our audit report was based on version 1.4.1 of the CA/Browser Forum’s Baseline 
Requirements and so we have reviewed this version of BR and planned our domain 
authorization validation method with respect to it. In chapter 3.2.2.4 of BR it 
was said that implementing at least one of the methods from 3.2.2.4.1 to 
3.2.2.4.10 is enough for validation but we are implementing  3.2.2.4.1, 
3.2.2.4.3 or 3.2.2.4.4, 3.2.2.4.5 and 3.2.2.4.6 for promoting validation. Note 
that, 3.2.2.4.5 and 3.2.2.4.6 are still active validation methods stated in 
v1.4.2. Let me briefly explain what we are doing in each step.

3.2.2.4.1: We are issuing OV SSL certificates only to government agencies and 
taking the application with the official letter containing the government 
agency seal. Nevertheless, we confirm it directly by communicating with nic.tr. 
"nic.tr" is the top level domain of Turkey, and holds domain authorization 
documents for all public institutions. The applicant representative for the 
certificate application on behalf of the government agency is determined by 
official correspondence between the Kamu SM and the government agency. Then it 
is checked that the applicant representative of certificate application is the 
person determined by official correspondence.  

3.2.2.4.3 or 3.2.2.4.4: The applicant representative identified in 3.2.2.4.1 is 
contacted by phone or e-mail and the certificate request is confirmed. 

3.2.2.4.5: Since we serve government agencies, the government agency that owns 
the domain can not change, but the applicant representative who applies on 
behalf of the agency can change. In this case, the government agency shall 
indicate to us the new representative with the official document as it was 
before, and it is required that the applicant representative in the certificate 
application document must be same with the official documented person.

3.2.2.4.6: Applicant representative is requested to change a web page hosted in 
certificate requested domain. That change is done by serving the file which we 
sent for this purpose. This method means Request-upon-change for us but until 
the next audit, we plan to use the request token method which is indicated in 
CAB BR section 3.2.2.4.6. 


Detailed verification steps are specified in CPS section 3.2.2.


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

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. 
>all publicly trusted CAs since 30 September 2016. 

Prior to CA/B BR v1.3.7, the certificate serial numbers are required to contain 
at least 20 bits of entropy. We were satisfying this condition by adding 32 
bits entropy to the serial number. We had implemented the 64-bit entropy 
restriction beginning with v1.3.7 which went into effect on September 30th, but 
the system is left to add 32-bit entropy. As a result of Andrew's warnings, we 
have quickly deployed 64-bit random generator implementation and updated the 
test web page certificate to ensure 

Re: Include Renewed Kamu SM root certificate

2017-03-07 Thread 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: Include Renewed Kamu SM root certificate

2017-03-07 Thread 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: Include Renewed Kamu SM root certificate

2017-03-07 Thread 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: Include Renewed Kamu SM root certificate

2017-03-07 Thread 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: Include Renewed Kamu SM root certificate

2017-03-03 Thread Andrew R. Whalley via dev-security-policy
Hello,

I've read though the English language version of CP/CPS dated March 30,
2016 version 1 and made the following notes:

No version history at the front of the document.  This not required, but is
evidence of good document change management and is a useful reference to
see what's changed when coming back to reviewing docs.

1.2 Document Name and Identification

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

3.1.5 Uniqueness of Names

CN Field: Note that use of the common name is deprecated.

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.

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."

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.

7.2.2 CRL and CRL Entry Extensions

Though optional, CRL reason codes are encouraged.

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.

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."

--

Overall the document was clear and well written and didn't contain anything
too worrying.

Cheers,

Andrew

On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilson 
wrote:

> This request from the Government of Turkey, Kamu Sertifikasyon Merkezi
> (Kamu SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum
> 1” root certificate, and enable the Websites trust bit. This SHA-256 root
> certificate will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika
> Hizmet Sağlayıcısı - Sürüm 3” root certificate that was included via
> Bugzilla Bug #381974. The old root certificate expires in August, 2017.
>
> Note that the CA has indicated that since Kamu SM is a government CA , the
> CA only issues certificates to government-owned domains (restricted by
> these TLDs: gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr
> and org.tr ) and does not issue any certificates outside of Turkey. So,
> Mozilla may constrain this root to those domains.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1262809
>
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
>
> Summary of Information Gathered and Verified:
> https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8738995
> http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer
>
> * The primary document, the SSL CP/CPS, is provided in both Turkish and
> English.
>
> Document Repository: http://depo.kamusm.gov.tr/ilke/
> SSL CP/CPS:
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf
>
> * CA Hierarchy: This root certificate has internally operated subordinate
> CAs that issue SSL end-entity certificates.
>
> * This request is to turn on the Websites trust bit.
> ** SSL CP/CPS section 3.2.2: Authentication of government agencies having
> requested OV SSL certificate from Kamu SM shall be performed by way of
> verification from official correspondences made between Kamu SM, relevant
> government agency and relevant channels of domain ownership (e.g., nic.tr
> ).
> All applications made to Kamu SM shall be supported with legal documents
> that shall authenticate the following information and some of this
> information shall be included within the Subject field:
> …...
> Residence address of applicant government agency is taken as a basis in OV
> SSL applications. Legal status, identification information, domain name,
> organization representative, presence of application, CSR information and
> other similar information of applicant should be verified. Since the
> organization authentication is of high importance while issuing OV SSL
> 

Include Renewed Kamu SM root certificate

2017-02-02 Thread Kathleen Wilson
This request from the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu 
SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1” root 
certificate, and enable the Websites trust bit. This SHA-256 root certificate 
will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika Hizmet 
Sağlayıcısı - Sürüm 3” root certificate that was included via Bugzilla Bug 
#381974. The old root certificate expires in August, 2017.

Note that the CA has indicated that since Kamu SM is a government CA , the CA 
only issues certificates to government-owned domains (restricted by these TLDs: 
gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr and org.tr ) and 
does not issue any certificates outside of Turkey. So, Mozilla may constrain 
this root to those domains.

The request is documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 

And in the pending certificates list: 
https://wiki.mozilla.org/CA:PendingCAs 

Summary of Information Gathered and Verified: 
https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967

* Root Certificate Download URL: 
https://bugzilla.mozilla.org/attachment.cgi?id=8738995
http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer

* The primary document, the SSL CP/CPS, is provided in both Turkish and English.

Document Repository: http://depo.kamusm.gov.tr/ilke/ 
SSL CP/CPS: 
http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf
http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf 

* CA Hierarchy: This root certificate has internally operated subordinate CAs 
that issue SSL end-entity certificates. 

* This request is to turn on the Websites trust bit. 
** SSL CP/CPS section 3.2.2: Authentication of government agencies having 
requested OV SSL certificate from Kamu SM shall be performed by way of 
verification from official correspondences made between Kamu SM, relevant 
government agency and relevant channels of domain ownership (e.g., nic.tr).
All applications made to Kamu SM shall be supported with legal documents that 
shall authenticate the following information and some of this information shall 
be included within the Subject field: 
…...
Residence address of applicant government agency is taken as a basis in OV SSL 
applications. Legal status, identification information, domain name, 
organization representative, presence of application, CSR information and other 
similar information of applicant should be verified. Since the organization 
authentication is of high importance while issuing OV SSL certificate, all 
information to be included in subject field of the certificate shall be 
verified as set forth in CA/B Forum Baseline Requirements document.
Verification procedures of Kamu SM shall be performed in compliance with the 
following steps:
• Head office address of the government agency requesting certificate and 
organization representative having applied for certificate shall be verified 
based on the legal documents. In addition to this, that
organization representative executing application procedures on behalf of the 
agency  requesting certificate is entitled to apply for on behalf of the 
organization shall be verified with legal documents.
• Phone numbers submitted in application documents by the organization 
representative having applied for certificate shall be checked whether they 
match with legal records or not. The organization representative having applied 
for certificate shall be called from phone numbers verified accordingly and is 
requested to verify its application.
• It should be verified that e-mail address declared by organization 
representative having
applied for certificate during application is sent by the organization 
representative. This verification procedure shall be confirmed by a 
verification e-mail sent to e-mail address of organization representative.
• WHOIS records pertinent to domain name specified in certificate application 
shall be verified via “www.nic.tr”
• As a principle, applicant should have exclusive right and authority in regard 
to use of relevant domain name which is included in the certificate. This 
exclusive right and authority must be granted by registered owner or 
organization of domain name.
• Continuity of operation should be verified with a current official document 
to be submitted by organization representative or the persons authorized to 
issue an official document on behalf of government agencies.

* EV Policy OID: Not Requesting EV treatment 

* Test Website: https://testssl.kamusm.gov.tr/ 

* CRL URLs: 
http://depo.kamusm.gov.tr/ssl/SSLSIL.S1.crl
http://depo.kamusm.gov.tr/ssl/SSLKOKSIL.S1.crl
SSL CP/CPS Section 4.9.7: CRL for end-entity certs is valid for maximum of 36 
hours.

* OCSP URLs
http://ocspssls1.kamusm.gov.tr
http://ocspsslkoks1.kamusm.gov.tr

* Audit: Annual audits are performed by Information and Communications 
Technologies Authority (ICTA) according to the ETSI TS 102 042 v2.4.1 criteria. 
Audit Statement: