<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My understanding is that the punycode issue is not altered by this ballot, because the current definitions state:</div><div class="">
                
        
        
                <div class="page" title="Page 14">
                        <div class="layoutArea">
                                <div class="column"><p class=""><span style="font-size: 10.000000pt; font-family: 'Cambria'; font-weight: 700" class="">Domain Name: </span><span style="font-size: 10.000000pt; font-family: 'Cambria'" class="">The label assigned to a node in the Domain Name System.</span></p><p class=""><font face="Cambria" class=""><span style="font-size: 10pt;" class="">and in the DNS, the label assigned to a node with an internationalised domain name is encoded in punycode.  So it is not allowed to produce certificates with UTF-encoded IDNs today.</span></font></p><div class=""><br class=""></div><div class="">I think that if GDCA is serious about this concern, they should propose a ballot which removes the restriction that commonName must match one of the subjectAltNames.  I don’t know if the world is ready for such a ballot yet, but I think the resulting discussion would be beneficial.  Perhaps the ballot could propose some additional restriction(s), such as that the commonName must contain a space, or a character higher than 0x00FF in unicode, or must not contain a period, so that the commonName couldn’t be mistaken for a domain name.</div>
                                </div>
                        </div>
                </div></div></body></html>