Could we define a new section for the PSKC registry instead of a whole new registry? (Agree we don't need all this info.) On Aug 26, 2011, at 8:48 AM, Simon Josefsson wrote: > <gareth.richards@xxxxxxx> writes: > >> 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 think a separate registry is needed, RFC 6030 requires several things > from a profile that shouldn't be required in order to support Kerberos > OTP. See below. > > /Simon > > 12.4. PSKC Algorithm Profile Registry > > IANA has created a registry for PSKC algorithm profiles in accordance > with the principles set out in RFC 5226 [RFC5226]. > > As part of this registry, IANA maintains the following information: > > Common Name: The name by which the PSKC algorithm profile is > generally referred. > > Class: The type of PSKC algorithm profile registry entry being > created, such as encryption, Message Authentication Code (MAC), > One-Time Password (OTP), Digest. > > URI: The URI to be used to identify the profile. > > Identifier Definition: IANA will add a pointer to the specification > containing information about the PSKC algorithm profile > registration. > > Algorithm Definition: A reference to the stable document in which > the algorithm being used with the PSKC is defined. > > Registrant Contact: Contact information about the party submitting > the registration request. > > Deprecated: TRUE if this entry has been deprecated based on expert > approval and SHOULD not be used in any new implementations. > Otherwise, FALSE. > > PSKC Profiling: Information about PSKC XML elements and attributes > being used (or not) with this specific profile of PSKC. > > PSKC algorithm profile identifier registrations are to be subject to > Specification Required as per RFC 5226 [RFC5226]. Updates can be > provided based on expert approval only. Based on expert approval, it > is possible to mark entries as "deprecated". A designated expert > will be appointed by the IESG. > > IANA has added two initial values to the registry based on the > algorithm profiles described in Section 10. > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@xxxxxxxxxxxxx > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf