Subject: WG LAST CALL: SECSH Public Key File Format

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Mar 2002 18:51:41 -0500

This is the start of a working group LAST CALL on:

	draft-ietf-secsh-publickeyfile-02.txt
		SECSH Public Key File Format

Last Call on this document expires in three weeks, on 3 April 2002
(I'm giving it an extra week due to the upcoming IETF week).

Send comments on the document to [email-masked]

Discussion question for the working group: Should this be advanced as
Informational or as a Standards Track document?  It could go either
way -- it's not a "wire protocol" per se but it does describe a blob
of data which can be exchanged (out of band) between implementations.

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 13 Mar 2002 19:10:49 -0700

> of data which can be exchanged (out of band) between implementations.

Personally, I'd like to see it go "Standards Track".

Jeff P. Van Dyke
[email-masked]

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 14 Mar 2002 04:25:50 +0000

> of data which can be exchanged (out of band) between implementations.

I'd say Informational.

DF

---

From: David Terrell <[email-masked]>
Date: Wed, 13 Mar 2002 22:10:19 -0800

> > of data which can be exchanged (out of band) between implementations.

I'd lean that way as well.

How many file formats are documented as parts of the standards
track?  Even HTML is only done by the W3C, not the IETF.  The only
example I know of is the DNS zone file format in 1034/5 and various
updates, and recent traffic on namedroppers has expressed regret
over that decision.

-- 
David Terrell   | "If I had a nickel for every time I've seen a Usenet poster
Nebcorp PM      | slip in an ostensibly casual reference to how much smarter
[email-masked]    | he/she is than everyone else... why, I'd be able to throw a
wwn.nebcorp.com |party for all my Mensa buddies!" -- Miguel Cruz

---

From: [email-masked] (Niels Möller)
Date: 14 Mar 2002 11:04:40 +0100

> > of data which can be exchanged (out of band) between implementations.

Me two. Actually, I'll most likely prefer *not* using this format, but
to stay with the keyformats defined by SPKI.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 14 Mar 2002 11:42:21 +0100

> (I'm giving it an extra week due to the upcoming IETF week).

I don't quite like the new rules for continuation lines and separation
between headers and body. I'd prefer using the good old method used
for other header-body type messages, like mail and http. I.e.:

  The (possibly) empty header part is separated from the body by an
  empty line. Continuation lines are non-empty, and start with a
  sequence of whitespace characters.

Then standard routines for dealing with header and body can be reused.
Some examples of the format I'd prefer are below.

Regards,
/Niels

---- BEGIN SSH2 PUBLIC KEY ----
Subject: galb
Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001

AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459
6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6
NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=
---- END SSH2 PUBLIC KEY ----

---- BEGIN SSH2 PUBLIC KEY ----

AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459
6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6
NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=
---- END SSH2 PUBLIC KEY ----

---- BEGIN SSH2 PUBLIC KEY ----
Subject: galb
Comment: 1024-bit rsa, created by galb@shimi 
	Mon Jan 15 08:31:24 2001

AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459
6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6
NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=
---- END SSH2 PUBLIC KEY ----

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 15 Mar 2002 08:45:15 -0700

> Some examples of the format I'd prefer are below.

The draft documents existing practice, (except where
it was necessary to deviate for interoperability --
for example, requiring that any newline convention
be allowed.)  I suppose this would argue for informational.

On the other hand, since there is no other mechanism
for a client to give the server it's public keys, if an
implementation can't at least convert this format to its
prefered format, it won't interoperate with any clients
except its own (for public key authentication.)

In order for public key authentication to interoperate,
there must be a way to exchange public keys between the
client and the server.  This draft provides a standard
that can be used for that exchange.  This would argue for
"Standards Track"

- Joseph