[cabfpub] BR Issues 15 and 29, take two

[Rick Andrews]

Bruce,

We discussed this on the call today, and some people expressed concern about removing the CN field, that legacy software would break. And it occurred to me that this particular requirement should be accompanied by an equivalent requirement on the browsers to work properly with certs that have no CN field. Would you consider adding this?

Also, I understand the reason for removing multiple CNs, but I don’t understand the impetus for removing it completely. Yngve pointed out that there’s some RFC that already mandates ignoring the CN if there is a SAN extension, but again, having a browser requirement to not display the CN to the user if there is a SAN might make sense.

-Rick

From: Bruce Morton [mailto:bruce.morton at entrust.com]
Sent: Friday, July 20, 2012 12:36 PM
To: Rick Andrews; 'Hill, Brad'; 'management at cabforum.org'
Subject: RE: BR Issues 15 and 29, take two

Here is an updated version. Thanks to Rick for the changes.

Please let me know if there are any other comments or any endorsers.

Thanks, Bruce.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Thursday, July 19, 2012 1:43 PM
To: Bruce Morton; 'Hill, Brad'; 'management at cabforum.org'
Subject: RE: BR Issues 15 and 29, take two

Bruce, sorry to be a nit-picker, but the definition of U-label refers to a Protocol document and a Tables document (which seem to be other RFCs). I suggest you add references for those too.

-Rick

From: Bruce Morton [mailto:bruce.morton at entrust.com]<mailto:[mailto:bruce.morton at entrust.com]>
Sent: Thursday, July 19, 2012 5:20 AM
To: 'Hill, Brad'; Rick Andrews; 'management at cabforum.org'
Subject: RE: BR Issues 15 and 29, take two

I have updated the proposal per Andrew’s comments and Brad’s clarifications. I have also changed the dates in 9.2.2 per iida’s comments.

If this addresses all concerns them I am still looking for two endorsers.

Thanks, Bruce.

From: Hill, Brad [mailto:bhill at paypal-inc.com]<mailto:[mailto:bhill at paypal-inc.com]>
Sent: Monday, July 16, 2012 4:04 PM
To: Rick Andrews; Bruce Morton; 'management at cabforum.org'
Subject: RE: BR Issues 15 and 29, take two

Rick,

Agree mostly, with a few clarifications inline.

-Brad

9.2.6:
I wasn’t familiar with the term “U-label”, and it doesn’t seem to be defined in the unicode.org reference. I found it at http://idn.icann.org/IDN_basics. Can you include the reference in your update?

Putting in those IDN checks will take some time, so I hope you don’t ask for these changes to go into effect in three months :^)

[Hill, Brad] U-label is defined by http://tools.ietf.org/html/rfc5890#section-2.3.2.1 as:
      A "U-label" is an IDNA-valid string of Unicode characters, in
      Normalization Form C (NFC) and including at least one non-ASCII
      character, expressed in a standard Unicode Encoding Form (such as
      UTF-8).  It is also subject to the constraints about permitted
      characters that are specified in Section 4.2<http://tools.ietf.org/html/rfc5890#section-4.2> of the Protocol
      document and the rules in the Sections 2<http://tools.ietf.org/html/rfc5890#section-2> and 3<http://tools.ietf.org/html/rfc5890#section-3> of the Tables
      document, the Bidi constraints in that document if it contains any
      character from scripts that are written right to left, and the
      symmetry constraint described immediately below.  Conversions
      between U-labels and A-labels are performed according to the
      "Punycode" specification [RFC3492<http://tools.ietf.org/html/rfc3492>], adding or removing the ACE
      prefix as needed.

I agree that I should have specified this by reference or inline as part of the language.

I’m open to suggestions as to a reasonable timeline for implementation.

11.1.4:
“Before issuing a certificate with a wildcard character (*) in a CN or DNS‐ID...” Do you mean a CN or SAN?

[Hill, Brad] Yes, I meant a SAN of type DNS-ID.

11.1.5:
You say “CAs SHALL review the proposed new gTLDs...” and then mandate behavior, but isn’t it possible that some of those proposed new gTLDs won’t get approved? I’d prefer if the mandate only applied to approved new gTLDs.

[Hill, Brad] Agreed.

“following the operationalization of a new gTLD” Can you confirm that ICANN will provide clear dates on when each new gTLD becomes operational?

[Hill, Brad] This seems to be still a moving target, though it is only moving later and later.  The plans described to date involve operationalizing in large batches, rather than one at a time, which should make this less onerous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120726/fe9a6600/attachment-0003.html>