RE: Suspicious test.com Cert Issued By GlobalSign

[Nio via dev-security-policy]

>Back in 2015, there were some GlobalSign testing in which users thought it was 
>acceptable to use domains like test.com and example.com for testing purposes.  
>Since this time, GlobalSign has implemented procedures to avoid any similar 
>situations in the future.  
 
Does it mean that GlobalSign allow RAs (trusted role employees) to add domain 
without necessary domain validation? Isn’t there any technical restriction that 
prevent this if the domain has not been validated, like having two different 
steps, and domain validation is the former step which cannot be overridden, 
than “adding a domain”?
 
>As part of researching this reported misissuance, we've reviewed all orders 
>and certificates we've issued since this time to test.com and example.com and 
>found several orders in the pending or cancelled state.
 
Is there any other domain that was thought to be allowed for testing purposes?

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

[Nio via dev-security-policy]

>Back in 2015, there were some GlobalSign testing in which users thought it was 
>acceptable to use domains like test.com and example.com for testing purposes.  
>Since this time, GlobalSign has implemented procedures to avoid any similar 
>situations in the future.  
 
Does it mean that GlobalSign allow RAs (trusted role employees) to add domain 
without necessary domain validation? Isn’t there any technical restriction that 
prevent this if the domain has not been validated, like having two different 
steps, and domain validation is the former step which cannot be overridden, 
than “adding a domain”?
 
>As part of researching this reported misissuance, we've reviewed all orders 
>and certificates we've issued since this time to test.com and example.com and 
>found several orders in the pending or cancelled state.
 
Is there any other domain that was thought to be allowed for testing purposes?

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

Re: Include Renewed Kamu SM root certificate

[Kathleen Wilson via dev-security-policy]

On Wednesday, March 15, 2017 at 9:56:25 AM UTC-7, Kathleen Wilson wrote:
> Thanks to those of you who have reviewed and commented on this request from 
> the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include 
> the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and 
> enable the Websites trust bit.


Thanks again to those of you who have reviewed this request, and to those of 
you who have participated in this discussion.

I am now closing this discussion, and I will update the bug to recommend 
approval of this request.

All further follow-up on this request should be in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1262809

Thanks,
Kathleen
___
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

[Gervase Markham via dev-security-policy]

On 16/03/17 11:25, douglas.beat...@gmail.com wrote:
> For the record, we don't think it's necessary (or permissible) to
> give employees (RAs) the power to add arbitrary domains to accounts
> without proper vetting.

I guess I'm still not being clear - sorry :-( Let me try one more time:

Why does GlobalSign believe it is necessary for employees to have the
technical capability to add arbitrary domains to accounts without going
through ownership validation?

I mean, clearly they did back in 2015, because that's exactly what
happened. Do they still have the technical capability (ignoring policy
and set procedures for a moment) or not?

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

RE: Symantec: Next Steps

[Jeremy Rowley via dev-security-policy]

We have DTP and RA roles slated as part of the validation WG discussion, but
only as they relate to validation. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 16, 2017 7:16 AM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec: Next Steps

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/03/17 13:32, Ryan Sleevi wrote:
> > (Wearing Google hat only for this statement) Have you considered 
> > having this discussion in the CA/Browser Forum?
> Google
> > had planned to discuss this very topic at our upcoming F2F about how 
> > to address this, and would be very interested in collaborating with 
> > Mozilla
> on
> > this. I mentioned this recently to Kathleen at the WebTrust TF 
> > meetings, but apologies for not mentioning to you as well.
>
> This sounds like a good idea. Do we want to get this added in an open 
> slot? There may still be time.
>

Unconference future discussion. If CAs aren't interested in it, and it
doesn't get discussed, then that seems like a suitable signal to discuss in
the browser policies, doesn't it?


> > I don't understand why you
> > believe it's relevant the act of "Mozilla requiring disclosure of 
> > the audits". Can you help me understand where, in the policy, that's
> required?
>
> I'm not sure where your text in quotes comes from, and nor can I work 
> out the referent of "it", so I don't understand this question.
>

The quoted text was attempting to summarize the following paragraph from
you:

"""No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would need to
flag that, and we would make a judgement about that party's suitability at
the time. The issue here arises that, because of the way things are set up,
these RA's audits were not submitted to Mozilla, and so Symantec didn't have
to resolve the Schrodinger's Cat of (qualified|not qualified and need us to
make a judgement)."""

The question here is that it seems you have hinged the
acceptability/unacceptability of the auditor on the basis of whether or not
it was required to be disclosed.

Or, put differently, it sounds as if you suggest the only obligation a CA
has to ensure their DTP auditors are qualified for the task at hand is if,
and only if, Mozilla requests those audits. In the absence of that request,
the CA is allowed to make their own individual determination. Further, it
seems that you are suggesting that if a CA makes that determination, and
it's incorrect, that's not a failure upon the CAs part, because they made 'a
decision', and the relevant portions of Mozilla policy only apply to the
'next' audit.

In effect, it makes the question of 'qualified' auditor one which can never
look retrospectively to prevent issues or instill a duty of care, and it
only applies forward thinking, to the 'next' audits. Or, put differently, it
sounds as if you're suggesting that Symantec, having made a determination of
qualified without input from Mozilla, has sufficiently abided by Mozilla's
policy.

I'm not sure that's a consistent read with the goals or policy stated.
Rather, by making that determination without input from Mozilla, Symantec
has instead taken on full liability for that audit. If, as in this case,
evidence appears that suggests the auditor is not qualified, then the root
issue rests with Symantec for not ensuring that the auditor was qualified.
Similarly, all other CAs who are accepting audits from third-parties
(whether DTPs or sub-CAs), and which are not ensuring those meet the
definition of qualified, similarly accept risk of violation. That risk can
be mitigated - for example, showing that the auditor is appropriately
licensed at the time they conducted the audit, rejecting audits that are
clearly problematic - but it's a risk born through exercising the capability
to delegate.

Put one last way (since this is such a thorny issue), I read your reply in
the above quoted text to say "Mozilla requires that the CA make a decision.
But it doesn't have to be a right one, and it doesn't have to use the same
data we would." I'm trying to push back on that, which is every CA has an
obligation to make the Right Decision - they have the tools at their
disposal to do so, but uncertainty or perceived risk can and should only be
mitigated by public consultation before - not after.
___
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

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/03/17 13:32, Ryan Sleevi wrote:
> > (Wearing Google hat only for this statement)
> > Have you considered having this discussion in the CA/Browser Forum?
> Google
> > had planned to discuss this very topic at our upcoming F2F about how to
> > address this, and would be very interested in collaborating with Mozilla
> on
> > this. I mentioned this recently to Kathleen at the WebTrust TF meetings,
> > but apologies for not mentioning to you as well.
>
> This sounds like a good idea. Do we want to get this added in an open
> slot? There may still be time.
>

Unconference future discussion. If CAs aren't interested in it, and it
doesn't get discussed, then that seems like a suitable signal to discuss in
the browser policies, doesn't it?


> > I don't understand why you
> > believe it's relevant the act of "Mozilla requiring disclosure of the
> > audits". Can you help me understand where, in the policy, that's
> required?
>
> I'm not sure where your text in quotes comes from, and nor can I work
> out the referent of "it", so I don't understand this question.
>

The quoted text was attempting to summarize the following paragraph from
you:

"""No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would
need to flag that, and we would make a judgement about that party's
suitability at the time. The issue here arises that, because of the way
things are set up, these RA's audits were not submitted to Mozilla, and
so Symantec didn't have to resolve the Schrodinger's Cat of
(qualified|not qualified and need us to make a judgement)."""

The question here is that it seems you have hinged the
acceptability/unacceptability of the auditor on the basis of whether or not
it was required to be disclosed.

Or, put differently, it sounds as if you suggest the only obligation a CA
has to ensure their DTP auditors are qualified for the task at hand is if,
and only if, Mozilla requests those audits. In the absence of that request,
the CA is allowed to make their own individual determination. Further, it
seems that you are suggesting that if a CA makes that determination, and
it's incorrect, that's not a failure upon the CAs part, because they made
'a decision', and the relevant portions of Mozilla policy only apply to the
'next' audit.

In effect, it makes the question of 'qualified' auditor one which can never
look retrospectively to prevent issues or instill a duty of care, and it
only applies forward thinking, to the 'next' audits. Or, put differently,
it sounds as if you're suggesting that Symantec, having made a
determination of qualified without input from Mozilla, has sufficiently
abided by Mozilla's policy.

I'm not sure that's a consistent read with the goals or policy stated.
Rather, by making that determination without input from Mozilla, Symantec
has instead taken on full liability for that audit. If, as in this case,
evidence appears that suggests the auditor is not qualified, then the root
issue rests with Symantec for not ensuring that the auditor was qualified.
Similarly, all other CAs who are accepting audits from third-parties
(whether DTPs or sub-CAs), and which are not ensuring those meet the
definition of qualified, similarly accept risk of violation. That risk can
be mitigated - for example, showing that the auditor is appropriately
licensed at the time they conducted the audit, rejecting audits that are
clearly problematic - but it's a risk born through exercising the
capability to delegate.

Put one last way (since this is such a thorny issue), I read your reply in
the above quoted text to say "Mozilla requires that the CA make a decision.
But it doesn't have to be a right one, and it doesn't have to use the same
data we would." I'm trying to push back on that, which is every CA has an
obligation to make the Right Decision - they have the tools at their
disposal to do so, but uncertainty or perceived risk can and should only be
mitigated by public consultation before - not after.
___
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

[douglas.beattie--- via dev-security-policy]

On Thursday, March 16, 2017 at 6:59:41 AM UTC-4, Gervase Markham wrote:
> Hi Doug,
> 
> On 03/03/17 11:17, Gervase Markham wrote:
> > That's lovely, but it doesn't answer my question. Let me restate it: why
> > does GlobalSign believe it is necessary to give employees the power to
> > add arbitrary domains to accounts without going through ownership
> > validation?
> 
Hi Gerv,

For the record, we don't think it's necessary (or permissible) to give 
employees (RAs) the power to add arbitrary domains to accounts without proper 
vetting.

This was a breakdown in the vetting process whereby this "test" domain was 
added in order to issue a certificate in production.  When this was done the 
cert was revoked and the vetting for the domain was disabled.

After this happened back in 2015 all of the RAs were instructed to follow 
production vetting procedures in production (obviously) and to not bend or 
break them when doing "testing". 

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[Gervase Markham via dev-security-policy]

Hi Blake,

On 02/03/17 16:26, blake.mor...@trustis.com wrote:
> We have engaged with our external auditors in relation to this and the 
> previous certificate that was reported. Once that activity has concluded we 
> will be providing further information.

Do you have an ETA for this incident report? It's been quite some time
now. I am still interested to understand how a "full investigation" of
the first certificate failed to turn up the second.

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

[Gervase Markham via dev-security-policy]

Hi Doug,

On 03/03/17 11:17, Gervase Markham wrote:
> That's lovely, but it doesn't answer my question. Let me restate it: why
> does GlobalSign believe it is necessary to give employees the power to
> add arbitrary domains to accounts without going through ownership
> validation?

You are getting various pings from me this morning :-) This question is
still outstanding, and has been for a month now.

Thanks,

Gerv

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

Re: GlobalSign BR violation

[Gervase Markham via dev-security-policy]

On 28/02/17 20:02, douglas.beat...@gmail.com wrote:
> And lastly this ticket.  The Domain name was validated in accordance
> with the BRs, but there was a bug that allowed a user entered space
> to be included in some of the SAN values.  While the value is not
> compliant with RFC 5280 or the BRs, there was no security issue with
> the certificate that was issued (it was likely not able to secure the
> intended subdomains).  We'll provide an incident report for this.

Hi Doug,

Any news on when we might see this incident report?

Thanks,

Gerv

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

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

[Gervase Markham via dev-security-policy]

On 03/03/17 20:59, douglas.beat...@gmail.com wrote:
> In general, when we receive new orders and issue certificates, the
> vetting is done just prior to issuance time which permits the
> certificate to be replaced up until expiration.  We're looking into
> cases where new "orders" may have used certificate data that was done
> prior and then verifying that the domains (and enterprise data on the
> subject DN) are re-verified at the applicable intervals.
> 
> I'll send out an update as soon I have more information.

Hi Doug,

Any update? Once you report back, if nothing terrible is found, I think
we can consider this matter resolved.

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 16/03/17 10:50, Gervase Markham wrote:
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

With these changes and the filing of
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this
particular discussion RESOLVED. This means Mozilla plans to take no
action against GTS based on what has been discovered and discussed. It
doesn't mean people can't continue to make suggestions about
improvements to our process, citing this situation.

Gerv

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 08/03/17 16:20, Gervase Markham wrote:
> On 09/02/17 22:55, Peter Bowen wrote:
>> Policy Suggestion A) When transferring a root that is EV enabled, it 
>> should be clearly stated whether the recipient of the root is also 
>> receiving the EV policy OID(s).
> 
> I agree with this suggestion; we should update
> https://wiki.mozilla.org/CA:RootTransferPolicy

Now done: "When transferring ownership of a root that is EV-enabled, it
should be clearly stated whether the recipient of the root is also
receiving the (right to use the) EV policy OID(s) and, if so, it should
be confirmed that they have or will get the relevant audits before
issuing EV certs."

> Again, would this be covered by a requirement that no issuance was
> permitted from a transferred root until all the paperwork was in place,
> including appropriately-scoped audits? This might lead to a PITRA, but
> would not have to.

Now done: "No issuance whatsoever is permitted from a root certificate
which has changed ownership by being sold by one company to another (as
opposed to by acquisition of the owning company) until the receiving
company has demonstrated to Mozilla that they have all the appropriate
audits, CP/CPS documents and other systems in place. In addition, if the
receiving company is new to the Mozilla root program, there must also be
a public discussion regarding their admittance to the root program."

https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 07/03/17 10:18, Gervase Markham wrote:
> OK. Question for group: would it make sense to add the intermediate(s)
> that GlobalSign is using for this purpose directly to the Mozilla trust
> store, with the EV bit enabled, and then remove the EV bit from the
> roots now owned by Google Trust Services?
> 
> This would scope EV permissions more closely to the audits, and so
> prevent Google from accidentally or intentionally issuing EV which was
> shown as such in Firefox, without having an EV audit.

Hearing no dissent, filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882

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

Re: DigiCert BR violation

[Gervase Markham via dev-security-policy]

On 13/03/17 21:31, Jeremy Rowley wrote:
> [JR] If you recall, I did try to change the policy. I was told to 
> change the RFC if I didn’t like the requirement. I find trying to
> change the RFC nearly impossible as PKIX is dead and there are too
> many other issues people would also like to change.

If RFCs are unchangeably wrong, we should override them in the BRs.
[citation needed] for the discussion where you were told to change the
RFC; I'd like to read how that conversation went.

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

Re: Symantec: Next Steps

[Gervase Markham via dev-security-policy]

On 08/03/17 15:06, Peter Bowen wrote:
> By eliminating the DTP option, you will massively raise costs for CAs
> that rely upon local translators and information gatherers.  I think a
> much better proposal would be to require the CA perform the RA
> activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to
> Subject Identity Information validation.

Let's call that "Policy Proposal 5" :-)

I think that if we did this, it might still make sense to enact Policy
Proposal 1. I believe that would have the side effect of making sure we
get all the audits.

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

Re: Symantec: Next Steps

[Gervase Markham via dev-security-policy]

On 09/03/17 13:32, Ryan Sleevi wrote:
> (Wearing Google hat only for this statement)
> Have you considered having this discussion in the CA/Browser Forum? Google
> had planned to discuss this very topic at our upcoming F2F about how to
> address this, and would be very interested in collaborating with Mozilla on
> this. I mentioned this recently to Kathleen at the WebTrust TF meetings,
> but apologies for not mentioning to you as well.

This sounds like a good idea. Do we want to get this added in an open
slot? There may still be time.

> I'm not sure that we can or should so easily dismiss this with a suggestion
> that we're dancing on the head of a pin here.

That's not quite what I'm saying; I'm saying that my position could be
seen as that (making very fine distinctions), and it possibly is.

> I don't understand why you
> believe it's relevant the act of "Mozilla requiring disclosure of the
> audits". Can you help me understand where, in the policy, that's required?

I'm not sure where your text in quotes comes from, and nor can I work
out the referent of "it", so I don't understand this question.

> I agree that removing the conflicting definition of qualified auditor is
> likely a suitable outcome, and a much welcome improvement, but I do think
> we owe it to the community to provide a greater degree of clarity then
> currently provided by this thread about the expectations related to such
> audits, both to the qualifications and the independence aspects.

Surely requiring the auditor to be qualified in all cases will provide
that clarity?

I've filed https://github.com/mozilla/pkipolicy/issues/63 .

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