Re: Action on undisclosed intermediates

[Gervase Markham]

On 12/11/16 17:43, Peter Bowen wrote:
> So it seems this problem has resolved itself.  No need to invent
> random selection schemes.

As Rob says, one could speculate on the connection between the proposal
and the sudden action. Although Kathleen did say she was in contact with
most of these CAs so perhaps all of the problems they were having
suddenly got solved.

Anyway, on to something else :-)

Gerv

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

Re: Action on undisclosed intermediates

[Rob Stradling]

On 12/11/16 17:43, Peter Bowen wrote:

> So it seems this problem has resolved itself.  No need to invent
> random selection schemes.

ISTM that the threat of random selection schemes may have been what
resolved the problem.  ;-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Action on undisclosed intermediates

[Peter Bowen]

On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham  wrote:
> I'd like to take some action about persistent failures to properly
> disclose intermediates. The deadline for this was June, and CAs have had
> a number of reminders, so there's no excuse.
>
> Of course, if intermediates aren't disclosed, we can't be certain what
> they are, but crt.sh has a good idea of many of them:
> https://crt.sh/mozilla-disclosures#undisclosed
>
> There is also a list on that page of certs which CAs have disclosed but
> not provided audit info, but given that you can get off that list by
> putting _anything_ in the relevant box in Salesforce, I'm worried about
> perverse incentives if we go after people on that list at the moment:
> https://crt.sh/mozilla-disclosures#disclosureincomplete

Based on data this morning, it looks like there are only two left on
that undisclosed list.  One of them is RSA, who is already scheduled
for removal.  The other is TurkTrust, which announced they are leaving
the server auth cert business:
https://cabforum.org/pipermail/public/2016-September/008475.html

So it seems this problem has resolved itself.  No need to invent
random selection schemes.

Now, the real fun is going to be seeing if the supplied audit report
URLs actually point to reports and if all the CAs claimed to be
covered are actually covered ;)

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

Re: Action on undisclosed intermediates

[Rob Stradling]

On 09/11/16 17:36, Kathleen Wilson wrote:
> On Wednesday, November 9, 2016 at 4:16:56 AM UTC-8, Rob Stradling wrote:
>> To have reached the incorrect conclusion that they'd "properly followed
>> the requirement", a CA would've presumably either...
>>   1. Looked at https://crt.sh/mozilla-disclosures#undisclosed, noticed
>> that one or more of their intermediates was marked as "Disclosure is
>> required!", but decided to ignore it.
> 
> Or thought it was incorrect. For example, there were some self-signed root 
> certs that were marked as disclosure is required. Those have been added as 
> intermediate certs for now...

Those undisclosed self-signed roots were signed by private keys that
also correspond to self-signed roots that are trusted by NSS.
Therefore, the undisclosed certs chain to the trusted ones.  And
therefore, they are required to be disclosed, according to your policy AIUI.

IINM, the CAs who have encountered this particular issue have been
talking to you about it.  That means that it wasn't the case that they
"decided to ignore it", which is good!

> Or got errors when trying to upload the certs to Salesforce. I still have 
> several of these in my inbox to work through.
> 
> Please note that the RSA root certificate is schedule for removal in the 
> December batch of root changes via
> https://bugzilla.mozilla.org/show_bug.cgi?id=1283326
> So I'm ignoring these: RSA the Security Division of EMC 18

Thanks for sharing that info.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Action on undisclosed intermediates

[Kathleen Wilson]

On Wednesday, November 9, 2016 at 4:16:56 AM UTC-8, Rob Stradling wrote:
> To have reached the incorrect conclusion that they'd "properly followed
> the requirement", a CA would've presumably either...
>   1. Looked at https://crt.sh/mozilla-disclosures#undisclosed, noticed
> that one or more of their intermediates was marked as "Disclosure is
> required!", but decided to ignore it.

Or thought it was incorrect. For example, there were some self-signed root 
certs that were marked as disclosure is required. Those have been added as 
intermediate certs for now...

Or got errors when trying to upload the certs to Salesforce. I still have 
several of these in my inbox to work through.

Please note that the RSA root certificate is schedule for removal in the 
December batch of root changes via
https://bugzilla.mozilla.org/show_bug.cgi?id=1283326
So I'm ignoring these: RSA the Security Division of EMC 18

Cheers,
Kathleen

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

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 21:09, Kathleen Wilson wrote:
> I've been exchanging email and working with just about all of these
> CAs. There have been a few problems in our Salesforce customization
> to work out, and there have been some questions about which
> intermediate certs needed to be disclosed (regarding different
> instances of essentially the same certificate).
> 
> Anyways, hopefully this discussion will give those CAs additional
> incentive to finish getting their intermediate certs fully disclosed
> in the CA Community in Salesforce. And it is a good idea to figure
> out what the consequences will be of CAs not disclosing their
> intermediate certs in the CA Community in Salesforce.

OK. I wouldn't fire off this plan without your approval :-) And if you
think there are CAs with acceptable mitigating circumstances, then we
could exclude them for one or more rounds of the process.

But really, uploading certs to Salesforce is, in general terms, not a
difficult or complicated task. Ben Wilson did about 20 of them during
the CAB Forum meeting.

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

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 16:18, Gervase Markham wrote:
> We would choose 3 certs from the list as it exists every Monday at 2pm
> UK time, using the following sources of randomness for the algorithm:
> 
> 1) UK National Lottery "Lotto" numbers, not including bonus ball
> 2) UK National Lottery "Thunderball" numbers, not including Thunderball
> 3) UK National Lottery "Lotto Hotpicks" numbers

It disappeared from the mod queue for some reason, but someone commented:

"There's a slight problem with that, Lotto Hotpicks reuses the same
numbers from the main Lotto draw. I would recommend changing those to
Friday's EuroMillions draw."

Yes, indeed. That seems like a good change :-) Without the Lucky Stars
numbers.

Gerv

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

Re: Action on undisclosed intermediates

[Kathleen Wilson]

On Tuesday, November 8, 2016 at 8:19:15 AM UTC-8, Gervase Markham wrote:
> Hi everyone,
> 
> I'd like to take some action about persistent failures to properly
> disclose intermediates. The deadline for this was June, and CAs have had
> a number of reminders, so there's no excuse.


I've been exchanging email and working with just about all of these CAs. There 
have been a few problems in our Salesforce customization to work out, and there 
have been some questions about which intermediate certs needed to be disclosed 
(regarding different instances of essentially the same certificate). 

Anyways, hopefully this discussion will give those CAs additional incentive to 
finish getting their intermediate certs fully disclosed in the CA Community in 
Salesforce. And it is a good idea to figure out what the consequences will be 
of CAs not disclosing their intermediate certs in the CA Community in 
Salesforce.


> There is also a list on that page of certs which CAs have disclosed but
> not provided audit info, but given that you can get off that list by
> putting _anything_ in the relevant box in Salesforce, I'm worried about
> perverse incentives if we go after people on that list at the moment:
> https://crt.sh/mozilla-disclosures#disclosureincomplete


For these I would like to add customization/automation to Salesforce to notify 
CAs when their subCA info is incomplete or out of date (similar to the audit 
reminder emails that get sent monthly). 
But currently we are working on customizing and workflow in Salesforce for CAs 
to be able to directly provide annual updates regarding audit/CP/CPS 
information for their root certs.

Cheers,
Kathleen

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

Re: Action on undisclosed intermediates

[Mark Wane]

On 08/11/16 16:18, Gervase Markham wrote:
> We would choose 3 certs from the list as it exists every Monday at 2pm
> UK time, using the following sources of randomness for the algorithm:
> 
> 1) UK National Lottery "Lotto" numbers, not including bonus ball
> 2) UK National Lottery "Thunderball" numbers, not including Thunderball
> 3) UK National Lottery "Lotto Hotpicks" numbers
> 
> All would be from the draws which take place on the Saturday preceding
> the Monday in question. https://www.national-lottery.co.uk/results
> 
> Comments?
> 
> Gerv
> 

There's a problem with those, Lotto Hotpicks uses the same numbers from
the main Lotto draw. As an alternative I would suggest Friday's
EuroMillions draw.

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

Re: Action on undisclosed intermediates

[Jakob Bohm]

On 08/11/2016 20:37, Gervase Markham wrote:

On 08/11/16 19:11, Jakob Bohm wrote:

However because all the sources are from a single entity (the UK
government), that entity could manipulate the results, thus falsifying
the provable randomness of the process.


I think you are bikeshedding the wrong part of this process.

The draws are televised live, and if someone could predict them, they
would simply clean up on the money side. Also, it's not the UK
government, it's a private company called Camelot.


Also, define the action time in UTC, not UK local time, e.g. 12:00 noon
UTC.


I'm defining it in UK time because it's going to be me doing the work,
and I'm in the UK.



I was merely countering your argument as to why Camelot could not abuse
their use in this formula.  It was about the provability, not their
actual intent to do so.

I was relying on the grandparent post by Alex for the suggestion that
the lottery organization was controlled by the UK government.

But yes, these are minor things, never mind.


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: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 19:11, Jakob Bohm wrote:
> However because all the sources are from a single entity (the UK
> government), that entity could manipulate the results, thus falsifying
> the provable randomness of the process.

I think you are bikeshedding the wrong part of this process.

The draws are televised live, and if someone could predict them, they
would simply clean up on the money side. Also, it's not the UK
government, it's a private company called Camelot.

> Also, define the action time in UTC, not UK local time, e.g. 12:00 noon
> UTC.

I'm defining it in UK time because it's going to be me doing the work,
and I'm in the UK.

Gerv

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

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 19:08, Peter Bowen wrote:
> Yes, that is how one fixes it.  But I'm worried that CAs may think
> they properly followed the requirement and then find themselves
> penalized.  Hence my suggestion to focus on CAs that clearly have not
> even attempted to follow the requirement.

For which of the CAs on the list is this the only problem?

Having asked that, it may be that we have not communicated that we will
be using this list. We should send a final warning email to all affected
CAs about this plan a week or two in advance, and encouraging them to
make sure they aren't on it.

Gerv

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

Re: Action on undisclosed intermediates

[Jakob Bohm]

On 08/11/2016 19:08, Gervase Markham wrote:

On 08/11/16 16:28, alex.gay...@gmail.com wrote:

Is it your intent that once OneCRL-revoked intermediates are brought
into compliance that they'd be removed from OneCRL, or are they gone
for good, a warning sign to those who follow.


TBD. I'm enquiring about whether it's possible to remove certs and, if
it is, what lingering effects (if any) that might have.


PS: Maybe it'd be good to use a source of randomness that is not from
the UK government.


If someone can predict the lottery numbers, I suspect they would put
that power to a different use than deciding which intermediate
certificates Mozilla should distrust.



However because all the sources are from a single entity (the UK
government), that entity could manipulate the results, thus falsifying
the provable randomness of the process.

Note that unlike a 3rd party predicting lottery numbers, the lottery
itself has limited alternative benefit (and no direct downside) to
fiddling its own outcome, as long as noone finds out they did it.

Thus to get this provable randomness, perhaps use lottery numbers from
3 trustworthy lotteries in 3 different parts of the world (who don't
have a "special relationship" in such matters).  For example:

1. One of those UK lotteries

2. A Russian state lottery, if any exist.

3. A Chinese state lottery, if any exist

4. A Japanese state lottery, if one of the above doesn't exist.

Also, define the action time in UTC, not UK local time, e.g. 12:00 noon
UTC.

P.S.

I am aware of the current zero-difference between UK local time and
UTC, but this was not so just 10 days ago.


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: Action on undisclosed intermediates

[Peter Bowen]

On Tue, Nov 8, 2016 at 11:05 AM, Gervase Markham  wrote:
> On 08/11/16 18:25, Peter Bowen wrote:
>> No, the problem is that the Issuer reported their subCA but Salesforce
>> links the audit info to certificates not to CAs.  In the above
>> example, there are three different CA certificates with the same
>> issuer and subject, so the same (sub)CA is in both a "disclosed" and
>> "not disclosed" state.
>
> Is it possible to fix the display by uploading the other two versions of
> the cert and duplicating the audit info?

Yes, that is how one fixes it.  But I'm worried that CAs may think
they properly followed the requirement and then find themselves
penalized.  Hence my suggestion to focus on CAs that clearly have not
even attempted to follow the requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 18:25, Peter Bowen wrote:
> No, the problem is that the Issuer reported their subCA but Salesforce
> links the audit info to certificates not to CAs.  In the above
> example, there are three different CA certificates with the same
> issuer and subject, so the same (sub)CA is in both a "disclosed" and
> "not disclosed" state.

Is it possible to fix the display by uploading the other two versions of
the cert and duplicating the audit info?

(I agree it's not optimal.)

Gerv

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

Re: Action on undisclosed intermediates

[Peter Bowen]

On Tue, Nov 8, 2016 at 10:17 AM, Gervase Markham  wrote:
> Hi Peter,
>
> On 08/11/16 16:53, Peter Bowen wrote:
>> Can the "undisclosed" list be broken down further into "CA not
>> disclosed at all" versus "missing disclosure of some
>> cross-certificate"?
>>
>> For example, ACCVCA-130 is listed under both "Disclosed" and
>> "Unconstrained id-kp-serverAuth Trust".
>> https://crt.sh/?sha256=572bf899fd774362dc19219625ecc157bb55434ea5166d5758dc4b4f890d6653=mozilladisclosure
>> (Disclosed)
>> https://crt.sh/?sha256=8f7cc455e9a5507804120655d7139186253e43b00422e734263a0769d2f89f7d=mozilladisclosure
>> (Not Disclosed)
>
> Both copies are now Disclosed for me. Have things changed since you
> posted this?

Apparently so.

Try this set of three instead:

https://crt.sh/?sha256=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35=mozilladisclosure
(Disclosed)
https://crt.sh/?sha256=870ed91b908c831672003003d451d2eccc13721531129a12f19a4266ce66f935=mozilladisclosure
(Not disclosed)
https://crt.sh/?sha256=376da371d590fed38a0d47bcbae142b04a510373d2976a69348ad1c160f889a0=mozilladisclosure
(Not disclosed)

This shows the issue -- all have the same subject info (DN, SKI, and KeyId).

>> I was very confused about this aspect of the tool, as I know other CAs
>> were, because full audit details were provided for the subordinate CA.
>> The problem is that the Salesforce system is treating
>> cross-certificates as independent even if they have the same subject
>> info (DN, SKI, and KeyId).
>
> So the problem is that the issuer of the cross-cert needs to disclose,
> but if they don't, blame is attributed to the receiver of the cross-cert?

No, the problem is that the Issuer reported their subCA but Salesforce
links the audit info to certificates not to CAs.  In the above
example, there are three different CA certificates with the same
issuer and subject, so the same (sub)CA is in both a "disclosed" and
"not disclosed" state.

>> Why not focus first on the Root CA operators that have failed to
>> disclose _anything_?  From the crt.sh report, it looks like Visa,
>> TurkTrust, SECOM Trust Systems Co. Ltd., RSA the Security Division of
>> EMC, Government of Taiwan: Government Root Certification Authority
>> (GRCA), Government of Japan: Ministry of Internal Affairs and
>> Communications, e-tugra, and certSIGN have entered zero disclosures.
>
> (That would lead to us ignoring 25 of the 90.) We could do that,
> although I'm not so concerned with being "fair" here, given the amount
> of notice everyone has had. There's also a bias in that those CAs which
> issued a lot of intermediates are more likely to get caught than those
> which work through only a few. But I'm not going to try and equalize for
> that either.
>
>> Have they responses to any CA communications?
>
> https://mozillacaprogram.secure.force.com/Communications/CACommSummaryReport?CommunicationID=a05o00iHdtx
> (March 2016 CA Communication responses) shows responses from all of the
> CAs you list, and therefore...
>
>> Have they even
>> established Salesforce accounts?
>
> they must have established Salesforce accounts.
>
> Gerv
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Action on undisclosed intermediates

[Gervase Markham]

Hi Peter,

On 08/11/16 16:53, Peter Bowen wrote:
> Can the "undisclosed" list be broken down further into "CA not
> disclosed at all" versus "missing disclosure of some
> cross-certificate"?
> 
> For example, ACCVCA-130 is listed under both "Disclosed" and
> "Unconstrained id-kp-serverAuth Trust".
> https://crt.sh/?sha256=572bf899fd774362dc19219625ecc157bb55434ea5166d5758dc4b4f890d6653=mozilladisclosure
> (Disclosed)
> https://crt.sh/?sha256=8f7cc455e9a5507804120655d7139186253e43b00422e734263a0769d2f89f7d=mozilladisclosure
> (Not Disclosed)

Both copies are now Disclosed for me. Have things changed since you
posted this?

> I was very confused about this aspect of the tool, as I know other CAs
> were, because full audit details were provided for the subordinate CA.
> The problem is that the Salesforce system is treating
> cross-certificates as independent even if they have the same subject
> info (DN, SKI, and KeyId).

So the problem is that the issuer of the cross-cert needs to disclose,
but if they don't, blame is attributed to the receiver of the cross-cert?

> Why not focus first on the Root CA operators that have failed to
> disclose _anything_?  From the crt.sh report, it looks like Visa,
> TurkTrust, SECOM Trust Systems Co. Ltd., RSA the Security Division of
> EMC, Government of Taiwan: Government Root Certification Authority
> (GRCA), Government of Japan: Ministry of Internal Affairs and
> Communications, e-tugra, and certSIGN have entered zero disclosures.

(That would lead to us ignoring 25 of the 90.) We could do that,
although I'm not so concerned with being "fair" here, given the amount
of notice everyone has had. There's also a bias in that those CAs which
issued a lot of intermediates are more likely to get caught than those
which work through only a few. But I'm not going to try and equalize for
that either.

> Have they responses to any CA communications?  

https://mozillacaprogram.secure.force.com/Communications/CACommSummaryReport?CommunicationID=a05o00iHdtx
(March 2016 CA Communication responses) shows responses from all of the
CAs you list, and therefore...

> Have they even
> established Salesforce accounts?

they must have established Salesforce accounts.

Gerv


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

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 16:47, Kurt Roeckx wrote:
> We also need to have a sorted list of them. I guess the list of crt.sh
> is acceptable. Sorting could for instance been done by sorting based on
> the SHA256.

I was planning to take the list in the order given by crt.sh at 2pm each
Monday, yes.

Gerv

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

Re: Action on undisclosed intermediates

[Gervase Markham]

On 08/11/16 16:28, alex.gay...@gmail.com wrote:
> Is it your intent that once OneCRL-revoked intermediates are brought
> into compliance that they'd be removed from OneCRL, or are they gone
> for good, a warning sign to those who follow.

TBD. I'm enquiring about whether it's possible to remove certs and, if
it is, what lingering effects (if any) that might have.

> PS: Maybe it'd be good to use a source of randomness that is not from
> the UK government.

If someone can predict the lottery numbers, I suspect they would put
that power to a different use than deciding which intermediate
certificates Mozilla should distrust.

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

Re: Action on undisclosed intermediates

[Peter Bowen]

On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham  wrote:
> Of course, if intermediates aren't disclosed, we can't be certain what
> they are, but crt.sh has a good idea of many of them:
> https://crt.sh/mozilla-disclosures#undisclosed
>
> There is also a list on that page of certs which CAs have disclosed but
> not provided audit info, but given that you can get off that list by
> putting _anything_ in the relevant box in Salesforce, I'm worried about
> perverse incentives if we go after people on that list at the moment:
> https://crt.sh/mozilla-disclosures#disclosureincomplete

Can the "undisclosed" list be broken down further into "CA not
disclosed at all" versus "missing disclosure of some
cross-certificate"?

For example, ACCVCA-130 is listed under both "Disclosed" and
"Unconstrained id-kp-serverAuth Trust".
https://crt.sh/?sha256=572bf899fd774362dc19219625ecc157bb55434ea5166d5758dc4b4f890d6653=mozilladisclosure
(Disclosed)
https://crt.sh/?sha256=8f7cc455e9a5507804120655d7139186253e43b00422e734263a0769d2f89f7d=mozilladisclosure
(Not Disclosed)

I was very confused about this aspect of the tool, as I know other CAs
were, because full audit details were provided for the subordinate CA.
The problem is that the Salesforce system is treating
cross-certificates as independent even if they have the same subject
info (DN, SKI, and KeyId).

> Anyway, considering the first list: what do we do? I'm not particularly
> in favour of sending another nagging email. We could just un-trust the
> lot, but that might be quite impactful. So here's my proposal: we play
> Russian Roulette. We choose 3 certs from the list each week and add them
> to OneCRL, and email the CAs concerned to tell them we've done it.
> Hopefully after a few weeks, they'll get the message.

Why not focus first on the Root CA operators that have failed to
disclose _anything_?  From the crt.sh report, it looks like Visa,
TurkTrust, SECOM Trust Systems Co. Ltd., RSA the Security Division of
EMC, Government of Taiwan: Government Root Certification Authority
(GRCA), Government of Japan: Ministry of Internal Affairs and
Communications, e-tugra, and certSIGN have entered zero disclosures.

Have they responses to any CA communications?   Have they even
established Salesforce accounts?

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

Re: Action on undisclosed intermediates

[alex . gaynor]

Hi Gerv,

Is it your intent that once OneCRL-revoked intermediates are brought into 
compliance that they'd be removed from OneCRL, or are they gone for good, a 
warning sign to those who follow.

Alex

PS: Maybe it'd be good to use a source of randomness that is not from the UK 
government.

On Tuesday, November 8, 2016 at 11:19:15 AM UTC-5, Gervase Markham wrote:
> Hi everyone,
> 
> I'd like to take some action about persistent failures to properly
> disclose intermediates. The deadline for this was June, and CAs have had
> a number of reminders, so there's no excuse.
> 
> Of course, if intermediates aren't disclosed, we can't be certain what
> they are, but crt.sh has a good idea of many of them:
> https://crt.sh/mozilla-disclosures#undisclosed
> 
> There is also a list on that page of certs which CAs have disclosed but
> not provided audit info, but given that you can get off that list by
> putting _anything_ in the relevant box in Salesforce, I'm worried about
> perverse incentives if we go after people on that list at the moment:
> https://crt.sh/mozilla-disclosures#disclosureincomplete
> 
> Anyway, considering the first list: what do we do? I'm not particularly
> in favour of sending another nagging email. We could just un-trust the
> lot, but that might be quite impactful. So here's my proposal: we play
> Russian Roulette. We choose 3 certs from the list each week and add them
> to OneCRL, and email the CAs concerned to tell them we've done it.
> Hopefully after a few weeks, they'll get the message.
> 
> RFC 3797 has a handy mechanism called "verifiable random selection",
> which allows you to make a random selection from a list that can be
> publicly verified as random. And, even more handily, I've written an
> implementation of it in JavaScript:
> http://www.gerv.net/hacking/vrs/
> 
> We would choose 3 certs from the list as it exists every Monday at 2pm
> UK time, using the following sources of randomness for the algorithm:
> 
> 1) UK National Lottery "Lotto" numbers, not including bonus ball
> 2) UK National Lottery "Thunderball" numbers, not including Thunderball
> 3) UK National Lottery "Lotto Hotpicks" numbers
> 
> All would be from the draws which take place on the Saturday preceding
> the Monday in question. https://www.national-lottery.co.uk/results
> 
> Comments?
> 
> Gerv

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

Action on undisclosed intermediates

[Gervase Markham]

Hi everyone,

I'd like to take some action about persistent failures to properly
disclose intermediates. The deadline for this was June, and CAs have had
a number of reminders, so there's no excuse.

Of course, if intermediates aren't disclosed, we can't be certain what
they are, but crt.sh has a good idea of many of them:
https://crt.sh/mozilla-disclosures#undisclosed

There is also a list on that page of certs which CAs have disclosed but
not provided audit info, but given that you can get off that list by
putting _anything_ in the relevant box in Salesforce, I'm worried about
perverse incentives if we go after people on that list at the moment:
https://crt.sh/mozilla-disclosures#disclosureincomplete

Anyway, considering the first list: what do we do? I'm not particularly
in favour of sending another nagging email. We could just un-trust the
lot, but that might be quite impactful. So here's my proposal: we play
Russian Roulette. We choose 3 certs from the list each week and add them
to OneCRL, and email the CAs concerned to tell them we've done it.
Hopefully after a few weeks, they'll get the message.

RFC 3797 has a handy mechanism called "verifiable random selection",
which allows you to make a random selection from a list that can be
publicly verified as random. And, even more handily, I've written an
implementation of it in JavaScript:
http://www.gerv.net/hacking/vrs/

We would choose 3 certs from the list as it exists every Monday at 2pm
UK time, using the following sources of randomness for the algorithm:

1) UK National Lottery "Lotto" numbers, not including bonus ball
2) UK National Lottery "Thunderball" numbers, not including Thunderball
3) UK National Lottery "Lotto Hotpicks" numbers

All would be from the draws which take place on the Saturday preceding
the Monday in question. https://www.national-lottery.co.uk/results

Comments?

Gerv

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