Re: [IETF-PKIX] Subject/Issuer Name Population

[John_Wray@xxxxxxxx]

---------------------- Forwarded by John Wray/Iris on 04/23/98 09:17 AM
---------------------------


John Wray
04/22/98 10:43 AM

To:   "IETF X.509-based public key infrastructure mailing list"
      <IETF-PKIX@LISTS.TANDEM.COM>
cc:
Subject:  Re: [IETF-PKIX] Subject/Issuer Name Population  (Document link
      not converted)

Tim Polk <wpolk@nist.gov> on 04/17/98 10:42:00 AM,  wrote:

>I have attached proposed text for the issuer and subject name sections.
>
>Highlights:
>
>(1) issuer name is required (that is, may not be an empty SEQUENCE).
>(2) subject name is required for CA certs.  (This means you never chain
off
>altnames!)
>(3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
>comparison of attribute values is permitted for everything except
>PrintableString. That is, no white space compression or case conversion in
>BMP or UTF8.
>
>(Rationale for PrintableString:  It has already been implemented, and is
>used in practically all certificates.  Upper and lowercase country codes,
>etc. will break if we don't support it.)

(1) and (2) above are fine.  However, the proposed text for (3) has
several problems.

Restatement of the proposal:

   A DirectoryString is now permitted to be a choice of printableString,
   teletexString, universalString, utf8String and bmpString, and PKIX
   implementations have to be able to understand certificates whose
   names use any of these syntaxes.   When generating certificates,
   use printableString if the string to be encoded fits in the
   printableString character-set, otherwise use bmpString if the
   string fits in the bmpString charset, otherwise use utf8String.

   Also, instead of X.520 matching rules (which depend on the attribute
   type, not the string syntax chosen, although for almost all reasonable
   attributes they turn out to be caseIgnoreString), define new matching
   rules based on the string syntax, such that attribute values encoded
   using printableString shall use caseIgnoreString matching rules, whereas
   attribute values using any other string syntax shall use binary
   matching.
   Attribute values that use different string syntaxes shall never match,
   regardless of their contents.

I have several issues with this.

i)  This may invalidate certificates that are currently deployed.
Since printableString is such a limited character set (a..z,
A..Z, 0..9 plus a few punctuation characters, not including
"@", "!" or "_"), many deployed certificates will currently
use either teletexString or universalString, but since X.520
matching rules are supposed to be in effect, there is no
reason to suppose that equivalent names in existing
certificates will match under a binary comparison.  This
will be even worse if we decide to throw out strings that would
otherwise match, simply because two CAs chose to use different
stringSyntaxes for encoding a given name.  I know of at least
one CA implementation that, if a name won't fit into the
printableString character-set, goes straight to universalString.
Certificates issued by this implementation will not be useful
in a PKIX infrastructure if the proposed text is adopted (or at
least, such certificates cannot appear in the same certificate
chain as PKIX-compliant certificates).

ii)  The preferred ordering of printableString, bmpString and
utf8String is problematic.  Since almost anything that might
ever appear in a name attribute is going to reside within the
BMP character-set, utf8String will hardly ever be used, so this
really comes down to a choice between printableString and
bmpString; utf8String will never actually be used if this
ordering is used.  This is a pity, since utf8String is
actually a very implementation-friendly codeset, in that
it's identical to 7-bit ASCII for characters that can be
represented in 7-bit ASCII, it doesn't use embedded null
octets, so code can use regular null-terminated C-strings to
store and manipulate it, it is designed so that it won't
break 8-bit clean code that scans for 7-bit ASCII values,
and it's efficient in terms of the number of octets used
to encode a given string.  It is also the standard codeset
for communicating between Java and other languages via the
Java native method interface.  Instead of this codeset, any
string that falls outside the printableString character-set
will be forced by this recommendation to use the 16-bit
bmpString codeset, with all the overhead (and potential
for byte-order bugs) that implies.

iii) If the restriction that attribute values have to use
the same syntax in order to be compared were to be dropped,
the only implication for PKIX implementations would be that
they would have to be able to convert from one string syntax
to another during chain processing.  However, this ability is
already required of a PKIX CA, by the requirement that a PKIX
implementation must choose the most restrictive syntax
that can represent a given attribute, so it's not an
great additional burden to put it in the chain processing
code as well (particularly as it's trivial to do for all the
allowed codesets except for the deprecated teletexString).
However, if an implementation _does_ have the ability to
convert between syntaxes, the rationale for using the most
restrictive syntax really goes away (since if the
implementation can convert, it shouldn't matter what syntax
a name is actually encoded with inside a certificate).
Given this, the PKIX profile should go for simplicity
(which to me as an implementor means removing choice wherever
possible), and simply specify the use of utf8String for all
names.  For the printableString character-set, the encoding
of a utf8String value is identical to the same value encoded
as a printableString - the only effect of using printableString
vs. utf8String is that they have different tags in the BER,
so there's no overhead in terms of code complexity or string
storage size.  The only effect would be to get rid of the
requirement on the implementation to dynamically pick a
preferred code-set by scanning the string;  instead it can
always use utf8.

iv) The specification of binary matching for all codesets
other than printable string doesn't really seem to buy
that much.  Consider an end-system E1, wishing to initiate a
secure communication with another end-system E2.  Assume that
the end-system retrieves certificates from a directory.
To initiate the connection, E1 will want to retrieve E2's
certificate.  Presumably, E2's name will have been provided
to E1 by a user, and it is unlikely that the user will know
the exact capitalization and spacing that E2's CA used when
binding E2's name into its certificate.  Instead, E1 will
likely take whatever name is provided, and use that to do
an directory retrieval.  The directory (which can be assumed
to understand X.520 matching rules) will return E2's
certificate, but before E1 can use the certificate it must
ensure that the subject name in the certificate actually
corresponds to E2 (since the directory isn't trusted).
So E1 has to be able to perform an X.520-style comparison
here, even if we specify binary matching in the certificate
chain processing.  So we haven't actually saved any code by
using binary matching - all we've done is to cause a PKIX
implementation to appear overly fussy about capitalization
and spacing.



In summary, now that the arcane teletexString syntax has
been deprecated, and we have utf8 as a compact universal
codeset that also happens to be ASCII-friendly, much of
the complexity of name comparisons has already been
eliminated.  The proposed PKIX restrictions on syntaxes
and comparisons don't simplify the implemention (and
in some cases they add complexity), while in almost all
cases they reduce functionality.




John