Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy
 wrote:
> On 05/05/2017 22:45, Dimitris Zacharopoulos wrote:
>>
>>
>>
>> On 5/5/2017 10:58 μμ, Peter Bowen wrote:
>>>
>>
>> I don't know if all implementations doing path validation, use the EKUs
>> at the CA level but it seems that the most popular applications use it.
>>
>
> The issue would be implementations that only check the EE cert for
> their desired EKU (such as ServerAuth checking for a TLS client or
> EmailProtection checking for a mail client).  In other words, relying
> parties whose software would accept a chain such as
>
> root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).

This is the Mozilla policy and Mozilla does not do that, so I think we
should be fine there.

>>> If you look at
>>> https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
>>> being two independent tests.
>>>
>
>
> One other question: Does your proposal allow a TCSC that covers both
> ServerAuth and EmailProtection for the domains of the same organization?
>
> Or put another way, would your proposed language force an organization
> wanting to run under its own TCSC(s) to obtain two TCSCs, one for their
> S/MIME needs and another for their TLS needs?

Yes, it allows a single TCSC that does both.  The little three diamond
symbol means parallel, so both legs are evaluated at the same time.
If both get to "Goto B", then it is a single TCSC that can issue both
serverAuth and emailProtection certs.

Also note that there is no check for pathlen:0 on the TCSC, so it
could be a policy CA that has multiple issuing CAs below it.

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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Jakob Bohm via dev-security-policy]

On 05/05/2017 22:45, Dimitris Zacharopoulos wrote:



On 5/5/2017 10:58 μμ, Peter Bowen wrote:

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:


On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:

Looking at https://github.com/mozilla/pkipolicy/issues/69

do you have a proposed language that takes all comments into account?
From
what I understand, the Subordinate CA Certificate to be considered
Technically Constrained only for S/MIME:

   * MUST include an EKU that has the id-kp-emailProtection value AND
   * MUST include a nameConstraints extension with
   o a permittedSubtrees with
   + rfc822Name entries scoped in the Domain (@example.com) or
 Domain Namespace (@example.com, @.example.com)
controlled by
 an Organization and
   + dirName entries scoped in the Organizational name and
location
   o an excludedSubtrees with
   + a zero‐length dNSName
   + an iPAddress GeneralName of 8 zero octets (covering
the IPv4
 address range of 0.0.0.0/0)
   + an iPAddress GeneralName of 32 zero octets (covering the
 IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that
ignore the
EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.


You are probably right. Two relevant threads:

 * https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html and
 * an older one from year 2000
   (https://www.ietf.org/mail-archive/web/pkix/current/msg06821.html)

I don't know if all implementations doing path validation, use the EKUs
at the CA level but it seems that the most popular applications use it.



The issue would be implementations that only check the EE cert for
their desired EKU (such as ServerAuth checking for a TLS client or
EmailProtection checking for a mail client).  In other words, relying 
parties whose software would accept a chain such as


root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).




So, if we want to align with both the CA/B
Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we
should
keep the excludedSubtrees.

The BRs cover serverAuth.


Of course they do, I was merely trying to re-use the same language for
S/MIME usage :)


Dimitris.


If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.




One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?

Or put another way, would your proposed language force an organization
wanting to run under its own TCSC(s) to obtain two TCSCs, one for their
S/MIME needs and another for their TLS needs?

P.S.

Does Mozilla as a Browser implementer have any policy or technical
requirements on certificates that Mozilla products can use for
ClientAuth (e.g. does Firefox only offer certs with the ClientAuth (or
no) EKU when prompting a user which cert to send to a webserver,
similar for Thunderbird doing ClientAuth to a TLS protected e-mail
server).


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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Dimitris Zacharopoulos via dev-security-policy]

On 5/5/2017 10:58 μμ, Peter Bowen wrote:

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:


On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:

Looking at https://github.com/mozilla/pkipolicy/issues/69

do you have a proposed language that takes all comments into account?
From
what I understand, the Subordinate CA Certificate to be considered
Technically Constrained only for S/MIME:

   * MUST include an EKU that has the id-kp-emailProtection value AND
   * MUST include a nameConstraints extension with
   o a permittedSubtrees with
   + rfc822Name entries scoped in the Domain (@example.com) or
 Domain Namespace (@example.com, @.example.com) controlled by
 an Organization and
   + dirName entries scoped in the Organizational name and
location
   o an excludedSubtrees with
   + a zero‐length dNSName
   + an iPAddress GeneralName of 8 zero octets (covering the IPv4
 address range of 0.0.0.0/0)
   + an iPAddress GeneralName of 32 zero octets (covering the
 IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that ignore the
EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.


You are probably right. Two relevant threads:

 * https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html and
 * an older one from year 2000
   (https://www.ietf.org/mail-archive/web/pkix/current/msg06821.html)

I don't know if all implementations doing path validation, use the EKUs 
at the CA level but it seems that the most popular applications use it.





So, if we want to align with both the CA/B
Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we should
keep the excludedSubtrees.

The BRs cover serverAuth.


Of course they do, I was merely trying to re-use the same language for 
S/MIME usage :)



Dimitris.


If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.

Thanks,
Peter



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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:
>
>
> On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:
>>
>> On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
>> dev-security-policy  wrote:
>>>
>>> Looking at https://github.com/mozilla/pkipolicy/issues/69
>>>
>>> do you have a proposed language that takes all comments into account?
>>> From
>>> what I understand, the Subordinate CA Certificate to be considered
>>> Technically Constrained only for S/MIME:
>>>
>>>   * MUST include an EKU that has the id-kp-emailProtection value AND
>>>   * MUST include a nameConstraints extension with
>>>   o a permittedSubtrees with
>>>   + rfc822Name entries scoped in the Domain (@example.com) or
>>> Domain Namespace (@example.com, @.example.com) controlled by
>>> an Organization and
>>>   + dirName entries scoped in the Organizational name and
>>> location
>>>   o an excludedSubtrees with
>>>   + a zero‐length dNSName
>>>   + an iPAddress GeneralName of 8 zero octets (covering the IPv4
>>> address range of 0.0.0.0/0)
>>>   + an iPAddress GeneralName of 32 zero octets (covering the
>>> IPv6 address range of ::0/0)
>>
>> Why do we need to address dNSName and iPAddress if the only EKU is
>> id-kp-emailProtection?
>>
>> Can we simplify this to just requiring at least one rfc822Name entry
>> in the permittedSubtrees?
>
>
> I would be fine with this but there may be implementations that ignore the
> EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.

> So, if we want to align with both the CA/B
> Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we should
> keep the excludedSubtrees.

The BRs cover serverAuth.  If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.

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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Dimitris Zacharopoulos via dev-security-policy]

On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:

Looking at https://github.com/mozilla/pkipolicy/issues/69

do you have a proposed language that takes all comments into account? From
what I understand, the Subordinate CA Certificate to be considered
Technically Constrained only for S/MIME:

  * MUST include an EKU that has the id-kp-emailProtection value AND
  * MUST include a nameConstraints extension with
  o a permittedSubtrees with
  + rfc822Name entries scoped in the Domain (@example.com) or
Domain Namespace (@example.com, @.example.com) controlled by
an Organization and
  + dirName entries scoped in the Organizational name and location
  o an excludedSubtrees with
  + a zero‐length dNSName
  + an iPAddress GeneralName of 8 zero octets (covering the IPv4
address range of 0.0.0.0/0)
  + an iPAddress GeneralName of 32 zero octets (covering the
IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that ignore 
the EKU at the Intermediate CA level. So, if we want to align with both 
the CA/B Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, 
perhaps we should keep the excludedSubtrees.


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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy  wrote:
>
> Looking at https://github.com/mozilla/pkipolicy/issues/69
>
> do you have a proposed language that takes all comments into account? From
> what I understand, the Subordinate CA Certificate to be considered
> Technically Constrained only for S/MIME:
>
>  * MUST include an EKU that has the id-kp-emailProtection value AND
>  * MUST include a nameConstraints extension with
>  o a permittedSubtrees with
>  + rfc822Name entries scoped in the Domain (@example.com) or
>Domain Namespace (@example.com, @.example.com) controlled by
>an Organization and
>  + dirName entries scoped in the Organizational name and location
>  o an excludedSubtrees with
>  + a zero‐length dNSName
>  + an iPAddress GeneralName of 8 zero octets (covering the IPv4
>address range of 0.0.0.0/0)
>  + an iPAddress GeneralName of 32 zero octets (covering the
>IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?

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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Dimitris Zacharopoulos via dev-security-policy]

Looking at https://github.com/mozilla/pkipolicy/issues/69

do you have a proposed language that takes all comments into account? 
From what I understand, the Subordinate CA Certificate to be considered 
Technically Constrained only for S/MIME:


 * MUST include an EKU that has the id-kp-emailProtection value AND
 * MUST include a nameConstraints extension with
 o a permittedSubtrees with
 + rfc822Name entries scoped in the Domain (@example.com) or
   Domain Namespace (@example.com, @.example.com) controlled by
   an Organization and
 + dirName entries scoped in the Organizational name and location
 o an excludedSubtrees with
 + a zero‐length dNSName
 + an iPAddress GeneralName of 8 zero octets (covering the IPv4
   address range of 0.0.0.0/0)
 + an iPAddress GeneralName of 32 zero octets (covering the
   IPv6 address range of ::0/0)

Borrowing language from BRs 7.1.5, it would look like this:

"If the Subordinate CA Certificate includes the id‐kp‐emailProtection 
extended key usage, then the Subordinate CA Certificate MUST include the 
Name Constraints X.509v3 extension with constraints on rfc822Name and 
DirectoryName as follows:


(a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that 
the Applicant has registered the Domain or Domain Namespace or has been 
authorized by the domain registrant to act on the registrant's behalf in 
line with the verification practices of section 3.2.2.4.
(b) For each DirectoryName in permittedSubtrees the CA MUST confirm the 
Applicants and/or Subsidiary’s Organizational name and location such 
that end entity certificates issued from the subordinate CA Certificate 
will be in compliance with section 7.1.2.4 and 7.1.2.5.


If the Subordinate CA Certificate is not allowed to issue certificates 
with an iPAddress, then the Subordinate CA Certificate MUST specify the 
entire IPv4 and IPv6 address ranges in excludedSubtrees. The Subordinate 
CA Certificate MUST include within excludedSubtrees an iPAddress 
GeneralName of 8 zero octets (covering the IPv4 address range of 
0.0.0.0/0). The Subordinate CA Certificate MUST also include within 
excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering 
the IPv6 address range of ::0/0). Otherwise, the Subordinate CA 
Certificate MUST include at least one iPAddress in permittedSubtrees.


If the Subordinate CA is not allowed to issue certificates with 
dNSNames, then the Subordinate CA Certificate MUST include a zero‐length 
dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate 
MUST include at least one dNSName in permittedSubtrees."


Although this might seem to be an overkill (perhaps the EKU should be 
sufficient and we could remove the requirement for excludedSubtrees) , 
it clearly narrows down the scope of such a Subordinate CA to only S/MIME.



Dimitris.



On 5/5/2017 7:16 μμ, Gervase Markham via dev-security-policy wrote:

On 01/05/17 09:55, Gervase Markham wrote:

"Each entry in permittedSubtrees must either be or end with a Public
Suffix." (And we'd need to link to publicsuffix.org)

Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual
domain owned by someone.


The second option is harder to spec, because I don't know the uses to
which TCSCs for email are put. Is the idea that they get handed to a
customer, and so it's OK to say that the domain names have to be
validated as being owned by the entity which has authority to command
issuance? Or are there scenarios I'm missing?

CAs who issue email certs need to pay attention here, as I want to close
this loophole but am at risk of making policy which does not suit you,
if you do not engage in this discussion.

Gerv
___
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: Email sub-CAs

[Peter Bowen via dev-security-policy]

(Resending as the attached file was too large)

On Fri, May 5, 2017 at 10:46 AM, Peter Bowen  wrote:
> On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via
> dev-security-policy  wrote:
>> On 15/04/17 17:05, Peter Bowen wrote:
>>> Should the Mozilla policy change to require disclosure of all CA
>>> certificates issued by an unconstrained CA (but not necessarily
>>> require audits, CP/CPS, etc)? This would help identify unintentional
>>> gaps in policy.
>>
>> https://github.com/mozilla/pkipolicy/issues/73
>>
>> I think I understand your point but if you could expand a bit in the
>> bug, that would be most welcome.
>
> Right now the policy does not require disclosure of CA-certificates
> that the CA deems are technically constrained.  We have seen numerous
> cases where the CA misunderstood the rules or where the rules had
> unintentional gaps an disclosing the certificate as constrained will
> allow discovery of these problems.  For example the current policy
> says "an Extended Key Usage (EKU) extension which does not contain
> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
> means a certificate that has EKU extension with only the
> anyExtendedKeyUsage KeyPurposeId fall outside of the scope.  This is
> obviously wrong, but would not be discovered today.
>
> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for 
> disclosure; it is a
> revised version from the one I posted to the CA/Browser Forum list and
> depends on the same higher level workflow
> (https://cabforum.org/pipermail/public/attachments/20170430/0e692c4d/attachment-0002.png
> ).
>
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Jakob Bohm via dev-security-policy]

On 05/05/2017 17:37, Gervase Markham wrote:

On 04/05/17 19:30, Jakob Bohm wrote:

1. Issue D actually seems to conflate three *completely different*
  issues:


Are you sure you are not referring to the Issues List document here
rather than the proposal?



I am referring to the "summary" of D in the proposal, which talks about 
"Test Certificate Misissuance - issuance of several thousand test 
certs...", the descriptions I have found in the newsgroup talk about the 
separate situations I call D1, D2 and D3, each of which was different in 
their degree of misissuance and in their quantity.


I think summarizing it as misissuance times several thousands leads to 
an exaggeration, and a suggestion that problems in one part occurred 
also in another part.


From my understanding of past discussions:

D1 had actual misissuance, violation of procedures and apparently no
separation of duties.  But it was a small number of certs, the private
keys never left Symantec, the certs were quickly revoked, it was years
ago and other concrete measures were taken.

D2 only violated a form requirement (that an actual company name should
be in the O field), but it was a deliberate violation of procedure, a
lack of RA oversight, collusion between separated duties at the RA and
a large number of certificates.  And it was relatively recent.

D3 had actual misissuance (where CrossCert didn't control the test
domains) a deliberate violation of procedure, a lack of RA oversight,
collusion between separated duties at the RA and it was relatively
recent.  But it was apparently a smallish number of certificates (I
don't think there was an actual counting of how many certs were
actually in category D3 versus false positives from issue D2
and valid uses of the word test).

Please correct me if I missed some other test certificate misissuance 
incidents.




2. If the remaining unconstrained SubCAs are operated by Symantec and
  subject to (retroactive if necessary) compliance audits showing that
  they don't issue certs that could not (under the BR and Mozilla
  policies) be issued from a public Symantec CA by an "Enterprise RA"
  (as defined in the BRs), could those SubCAs not simply be
  reclassified as "public SubCAs" for Mozilla/BR policy purposes while
  remaining further usage limited by actual Symantec practices and
  contractual arrangements beyond the BR/Mozilla policies?


I'm afraid I just don't understand this.



Symantec has claimed that some of the remaining unconstrained SubCA's
identified before my post (they had not yet commented on the most
recent batch found) are hosted within Symantec's infrastructure, which
means that Symantec probably has some direct control over issuance
limitations, as well as complete logs of all issued certs.  This could
mean that reinterpreting their status as "public SubCAs subject to
Symantec policies and audits" rather than "flawed TCSCs lacking proper
'technical' constraints" could make them compliant.

Since such a formal/legal reinterpretation of the ground facts would be
retroactive going back from some time in May 2017 to when each SubCA
was issued, the related rephrased policy documents and additional BR
etc. audits would have to be similarly retroactive.

The goal of such a paperwork exercise would be to avoid revocation and
replacement of the EE certs issued from the SubCAs thus rescued.



   - Is it really necessary to outsource this to bring the Symantec PKI
under control?  Or was this simply copy/pasted from the
WoSign/StartCom situation?


Nothing like this was proposed for WoSign/StartCom.


I seem to recall that making WoSign/StartCom a (possibly disguised)
reseller of certs from another CA was a suggestion made as to what
WoSign/StartCom could do to keep their customer relationships during
their minimum 1 year of complete distrust.




   - If this is outsourced as suggested, how can/should Symantec
continue to serve customers wanting certificates that chain to
older CA certs in the old hierarchy.


The old cross-signs the new.


Some of the examples I mention seem to have tree height or other 
technical limitations baring this.  Which means that to serve those

segments, Symantec would need to operate the core of their CA
infrastructure while not having the large volume of WebPKI and S/MIME
certificates to fund basic operations.

Also some of these operate in peculiar (CP specified) modes that
most/all other CAs don't have ready systems to handle.  One variant
involve submitting the item to be signed to Symantec for (automated
and/or manual) inspection of the item, issuance of a one-off
certificate for signing that item followed by the immediate destruction
of the private key (this allows individual signatures to be revoked by
revoking the associated one-off cert).





   - Could some of the good SubCAs under the "Universal" and "Georoot"
program be salvaged by signing them from new roots and adding the
cross certs to default Mozilla and Chrome 

Re: Symantec: Draft Proposal

[Andrew Ayer via dev-security-policy]

On Fri, 5 May 2017 17:18:38 +0100
Gervase Markham via dev-security-policy
 wrote:

> On 05/05/17 17:09, Peter Bowen wrote:
> > We know that the RAs could use different certificate profiles, as
> > certificates they approved had varying issuers, and "Issuer DN" has
> > the same "No(1)" that CP has in the table in the doc you linked.  I
> > don't see any indication of what profiles each RA was allowed to
> > use. It could be that Symantec provided one or more profiles to the
> > RA that contained EV OIDs.
> 
> So the question to Symantec is: "did any of the RAs in your program
> have EV issuance capability? If not, given that they had issuance
> capability from intermediates which chained up to EV-enabled roots,
> what technical controls prevented them from having this capability?"
> Is that right?

It may be useful to note that Certsuperior, Certisur, Certisign, and
Crosscert were all advertising EV certificates on their websites at
some point in 2016:

http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx

http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros

http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada

http://web.archive.org/web/20161223000146/http://www.crosscert.com/

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

Re: Symantec: Draft Proposal

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 9:18 AM, Gervase Markham  wrote:
> On 05/05/17 17:09, Peter Bowen wrote:
>> We know that the RAs could use different certificate profiles, as
>> certificates they approved had varying issuers, and "Issuer DN" has
>> the same "No(1)" that CP has in the table in the doc you linked.  I
>> don't see any indication of what profiles each RA was allowed to use.
>> It could be that Symantec provided one or more profiles to the RA that
>> contained EV OIDs.
>
> So the question to Symantec is: "did any of the RAs in your program have
> EV issuance capability? If not, given that they had issuance capability
> from intermediates which chained up to EV-enabled roots, what technical
> controls prevented them from having this capability?" Is that right?

I do not see answers to those questions in any of the documents
Symantec has attached to the bug.

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

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

On 05/05/17 17:09, Peter Bowen wrote:
> We know that the RAs could use different certificate profiles, as
> certificates they approved had varying issuers, and "Issuer DN" has
> the same "No(1)" that CP has in the table in the doc you linked.  I
> don't see any indication of what profiles each RA was allowed to use.
> It could be that Symantec provided one or more profiles to the RA that
> contained EV OIDs.

So the question to Symantec is: "did any of the RAs in your program have
EV issuance capability? If not, given that they had issuance capability
from intermediates which chained up to EV-enabled roots, what technical
controls prevented them from having this capability?" Is that right?

Gerv

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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Gervase Markham via dev-security-policy]

On 01/05/17 09:55, Gervase Markham wrote:
> "Each entry in permittedSubtrees must either be or end with a Public
> Suffix." (And we'd need to link to publicsuffix.org)

Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual
domain owned by someone.

> The second option is harder to spec, because I don't know the uses to
> which TCSCs for email are put. Is the idea that they get handed to a
> customer, and so it's OK to say that the domain names have to be
> validated as being owned by the entity which has authority to command
> issuance? Or are there scenarios I'm missing?

CAs who issue email certs need to pay attention here, as I want to close
this loophole but am at risk of making policy which does not suit you,
if you do not engage in this discussion.

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

More CrossCert antics

[Gervase Markham via dev-security-policy]

CrossCert appear to be issuing BR-noncompliant certs under KISA roots now:
https://crt.sh/?cablint=101&iCAID=40347&opt=cablint

We don't trust KISA as it's a Super-CA:
https://crt.sh/?caid=55&opt=cablint
https://bugzilla.mozilla.org/show_bug.cgi?id=335197
https://bugzilla.mozilla.org/show_bug.cgi?id=1310580
but other root stores do.

Gerv


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

Re: Symantec: Draft Proposal

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via
dev-security-policy  wrote:
> On 04/05/17 21:58, Ryan Sleevi wrote:
>
> I asked Symantec what fields CrossCert had control over. Their answer is
> here on page 3:
> https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
> It says CrossCert (and so, presumably, the other RAs in the program) had
> no control over the CP field, which is (AIUI) the one they'd need to
> change in order to add an EV OID. If I've got this wrong, please tell me
> ASAP.

Note footnote (1): "These attributes and extensions are static values
configured in the certificate profile"

We know that the RAs could use different certificate profiles, as
certificates they approved had varying issuers, and "Issuer DN" has
the same "No(1)" that CP has in the table in the doc you linked.  I
don't see any indication of what profiles each RA was allowed to use.
It could be that Symantec provided one or more profiles to the RA that
contained EV OIDs.

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

Re: [EXT] Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

On 05/05/17 04:30, Steve Medin wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue

It feels somewhat strange to have this disjointed blog-vs.forum
conversation... Here are my initial reactions on reading it.

It seems to me that Symantec's new statement says very little which has
not been said before, and that Symantec continues to underestimate the
perceived severity of the issues.

An argument that "we have revalidated all of these certificates and we
haven't found very many with problems" seems basically like "OK, we
weren't paying attention to what was going on over there, but as far as
we can tell now, turns out it was nothing bad, so that's all OK then,
isn't it?" Well, no.

Symantec makes much of their upcoming super-strict audit regime, but
does not seem to address the concerns raised in my proposal about the
limitations of audit as a mechanism for ensuring appropriate conduct.

They also seem to have ceased engaging with the issues list entirely,
despite the fact that issue Y, a very serious issue, seems to be
developing new facets and ramifications daily.

> This transparency effort included explicitly providing to Google for
> whitelisting the certificates that were issued by Symantec prior to us
> fully deploying CT support.

I notice Chrome does not contain such a whitelist. Ryan: are you able to
comment on this?

> If this action is taken exclusively against Symantec, it will create
> significant disruption for hundreds of thousands of customers / users
> and will harm our CA business.

Mozilla does not take the possible business harm to CAs into
consideration - in either direction -  when considering our appropriate
response to a CA incident. It is unreasonable of Symantec to argue that
Mozilla should only take actions which result in no harm to Symantec's
business, just as it would be unreasonable for a community member to
argue that Mozilla should take additional actions "because the harm
isn't great enough yet to teach them a lesson" or somesuch.

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

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the
evidence that there were issues
> and patterns that were unresolved, and thus sought to minimize the impact
> of an eventual total distrust in a gradual way.

So the first Chrome proposal had the explicit target of an eventual
total distrust? Or was it possible that, upon good behaviour from
Symantec, the extent of that proposal would remain the status quo on an
ongoing basis?

> Regarding EV certificates, your analysis of EV certificates appears to have
> failed to include Issue D.

Hmm, you are correct. At least one EV cert, for www.google.com, was
mis-issued in issue D; it ended up in CT logs. Noted.

> In particular, in the iterations of the Final
> Reports, Symantec acknowledged that their authentication team was not
> properly reviewing the work of validation. That is, EV certificates are
> required to have a separation of duties to ensure multi-party control
> (Section 14.1.3),

That section says: "The CA MUST enforce rigorous control procedures for
the separation of validation duties to ensure that no one person can
single-handedly validate and authorize the issuance of an EV Certificate."

While the Symantec report does not provide explicit evidence that this
part of the EV Guidelines was violated by their test certificate
issuance, you are right that it's likely it was.

> This is also captured in “Issue 3” on https://www.symantec.com/page.
> jsp?id=test-certs-update#

I don't see numbered issues, or an "Issue #3", at that URL?

> I’m also having trouble finding assertions or guarantees from Symantec that
> at no point has any RA been involved in the issuance of EV certificates. 

I asked Symantec what fields CrossCert had control over. Their answer is
here on page 3:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
It says CrossCert (and so, presumably, the other RAs in the program) had
no control over the CP field, which is (AIUI) the one they'd need to
change in order to add an EV OID. If I've got this wrong, please tell me
ASAP.

> If
> Symantec is unwilling or unable to provide that assurance, or if it later
> emerges that evidence of such issuance is found, does Mozilla have any
> thoughts on how best to address it? More specifically - would that be a
> removal of EV or a removal of trust, should such evidence emerge?

If these RAs had EV issuance capability, given the lack of oversight of
them and their lack of EV audits, I would consider that to be more than
sufficient grounds for removing the EV indicator from Symantec. As for a
removal of trust, I withhold judgement.

> Regarding your analysis of the other incidents for precedent, you drew a
> bright line around intentional deception in the case of WoSign and
> StartCom, which seems a little heavy-handed. Were you thinking about their
> response to the disclosure of StartCom’s sale, or to the backdated
> issuance? 

Both. (Some of the relevant interactions regarding the sale were by
private email.)

> Does Mozilla have a process for determining what is deceptive
> and/or intentional? During those past discussions, there was concern that
> perhaps the answers were just based on a misunderstanding of the request,
> and not intentional deception. Richard Wang certainly argued this
> perspective, in part, in his Incident Report regarding Issue R
> .

I am basing my assessment not only on the published documentation from
WoSign, but also the conversations we had at our face-to-face meeting,
where deception was plainly admitted.

> I’m curious how you view the answers for Q9. 

Presumably you mean the answer in
https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216
?

> In particular, in light of the
> subsequent information disclosing that third-party RAs are involved in the
> issuance of domain controller certificates, for which the publicly
> available evidence suggests are indistinguishable from SSL/TLS
> certificates, thus in scope of the Mozilla Certificate Policy, what was the
> reasonable or common understanding of CAs on what was being asked, and was
> it upheld? Further, given the the lack of complete disclosure of some
> subordinates, or the exclusion of other subordinates from the scope of the
> audits that they’re claimed to participate in, at what point does the
> result become unreasonable?

I guess I have a high standard for calling someone a liar.

> I ask this, in part, because your alternative proposal to moving to new,
> independently operated infrastructure to take some form of immediate action
> to clean up and document the extent of the publicly-trusted PKI. Given the
> statements Symantec made to Mozilla - in May 13, 2014
>  and in May 2015
>  - asserting to
> Mozilla that they had fully disclosed their subordinate certificates, and
> that those c

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

On 04/05/17 19:30, Jakob Bohm wrote:
> 1. Issue D actually seems to conflate three *completely different*
>   issues:

Are you sure you are not referring to the Issues List document here
rather than the proposal?

> 2. If the remaining unconstrained SubCAs are operated by Symantec and
>   subject to (retroactive if necessary) compliance audits showing that
>   they don't issue certs that could not (under the BR and Mozilla
>   policies) be issued from a public Symantec CA by an "Enterprise RA"
>   (as defined in the BRs), could those SubCAs not simply be
>   reclassified as "public SubCAs" for Mozilla/BR policy purposes while
>   remaining further usage limited by actual Symantec practices and
>   contractual arrangements beyond the BR/Mozilla policies?

I'm afraid I just don't understand this.

>- Is it really necessary to outsource this to bring the Symantec PKI
> under control?  Or was this simply copy/pasted from the
> WoSign/StartCom situation?

Nothing like this was proposed for WoSign/StartCom.

>- If this is outsourced as suggested, how can/should Symantec
> continue to serve customers wanting certificates that chain to
> older CA certs in the old hierarchy.

The old cross-signs the new.

>- Could some of the good SubCAs under the "Universal" and "Georoot"
> program be salvaged by signing them from new roots and adding the
> cross certs to default Mozilla and Chrome installations (so servers
> don't need to install them)?  For example, if the legit EV SubCAs
> under "Universal" are cross-signed by a (new) "EV-only" root, could
> Mozilla move the EV trust to that new root, thus removing the
> risk of EV-trusting any other "Universal" subCAs.

I'm sure we'd be open to discussing implementation details like that.

Gerv

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

Re: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote:

On 05/05/17 10:22, Rob Stradling wrote:

Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.


It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an introductory website for the CCADB, once Mozilla IT
configures things correctly ;-)


How about...

login.ccadb.org => mozillacacommunity.force.com
(to be changed on May 19th to => ccadb.force.com)

reports.ccadb.org => mozillacaprogram.secure.force.com
(to be changed on May 19th to => ccadb.secure.force.com)

?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Changing CCADB domains

[Gervase Markham via dev-security-policy]

On 05/05/17 10:22, Rob Stradling wrote:
> Mozilla could CNAME from ccadb.org to .force.com, and then
> declare that the ccadb.org URLs are the official ones.

It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an introductory website for the CCADB, once Mozilla IT
configures things correctly ;-)

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

Re: Updating Root Program wiki pages

[Gervase Markham via dev-security-policy]

On 04/05/17 18:42, Kathleen Wilson wrote:
> Gerv is leading the effort to clean up Mozilla's Root Store related
> wiki pages.

With lots of help from Kathleen :-)

> Please let me know if information that you need disappears, and you
> are not able to find it by starting with https://wiki.mozilla.org/CA

The areas we haven't really tackled yet are those documenting the
application process, and those relating to the CCADB. But hopefully you
should already find:

https://wiki.mozilla.org/CA

to be a much more useful portal to our CA-related content than was
available previously.

Gerv

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

Re: [EXT] Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

It is clear to me from reading this that there is a significant gap between
Symantec's perspective on the severity of the issues discussed and the
perspective of many m.d.s.p. participants. Hopefully this email will serve
to highlight some specific areas that contribute to this gap, and which
leads many of us to find Symantec's proposal insufficient.

Quoting:
> Moreover, the additional transparency we are already providing by logging
all certificates issued to Certificate Transparency logs – including DV and
OV – is a practice that the rest of the industry has yet to adopt.

Given that Symantec's CT logging was imposed as a requirement for continued
trust in Chrome, it is misleading to state that this reflects an effort by
Symantec to go above and beyond (particularly given that some other CAs
_voluntarily_ log all certs to CT).

That is, however, a question of style. To ask a substantive question, you
have asserted that all certificates issued have been logged to CT; this
Symantec CA currently has no publicly logged issued certificates:
https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798&opt=mozilladisclosure.
Can you confirm that this CA has _never_ been used to issue a certificate?
(There are several other similar Symantec intermediates for which there are
no publicly logged certs about which I have the same question).

Some of Symantec's assertions (particularly those about re-auditing issued
certificates) seem to largely revolve around distinguishing the level to
which their practices resulted in mis-issuance and the level of risk they
represented for relying parties. To use an analogy, if I have a publicly
trusted CA certificate and private key on a USB stick in my apartment, this
represents a _massive_ risk for relying parties everywhere, even I never
issue a single certificate from it. I would expect the WebPKI community to
treat this with the utmost severity, even if I never (mis-)issued a single
a certificate!

Finally, Symantec states "we have put forward a proposal [1] that provides
the highest level of transparency and reassurance of trust in active
SSL/TLS certificates available in the industry" and "we believe our
proposal provides the most open and transparent posture of any CA in the
industry and reassures trust in active Symantec certificates and our
current issuance practice". To help bridge the gap between Symantec and
many other participants understanding, if Symantec were to propose an _even
more_ aggressive remediation plan, aiming to achieve even higher levels of
reassurance, what is the next additional change you would propose?

Alex


On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec: Draft Proposal
> >
> > Here is my analysis and proposal for what actions the Mozilla CA
> Certificates
> > module owner should take in respect of Symantec.
> >
> [snip]
>
> > Please discuss the document here in mozilla.dev.security.policy. A good
> > timeframe for discussion would be one week; we would aim to finalise the
> > plan and pass it to the module owner for a decision next Monday, 8th May.
> > Note that Kathleen is not around until Wednesday, and may choose to read
> > rather than comment here. It is not a given that she will agree with me,
> or
> > the final form of the proposal :-)
> >
> > Gerv
>
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues
> -public-dialogue
> .
>
>
>
> ___
> 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: Symantec: Draft Proposal

[Kurt Roeckx via dev-security-policy]

On 2017-05-04 22:55, Alex Gaynor wrote:

I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.

The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or there are still more. Personally, I
think this highlights the value of my earlier proposal, and I think it's
worth considering if, before any long term remediation strategies are
considered, such a rule requiring full disclosure and CT submission of all
Symantec CA certificates be implemented.


They were already required to disclose them, so I think just requiring 
them to submit them to CT it not going to change much. You would also 
need to enforce that all CA certificates have been submitted to CT when 
validating anything that that traces back to one of their CAs. Note that 
the subscriber certificate doesn't need to be submitted for that,

just all the CA certificates.

If we were to require submission to CT, we should probably also require 
that it's been submitted to CT some time before, so that we can do such 
checks as seeing they actually have the proper audit.


That leave what we should do with such certificates if they don't have 
the needed audits. And I think Mozilla already has a policy for that, 
which we should probably follow.



Kurt

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

Re: Changing CCADB domains

[Peter Bowen via dev-security-policy]

Yes
On Fri, May 5, 2017 at 2:22 AM Rob Stradling 
wrote:

> On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
> > On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
> > dev-security-policy  wrote:
> >> All,
> >>
> >> I think it is time for us to change the domains that we are using for
> the CCADB as follows.
> >>
> >> Change the links for...
> >>
> >> 1)  CAs to login to the CCADB
> >> from
> >> https://mozillacacommunity.force.com/
> >> to
> >> https://ccadb.force.com/
> >>
> >> 2) all published reports
> >> from
> >> https://mozillacaprogram.secure.force.com/
> >> to
> >> https://ccadb.secure.force.com/
> >>
> >>
> >> We asked Salesforce for a temporary redirect from the old to the new
> URLs, but that was declined because we're not paying for premium support
> for the CCADB. (Other than this change, I do not currently see the need for
> us to pay for premium support.)
> >
> > Is it also a "premium" feature to use custom domain names?  I think it
> > would probably make sense to use ccadb.org (which seems to belong to
> > Mozilla) rather than force.com.
>
> Mozilla could CNAME from ccadb.org to .force.com, and then
> declare that the ccadb.org URLs are the official ones.
>
> Is that what you meant, Peter?
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec: Draft Proposal

[tmcqueen.old--- via dev-security-policy]

Steve,

I am glad to see that Symantec is willing to continue public discussion on 
possible paths forward. But these responses still seem to continue to focus on 
the RA issue, and do not respond to or address all of the other serious issues 
identified here. For example, issue Y (Q9) -- un- or under- audited sub-CAs 
technically capable (even if administratively constrained) of issuing SSL/TLS 
certificates trusted by Mozilla (and others). Especially given that there are 
clearly still undislosed sub-CAs that Symantec is only now revealing (despite 
claims in 2014/2015 that all had been), at least one with a non-zero pathlen 
constraint (e.g. 
https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798
 ) and thus capable not only of issuing end-entity certs, but of having 
undisclosed sub-subCAs. 

For reasons such as this, I am highly skeptical that Symantec [intentionally or 
not] appreciates the gravity of the issues raised here; had Symantec's current 
proposal been the response to the test certificate problems from a couple of 
years ago, I would have considered it an appropriate response. Now I view it as 
an untenable position that can be succinctly described as: too little, too 
late, to restore confidence in Symantec management and issuance practices.

The argument against the new public PKI (making the existing symantec PKI a 
large private PKI) also seems quite weak, essentially boiling down to: Symantec 
thinks it is not a proportional response to the issues identified, implicitly 
acknowledging that it may mitigate many of the compatibility concerns of your 
customers as long as the new roots or subCAs are signed by the old roots as 
needed. 

I'd also be very curious to know the answer to Ryan's question about EV 
certificates and RAs (both now and in the past), as the answer to that seems 
germane to Mozilla's decision making process.

Also, your reporting of the responses of your enterprise customers seems a bit 
incongruous: in the earlier response, you claimed many large enterprises would 
require months or years to plan a change of certificates -- but then claim here 
that should Symantec be restricted to 13 months, these customers will move to 
other CAs who can issue longer certs. But given the direction of travel in cert 
lifetimes (where 2 yr+renewal time begins in 2018 and it is plausible a 13 
month lifetime may be required in 2-3 years), I don't understand how moving 
would be substantially advantageous to these customers (esp. since any of the 
proposals here would involve less compatability risks since chaining to the old 
symantec roots would be maintained).

On Thursday, May 4, 2017 at 11:30:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec: Draft Proposal
> > 
> > Here is my analysis and proposal for what actions the Mozilla CA
> Certificates
> > module owner should take in respect of Symantec.
> > 
> [snip]
> 
> > Please discuss the document here in mozilla.dev.security.policy. A good
> > timeframe for discussion would be one week; we would aim to finalise the
> > plan and pass it to the module owner for a decision next Monday, 8th May.
> > Note that Kathleen is not around until Wednesday, and may choose to read
> > rather than comment here. It is not a given that she will agree with me,
> or
> > the final form of the proposal :-)
> > 
> > Gerv
> 
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
> .

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

Re: [EXT] Re: Symantec: Draft Proposal

[wizard--- via dev-security-policy]

Steve,

Thank you for the prompt response, and I am glad this certificate was in fact 
validated internally by Symantec.

On Tuesday, May 2, 2017 at 6:55:13 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > wizard--- via dev-security-policy
> > Sent: Tuesday, May 02, 2017 7:10 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec: Draft Proposal
> >
> >
> > Also, in the responses, Symantec claims that MSC Trustgate is no longer an
> > RA (but could be a reseller). I did a quick search on crt.sh for recent
> > certificates that have supplied by MSC Trustgate:
> >
> > [link]
> >
> > Going back to April 2013, this is the *only* "supplied by MSC trustgate"
> > certificate in crt.sh that chains off a Symantec root; all others are 
> > Globalsign.
> > Can Symantec confirm that they vetted this (OV) certificate in-house? While 
> > I
> > suppose MSC could supply certs from multiple CAs, I find it odd that
> > everything in the logs since April 2013 is Globalsign except this one 
> > outlier --
> > and am concerned it means there was some mechanism for MSC to issue /
> > have issued a cert off a Symantec chain -- and this concerns me given the
> > higher nominal level of validation.
> 
> MSC Trustgate is an approved reseller of Symantec certificates. They are no 
> longer operating as an SSL/TLS RA. This certificate was authenticated and 
> issued by Symantec after having been properly submitted to us by MSC 
> Trustgate.

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

Re: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:

On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy  wrote:

All,

I think it is time for us to change the domains that we are using for the CCADB 
as follows.

Change the links for...

1)  CAs to login to the CCADB
from
https://mozillacacommunity.force.com/
to
https://ccadb.force.com/

2) all published reports
from
https://mozillacaprogram.secure.force.com/
to
https://ccadb.secure.force.com/


We asked Salesforce for a temporary redirect from the old to the new URLs, but 
that was declined because we're not paying for premium support for the CCADB. 
(Other than this change, I do not currently see the need for us to pay for 
premium support.)


Is it also a "premium" feature to use custom domain names?  I think it
would probably make sense to use ccadb.org (which seems to belong to
Mozilla) rather than force.com.


Mozilla could CNAME from ccadb.org to .force.com, and then 
declare that the ccadb.org URLs are the official ones.


Is that what you meant, Peter?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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