Subject: Re: RFC 2459 and internationalized domain names

From: [email-masked]
Date: Wed, 5 Jul 2000 10:49:38 -0400

Comments below.  Are we going to need to change over a third of the
extension OID's - and if so, should we try hard to avoid doing so?

          Tom Gindin

Jean-Marc Desperrier <[email-masked]> on 07/05/2000
05:40:40 AM

To:   [email-masked]
cc:
Subject:  Re: RFC 2459 and internationalized domain names

Paul Hoffman / IMC wrote:

> >My secondary comment is that PKIX really shouldn't be in the business of
> >specifying altName formats and semantics at all.  The definition of what
> >constitutes a valid email address, DNS name, IP address, and so forth,
has no
> >place in a PKIX RFC.  The same goes for name-matching rules: it's not up
to
> >PKIX to define these.  It's a loser's game, where PKIX will have to be
> >maintained indefinitely in order to keep up with the evolving Internet.
>
> Agree.

The current version of RFC2459 serves two purposes : defining the format of
the
certificate and defining some "best practices" for implementations of what
everyone must be able to support.
This best practices are needed, an ASN1 based format has just too many
possibilities.

[Tom Gindin] And somebody has to define the ASN.1 for each extension.  If
that doesn't belong in PKIX, why do we have an entire section on the use of
standard extensions?

> >If an Internet group wants to be compatible with PKIX, it should be up
to
> >them to define a PKIX sub-profile on what it means to conform to their
stuff.

And this would be a big problem because there would several different PKIX
sub-profiles.

If the standard of PKIX defines both the format and the best practices,
that means
it must be able to evolve easily to adapt to new practices.

Or there must be two separate documents for each of theses aspects.

Now if the RFC2459 wasn't so strict about the email format, url format,
etc...
this would be a good thing.

[Tom Gindin] Agreed.

The format of GeneralName is :
GeneralName ::= CHOICE {
        otherName                   [0] INSTANCE OF OTHER-NAME,
        rfc822Name                  [1] IA5String,
        dNSName                     [2] IA5String,
        x400Address                 [3] ORAddress,
        directoryName               [4] Name,
        ediPartyName                [5] EDIPartyName,
        uniformResourceIdentifier   [6] IA5String,
        iPAddress                   [7] OCTET STRING,
        registeredID                [8] OBJECT IDENTIFIER }

As these are implicits tags, this  is closed to evolutions in the format of
the
data, it is not possible to modify the standard to allow rfc822Name to be a
CHOICE
between UTF8strings, and IA5String, as could be done with explicit tags. It
seems
we need to create something like :
        rfcSonOf822Name                  [9] UTF8strings,

[Tom Gindin] I think it's rfc822I18N [9] UTF8String, but that's minor.

The same applies to dNSName, and uniformResourceIdentifier.

[Tom Gindin] I have one basic question here.  Does adding new members to
this choice mean we have to change OID's for the extensions using it (not
just SubjectAltName, but IssuerAltName, AuthorityKeyIdentifier,
NameConstraints, CRLDistributionPoint, CertificateIssuer,
IssuingDistributionPoint and AuthorityInfoAccess in RFC 2459 alone - and I
might have missed one)?  If it does, should we and X.509 bite that
particular bullet or define OTHER-NAME's as DirectoryString's instead?

It seems to me using a CHOICE format similar to DirectoryString for
rfc822Name,
dNSName, uniformResourceIdentifier, and a recommendation to use IA5String
in the
current state of things would have been a better solution.

[Tom Gindin] It might well have been better (using AugmentedDirectoryString
as a CHOICE between DirectoryString and IA5String, or
InternetDirectoryString as a CHOICE between IA5String and the three Unicode
string types), but it's probably too late.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 05 Jul 2000 18:17:49 +0200

> ...

> It seems

> particular bullet or define OTHER-NAME's as DirectoryString's instead?

OK, OTHER-NAME is the way to go.

It is clearly a lot better to define a specific OID for rfc822I18N and then
insert that kind of thing as an otherName element, and *not* to change the
syntax of GeneralName.

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

The only thing that is needed is to define that "value" is of type UTF8String
or InternetDirectoryString when "type-id" is rfc822I18N,

OtherName might be anything, it's defined by the OID used.

Also a dNSNameI18N, and uniformResourceIdentifierI18N OID would be needed.

> string types), but it's probably too late.

It's too late, but I think the moral is that the standard should always leave
some room for the type of strings elements to evolve in the future.