Subject: sample IANA considerations for Kerberos crypto draft

From: Ken Raeburn <[email-masked]>
Date: Wed, 6 Aug 2003 22:59:15 -0400

As I said in earlier mail to the group, Russ wants a stated policy for 
encryption and checksum type numbers, and if we're formalizing that, I 
think there's little point in keeping the registry somewhere other than 
IANA.  (At least, my impression was the reasons people had were 
somewhere between "we don't want to have to think about the policy" and 
"we want to own it, it's all ours, Ours, OURS HAHAHAHAHAha er, um".  
But we didn't discuss it much besides deciding to be lame.)

Unless we want to say, "Joe Smith is the keeper of the numbers, and you 
get a number if he says it's okay", that is.  (Where Joe Smith would 
probably be me, Cliff, or the working group as a body.)  But since in 
the long run IANA should be the keeper of the registries, and we don't 
plan to do another revision of the crypto framework, we might as well 
transfer the control from me (as editor of the crypto draft) to IANA 
now.

After talking with Sam Hartman, Jeff Altman and others, I've come up 
with a sample policy and text, based mostly on a recommendation of Jeff 
Altman's.  Partly this is another attempt to get discussion going.  If 
the WG thinks it's a good idea, and the ADs don't mind us revising it 
in this way after we've handed them a version for approval, I'll write 
up a revised draft with this text (minus the "Question" paragraphs) 
and... what, send it to Russ?  Submit an -06 draft for publication and 
have Doug gather feedback and send it to the IESG?  How should this 
work, procedurally?  This isn't some minor editorial change, and I've 
never published an RFC before.

If this is too big a change, maybe we should just decide who "Joe 
Smith" is going to be, and send in another RFC later when we want IANA 
to take over.

x. IANA Considerations

Two registries for numeric values should be created: Kerberos 
Encryption Type Numbers and Kerberos Checksum Type Numbers.  These are 
signed 32-bit values in twos-complement form.  Positive values up to 
2**31-1 inclusive should be assigned only for algorithms specified in 
accordance with this specification for use with Kerberos or related 
protocols.  Negative values through -2**31 are for private use; local 
and experimental algorithms should use these values.  Zero is reserved 
and may not be assigned.

Positive encryption and checksum type numbers may be assigned following 
either of two policies described in [BCP26].

Standards-track specifications may be assigned values under the 
Standards Action policy.

Specifications in Informational RFCs may be assigned values after 
Expert Review.  A non-IETF specification may be assigned values by 
publishing an Informational or standards-track RFC referencing the 
external specification; that specification must be public and published 
in some permanent record much like the IETF RFCs.  It is highly 
desirable, though not required, that the full specification be 
published as an IETF RFC.

[Question: Do we want weasel wording to allow for a government 
classified mechanism but still prohibit registered assignments for 
vendors who just don't want interoperability?]

Smaller encryption type values, which encode to smaller octet strings 
under ASN.1, should be used for IETF standards-track mechanisms, and 
much higher values (hex 0x1000000 and above) for other mechanisms.  No 
other guidance into allocation order is given.

Draft IETF specifications should not include values for encryption and 
checksum type numbers.  Instead, they should indicate that values would 
be assigned by IANA when the document is approved as an RFC.  For 
development and interoperability testing, values in the private-use 
range (negative values) may be used, but should not be included in the 
draft specification.

Each registered value should have an associated unique name to refer to 
it by.  The lists given in section Y should be used as an initial 
registry; they include reservations for specifications in progress in 
parallel with this document, and for certain other values believed to 
be in use already.

[Question: Should the tables be moved to this section?]

For the AES draft:

x.  IANA Considerations

The Kerberos encryption and checksum type values used in section Y were 
previously reserved in [KCRYPTO] for the mechanisms defined in this 
document.  The registries should be updated to list this document as 
the reference.

Please send comments....

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 07 Aug 2003 09:45:04 -0500

> never published an RFC before.

Since it is in the hands of the IESG, I would ask Russ. I don't think
it needs a WG last call as it does not change the substance of the 
draft, but should get a WG concenses. 
 
> vendors who just don't want interoperability?]

I would say no, as they could use the private numbers.

> [Question: Should the tables be moved to this section?]

I would say no, to keep the changes to the draft as short as possible.

> document.  The registries should be updated to list this document as

Personally, it looks good to me. and if there are no real comments,
we can call for WG consensus.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Aug 2003 09:11:11 -0700

> Smith" is going to be, and send in another RFC later when we want IANA 

I have no objection to the proposed text.  I am neutral as to whether
this should be added to the kcrypto I-D without another WG Last Call or
whether this text should be in a separate I-D - I have no objection to
either approach, but if a separate draft be used for the IANA
assignments then IMO such a draft should be published, last called
and moved to publication ASAP.

[...]
> vendors who just don't want interoperability?]

This can always be addressed, if and when the issue comes up, in a
separate RFC creating an exemption to the rules.  If there's no
requester for such exemptions now I see no point in including such
"weasel wording" now.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Aug 2003 17:50:02 -0400

I have not reviewed the text and will not do so before I return from
vacation next Monday.

I don't think this needs a last call no matter what.  It does need WG
review, but for individual changes, especially changes suggested by
the IESG or during an IETF last call, asking for review/objections
from the WG seems sufficient.

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 18 Aug 2003 16:01:46 -0400

Doug, my impression is that the policy and text I proposed (minus the
bracketed questions, and with the section numbers filled in) are
generally acceptable to the working group.  If you agree, I'll update
my copies of the drafts, fill in the section numbers, etc.

Russ, do you want fresh copies of the drafts with the updated IANA
Considerations using real section numbers?

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 19 Aug 2003 14:01:53 -0500

> my copies of the drafts, fill in the section numbers, etc.

Yes I agree. 

--