Russ Housley wrote: > I would like to see an additional section in this document. When > otherName forms are registered, some of these will in include text > strings. However, they will probably not make use of GeneralName or > Name. Therefore, I think it would be useful to list the ASN.1 types > where these rules should be applied. UTF8String is obvious. What > else?
In my experience, many name forms have their own matching rules. For instance, DNS names are case-insensitive. RFC822Names use receiver-specific matching conventions in the localpart and case-insensitive matching for the domain.
I'd be reluctant to specify any rules for future name forms, but maybe we can come up with some guidelines. For instance, we could say that name forms that include Unicode strings (BMPString, UnicodeString, or UTF8String) SHOULD consider using a variant of the stringprep algorithm and MUST specify a clear, well-defined algorithm for name matching or prohibit the use of these name forms in name constraints.
P.S. Maybe this document should describe how to handle international characters when matching DNS names, URIs, and RFC 822 names in certificates (in name constraints). But I'd be inclined to specify these in separate documents, especially since internationalization of email addresses is not settled yet.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature