Re: Undisclosed CA certificates

[Dimitris Zacharopoulos]

Hi Peter,

Here is the wiki reference that states which Intermediate CAs should be
included in salesforce:

https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

I think Kathleen has captured all cases and the instructions are clear.
It should also be straightforward to script and get a perfect match of
what should be included in salesforce.


Best regards,
Dimitris.



On 28/4/2016 7:25 πμ, Peter Bowen wrote:
> Here is a Google Spreadsheet without the subordinates that have EKU
> restrictions.  I didn't match to SalesForce, so most of these are
> probably already in there.
>
> https://docs.google.com/spreadsheets/d/14lO33nW-tTN86Vq_urmI6IAIWRPZgd1KKfzvrLk5TZQ/edit?usp=sharing
>
> On Wed, Apr 27, 2016 at 6:11 PM, Wayne Thayer  wrote:
>> My understanding is that CAs are not to add CAs with an EKU extension that 
>> doesn't include anyEKU or serverAuth, but this list appears to include those?
>>
>> Thanks,
>>
>> Wayne
>>
>>> -Original Message-
>>> From: dev-security-policy [mailto:dev-security-policy-
>>> bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Richard
>>> Barnes
>>> Sent: Wednesday, April 27, 2016 5:16 PM
>>> To: mozilla-dev-security-pol...@lists.mozilla.org
>>> Cc: Zakir Durumeric 
>>> Subject: Undisclosed CA certificates
>>>
>>> Dear CAs,
>>>
>>> As you guys are working toward the June 30 deadline for disclosing
>>> intermediate certificates in SalesForce, I thought I would share some notes
>>> on the undisclosed certificates that we're seeing, so that you can make sure
>>> you get them all uploaded.
>>>
>>> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
>>> certificates that have been observed in Censys scans of the Internet, and
>>> noted which of those certificates are not in SalesForce so far.
>>>
>>> I've posted the list here for your reference:
>>> https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52
>>>
>>> Note that this list is static, so if you add a certificate to SalesForce, 
>>> it won't
>>> instantly disappear from this list.  But we'll try to update it every so 
>>> often as
>>> we approach June 30, and will notify this list when we do.
>>>
>>> Cheers,
>>> --Richard
>>> ___
>>> 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
> ___
> 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: Undisclosed CA certificates

[Peter Bowen]

Here is a Google Spreadsheet without the subordinates that have EKU
restrictions.  I didn't match to SalesForce, so most of these are
probably already in there.

https://docs.google.com/spreadsheets/d/14lO33nW-tTN86Vq_urmI6IAIWRPZgd1KKfzvrLk5TZQ/edit?usp=sharing

On Wed, Apr 27, 2016 at 6:11 PM, Wayne Thayer  wrote:
> My understanding is that CAs are not to add CAs with an EKU extension that 
> doesn't include anyEKU or serverAuth, but this list appears to include those?
>
> Thanks,
>
> Wayne
>
>> -Original Message-
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Richard
>> Barnes
>> Sent: Wednesday, April 27, 2016 5:16 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Cc: Zakir Durumeric 
>> Subject: Undisclosed CA certificates
>>
>> Dear CAs,
>>
>> As you guys are working toward the June 30 deadline for disclosing
>> intermediate certificates in SalesForce, I thought I would share some notes
>> on the undisclosed certificates that we're seeing, so that you can make sure
>> you get them all uploaded.
>>
>> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
>> certificates that have been observed in Censys scans of the Internet, and
>> noted which of those certificates are not in SalesForce so far.
>>
>> I've posted the list here for your reference:
>> https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52
>>
>> Note that this list is static, so if you add a certificate to SalesForce, it 
>> won't
>> instantly disappear from this list.  But we'll try to update it every so 
>> often as
>> we approach June 30, and will notify this list when we do.
>>
>> Cheers,
>> --Richard
>> ___
>> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Undisclosed CA certificates

[Peter Bowen]

On Wed, Apr 27, 2016 at 7:36 PM, Richard Barnes  wrote:
> On Wed, Apr 27, 2016 at 8:41 PM, Peter Bowen  wrote:
>>
>> As far as I can tell, SalesForce does not have a way to show multiple
>> certificates for one CA.  So it is entirely possible to have all CAs
>> disclosed but not have all CA certificates disclosed. (Some of the
>> edges in the graph may not be present)
>>
>> Does disclosing all CAs meet the policy or does there need to be an
>> update to support disclosing additional certificates?
>
>
> Policy saith:
> """
> All certificates that are capable of being used to issue new certificates,
> and which directly or transitively chain to a certificate included in
> Mozilla’s CA Certificate Program, MUST be operated in accordance with
> Mozilla’s CA Certificate Policy and MUST either be technically constrained
> or be publicly disclosed and audited.
> """
>
> That reads to me to say that all certificates that might be used in building
> a chain to a trusted root need to be disclosed, not just one per CA.

Does this also include certificates that are revoked?

The test is something like:

(extensions:basicConstraints:CA == TRUE ||
extensions:keyUsage:keyCertSign == TRUE || extensions:keyUsage:crLSign
== TRUE) && ((NOT extensions.include(extendedKeyUsage)) ||
extensions:extendedKeyUsage.include(anyEKU) ||
extensions:extendedKeyUsage.include(serverAuth)) && notAfter >= NOW &&
(NOT TechnicallyConstrained)

> If our SalesForce system doesn't support multiple certs per CA, we might
> have to come with a work-around until it does.

Your SalesForce system seems to assume that a certificate and CA are
equal instead of treating CAs as nodes and certificates as edges in a
directed graph.  I'm not sure how to best disclose additional
certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Undisclosed CA certificates

[Richard Barnes]

On Wed, Apr 27, 2016 at 8:41 PM, Peter Bowen  wrote:

> As far as I can tell, SalesForce does not have a way to show multiple
> certificates for one CA.  So it is entirely possible to have all CAs
> disclosed but not have all CA certificates disclosed. (Some of the
> edges in the graph may not be present)
>
> Does disclosing all CAs meet the policy or does there need to be an
> update to support disclosing additional certificates?
>

Policy saith:
"""
All certificates that are capable of being used to issue new certificates,
and which directly or transitively chain to a certificate included in
Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s
CA Certificate Policy
 and MUST
either be *technically constrained* or be *publicly disclosed and audited*.
"""

That reads to me to say that all certificates that might be used in
building a chain to a trusted root need to be disclosed, not just one per
CA.

If our SalesForce system doesn't support multiple certs per CA, we might
have to come with a work-around until it does.

--Richard



>
> On Wed, Apr 27, 2016 at 5:19 PM, Richard Barnes 
> wrote:
> > I think it was pulled this afternoon, but I don't know if SalesForce
> updates
> > the report.
> >
> > In any case, this is being provided as a guide to CA to help them make
> sure
> > they get everything, not to place blame on anyone for being on the
> list.  Of
> > course, as we get closer to June 30...
> >
> > On Wed, Apr 27, 2016 at 8:17 PM, Peter Bowen  wrote:
> >>
> >> When was the Salesforce data pulled?  I see several in that list I
> >> entered a while ago.
> >>
> >> On Wed, Apr 27, 2016 at 5:15 PM, Richard Barnes 
> >> wrote:
> >> > Dear CAs,
> >> >
> >> > As you guys are working toward the June 30 deadline for disclosing
> >> > intermediate certificates in SalesForce, I thought I would share some
> >> > notes
> >> > on the undisclosed certificates that we're seeing, so that you can
> make
> >> > sure you get them all uploaded.
> >> >
> >> > Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of
> CA
> >> > certificates that have been observed in Censys scans of the Internet,
> >> > and
> >> > noted which of those certificates are not in SalesForce so far.
> >> >
> >> > I've posted the list here for your reference:
> >> > https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52
> >> >
> >> > Note that this list is static, so if you add a certificate to
> >> > SalesForce,
> >> > it won't instantly disappear from this list.  But we'll try to update
> it
> >> > every so often as we approach June 30, and will notify this list when
> we
> >> > do.
> >> >
> >> > Cheers,
> >> > --Richard
> >> > ___
> >> > 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

Undisclosed CA certificates

[Richard Barnes]

Dear CAs,

As you guys are working toward the June 30 deadline for disclosing
intermediate certificates in SalesForce, I thought I would share some notes
on the undisclosed certificates that we're seeing, so that you can make
sure you get them all uploaded.

Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
certificates that have been observed in Censys scans of the Internet, and
noted which of those certificates are not in SalesForce so far.

I've posted the list here for your reference:
https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52

Note that this list is static, so if you add a certificate to SalesForce,
it won't instantly disappear from this list.  But we'll try to update it
every so often as we approach June 30, and will notify this list when we do.

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

Japan GPKI Root Renewal Request

[Kathleen Wilson]

This request by the Government of Japan, Ministry of Internal Affairs and 
Communications, is to include the GPKI 'ApplicationCA2 Root' certificate and 
enable the Websites trust bit. This new root certificate has been created in 
order to comply with the Baseline Requirements, and will eventually replace the 
'ApplicationCA - Japanese Government' root certificate that was included via 
Bugzilla Bug #474706. Note that their currently-included root certificate 
expires in 2017, and will be removed via Bugzilla Bug #1268219.

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

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

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8673399

Noteworthy points:

* The primary documents are the Root and SubCA CP/CPS, provided in Japanese and 
English.

Document Repository (Japanese):
http://www.gpki.go.jp/apca/cpcps/index.html
Document Repository (English):
https://www2.gpki.go.jp/apca2/apca2_eng.html
Root CP/CPS:
https://www2.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf
SubCA CP/CPS:
https://www2.gpki.go.jp/apca2/cpcps/cpcps_sub_eng.pdf

* CA Hierarchy: This root certificate has one internally-operated subordinate 
CA that issues end-entity certificates for SSL and code signing.

* This request is to turn on the Websites trust bit.

SubCA CP/CPS section 3.2.2, Authentication of organization identity
As for the application procedure of a server certificate, ... the LRA shall 
verify the authenticity of the organization to which the subscriber belongs 
according to comparing with organizations which were written in the application 
by directory of government officials that the Independent Administrative Agency 
National Printing Bureau issued.

SubCA CP/CPS section 3.2.3, Authentication of individual identity
As for the application procedure of a server certificate, ... the LRA shall 
verify the authenticity of the subscriber according to comparing with name, 
contact, etc. which were written in the application by directory of government 
officials that the Independent Administrative Agency National Printing Bureau 
issued.
The LRA also check the intention of an application by a telephone or meeting.

SubCA CP/CPS section 4.1.2, Enrollment process and responsibilities
(1) Server certificate
The subscriber shall apply accurate information on their certificate 
applications to the LRA.
The LRA shall confirm that the owner of the domain name written as a name(cn) 
of a server certificate in the application form belongs to Ministries and 
Agencies who have jurisdiction over LRA, or its related organization with the 
thirdparty databases and apply accurate information to the Application CA2(Sub).

* Mozilla Applied Constraints: This CA has indicated that the CA hierarchy may 
be constrained to the *.go.jp domain.

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8673392
https://www.gpki.go.jp/apca2/APCA2Root.der

* EV Policy OID: Not requesting EV treatment

* Test Website:
https://www2.gpki.go.jp/apca2/apca2_eng.html

* CRL URLs:
http://dir.gpki.go.jp/ApplicationCA.crl
http://dir2.gpki.go.jp/ApplicationCA2Root.crl
http://dir2.gpki.go.jp/ApplicationCA2Sub.crl
SubCA CPS section 4.9.7: The CRL of 48-hour validity period is issued at 
intervals of 24 hours.

* OCSP URL:
http://ocsp-sub.gpki.go.jp
http://ocsp-root.gpki.go.jp

* Audit: Annual audits are performed by KPMG AZSA LLC according to the WebTrust 
criteria.
WebTrust Audit (Japanese and English in same document):
https://cert.webtrust.org/SealFile?seal=1793=pdf
BR Readiness Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8667814
Response to Audit Findings: 
https://bugzilla.mozilla.org/attachment.cgi?id=8667815
We will improve the issues that was pointed out in the pre-audit and submit the 
investigation report by September 2016. 

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from the Government of Japan to 
include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites 
trust bit.

Please review this CA's request and provide feedback now, so that this CA may 
address any concerns while awaiting the results of their investigation report 
that is expected to show that the issues found during their BR audit have been 
addressed. A decision about inclusion will wait until after the investigation 
report has been provided.

Kathleen

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

Re: What is the Mozilla Firefox policy concerning SHA-1 Client authentication certificates?

[Richard Barnes]

Well, now you've made me go and try it.  I couldn't get OpenSSL to use
RSAwithMD2, but it works fine with MD5:

openssl req -x509 -out client-cert.pem -new -newkey rsa:512 -md5 -nodes
-keyout client-priv.pem
openssl pkcs12 -export -in client-cert.pem -inkey client-priv.pem -out
client.p12

# Preferences > Advanced > Certificates > View Certificates > Your
Certificates
# Import the p12
# Configure /etc/hosts to point example.com to 127.0.0.1

openssl req -x509 -out server-cert.pem -new -newkey rsa:2048 -sha256 -nodes
-keyout server-priv.pem
openssl s_server -cert server-cert.pem -key server-priv.pem -accept 8080
-www -Verify 0

# Navigate to https://example.com:8080/
# Add an exception for the server cert
# Note that the client cert you just imported is offered in the prompt
# Select the client cert you just imported
# Note that the server accepts the client cert



On Wed, Apr 27, 2016 at 2:25 PM, Peter Bowen  wrote:

> It does to a certain extent.  If I have a certificate that uses a
> 512-bit RSA key and is signed using RSAwithMD2, will Mozilla even
> attempt to use that certificate for client authentication?
>
> On Wed, Apr 27, 2016 at 10:54 AM, Richard Barnes 
> wrote:
> > For client certificates, it doesn't really matter what Mozilla thinks --
> it
> > matters what the website thinks when you present the client cert.
> >
> > On Wed, Apr 27, 2016 at 7:48 AM,  wrote:
> >
> >> Hi ! I read "
> >>
> https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/
> "
> >> article but my question is what about Client authentication certificates
> >> that are issued using SHA-1 like Qualified Certificates issued to
> clients
> >> in order to make client authenticated SSL connection and
> >> sign/encrypt/decrypt documents? Are they going to be valid and until
> when ?
> >> ___
> >> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What is the Mozilla Firefox policy concerning SHA-1 Client authentication certificates?

[Peter Bowen]

It does to a certain extent.  If I have a certificate that uses a
512-bit RSA key and is signed using RSAwithMD2, will Mozilla even
attempt to use that certificate for client authentication?

On Wed, Apr 27, 2016 at 10:54 AM, Richard Barnes  wrote:
> For client certificates, it doesn't really matter what Mozilla thinks -- it
> matters what the website thinks when you present the client cert.
>
> On Wed, Apr 27, 2016 at 7:48 AM,  wrote:
>
>> Hi ! I read "
>> https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/;
>> article but my question is what about Client authentication certificates
>> that are issued using SHA-1 like Qualified Certificates issued to clients
>> in order to make client authenticated SSL connection and
>> sign/encrypt/decrypt documents? Are they going to be valid and until when ?
>> ___
>> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What is the Mozilla Firefox policy concerning SHA-1 Client authentication certificates?

[Richard Barnes]

For client certificates, it doesn't really matter what Mozilla thinks -- it
matters what the website thinks when you present the client cert.

On Wed, Apr 27, 2016 at 7:48 AM,  wrote:

> Hi ! I read "
> https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/;
> article but my question is what about Client authentication certificates
> that are issued using SHA-1 like Qualified Certificates issued to clients
> in order to make client authenticated SSL connection and
> sign/encrypt/decrypt documents? Are they going to be valid and until when ?
> ___
> 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

What is the Mozilla Firefox policy concerning SHA-1 Client authentication certificates?

[vazmuten]

Hi ! I read 
"https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/;
 article but my question is what about Client authentication certificates that 
are issued using SHA-1 like Qualified Certificates issued to clients in order 
to make client authenticated SSL connection and sign/encrypt/decrypt documents? 
Are they going to be valid and until when ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

On Friday, April 8, 2016 at 12:58:41 AM UTC+3, Kathleen Wilson wrote:
> The status of this discussion is that we are waiting for the CA to provide 
> the following:
> 
> 1) Updated/restructured CPS (both in Hebrew and translated into English).
> 
> 2) Full BR Audit statement.
> 
> 3) An explanation of how the requirement for an unbroken sequence of audit 
> periods has been met.
> 
> This discussion may continue as soon as the CA has provided the three items 
> listed above.
> 
> Thanks,
> Kathleen

I've added our latest WebTrust CA Audit report to the Root Inclusion Bug:
"https://bugzilla.mozilla.org/show_bug.cgi?id=675060;
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy