I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-kitten-gssapi-channel-bindings-06.txt
Reviewer: Brian Carpenter
Review Date: 2009-04-05
IESG Telechat date: 2009-04-09
Summary: Almost ready; needs one clarification.
Comments:
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@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
