Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS)

[Adam Roach <[e-mail]>]

On 6/25/19 11:53 AM, Benjamin Kaduk wrote:
> On Tue, Jun 25, 2019 at 11:49:21AM -0500, Adam Roach wrote:
>> On 6/24/19 3:19 PM, Benjamin Kaduk wrote:
>>> On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote:
>>>> Alissa Cooper has entered the following ballot position for
>>>> draft-ietf-curdle-gss-keyex-sha2-09: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> "The IESG is considered to be the owner of all these key exchange
>>>>      methods; this does NOT imply that the IESG is considered to be the
>>>>      owner of the underlying GSS-API mechanism."
>>>>
>>>> I don't understand this text. What does it mean for the IESG to be the owner of a method?
>>> The IESG has change control for the SSH key exchange method; the IESG does
>>> not necessarily have change control for the underlying GSS-API mechanism.
>>
>> I'm confused. Your statement would imply that one of the following is false:
>>
>>   1. GSS-API is authoritatively defined by RFC 2743
>>   2. RFC 2743 is an IETF-stream document
>>   3. The IESG is responsible for change control of IETF-stream documents
>>
>> Which of these have I misunderstood?
> None of them :)
>
> "GSS-API mechanism" is a term of art for a cryptographic service provider,
> identified by OID, that implements the underlyin functionality of the
> GSS-API.  While the GSS-API framework is defined by RFC 2743, anyone that
> can allocate an OID can specify a GSS-API mechanism corresponding to that
> OID, and the IETF cannot try to assert change control over that
> cryptographic provider.
>
> Does that help?


Oh! Yes, that's much clearer, thanks. I hear you saying that there's a 
one-to-one correspondence. I think replacing "underlying" with 
"corresponding" might avoid similar confusion by others.

/a