RE: PROCERT issues

2017-10-05 Thread Inigo Barreira via dev-security-policy 
Has this been asked ever? Has any other CA published it? It´s just to know. 
And, is there a "default" scope for this kind of security audits?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: jueves, 5 de octubre de 2017 11:48
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: PROCERT issues
> 
> On 05/10/17 15:32, Inigo Barreira wrote:
> > I know this reply is not related to the email thread but wouldn´t like
> > to leave the feeling that the code we are using is bad, or not secure, etc.
> 
> Perhaps now might be a good time to publish the security audits that were
> done on the code, then?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: PROCERT issues

2017-10-04 Thread Kathleen Wilson via dev-security-policy 
Bug Filed regarding PROCERT Action Items:
https://bugzilla.mozilla.org/show_bug.cgi?id=1405862

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

Re: PROCERT issues

2017-10-03 Thread Ryan Sleevi via dev-security-policy 
Hi Kathleen,

With respect to providing a list - is there any requirement to ensure
Mozilla accepts that as a reasonable remediation?

For example, would "We plan to not do the same in the future" be an
acceptable remediation plan? As currently worded, it would seem to meet the
letter of this requirement.

This would be useful to ensure before [2]

On Tue, Oct 3, 2017 at 10:38 AM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Here's a draft of the Bugzilla Bug that I plan to file to list the action
> items for PROCERT to complete before they may re-apply for inclusion in
> Mozilla's Root Store. I will appreciate feedback on this.
>
> == DRAFT ==
> Subject: PROCERT: Action Items
>
> As per Bug #1403549 the PSCProcert certificate will be removed from
> Mozilla’s Root Store due to a long list of problems and they way that
> PROCERT responded to those problems (and to previous CA Communications).
> For details about the problems, see Bug #1391058 and
> https://wiki.mozilla.org/CA:PROCERT_Issues
>
> The purpose of this bug is to record the action items that PROCERT must
> complete before their certificate may be included as a trust anchor in
> Mozilla’s Root Store again.
>
> PROCERT may apply for inclusion of a new certificate[1] following
> Mozilla's normal root inclusion/change process[2], after they have
> completed all of the following action items.
>
> 1. Provide a list of changes that the CA plans to implement to ensure that
> there are no future violations of Mozilla's CA Certificate Policy and the
> CA/Browser Forum's Baseline Requirements.
>
> 2. Implement the changes, and update their CP/CPS to fully document their
> improved processes.
>
> 3. Provide a reasonably detailed[4] public-facing attestation from a
> licensed auditor[3] acceptable to Mozilla that the changes have been made.
> This audit may be part of an annual audit.
>
> 4. Provide auditor[3] attestation that a full performance audit has been
> performed confirming compliance with the CA/Browser Forum's Baseline
> Requirements. This audit may be part of an annual audit.
>
>
> Notes:
> [1] The new certificate (trust anchor) may be cross-signed by the removed
> certificate. However, the removed certificate may *not* be cross-signed by
> the new certificate, because that would bring the concerns about the
> removed certificate into the scope of the new trust anchor.
> [2] Mozilla's root inclusion/change process includes checking that
> certificates in the CA hierarchy comply with the CA/Browser Forum's
> Baseline Requirements.
> [3] The auditor must be an external company, and approved by Mozilla.
> [4] “detailed” audit report means that management attests to their system
> design and the controls they have in place to ensure compliance, and the
> auditor evaluates and attests to those controls. This assertion by
> management - and the auditor's independent assessment of the factual
> veracity of that assertion - will help provide a greater level of assurance
> that PROCERT has successfully understood and integrated the BRs.
> ==
>
> Thanks,
> Kathleen
>
> ___
> 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: PROCERT issues

2017-10-02 Thread Ryan Sleevi via dev-security-policy 
On Mon, Oct 2, 2017 at 10:42 AM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote:
> > That dynamic is natural, but accepting that this dynamic exists is
> > different than giving into it in some absolute way. When offering second
> > chances, requiring that the person/org fulfill certain conditions that
> > speak directly to their ability to have learned and adapted from the
> thing
> > they failed at the first time is an approach that accepts this dynamic,
> > without shutting the door on people or organizations that have grown as a
> > result of the experience.
> >
> > I think it would arguably lead to worse behavior, and less disclosure of
> > incidents and mistakes, if Mozilla adopted a posture where second chances
> > are rarely given. Not saying that's what's being said here, but I think
> > it's worth emphasizing that the first principle here should be to
> optimize
> > for incentivizing the behavior you want out of the CA community that
> > protects users and increases information sharing.
> >
> > -- Eric
>
>
> I agree with Eric on this.
>
> The last sentence in our CA Communications and Mozilla Security Blog Posts
> regarding our CA Program is frequently:
> "... we believe that the best approach to safeguard that security is to
> work with CAs as partners, to foster open and frank communication, and to
> be diligent in looking for ways to improve."
>
> Below are my personal feelings...
>
> In the case of WoSign and StartCom, I felt such a level of deception that
> it will be extremely difficult for either CA to ever gain my trust again.
> Rightly or wrongly so, I have not recognized that level of deception from
> other CAs in Mozilla's program. The deception happened before Inigo went to
> StartCom, and I appreciate all of Inigo's efforts, but due to the position
> he is now in, he will have to do an outstanding job, be test-driven, and
> demonstrate a truly clean CA hierarchy in order to regain my trust in
> StartCom. Unfortunately, I just don't feel that I've seen that so far.
>
> In regards to PROCERT, I do not believe that they have intentionally
> deceived me, but that their representatives responded to previous CA
> Communications and the Bugzilla Bug without getting their technical people
> involved. That is very bad! and I am very disappointed! But perhaps there
> are actions that they can take to demonstrate their commitment to not
> repeating those mistakes, to putting code into place to prevent
> non-BR-compliant cert issuance, and to show that they do have the level of
> technical knowledge in their organization that is needed to operate a good
> CA.
>

These are also my personal feelings, and not speaking on behalf of Mozilla
or Google.

I think these are excellent ways of framing the discussion, given the
current state of the ecosystem and the incentives. I think attempting to
blackball a CA organization is largely ineffective, for reasons others have
highlighted - such as the lack of transparency around beneficial or
controlling interests.

With respect to PROCERT, I think it's important to note that there are
several problematic practices:
- The displayed technical competence was grossly insufficient for the level
of trust afforded.
- The technical responses (continue) to demonstrate a degree of
interpretative leeway that is not supported by the text.
- The sum totality of the number and nature of the incidents raise serious
concerns about the overall operation.

Unlike other incidents, there's no one "Fix this thing" incident - it's a
systemic failure of both implementation and oversight that caused the loss
of a trust, a dozen of incidents both big and small, and the response to
those incidents, that caused a loss of trust.

I think it's reasonable to suggest that developing technical competence is
not something that will happen overnight. And systemically addressing the
organizational and operational failures will require a careful degree of
analysis of the past issues and preventive steps (of which revocation is,
again, completely insufficient).

We've also seen from past incidents and discussions that one year is very
likely too short a time to allow such remediations. If anything, it
incentivizes hasty changes, rather than methodical analysis. It's very
likely that, for an organization like PROCERT, it would be far more
appropriate to suggest something like three or more years - to allow them
the opportunity to invest and improve.

Similarly, given the nature of these incidents, it seems reasonable to
suggest that new keys must be used, without any relation to the old keys or
infrastructure. This hopefully goes without saying.

In terms of oversight and audits, it seems beneficial to have a
community-agreed upon auditor, a Mozilla-delegated auditor, or even an open
RFP, so that auditors themselves can compete on the thoroughness and
oversight that they can provide.

Re: PROCERT issues

2017-10-02 Thread Kathleen Wilson via dev-security-policy 
On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote:
> That dynamic is natural, but accepting that this dynamic exists is
> different than giving into it in some absolute way. When offering second
> chances, requiring that the person/org fulfill certain conditions that
> speak directly to their ability to have learned and adapted from the thing
> they failed at the first time is an approach that accepts this dynamic,
> without shutting the door on people or organizations that have grown as a
> result of the experience.
> 
> I think it would arguably lead to worse behavior, and less disclosure of
> incidents and mistakes, if Mozilla adopted a posture where second chances
> are rarely given. Not saying that's what's being said here, but I think
> it's worth emphasizing that the first principle here should be to optimize
> for incentivizing the behavior you want out of the CA community that
> protects users and increases information sharing.
> 
> -- Eric


I agree with Eric on this.

The last sentence in our CA Communications and Mozilla Security Blog Posts 
regarding our CA Program is frequently:
"... we believe that the best approach to safeguard that security is to work 
with CAs as partners, to foster open and frank communication, and to be 
diligent in looking for ways to improve."

Below are my personal feelings...

In the case of WoSign and StartCom, I felt such a level of deception that it 
will be extremely difficult for either CA to ever gain my trust again. Rightly 
or wrongly so, I have not recognized that level of deception from other CAs in 
Mozilla's program. The deception happened before Inigo went to StartCom, and I 
appreciate all of Inigo's efforts, but due to the position he is now in, he 
will have to do an outstanding job, be test-driven, and demonstrate a truly 
clean CA hierarchy in order to regain my trust in StartCom. Unfortunately, I 
just don't feel that I've seen that so far.

In regards to PROCERT, I do not believe that they have intentionally deceived 
me, but that their representatives responded to previous CA Communications and 
the Bugzilla Bug without getting their technical people involved. That is very 
bad! and I am very disappointed! But perhaps there are actions that they can 
take to demonstrate their commitment to not repeating those mistakes, to 
putting code into place to prevent non-BR-compliant cert issuance, and to show 
that they do have the level of technical knowledge in their organization that 
is needed to operate a good CA.

Thanks,
Kathleen





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

Re: PROCERT issues

2017-10-02 Thread alejandrovolcan--- via dev-security-policy 
Dear Mozilla CA Root Team,
 
After reviewing Mr. Gervase's reply, referring to the exclusion of the PSC 
PROCERT from the Mozilla trust repository and having seen the antecedents 
existing in multiple previous cases, it is evident that in all cases it was 
offered through the bug of a mechanism of remediation and the ACs were 
adequately informed about the open observations and even in some cases are 
closed with simple statements about how the case is remedied.
 
The technical aspects indicated in the bug and its answers are included below:
 
1. Serial Number does not meet the standard.
RFC 5280, in section 4.1.2.2 states the following:
 
“4.1.2.2. Serial Number
The serial number MUST be a positive integer assigned by the CA to each 
certificate. It MUST be unique for each certificate issued by a given CA (i.e., 
the issuer name and serial number identify a unique certificate).  CAs MUST 
force the serialNumber to be a non-negative integer.
Given the uniqueness requirements above, serial numbers can be expected to 
contain long integers. Certificate users MUST be able to handle serialNumber 
values up to 20 octets. Conforming CAs MUST NOT use serialNumber values longer 
than 20 octets.
Note: Non-conforming CAs may issue certificates with serial numbers that are 
negative or zero. Certificate users SHOULD be prepared to gracefully handle 
such certificates”
 
In addition, section 7.1 of the BR indicates the following:
 
“Effective September 30, 2016, CAs SHALLgenerate non‐sequential Certificate 
serial  numbers greater than zero  (0) containing  at least 
  64 bits  of output   from   aCSPRNG.”
 
PSC PROCERT works with the Microsoft cryptography service, which has a CSPRNG 
inside the CryptoAPI library suite, which includes a CryptGenRandom function, 
which is a cryptographically secure pseudo-random number generator, this 
function was found by default in the generation of the short serial numbers, 
therefore we proceeded to modify the registry of the CA and activate the option 
of high serial, which comes by default deactivated (0), we proceeded to 
activate this registry, so that serials are generated under the parameters of 
the standard.
 
In the following link you can see an example of a certificate with the 
appropriate serial number
 
https://crt.sh/?id=204446748
 
After this action was taken, we proceeded to recognize the certificates with 
these problems and were notified to our clients that they should be revoked and 
reissued, the certificates denounced in the bug are revoked.
 
PSC PROCERT is not the only one to present this case, QuoVadis and SwissSign, 
presented the same situation and the remediation was accepted.
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391063
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391066
 
 
Note that the answers offered by QuoVadis and SwissSign were simple and not 
detailed; such as those offered by PROCERT, the response and follow-up on 
compliance was further expanded. We do not understand then why for other cases 
apply and for PROCERT not ?.
 
2.-  Issues with SSL Certificates
   Issue D: URI in CN and dnsName SAN (December 2016)
   Issue G: Internal IP Address in SAN (March 2015 - March 2017)
   Issue I: CN Not Also In SAN (March 2016 - June 2017)
   Issue K: Internal DNS Names in Certificates (May - June 2017)
   Issue L: helloburgershack.com (June - July 2017)
 
2.1.Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString 
(December 2015 - August 2017)
Taking into account what was stated in the bug, the BR was reviewed and it 
indicates the following in section 7.1.4.2.2
 
“j. Other Subject Attributes
All  other  optionalattributes, when  present within  
the  subject field,   MUST contain information thathas 
been  verified by  the CA.  Optional   
attributes  MUST NOT contain metadata  such   as  ‘.’,   ‘‐‘,   
   and‘ ‘ (i.e.  space) characters,  and/or any 
other  indication  thatthe value  isabsent, 
incomplete,   or   not applicable.e.”
 
In addition, section 7.4.2.1 states the following
 
“7.1.4.2.1. Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required  
Contents: Thisextension  MUST contain at   least   one  
entry. Each   entry MUST  be either adNSName containing the 
 Fully‐Qualified Domain Name  or   an  iPAddress containing 
the IP addressof   aserver.
TheCA MUST confirmthatthe Applicant  controls   
   the Fully‐Qualified Domain  Name or IP   addressor   has 
 been   grantedtheright   to use itby  the 
Domain  Name Registrant or IP

Re: PROCERT issues

2017-09-29 Thread Eric Mill via dev-security-policy 
On Thu, Sep 28, 2017 at 12:50 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 27/09/17 18:54, Matthew Hardeman wrote:
> > 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.
>
> I don't know if it's quite as absolute as that, but recent incidents
> have caused me to ponder somewhat on the nature of trust. The root
> program is all about trust, and trust is not something which can be
> encoded in audits, checkboxes and rules. This will always be a tension
> at the heart of our root program - we are trying to be as objective as
> we can about something which is ultimately subjective.
>
> The nature of trust is that it's harder to regain than it is to gain in
> the first place. Just ask someone who's been the victim of adultery - or
> someone who is a now-repentant adulterer. Rightly or wrongly, people get
> a first chance, but it's tough to get a second. I think you are right
> when you conclude that this is just the way of things, and we should
> accept it rather than kick against it.
>

That dynamic is natural, but accepting that this dynamic exists is
different than giving into it in some absolute way. When offering second
chances, requiring that the person/org fulfill certain conditions that
speak directly to their ability to have learned and adapted from the thing
they failed at the first time is an approach that accepts this dynamic,
without shutting the door on people or organizations that have grown as a
result of the experience.

I think it would arguably lead to worse behavior, and less disclosure of
incidents and mistakes, if Mozilla adopted a posture where second chances
are rarely given. Not saying that's what's being said here, but I think
it's worth emphasizing that the first principle here should be to optimize
for incentivizing the behavior you want out of the CA community that
protects users and increases information sharing.

-- Eric


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



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

Re: PROCERT issues

2017-09-28 Thread Gervase Markham via dev-security-policy 
On 27/09/17 18:54, Matthew Hardeman wrote:
> 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.

I don't know if it's quite as absolute as that, but recent incidents
have caused me to ponder somewhat on the nature of trust. The root
program is all about trust, and trust is not something which can be
encoded in audits, checkboxes and rules. This will always be a tension
at the heart of our root program - we are trying to be as objective as
we can about something which is ultimately subjective.

The nature of trust is that it's harder to regain than it is to gain in
the first place. Just ask someone who's been the victim of adultery - or
someone who is a now-repentant adulterer. Rightly or wrongly, people get
a first chance, but it's tough to get a second. I think you are right
when you conclude that this is just the way of things, and we should
accept it rather than kick against it.

Gerv
___
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 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

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: PROCERT issues

2017-09-26 Thread urijah--- via dev-security-policy 
Why does the document say "Date: 11/07/17" on every page, and the signed pdf 
metadata say

2017-09-25T17:14:35-04:00
2017-09-25T17:18:07-04:00
2017-09-25T17:18:07-04:00

On Tuesday, September 26, 2017 at 4:56:36 PM UTC-4, alejand...@gmail.com wrote:
> In the following link you can find the CPS in English language
> 
> https://www.procert.net.ve/documentos/CPS-PROCERT.pdf

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

Re: PROCERT issues

2017-09-21 Thread Patrick Figel via dev-security-policy 
On 21/09/2017 23:08, alejandrovolcan--- via dev-security-policy wrote:
> Dear Gerv, I have attached a document that gives us a greater
> response to each of the points, as well as Mr. Oscar Lovera sent you
> an email with the same information
> 
> https://www.dropbox.com/s/qowngzzvg5q5pjj/Mozilla%20issues.docx?dl=0


To save everyone else some time trying to find out what has changed,
these are the additions for every issue, diffed against the original
response[1]:



Issue D:

PROCERT initially claimed that this was entirely RFC-compliant, a claim
comprehensively rebutted by Ryan Sleevi.

This certificate was issued with the modifications and here it is
possible to appreciate the evidence https://crt.sh/?id=209727657



Issue E:

This certificate is not in use and is appended to the internal
revocation schedule, the current certificate is 2048 in length and can
be seen in the attached OCSP response (ocsp.txt)



Issue G:

Please find evidence of new certificate issued without problems
https://crt.sh/?id=202869851



Issue I:

These certificates were revoked and generated again, please consult
through the following link
https://crt.sh/?iCAID=750=2000-01-01=1000=25



Issue J:

Although certificates are not certified, the certificates have been
revoked and corrected, please check the link
https://crt.sh/?iCAID=750=2000-01-01=782



Issue K:

Corrective action taken, please consult the link
https://crt.sh/?id=197158298=cablint



Issue L:

That certificate was revoked and generated again, please consult through
the following link https://crt.sh/?id=167929373



Issue M:

This is not an infringement or violation of the RFC. Regarding to the
language, the national language in Venezuela is the Spanish. We will
work to updated the English version of this document and posted in the
web page.
https://www.procert.net.ve/documentos/AC-D-0011.pdf
https://www.procert.net.ve/documentos/AC-D-0003.pdf

Standard
https://tools.ietf.org/html/rfc3647
https://tools.ietf.org/html/rfc2527



Issue N:

Taking into account what the Baseline says, it states the following:
i. Other Subject Attributes
All other optional attributes, when present within the subject field,
MUST contain information that has been verified by the CA.

Indicates that another field can be included as long as it is
information verified by the CA in this case the CA verifies the number
of RIF of each company and also the field is with an OID for that
purpose, which is 2.16.862.2.2



Issue O:

Our OCSP works without any problem in the validation with automatic
tools such as certutil, even with the same command openssl, in
consultation under standard.

The standard openssl query is done in the following way: openssl ocsp
-issuer issuer.cer -cert cert.cer -url http://ura.procert.net.ve/ocsp
-noverify -text.

We detected that OCSP does work correctly with the Microsoft tool.

Open SSL creates a problem when doing a non-standard query (hacking). We
are already working the point with Microsoft and we even have an
assigned ticket.



Issue P:

No RFC 2560 nor RFC 5280 is being violated.



Issue R:

The certificate was revoked and reissued, please see the link
https://crt.sh/?id=194225991



Issue S:

Already it was given previous answer to this point and was solved
modifying certain parameters in our CA, which counts on a CSPRNG that
acts like generator of serial numbers and was modified in its register
so that it increased the capacity and strength of the serial numbers
that generates automatically and without human intervention.



Issue T:

These certificates were revoked and generated again, please consult
through the following link
https://crt.sh/?iCAID=750=2000-01-01=1000=734
Additionally, we have already modified the certificate template to
prevent it from containing this key usage.



Issue V:

No additions.



Issue W:

This

Re: PROCERT issues

2017-09-21 Thread alejandrovolcan--- via dev-security-policy 
El lunes, 18 de septiembre de 2017, 8:27:18 (UTC-5), Gervase Markham  escribió:
> On 11/09/17 12:03, Gervase Markham wrote:
> > Thank you for this initial response. It is, however, far less detailed
> > than we would like to see. 
> 
> I have not had any further updates from PROCERT. I have tried to reflect
> their responses from this email here:
> https://wiki.mozilla.org/CA:PROCERT_Issues
> 
> We hope to conclude the discussion at the end of this week, although I
> am having minor surgery on Wednesday, so it may be next week.
> 
> Gerv

Dear Gerv, I have attached a document that gives us a greater response to each 
of the points, as well as Mr. Oscar Lovera sent you an email with the same 
information

https://www.dropbox.com/s/qowngzzvg5q5pjj/Mozilla%20issues.docx?dl=0

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

Re: PROCERT issues

2017-09-18 Thread Gervase Markham via dev-security-policy 
On 11/09/17 12:03, Gervase Markham wrote:
> Thank you for this initial response. It is, however, far less detailed
> than we would like to see. 

I have not had any further updates from PROCERT. I have tried to reflect
their responses from this email here:
https://wiki.mozilla.org/CA:PROCERT_Issues

We hope to conclude the discussion at the end of this week, although I
am having minor surgery on Wednesday, so it may be next week.

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

Re: PROCERT issues

2017-09-11 Thread Gervase Markham via dev-security-policy 
Hi Alejandro,

Thank you for this initial response. It is, however, far less detailed
than we would like to see. In the email I sent to you letting you know
that we were looking at PROCERT, I wrote:

"You may wish to review a similar issue list we created for Symantec:
https://wiki.mozilla.org/CA:Symantec_Issues
in order to see how such a wiki page might develop in the future. For
example, we would expect most or all issues on your list to soon carry a
"PROCERT Response" section. Good responses will be more than "yes, we
have revoked the certificate" or even "we have revoked, and updated our
software". We want to know how each problem occurred in the first place,
and why it was not detected until now by PROCERT's existing systems for
quality control. This wiki page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance
gives best practices in responding to incidents and writing reports,
which may prove useful in formulating your responses."

It seems you have chosen not to follow this advice, as many of your
responses consist solely of an assertion that you have revoked and
replaced the problematic certificates. So, because there is no root
cause analysis, we have no assurance at all that the issue will not
occur again.

Even beyond that major concern, I think there are some of these issues
where you have not entirely understood the problem.

On 08/09/17 20:09, PSC Procert wrote:
> Issue E: Issuance of 1024-bit Certificate (December 2016)
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate in 2048, 
> supporting into the installation process. We completed those actions in this 
> point.

Your cut-and-paste answer is inapplicable in this case, because the
"client" was PROCERT itself - the certificate in question was an OCSP
responder cert.

> Issue L: helloburgershack.com (June - July 2017)
> 
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate, supporting 
> into the installation process. This client provides a production window after 
> the next Tuesday in order to proceed with the revoke and the reissue of the 
> certificate. Pending action.

What was sought here was an explanation of why it took five attempts to
issue this certificate, and even the last version had problems.

> Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)
> 
> Procert:
> 
> After a validation process, we modify the RFC number in our documentation. We 
> complete this point.

I think you misunderstand. The issue here is not that some RFC number in
the document is wrong, but that your document is not arranged according
to the layout given in RFC3647. To fix this would require completely
rearranging the document. Are you saying that you have already completed
this? If so, can we see a copy of the updated document?

> Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - 
> August 2017)

> Now we stay contacting Microsoft in order to obtain and adequate procedure or 
> batch. In paralleled we work in our own OCSP software. 

I suggest that writing and deploying your own OCSP software is unlikely
to be a route towards speedy conformance with all applicable
regulations. If you are unable to get Microsoft's software to function,
I would suggest approaching another vendor. But perhaps another CA has
the Microsoft software working, and could help out? You may want to ask
on the CAB Forum list.

> Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)
> 
> Procert:
> 
> We check the standard, the OCSP certificate is SHA 256, the answer in this 
> case is an observation. We work to check and validate the adjust to SHA 256 
> in the OCSP answer. This situation does not contravene any standard.

No, but it does contradict your assertions in your responses to two
previous Mozilla CA Communications.

> Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)
> 
> Procert:
> 
> Please validate the certificate issuance. This certificate is not issued by 
> PSC PROCERT

You are quite right - my apologies. It's from a different part of the
Venezuelan Goverment's hierarchy. I was sent a large list of
certificates with this problem but a few others I've sampled also seem
to be from other parts. I will look into this and see if I can find an
example issued by PROCERT; if not, I will strike this issue.

> Issue S: Non-Random Serial Numbers (September 2016 - August 2017)
> 
> Procert:
> 
> We check the observation. Procert technical staff applied the observation and 
> fix the system in this particular point.

Please can you explain the method of construction used for the most
recent serial numbers, e.g. the one on https://crt.sh/?id=207894453?

> Issue X: High Percentage of Revocations (August 2017) 
> 
> Procert:
> 
> Staff takes actions considering the observations

Re: PROCERT issues

2017-09-09 Thread PSC Procert via dev-security-policy 
Good Afertnoon

In order to answer the points of the wiki, we make the following explanations



Issue D: URI in CN and dnsName SAN (December 2016)

Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate, supporting into 
the installation process. We completed those actions in this point.


Issue E: Issuance of 1024-bit Certificate (December 2016)
Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate in 2048, supporting 
into the installation process. We completed those actions in this point.


Issue G: Internal IP Address in SAN (March 2015 - March 2017)

Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate, supporting into 
the installation process. We completed those actions in this point.

 

Issue I: CN Not Also In SAN (March 2016 - June 2017)

Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate, supporting into 
the installation process. We completed those actions in this point.

 

Issue J: Use of keyCertSign in Leaf Certificates (October 2016 - June 2017)

Procert:

The template for this certificate was fixed and based on internals test and 
validation, we contacting the client, we asking for a new CSR and proceed to 
revoke and reissue the certificate, supporting into the installation process. 
We completed those actions in this point.

 

Issue K: Internal DNS Names in Certificates (May - June 2017)

Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate, supporting into 
the installation process. We completed those actions in this point.

 

Issue L: helloburgershack.com (June - July 2017)

Procert:

Based on internals test and validation, we contacting the client, we asking for 
a new CSR and proceed to revoke and reissue the certificate, supporting into 
the installation process. This client provides a production window after the 
next Tuesday in order to proceed with the revoke and the reissue of the 
certificate. Pending action.

 

Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)

Procert:

After a validation process, we modify the RFC number in our documentation. We 
complete this point.

 

Issue N: otherNames in Certificate SAN (2011 - August 2017)

Procert:
Based on internal testing and validation, we contact the customer, request a 
window to generate a new CSR and review and reissue the certificate, we will 
also support the installation process. We keep in touch with customers with 
active SSL to proceed with this point. We advance as much as possible with 
customers. Some of these certificates have expired. For the issue of new 
certificates, verify the observations contained in the number V

 
Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - 
August 2017)

Procert:

As we explained into Mozilla Bug (1391058), when we applied the Microsoft tool, 
the system shows this message “In the Value data box, type the path to the 
directory you created in step 3 of the directory structure procedure and that 
contains the issued serial numbers, and then click OK.”. 

 We refresh or restart the service, then, the OSCP registry is automatically 
deleted. For testing we use different versions of Windows Server (2008, 2012 
and 2016) all the versions present the same result. Additionally we ask for an 
answer at Microsoft TechNet please 
https://social.technet.microsoft.com/Forums/windowsserver/es-ES/981f6e48-dc25-4eeb-a1d6-0bc72b9b4fc9/ocsp-online-responder-service-assume-a-certificate-that-is-not-included-in-the-crl-as-a-valid-and?forum=winserversecurity

Now we stay contacting Microsoft in order to obtain and adequate procedure or 
batch. In paralleled we work in our own OCSP software. 

 

Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)

Procert:

We check the standard, the OCSP certificate is SHA 256, the answer in this case 
is an observation. We work to check and validate the adjust to SHA 256 in the 
OCSP answer. This situation does not contravene any standard.

 

Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)

Procert:

Please validate the certificate issuance. This certificate is not issued by PSC 
PROCERT

 

Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 
2015 - August 2017)

Based on internal testing and validation, we contact the customer, request a 
window to generate a new CSR and review and reissue the certificate, we will 
also support the installation process. We keep in touch with customers with 
active certificate to proceed with this point. We advance as much as possible

Re: PROCERT issues

2017-09-08 Thread Ryan Sleevi via dev-security-policy 
On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/09/2017 17:17, Gervase Markham wrote:
>
>> Mozilla has decided that there is sufficient concern about the
>> activities and operations of the CA "PROCERT" to collect together our
>> list of current concerns. That list can be found here:
>> https://wiki.mozilla.org/CA:PROCERT_Issues
>>
>> Note that this list may expand or reduce over time as issues are
>> investigated further, with information either from our or our
>> community's investigations or from PROCERT.
>>
>> We expect PROCERT to engage in a public discussion of these issues and
>> give their comments and viewpoint. We also hope that our community will
>> make comments, and perhaps provide additional information based on their
>> own investigations.
>>
>> When commenting on these issues, please clearly state which issue you
>> are addressing on each occasion. The issues have been given identifying
>> letters to help with this.
>>
>> At the end of a public discussion period between Mozilla, our community
>> and PROCERT, which we hope will be no longer than a couple of weeks,
>> Mozilla will move to make a decision about the continued trust of
>> PROCERT, based on the picture which has then emerged.
>>
>> Gerv
>>
>>
> Although violating the same rules, and involving the same certificates;
> for purposes of risk assessment I think issue K should be divided into
> two issues:
>

Note, I was explicitly suggesting we not do this, because this introduces a
greater level of subjectivity of assessment, and based on incomplete or
unknowable information. For this reason, ensuring a consistent application
of risk (e.g. the factors that allowed this to happen are the same) is far
more beneficial for the community and for consistency in application of
policy.

So I do not believe we should split these issues up, and do not think it
would help the discussions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issues

2017-09-08 Thread Jakob Bohm via dev-security-policy 

On 07/09/2017 17:17, Gervase Markham wrote:

Mozilla has decided that there is sufficient concern about the
activities and operations of the CA "PROCERT" to collect together our
list of current concerns. That list can be found here:
https://wiki.mozilla.org/CA:PROCERT_Issues

Note that this list may expand or reduce over time as issues are
investigated further, with information either from our or our
community's investigations or from PROCERT.

We expect PROCERT to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you
are addressing on each occasion. The issues have been given identifying
letters to help with this.

At the end of a public discussion period between Mozilla, our community
and PROCERT, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about the continued trust of
PROCERT, based on the picture which has then emerged.

Gerv



Although violating the same rules, and involving the same certificates;
for purposes of risk assessment I think issue K should be divided into
two issues:

K1 (most serious): Multiple certificates issued for the bare hostname
  OWASERVER (uppercase, no qualifying domain).  As pointed out by Ryan
  Sleevi, many e-mail clients (including mobile clients) may look for
  this name on their local DNS search list and may or may not (depending
  on client implementation) accept any of these bare certificates as
  proving they are talking to their "home" mail server.  So far none of
  the other MS mail server magic/default names have been found as bare
  name SANs.

K2 (very serious): Multiple certificates issued to potentially
  non-unique subdomains of the local. TLD previously common for LAN DNS,
  but now mostly reserved for multicast DNS.  These violations should
  only pose a risk to clients who have somehow chosen the same arbitrary
  2. level domain under local. as the certificate holder(s).  The main
  issue here is that since the local. TLD doesn't have an official
  registry, there is no way that the CA could have properly validated
  that *any* applicant was the proper owner of such a 2nd level domain,
  because noone is.


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: PROCERT issues

2017-09-08 Thread Gervase Markham via dev-security-policy 
On 07/09/17 22:27, Ryan Sleevi wrote:
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?

I don't want to place a hard limit on it because often finding the truth
requires several rounds of interaction. But, as noted in the original
post, I would expect to be moving towards a determination of a response
in a matter of weeks (rather than months).

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

Re: PROCERT issues

2017-09-08 Thread Alex Gaynor via dev-security-policy 
I believe it's important to consider more than just the issues themselves,
and to look at a CA's response to the issues. In the past weeks, we've done
a lot of really fantastic work to push CAs on publishing more comprehensive
post-mortems, and several CAs have distinguished themselves with timely
responses and solid analysis of the underlying causes of failures.

In that frame, I want to highlight a few issues that raise serious concerns
to me:

* In responding to issue D, PROCERT displayed a failure to analyze and
understand the issues.
* In responding to issue O, PROCERT once again claimed there wasn't a
problem after evidence has already been provided of the issue. Further,
they appear to have significant challenges maintaining and updating their
PKI software.
* In responding to issue E, PROCERT made several rounds of incorrect
statements about their certificate issuance; they have not substantively
responded to the issue.

I believe that PROCERT's inability to respond to problem reports in a
timely and correct fashion, even more so than the certificate issuance
itself, represents an ongoing practice practice which is not in keeping
with the goals of the Mozilla Root Program.

Alex

On Thu, Sep 7, 2017 at 5:27 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Mozilla has decided that there is sufficient concern about the
> > activities and operations of the CA "PROCERT" to collect together our
> > list of current concerns. That list can be found here:
> > https://wiki.mozilla.org/CA:PROCERT_Issues
> >
> > Note that this list may expand or reduce over time as issues are
> > investigated further, with information either from our or our
> > community's investigations or from PROCERT.
> >
> > We expect PROCERT to engage in a public discussion of these issues and
> > give their comments and viewpoint. We also hope that our community will
> > make comments, and perhaps provide additional information based on their
> > own investigations.
> >
> > When commenting on these issues, please clearly state which issue you
> > are addressing on each occasion. The issues have been given identifying
> > letters to help with this.
> >
> > At the end of a public discussion period between Mozilla, our community
> > and PROCERT, which we hope will be no longer than a couple of weeks,
> > Mozilla will move to make a decision about the continued trust of
> > PROCERT, based on the picture which has then emerged.
> >
>
> (Unless stated, wearing a personal hat)
>
> Hi Gerv,
>
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?
>
> Based on the information provided, Issue K represents an unconditional
> security issue, in as much as names such as "autodiscover" and "owaserver"
> are widely-used domains for Outlook Web Access. Many clients attempt to
> access resources at this (unqualified) domain, relying on the combination
> of DNS suffix search and locally-trusted certificates to ensure proper
> resolution. By issuing a publicly trusted certificate for this name - and
> then failing to revoke it - represents a critical security risk and
> arguably a dereliction of responsibility.
>
> Combined with Issue D and Issue G, it is questionable as to how it was ever
> validated, and suggest serious failings over the most critical security
> control of a CA - which is validation of a domain.
>
> Combined with Issue L, Issue Q, Issue R, Issue X, and Issue W, serious
> questions are raised about the oversight and technical ability of the
> staff, as these are indicative of serious control failures.
>
> Outside of Issue K, I would suggest that Issue O and Issue S show a lack of
> awareness of developments in the CA ecosystem, as both of these controls
> were direct responses to widely reported CA security issues. The failure to
> take appropriate steps - or to appreciate the reasons behind such steps -
> are indicative of a systematic misunderstanding of the security function of
> a CA.
>
> On the basis of the sum of these issues, it would seem that the criteria in
> Section 7.3 of Mozilla policy -
> https://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/policy/
> - is met: "Mozilla will disable or remove a certificate if the CA
> demonstrates ongoing or egregious practices that do not maintain the
> expected level of service or that do not comply with the requirements of
> this policy."
> ___
> 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

Re: PROCERT issues

2017-09-07 Thread Ryan Sleevi via dev-security-policy 
On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Mozilla has decided that there is sufficient concern about the
> activities and operations of the CA "PROCERT" to collect together our
> list of current concerns. That list can be found here:
> https://wiki.mozilla.org/CA:PROCERT_Issues
>
> Note that this list may expand or reduce over time as issues are
> investigated further, with information either from our or our
> community's investigations or from PROCERT.
>
> We expect PROCERT to engage in a public discussion of these issues and
> give their comments and viewpoint. We also hope that our community will
> make comments, and perhaps provide additional information based on their
> own investigations.
>
> When commenting on these issues, please clearly state which issue you
> are addressing on each occasion. The issues have been given identifying
> letters to help with this.
>
> At the end of a public discussion period between Mozilla, our community
> and PROCERT, which we hope will be no longer than a couple of weeks,
> Mozilla will move to make a decision about the continued trust of
> PROCERT, based on the picture which has then emerged.
>

(Unless stated, wearing a personal hat)

Hi Gerv,

Do you have an anticipated time period for discussion? That is, what
represents a time for which PROCERT may submit feedback to have it
considered, and at what point you will consider discussion closed?

Based on the information provided, Issue K represents an unconditional
security issue, in as much as names such as "autodiscover" and "owaserver"
are widely-used domains for Outlook Web Access. Many clients attempt to
access resources at this (unqualified) domain, relying on the combination
of DNS suffix search and locally-trusted certificates to ensure proper
resolution. By issuing a publicly trusted certificate for this name - and
then failing to revoke it - represents a critical security risk and
arguably a dereliction of responsibility.

Combined with Issue D and Issue G, it is questionable as to how it was ever
validated, and suggest serious failings over the most critical security
control of a CA - which is validation of a domain.

Combined with Issue L, Issue Q, Issue R, Issue X, and Issue W, serious
questions are raised about the oversight and technical ability of the
staff, as these are indicative of serious control failures.

Outside of Issue K, I would suggest that Issue O and Issue S show a lack of
awareness of developments in the CA ecosystem, as both of these controls
were direct responses to widely reported CA security issues. The failure to
take appropriate steps - or to appreciate the reasons behind such steps -
are indicative of a systematic misunderstanding of the security function of
a CA.

On the basis of the sum of these issues, it would seem that the criteria in
Section 7.3 of Mozilla policy -
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
- is met: "Mozilla will disable or remove a certificate if the CA
demonstrates ongoing or egregious practices that do not maintain the
expected level of service or that do not comply with the requirements of
this policy."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PROCERT issues

2017-09-07 Thread Gervase Markham via dev-security-policy 
Mozilla has decided that there is sufficient concern about the
activities and operations of the CA "PROCERT" to collect together our
list of current concerns. That list can be found here:
https://wiki.mozilla.org/CA:PROCERT_Issues

Note that this list may expand or reduce over time as issues are
investigated further, with information either from our or our
community's investigations or from PROCERT.

We expect PROCERT to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you
are addressing on each occasion. The issues have been given identifying
letters to help with this.

At the end of a public discussion period between Mozilla, our community
and PROCERT, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about the continued trust of
PROCERT, based on the picture which has then emerged.

Gerv

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