[anonsec] comments on the BTNS core I-D
kent at bbn.com
Mon Jul 30 10:50:57 PDT 2007
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. ...").
> > >> 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
>> 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
> > 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
>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.
More information about the ANONSEC