Subject: [Ietf-krb-wg] [Tom Yu] case-converted padata numbers

From: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 13:49:14 -0400

Tom would really like to see case normalized PA types in the IANA
registry.  I'm happy to do this but want a positive ACK from someone
other than Tom and no NACK from anyone (especially Jeff) within the next
day.

Subject: case-converted padata numbers
From: Tom Yu <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 24 Mar 2010 13:12:42 -0400

Per earlier conversation, I downcased/normalized the spellings of the
padata/td type names from the preauth draft.

      Type                Value    Reference
  ----------------------------------------------------------------------
  pa-tgs-req                 1    RFC 4120
  pa-enc-timestamp           2    RFC 4120
  pa-pw-salt                 3    RFC 4120
  [reserved]                 4
  pa-enc-unix-time           5    (deprecated)
  pa-sandia-secureid         6
  pa-sesame                  7
  pa-osf-dce                 8
  pa-cybersafe-secureid      9
  pa-afs3-salt               10
  pa-etype-info              11   RFC 4120
  pa-sam-challenge           12   (sam/otp)
  pa-sam-response            13   (sam/otp)
  pa-pk-as-req-old           14   draft-ietf-cat-kerberos-pk-init-09
  pa-pk-as-rep-old           15   draft-ietf-cat-kerberos-pk-init-09
  pa-pk-as-req               16   RFC 4556
  pa-pk-as-rep               17   RFC 4556
  pa-pk-ocsp-response        18   RFC 4557
  pa-etype-info2             19   RFC 4120
  pa-use-specified-kvno      20
  pa-svr-referral-info       20   (referrals)
  pa-sam-redirect            21   (sam/otp)
  pa-get-from-typed-data     22   (embedded in typed data)
  td-padata                  22   (embeds padata)
  pa-sam-etype-info          23   (sam/otp)
  pa-alt-princ               24   ([email-masked])
  pa-server-referral         25   (referrals)
  pa-sam-challenge2          30   ([email-masked])
  pa-sam-response2           31   ([email-masked])
  pa-extra-tgt               41   Reserved extra TGT
  td-pkinit-cms-certificates 101  CertificateSet from CMS
  td-krb-principal           102  PrincipalName
  td-krb-realm               103  Realm
  td-trusted-certifiers      104  PKINIT
  td-certificate-index       105  PKINIT
  td-app-defined-error       106  Application specific
  td-req-nonce               107  INTEGER
  td-req-seq                 108  INTEGER
  td-dh-parameters           109  PKINIT
  td-cms-digest-algorithms   111  draft-ietf-krb-wg-pkinit-alg-agility
  td-cert-digest-algorithms  112  draft-ietf-krb-wg-pkinit-alg-agility
  pa-pac-request             128  MS-KILE
  pa-for-user                129  MS-KILE
  pa-for-x509-user           130  MS-KILE
  pa-for-check-dups          131  MS-KILE
  pa-as-checksum             132  MS-KILE
  pa-fx-cookie               133  draft-ietf-krb-wg-preauth-framework
  pa-authentication-set      134  draft-ietf-krb-wg-preauth-framework
  pa-auth-set-selected       135  draft-ietf-krb-wg-preauth-framework
  pa-fx-fast                 136  draft-ietf-krb-wg-preauth-framework
  pa-fx-error                137  draft-ietf-krb-wg-preauth-framework
  pa-encrypted-challenge     138  draft-ietf-krb-wg-preauth-framework
  pa-otp-challenge           141  ([email-masked])
  pa-otp-request             142  ([email-masked])
  pa-otp-confirm             143  ([email-masked])
  pa-otp-pin-change          144  ([email-masked])
  pa-epak-as-req             145  ([email-masked])
  pa-epak-as-rep             146  ([email-masked]>)
  pa-pkinit-kx               147  draft-ietf-krb-wg-anon
  pa-pku2u-name              148  draft-zhu-pku2u
  pa-supported-etypes        165  MS-KILE
  pa-extended-error          166  MS-KILE

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2010 20:27:25 +0200

> other than Tom and no NACK from anyone (especially Jeff) within the next

Why?  RFC 4120 uses upper-case for these symbols, and appears to be
fairly consistent about it (I can only find two exceptions).

/Simon

> ----------

---

From: Tim Alsop <[email-masked]>
Date: Tue, 18 May 2010 20:08:20 +0100

Hi,

>   pa-cybersafe-secureid      9

I think you will find that these related to RSA SecurID so there should be no 'e' 
Also, from CyberSafe perspective, I can confirm that we are not using this anymore so you can reallocate 9 to another use case.

Thanks,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: 18 May 2010 19:27
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] [Tom Yu] case-converted padata numbers

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 May 2010 14:18:19 -0500

> other than Tom and no NACK from anyone (especially Jeff) within the next

I don't see why this down-casing is necessary and would rather we use
the same case and spelling consistently in our documents and registries.

That said, my objection is not a strong one, and you can go ahead with
this plan as fare as I'm concerned.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Tue, 18 May 2010 16:22:31 -0400

> fairly consistent about it (I can only find two exceptions).

I sent the following proposal more than a year ago.  There were no
objections, and one "+1" from Henry Hotz.

-------------------- Start of forwarded message --------------------
To: [email-masked]
From: Tom Yu <[email-masked]>
Date: Thu, 26 Mar 2009 19:14:23 -0400
Message-ID: <[email-masked]>
Subject: [Ietf-krb-wg] the naming of constants is a difficult matter

I have been thinking about what "spelling" to give the names of
protocol constants, especially as we are about to hand off some of
these to IANA.  Many integer constants have associated names that have
appeared in specifications and as identifiers in implementation code,
though the names are not part of the protocol.

I think the two most logical possibilities are:

* C language preprocessor macro style

* ASN.1 value reference style

Luckily, if we choose carefully, we can create rules mapping between
them.  I propose the following practices:

* Use ASN.1 value reference style in tables.

* Use C-style in running text.

The lexical structure of ASN.1 value references is more restrictive
than that of C language preprocessor macro names.  ASN.1 value
references are required to begin with a lowercase letter, followed by
hyphens, digits, or letters.  Two or more hyphens may not appear
adjacent to each other, and there may not be a hyphen at the end.

The obvious mapping to C language style identifiers is to change all
the letters to uppercase and replace all hyphens with underscores.

For example:

    pa-etype-info2              Int32 ::= 19

    #define PA_ETYPE_INFO2      19

(Ignore the fact that the above C-style symbol does not actually
appear in the MIT krb5 implementation, but something that looks a lot
like it does.)

In running (flat ASCII) text, the (conventionally) all-lowercase ASN.1
value references do not stand out.  Surrounding them with quotation
marks probably helps, but looks somewhat intrusive.  Simply
transforming the ASN.1 value reference to all-uppercase makes them no
longer valid value references.  (ASN.1 type references begin with an
uppercase letter.)  Using a C-style identifier makes it clear that the
reference is not to an ASN.1 type name.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 May 2010 08:28:35 +0200

> objections, and one "+1" from Henry Hotz.

That doesn't address the fact that RFC 4120 (and as a consequence,
likely, other documents too) uses upper-case for these symbols.  My
preference would to aim for consistency, however I don't feel strongly
about it.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Wed, 19 May 2010 09:34:13 -0400

> preference would to aim for consistency, however I don't feel strongly

Actually RFC 4120 (and also other documents) is inconsistent about
lower/upper case and hyphens/underscores, with little correlation to
the ASN.1 syntactic context.  Sometimes the constants are C macro
style uppercase with underscore, sometimes uppercase with hyphens, and
sometimes lowercase with hyphens.  I would just as soon be consistent
by using the ASN.1 value reference syntax (lowercase with hyphens).
Using ASN.1 value reference syntax also enables the use of ASN.1
compilers with the symbols.  There are logical transformations to the
other styles, if needed.  It's likely that RFC 4120 uses the uppercase
in running text for emphasis.

A sampling of styles from RFC 4120:

* 5.3 ticket flags:     lowercase with hyphens
* 5.4.1 kdc options:    both lowercase with hyphens and uppercase with hyphens
* 7.5.2 preauth types:  uppercase with hyphens
* 7.5.3 address types:  mixed case with spaces (!)
* 7.5.4 authdata types: uppercase with hyphens
* 7.5.8 name types:     uppercase with underscores
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 19 May 2010 09:23:00 -0700

In the absence of a consistent convention to the contrary, I still like the idea of connecting RFC text closely to with what gets copied into implementations.  I'll grant it's not the most important issue out there.

> * 7.5.8 name types:     uppercase with underscores

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 May 2010 13:11:22 -0400

OK.  It does not look like we have the consensus to make the change Tom
is asking for post-ietf-LC.  Absent direction from Jeff or Tim I will
not make changes to the case/punctuation of the registry.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 May 2010 14:08:42 -0400

> not make changes to the case/punctuation of the registry.

It sounds to me like we have consensus that we want to be consistent.
Unfortunately, we do not have consensus about what we want to be consistent 
_with_.

Speaking as an individual, I'd really like to see us use a consistent style 
in all of our documents and registries.  To some extent, it's already too 
late -- we've published RFC4120 and other documents which are not even 
internally consistent, let alone with each other.  We also have three 
existing IANA registries (enctypes, cksumtypes, and TCP extensions, though 
the last is still effectively empty).  FWIW, the existing registries use 
mostly lowercase-with-hyphens, except for some of the PKINIT OID enctypes 
which use StudlyCaps-with-hyphens.

There's nothing we can do with the already-published documents, except 
insure they conform to whatever style we adopt if/when we ever revise them. 
What we can and should do is adopt a style and then be consistent about 
using it in future documents.

Speaking as chair, I think it would be appropriate, if the WG reaches 
consensus on a preferred style for these identifiers, to make the needed 
editorial changes to already-approved documents to bring them in line with 
the preferred style.  After all, the RFC-Editor makes changes to such 
documents all the time to bring them into line with the established style 
for the RFC series.

Given that we're probably not going to see a consensus in the next day or 
so, I think the best thing to do with the present document is to leave it 
as-is for now.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Wed, 19 May 2010 14:12:44 -0400

Jeffrey Hutzelman <[email-masked]> writes:

> consensus on a preferred style for these identifiers, to make the
> needed editorial changes to already-approved documents to bring them
> in line with the preferred style.  After all, the RFC-Editor makes
> changes to such documents all the time to bring them into line with
> the established style for the RFC series.
>
> Given that we're probably not going to see a consensus in the next day
> or so, I think the best thing to do with the present document is to
> leave it as-is for now.

How do you think IANA will react if we request that they case-fold
some of our registries at some point after they're established?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 May 2010 14:26:19 -0400

> some of our registries at some point after they're established?

Good question.  Given that it's an editorial change and the names have no 
protocol significance, I suspect they won't object too much.  I suppose we 
could ask them.

-- Jeff