Re: [Spasm] Spasm Digest, Vol 14, Issue 6

[Viktor Dukhovni <[e-mail]>]

> On May 9, 2017, at 3:38 AM, [e-mail] wrote:
> 
> Are you ready to link openssl with punycode decoder or implement the necessary functions in it?

Thanks for your post.

Yes, a punycode decoder does not require external libraries, we can just import a
compact punycode decoder (for one-way A-label to U-label conversion) implementation
directly into OpenSSL without introducing a dependency on any external libraries.
This requires no Unicode property tables, just some math that can be added to
libcrypto.


> Doesn't the Option 2 fit better? In that case the punycode decoder is linked with applications 
> where we need it for visualization purpose, not with the library itself.

If option 2 is to always encode domains in A-label form, even in SMTPUtf8Name
SAN elements, then that's fine too.  We might then ask users to prepare the
email address for verification in that form, and indeed avoid all conversions
in the X.509 verification stack, leaving just the job of preparing the
"reference identifier" as:

	[e-mail].a-labels

which is then compared against rfc822Name SANs or SMTPUtf8Name SANs depending
on the localpart.  So that's equally (or perhaps slightly more) acceptable for me.

This leaves the application in the driver's seat with respect to any "mappings"
that might or might not be relevant to the original U-labels in the reference
identifier.

The reason my previous post suggested U-labels in the domain parts of SMTPUtf8Name
SANs, was that it is acceptable to em, and I did not expect much support for A-labels
in that context.  Perhaps I misjudged the likely rough consensus, and perhaps others
too would have preferred consistency across encodings of domains in name constraints
and SANs over "unicode purity" in the SMTPUtf8Name SAN, but might also be too shy to
say so.

Bottom line, I can deal with either choice, but personally prefer consistency of
the representation of domains.  That is, use DNS wire-form of the domainpart in
rfc822Name constraints, rfc822Name SANs and SMTPUtf8Name SANs.

-- 
	Viktor.