Re: DarkMatter CAs in Google Chrome and Android

[okaphone.elektronika--- via dev-security-policy]

I did not consider it useful to say it, so I didn't. But I was certainly 
thinking that "try... over the heads of people who make the decision" bit, when 
the "appeal" got posted. ;-)

Is there such a thing as a right to be trusted? Interesting question... I would 
say there isn't, trust cannot be demanded because it's based on other things 
than rules and laws. 

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

Re: Certinomis Issues

[okaphone.elektronika--- via dev-security-policy]

On Friday, 10 May 2019 19:00:11 UTC+2, Wayne Thayer  wrote:

...

> I share the concern that option #2 sends a confusing message. As Jonathan
> stated, why should we distrust a CA for all but the most important websites
> they secure?
 
I'd say that both "too big to fail" and "too important to fail" are not 
particularly good reasons for trusting something/somebody.

It's understandable that as a browser you'd want to limit the collateral damage 
of distrusting a CA, but your first priority should definitely be limiting the 
possible damage from trusting a CA that has turned out not to be trustworthy.

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

Re: A modest proposal for a better BR 7.1

[okaphone.elektronika--- via dev-security-policy]

On Saturday, 9 March 2019 03:44:12 UTC+1, Matthew Hardeman  wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.
> 
> I present alternative language along with notes and rationale which, I put
> forth, would have resulted in a far better outcome for the ecosystem than
> the issues which have arisen from the present BR 7.1 subsequent to ballot
> 164.
> 
> I humbly propose that this would have been a far better starting point, for
> reasons I discuss in notes below.
> 
> Effective as of Month Day, Year, CAs shall generate a certificate serial
> numbers as herein specified:
> 
> 
>1. The ASN.1 signed integer encoded form of the certificate serial
>number value must be represented as not less than 9 bytes and not more than
>20 bytes.  [Note 1]
>2. The hexadecimal value of the first byte of the certificate serial
>number shall be 0x75.  [Note 2]
>3. The consecutive 64 bits immediately following the first byte of the
>encoded serial number shall be the first 64 bits of output of an AES-128
>random session key generation operation, said operation having been seeded
>within random data to within its design requirements. [Note 3]
>4. The remaining bytes of the encoded serial number (the 10th through
>20th bytes of the encoded serial number), to the extent any are desired,
>may be populated with any values. [Note 4]

Is it still important that the random bits are not all zero? Because that seems 
to be omitted here.

And if it is then the next question is: is it still important that the entropy 
of the whole thing is at least 64 bits? For if that is the case then you will 
need at least one more bit in the random part because of the exclusion of the 
all zeroes value, which reduces entropy to slightly below 64 bits.

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[okaphone.elektronika--- via dev-security-policy]

On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer  wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
> this issue.
> 
> Apple has also submitted the following bug for this issue listing a large
> number of impacted certificates:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1533655
> 
> - Wayne

Wow! Looks like there are going to be A LOT of certificates that MUST be 
revoked. Formally correct of course, but could it perhaps be a good idea to 
consider the possibility of handling this one somewhat different? ;-)

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

Re: EJBCA defaulting to 63 bit serial numbers

[okaphone.elektronika--- via dev-security-policy]

On Friday, 8 March 2019 04:28:17 UTC+1, Matt Palmer  wrote:
> On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via 
> dev-security-policy wrote:
> > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > > But BRs are not to be interpreted, just to be applied to the letter,
> > > whether it makes sense or not. When it no longer makes sense, the wording
> > > can be improved for the future.
> > 
> > Indeed.  But following BR 7.1 to the letter apparently doesn't get you all
> > the way to compliance, by some opinions.
> 
> No, *misinterpreting* BR 7.1 doesn't get you all the way to compliance.
> 
> > After all, nothing in 7.1
> > requires anything as to the quality of the underlying CSPRNG utilized.
> 
> The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is
> defined in the BRs.
> 
> > It
> > does not specify whether the 64-bits must be comprised of sequential bits
> > of data output by the CSPRNG,
> 
> Nor does it need to.
> 
> > nor does it specify that one is not permitted
> > to discard inconvenient values (assuming you seek replacement values from
> > the CSPRNG).
> 
> If you generate a 64-bit random value, then discard some values based on any
> sort of quality test, the end result is a 64-bit value with
> less-than-64-bits of randomness.  The reduction in randomness depends on the
> exact quality function employed.
> 
> - Matt

Could be me but when I read this spec as a programmer, I would probably decide 
that the serial number needs to be bigger than 64 bits. After all the specs 
require you to exclude the value zero. Because of that the entropy of the 
serial number can only be at least 64 bits if its size is actually larger than 
64 bits.

And if you need more than 64 bits anyway... having a bit more entropy than 
required is not going to hurt, so I'd probably go for 128 bits. ;-)

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

Re: Fond Farewell to Gerv Markham

[okaphone.elektronika--- via dev-security-policy]

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[okaphone.elektronika--- via dev-security-policy]

"... don't START inventing and applying any unwritten new rules..."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 12 April 2018 21:28:49 UTC+2, Alex Gaynor  wrote:
> All that proves is the entire EV model cannot possibly accomplish what CAs
> claims (with respect to phishing and other similar concerns). To whit:
> 
> - Two companies can validly possess trademarks for the same name in the
> United States (and I assume other jurisdictions)
> - A CA, or anyone else's ability to tell if the identity collision is being
> used maliciously to deceive is totally based on seeing what content is
> being served under that name; the reality of trademark law means that two
> organizations with the same name is not inherently deceptive
> - An actually malicious entity will not broadcast their name collision!
> Instead they'd probably have a benign website that normal users see, and at
> particular URLs sent to their victims, they'd serve the misleading content.
> 
> In conclusion, revoking stripe.ian.sh while ignoring the broader issues WRT
> the limitations of EV's binding of real world corporate identity to domain
> control is security theater at its worst.

Actually as a browser user I've never understood what it is I'm supposed to 
look for in the EV texts being displayed.

There is no definition what is in it nor in what format, many banks here show 
their legal form (which is hardly something people would know or recognize), 
some show the name of a holding they are part of, some don't even have EV, some 
use all capitals, there is not even a requirement that the texts are unique... 
So bottom line it's just free text.

And of very limited use for verifying that it's the organization you are 
looking for, I'd say.

Adding some unspecified and therefore unknown "scrubbing" by CA's to it, does 
not make tings any easier. How am I to know which EV's are protected by that 
and which are not?

For instance, Stripe did not mean anything to me (and most people here in 
Holland I expect) before it got used to demonstrate this "problem". So why 
would our local Stripe, Duerswâld 23, 9241 GW Wijnjewoude not be allowed to 
have just Stripe V.O.F. as their EV? It's only a restaurant, but from Dutch 
perspective a lot more important that some payment provider elsewhere in the 
world.

So I'd say don't inventing and applying any unwritten new rules. It's useless 
enough as it is. ;-)

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

Re: c=US policy layer in development

[okaphone.elektronika--- via dev-security-policy]

On Tuesday, 10 April 2018 01:06:36 UTC+2, Peter Bachman  wrote:
> https://groups.google.com/forum/#!forum/cus-policy-layer

Can you give us a few words, with the links you drop here? It would be nice. 
Especially when in order to see what the link is about you must first become a 
member of the group. :-(
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[okaphone.elektronika--- via dev-security-policy]

On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com  wrote:
> El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com  
> escribió:
> > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > > > I fully understand the proposed solution about 2018 roots but as I 
> > > > > previously said some concerns arise, [...]
> > > > 
> > > > 
> > > > That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> > > > issue. While people have provided some suggestions on how you can 
> > > > create a root that *might* be acceptable, I don't think any of the 
> > > > participants care if Camerfirma has a root accepted; given the issues 
> > > > previously identified and the responses to those issues, I think a 
> > > > number of participants would be just as happy if Camerfirma doesn't get 
> > > > accepted.
> > > > 
> > > 
> > > Hi Tom
> > > I'm just trying to provide a different scenario than create a new root. 
> > > Sure that many participants do not care about our particular 
> > > situation:-(, but this make a big difference for us and also for our 
> > > customers. If the only way to going forward is to create a new root, we 
> > > will do it, but our obligation is trying to provide a more convenient 
> > > solution for Camerfirma without jeopardize the trustworthiness of the 
> > > ecosystem.
> > 
> > Creating a new root by itself will not solve anything. The problem you have 
> > is with trust. It's up to you to offer a root that can be used as a trust 
> > anchor. Reasons why the 2016 root has become unsuitable for this have been 
> > discussed in detail.
> > 
> > The way out can be creating a new root, but that makes only sense if/when 
> > you are sure all problems have been solved and will not happen with the 
> > certificates that would be issued from this new root. If you are not 100% 
> > sure about this, the new root will most likely soon become as useless (for 
> > thrust) as the old one. Please don't do it before you are ready.
> > 
> > CU Hans
> 
> Thank Hans for your comments.
> 
> Completely agree with you about that a new root by itself do not solve the 
> problem.
> 
> We have been working on those aspect detected by Wayne at the beginning of 
> this thread. CPS issues, CAA issues..etc. So we think we are now ready to 
> keep on with the root inclusion. Are we 100% sure ?, No one can assure that 
> of their own systems, but we have placed controls to avoid the known 
> problems, and detect the unknown ones.
> 
> The issue now is choosing the starting point.
> 
> 1.- New root 2018
> 
> 2.- 2016 root, after revoke all certificates (< 100 units) and pass an "Point 
> in Time" BR compliant audit. (Camerfirma proposal)
> 
> 3.- We have send two root to the inclusion process. "Chambers of commerce 
> root 2016", this is the root which has issue a few(4) missunsed certificates 
> https://crt.sh/?cablint=273=50473=2011-01-01, all of them 
> revoked. But we have sent "Chambersign Global Root 2016" as well, and this 
> root is free of issuing errors.
> 
> Our claim to the community is to use as starting point option 2 or option 3.

You still don't seem to understand. This is not about hoops you need to jump 
through to get your root included. It is about trust and it is entirely up to 
you to do whatever is needed to (re)gain that.

You won't get any "requirements" other than the ones you already know all 
about. Some people here may offer you advice they think will help you move 
forward with this. But if that doesn't suit you for one reason or another then 
that is just your choice, no problem. And if you do choose to follow somebody's 
advice, that doesn't imply your root will be included. It's just what they 
think is your best option. But as I said, creating a new root won't help you 
one bit if the problems have not been solved in a way that makes sure they 
won't happen again. Or if further problems will surface.

The bottom line is nothing more and nothing less than making it sufficiently 
plausible as a CA that the root you would like to see included is (and will 
stay) a suitable trust anchor. How you want to do that is your decision. The 
community will and can not make that decision for you. All they have for you is 
feedback (see above).

(Actually I have no idea why I'm telling you all this. You should already 
understand it as a CA. Anyway, just trying to help... ;-)

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[okaphone.elektronika--- via dev-security-policy]

On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > I fully understand the proposed solution about 2018 roots but as I 
> > > previously said some concerns arise, [...]
> > 
> > 
> > That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> > issue. While people have provided some suggestions on how you can create a 
> > root that *might* be acceptable, I don't think any of the participants care 
> > if Camerfirma has a root accepted; given the issues previously identified 
> > and the responses to those issues, I think a number of participants would 
> > be just as happy if Camerfirma doesn't get accepted.
> > 
> 
> Hi Tom
> I'm just trying to provide a different scenario than create a new root. Sure 
> that many participants do not care about our particular situation:-(, but 
> this make a big difference for us and also for our customers. If the only way 
> to going forward is to create a new root, we will do it, but our obligation 
> is trying to provide a more convenient solution for Camerfirma without 
> jeopardize the trustworthiness of the ecosystem.

Creating a new root by itself will not solve anything. The problem you have is 
with trust. It's up to you to offer a root that can be used as a trust anchor. 
Reasons why the 2016 root has become unsuitable for this have been discussed in 
detail.

The way out can be creating a new root, but that makes only sense if/when you 
are sure all problems have been solved and will not happen with the 
certificates that would be issued from this new root. If you are not 100% sure 
about this, the new root will most likely soon become as useless (for thrust) 
as the old one. Please don't do it before you are ready.

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

Re: TunRootCA2 root inclusion request

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com  wrote:
> Dear Wayne,
> Based on the long discussion regarding our request, I would appreciate having 
> your opinion on the following:
> Move to a new root based on EJBCA (Enterprise License) and conduct a new 
> audit with a new auditor as required by Mozilla and the BR.
> We are ready and we do commit to do these steps in 6 months. As we hope that 
> you would accept to resume the inclusion process from this point.
> We are looking forward to hearing from you.
> 
> Syrine.

Do consider that it only makes sense to start with a new root (and do the 
required audits etc.) when you are sure that all problems have been fixed, in 
such a way that they (and others like them) will not happen again.

Because if that isn't the case, the new root will soon be as useless as 
trust-anchor as the old one. The fastest way forward is probably to not try to 
do it quickly.

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

Re: Following up on Trustico: reseller practices and accountability

[okaphone.elektronika--- via dev-security-policy]

On Monday, 5 March 2018 18:10:17 UTC+1, okaphone.e...@gmail.com  wrote:
> On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill  wrote:
> > I think it probably makes more sense to focus on sensitive key material
> > than non-sensitive CSRs.
> > 
> > As a starting point, how reasonable would it be for CAs to question their
> > resellers, or to disseminate additional language to add to their reseller
> > agreements to prohibit non-transactional/ephemeral key storage?
> > 
> > -- 
> > konklone.com | @konklone 
> 
> I remember I read somewhere in the discussion about this incident that 
> Trustico also may have taken normal CSR's from their customers and replaced 
> them with CSR's they generated. Which would typically go unnoticed as they 
> then after singing provided a file (pem or whatever) that could be put on the 
> users webserver "without any further hassle". That is, they private key in 
> that file would be the one Trustico used for that replacement CSR and not the 
> one the customer provided. So, ehm... it worked. ;-)
> 
> I do not know if that is truly what happend. But if it is, it would explain 
> why some people on reddit persisted in saying their key could not have been 
> compromised as they never gave it to Trustico at all, but they still got the 
> notification E-Mail that their certificatie was about to be revoked.
> 
> I don't know if it's worth investigating that angle any further, but it's 
> perhaps a scenario worth considering in this context. For the reseller would 
> strictly not be storing private keys of such subscribers.
> 
> CU Hans

Ah, found it. It was tialaramex who suggested that this could be how Trustico 
got the private keys. 
https://www.reddit.com/r/sysadmin/comments/80uaq3/digicert_certificates_being_revoked/duyg6pn/

Just speculation then. But still worth keeping in mind as something a reseller 
could be doing. I can just see some programmer coming up with this idea to 
workaround the problem of not having the private key. ;-)

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

Re: Following up on Trustico: reseller practices and accountability

[okaphone.elektronika--- via dev-security-policy]

On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill  wrote:
> I think it probably makes more sense to focus on sensitive key material
> than non-sensitive CSRs.
> 
> As a starting point, how reasonable would it be for CAs to question their
> resellers, or to disseminate additional language to add to their reseller
> agreements to prohibit non-transactional/ephemeral key storage?
> 
> -- 
> konklone.com | @konklone 

I remember I read somewhere in the discussion about this incident that Trustico 
also may have taken normal CSR's from their customers and replaced them with 
CSR's they generated. Which would typically go unnoticed as they then after 
singing provided a file (pem or whatever) that could be put on the users 
webserver "without any further hassle". That is, they private key in that file 
would be the one Trustico used for that replacement CSR and not the one the 
customer provided. So, ehm... it worked. ;-)

I do not know if that is truly what happend. But if it is, it would explain why 
some people on reddit persisted in saying their key could not have been 
compromised as they never gave it to Trustico at all, but they still got the 
notification E-Mail that their certificatie was about to be revoked.

I don't know if it's worth investigating that angle any further, but it's 
perhaps a scenario worth considering in this context. For the reseller would 
strictly not be storing private keys of such subscribers.

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

Re: Following up on Trustico: reseller practices and accountability

[okaphone.elektronika--- via dev-security-policy]

On Sunday, 4 March 2018 22:44:26 UTC+1, Paul Kehrer  wrote:
> On March 4, 2018 at 5:06:41 PM, Eric Mill via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
> 
> 
> 
> It's also clear from the experience that rules of the road for resellers
> are unclear, and that accountability is limited. It seems possible, or
> likely, that other resellers may also be mishandling customer keys
> 
> So, what would useful next steps be to improve security and accountability
> for resellers?
> 
> 
> As you already suggested an official communication requesting information
> from the CAs about the way their reseller networks manage subscriber key
> material would be a good start. Eventually I think it's likely that
> resellers need to be subject to some limited form of audit (maybe as
> simplistic as a PCI self-assessment questionnaire?). While that doesn't
> prevent bad behavior it would generate an evidence trail for termination of
> relationships with incompetent/malicious actors.

I'm not sure that that would be reasonable. After all resellers can have 
resellers, and so on so where would that end? With the end user having to 
accept a "general license agreement"? And distrusting a reseller could also be 
difficult.

I think it will have to be/remain the responsibility of the CA to choose their 
reselllers in such a way that "not too many questions are being asked" about 
them.


> Of course, CAs are likely to be reluctant to share a complete list of their
> resellers since they probably consider that competitive information. So, it
> would be nice if we could just make it part of the CA's audits...
> 
> One way to do that would be that the baseline requirements could be updated
> to create a section defining requirements placed upon resellers (especially
> around subscriber key management). This way CAs would be incentivized to
> manage their business relationships more carefully since their business
> partners could cause them audit issues. This has some precedent since in
> the past some resellers acted as RAs and had their own subordinates -- a
> practice that was terminated as they came under scrutiny and demands for
> audits.
> 
> Mozilla, of course, cannot amend the BRs itself. However, past evidence
> suggests that if the Mozilla program introduces their own requirements
> around reseller management and disclosure then the probability of a CABF
> ballot with similar restrictions passing is relatively high (thus getting
> it into the audit regime).
> 
> -Paul

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

Re: PROCERT issues

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 27 September 2017 18:56:27 UTC+2, Kathleen Wilson  wrote:
> In past incidents, we have provided a list of action items that the CA must 
> complete before they can be re-included in Mozilla's root store.
> 
> What action items do you all think PROCERT should complete before they can be 
> re-included in Mozilla's root store?
> 
> What do you think should happen if PROCERT completes those action items 
> before their PSCProcert root is actually removed?

This it about trust. No more, no less. Once you've lost trust, what can be done 
to restore it  really depends on how you've lost it. Jumping through a series 
of Mozilla defined (technical) hoops is never going to be convincing. 
Especially not if it takes more several tries. ;-)

So, was it incompetence? Then show that the lacking skills have be acquired. 
Was it human error? Show that you are not relying on human accuracy anymore. 
Etcetera...

And it makes definitely most sense parties who loose trust come up with a 
relevant plan for this themselves. That is, after identifying what the problem 
was themselves. They will unfortunately have to do that transparently. Here 
where everybody can see it. And where questions can be asked about it and 
answered.

This will definitely be a lot of work and it will certainly not be easy. But 
I'd say that anything less is too little to result in regaining trust.

(Apart from this I personally don't think any CAs will/should be able to find a 
way back from loosing trust through willfully lying.)

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

Re: Certificates with invalidly long serial numbers

[okaphone.elektronika--- via dev-security-policy]

The answers from CAs we typically see in this group are more along the lines of 
not thinking it necessary to revoke at all than needing more time, I'd say. So 
I don't really see what this idea that 24 hours would be too short is based on. 
I think relaxing the revocation time limit may in fact be a solution for a 
problem that doesn't exist (much). After all quite a few of these misissued 
certificates will not even work properly.

What I don't like is that the answers of CAs hardly ever explain what happened, 
how it was possible that it happened and what has/will be done to prevent is 
from happening again. It looks like they have no real incentive to do things 
right.

Yes, in some cases the bad certificates will be in use and the revocation may 
cause problems (not too much I understand as revocation mostly does not work 
;-) for CA-customers and their website visitors. But having to deal with that 
when they are doing it wrong is the only motivation a CA has for doing things 
right. As things are this doesn't seem to motivate them very much. ;-)

And customers will have to learn to choose CAs that don't cause this kind of 
problems. Or suffer them... that is up to them.

On to other hand customers also have little motivation to do things right. To 
most of them HTTPS is something they are forced into by the recent HTTPS-only 
drive by the browsers.

All in all I appreciate how CT is pulling all this garbage into broad daylight. 
We should be simply aiming to get it cleared away. And if there is stuff in 
there that is not worth revoking promptly then it would be better to remove 
theses issuance requirements than to relax the revocation requirement.

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

Re: StartCom cross-signs disclosed by Certinomis

[okaphone.elektronika--- via dev-security-policy]

On Friday, 4 August 2017 03:16:45 UTC+2, Matt Palmer  wrote:
> On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via 
> dev-security-policy wrote:
> > However, I think it is fine for Certinomis to cross-sign with new StartCom
> > subCA certs, as long as Certinomis ensures that Mozilla's Root Store
> > Policy is being followed.
> 
> ... which they didn't.  So there's that.

Exactly.

I don't understand why this discussion seems to be about StartCom. Until they 
re-apply for the root program they have no direct obligation to conform to 
anything anymore. They may have to answer to Certinomis, depending on what was 
agreed with respect to the cross-signing. But that is really only relevant to 
Certinomis and StartCom themselves. Certinomis however, does have a root in 
Mozilla's root program and as such has to answer for any misissuance chaining 
up to their root certificate(s).

In my opinion it would make more sense for Certinomis to decide that they'd 
better revoke their cross-signings than for Mozzilla to add them to OneCRL.

Or am I missing something here?

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

Re: StartCom cross-signs disclosed by Certinomis

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 3 August 2017 02:12:18 UTC+2, Matt Palmer  wrote:
> On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via 
> dev-security-policy wrote:
> > I think the correct response is to add both intermediates to OneCRL
> > immediately, especially given the historic issues with StartCom.
> 
> +1.  Also a strongly worded letter of "are you f%*king kidding me?!?" to
> Certinomis.  Everyone even ephemerally involved in the WebPKI should know by
> now that StartCom/WoSign are viewed with deep suspicion, and blithely
> signing an intermediate for them is not a smart move.
> 
> - Matt

It just means Certinomis now has to answer for the misissuance, doesn't it? I 
don't see the problem. They can choose to risk their own webtrust if they want 
to. ;-)

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

Re: Final Decision by Google on Symantec

[okaphone.elektronika--- via dev-security-policy]

On Friday, 28 July 2017 08:15:43 UTC+2, Gervase Markham  wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv

I can understand that it would be safest (from the point of PR) to remove their 
roots more or less at the same time as Chrome. But the simple fact that 
Symantec is still playing "to big to fail" shows that THEY will not do what is 
in the interest of the browser users... Browsers and browser users will 
therefore have to fend for themselves. I'd say allowing them until november 1st 
is a very generous implementation of "some time in 2018" and will have to do 
for them. After all they have been dragging their feet for months now. They 
could actually have used all that wasted time... ;-)

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

Re: WoSign new system passed Cure 53 system security audit

[okaphone.elektronika--- via dev-security-policy]

On Friday, 14 July 2017 04:44:39 UTC+2, Richard Wang  wrote:
> Hi Peter,
> 
> Thanks for your guesses.
> Buy no those issues in our system.
> 
> 
> Best Regards,
> 
> Richard

That's what you say. But you've lied before. :-( So sorry, but that won't go 
anywhere near regaining trust. You'll have to be quite a bit more transparant 
before anything you say will be believed.

I really don't see why you post this summary at a time when you have not yet 
told us anything about the items that went before it. Or should have gone 
before?

The summary itself doesn't say much. But some things can be read between the 
lines.

There was a penetration test and they found problems which you then fixed 
quickly. Sounds like you did not do anything about the reason why those 
problems were in your code. So there will probably be more. That in itself is 
not surprising, but a team that quickly fixes those problem is. They should 
instead have done an an analyses why those problems were there in the first 
place and fixed there software development practices/process, then let that 
take care of fixing the problems.

There was a code review. But we don't hear anything about what the outcome was. 
There may have been findings but more import is what the overall quality of the 
code is. And still more important is what the quality of your development 
process is.

Are there unit tests, integration tests, what is the coverage, how complete is 
the documentation, specs, structure of the code, how good the layering, how 
complex is it, how maintainable, how correct, are you using version control, 
release management, code quality scanners?

All that is not covered by a penetration test and only some of it by a code 
review. So item five is really not all that important. It is just an extra 
insurance that all is well after all the other work has been done.

I still think that it would make most sense to start by showing us this item 
one. That would be a real step towards regaining trust.

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

Re: WoSign new system passed Cure 53 system security audit

[okaphone.elektronika--- via dev-security-policy]

On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang  wrote:
> 
> Please note this email topic is just for releasing the news that WoSign new 
> system passed the security audit, just for demonstration that we finished 
> item 5:
>  " 5. Provide auditor[3] attestation that a full security audit of the CA’s 
> issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by Mozilla. "

It also seems a bit strange to report item 5 "successfully completed" before we 
hear anything about the other items. How about starting with item 1? What are 
your plans voor fixing the problems?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham  wrote:
> On 11/05/17 13:02, wiz...@ida.net wrote:
> > That said, it is fair point that the plan should spell out what happens if 
> > symantec does not cooperate. 
> 
> I think we should cross that bridge when we come to it, which I hope we
> won't. Not that I'm not prepared to cross it, but there's no point
> devising plans and writing text in advance for a situation which can be
> dealt with when and if it occurs.
> 
> Gerv

Better keep your deadlines short then. They seem to be the only times Symantec 
actually responds to anything asked/said here. :-(

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

Re: Symantec: Update

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham  wrote:
> On 09/05/17 16:51, Gervase Markham wrote:
> > * Editing the proposal to withdraw the "alternative" option, leaving
> > only the "new PKI" option. 
> 
> This has now been done:
> 
> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
> 
> > * Engagement here in m.d.s.p. with the community to refine and flesh out
> > the "new PKI" proposal, based on the Google outline but examining it and
> > enhancing it to make sure it is practical, both from an implementation
> > perspective and to reduce disruption to sites as far as possible.
> 
> I would appreciate people's comments on the details of the current draft.

Makes sense to me.

But it does seem to assume that Symantec will cooperate with this. What happens 
if they decide not to is less clear. Perhaps it would be a good idea to 
indicate which steps will be taken in any case?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[okaphone.elektronika--- via dev-security-policy]

Hi Rick,

I don't see a "May 4th post". Where was it posted? Not here it seems.

Also it's reasonable that Symantec wants to "address impact to their customers" 
but what about impact to all of the browsers users? It may be a good idea to 
try and address (in your proposals) that to.

So far I have not seen much more than "trust us, we take it seriously and we'll 
do it right from now on". But what do you think of Eric's idea? He seems to 
suggest a way forward that may be used to turn the whole debacle into an 
advantage for you.

CU Hans


On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews  wrote:
> I'm posting this on behalf of Symantec:
> 
> We would like to update the community about our ongoing dialogue with Google. 
>  
>  
> Following our May 4th post, senior executives at Google and Symantec 
> established a new dialogue with the intention to arrive at a new proposal for 
> the community that addresses the substantial customer impact that would 
> result from prior proposals. We urge Symantec customers and the browser 
> community to pause on decisions related to this matter until final proposals 
> are posted and accepted. The intent of both Google and Symantec is to arrive 
> at a proposal that improves security while minimizing business disruption 
> across the community.
>  
> We want to reassure the community that we are taking these matters and the 
> impact on the community very seriously.

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 27 April 2017 00:42:20 UTC+2, Ryan Sleevi  wrote:
> On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> >
> > If this is about the possible consequences of compromise, then I'd say you
> > should try to adres that. But please do come up with something that still
> > allows for enough flexibility, so I can arrange the HTTPS everywhere you
> > guys (browsers that is ;-) want so much. At least while there is only a
> > single CA (LetsEncrypt) that offers an alternative for wildcards for a
> > reasonable fixed price.
> >
> 
> I'm not sure your concern - there's otherwise been broad support for
> wildcards, only concerns related to the methods used to validate them to
> ensure they're meaningful.
> 
> 
> > After all the internet is also about variety isn't it? Seems to me there
> > are not all that much CA's around... I do like the LetsEncrypt initiative
> > but I also do hope they will not become the only choice. :-(
> >
> > I could live with wildcards that would only work for one DNS level for
> > instance. Would that be an improvement?
> 
> 
> They already only work for one DNS level, as a certificate. The
> authorization the CA performs, however, lets them issue wildcards for any
> number of subordinate subdomains - but only one wildcard in each, and each
> certificate only covers a single hierarchy.
> 
> I realize that the conversation may be complex here, but I think it might
> be best to simply assure you that your concerns are not misunderstood, but
> more importantly, they are unwarranted, because no one is discussing
> anything that would (negatively) impact the set of use cases you've
> described so far. It's probably just a misunderstanding as to what's being
> discussed and the subtlety of the validation points :)

Well, sorry I misunderstood then. And thanks for reassuring me. ;-)

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 26 April 2017 22:43:19 UTC+2, Ryan Sleevi  wrote:
> On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika wrote:
> 
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt does
> > not do anything beyond domain validation and possibly on notification take
> > down a few certificates of phishing site. And that was "... all OK because
> > we want SSL to be used everywhere, and anyway domain validation means just
> > that, nothing more..."
> >
> > And now you guys are suddenly seeing problems in wild card certificates
> > "... because it could be use for phishing..." Ehm, what?
> 
> Could you point to examples? I think the tone of this thread has almost
> universally been consistent with the people who have said phishing isn't
> for the CAs :)

Good, I guess I simplified that to the point of not being correct anymore then. 
Just read "incidental effects of compromise" where I said phishing. It doesn't 
change what I'm saying all that much. After all LetsEncrypt can also be abused 
for this when a site has been compromised. ;-)


> > I like it this way. Thats why I'm paying Comodo for their services. If you
> > are going to make this kind of thing impossible then you are:
> 
> Who do you believe "you guys" are?

Well anybody in here in favour of doing away with wildcard certificates. It's a 
forum, anybody can join the discussion don't they? (Even though "some pigs may 
be more equal" in this context I expect. ;-)

 
> > 1) Frustrating me.
> >
> > 2) Causing Comodo to lose business, for I will have to use LetsEncrypt
> > instead.
> >
> > 3) Putting all my eggs in one basket (there is currently no alternative
> > for LetsEncrypt).
> >
> > 4) Not solving the problem at all, it's easy to get a certificate for a
> > phishing domain from LetsEncrypt.
> >
> > 5) Trying to do something that certificates are not meant for. I don't
> > think it is (or should be) the responsibility of CA's to verify that sites
> > are not used for phishing.
> 
> I think almost everyone on this thread has expressed general agreement :)
> 
> I think you may be confusing the phishing discussion (which was only
> brought up once or twice) with the general _capability_/_security_
> discussion, for which a wildcard certificate has unlimited capability (over
> a subdomain), and thus much greater risk, and the desire to balance that
> risk.
> 
> The risk is not phishing. The risk is incidental effects of compromise.
> It's no different than a discussion of compromise of a technically
> constrained sub-CA (which is an 'ultra-wildcard') or of an unconstrained
> sub-CA/CA itself (which is a 'global-wildcard'). Each level has different
> risks, and we want to make sure they're all treated accordingly. Phishing
> has not been preeminent among that discussion of risks, and so if that's
> your takeaway, I would say the message on this thread has been fairly
> consistent in agreeing with you that certs don't solve phishing.

If this is about the possible consequences of compromise, then I'd say you 
should try to adres that. But please do come up with something that still 
allows for enough flexibility, so I can arrange the HTTPS everywhere you guys 
(browsers that is ;-) want so much. At least while there is only a single CA 
(LetsEncrypt) that offers an alternative for wildcards for a reasonable fixed 
price.

After all the internet is also about variety isn't it? Seems to me there are 
not all that much CA's around... I do like the LetsEncrypt initiative but I 
also do hope they will not become the only choice. :-(

I could live with wildcards that would only work for one DNS level for 
instance. Would that be an improvement?

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

I think this is getting weird.

At first (some other thread) it get's explained that e.g. LetsEncrypt does not 
do anything beyond domain validation and possibly on notification take down a 
few certificates of phishing site. And that was "... all OK because we want SSL 
to be used everywhere, and anyway domain validation means just that, nothing 
more..."

And now you guys are suddenly seeing problems in wild card certificates "... 
because it could be use for phishing..." Ehm, what?

Our site (category tiny) has LetsEncrypt certificates on several domain names 
and a single Comodo wildcard certificate for okaphone.com,*okaphone.com. We 
currently have the following set of domain names in the global DNS:

klant.okaphone.com
munin.okaphone.com
hans.okaphone.com
kassa.okaphone.com
ntp.okaphone.com
okaphone.com
stats.okaphone.com
svn.okaphone.com
vpn.okaphone.com
webcam.okaphone.com
www.okaphone.com

I terminate HTTPS with Pound and distribute the traffic from there to a number 
of servers (I'll spare you the details ;-). This setup gives me flexibility and 
it changes regularly for all kinds of reasons that have to do with our business.

I like it this way. Thats why I'm paying Comodo for their services. If you are 
going to make this kind of thing impossible then you are:

1) Frustrating me.

2) Causing Comodo to lose business, for I will have to use LetsEncrypt instead.

3) Putting all my eggs in one basket (there is currently no alternative for 
LetsEncrypt).

4) Not solving the problem at all, it's easy to get a certificate for a 
phishing domain from LetsEncrypt.

5) Trying to do something that certificates are not meant for. I don't think it 
is (or should be) the responsibility of CA's to verify that sites are not used 
for phishing.

I'd say, this is not a good idea at all. :-(

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[okaphone.elektronika--- via dev-security-policy]

Right. It is then.

It says private keys can only be stored with permission of the subscriber and 
encryption must always be used to transfer them. And of course the certificate 
must be revoked if/when it becomes known that a private key has gotten to the 
wrong person.

Well... NOT my private keys. I'll create the CSR myself, thank you. ;-)

Anyway, would be nice if there was some evidence in this thread.

CU Hans

On Thursday, 30 March 2017 00:31:50 UTC+2, Ryan Sleevi  wrote:
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
> 
> Section 6.1.2
> 
> On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> 
> > Weird.
> >
> > I expect there are no requirements for a CA to keep other people's private
> > keys safe. After all handling those is definitely not part of being a CA.
> > ;-)
> >
> > CU Hans
> > ___
> > 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: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[okaphone.elektronika--- via dev-security-policy]

Weird.

I expect there are no requirements for a CA to keep other people's private keys 
safe. After all handling those is definitely not part of being a CA. ;-)

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

Re: Google Trust Services roots

[okaphone.elektronika--- via dev-security-policy]

It's probably my ignorance in these matters, but how does purchasing a root 
certificate affect revocation?

Will that remain the responsibility of GlobalSign for any existing certificates 
that have been signed with these roots? (Those would be intermediate 
certificates, if I understand correctly.) Or does revocation also require 
signing, and does it therefore become the responsibility of the new owner of 
the roots?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Suspicious test.com Cert Issued By GlobalSign

[okaphone.elektronika--- via dev-security-policy]

On Friday, 17 March 2017 17:28:12 UTC+1, douglas...@gmail.com  wrote:
> On Friday, March 17, 2017 at 5:37:38 AM UTC-4, Gervase Markham wrote:
> > On 16/03/17 17:20, douglas beattie wrote:
> > > Yes, RAs (trusted role employees) need to have the technical ability
> > > to manually add domains to accounts.  They can verify domains in one
> > > of the 10 different methods and some of those involve manually
> > > looking in who-is for registrant info, using a DAD or in calling the
> > > contact.  When one of these is used, we collect the vetting data then
> > > the RA can add/approve that domain.
> > 
> > But is the addition of the domain gated on the
> > uploading/attachment/submission of what could plausibly be vetting data?
> 
> It's gated on the RA following the correct process which is uploading the 
> documents in one system and then approving the domain in a different system.
> 
> > I mean, I understand you can't programmatically check that a person has
> > made a phone call. But you can require them to write a report of the
> > results of that phone call and not allow addition of the domain until
> > they've done it. Yes, they could just put "flibbertigibbet" into the
> > text box, but that at least shows they are deliberately bypassing the
> > process.
> > 
> > If the addition is so gated, what did the employee in this case do? Did
> > they upload bogus data?
> 
> No bogus data was uploaded.
> 
> Doug

The suspense is killing... What "non bogus" data was uploaded then? Can't have 
been any "plausible vetting data" can it?

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

Re: Intermediates Supporting Many EE Certs

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 1 March 2017 12:44:16 UTC+1, Gervase Markham  wrote:
> On 13/02/17 12:23, Gervase Markham wrote:
> > The GoDaddy situation raises an additional issue.
> 
> > What can be done about the potential future issue (which might happen
> > with any large CA) of the need to untrust a popular intermediate?
> > Suggestions welcome.
> ...
> If customers tend to renew annually, one could imagine a "January
> intermediate", "February intermediate" and so on, and one uses the
> former every January, etc.
> ...

Or a different intermediate each day? ;-)

I guess what you really are looking for is being able to distrust a CA for a 
date range. Any requirement that doesn't produce that is probably not worth the 
effort.

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

Re: Intermediates Supporting Many EE Certs

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 15 February 2017 18:27:28 UTC+1, Gervase Markham  wrote:
> On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote:
> > Isn't this mostly something that CAs should keep in mind when they
> > setup "shop"?
> > 
> > I mean it would be nice to have a way of avoiding that kind of impact
> > of course, but if they think it's best to put all their eggs in one
> > basket... ;-)
> 
> Well, if it's harder for us to dis-trust an intermediate with many leafs
> due to the site impact, the CA may decide to do it that way precisely
> because it is harder!

Ehm... play chicken? Nah, perhaps better not. ;-)

So you really would like to make distrust more doable. But if it doesn't "hurt" 
enough you don't get the effect you want either. Difficult to know what level 
would be optimum.

So I guess that means what you really need is a certain scalability in the 
solution.

(Thanks for explaining. I'm just trying to understand what is happening here.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy