Re: PKITS test case 4.13.38 vs RFC 3280

[Sam Roberts <sroberts@certicom.com>]

Wrote Nelson Bolyard <misterssl@aol.com>, on Wed, Jan 21, 2004 at 06:43:36PM -0500:
> Tim, given the existing text of RFC 3280, and reading it strictly, a 
> constraint string of "test.com" would match "my.test.com" and "mytest.com", 
> and a constraint string of ".test.com" would match "my.test.com" but not 
> "mytest.com".  The RFC does not prohibit the constraint from starting with
> a dot.  Hence, it seems that the existing rules already suffice for 
> constraints to disallow a case like "mytest.com".

The RFC says:

	Any DNS name that can be constructed by simply adding to the left hand
	side of the name satisfies the name constraint.

I does not go on to define "adding". How does one perform the addition
operation with a "DNS name"? Reading this strictly, it is
unimplementable without this definition.

You took the view that "DNS name addition" is "string concatenation",
but it doesn't say that.

> If you change the RFC now, you may break working implementations.
> 
> If you do correct the RFC, the rules for this constraint need to be MUCH 
> more exactly spelled out.  If (as I expect you will say) the constraint
> string MUST NOT begin with a dot, then the RFC MUST say so.  

I would agree.

> What about "my..test.com"?  Does it match a constraint of "test.com"? 

Is "my..test.com" a DNS name?

> The RFC should make this all unambiguous and clear.  

Defining what "adding to the left hand side of the name" means would be
a good think, and describing it as adding domains components, as
intended, wouldn't break anything - it would deine something previously
left vague.

For what its worth, I took DNS name addition to be the addition of
domain components, not random substrings.

Cheers,
Sam

-- 
Sam Roberts <sroberts@certicom.com>