Re: Identrust Commercial Root CA 1 EV Request

2018-11-07 Thread identrust--- via dev-security-policy 
On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:
> I am recommending denial of this request.
> 
> It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
> I'm not going to argue this point and claim that these certificates were
> misissued because 'identrust.int' and 'identrus.int' were not registered
> domain names.
> 
> Under the assumption that these are Internal Names, none of these
> certificates were issued after the BR deadline of 1-November 2015. From
> this I would infer that Identrust was aware of the requirements. Three of
> the disclosed certificates were not expired or revoked prior to the BR
> Internal Name deadline of 1-October 2016:
> https://crt.sh/?id=7852280
> https://crt.sh/?id=882509134
> https://crt.sh/?id=882509077
> 
> This happened in spite of well documented incidents in which other CAs
> failed to revoke certificates containing Internal Names [1]. One of these
> three certificates was revoked on 22-February 2018, corresponding with the
> date Nick Hatch reported it to Identrust. Identrust did not disclose the
> incident, nor - given that the other two were never revoked - did they
> apparently perform a scan of their certificates to identify any others.
> This calls into question Identrust's ability to adhere to the BRs, their
> remediation practices, and their willingness to publicly disclose incidents.
> 
> Identrust has requested that Mozilla grant EV indication to the Commercial
> Root CA 1 - the same root involved in this incident. Identrust's actions in
> this incident are troubling and provide justification for denying the
> higher level of trust implied by EV.
> 
> - Wayne
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ
> 
> On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> > dev-security-policy wrote:
> > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> > dev-security-policy wrote:
> > > > > > 5.Explanation about how and why the mistakes were made, and not
> > caught and
> > > > > > fixed earlier.
> > > > > >
> > > > > > IdenTrust:
> > The certificate was generated for a server within IdenTrust.
> > > > > > The certificate contained internal domain names which were not
> > reachable
> > > > > > externally.  Two domain names in the SAN (
> > Autodiscover.identrus.int and
> > > > > > Mercury.identrus.int) were included at that time.  When the
> > certificate
> > > > > > was generated, these domains were internally hosted domains.
> > > > >
> > > > > This doesn't explain why the mistakes were made, nor does it explain
> > why
> > > > > they were not caught and fixed earlier.
> > > >
> > > > IdenTrust:IdenTrust has strict procedures regarding issuance of
> > publicly
> > > > trusted website certificates.  However at the time of this certificate
> > > > issuance (2015) the procedures did allow ability to request exceptions
> > for
> > > > IdenTrust internal deployments that were not accessible externally.
> > >
> > > On what date was this exception-requesting element added to IdenTrust's
> > > procedures?
> > IdenTrust:
> > At this point we are unable to ascertain the exact date the
> > exception-requesting element was added.  We can confirm the that the
> > exception-requesting element pre-dates 2012.
> >
> > > Please share the criteria which were used to evaluate exception requests.
> > IdenTrust:
> > The criteria for the exception is  that Registration desk, upon request of
> > IdenTrust IT Staff, can request to risk management an exception to complete
> > an attempted Verification of Domain through external registrars for domain
> > name that is IdenTrust owned domain equivalent for servers that will not be
> > accessible externally.
> >
> > > How many times has the procedure for requesting an exception been used?
> > How
> > > many times has the exception been granted?  I think it would be best if
> > all
> > > certificates issued under this exception process were made public, to
> > ensure
> > > that there is full transparency around the extent to which this exception
> > > process was used.
> > IdenTrust:
> > The exception request has been used on the issuance of the 13 certificates
> > listed below, now in CT logs.  Please note that majority of the
> > certificates listed were issued pre-2012.
> > https://crt.sh/?id=514746
> > https://crt.sh/?id=7852280
> > https://crt.sh/?id=882509134
> > https://crt.sh/?id=882509077
> > https://crt.sh/?id=882509158
> > https://crt.sh/?id=882509159
> > https://crt.sh/?id=882597656
> > https://crt.sh/?id=882509100
> > https://crt.sh/?id=882509154
> > https://crt.sh/?id=882509101
> > https://crt.sh/?id=882597659
> > https://crt.sh/?id=882509103
>

Re: Comodo Rebrand to Sectigo

2018-11-07 Thread (RS) Tyler Schroder via dev-security-policy 
Thanks for the clarification! That makes much more sense.


-Tyler


On 11/7/2018 6:28 AM, Rob Stradling via dev-security-policy wrote:
> CAUTION: This message was sent from outside the company.
>
>
> On 07/11/2018 01:36, RS Tyler Schroder via dev-security-policy wrote:
>> Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo 
>> 
>>
>> (Talked with Wayne off-list to confirm there's no announcement required 
>> under BR Sec. 8, so just posting it for general awareness / discussion)
> Hi Tyler.  Thanks for posting this.  However, I think your
> (unfortunately inaccurate) statement - "Comodo has rebranded to Sectigo"
> - demonstrates perfectly the confusion between two distinct
> organizations that necessitated this rebrand!
>
> Comodo (https://www.comodo.com/) has not rebranded.  Comodo, which
> continues to offer various cybersecurity products and services, ceased
> being a CA when it sold a majority share in its "Comodo CA" business
> unit to Francisco Partners just over a year ago.
>
> Sectigo (https://sectigo.com/) is the new name for "Comodo CA".
>
> https://sectigo.com/newsroom/comodo-ca-rebrands-as-sectigo
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
>
> ___
> 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: Comodo Rebrand to Sectigo

2018-11-07 Thread Rob Stradling via dev-security-policy 
On 07/11/2018 01:36, RS Tyler Schroder via dev-security-policy wrote:
> Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo 
> 
> 
> (Talked with Wayne off-list to confirm there's no announcement required under 
> BR Sec. 8, so just posting it for general awareness / discussion)

Hi Tyler.  Thanks for posting this.  However, I think your 
(unfortunately inaccurate) statement - "Comodo has rebranded to Sectigo" 
- demonstrates perfectly the confusion between two distinct 
organizations that necessitated this rebrand!

Comodo (https://www.comodo.com/) has not rebranded.  Comodo, which 
continues to offer various cybersecurity products and services, ceased 
being a CA when it sold a majority share in its "Comodo CA" business 
unit to Francisco Partners just over a year ago.

Sectigo (https://sectigo.com/) is the new name for "Comodo CA".

https://sectigo.com/newsroom/comodo-ca-rebrands-as-sectigo

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

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