Subject: One More Straw Poll - msg#00197

Folks,

Steve Kent revisited the area of name constraints in some email earlier this week. In the interest of quick resolution, I have developed alternative text and am requesting a straw poll to determine which text to use. Please email by 8AM eastern time Friday morning! Once again, sorry about the timeframe - can't be helped.

Hopefully the two alternatives will represent the differing views adequately...

To quote Steve's message:

>I do have some issues about the name constraints extension in with
>regard to URIs and DNS names. (I think we fixed this for RFC822 names,
>right?) Specifically, these constraints don't seem to match the semantics
>of this extension. The permitted use of a "star name" at other than the
>end of a name means that these constraints do not always define subtrees.
>There is no need for a star name construct when one is defining a subtree
>for a tree structured name space. So, I'd like to see us redfine the
>constraint syntax for these two name types so that they conform to what we
>are using for all the others. We had a similar discussion a while ago with
>regard to the syntax for these names, and RFC822 names, and agreed not to
>put in asterisks as a means of expressing a name range, which would violate
>the semantics of a a cert as identifying one, explicitly-named entity.
>

Basically, the current name constraints text expands the semantics for URIs and DNS names. The text permits definition of a name constraint that is *not* a subtree. (Of course, it also permits definition of a name constraints that are subtrees.)

The problem comes from wildcards in the middle of names. For example, www*.foo.bar.com isn't a proper subtree. However, *.foo.bar.com is a proper subtree. I think the former construct is of limited utility, but I can come up with scenarios where it is useful.

For example, assume NIST has a CA called "routerCA" that issues certificates to all its routers, but should not issue other certificates. Assume a naming convention - router.[x].nist.gov is the router for subnet [x].nist.gov. Another CA might wish to impose the name constraint "router.*.nist.gov" when issuing a CA certificate to the subject "routerCA". The same general problem arises if a CA is only trusted to issue certificates to web servers (hence the www*.foo.bar.com example.)

There is a related problem as well - www*.foo.bar.com is a legal DNS name. In general, you won't encounter such a host, so we forged ahead with the asterisk as the wildcard as a pragmatic solution. This problem can be resolved if we eliminate interior wildcards.

Choice A presents the current text. That text is excerpted from section 4.2.1.11. Choice B presents text that would resolve these two issues, but would slightly diminsh the functionality.

Choice A:

For URIs, the constraint applies to the host part of the name. Examples would be foo.bar.com; www*.bar.com; and *.xyz.com. When a wildcard appears as the leftmost subdomain, it may be matched with one or more subdomains. That is, the constraint "*.xyz.com" is satisfied by both abc.xyz.com and abc.def.xyz.com. However, the constraint "*.xyz.com" is not satisfied by "xyz.com". Otherwise, the wildcard may only be expanded within a single subdomain. That is, www*.bar.com is satisfied by www1.bar.com but not www.foo.bar.com.

To indicate all Internet mail addresses on a particular host, the "*" character is used. For example, "*@xyz.com" indicates all mail addresses at the host "xyz.com". Note that although "*" is a valid character in Internet mail addresses, it is very rarely used on the Internet, and thus is appropriated by this specification for the email wildcard.

Internet mail addresses may also be constrained by the host part of the name, as with URIs. For example, "root@*.xyz.com" indicates all the Internet mail addresses root in the domain "xyz.com". As above, "*" is a valid character in the host part of the name, but it is very rarely used on the Internet, and thus is appropriated by this specification for the mail address wildcard.

Choice B:

For URIs, the constraint applies to the host part of the name. The constraint may specify a particular host or a domain. Examples would be "foo.bar.com"; and ".xyz.com". When the leftmost subdomain is unspecified (that is, the constraint begins with a period), it may be matched with one or more subdomains. That is, the constraint ".xyz.com" is satisfied by both abc.xyz.com and abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied by "xyz.com". Only the leftmost subdomain may be left unspecfied.

A name constraint for Internat mail addresses may specify a particular mailbox, or apply to all addresses at a particular host. To indicate all Internet mail addresses on a particular host, the account name is omitted, and the name constraint begins with the "@" character. For example, "@xyz.com" is satisfied by any mail address at the host "xyz.com". To specify a particular address on a host, the name is simply specified. For example, "root@xxxxxxx" is satisfied only by the mailbox root at the host "xyz.com".

Internet mail addresses may also be constrained by the host part of the name, as with URIs. For example, "@.xyz.com" indicates all the Internet mail addresses root in the domain "xyz.com". "root@.xyz.com" indicates all the root mailboxes on hosts in the domain "xyz.com".
Finally, "root@xxxxxxx" indicates the root mailbox on the host "xyz.com".


--- Voting ----

As with the previous straw poll, please send email with one of the following subject lines to ietf-pkix@xxxxxxxx

Choice A: permit wildcards inside names

Choice B: require proper subtrees

As before leave the message body empty. I'm counting them, not reading them.