4 ms·
Oh I don't think Daniel was asking why we're doing i18n. My remark was not at him, at all. I was just pre-empting a possible made up objection. He's in fact cor
by FiloSottile 4y ago
Oh I don't think Daniel was asking why we're doing i18n. My remark was not at him, at all. I was just pre-empting a possible made up objection. He's in fact correct to wonder why punycode decoding ended up in OpenSSL, as the rest of that section explores. The point being that OpenSSL could do its job and still support i18n domains and emails without having to ever decode punycode if only the spec had made different tradeoffs.
- AceJohnny2 4y agoah. Thanks for the clarification!
- tialaramex 4y agoExactly this. I had the very image of this discussion with Python folks for DNSname SANs back when Python was learning not to just rely on CN. Python folks felt like the correct thing was: 1) Implement a Punycode decoder. 2) Decode hostnames and certificate information to get Unicode 3) Compare the Unicode Strings. They were fretting about how complicated it would be to arrange all this, the months of work needed and the need to bring in teams who understood about i18n issues... And I was like No, don't do any of that, take the bytes and compare the bytes. If the bytes aren't identical that's not a match, you are done. It seemed to take a while for it to sink in that this is correct and simpler and thus better.
- cryptonector 4y agoYes, it should be possible to compare labels for equality octet-wise. There should be no normalization considerations in this case because every A-label in a certificate should already be normalized.