Subject: IANA considerations for Kerberos crypto specification

From: Ken Raeburn <[email-masked]>
Date: Sat, 2 Aug 2003 16:57:09 -0400

Russ has asked for an explanation of how registration of new 
cryptosystem numbers is supposed to work, which hasn't been specified 
in the crypto draft thus far.  I've been thinking it over, and talking 
it over with my co-authors.

First of all, not having the encryption and checksum type numbers 
listed with IANA seems pointless.  If they don't keep the registry, 
someone else has to, and a process still needs to be specified.

BCP 26 (RFC 2434) lists several straightforward "example" procedures 
for updating a registry, clearly specifying what criteria IANA should 
use when a new registration is requested.  We aren't required to use 
one of these, but if we don't, the policy should be comparably simple 
and precise.  Some registries use different policies for different 
ranges of values, for example, all names "x-*" might be Private Use 
while non "x-" names are registered under the Expert Review process.  
We already specify in the draft that negative values are for private 
use, and that zero is invalid.  That just leaves the question of how to 
allocate the positive numbers 1 through 2**31-1 that aren't already 
assigned or reserved.  They're a finite resource, but we have a lot.  
Unless some structure is imposed, or we allow someone to register huge 
blocks of numbers, we don't need to worry about running out.  More 
interesting, perhaps, is the desire to have adequate specifications 
available to the public.

In exchanging email and talking with Sam, Tom, Jeff and Jeff, it seems 
clear we don't have a single clear preference, though several options 
are close to what we want.  Mostly, we seem to be leaning towards one 
of:

* Expert Review, with advice to the reviewer that the specification 
should be required to be public if at all possible (i.e., *maybe* an 
exception could be made for government classified encryption systems, 
but then again, they could just use the Private Use range).  The review 
would concern the quality of the specification, not the quality of the 
cryptosystem defined.  The Designated Expert is appointed by the 
Security ADs, and decisions are subject to IETF appeal procedures.

* IETF Consensus, which requires an RFC going through IESG approval.  
"Typically, the IESG will seek input on prospective assignments from 
appropriate persons (e.g., a relevant Working Group if one exists)."  
(RFC 2434)  It doesn't have to be standards track, or necessarily a 
working group document, but it does need to go through the whole 
process.

* Specification Required, which specification doesn't need to be an 
RFC, but does need to be public and detailed enough for 
interoperability, though it's unclear who decides if a document 
actually qualifies.

We could also use a combination approach, something like "policy A is 
preferred, or use policy B if policy A isn't appropriate", but we 
should be able to express under just what sort of circumstances the 
secondary policy might be appropriate.

None of us have been especially excited about the First Come First 
Served policy, precisely because it doesn't require a public 
specification or any sort of review.

I guess the important issues come down to:
* Must there be a public spec?
* Must the spec be an RFC?
* For an RFC, do we want full IETF review (i.e., Last Call), or a 
Designated Expert?
* If no RFC, review by an Expert, or just accept any published spec?

Any comments?  Should we just pick one?

Then there's the question of assigning values when the usage doesn't 
conform to the crypto framework.  The encryption values reserved for 
PKINIT fall into this category.  Do we want to allow any more of that 
sort?  My feeling is no, but others may disagree.

Who chooses the values for a new specification?  IANA, or the 
Designated Expert, or the submitter of the specification?  My 
preference would be to recommend that it be IANA or the Designated 
Expert, and that we suggest that draft authors specify "this value will 
be specified by IANA" and not specify a value.  But this shouldn't be 
an absolute requirement, because we've got documents in the works (AES, 
RC4) that document schemes already deployed, so the authors should be 
able to request specific values when necessary; we just shouldn't 
encourage that approach.  Tom has suggested that we should keep the 
smaller values, which encode to shorter octet strings under ASN.1, for 
standards track schemes, and assign much larger values to experimental 
schemes.

Once the decision is made, the details still need to be written up for 
a revised draft.  I'll send out text when I've got it ready.

Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sun, 03 Aug 2003 12:55:57 -0400

If you require a published spec for IANA to assign a number, one of
two things is going to happen:

1) People will be more inclined to publish specs.

2) People will pick values independently of the IANA process and hope
they don't conflict.

People also have this habit of implementing things before the
internet-drafts find their way to the RFC stage (AES and RC4 for
Kerberos; the entire sshv2 protocol; probably other things that I'm
not paying any attention to).  What you may be encouraging is that
people initially deploy their schemes with the Private Use range, and
then switch to using a new enctype a year later when the RFC finally
comes out, along with an implementation note suggesting that everyone
support either enctype value in order to maximize interoperability, or
something.

It would be nice if we could have a process by which you could get a
number from IANA but you'd be required to eventually publish a quality
spec, but I'm not sure how enforcable that would be.  Maybe we could
say that you can't get new numbers in the future if you got numbers
more than a year ago for which you haven't published the spec, but
then maybe people will just request a dozen numbers now to cover all
of their future needs.  Or maybe having a spec that looks mostly
reasonable, but that hasn't necessarily finished going through the
IETF process, could be the requirement for getting a number from IANA.

Maybe requiring an internet-draft to have been available for a month,
and a consensus from the working group as to whether the authors of
that internet-draft were making a good faith effort to produce a clear
spec, should be sufficient to get a number from the IANA.  It might
also be reasonable to require that comments about the clarity of the
specification made on the working group mailing list in the first two
weeks after the internet-draft is make available need to be
substantially addressed in a revised internet-draft in order to
qualify for a number from IANA.

I really don't like the ``any published spec of unspecified quality
and unspecified process'' approach.  The US Patent system has
demonstrated that if you require a readable, detailed, useful
description of how to do something and don't have a good enforcement
mechanism, people don't necessarily provide documents that are clear
explainations.  On the other hand, there's probably more incentive to
provide an actively bad document to the patent office than there is to
the IANA.  If there is going to be a requirement to have a published
spec at all, I think it needs to come with some clear procedure for
reviewing the quality.

I do like the idea of reserving smaller values for standards track
enctypes, although I think perhaps working group consensus that there
is a quality spec deserving of a smaller number might be a better
target, because that gives people an (admittedly small) incentive to
write a good spec even for enctypes that aren't quite standards track.

Would it be reasonable to assign numbers consecutively, starting at
the bottom of the range and working up for things that get small
numbers, and at the top of the range and working down for things that
get large numbers, with the option that working group consensus or a
Designated Expert could specify something else if there is a good
reason?

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Aug 2003 14:04:02 -0400

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:

    Joel> People also have this habit of implementing things before
    Joel> the internet-drafts find their way to the RFC stage (AES and
    Joel> RC4 for Kerberos; the entire sshv2 protocol; probably other
    Joel> things that I'm not paying any attention to).  What you may
    Joel> be encouraging is that people initially deploy their schemes
    Joel> with the Private Use range, and then switch to using a new
    Joel> enctype a year later when the RFC finally comes out, along
    Joel> with an implementation note suggesting that everyone support
    Joel> either enctype value in order to maximize interoperability,
    Joel> or something.

That seems to work reasonably well for other protocols.  I don't
really see the problem with it.