Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

On 10/02/2017 05:42, Ryan Sleevi wrote:



On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy
> wrote:

Additional issue #2: The information at https://pki.goog/ about how to
report misissuance directs visitors to a generic reporting page for
code vulnerabilities, which (by their nature) tends to require reaction
times measured in days/weeks rather than the 1 day maximum specified
in Google's CPS.


(To be clear, I am responding only as an individual, neither as Mozilla
peer or Google employee, although I recognize you will likely disregard
my remarks regardless.)

In the past, such comments have generally been seen as
offtopic/accusatory, because they are inherently absent of evidence of
any malfeasance. Indeed, your very comment seems to suggest that Google
is not adhering to its CP/CPS, but without evidence, and such
implication comes not based on any action that Google has taken, but
based on your view of what 'others' do or the 'class' of bugs.

I highlight this because we (the community) see the occasional remark
like this; most commonly, it's directed at organizations in particular
countries, on the basis that we shouldn't trust "them" because they're
in one of "those countries". However, the Mozilla policy is structured
to provide objective criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present
it as an "issue"; you are implying that Google will not adhere to its
CP/CPS, but without evidence. The nature of incident reporting via this
method may indeed be risky, but it's neither forbidden nor intrinsically
wrong. If you look at many members in the Mozilla program, you will see
far less specificity as to a problem report and the acceptable means of
reporting this.



For clarity, I was pointing out that GTS seems to have chosen a method
likely to fail if an when actually needed, due to the typical dynamics
of large human organizations.  Presumably an organization of such
magnitude is likely to have contact points more dedicated to
time-sensitive action-required messages than the contact point they chose.


So while it's useful for you to draw attention to this, it's without
evidence or basis for you to suggest that this is an "issue", per se -
that is, it seemingly in no way conflicts with Mozilla policy or
industry practice.


I find that it is an issue, but not an absolute cause for rejection.


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: Google Trust Services roots

[Peter Bowen via dev-security-policy]

On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy
 wrote:
> I can't see this sentence
>  " I highlight this because we (the community) see the occasional remark like 
> this; most commonly, it's directed at organizations in particular countries, 
> on the basis that we shouldn't trust "them" because they're in one of "those 
> countries". However, the Mozilla policy is structured to provide objective 
> criteria and assessments of that."
> has any relationship with this topic, please advise, thanks.

I think the point is that issues raised about CAs need to be grounded
in fact.  "Universal Trust Services wrote Y in their CPS but did not
do Y as demonstrated by Z" is something that can be evaluated
factually  "UTS wrote Y in their CPS but might not being doing Y"
without any evidence is not something that can be evaluated factually.

I agree with Ryan; we tend to see the second type of issue come up
more often with CAs from certain countries.  This sort of non-data
driven issue is not appropriate to raise.  Instead show what should
have happened and what did not.

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

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Richard Wang via dev-security-policy]

I think Mozilla should have a very clear policy for:
(1)  If a company that not a public trusted CA acquired a trusted root key, 
what the company must do?
(2)  If a company is a public trusted CA that acquired a trusted root key, what 
the company must do?
(3) If a company is a public trusted CA, but distrusted by Mozilla, this 
company acquired a trusted root key, what the company must do?

Thanks.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Bowen via dev-security-policy
Sent: Friday, February 10, 2017 1:10 PM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Public disclosure of root ownership transfers (was: Re: Google 
Trust Services roots)

On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy 
 wrote:
> On 09/02/17 14:32, Gijs Kruitbosch wrote:
>> Would Mozilla's root program consider changing this requirement so 
>> that it *does* require public disclosure, or are there convincing 
>> reasons not to? At first glance, it seems like 'guiding' CAs towards 
>> additional transparency in the CA market/industry/... might be 
>> helpful to people outside Mozilla's root program itself.
>
> This would require CAs and companies to disclose major product plans 
> publicly well in advance of the time they would normally disclose them.
> I won't dig out the dates myself, or check the emails, but if you look 
> for the following dates from publicly-available information:
>
> A) The date Google took control of the GlobalSign roots
> B) The date Google publicly announced GTS
>
> you will see there's quite a big delta. If you assume Google told 
> Mozilla about event A) before it happened, then you can see the problem.

Google says they took control on 11 August 2016.

On 19 October 2016, Google publicly stated "Update on the Google PKI:
new roots were generated and web trust audits were performed, the report on 
this is forthcoming,"
(https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google)

Google didn't file with Mozilla until 22 December 2016, and I suspect that was 
only because I happened to run across their staged website:
https://twitter.com/pzb/status/812103974220222465

I appreciate the business realities of pre-disclosure, but that is not the case 
here.  There is no excuse for having taken control of existing roots and not 
disclosing such once they disclosed that they are intending to become a root CA.

Thanks,
Peter
___
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: Google Trust Services roots

[Richard Wang via dev-security-policy]

I can't see this sentence
 " I highlight this because we (the community) see the occasional remark like 
this; most commonly, it's directed at organizations in particular countries, on 
the basis that we shouldn't trust "them" because they're in one of "those 
countries". However, the Mozilla policy is structured to provide objective 
criteria and assessments of that."
has any relationship with this topic, please advise, thanks.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, February 10, 2017 12:43 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their nature) tends to require
> reaction times measured in days/weeks rather than the 1 day maximum
> specified in Google's CPS.
>

(To be clear, I am responding only as an individual, neither as Mozilla peer or 
Google employee, although I recognize you will likely disregard my remarks 
regardless.)

In the past, such comments have generally been seen as offtopic/accusatory, 
because they are inherently absent of evidence of any malfeasance. Indeed, your 
very comment seems to suggest that Google is not adhering to its CP/CPS, but 
without evidence, and such implication comes not based on any action that 
Google has taken, but based on your view of what 'others' do or the 'class' of 
bugs.

I highlight this because we (the community) see the occasional remark like 
this; most commonly, it's directed at organizations in particular countries, on 
the basis that we shouldn't trust "them" because they're in one of "those 
countries". However, the Mozilla policy is structured to provide objective 
criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present it as 
an "issue"; you are implying that Google will not adhere to its CP/CPS, but 
without evidence. The nature of incident reporting via this method may indeed 
be risky, but it's neither forbidden nor intrinsically wrong. If you look at 
many members in the Mozilla program, you will see far less specificity as to a 
problem report and the acceptable means of reporting this.

So while it's useful for you to draw attention to this, it's without evidence 
or basis for you to suggest that this is an "issue", per se - that is, it 
seemingly in no way conflicts with Mozilla policy or industry practice.
___
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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Peter Bowen via dev-security-policy]

On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via
dev-security-policy  wrote:
> On 09/02/17 14:32, Gijs Kruitbosch wrote:
>> Would Mozilla's root program consider changing this requirement so that
>> it *does* require public disclosure, or are there convincing reasons not
>> to? At first glance, it seems like 'guiding' CAs towards additional
>> transparency in the CA market/industry/... might be helpful to people
>> outside Mozilla's root program itself.
>
> This would require CAs and companies to disclose major product plans
> publicly well in advance of the time they would normally disclose them.
> I won't dig out the dates myself, or check the emails, but if you look
> for the following dates from publicly-available information:
>
> A) The date Google took control of the GlobalSign roots
> B) The date Google publicly announced GTS
>
> you will see there's quite a big delta. If you assume Google told
> Mozilla about event A) before it happened, then you can see the problem.

Google says they took control on 11 August 2016.

On 19 October 2016, Google publicly stated "Update on the Google PKI:
new roots were generated and web trust audits were performed, the
report on this is forthcoming,"
(https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google)

Google didn't file with Mozilla until 22 December 2016, and I suspect
that was only because I happened to run across their staged website:
https://twitter.com/pzb/status/812103974220222465

I appreciate the business realities of pre-disclosure, but that is not
the case here.  There is no excuse for having taken control of
existing roots and not disclosing such once they disclosed that they
are intending to become a root CA.

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

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their nature) tends to require reaction
> times measured in days/weeks rather than the 1 day maximum specified
> in Google's CPS.
>

(To be clear, I am responding only as an individual, neither as Mozilla
peer or Google employee, although I recognize you will likely disregard my
remarks regardless.)

In the past, such comments have generally been seen as offtopic/accusatory,
because they are inherently absent of evidence of any malfeasance. Indeed,
your very comment seems to suggest that Google is not adhering to its
CP/CPS, but without evidence, and such implication comes not based on any
action that Google has taken, but based on your view of what 'others' do or
the 'class' of bugs.

I highlight this because we (the community) see the occasional remark like
this; most commonly, it's directed at organizations in particular
countries, on the basis that we shouldn't trust "them" because they're in
one of "those countries". However, the Mozilla policy is structured to
provide objective criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present it
as an "issue"; you are implying that Google will not adhere to its CP/CPS,
but without evidence. The nature of incident reporting via this method may
indeed be risky, but it's neither forbidden nor intrinsically wrong. If you
look at many members in the Mozilla program, you will see far less
specificity as to a problem report and the acceptable means of reporting
this.

So while it's useful for you to draw attention to this, it's without
evidence or basis for you to suggest that this is an "issue", per se - that
is, it seemingly in no way conflicts with Mozilla policy or industry
practice.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

On 09/02/2017 20:55, Ryan Hurst wrote:

Peter,

Thank you very much for your, as always, thorough review.

Let me start by saying I agree there is an opportunity for improving the 
policies around how key transfers such your recent transfer and Google's are 
handled.

It is my hope we can, through our respective recent experiences performing such 
transfers, help Mozilla revise their policy to provide better guidance for such 
cases in the future.

As for your specific questions, my responses follow:

pzb: First, according to the GTS website, there is no audit using the WebTrust 
Principles and Criteria for Certification Authorities – Extended Validation 
SSL.  However the two roots in the Mozilla CA  program currently are EV enabled 
and at least one subordinate CA under them is issuing EV certificates.

rmh: Prior to our final stage of the acquisition we contacted both Mozilla and 
Microsoft about this particular situation.



Additional issue #1: Apparently, GlobalSign has not updated its website
with the fact that GlobalSign root R2 is no longer operated by
GlobalSign, see for example 
https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates 
..


Also looking at the GlobalSign website I saw no obvious press release
regarding this transfer, the closest I could find was the following,
which seems kind of misleading, as it mentions new EV certs chaining to
GlobalSign R3 instead of R2, but not the fact that R2 is no longer a
GlobalSign root: 
https://support.globalsign.com/customer/portal/articles/2580816-ev-ssl-intermediate-and-root-changes


Additional issue #2: The information at https://pki.goog/ about how to
report misissuance directs visitors to a generic reporting page for
code vulnerabilities, which (by their nature) tends to require reaction
times measured in days/weeks rather than the 1 day maximum specified
in Google's CPS.


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: Taiwan GRCA Root Renewal Request

[horn917--- via dev-security-policy]

Kathleen Wilson於 2017年2月3日星期五 UTC+8上午6時36分54秒寫道：
> On Tuesday, December 13, 2016 at 2:36:15 PM UTC-8, Kathleen Wilson wrote:
> > Thanks to all of you who have reviewed and commented on this request from 
> > Government of Taiwan, Government Root Certification Authority (GRCA), to 
> > include their renewed Government Root Certification Authority root 
> > certificate, and turn on the Websites and Email trust bits.
> > 
> > To summarize this discussion so far, two primary concerns have been raised, 
> > as follows.
> > 
> > 1) There are several intermediate certificates that are technically capable 
> > of issuing TLS certificates, but have not been audited according to the 
> > BRs. This is a show-stopper.
> > 
> > Reference:
> > https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs
> > “BR Audits must always include the whole-population audit of intermediate 
> > certificates that are capable of issuing SSL certs.”
> > 
> > This means that if the intermediate certificate is not technically 
> > constrained via EKU (and name constraints) then it must be audited 
> > according to the BRs. 
> > 
> > We have resolved this particular situation in the past by having the CA get 
> > an audit statement saying that the intermediate certificate has not issued 
> > TLS certificates during the audit period. And requiring that the CA get 
> > such an audit statement annually.
> > 
> 
> The CA has been working with their auditor to get an appropriate audit 
> statement that covers all of the intermediate certs chaining up to this root.
> 

In accordance with Kathleen's advice, our auditor has provided such a audit 
statement.(https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815)

> > 
> > 2) The new root certificate has the same exact full distinguished name as 
> > the old root certificate. I think this is OK.
> > 
> > The CA tested this with Firefox, and provided their test results:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8818360
> >
> 
> The new root cert having the same DN as the old root cert appears to work
> from a technical standpoint (i.e. mozilla::pkix will find the right path if 
> all necessary certificates are present). However, the duplicate names have 
> already caused unnecessary confusion: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1304264
> 
> This "new" root certificate was created in 2012, is included in Microsoft's 
> program, and has several active intermediate certs. So it might not be 
> reasonable to ask the CA to generate a new root certificate at this point in 
> time. However, I urge the CA to take note, and not repeat this with the next 
> generation of their root certificate.
> 
> Kathleen

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

Re: Misissued/Suspicious Symantec Certificates

[Nick Lamb via dev-security-policy]

On Thursday, 9 February 2017 03:08:14 UTC, Ryan Sleevi  wrote:
> 19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur
> are the only Delegated Third Parties utilized by Symantec, across all
> Symantec operated CAs that are trusted by Mozilla products?

Maybe Ryan has better information than me, but I had assumed that in practice 
all the companies identified on their site as Symantec "Affiliates" offering 
SSL are or have been Delegated Third Parties under the BRs.

https://forms.ws.symantec.com/verisign-worldwide/index.html

I confess that I reached this supposition by Googling "Symantec Crosscert" and 
thinking about what I found, rather than through deep knowledge of Symantec's 
business or direct personal information.

Symantec provides the following links for "affiliates" offering SSL

https://www.acs.altech.co.za/symantec-pki
https://www.egypttrust.com/
http://www.comsign.co.il/
http://www.verisign.co.jp/
http://www.crosscert.com/
http://www.itrus.com.cn/
http://www.msctrustgate.com/
http://www.mysecuresign.com/
http://www.niftetrust.com/
http://www.safescrypt.com/
http://www.adacom.com/
http://www.skyrr.is/
http://www.telefonica.es/
http://www.trustitalia.it/
http://www.certsuperior.com/
http://www.certisign.com.br/
http://www.certisur.com/
http://www.e-sign.cl/

Some of those were on Ryan's list above already, and some are defunct, but 
despite language barriers I think I was able to determine that some of the 
others are selling Symantec certificates. I suppose it's possible that they're 
merely acting as resellers and all validation etc. is done by Symantec, but I 
wanted to flag it up.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

Ryan,

Thank you for the quick reply.  My comments and questions are inline.

On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy
 wrote:
> Peter,
>
> Thank you very much for your, as always, thorough review.
>
> Let me start by saying I agree there is an opportunity for improving the 
> policies around how key transfers such your recent transfer and Google's are 
> handled.
>
> It is my hope we can, through our respective recent experiences performing 
> such transfers, help Mozilla revise their policy to provide better guidance 
> for such cases in the future.

Where I see opportunities below, I'm marking them with "Policy Suggestion".

> As for your specific questions, my responses follow:
>
> pzb: First, according to the GTS website, there is no audit using the 
> WebTrust Principles and Criteria for Certification Authorities – Extended 
> Validation SSL.  However the two roots in the Mozilla CA  program currently 
> are EV enabled and at least one subordinate CA under them is issuing EV 
> certificates.
>
> rmh: Prior to our final stage of the acquisition we contacted both Mozilla 
> and Microsoft about this particular situation.
>
> At this time, we do not have any interest in the issuance of EV SSL 
> certificates, however GlobalSign does. Based on our conversations with 
> representatives from both organizations we were told that since:
> - The EV OID associated with this permission is associated with GlobalSign 
> and not Google and,
> - GlobalSign is active member in good standing with the respective root 
> programs and,
> - Google will not be issuing EV SSL certificates,
> - Google will operate these roots under their own CP/CPS’s and associated 
> OIDs,
> - Google issuing a certificate with the GlobalSign OIDs would qualify as 
> miss-issuance.

Mozilla recognizes 2.23.140.1.1 as being a valid OID for EV
certificates for all EV-enabled roots
(https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).

1) Do you consider it mis-issuance for Google to issue a certificate
containing the 2.23.140.1.1 OID?

Policy Suggestion A) When transferring a root that is EV enabled, it
should be clearly stated whether the recipient of the root is also
receiving the EV policy OID(s).

> That it would be acceptable for us not to undergo a EV SSL audit, and that 
> GlobalSign could keep the EV right for the associated subordinate CA for the 
> remaining validity period to facilitate the transition (assuming continued 
> compliance).
>
> As a former manager of a root program, this seems an appropriate position to 
> take. And as one who has been involved in several such root transfers I think 
> differences in intended use are common enough that they should be explicitly 
> handled by policy.
>
> pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 
> December 2016, Google Inc. operated these Roots according to Google Inc.’s 
> Certification Practice Statement."  The basic WebTrust for CA and WebTrust BR 
> audit reports for the period ending September 30, 2016 explicitly state they 
> are for "subordinate CA under external Root CA" and do not list the roots in 
> the GTS CPS at all.
>
> rmh: I believe this will be answered by my responses to your third and fourth 
> observations.

It was not.

2) Will Google be publishing an audit report for a period starting 11
August 2016 that covers the transferred GS roots?  If so, can you
estimate the end of period date?

> pzb: Third, the Google CPS says Google took control of these roots on August 
> 11, 2016.  The Mozilla CA policy explicitly says that a bug report must be 
> filed to request to be included in the Mozilla CA program.  It was not until 
> December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA 
> program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).  This does 
> not appear to align with Mozilla requirements for public disclosure.
>
> rmh: As has been mentioned, timing for a transaction like this is very 
> complicated. The process of identifying candidates that could meet our needs 
> took many months with several false starts with different organizations. That 
> said, prior to beginning this process we proactively reached out to both 
> Microsoft and Mozilla root programs to let them know we were beginning the 
> process. Once it looked like we would be able to come to an agreement with 
> GlobalSign we again reached out and notified both programs of our intent to 
> secure these specific keys. Then once the transaction was signed we again 
> notified the root programs that the deal was done.
>
> As you know the process to ensure a secure, audited and well structured key 
> migration is also non-trivial. Once this migration was performed we again 
> notified both root programs.
>
> Our intention was to notify all parties, including the public, shortly after 
> the transfer but it took some time for our auditors, for reasons unrelated to 
> our audit, 

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

[Jakob Bohm via dev-security-policy]

On 09/02/2017 18:20, Jakob Bohm wrote:

On 09/02/2017 10:59, Gervase Markham wrote:

On 08/02/17 11:25, Jakob Bohm wrote:

My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses.   For example if the existing CA
setup uses all bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.


Requiring randomness in the serial number is only appropriate when some
of the certificate contents are attacker-controlled. This is not true
for an intermediate issued by a CA. And if the CA is an attacker,
restricting them to a serial number of the same length (i.e. not
arbitrary) makes it harder for them to engineer a collision.

Gerv



However as a best practice, a CA may establish internal countermeasures
involving adding entropy even for internal requests for intermediary
certificates.  My proposal was to simply not ban that.

For external requests, the issue would be if a specific CA certificate
was previously used to sign certificates whose serial number consisted
of e.g. a 128 bit internally computed value (such as AES128(fixed key,
counter)) and a few bits of fresh entropy (such as 20 bits), then
moving to to the higher requirement of 64 fresh CSPRNG bits might be
best implemented (for some such CA) by changing to those same 128 bits
(for continued uniqueness), plus 64 bits of CSPRNG output.  Again my
proposal was not to ban that.

More generally, there might be a Mozilla policy requirement that the
length should be fixed in the (updated) CP/CPS, and the serial number
should be mostly generated by the issuing CA (except for cross-certs).


Strike that exception, the serial number is not dictated by the
requester, even for cross-certs.


While such length-growing security improvements might be hampered by
the need to support legacy parties with hard limits on serial number
length, that would be for each CA to consider and decide.




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: Talk at FOSDEM

[Martin Heaps via dev-security-policy]

Thank you for the link, Gerv. That was a very interesting watch. Curious 
correlation [post video] between Earnst and Young re:Wosign and Earnst and 
Young re: CrossCert (although I assume this CrossCert relationship was only 
forthcoming after your talk).












And the gent around the 38 minute mark turning the lights off as you where 
talking was somewhat amusing (sorry)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

Peter,

Thank you very much for your, as always, thorough review. 

Let me start by saying I agree there is an opportunity for improving the 
policies around how key transfers such your recent transfer and Google's are 
handled.

It is my hope we can, through our respective recent experiences performing such 
transfers, help Mozilla revise their policy to provide better guidance for such 
cases in the future.

As for your specific questions, my responses follow:

pzb: First, according to the GTS website, there is no audit using the WebTrust 
Principles and Criteria for Certification Authorities – Extended Validation 
SSL.  However the two roots in the Mozilla CA  program currently are EV enabled 
and at least one subordinate CA under them is issuing EV certificates. 

rmh: Prior to our final stage of the acquisition we contacted both Mozilla and 
Microsoft about this particular situation. 

At this time, we do not have any interest in the issuance of EV SSL 
certificates, however GlobalSign does. Based on our conversations with 
representatives from both organizations we were told that since:
- The EV OID associated with this permission is associated with GlobalSign and 
not Google and,
- GlobalSign is active member in good standing with the respective root 
programs and,
- Google will not be issuing EV SSL certificates,
- Google will operate these roots under their own CP/CPS’s and associated OIDs,
- Google issuing a certificate with the GlobalSign OIDs would qualify as 
miss-issuance.

That it would be acceptable for us not to undergo a EV SSL audit, and that 
GlobalSign could keep the EV right for the associated subordinate CA for the 
remaining validity period to facilitate the transition (assuming continued 
compliance).

As a former manager of a root program, this seems an appropriate position to 
take. And as one who has been involved in several such root transfers I think 
differences in intended use are common enough that they should be explicitly 
handled by policy. 

pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 
December 2016, Google Inc. operated these Roots according to Google Inc.’s 
Certification Practice Statement."  The basic WebTrust for CA and WebTrust BR 
audit reports for the period ending September 30, 2016 explicitly state they 
are for "subordinate CA under external Root CA" and do not list the roots in 
the GTS CPS at all. 

rmh: I believe this will be answered by my responses to your third and fourth 
observations.

pzb: Third, the Google CPS says Google took control of these roots on August 
11, 2016.  The Mozilla CA policy explicitly says that a bug report must be 
filed to request to be included in the Mozilla CA program.  It was not until 
December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA 
program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).  This does not 
appear to align with Mozilla requirements for public disclosure. 

rmh: As has been mentioned, timing for a transaction like this is very 
complicated. The process of identifying candidates that could meet our needs 
took many months with several false starts with different organizations. That 
said, prior to beginning this process we proactively reached out to both 
Microsoft and Mozilla root programs to let them know we were beginning the 
process. Once it looked like we would be able to come to an agreement with 
GlobalSign we again reached out and notified both programs of our intent to 
secure these specific keys. Then once the transaction was signed we again 
notified the root programs that the deal was done.

As you know the process to ensure a secure, audited and well structured key 
migration is also non-trivial. Once this migration was performed we again 
notified both root programs.

Our intention was to notify all parties, including the public, shortly after 
the transfer but it took some time for our auditors, for reasons unrelated to 
our audit, to produce the associated audit letters. 

Once we received said letters, we then filed the bugs.

This is, although not our ideal timeline, and based on our understanding, in 
compliance with the Mozilla root program in that since these roots were already 
members they did not require us to publicly disclose the above negotiation, 
contracting, planning, migration and other intermediate steps.

pzb: Fourth, the audit reports linked in the bug explicitly set the scope of 
"subordinate CA operated under external Root CA" and do not include any 
indication of controls around the issuance of subordinate CA certificates.  
These audit reports do not have an appropriate scope for a root CA. 

rmh: Yes, we were also concerned about this topic, especially with the recent 
scope issues with audits. As such, we discussed this with both our auditors, 
and the the root programs prior to acquisition of the key material. 

When looking at this issue it is important to keep in mind Google has operated 
a WebTrust 

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

Peter,

Thank you very much for your, as always, thorough review.

Let me start by saying I agree there is an opportunity for improving the
policies around how key transfers such your recent transfer and Google's
are handled.

It is my hope we can, through our respective recent experiences performing
such transfers, help Mozilla revise their policy to provide better guidance
for such cases in the future.

As for your specific questions, my responses follow:

pzb: First, according to the GTS website, there is no audit using the
WebTrust Principles and Criteria for Certification Authorities – Extended
Validation SSL.  However the two roots in the Mozilla CA  program currently
are EV enabled and at least one subordinate CA under them is issuing EV
certificates.

rmh: Prior to our final stage of the acquisition we contacted both Mozilla
and Microsoft about this particular situation.

At this time, we do not have any interest in the issuance of EV SSL
certificates, however GlobalSign does. Based on our conversations with
representatives from both organizations we were told that since:

   -

   The EV OID associated with this permission is associated with GlobalSign
   and not Google and,
   -

   GlobalSign is active member in good standing with the respective root
   programs and,
   -

   Google will not be issuing EV SSL certificates,
   -

   Google will operate these roots under their own CP/CPS’s and associated
   OIDs,
   -

   Google issuing a certificate with the GlobalSign OIDs would qualify as
   miss-issuance.


That it would be acceptable for us not to undergo a EV SSL audit, and that
GlobalSign could keep the EV right for the associated subordinate CA for
the remaining validity period to facilitate the transition (assuming
continued compliance).

As a former manager of a root program, this seems an appropriate position
to take. And as one who has been involved in several such root transfers I
think differences in intended use are common enough that they should be
explicitly handled by policy.

pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8
December 2016, Google Inc. operated these Roots according to Google Inc.’s
Certification Practice Statement."  The basic WebTrust for CA and WebTrust
BR audit reports for the period ending September 30, 2016 explicitly state
they are for "subordinate CA under external Root CA" and do not list the
roots in the GTS CPS at all.

rmh: I believe this will be answered by my responses to your third and
fourth observations.

pzb: Third, the Google CPS says Google took control of these roots on
August 11, 2016.  The Mozilla CA policy explicitly says that a bug report
must be filed to request to be included in the Mozilla CA program.  It was
not until December 22, 2016 that Google requested inclusion as a CA in
Mozilla's CA program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).
This does not appear to align with Mozilla requirements for public
disclosure.

rmh: As has been mentioned, timing for a transaction like this is very
complicated. The process of identifying candidates that could meet our
needs took many months with several false starts with different
organizations. That said, prior to beginning this process we proactively
reached out to both Microsoft and Mozilla root programs to let them know we
were beginning the process. Once it looked like we would be able to come to
an agreement with GlobalSign we again reached out and notified both
programs of our intent to secure these specific keys. Then once the
transaction was signed we again notified the root programs that the deal
was done.

As you know the process to ensure a secure, audited and well structured key
migration is also non-trivial. Once this migration was performed we again
notified both root programs.

Our intention was to notify all parties, including the public, shortly
after the transfer but it took some time for our auditors, for reasons
unrelated to our audit, to produce the associated audit letters.

Once we received said letters, we then filed the bugs.

This is, although not our ideal timeline, and based on our understanding,
in compliance with the Mozilla root program in that since these roots were
already members they did not require us to publicly disclose the above
negotiation, contracting, planning, migration and other intermediate steps.

pzb: Fourth, the audit reports linked in the bug explicitly set the scope
of "subordinate CA operated under external Root CA" and do not include any
indication of controls around the issuance of subordinate CA certificates.
These audit reports do not have an appropriate scope for a root CA.

rmh: Yes, we were also concerned about this topic, especially with the
recent scope issues with audits. As such, we discussed this with both our
auditors, and the the root programs prior to acquisition of the key
material.

When looking at this issue it is important to keep in mind Google has
operated a WebTrust audited 

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

[Jakob Bohm via dev-security-policy]

On 09/02/2017 10:59, Gervase Markham wrote:

On 08/02/17 11:25, Jakob Bohm wrote:

My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses.   For example if the existing CA
setup uses all bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.


Requiring randomness in the serial number is only appropriate when some
of the certificate contents are attacker-controlled. This is not true
for an intermediate issued by a CA. And if the CA is an attacker,
restricting them to a serial number of the same length (i.e. not
arbitrary) makes it harder for them to engineer a collision.

Gerv



However as a best practice, a CA may establish internal countermeasures
involving adding entropy even for internal requests for intermediary
certificates.  My proposal was to simply not ban that.

For external requests, the issue would be if a specific CA certificate
was previously used to sign certificates whose serial number consisted
of e.g. a 128 bit internally computed value (such as AES128(fixed key,
counter)) and a few bits of fresh entropy (such as 20 bits), then
moving to to the higher requirement of 64 fresh CSPRNG bits might be
best implemented (for some such CA) by changing to those same 128 bits
(for continued uniqueness), plus 64 bits of CSPRNG output.  Again my
proposal was not to ban that.

More generally, there might be a Mozilla policy requirement that the
length should be fixed in the (updated) CP/CPS, and the serial number
should be mostly generated by the issuing CA (except for cross-certs).

While such length-growing security improvements might be hampered by
the need to support legacy parties with hard limits on serial number
length, that would be for each CA to consider and decide.


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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Gervase Markham via dev-security-policy]

On 09/02/17 14:32, Gijs Kruitbosch wrote:
> Would Mozilla's root program consider changing this requirement so that
> it *does* require public disclosure, or are there convincing reasons not
> to? At first glance, it seems like 'guiding' CAs towards additional
> transparency in the CA market/industry/... might be helpful to people
> outside Mozilla's root program itself.

This would require CAs and companies to disclose major product plans
publicly well in advance of the time they would normally disclose them.
I won't dig out the dates myself, or check the emails, but if you look
for the following dates from publicly-available information:

A) The date Google took control of the GlobalSign roots
B) The date Google publicly announced GTS

you will see there's quite a big delta. If you assume Google told
Mozilla about event A) before it happened, then you can see the problem.

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