> -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@xxxxxxx] > Sent: 29 August 2011 14:58 > To: Richards, Gareth > Cc: Black, David; hartmans-ietf@xxxxxxx; gen-art@xxxxxxxx; > ietf@xxxxxxxx; ietf-krb-wg@xxxxxxxxxxxxx; stephen.farrell@xxxxxxxxx > Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 > > >>>>> <gareth.richards@xxxxxxx> writes: > > >> > Why should we require that alg-ids be registered URIs? > >> > >> That's not my concern - the existing first paragraph of the IANA > >> considerations section in the draft requires IANA registration > >> (or at least tries to) by pointing to the PSKC registry. My > >> concern is that if this is going to be done, it needs to be done > >> right (duh!), and the current text is insufficient. Please take > >> the issue of whether to use IANA for this purpose up with Gareth > >> and the WG. > >> > >> > I have no problem with the IETF registering its algorithms > >> there, or us > encouraging people to register them there, but > >> it's a URI. What purpose > is served by forcing registration? > >> > >> Hmm - more than one URI for the same algorithm might cause > >> interoperability problems. > >> > > g>Some form of identifier will be required for the otp-algID in the PA- > OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about > when this was first discussed, it was agreed that it would make sense > to use the registry of identifiers already being established for PSKC > rather than produce a duplicate one. My assumption was that a registry > would be required to ensure that the URIs were unique. > > I don't really care so just fix the current text to resolve David's > concern. My point was simply that whatever spec tells you how to use > some algorithm with Kerberos can provide a unique URI and I'm > unconvinced that it matters where that URI is drawn so long as everyone > agrees on the URI. Having a registry for everything the IETF does is > fine; reusing an existing registry is better. Constraining what > non-IETF people do seems kind of silly but they will not listen to us > anyway, so no harm is done. How about the following text? I am not sure whether to make these SHOULDs rather than MUSTs to allow the option of other algorithm identifiers to be used. a) Section 4.1: otp-algID Use of this field is OPTIONAL, but MAY be used by the KDC to identify the algorithm to use when generating the OTP. URIs used in this section SHOULD be obtained from the PSKC algorithm registry [RFC6030]. b) Section 4.2 otp-algID This field MAY be used by the client to send the identifier of the OTP algorithm used, as reported by the OTP token. Use of this element is OPTIONAL but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value. URIs used in this section SHOULD be obtained from the PSKC algorithm registry [RFC6030]. c) Section 5 The OTP algorithm identifiers used as otp-algID values in the PA-OTP-CHALLENGE described in section 4.1 and the PA-OTP-REQUEST described in section 4.2 SHOULD be registered in the PSKC algorithm registry [RFC6030]. --Gareth _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf