this is only peripherally related to PEM, and the IETF...
I supply it for interest as problems recently discussed are manifest in
other mixed and commercially-operational security and messaging theatres.
The encoding rules for encoding or "presenting" ASN.1 Certificate
values when conforming to the ISO 9735 EDIFACT standard - the
international EDI application of messaging - are given in the
"UN/EDIFACT Security implementation Guidelines." Given the nature of
the EDIFACT syntax level definitions used to constrain multilateral and
open interchange communication, the character sets used for encoding
and transmission of the Certificate value are limited to a subset of
ISO 646. Basically, limitations are imposed to ensure Telex
compatibility, with the limitations being imposed to ensure that this
telematic medium may continue to be used as a basis for electronic
messaging in both first and third world, and to ensure that when syntax
level A is used, the international telex service (which restricts some
more characters) can be guaranteed as a basis of end-to-end messaging
capable of guaranteeing no info loss, and thus supporting
non-repuduiation security services.
There are 75 million telex machines in the world, rather more than the
number of Internet users! And they do not make use of the "@" (at)
character. And neither do the one or two EDI translators used in the
VAN-based messaging world. Restriction of the strings types to Printable
Strings to communicate name forms is sensible.
All compliant RFC 822 message handlers are required to handle the 'user
at domain' syntax for addressing (naming if you are Internet type)
mailboxes, where "at" is a word serving the same purpose as "@" (at). So,
its not hard to just avoid the character, and continue to use the 1988
Certificate definition to convey a Name whose one and only attribute
(distinguished or not depending on the CA and Naming Authority) has an
associated attribute syntax of Printable String whose content is a RFC
822 mailbox string. For example
"williams at atlas.arc.nasa.gov" , or even
"/S=williams/OU=Sterling/O=ARC/PRMD=NASA/ADMD=TELEMAIL/C=US/ at
sprint.com" for EDI mailboxes needing organizational addressing and
routing.
Any decent Internet UA tool can already reform these basic name/address
syntaxes and make them presentable for users at the UI. This include
substitution of "at" as '@' (at) on terminals capable of such display. Even
sendmail can transform the repugnant
"/S=williams/OU=Sterling/O=ARC/PRMD=NASA/ADMD=TELEMAIL/C=US/" used
by many messaging computers into
"williams(_at_)Sterling(_dot_)arc(_dot_)nasa(_dot_)gov"
demanded by users. So there is really no excuse. (And neither are any
particular providers shown upon UI indication of an authenticated
identity.)
(The EDIFACT syntax allows a number of registered name forms. Should one
of these be suggested as the RFC 822 'user(_at_)domain' form of
identification (in a manner as suggested for RFC 1422 by Warwick), then
this standard too will have the same problem as all other standards
which base their design on deployed equipment capabilities.) The
correct way in specification to convey the constraints to indeed
to type the string suitable. In this case, it is Printable String.
I do find it strange that Internet WWW culture accepts such as
"URL: gopher://naic.nasa.gov:70/00/Notice";
as acceptable to users as a resource reference string,
but the Internet-types will no doubt scream at the equally machine-oriented
"To: /S=williams/OU=Sterling/O=ARC/PRMD=NASA/ADMD=TELEMAIL/C=US/ at sprint.com"
or
"To: /S=williams/OU=Sterling/O=ARC/PRMD=NASA/ at arc.nasa.gov"
Peter.