[cabfpub] New proposed text for BR 1.1 issues 15 and 29

[Rich Smith]

Rob can probably better answer how we deal with them.  I know we do parse
the xn--xxxxxxx into readable form and stop them all for human review so
that we can keep an eye out for blatant attack domains, but the technical
end of it is not my forte.  I'm just concerned that whoever came up with the
two different standards already screwed up by not make 2008 backward
compatible w/2003, and it seems that 2003 has some serious flaws, so it
seems that someone ought to step in now and force the issue before there are
wide spread problems.  It also seems to me that CAs are in a position to do
that if we all simply refuse to work with 2003.  That being said, as I have
stated, I'm not at all well versed in this, so I may be overstating the case
as far as it really being a problem.

 

It would also be beneficial to have some idea of which version the
registries who handle these have implemented against.  If 90% are already
2008 compliant then that would bolster the argument for a line in the sand
and just make the stragglers update.

 

-Rich

 

From: Hill, Brad [mailto:bhill at paypal-inc.com] 
Sent: Friday, September 28, 2012 12:09 PM
To: richard.smith at comodo.com; public at cabforum.org; Yngve Nysaeter Pettersen
(yngve at opera.com)
Subject: RE: [cabfpub] New proposed text for BR 1.1 issues 15 and 29

 

Well, if the CABF members have noticed anything about me, it's that I
perhaps am not cautious enough about peeing on fences that might be
electrified.  But even I can smell the ozone and see the charred bits of fur
stuck to this one.

 

If the CAs want to "draw a line in the sand" with the browsers and
registrars on IDNA2008, that's your prerogative, but don't tell them I told
you to it.

 

But maybe it's not a big issue yet.  Does anyone have a convenient copy of
the SSLObservatory data instantiated? Or perhaps Yngve can tell us based on
his data how many certificates are out there today for non-ASCII names?  

 

I'd also like to know, Yngve (and other browsers) how you handle punycode in
certificates, since you mentioned that at the face-to-face.  Do we need to
add additional requirements about reverse-encoding punycode DNSNames to
U-labels and applying the proposed tests?

 

-Brad

 

From: Rich Smith [mailto:richard.smith at comodo.com] 
Sent: Friday, September 28, 2012 11:06 AM
To: Hill, Brad
Subject: RE: [cabfpub] New proposed text for BR 1.1 issues 15 and 29

 

Brad,

I know we talked about the 2003 vs. 2008 problem and this is partly because
I'm not completely literate in this issue, but it seems to me that given the
possible name confusion, and the fact that 2008 expressly prohibits the use
of some characters, while 2003 only vaguely discourages such use, I think it
would be better for everyone if the CA/B Forum drew a line in the sand and
said only 2008 is acceptable.  We should force the browsers AND the
registries to update if they want certs to work.  That being said, I'm not
sure we can get away with pushing the issue, but I think we should if we
can.

-Rich

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Hill, Brad
Sent: Wednesday, September 26, 2012 2:20 PM
To: public at cabforum.org
Subject: [cabfpub] New proposed text for BR 1.1 issues 15 and 29

 

Updated proposal attached.  

 

Changes:

 

.         Updated rules for IDN hostname labels to "label components" to
allow, e.g. non-Latin scripts to be combined with Latin gTLD suffixes such
as ".com"

.         Updated IDNA requirements such that hostnames must be valid in
EITHER IDNA2003 or IDNA2008.  Opera is currently the only browser that
supports IDNA2008, Mozilla has a bug to support it, and WebKit apparently
has no current plans to implement IDNA2008.  Allowing both standards allows
maximum compatibility, though there is some risk as some names that are
valid in one but not the other, and some which are valid in both but resolve
to different effective host names.

.         Updated the Unicode Security Mechanisms Restriction Levels and
Alerts reference which has moved from UTR #36 to UTS #39 in the last few
weeks.

 

Brad Hill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120928/b7bce034/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120928/b7bce034/attachment-0004.bin>