Gen-ART review of draft-ietf-kitten-gssapi-channel-bindings-06.txt
Brian E Carpenter <brian.e.carpenter <at> gmail.com>
2009-04-04 22:30:21 GMT
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Reviewer: Brian Carpenter
Review Date: 2009-04-05
IESG Telechat date: 2009-04-09
Summary: Almost ready; needs one clarification.
I was expecting the sentence quoted below to be updated
following Nico's comments on my Last Call comment. I think the new
text would be
Where the language binding of the GSS-API model's channel bindings is as
single OCTET STRINGs (or the language's equivalent), then the implementation
SHOULD assume that the given bindings correspond only to the
application-data field of GSS-CHANNEL-BINDINGS as shown above.
On 2008-11-03 21:47, Nicolas Williams wrote:
> On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote:
>> I can't parse this sentence:
>> Where a language binding of the GSS-API models channel bindings as
>> OCTET STRINGs (or the language's equivalent), then the implementation
>> MUST assume that the given bindings correspond only to the
>> application-data field of GSS-CHANNEL-BINDINGS as shown above, rather
>> than some encoding of GSS-CHANNEL-BINDINGS.
>> 1. Is the 'as' supposed to mean 'only as'?
> More like "as a single OCTET STRING".
>> 2. Why is this restricted to the application-data field? Why doesn't
>> it also cover the various address fields? (OK, there's a clue hidden
>> in the Security Considerations, but the explanation belongs here.)
> Because RFC2743 said "OCTET STRING" and later RFC2744 imposed structure
> without specifying an encoding of that structure to an OCTET STRING.
> That's an old screwup.
> Now, if anyone had built a language binding based strictly on RFC2743
> then they'd have only an OCTET STRING input. What to do? Well, since
> those "network addresses" in the RFC2744 channel binding structure
> turned out to be utterly useless[*] and since such a language binding
> would not have intended for network-addresses-as-channel-bindings, the
> simplest choice is as given above.
>> 3. Maybe I'm lacking context, but the 'rather than' clause doesn't make
>> sense to me at all.
> I think it can be removed. Also, I suppose the MUST should be a SHOULD.
Gen-art mailing list
Gen-art <at> ietf.org