[cabfpub] ICANN, gTLD, internal names

Jeremy Rowley jeremy.rowley at digicert.com
Sat Mar 16 04:31:06 UTC 2013


A couple of thoughts:

1) The baseline requirements are meant to be minimum standards.  As such, I
expect that most CAs will start to revoke/stop issuing potentially affected
certificates as soon as possible, probably well before the 120 day
post-approval deadline.  The 120 day deadline was chosen to give CAs time to
notify customers and help them transition away from these type of
certificates.  In my experience, most customers need a few months to make
significant changes to their systems.  The 120 day deadline will give these
customers time to decide on and implement an alternate solution, including
modifying their internal networks in a manner that avoids the conflict
problems described by Rick and Geoff. 

2) Although I'm sure they would have preferred an immediate resolution to
the issue, ICANN indicated that a 120-phase out period was acceptable in
mitigating the risks.  I think they indicated that most of the new gTLDs
will not be registrable 120 days after approval, meaning there is little
risk of someone purchasing a certificate with a new gTLD and using it for an
attack on an internal network. 

3) One unanswered concern is how to treat CAs that are not part of the
Forum.  The Forum's errata will likely not become part of the BR audit
criteria until well after adoption of the new gTLDs.  This means that some
CAs might not realize the problem and may continue issuing certificates to
internal server names beyond the 120 day deadline.  I strongly encourage the
browsers to require compliance with this particular errata well before it
becomes auditable.  This will ensure that all CAs are uniformly working
towards the adopted solution.

4) I agree with Geoff - fault is irrelevant. Since ICANN will be releasing
the new gTLDs soon (which may include.corp), CAs and Browsers are in the
best position to help mitigate security concerns (although not the concern
expressed by Rick Andrews).  As such, the Forum participants should take the
lead in resolving the issue, regardless of opinions on the problem's
origination.  I think the Forum did just that by passing the gTLD ballot,
provided that browsers require adherence by all CAs.

5) I am disappointed that the routing problem was not mentioned in the ICANN
report, despite us pointing out the issue.  Although the Forum can't solve
the routing problem, we can provide assistance to customers in understanding
the impact of using the names.  Hopefully, the unavailability of
certificates for these internal names will provide awareness on the issue
and encourage companies using internal names to re-evaluate their decision.

Jeremy



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Hill, Brad
Sent: Friday, March 15, 2013 9:32 PM
To: Geoff Keating
Cc: public at cabforum.org
Subject: Re: [cabfpub] ICANN, gTLD, internal names

Geoff is right.  Or consider what happens when a widget corp employee takes
his laptop home or to Starbucks.  His email client starts sending his name,
password and email to exchange.corp

Brad Hill
Ecosystem Security
PayPal Information Risk Management
cell: 206.245.7844 / skype: hillbrad

On Mar 15, 2013, at 6:21 PM, "Geoff Keating" <geoffk at apple.com> wrote:

> 
> On 15/03/2013, at 4:47 pm, Robert Relyea <rrelyea at redhat.com> wrote:
> 
>> On 03/15/2013 03:27 PM, Geoff Keating wrote:
>>> One thing that does affect CAs is that if a heavily used internal TLD
like .corp is made global, then there's still the possibility of conflict
between an internal CA and a cert that a global CA issues.
>>> 
>>> For example, suppose Widgets Inc. uses widget.corp internally.  They
have an internal CA and have issued a cert to www.widget.corp.  Now suppose
ICANN allocates .corp and someone else registers widget.corp.  Even after
2016, that someone else can get a cert from a CABforum CA for
www.widget.corp (since they own it) and then use that cert to attack Widgets
Inc.
>> What, seriously? You are worried that the owner of the domain can
man-in-the-middle a local unrouteable domain?
> 
> I'm worried that someone who is, perhaps, already inside Widget's network,
can register its domain, get a certificate, and then intercept the traffic.
> 
> This is not the case where Widget's internal CA is publicly trusted.  The
CA is installed only on their machines.
> 
>> What ICANN is asking for is the Widgets, Inc. widget.corp cert be revoked
'now', so the first cert becomes invalid, since it hasn't been verified.
> 
> It's not reasonable to say the first cert is 'invalid'.  Within the scope
of Widget's CA, there is only one www.widget.corp and it's been issued
properly.
> 
>> It's Widgets Inc. that has the invalid cert, not the true domain owner.
> 
> It could be said that Widgets Inc. should never have used .corp like this,
they should have known better.  But also it could be said that the Internet
community as a whole encouraged this kind of thing.  *I* would say that it
doesn't matter who was at fault.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public




More information about the Public mailing list