Re: PROCERT issues

2017-09-27 Thread 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: PROCERT issues

2017-09-27 Thread Matthew Hardeman via dev-security-policy
On Wednesday, September 27, 2017 at 11:56:27 AM UTC-5, Kathleen Wilson wrote:

> 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 is at least the second recent instance in recent memory where technical 
competencies and/or other issues cause a CA to respond in a less than truthful 
way.  (Startcom, also, but in the original Startcom case it was also alleged 
that there was intentional deception.)

While I think it would be a stretch to suggest that any of PROCERT's answers to 
questions posed to them were deceptive by intention, there were certainly 
statements of fact asserted by PROCERT in their answers which were factually 
incorrect and thus not truthful.  (Particularly responses alleging compliance 
with certain RFCs while this was observably not the case.  I imagine but don't 
recall with specificity that there are other examples).

There also seemed a reluctance to provide real answers to the questions asked 
by the community.

While there was also technical cause to eject these program participants, it 
looks / feels like the community's object to these CAs in the end is really 
about lack of confidence in their responses and willingness to respond.  There 
seemed to be a real reluctance (to put it mildly) in these programs to comply 
with evolving industry requirements.

StartCom's recent attempts to get re-added to the program certainly 
demonstrated some flaws (which StartCom claims they now have a handle on) in 
their stand-up of their new PKI.

In the case of StartCom, I can not help but feel that they are being held to an 
especially high standard (higher than other prior adds to the program) in this 
new PKI because of who they are -- despite the fact that management and 
day-to-day decisions are a completely different team.

Where I am headed with this is a concern that perhaps no amount of technical 
remediation can really get these entities back in the graces of the community.

Honestly, that follows pretty logically.  No technical mitigation on earth is 
an appropriate remedy for any of delays, boilerplate verbiage, or factual 
inaccuracies in responses to community and program inquiries.

To build a remediation plan comprised of technological steps and requirements 
stops far short of actually establishing faith in competency and trust of 
compliance.

I believe this is reflected in the StartCom re-inclusion request.  Certainly 
the level of scrutiny applied is heightened -- and this is not wrong.

On the other hand, if you move to remedies such as sweeping changes in 
management being required, there is the chance that you diminish quality and 
experience of the technical management.  There is a chance of improvement also, 
but it is not a guarantee.

The trouble I see is that re-establishing trust in either of these entities 
pragmatically would require a significant technology remediation as well as 
serious management remediation.

But, looking at the experience StartCom has had -- if you, Kathleen, were 
counsel to StartCom or PROCERT, wouldn't you be saying something along the 
lines of "We need to talk about corporate structure, entity name, etc.   This 
is a whole new management, as required by the program.  The number of 
technological steps asked are significant and tedious.  It's a new house 
anyway, why don't we name it as such, spin up a new corporate entity, stand up 
a new PKI to best practices under custody and management of the new executive 
team and apply to the root program as a new and novel entity -- which you are.  
Let's not bring any unnecessary baggage with the old name."?

I'm not sure the issue has public arisen, but I am guessing that Mozilla and 
the other root programs DO concern themselves with beneficial ownership of the 
various CAs but at the same time, absent evidence of undue influence / coercion 
by beneficial owners, broadly regard the management and operations teams of the 
CA applicant / participant as the key individuals for which trust must be 
vested.

Among the reasons I believe that is there are numerous private equity and/or 
publicly traded entities which wholly own publicly trusted CAs.  There must be 
_some_ actual felons with not insignificant ownership interests in those 
entities.  The executive management and operations teams are likely beyond 
reproach, however.

In summary, it is difficult for me to see how either of PROCERT or StartCom 
would not be better served to start over for real, with trustworthy management 
on all new infrastructure, beneficial ownership be damned because I'm not sure 
you can or would or should care about that end.

It seems to me that any remediation plan which comprises a cross-section of 
both technical issues AND management competencies/trustworthiness that we 
arrive at a plan which is more onerous th

Re: PROCERT issues

2017-09-27 Thread Kathleen Wilson via dev-security-policy
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?

Thanks,
Kathleen



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


Re: TunRootCA2 root inclusion request

2017-09-27 Thread Olfa Kaddachi via dev-security-policy
Hi,

please find at this URL the translation of the root CP/CPS.
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf

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