Re: ccadb.org

[Jonathan Rudenberg via dev-security-policy]

Hrm, I didn’t realize it had been restricted. The gist is that bug is closed as 
incomplete as of three months ago and there is a new bug that I don’t have 
access to: https://bugzilla.mozilla.org/show_bug.cgi?id=1409786


> On Jan 29, 2018, at 20:02, James Burton  wrote:
> 
> Hi Jonathan,
> 
> I haven't got the required permission to access bug 1376996. 
> 
> Thank you,
> 
> James 
> 
> 
> On Tue, Jan 30, 2018 at 12:57 AM, Jonathan Rudenberg  
> wrote:
> 
> > On Jan 29, 2018, at 19:48, James Burton via dev-security-policy 
> >  wrote:
> >
> > I was doing research on the ccadb.org site and was surprised to find that
> > the site is running only in HTTP and is not using HTTPS.
> 
> There is already a bug about this: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1376996
> 

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

Re: ccadb.org

[James Burton via dev-security-policy]

 Hi Jonathan,

I haven't got the required permission to access bug 1376996.

Thank you,

James


On Tue, Jan 30, 2018 at 12:57 AM, Jonathan Rudenberg 
wrote:

>
> > On Jan 29, 2018, at 19:48, James Burton via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > I was doing research on the ccadb.org site and was surprised to find
> that
> > the site is running only in HTTP and is not using HTTPS.
>
> There is already a bug about this: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1376996
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ccadb.org

[Jonathan Rudenberg via dev-security-policy]

> On Jan 29, 2018, at 19:48, James Burton via dev-security-policy 
>  wrote:
> 
> I was doing research on the ccadb.org site and was surprised to find that
> the site is running only in HTTP and is not using HTTPS.

There is already a bug about this: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1376996
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

ccadb.org

[James Burton via dev-security-policy]

I was doing research on the ccadb.org site and was surprised to find that
the site is running only in HTTP and is not using HTTPS. Now, I understand
that GitHub pages don't support HTTPS for custom domains but you could
always use CloudFlare for HTTPS support in the meantime until GitHub
enables HTTPS for custom domains.

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

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

The email has been sent, and we've published a blog post:

https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/

On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote:
> You can find a link to the final version of the survey at
> https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
> 
> We're planning to send this out to all CAs in the Mozilla program later
> today. The deadline for responses has been set to 9-February.
> 
> Thanks to everyone who contributed to this effort.
> 
> - Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.

Thanks to everyone who contributed to this effort.

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

Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

Thanks for pointing this out Ryan and Dimitris. You are both correct: we
should direct Taiwan GRCA to change their request from including the root
to including only the subordinate CAs that comply with the Mozilla policy.
The option of adding the non-compliant subordinate CAs to OneCRL does not
meet our policy.

I will determine what additional information we need to change this
inclusion request and will add it to bug 1065896. I then expect to place
this request on hold until we receive the updated information.


- Wayne

On Sun, Jan 28, 2018 at 10:53 PM, Dimitris Zacharopoulos 
wrote:

>
>
> On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
>
> Has any consideration been given to adopt a similar policy as discussed
> with the Government of Korea application 
> -https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38
>
>
>
> Just to avoid any possible mis-reading of:
>
> "If you have intermediates for which you cannot disclose, whether it be for 
> personal, operational, or legal reasons, then an appropriate solution, 
> consistent with Mozilla CA Certificate Policy, is to use Technically 
> Constrained Subordinate CAs - as defined within the Baseline Requirements and 
> as reflected within the Mozilla policy. Such TCSCAs are technically limited 
> from the issuance of TLS certificates, and by doing so, are allowed to be 
> operated in a way that is not consistent with the Baseline Requirements nor 
> compliant with Mozilla Policy."
>
>
> Currently, the Baseline Requirements (section 7.1.5) allow for TCSCAs to
> issue TLS Certificates, by requiring the nameConstraints extension,
> limiting the issuance to specific Domain Names and Organizations. These
> TCSCAs MUST follow the Baseline Requirements, with the exceptions provided
> for these types of TCSCAs.
>
> As far as the Mozilla Policy is concerned, if a TCSCAs is technically
> capable of issuing a Certificate for TLS authentication or S/MIME, it MUST
> comply with the Mozilla policy, with the exceptions provided for TCSCAs.
> Section 1.1 of the Mozilla Policy is fairly clear on the scope of the
> policy. If there are possibly more exceptions, it should probably be
> updated to reflect these cases.
>
>
> Dimitris.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Yair,

Will you please provide a detailed response to each of Ryan's points? Also,
please provide the specific version of the RSA Certificate Manager in use
by ComSign.

Thanks,

Wayne

On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan,
>
> I noticed that your notes refer to a previous version of the CPS and not
> the current one
> here is a link to the current version which is 4.1.
> https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf
>
> About the CA software – we are now under auditing for our new Microsoft CA
> and it will take at least 4-6 months until it will be approved for full
> usage.
> We do understand that the Microsoft CA is much better and secure but we
> still ask of you to approve our root considering the fact we are at the
> last steps of implementing the Microsoft CA
> We are under heavy pressure from customers that are using Mozilla to allow
> them SSL and we were waiting too much until we reached this point
> Even if we receive that you acknowledged for 6 month to continue the
> current CA – it is good for us.
>
> Yair
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

Hi Ryan,

I noticed that your notes refer to a previous version of the CPS and not the 
current one 
here is a link to the current version which is 4.1.
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf

About the CA software – we are now under auditing for our new Microsoft CA and 
it will take at least 4-6 months until it will be approved for full usage.
We do understand that the Microsoft CA is much better and secure but we still 
ask of you to approve our root considering the fact we are at the last steps of 
implementing the Microsoft CA 
We are under heavy pressure from customers that are using Mozilla to allow them 
SSL and we were waiting too much until we reached this point
Even if we receive that you acknowledged for 6 month to continue the current CA 
– it is good for us.

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

Re: Certigna Root Renewal Request

[josselin.allemandou--- via dev-security-policy]

Le jeudi 27 avril 2017 15:22:27 UTC+2, Aaron Wu a écrit :
> This request from the Dhimyotis/Certigna is to include the SHA-256 ‘Certigna 
> Root CA’ certificate and turn on the Websites and Email trust bits. This root 
> certificate will eventually replace the SHA-1 ‘Certigna’ root certificate 
> that was included via Bugzilla #393166. 
> 
> Dhimyotis, t e name of the company,  is a commercial CA and Certigna is the 
> brand for their certificates.
> 
> The new ‘Certigna Root CA’ has 7 internally operated subordinated CAs : 
> - Identity CA : encipherment, authentication and/or digitally-signed email 
> - Identity Plus CA : authentication and/or digitally-signed email 
> - Entity CA : seal (EKU : emailProtection or timeStamping) 
> - Entity Code signing CA : seal (EKU : codeSigning) 
> - Services CA : SSL (EKU : authServer or authClient) 
> - Wild CA : SSL (EKU : authServer and authClient) 
> - FR03 : Seal
> 
> The request is documented in the following bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> 
> BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=8861810
> 
> Summary of Information Gathered and Verified: 
> https://bugzilla.mozilla.org/attachment.cgi?id=8862251
> 
> * Root Certificate Download URL: 
> http://autorite.dhimyotis.com/certignarootca.der
> 
> * The CP documents are in French and translated into English.
> 
> Document Repository: https://www.certigna.fr/autorites/index.xhtml
> CP - Root CA: http://politique.certigna.fr/en/PCcertignarootca.pdf
> CP - Services CA: http://politique.certigna.fr/en/PCcertignaservicesca.pdf
> CP - Wild CA:  http://politique.certigna.fr/en/PCcertignawildca.pdf
> 
> * CA Hierarchy
> Certificate Hierarchy Diagram  : https://www.certigna.fr/autorites/index.xhtml
> 
> * The request is to enable the Websites and Email trust bits
> 
> ** Section 4.2.1 of CP - Services CA and CP - Wild CA : "The verification of 
> the FQDN and the entity holding it is achieved using "WHOIS"websites and of 
> the AFNIC website if applicable. A legal representative of the entity which 
> hold the domain must formally designate the RC and its entity in a domain 
> authorization document signed by that representative (request form or 
> specific form provided by the CA)."
> *** This corresponds to BR section 3.2.2.4.5 Domain Authorization Document
> 
> * EV Policy OID: Not Requesting EV treatment 
> 
> * Test Websites
> Valid certificate : https://valid.servicesca.dhimyotis.com 
> Expired certificate: https://expired.servicesca.dhimyotis.com 
> Revoked certificate: https://revoked.servicesca.dhimyotis.com 
> 
> * CRL URLs: 
> Root CAs: http://crl.certigna.fr/certignarootca.crl
> Subordinated CAs : https://www.certigna.fr/autorites/index.xhtml 
> Frequency of updating CRL is described in chapters 2.3 and 4.9.6 of the CP/CPS
> 
> * OCSP URLs:
> URI for SSL certificates : http://servicesca.ocsp.certigna.fr/
> Frequency of updating OCSP is described in chapter 4.9.6 of the CP/CPS. 
> The maximum time elapsing from the revocation of an end entity or CA 
> certificate until OCSP responders are updated to reflect that revocation : 1 
> hour
> 
> * Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 
> / 101 456 criteria. 
> https://bug1265683.bmoattachments.org/attachment.cgi?id=8856978
> 
> * Potentially Problematic Practices : None Noted
> (https://wiki.mozilla.org/CA:Problematic_Practices)
> 
> This begins the discussion of the request from Dhimyotis/Certigna to include 
> the SHA-256 ‘Certigna Root CA’ certificate and turn on the Websites and Email 
> trust bits. 
> 
> Aaron

In order to finalize our integration request, I would like to inform you of new 
information: 
- We have published all our CPs and CPSs updated on 25/01/2017 in French and 
English version : https://www.certigna.fr/autorites/index.xhtml
- We have updated our integration ticket 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1265683), because under this 
authority, we now issue QCP-w/EV qualified certificates. We have updated the 
Attestation letter and the document "Initial Information Gathering Document"

Could you ensure that the Certigna Root CA integration can enable EV 
recognition for this root authority.

We remain at your disposal for any further information.

Thanking you in advance for your help.

Best regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy