Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006]

From: Joseph Galbraith <[email-masked]>
Date: Wed, 01 Mar 2006 08:43:53 -0700

I just submitted a new version of the draft with
the changes suggested by Jacob.

I think this should clear up the confusion about the
IANA section.

Thanks,

Joseph

Jacob Nevins wrote:
> I wrote:
>> I guess RFC2434/BCP0026 might be of use?
>>
>> Could it be as simple as moving the language about "IETF Consensus" and
>> X-headers to the IANA Considerations section, and referencing 2434?
> 
> Sam Hartman threatened to bounce this draft if nothing happened before
> the end of February. Something has happened, but then it all went quiet
> again. So, here's a minimal attempt to sort out the "IANA
> Considerations" section, based on reading RFC 2434:
> 
> Section 3.3 "Key file header", change the following text:
> 
> before:
>    Compliant implementations MUST ignore unrecognized header fields.
>    Implementations SHOULD preserve unrecognized header fields when
>    manipulating the key file.
> 
> after:
>    The space of header-tags is managed as described in Section 5.
> 
>    Compliant implementations MUST ignore headers with unrecognized
>    header-tags. Implementations SHOULD preserve such unrecognized
>    headers when manipulating the key file.
> 
> Section 3.3.3 "New Headers": replace whole section:
> 
> before:
> 3.3.3.  New Headers
> 
>    Headers with header-tags beginning with "x-" are considered
>    experimental, and may be used without IETF consensus.
> 
>    All other headers are reserved for use only by IETF consensus.
> 
> after:
> 3.3.3.  Private Use Headers
> 
>    Headers with header-tags beginning with "x-" are reserved for
>    private use.
> 
> Section 5 "IANA Considerations": replace entire section text:
> 
> before:
>    An IANA registry needs to be created containing the defined header-
>    tags.  These are 'subject' and 'comment'
> 
> after:
>    Section 3.3 defines a new namespace of "Header-tags". These are
>    US-ASCII strings of maximum length 64 characters, and are
>    case-insensitive.
> 
>    The following header-tags are defined by this document:
>      subject
>      comment
> 
>    In addition, all header-tags beginning with "x-" are reserved for
>    Private Use, as defined in [RFC2434].
> 
>    Further allocations are to be made by IETF Consensus, as defined
>    in [RFC2434].
> 
> Section 7.2 "Informative References" (right section?): add one:
> 
>    [RFC2434]  Narten, T. and Alvestrand, H., "Guidelines for Writing an
>               IANA Considerations Section in RFCs", RFC 2434,
>               October 1998.
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Mar 2006 14:02:43 -0500

1) RFC 2434 needs to be normative not informative.

2) You don't actually manage to describe what fields are in the IANA
   registry Do you want anything more than the header name and a
   reference to the document defining the header If not, say that.

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 2 Mar 2006 21:52:45 +0000

>    reference to the document defining the header If not, say that.

I don't think we need anything more than that.

How about these edits, relative to the publickeyfile-12 posted on
this list?:

Section 5 "IANA Considerations":
replace the following text:

      subject

      comment

   Further allocations are to be made by IETF Consensus, as defined in
   [RFC2434].

with:

   IANA is required to create and maintain a registry of these
   header-tags. The registry will map each header-tag to a reference
   defining the header.

   The initial contents of the registry are as follows:

      subject           defined in Section 3.3.1
      comment           defined in Section 3.3.2

   Header-tags beginning with "x-" are reserved for Private Use,
   as defined in [RFC2434].

   All other allocations are to be made by IETF Consensus, as
   defined in [RFC2434].

Move [RFC2434] reference from section 7.2 to 7.1.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 03 Mar 2006 22:30:32 +1300

Jacob Nevins <[email-masked]> writes:

>How about these edits, relative to the publickeyfile-12 posted on this list?:

I'd like to suggest one more, at the end of section 3.2:

  Note that this differs from the widely-used PEM format on which this is
  based in using four dashes and a space.  Every other implementation uses
  five dashes and no space.

This is to point out a potential booby-trap for implementors who are used to
the PGP, OpenSSL, Netscape, etc etc use of the standard PEM-style "-----BEGIN
whatever" form.

Peter.

---

From: Jacob Nevins <[email-masked]>
Date: Fri, 3 Mar 2006 10:37:41 +0000

Peter Gutmann writes:
>   Note that this differs from the widely-used PEM format [...]

There's already a whole section (3.5) on this subject.