[anonsec] comments on the BTNS core I-D

[Stephen Kent]

At 12:15 PM -0500 7/30/07, Nicolas Williams wrote:
>On Mon, Jul 30, 2007 at 12:27:44PM -0400, Stephen Kent wrote:
>>  At 10:47 AM -0500 7/30/07, Nicolas Williams wrote:
>>  >...
>>  >
>>  >It was misspelled, and no word is missing ("because <adjective>" is a
>>  >legitimate English language idiom, as in "Joe was lazy because
>>  >spoiled").  It is an odd idiom, but one that I'm fond of.
>>
>>  For standards documents we tend to look for somewhat more formal writing
>>  :-).
>
>Sure, but show me that this is not formal (it's harder than you think).

Do you even have a copy of "Strunk and White" on your bookshelf?

>Or did you mean that we want to use a subset of English likely to be
>understood by most readers, including those for whom English is not a
>first language?  :)  Such an argument wins me over more easily :)

That's a good argument too, and if that's the one that will cause 
this text to be changed, I'll buy into it :-).

>OK, we can change that to a singular ("A node wishing to be treated as a
>BTNS node MUST include a bare RSA key CERT payload.  ...").

great.

>  > >> A final question re this text: why allow sending additional certs?
>>  >
>>  >Because it would allow a node to do better than BTNS with some peer if
>>  >that peer could authenticate it; the node need not know a priori that
>>  >its peer can do so.  RFC4306 doesn't seem to disallow multiple CERT
>>  >payloads, but the structure of the protocol is such that only one AUTH
>>  >payload makes sense, thus all CERT payloads should use the same public
>>  >key.
>>
>>  yes, and it would be appropriate to not that here.
>
>Er, "to not that here"?  Did you mean "to do that here"?

no, I meant to "note that here." Just a single letter typo :-).

>...
>
>Yes, there can be.  Such an entry could be made as a result of
>connection latching (using the automatic IPsec policy editing scheme) or
>some leap of faith-ish schemes (not yet defined).

Then perhaps the text should define a BTNS entry more clearly, near 
the beginning, and discuss the "catch-all" BTNS entry as a special 
case.

>  > we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY
>>  ID type, then syntactically this would allow other than catch-all
>>  BTNS entries.
>
>I'll make sure that we distinguish between the BTNS wildcard PAD entry
>and others.

great.

>For example, the second bullet in section 2 needs a "wildcard" qualifier
>to be sprinkled here and there, and another bullet item needs to be
>added describing non-wildcard BTNS PAD entries (each such entry must
>match a single public key, either by value or by fingerprint).
>
>Thanks for catching this.

You're welcome.

Steve