Re: CA Problem Reporting Mechanisms

[userwithuid via dev-security-policy]

After skimming the responses and checking a few CAs, I'm starting to wonder: 
Wouldn't it be easier to just add another mandatory field to the CCADB (e.g. 
"revocation contact"), requiring $URL or $EMAIL via policy and just use that to 
provide a public list?

It seems to me that most revocation related procedures are very specific to 
CA-customers (e.g. log in and use the revoke button) and often not even TLS 
related (e.g. send a document signed with key you want to revoke, use the 
revocation password you got when creating the email cert, ...). I think it's 
not your intention for the wiki page to capture that, or is it?

>From what I can see, for non-customers the "instructions" - if there are any - 
>really seem to amount to: A) Send email with cert info + reason you suspect 
>misuse, we'll check or B) use web form to do the same.

IMHO, a wiki page with manually copied info has a good chance to get stale as 
CAs change their documents, websites, primary domains, etc.

(That being said, trying to use CPS urls from the CCADB [0] I got some 404s and 
some 30* lead nowhere as well. Also some CAs link an outdated version when the 
website has a WAY more recent one, though that might be because of the English 
vs native lang situation. Point is, CCADB entries might also be outdated, but 
at least that will be a policy violation now, right?).

[0] https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: April CA Communication: Results

[Jakob Bohm via dev-security-policy]

On 15/05/2017 15:53, Doug Beattie wrote:


...
Yes, it is certainly a bit dated.  Outlook 2013 and 2016 are not listed along 
with more recent versions of iMail and Thunderbird.



I believe the point of the document was only to list what was needed to
get SHA256 compatibility.  So for each vendor, product and use, it
lists the incompatible products and the first fully compatible product.




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: Symantec: Update

[Jakob Bohm via dev-security-policy]

On 15/05/2017 22:06, Michael Casadevall wrote:

On 05/15/2017 09:32 AM, Jakob Bohm wrote:

This won't work for the *millions* of legitimate, not-misissued,
end certificates that were issued before Symantec began SCT
embedding (hopefully in the past) and haven't expired before such
an early deadline.



Sorry, I could have been more clear here. What I'm proposing is that
after a specific TBD NotBefore date, we require SCTs to be in place on
the certificate to be trusted. Certificates from before that date
would remain trusted as-is (pending any reduction of expiration time).



Ok, that's much better.


I don't know if NSS has support for checking of SCTs (I can't pull the
source at the moment to check), but it should fail if the SCT is
missing, and otherwise behave like OCSP validation.


Also, since both Mozilla and Debian-derived systems such as Ubuntu
use the the Mozilla store as the basis for S/MIME checking, it is
worth noting that CT-logging of S/MIME end certs under the current
Google- dominated specifications is a guaranteed spam disaster, as
it would publish all the embedded e-mail addresses for easy
harvesting.



I didn't consider the S/MIME use case here. A brief look at the root
store I'd be fine with the SCT restriction only applying when looking
at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata,
it looks like at least some of the current Verisign/Symantec roots
have both the S/MIME and server auth bits enabled.

While I feel CT would be a nice thing for S/MIME, unfortunately, I
have to agree with this point that we don't need to make spammers
lives easier. That being said, part of me wonders if there would be
other undisclosed intermediates if one could easily evaluate S/MIME
issuances ...


Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and
we should never be in a case where a Mozilla product is accepting
a certificate that we can't independent review at a further point
via the CT logs. It should also prevent an undisclosed
intermediately from being undetected (as we've seen with Issue
Y).



However it would mandate that they be updated with new
certificates instead.  A lot easier, but still a mountain not
easily moved.


See above on NotBefore.




I'd also like to add the following to the transition plans: -
Limit certificate expiration to nine months from the existing
roots for new certificates.


I strongly believe the "9 month" rule mysteriously proposed but
never explained by Google was designed specifically to make buying
certs from Symantec all but worthless, chasing away all their
customers.  People *paying* for certificates generally don't want
to buy from anyone selling in increments of less than 1 year,
preferably 2 or 3.  "9 months" is an especially bad duration, as it
means the renewal dates and number of renewals per fiscal year will
fluctuate wildly from an accounting perspective.



I can see the point here, but I'm not sure I agree. Every time we keep
digging, we keep finding more and more problems with these roots.
WebPKI depends on all certificates in the root store being
trustworthy, and Symantec as a whole has not exactly shown themselves
to be responsive or willing to communicate publicly on the various
issues brought up on the list.



Yes, that seems to be the trend.  But it has nothing to do with if the
"9 month" rule or some other measures are the best remedy.


There's a decent argument to be had to simply disallow new issuance
from the existing roots and allow the current certificates to age out
(in which case imposing SCT embedded as I propose is simple), but I'm
not sure we've gotten a complete picture of how far this rabbit hole goe
s.



That wouldn't work, see below.


There's been a continual pattern of "this is everything", and then we
find another bunch of misissued certificates/undisclosed subCAs/etc.
Can we honestly say that we're comfortable with allowing these roots
to still be active at all?


- The above SCT requirement shall come into affect for the old
roots no less that three months from the date the proposal is
ratified. - Create a whitelist of intermediate certificates from
the root that can continue issuing certificates, but cutting off
RAs after an initial six month time period


Are there any RA's left for Symantec?



TBH, I'm not sure. I think Gervase asked for clarification on this
point, but its hard to keep track of who could issue as an RA. I know
quite a few got killed, but I'm not sure if there are any other subCAs
based off re-reading posts in this thread.



RAs (external companies that can decide if Symantec itself should issue
a cert) are completely different from external SubCAs (external
companies that have their own CA and a certificate chain back to a
Symantec root), which are different from internal SubCAs (CA
certificates for Symantec controlled keys, such as the SubCA that
signed normal OV certificates issued in January 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Patrick Tronnier via dev-security-policy]

Greetings, I have reviewed your second BR self-assessment 
(https://bugzilla.mozilla.org/attachment.cgi?id=8860627) against your updated 
CP/CPS (CP V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5) and provided the 
following comments and/or recommendations.


1. BR Section 3.2.2.5 Authentication for an IP: Per your comments please make 
sure your CPS states “GDCA does not issue EV certificate for an IP address.”

2. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
section 3.2.11 of your CPS.   

3. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
section 3.2.7 of your EV CPS.   

4. BR Section 3.2.3 Authentication of Individual Identity: I do not see in the 
CPS/CP where the differences in authentication of individuals is backed up by 
the appropriate technical constraining of the type of certificate issued. 
   4.1. Your comments for Type I and Type II Individual Certificates state they 
“are only for ordinary signing certificates, not for SSL certificates and code 
signing certificates” but I can’t find in the CPS where this is substantiated. 
I recommend clearly documenting in the CPS how each type of certificate is 
technically constrained (i.e. Key Usage, Enhanced Key Usage, etc.) and in CPS 
section 1.3.7.1 removing the words “but not limited to”. 
   4.2. For Type III certificates change the word “can” to “must”. (i.e. This 
must be validated by ID card, officer card or other valid document issued by 
government agency.”

5. BR Section 3.2.5 Validation of Authority: Per your comments please make sure 
this is clearly defined in the next version of your CPS.

6. BR Section 3.2.6 Criteria for Interoperation or Certification. Per your 
comments please make sure the next version of your CPS states you do not issue 
any cross certificates. 

7. BR Section 4.2.1 Performing Identification and Authentication Functions. Per 
your comments please make sure the next version of your CPS states you do not 
rely on data older than 27 months (or 39 months or 825 days per BRs).

8. BR Section 4.2.2 Approval or Rejection of Certificate Applications: Per your 
comments please make sure the next version of your CPS states GDCA does not 
issue certificates containing a new gTLD under consideration by ICANN.

9. BR Section 4.3.1 CA Actions during Certificate Issuance: Per your comments 
please make sure the next version of your CPS states “Certificate issuance by 
the Root CA SHALL require an individual authorized by the CA (i.e. the CA 
system operator, system officer, or PKI administrator) to deliberately issue a 
direct command in order for the Root CA to perform a certificate signing 
operation.”

10. BR Section 4.5.1 Subscriber private key and certificate usage: Per your 
comments please make sure the next version of your CPS details the use of SSL 
certificates per #4 (Use of Certificate) as described in BR Section 9.6.3. 
Subscriber Representations and Warranties.

11. BR Section 4.9.13 Circumstances for Suspension: Per your comments please 
make sure the next version of your CPS states certificate suspension is not 
allowed.

12. BR Section 4.10.1 Operational Characteristics: Per your comments please 
make sure the next version of your CPS states “Revocation entries on a CRL or 
OCSP Response will not be removed until after the Expiry Date of the revoked 
Certificate”.

13. BR Section 4.10.2 Service Availability: Per your comments please make sure 
the next version of your CPS states “the service response time shall be less 
than 10 seconds”.

14. Based on your self assessment comments in BR sections 1 – 4, I submit it 
would be useful for you to revisit your assessment of BR sections 5 
(MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS) through section 9 (OTHER 
BUSINESS AND LEGAL MATTERS) and update your BR Assessment.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Draft further questions for Symantec

[Steve Medin via dev-security-policy]

Replacement link:  https://bugzilla.mozilla.org/attachment.cgi?id=8867892

Sorry, I had the PDF cached.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> urijah--- via dev-security-policy
> Sent: Monday, May 15, 2017 3:41 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Re: Draft further questions for Symantec
> 
> The link in footnote [1]
> https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t
> 000Gmi3AAC=File__Body__s
> 
> gives me a 404 error.
> 
> 
> On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote:
> > Gerv,
> >
> > Our response to the recent questions is posted at:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8867735
> >
> > Kind regards,
> > Steve
> >
> > > -Original Message-
> > > From: dev-security-policy [mailto:dev-security-policy-
> > > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > > Gervase Markham via dev-security-policy
> > > Sent: Wednesday, May 10, 2017 7:06 AM
> > > To: mozilla-dev-security-pol...@lists.mozilla.org
> > > Subject: [EXT] Re: Draft further questions for Symantec
> > >
> > > On 08/05/17 13:24, Gervase Markham wrote:
> > > > 8) Please explain how the Management Assertions for your December
> > > > 2014
> > > 
> > >
> > > Strike this question; it's based on a misunderstanding of how audits
> > > are done.
> > >
> > > Let's add:
> > >
> > > 10) Do you agree that, during the period of time that Symantec
> > > cross-signed the Federal PKI (Issue L), it was technically possible
> > > for issuers inside the FPKI to issue EV certs by inserting Symantec's
EV
> OID?
> > >
> > > 11) If, in the Symantec Issues list or any other document relating
> > > to this matter we may publish in future, we have drawn a conclusion
> > > or inference about Symantec's PKI, actions or behaviour which is
> > > incorrect, we expect you to draw that to our attention, even if the
> > > truth is not as favourable to Symantec. Are there any incorrect
> > > inferences or conclusions in the Issues List which need to be
corrected?
> > >
> > > Gerv
> > > ___
> > > 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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Re: Draft further questions for Symantec

[Michael Casadevall via dev-security-policy]

I took a stab at trying to grok this. I find I have more questions and a
lot more concerns the more I read though. Please let me know if I'm not
the only one having issues decoding the responses. Here's my first
impressions:

RA & EV:
Were all the certificates issued by the RAs uploaded to a CT log? If
not, what, if any, subsets were uploaded?

I'm aware Symantec was required to upload certificates to CT or if it
was retroactive, but I'm unsure if that requirement was extended to the RAs.

Furthermore, based on what I'm reading, at least one of these
certificates should be in the logs since it took place post 01/01/15.

Issue Y:
A simple yes or no answer for the questions would have been nice here.

What I'm reading and my understanding suggests that the subCA
certificates could have technically issued a certificate trusted by
Mozilla, but system controls prevented them from being used that way.
How these system controls work is at best unclear.

It's worth noting that the subCA "State of Florida AHCA Medium Assurance
CA" and several other fPKI subCAs chaining off "VeriSign Class 3 SSP
Intermediate CA - G2" are listed in crt.sh is listed as trusted in
Mozilla in crt.sh (https://crt.sh/?caid=1384), and based on my
understanding thus could theoretically issue certificates as there's no EKU.

I can't find any leaf certificates issued by these CAs in crt.sh to
confirm this fact though. Here's a question for Symantec, how are they
aware of what certificates these sub-subCAs have or have not issued?

I'm not sure if the green bar requires OIDs in all points along the
certificate chain or if this Florida CA could have issued an leaf
certificate by adding the OIDs there.

Issue L:
Given that the cross-signature was doing by VeriSign, I've got more
questions. As far as I can tell, the response suggests that Symantec was
aware that the cross-signature allowed the FPKI to be trusted in places
it otherwise wouldn't be, and decided to ignore it until it expired out
in 2016.

That sounds bad, but my other possible reading of this was: "We were
unaware of the cross-signature until 2014, and we let it expire in 2016
since we didn't know what it did".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/15/2017 09:32 AM, Jakob Bohm wrote:
> This won't work for the *millions* of legitimate, not-misissued,
> end certificates that were issued before Symantec began SCT
> embedding (hopefully in the past) and haven't expired before such
> an early deadline.
> 

Sorry, I could have been more clear here. What I'm proposing is that
after a specific TBD NotBefore date, we require SCTs to be in place on
the certificate to be trusted. Certificates from before that date
would remain trusted as-is (pending any reduction of expiration time).

I don't know if NSS has support for checking of SCTs (I can't pull the
source at the moment to check), but it should fail if the SCT is
missing, and otherwise behave like OCSP validation.

> Also, since both Mozilla and Debian-derived systems such as Ubuntu
> use the the Mozilla store as the basis for S/MIME checking, it is
> worth noting that CT-logging of S/MIME end certs under the current
> Google- dominated specifications is a guaranteed spam disaster, as
> it would publish all the embedded e-mail addresses for easy
> harvesting.
> 

I didn't consider the S/MIME use case here. A brief look at the root
store I'd be fine with the SCT restriction only applying when looking
at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata,
it looks like at least some of the current Verisign/Symantec roots
have both the S/MIME and server auth bits enabled.

While I feel CT would be a nice thing for S/MIME, unfortunately, I
have to agree with this point that we don't need to make spammers
lives easier. That being said, part of me wonders if there would be
other undisclosed intermediates if one could easily evaluate S/MIME
issuances ...

>> Mandating the X509v3 extension for TLS certificates means that 
>> downstream servers don't have to be updated for CT awareness, and
>> we should never be in a case where a Mozilla product is accepting
>> a certificate that we can't independent review at a further point
>> via the CT logs. It should also prevent an undisclosed
>> intermediately from being undetected (as we've seen with Issue
>> Y).
>> 
> 
> However it would mandate that they be updated with new
> certificates instead.  A lot easier, but still a mountain not
> easily moved.

See above on NotBefore.


>> 
>> I'd also like to add the following to the transition plans: -
>> Limit certificate expiration to nine months from the existing
>> roots for new certificates.
> 
> I strongly believe the "9 month" rule mysteriously proposed but
> never explained by Google was designed specifically to make buying
> certs from Symantec all but worthless, chasing away all their
> customers.  People *paying* for certificates generally don't want
> to buy from anyone selling in increments of less than 1 year,
> preferably 2 or 3.  "9 months" is an especially bad duration, as it
> means the renewal dates and number of renewals per fiscal year will
> fluctuate wildly from an accounting perspective.
> 

I can see the point here, but I'm not sure I agree. Every time we keep
digging, we keep finding more and more problems with these roots.
WebPKI depends on all certificates in the root store being
trustworthy, and Symantec as a whole has not exactly shown themselves
to be responsive or willing to communicate publicly on the various
issues brought up on the list.

There's a decent argument to be had to simply disallow new issuance
from the existing roots and allow the current certificates to age out
(in which case imposing SCT embedded as I propose is simple), but I'm
not sure we've gotten a complete picture of how far this rabbit hole goe
s.

There's been a continual pattern of "this is everything", and then we
find another bunch of misissued certificates/undisclosed subCAs/etc.
Can we honestly say that we're comfortable with allowing these roots
to still be active at all?

>> - The above SCT requirement shall come into affect for the old
>> roots no less that three months from the date the proposal is
>> ratified. - Create a whitelist of intermediate certificates from
>> the root that can continue issuing certificates, but cutting off
>> RAs after an initial six month time period
> 
> Are there any RA's left for Symantec?
> 

TBH, I'm not sure. I think Gervase asked for clarification on this
point, but its hard to keep track of who could issue as an RA. I know
quite a few got killed, but I'm not sure if there are any other subCAs
based off re-reading posts in this thread.

>> - Require that Symantec reapply to the root program for a new DV
>> and EV root certificates, and begin the migration here. Once the
>> new roots are approved, then they can cross-sign from the old
>> roots to the new ones.
>> 
>> My thought process here is to try and keep impact on WebPKI a
>> minimum, while making sure that we can externally audit how
>> Symantec is using their root store for certificates that will be
>> trusted by Mozilla.
>> 
>> I'm concerned that spinning up new roots and having them be in
>> the most 

Re: [EXT] Re: Draft further questions for Symantec

[urijah--- via dev-security-policy]

The link in footnote [1]
https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t000Gmi3AAC=File__Body__s

gives me a 404 error.


On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote:
> Gerv,
> 
> Our response to the recent questions is posted at: 
> https://bugzilla.mozilla.org/attachment.cgi?id=8867735
> 
> Kind regards,
> Steve
> 
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Wednesday, May 10, 2017 7:06 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Draft further questions for Symantec
> >
> > On 08/05/17 13:24, Gervase Markham wrote:
> > > 8) Please explain how the Management Assertions for your December 2014
> > 
> >
> > Strike this question; it's based on a misunderstanding of how audits are
> > done.
> >
> > Let's add:
> >
> > 10) Do you agree that, during the period of time that Symantec cross-signed
> > the Federal PKI (Issue L), it was technically possible for issuers inside 
> > the FPKI
> > to issue EV certs by inserting Symantec's EV OID?
> >
> > 11) If, in the Symantec Issues list or any other document relating to this
> > matter we may publish in future, we have drawn a conclusion or inference
> > about Symantec's PKI, actions or behaviour which is incorrect, we expect you
> > to draw that to our attention, even if the truth is not as favourable to
> > Symantec. Are there any incorrect inferences or conclusions in the Issues 
> > List
> > which need to be corrected?
> >
> > Gerv
> > ___
> > 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: Changing CCADB domains

[Kathleen Wilson via dev-security-policy]

Here are the changes we are requesting to be made on Friday, May 19, at 1pm PDT.

1) https://mozillacacommunity.force.com/
will be changed to
https://ccadb.force.com/
(This is the CA login page, and the domain CAs see when they are logged into 
the CCADB)

2) https://mozillacaprogram.secure.force.com/
will be changed to
https://mozilla-ccadb.secure.force.com/
(This is the domain for the Mozilla reports that are published directly from 
the CCADB)

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

RE: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

Symantec logs TLS server certificates that are intended to be trusted by Chrome 
to Certificate Transparency logs. Symantec does not systematically log other 
certificate types to CT, including Class 1, Class 2 and other types of user 
certificates.



The Adobe Approved Trust List intermediate CA does not issue TLS certificates. 
This subCA issues Adobe document digital signature certificates that identify 
people and organizations and as such they are not systematically included in CT 
logging.



See also:

https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html

https://helpx.adobe.com/acrobat/kb/approved-trust-list2/_jcr_content/main-pars/download-section/download-1/file.res/aatl_technical_requirements_v14.pdf





From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Friday, May 05, 2017 10:18 AM
To: Steve Medin 
Cc: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec: Draft Proposal



To ask a substantive question, you have asserted that all certificates issued 
have been logged to CT; this Symantec CA currently has no publicly logged 
issued certificates: 
https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798=mozilladisclosure.
 Can you confirm that this CA has _never_ been used to issue a certificate? 
(There ar
 e several other similar Symantec intermediates for which there are no publicly 
logged certs about which I have the same question).

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

RE: [EXT] Re: Symantec Conclusions and Next Steps

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, April 25, 2017 6:50 PM
> To: Ryan Sleevi 
> Cc: mozilla-dev-security-policy  pol...@lists.mozilla.org>; Gervase Markham 
> Subject: [EXT] Re: Symantec Conclusions and Next Steps
> 
> Continuing to look through the audits, I happened to notice a few other
> things that stood out, some more pressing than others.
> 
> More pressing:
> I can find no disclosure with Salesforce or crt.sh of at least two CAs
that are
> listed 'in scope' of the audit report, as part of
> https://www.symantec.com/content/en/us/about/media/
> repository/Symantec-NFSSP-WTCA_11-30-2016.pdf
> 
> This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2"
> as within scope for this audit. It would be useful to understand their
lack of
> disclosure, relative to the audits and to Section 5.3.2 of the inclusion
policy.
> 

The two SureID CAs are now disclosed. They were inadvertently omitted.

https://mozillacacommunity.force.com/001o016Uc20 
https://mozillacacommunity.force.com/001o016Uc6M 

Based on https://crt.sh/mozilla-disclosures#undisclosedsummary, we also
disclosed an additional version of the CSC Device CA - G2. Both versions are
signed by the VeriSign Class 3 SSP Intermediate CA - G2. The previously
disclosed CSC Device CA - G2 expires on August 14, 2021.

Existing: https://mozillacacommunity.force.com/001o00p4Sf2 
New: https://mozillacacommunity.force.com/001o016UfuS 

We further updated CCADB to ensure it mirrors the PKI Map we are creating.
As part of that effort we posted:

-   39 entries that chain to roots no longer trusted by Mozilla
-   10 which chain to the revoked VeriSign Class 3 SSP Intermediate CA
-   13 which are either technically constrained by EKU or software
constrained in Symantec operated systems, limiting issuance to code signing
or time stamping authority certificates.
-   Additional entries to capture different versions of the same subCA,
even in cases where the versions were never deployed and/or never issued end
entity certificates.


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Mon, May 15, 2017 at 10:18 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Once upon a time I would said "yes, we should totally encourage people to
> lovingly craft their perfect trust store, to reduce their risk profile".
> Now, not so much.
>
> As we've seen in numerous discussions, customers of CAs, particularly large
> enterprises and vendors (think payment terminals) love to pick out one or
> two roots, ship them to a billion devices with no update capability, and
> then use this as an argument against improvements to the WebPKI ecosystem
> (e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
> trust stores are significantly less likely to have any hope of getting an
> update than just shipping the whole Mozilla bundle. Further, with CT
> enforcement, you can get basically the same security guarantee (only certs
> I intend; +/- 24 hours) without burdening the ecosystem with your lack of
> agility.
>
> Cheers,
> Alex


An alternative solution to the ossification that Alex muses about is to
require that all CAs must generate (new) roots on some interval (e.g. 3
years) for inclusion. That is, the 'maximum' a root can be included in a
Mozilla product is 3 years (or less!)

What this does is it bounds the limit of badness (from these CAs) to 5
years. As a new CA is stood up for inclusion in Mozilla products, the
(existing) root can sign the (new) root. The third year the CA transitions
all new certificates to be issued from this (new) root, and starts the
inclusion process, so that by the fifth year, it can ubiquitously included
within Mozilla products.

That is, imagine you have the following scenario:

(old root) -> (old intermediate) -> (3 year leaf)

On Y3, you generate new root and new intermediate, and then cross-sign,
such that you have

(old root) -> (old intermediate) -> (old existing certs)
   -> (new root) -> (new intermediate) -> (new leaf certs)

Sites can either rely on AIA (Ideal, but unfortunately, not yet supported
by Mozilla) or simply supply the full chain (less ideal, wasteful on
bandwidth and caching), of either

(site cert) -> (new intermediate) -> (new root) [the AIA path]
(site cert) -> (new intermediate) -> (new root) -> (old root) [the slow,
compatibility path]

The benefit here is that we can reasonably assume that the 'risk' profile
of a root is bounded to its 'acceptance within Mozilla' - here, at 3 years
of 'live' issuance, plus 2-3 years (depending on the max age of the cert)

For products that bake in roots, the CA can continue to support/maintain
them, as they essentially become 'private' PKI roots after some period of
time. Sites that need 'publicly trusted' certs, but also need to support
those old devices, can use the (new root) -> (old root) -> (older root) ->
(oldest root) [if we assume 12 year device lifecycle] - *provided* that the
new certs are supported on the old devices.

If the new certs aren't, then just cut a 'legacy' cert from the old device
- and know that Web clients cannot and should not be expected to support
these.

It forces agility into the system. The arguments against this is that it'd
be more work for the CAs (... for which I'm admittedly not sympathetic),
that it doesn't address cases where both old devices with old certs and new
devices/web users with new certs need to exist on the same endpoint (again,
I'm less sympathetic of this, in this modern age), and more work for
Mozilla (processing trust store changes). But this seems a good balance.

Most importantly, it systematically addresses the risk factors posed by
having 'ancient' roots included in modern clients - and all of those past
decisions affecting the security of up-to-date users. By ensuring agility
in the ecosystem, it substantially reduces that risk.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Draft further questions for Symantec

[Steve Medin via dev-security-policy]

Gerv,

Our response to the recent questions is posted at: 
https://bugzilla.mozilla.org/attachment.cgi?id=8867735

Kind regards,
Steve

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Wednesday, May 10, 2017 7:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Draft further questions for Symantec
>
> On 08/05/17 13:24, Gervase Markham wrote:
> > 8) Please explain how the Management Assertions for your December 2014
> 
>
> Strike this question; it's based on a misunderstanding of how audits are
> done.
>
> Let's add:
>
> 10) Do you agree that, during the period of time that Symantec cross-signed
> the Federal PKI (Issue L), it was technically possible for issuers inside the 
> FPKI
> to issue EV certs by inserting Symantec's EV OID?
>
> 11) If, in the Symantec Issues list or any other document relating to this
> matter we may publish in future, we have drawn a conclusion or inference
> about Symantec's PKI, actions or behaviour which is incorrect, we expect you
> to draw that to our attention, even if the truth is not as favourable to
> Symantec. Are there any incorrect inferences or conclusions in the Issues List
> which need to be corrected?
>
> Gerv
> ___
> 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: April CA Communication: Results

[urijah--- via dev-security-policy]

It's useful to note that Outlook 2007 leaves extended support on October 10. 
(That deadline has been extended a few times, I believe, but this should be the 
final date.)

https://support.microsoft.com/en-us/help/3198497/office-2007-approaching-end-of-extended-support

On Monday, May 15, 2017 at 9:16:46 AM UTC-4, Gervase Markham wrote:
> On 15/05/17 14:07, Jakob Bohm wrote:
> > 1. Microsoft's e-mail clients were very late to accept stronger
> >   signature algorithms for e-mails (including e-mails sent by users of
> >   non-problematic e-mail clients).  I believe Globalsign's page about
> >   SHA256-transition for customers provides a nice overview.
> 
> Link? Any docs about research people have done into the prevalance of
> SHA-1 for S/MIME, and which clients don't support SHA-256, would be very
> useful.
> 
> Gerv

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

Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

Once upon a time I would said "yes, we should totally encourage people to
lovingly craft their perfect trust store, to reduce their risk profile".
Now, not so much.

As we've seen in numerous discussions, customers of CAs, particularly large
enterprises and vendors (think payment terminals) love to pick out one or
two roots, ship them to a billion devices with no update capability, and
then use this as an argument against improvements to the WebPKI ecosystem
(e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
trust stores are significantly less likely to have any hope of getting an
update than just shipping the whole Mozilla bundle. Further, with CT
enforcement, you can get basically the same security guarantee (only certs
I intend; +/- 24 hours) without burdening the ecosystem with your lack of
agility.

Cheers,
Alex

On Mon, May 15, 2017 at 9:19 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/05/17 09:18, Cory Benfield wrote:
> > I try not to decide whether there is interest in features like this:
> > if they’re easy I’d just implement them and let users decide if they
> > want it. That’s what I’d be inclined to do here. If Mozilla added
> > such a flag, I’d definitely be open to adding an extra certifi
> > bundle. Certifi currently already ships with two bundles (one
> > labelled “weak”, which includes 1024-bit roots to work around
> > problems with older OpenSSLs), so we could easily add a third called
> > “strong” or “pedantic” or “I hate CAs” or something that removes any
> > CA that is subject to graduated trust in Firefox.
>
> If people actually care enough to make a root store choice, should we be
> encouraging them instead to use a store containing only the CA they care
> about for the connection they are making (and perhaps a backup)? In
> other words, is some sort of easy-to-use root store filtering/splitting
> tool a better solution to this issue?
>
> Gerv
> ___
> 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: April CA Communication: Results

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Kurt
> Roeckx via dev-security-policy
> Sent: Monday, May 15, 2017 9:41 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: April CA Communication: Results
> 
> On 2017-05-15 15:38, Kurt Roeckx wrote:
> > On 2017-05-15 15:26, Gervase Markham wrote:
> >> On 15/05/17 14:19, Doug Beattie wrote:
> >>> https://support.globalsign.com/customer/portal/articles/1216323
> >>
> >> Thanks, Doug. There's no date on that doc - are you able to say when
> >> it was written?
> >
> > It says: Last Updated: Aug 26, 2013 11:24AM EDT
> 
> And the http reply itself says:
> Last-Modified: Thu, 11 Dec 2014 14:02:12 GMT

Yes, it is certainly a bit dated.  Outlook 2013 and 2016 are not listed along 
with more recent versions of iMail and Thunderbird.

> 
> Kurt
> 
> 
> ___
> 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: April CA Communication: Results

[Kurt Roeckx via dev-security-policy]

On 2017-05-15 15:38, Kurt Roeckx wrote:

On 2017-05-15 15:26, Gervase Markham wrote:

On 15/05/17 14:19, Doug Beattie wrote:

https://support.globalsign.com/customer/portal/articles/1216323


Thanks, Doug. There's no date on that doc - are you able to say when it
was written?


It says: Last Updated: Aug 26, 2013 11:24AM EDT


And the http reply itself says:
Last-Modified: Thu, 11 Dec 2014 14:02:12 GMT


Kurt


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

Re: April CA Communication: Results

[Kurt Roeckx via dev-security-policy]

On 2017-05-15 15:26, Gervase Markham wrote:

On 15/05/17 14:19, Doug Beattie wrote:

https://support.globalsign.com/customer/portal/articles/1216323


Thanks, Doug. There's no date on that doc - are you able to say when it
was written?


It says: Last Updated: Aug 26, 2013 11:24AM EDT


Kurt


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

Re: April CA Communication: Results

[Jakob Bohm via dev-security-policy]

On 15/05/2017 15:26, Gervase Markham wrote:

On 15/05/17 14:19, Doug Beattie wrote:

https://support.globalsign.com/customer/portal/articles/1216323


Thanks, Doug. There's no date on that doc - are you able to say when it
was written?

Gerv



I believe it is a "live" doc, that was regularly updated, at least
while relevant changes were happening in the world.

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: Configuring Graduated Trust for Non-Browser Consumption

[Jakob Bohm via dev-security-policy]

On 15/05/2017 15:19, Gervase Markham wrote:

On 12/05/17 09:18, Cory Benfield wrote:

I try not to decide whether there is interest in features like this:
if they’re easy I’d just implement them and let users decide if they
want it. That’s what I’d be inclined to do here. If Mozilla added
such a flag, I’d definitely be open to adding an extra certifi
bundle. Certifi currently already ships with two bundles (one
labelled “weak”, which includes 1024-bit roots to work around
problems with older OpenSSLs), so we could easily add a third called
“strong” or “pedantic” or “I hate CAs” or something that removes any
CA that is subject to graduated trust in Firefox.


If people actually care enough to make a root store choice, should we be
encouraging them instead to use a store containing only the CA they care
about for the connection they are making (and perhaps a backup)? In
other words, is some sort of easy-to-use root store filtering/splitting
tool a better solution to this issue?



That obviously wouldn't be any good where the intent is to accept
general third parties (just like the intent in a Browser).

It would also cause the specific problems with entities randomly stuck
at specific historic roots that are part of our current Symantec
dilemma.


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: Symantec: Update

[Jakob Bohm via dev-security-policy]

On 13/05/2017 12:27, Michael Casadevall wrote:

On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:



On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy 
 wrote:

I would appreciate people's comments on the details of the current draft.


I don’t think that this proposal goes far enough.


First post on the list but long time lurker, but I feel the need to
weigh in here that I think Jonathah's proposal is much closer to what
has to happen.



I suspect you may be believing too much of what Google says, see
specific problems below.


Reading through Gervase's document, I'd like to add the following to
this in addition to the existing notes in PKI operations:

 - EV certificate roots loose their trust bits effective immediately
   (I don't think this can be done via OneCRL so it would be via the
next release)
 - Any root stores (new or old) operated by Symantec shall require all
certificates to be posted to a CT log.
 - Within three months, require all certificates issued from Symantec to
have SCT embedded in the end point certificate, and mandate this from
the beginning for any root certificates.
   - NSS shall only accept certificates with the embedded SCT record in
the certificate.


This won't work for the *millions* of legitimate, not-misissued, end
certificates that were issued before Symantec began SCT embedding
(hopefully in the past) and haven't expired before such an early
deadline.

Also, since both Mozilla and Debian-derived systems such as Ubuntu use
the the Mozilla store as the basis for S/MIME checking, it is worth
noting that CT-logging of S/MIME end certs under the current Google-
dominated specifications is a guaranteed spam disaster, as it would
publish all the embedded e-mail addresses for easy harvesting.



Certificate transparency was the only way we began to get a real look at
how bad some of these issues are, and I feel that if we're going to
actually continue with Symatec as a CA, then we're going to make
absolutely sure we know how certificates are being utilized.



That is unfortunately true.


Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and we
should never be in a case where a Mozilla product is accepting a
certificate that we can't independent review at a further point via the
CT logs. It should also prevent an undisclosed intermediately from being
undetected (as we've seen with Issue Y).



However it would mandate that they be updated with new certificates
instead.  A lot easier, but still a mountain not easily moved.



I'd also like to add the following to the transition plans:
 - Limit certificate expiration to nine months from the existing roots
for new certificates.


I strongly believe the "9 month" rule mysteriously proposed but never
explained by Google was designed specifically to make buying certs from
Symantec all but worthless, chasing away all their customers.  People
*paying* for certificates generally don't want to buy from anyone
selling in increments of less than 1 year, preferably 2 or 3.  "9
months" is an especially bad duration, as it means the renewal dates
and number of renewals per fiscal year will fluctuate wildly from an
accounting perspective.


 - The above SCT requirement shall come into affect for the old roots no
less that three months from the date the proposal is ratified.
 - Create a whitelist of intermediate certificates from the root that
can continue issuing certificates, but cutting off RAs after an initial
six month time period


Are there any RA's left for Symantec?


 - Require that Symantec reapply to the root program for a new DV and EV
root certificates, and begin the migration here. Once the new roots are
approved, then they can cross-sign from the old roots to the new ones.

My thought process here is to try and keep impact on WebPKI a minimum,
while making sure that we can externally audit how Symantec is using
their root store for certificates that will be trusted by Mozilla.

I'm concerned that spinning up new roots and having them be in the most
common root stores is going to take a significant period of time and
during that window we're still stuck with the old roots being in
operation. By limiting the branches of the old roots, it should limit
our risk while the new roots come into existence and begin to spread
through the ecosystem.


I believe the only reasonable interpretation of the "new root" plan
would be based on cross signing for trust by old Mozilla browsers and
other root programs.



Winding down the old roots (phase four as described in the proposal) is
going to be a long and slow process so I want to make sure we're making
sure that while we're in the transition period that we've got an
extremely clear picture on what's going on on both sets of roots.

My problem with the Google "sliding scale" is that's its damn hard to
understand when exactly a 

Re: April CA Communication: Results

[Gervase Markham via dev-security-policy]

On 15/05/17 14:19, Doug Beattie wrote:
> https://support.globalsign.com/customer/portal/articles/1216323

Thanks, Doug. There's no date on that doc - are you able to say when it
was written?

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

Re: Configuring Graduated Trust for Non-Browser Consumption

[Gervase Markham via dev-security-policy]

On 12/05/17 09:18, Cory Benfield wrote:
> I try not to decide whether there is interest in features like this:
> if they’re easy I’d just implement them and let users decide if they
> want it. That’s what I’d be inclined to do here. If Mozilla added
> such a flag, I’d definitely be open to adding an extra certifi
> bundle. Certifi currently already ships with two bundles (one
> labelled “weak”, which includes 1024-bit roots to work around
> problems with older OpenSSLs), so we could easily add a third called
> “strong” or “pedantic” or “I hate CAs” or something that removes any
> CA that is subject to graduated trust in Firefox.

If people actually care enough to make a root store choice, should we be
encouraging them instead to use a store containing only the CA they care
about for the connection they are making (and perhaps a backup)? In
other words, is some sort of easy-to-use root store filtering/splitting
tool a better solution to this issue?

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

RE: April CA Communication: Results

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, May 15, 2017 9:16 AM
> To: Jakob Bohm ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: April CA Communication: Results
> 
> On 15/05/17 14:07, Jakob Bohm wrote:
> > 1. Microsoft's e-mail clients were very late to accept stronger
> >   signature algorithms for e-mails (including e-mails sent by users of
> >   non-problematic e-mail clients).  I believe Globalsign's page about
> >   SHA256-transition for customers provides a nice overview.
> 
> Link? Any docs about research people have done into the prevalance of
> SHA-1 for S/MIME, and which clients don't support SHA-256, would be very
> useful.
>
https://support.globalsign.com/customer/portal/articles/1216323

> Gerv
> ___
> 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: Aetna and UniCredit audits

[Gervase Markham via dev-security-policy]

On 15/05/17 12:54, Kurt Roeckx wrote:
> At least it's technically constrained.

Ah yes, you are right. Not nearly such an issue, then.

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

Re: April CA Communication: Results

[Gervase Markham via dev-security-policy]

On 15/05/17 14:07, Jakob Bohm wrote:
> 1. Microsoft's e-mail clients were very late to accept stronger
>   signature algorithms for e-mails (including e-mails sent by users of
>   non-problematic e-mail clients).  I believe Globalsign's page about
>   SHA256-transition for customers provides a nice overview.

Link? Any docs about research people have done into the prevalance of
SHA-1 for S/MIME, and which clients don't support SHA-256, would be very
useful.

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

Re: Aetna and UniCredit audits

[Adriano Santoni via dev-security-policy]

  
  
Right. Not very recently: in October 2016;
it is technically-constrained, and expires this October.


Il 15/05/2017 12:52, Gervase Markham
  via dev-security-policy ha scritto:


  Also, am I right in thinking that Actalis has recently cross-signed
UniCredit?
https://crt.sh/?id=47081615



-- 
  
Cordiali saluti,

Adriano Santoni
ACTALIS S.p.A.
(Aruba Group)

  




smime.p7s
Description: Firma crittografica S/MIME
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: April CA Communication: Results

[Kurt Roeckx via dev-security-policy]

On 2017-05-15 13:40, Gervase Markham wrote:

* (Q13) Many CAs plan to stop issuing SHA-1 S/MIME by the end of this
year. CAs without a firm date are: Comodo, GlobalSign, SECOM, TWCA, and
Visa. A couple of these CAs hint that an industry deadline to stop would
help their customers see the need to migrate.


So is this something we can work on?

I think Thunderbird probably doesn't have enough market share to 
actually do something with this, so maybe this is more something for 
Microsoft?


The preferred changed would be to require both the certificates and the 
message itself to be signed with SHA-2.



Kurt

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

Re: Aetna and UniCredit audits

[Kurt Roeckx via dev-security-policy]

On 2017-05-15 12:52, Gervase Markham wrote:


Symantec never received any formal audits from UniCredit; I am trying to
get hold of the informal ones. Their participation in the GeoRoot
program started in January 2012:
https://crt.sh/?CN=UniCredit+Subordinate+External

So both organizations had full issuance rights for the WebPKI for over 5
years with no audit oversight whatsoever. And when it was finally done,
the audit of Aetna seems to show what sort of arrangements result from that.

Also, am I right in thinking that Actalis has recently cross-signed
UniCredit?
https://crt.sh/?id=47081615


At least it's technically constrained.


Kurt

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

April CA Communication: Results

[Gervase Markham via dev-security-policy]

With two exceptions (neither of which have the websites trust bit set),
all answers are now in from the April 2017 CA Communication. You can
find links to the answers here:
https://wiki.mozilla.org/CA/Communications#April_2017_Responses

Some highlights for the community's attention:

* (Q1) It seems like all CAs are on track to implement domain validation
via one of the Ten Blessed Methods by July 21st 2017.

* (Q2) CAs are now required to increment the version number of their
CP/CPS every year, which will make it much easier to notice CAs who are
not regularly reviewing and revising their documentation.

* (Q3) A few CAs might have difficulty meeting the June 1st deadline for
CP/CPS in English. But of course, this may not be a problem unless their
audit becomes due before they've got it done.

* (Q5/Q6) There is some concern over the requirement to include the
words "clean" or "qualified" in audit reports, particularly for ETSI
audits. This is one for Kathleen to look at.

* (Q8) All 60 CAs confirm they have ceased publicly-trusted SHA-1 SSL
issuance :-)

* (Q9) DocuSign (and perhaps T-Systems; it's not clear) are the only CAs
of the 60 who say they have 3rd party RAs doing domain validation.

* (Q11) A number of CAs haven't answered this or seem not to have quite
understood the requirement. I sent some of them an email a week or two
ago; I may need to send another. But still, it's a good starting
collection of CAA identifiers. A surprisingly large number of CAs wish
to use more than one domain name. DigiCert's comment is amusing:

"digicert.com, although I may add misspellings of "Digicert" shortly. It
happens a lot."

* (Q13) Many CAs plan to stop issuing SHA-1 S/MIME by the end of this
year. CAs without a firm date are: Comodo, GlobalSign, SECOM, TWCA, and
Visa. A couple of these CAs hint that an industry deadline to stop would
help their customers see the need to migrate.

* (Q14) There is a surprising level of support for reducing certificate
lifetimes to 13 months. Here's my quick analysis:

YES 20
NO  21
MORE TIME   6
DV ONLY 4
N/A 4
UNKNOWN 4

The opposition group, though, contains many of the larger CAs (e.g.
Comodo, Entrust, Symantec). Let's Encrypt is in favour, and GoDaddy is
in the More Time camp. Most More Timers suggested March 2019 rather than
2018. A few CAs suggest reducing the lifetime for DV certs only.
"Unknown" means they gave an answer but didn't actually indicate a position!

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

CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

Hi all,

One of the CA Communication questions was about the Problem Reporting
Mechanisms that CAs are supposed to have. The answers are here:
https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028

I would love it if someone would volunteer to turn this into a wiki page
in a more standardized and useful format, looking up the actual
information where people have said "see section X.X of our CPS", and so
on. And they can send me a list of CAs I have to email to remind them
that this is a compulsory requirement so they can't put "Not applicable"
or "We'll figure it out later".

Might anyone have an hour or two to spare, to help in this way? If so,
drop me an email for a more detailed brief.

Thanks :-)

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

Aetna and UniCredit audits

[Gervase Markham via dev-security-policy]

Symantec have supplied the audits for their GeoRoot partner "Aetna":

https://bug1334377.bmoattachments.org/attachment.cgi?id=8867397
https://bug1334377.bmoattachments.org/attachment.cgi?id=8867398

The community might find them interesting reading. These audits are the
only ones Symantec received from Aetna, and are dated May 10th 2016,
auditing the calendar year 2015. Aetna's intermediate has a notBefore of
July 2010:
https://crt.sh/?id=33549

Symantec never received any formal audits from UniCredit; I am trying to
get hold of the informal ones. Their participation in the GeoRoot
program started in January 2012:
https://crt.sh/?CN=UniCredit+Subordinate+External

So both organizations had full issuance rights for the WebPKI for over 5
years with no audit oversight whatsoever. And when it was finally done,
the audit of Aetna seems to show what sort of arrangements result from that.

Also, am I right in thinking that Actalis has recently cross-signed
UniCredit?
https://crt.sh/?id=47081615

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