Re: More SHA-1 certs

2016-02-06 Thread Rob Stradling 

On 05/02/16 21:43, Charles Reiss wrote:

On 02/05/16 20:13, martin.suc...@gmail.com wrote:

Here's a list of all certificates with SHA-1 signatures and notBefore >= 
2016-01-01, logged in the Certificate Transparency Log:
https://crt.sh/?cablint=211=2016-01-01


Some notes on how these look as of now. The listed subCA CNs are:
- DOD CA-28
- DOD CA-27

These chain to DST ACES CA X6, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 and
https://cabforum.org/pipermail/public/2016-February/006696.html


- Intel External Basic Issuing CA 3A

These chain through a technically constrained subordinate CA
https://crt.sh/?id=1250505


- Symantec Private SSL SHA1 CA

These chain to the 1024-bit VeriSign roots 'Class 3 Public Primary
Certification Authority' and 'Class 3 Public Primary Certification
Authority - G2' which are no longer included in Mozilla's root program.


"Class 3 Public Primary Certification Authority - G2" is still trusted 
for serverAuthentication in Microsoft's root program.



Curiously, the similar COMODO CA 'COMODO Domain Validation Legacy Server
CA 2' (chains to retired root 'UTN - DATACorp SGC') appears to be
exempted from listing? (example cert:
https://crt.sh/?id=12584167=cablint)


On the crt.sh database I'd marked "COMODO Domain Validation Legacy 
Server CA 2" as out-of-scope for cablint checks, on the grounds that the 
root (UTN - DATACorp SGC) has been (or is waiting to be) pulled from 
root programs that demand BR compliance.


However, I'm going to add it back in-scope.  We (Comodo) currently 
intend that new certs issued under "UTN - DATACorp SGC" will adhere to 
the BRs in every way except for SHA-1.  It would be useful for crt.sh / 
cablint to spot any unintended issues.



- VeriSign Class 3 Secure Server CA - G3
- VeriSign Class 3 International Server CA - G3

I believe these are the certs at
https://cabforum.org/pipermail/public/2016-January/006519.html or
precertificates for them.

- RSA Corporate Server CA v2
- DnB NOR ASA PKI Class G
- Shared Business CA 3
- TI Trust Technologies Global CA
- Postecom CS3
- Aetna Inc. Certificate Authority
- SHECA
- AC Infrastructure
- YourNet SSL for business
- Verizon Public SureServer CA G14-SHA1

These have been mentioned here previously.



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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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

RE: More SHA-1 certs

2016-02-06 Thread Yuhong Bao 
> "Class 3 Public Primary Certification Authority - G2" is still trusted 
> for serverAuthentication in Microsoft's root program.
Actually the same is true for the G1 one too (they just added the trust back).
Yuhong Bao
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy revision proposal - transitive disclosure exception

2016-02-06 Thread Peter Bowen 
The Mozilla CA Certificate policy says, in part:

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

* A certificate is deemed as capable of being used to issue new
certificates if it contains an X.509v3 basicConstraints extension,
with the cA boolean set to true.
* These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla’s CA Certificate
Program."

I would propose that transitive disclosure not be required when the
subject of the CA-certificate is also the subject of a certificate
included directly in the Mozilla trust store.

This will not change the total set of certificates disclosed, rather
just limit duplicate disclosure.  It also ensures that the program
member who most closely controls or is responsible for the transitive
certificates is handling the disclosure, which should help assure
accuracy of the disclosures.

However, to be clear, in the event that a CA not in the Mozilla trust
store is cross-certified by two different program members, both are
still responsible for full disclosure of all transitive certificates.
This is due to the fact that each member is equally responsible;
revocation of a cross-certificate issued by one member does not impact
the cross-certificate issued by the other member.

I think that this should be adopted for policy version 2.3.

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