Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt

From: [email-masked]
Date: Mon, 04 Apr 2005 15:52:13 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Public Key File Format
	Author(s)	: J. Galbraith, R. Thayer
	Filename	: draft-ietf-secsh-publickeyfile-08.txt
	Pages		: 14
	Date		: 2005-4-4
	
This document formally documents the existing public key file format
in use for exchanging public keys between different SECSH
implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-publickeyfile-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-publickeyfile-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Apr 2005 00:59:56 -0400 (EDT)

I jsut read over draft-ietf-secsh-publickeyfile-08.txt; herewith
comments.  Bare numbers flush left are section numbers.

3
   A key file is a text file, containing a sequence of lines.  Each line
   in the file MUST NOT be longer than 72 bytes excluding line
   termination characters.
3.1
   Implementations are REQUIRED to read files using any of the common
   line termination sequence, <CR>, <LF> or <CR><LF>.

I see problems here, both philosophical and practical.

A file containing a sequence of lines does not necessary have *any*
line termination sequence.  Across the OSes I've used, I've seen at
least three ways of storing a sequence of lines in a text file, only
one of which fits the termination-sequence model.  (One way is a
termination sequence; another way is a length attached to each line,
but returned by the interface not as in-band octets but rather as the
length of the record read; a third way is a record length attached to
the file, equal for all records in the file.)  Line termination
sequences make sense only for files that are conceptually sequences of
octets, rather than files that are conceptually sequences of lines
("records" is the usual word in filesystem docs I've seen).

If you want to provide a spec for encoding public keys as octet streams
containing sequences of lines delimited by line termination sequences,
that's fine, but that's (a) less useful (because it requires converting
between octet-stream representations and native representations for
filesystems that don't use line termination sequences) and (b) not what
publickeyfile-08 calls itself.

At various other places, I see wording such as "excluding line
termination characters" which I think needs an ", if any" attached.  Of
course, depending on how the line termination wording is resolved, this
may become a non-issue.

3.3
   The Header-tag MUST NOT be more than 64 bytes, and is
   case-insensitive.  The Header-value MUST NOT be more than 1024 bytes.
   Each line in the header MUST NOT be more than 72 bytes.

Since the Header-tag is explicitly declared case-insensitive, I'd
prefer to see the case-sensitivity of the Header-value mentioned, even
if only with wording like "...more than 1024 bytes, and, depending on
the Header-tag, may or may not be case-sensitive.".

3.3
   A line that is not a continuation line that has no ':' in it is the
   first line of the base 64 encoded body (See Section 3.4.)

s/base 64/base-64/ here?

3.3.1
No indication is given here what to do if the login name in question
does not exist or is not available.  Is the format unusable?  Should
Subject: be omitted?  Should whatever username is available be used?
Or something else?

3.3.2
   existing implementations fail if these quotation marks are omitted

There's an end-of-sentence . missing here.

3.3.2
   Implementations MAY include the quotation marks.  If the first and
   last characters of the Header-value are matching quotation marks,
   implementations SHOULD remove them before using the value.

"matching quotation marks" sounds as though there are other characters
than " that count as quotation marks.  I'd prefer to see this list
explicitly described, or else an indication that any character can
function as a quotation mark (or possibly any character except a
letter, or some such).

4
I'd like to see a specific public key quoted here together with its
fingerprint, for the same reason crypto specs include test vectors.

6
   intentionally or otherwise (e.g "Comment: Mary E.  Jones, 123 Main

s/E.  J/E. J/ surely?

6
   is for historical purposes, and the particular use made of it depends
   solely one it's 2nd-preimage resistance, not on it's

s/it's/its/g on the second of the quoted lines.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ben Harris <[email-masked]>
Date: Tue, 05 Apr 2005 13:52:36 +0100

>publickeyfile-08 calls itself.

Um, section 2 makes it fairly clear that the format described is for
exchanging public keys between implementations, rather than necessarily for
use within an implementation.  It could probably be clearer.

>the Header-tag, may or may not be case-sensitive.".

I don't think case-sensitivity is a useful concept to apply to header-values
in the abstract.  To take an analogy, would you say that the RFC-822
"Subject" header is case-sensitive or not?

>   first line of the base 64 encoded body (See Section 3.4.)

"base64-encoded", actually.  See RFC 2045.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Tue, 05 Apr 2005 14:38:01 +0100

>	Filename	: draft-ietf-secsh-publickeyfile-08.txt

One semantic problem:  Both sections 3.4 and 4 refer to a "public key blob". 
This term isn't clearly defined by [SSH-TRANS], and in particular it's
hinted there that it doesn't include the name of the key type:

   The key type MUST always be explicitly known (from algorithm
   negotiation or some other source).  It is not normally included in
   the key blob.

It would appear from the first example given that publickeyfile expects the
"public key blob" to include the key type name, though, since it begins with
the string "ssh-rsa".  I'd suggest removing the word "blob" wherever it
occurs, since it appears that "public key" in [SSH-TRANS] includes the key
type string.

I echo der Mouse's suggestion that an example of a key and its corresponding
fingerprint would be useful.  I'd suggest putting the examples in a section
of their own after the definition of fingerprints, and including the
fingerprint of each key.

It might be polite to acknowledge Markus Friedl, who wrote the previous
fingerprint drafts.

Simple nits, presented as a diff as usual:

--- draft-ietf-secsh-publickeyfile-08.txt       Mon Apr  4 17:47:10 2005
+++ draft-ietf-secsh-publickeyfile-bjh.txt      Tue Apr  5 14:23:53 2005
@@ -283 +283 @@
-   first line of the base 64 encoded body (See Section 3.4.)
+   first line of the base64-encoded body (See Section 3.4.)
@@ -308 +308 @@
-   existing implementations fail if these quotation marks are omitted
+   existing implementations fail if these quotation marks are omitted.
@@ -327,2 +327,2 @@
-   described in [I-D.ietf-secsh-transport], section 4.6, "Public Key
-   Algorithms", encoded in base 64 as specified in [RFC2045], section
+   described in [I-D.ietf-secsh-transport], section 6.6, "Public Key
+   Algorithms", encoded in base64 as specified in [RFC2045], section
@@ -357 +357 @@
-   (note that the examples all wrap before 72 lines to meet ietf
+   (note that the examples all wrap before 72 columns to meet IETF
@@ -454 +454,2 @@
-   difficult for a human to verify an entire host key.  Even with a PKI
+   difficult for a human to verify an entire host key.  Even with a
+   public key infrastructure
@@ -566 +567 @@
-   stored in such files.  Given the potential of an adversarial
+   stored in such files.  Given the potential for an adversary's
@@ -571 +572 @@
-   trusted channel.
+   secure channel.
@@ -585 +586 @@
-   solely one it's 2nd-preimage resistance, not on it's
+   solely on its 2nd-preimage resistance, not on its

-- 
Ben Harris

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Apr 2005 12:22:10 -0400 (EDT)

>> If you want to provide a spec for encoding public keys as octet
>> streams containing sequences of lines delimited by line termination
>> sequences, that's fine, but that's (a) less useful (because it
>> requires converting between octet-stream representations and native
>> representations for filesystems that don't use line termination
>> sequences) and (b) not what publickeyfile-08 calls itself.
> exchanging public keys between implementations, rather than
> necessarily for use within an implementation.  It could probably be
> clearer.

It's clear that's what motivated it.  It's not clear that it's intended
to be restricted to that.

I'm also not convinced that it makes any difference.  A text file is a
reasonable unit for interchange; there is no need to reduce it to an
octet sequence of defined contents.  After all, such interchange may
well be between implementations running on the same OS or even the same
machine.  While most storage mechanisms do reduce a text file to an
octet sequence at some point, that octet sequence does not need to fall
under the jurisdiction of the spec - nor would it be particularly
useful for it to do so.

>> prefer to see the case-sensitivity of the Header-value mentioned,
>> even if only with wording like "...more than 1024 bytes, and,
>> depending on the Header-tag, may or may not be case-sensitive.".
> I don't think case-sensitivity is a useful concept to apply to
> header-values in the abstract.

I do (see below).  Your I-D defines only two headers, though, and
neither of them is for routine automated consumption, so neither of
them really needs a case-sensitivity spec - though they need to be
case-preserved, it seems to me.

> To take an analogy, would you say that the RFC-822 "Subject" header
> is case-sensitive or not?

Since Subject: is an unstructured header field, I'm not sure it is
useful in that case.  But as an abstract concept it is useful; consider
Content-Transfer-Encoding:, which is defined to be case-insensitive.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 Apr 2005 13:26:34 -0400

> under the jurisdiction of the spec - nor would it be particularly

On the contrary, this document essentially specifies a wire format for the 
interchange of SSH public keys.  As such, it MUST specify details like line 
termination.  Otherwise it is underspecified, and it may not be possible to 
create interoperable implementations.

-- Jeff

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 06 Apr 2005 13:54:27 +1200

>create interoperable implementations.

This is just getting silly... no, more than that, it's ridiculously pedantic.
Yes, it is in theory possible to find a record-oriented system that doesn't
support flat text files.  However, if anyone were ever to port SSH to CICS,
I'm sure they could write a special profile for it that would allow it to
interoperate with all the other CICS implementations of SSH.  In the meantime
since MIME, PGP, XML, and a million other flat-text formats have somehow
managed to struggle by without worrying about this, why is it a concern here?
The coverage of the flat-text format in the spec seems perfectly clear and
completely adequate to me, I'd suggest that if anyone feels the need to add 20
pages of additional wording explaining to readers what a text file is, they
may prefer another line of work.  Writing ETSI PKI standards springs to mind.

Peter :-).

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Apr 2005 23:34:34 -0400 (EDT)

> On the contrary, this document essentially specifies a wire format
> for the interchange of SSH public keys.

That's not what it says it specifies, but it's approximately what it
does specify.  That dissonance is, essentially, what I think needs
fixing.

> As such, it MUST specify details like line termination.  Otherwise it
> is underspecified, and it may not be possible to create interoperable
> implementations.

Yes - if it were a wire format.  But a wire format without a protocol
to transmit it over is an odd thing, and, conceptually, it really does
make sense to specify the format in terms of a stream of lines.

It really needs, it seems to me, to decide whether it is specifying a
stream of lines (in which case line termination should not even be
mentioned, since that is outside the scope of the spec, how lines are
represented in storage being a local matter and how lines are encoded
for transmission being a matter for the transmission protocol in use)
or a stream of octets (in which case it should not call itself a file
format, and definitely does need to specify how lines are encoded into
octet streams).

Personally, I prefer the stream-of-lines model, but it's not my draft.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Apr 2005 23:44:50 -0400 (EDT)

> This is just getting silly... no, more than that, it's ridiculously
> pedantic.  Yes, it is in theory possible to find a record-oriented
> system that doesn't support flat text files.

However, that's not what I'm talking about.

I'm talking about systems that support "flat text files", but in ways
other than as an octet stream with line boundaries marked by
distinctive octet sequences.  Some text file types on VMS, for example.

> However, if anyone were ever to port SSH to CICS, I'm sure they could
> write a special profile for it that would allow it to interoperate
> with all the other CICS implementations of SSH.

Quite possibly, but, as written, they would not be able to use
publickeyfile (assuming, that is, that CICS text files cannot use
line-termination octets).  They would at best use a similar format that
did not require line-termination octets to represent line breaks -
basically, publickeyfile without the folderol about line termination
characters.

> In the meantime since MIME, PGP, XML, and a million other flat-text
> formats have somehow managed to struggle by without worrying about
> this, why is it a concern here?

Quite so.  I would prefer that all the language about line-termination
characters be ripped out and the spec be written purely in terms of
lines, without specifying anything about how those lines are
represented.

> The coverage of the flat-text format in the spec seems perfectly
> clear and completely adequate to me, I'd suggest that if anyone feels
> the need to add 20 pages of additional wording explaining to readers
> what a text file is, they may prefer another line of work.

(1) I point out to you the language about line termination characters,
which is unimplementable nonsense on OSes that don't use line
termination characters to delimit lines; (2) 20 pages is a gross
exaggeration; (3) I am not suggesting adding any text, but rather
removing text (unless someone is steadfastly opposed to removing the
line termination language, and even then only the occasional "if any"
note or equivalent); and (4) this (proposed) change is not an attempt
to explain or specify what a text file is, but to avoid constraining
what a text file is in ways that are incompatible with some
environments.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 07 Apr 2005 15:55:36 +1200

der Mouse <[email-masked]> squeeked:

>termination characters to delimit lines; 

Which OSes can't handle flat text files?  Yes, I know it's possible with a bit
of effort to dig up some OS relic that has record-format files *alongside text
files*, but the only OS I can think of right now that *only* has record-format 
files is CICS, and since AFAIK cryptlib is the only SSH implementation than 
runs on CICS and I don't care how it stores its files, this isn't an issue.  
Thus my comment that your objection is ridiculously pedantic - I can claim (for 
example) that QNX version 2 and earlier use record separators instead of CR or 
LF and that the spec is therefore completely unworkable for people running QNX 
on their PC AT, but in practice I think if anyone's still using that they'll 
be able to cope.  The text as is (that is, saying that you need to be able to 
handle CR and/or LF terminators) is just fine, and as a vast number of other 
IETF specs that work with flat text have shown is perfectly workable and 
adequate.  This is starting to sound like those X3J11 arguments about needing 
trigraphs...

Peter.

---

From: der Mouse <[email-masked]>
Date: Thu, 7 Apr 2005 00:02:35 -0400 (EDT)

>> (1) I point out to you the language about line termination
>> characters, which is unimplementable nonsense on OSes that don't use
>> line termination characters to delimit lines;
> Which OSes can't handle flat text files?

What is a "flat text file"?  You appear to be using it to mean
something close to "file which uses line termination characters to
delimit text lines", which seems..wrong.

> Yes, I know it's possible with a bit of effort to dig up some OS
> relic that has record-format files *alongside text files*,

I don't know what you think a text file is, but back when I used VMS,
and as I understand the terms, it had record-format files that *were*
text files: one of the ways of storing a text file - the commonest, if
my memory from then is accurate - involved records with lengths
associated with them, each line being its own record.

> [...] and I don't care how it stores its files, this isn't an issue.

So anything you don't care about isn't an issue?  That's
an..interesting..point of view.

But your remark actually reinforces my point of view: you *don't* care
how it stores its files - so why should the the publickeyfile spec?

> Thus my comment that your objection is ridiculously pedantic - I can
> claim (for example) that QNX version 2 and earlier use record
> separators instead of CR or LF and that the spec is therefore
> completely unworkable for people running QNX on their PC AT, but in
> practice I think if anyone's still using that they'll be able to
> cope.

Yes - but they will do so by ignoring that aspect of the spec.

And that is why I think that aspect should be fixed: it unreasonably
and unnecessarily constrains implementations.  Writing the spec such
that the only reasonable way to approximate it on some OSes is by
violating part of it is a Bad Thing, it seems to me, unless of course
excluding those OSes is a deliberate goal.

> The text as is (that is, saying that you need to be able to handle CR
> and/or LF terminators) is just fine,

If that's what it's intended to say, it needs some touchup.  What it
actually says is

Reading this with your interpretation in mind, I can see how it can be
interpreted that way.  But it can also be interpreted as saying that
implementations must treat any of those octet sequences as a line
terminator, even if the file is such that lines are not normally
delimited with line termination octets, which is a peculiar and
unnecessary (and arguably wrong) thing to do for such files.

The rest of the draft also contains language that assumes line
termination characters are used, such as the next sentence

   Implementations may generate files using whichever of these line
   termination conventions is most convenient.

which I argue needs to be rewritten to take into account the
possibility that the "most convenient" format does not use line
terminations at all, but instead, say, record lengths.  As written, I
cannot but read it as specifying that one of those line termination
conventions be used, but exactly which one is chosen is up to the
implementation.  I do think it is possible to serve both this end and
the end this is apparently intended to serve, with language such as

   Implementations for text file formats using line termination
   characters MUST recognize any of the common line termination
   sequences (<CR>, <NL>, or <CR><LF>) as a line termination.  When
   generating such a file, implementations may use whichever sequence
   they find most convenient.

(Note the mnemonic change - when a bare 0x0a is a line termination, it
is more correctly called NL than LF.)

3.3 ("formed by removing the '\' and the line termination characters")
and 3.4 ("MUST NOT be longer than 72 characters excluding line
termination characters") also appear to be written in the assumption
that line termination is in use.  I argue that they should be modified
to fix this.  Specifically, I propose "...the '\' and any line
termination characters" and "...excluding line termination characters,
if any".

Your point about other specs is an interesting one.  It prompted me to
go read 2822 and 2045 with this in mind, and I am surprised and
discouraged to find that those specs do include such specification and
that when they are supposedly applied to local storage, they have thus
been (almost universally, in my experience) "implemented" by ignoring
their line-termination aspects.  Most such implementations are
therefore not implementations of those specs at all, but rather of
closely related specs, never formally codified, which use OS-native
conventions for representing line boundaries.  (The specs as written
generally do apply on the wire, which is the proper place for
specifying line boundary representation.)

I believe that this should be taken not as an indication that it's OK
to write another such spec which will undoubtedly draw similar
not-quite-implementations - especially since this one is not used by a
wire protocol, unlike 2045 and 2822 which are used by the wire protocol
defined by 2821 - but rather as an indication that attempts to specify
such things do not belong in a file-format spec, only in
wire-protocol-format specs.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 07 Apr 2005 09:58:07 -0600

> associated with them, each line being its own record.

Yes.  Each 'line' is preceeded by a two-byte, big endian, length
field, and has no delimitting sequence.  An interesting side effect
is that if you accidentally transfer a binary file in text-mode, it
can often be repaired.

Shall I include this format in the draft and require that
implementations be able to read files in such a format?

I believe that the current draft specifies cr, crlf, or lf for
a very good reason--

I suppose we could have require that any transport translate
from the source to the destination text formats.  In which
case we could omit specifying how lines are delimitted and
leave that as an implemenation detail.

However, that wasn't the route we chose to take.

> Yes - but they will do so by ignoring that aspect of the spec.

No.  QNX version 2 may not consider a publickey file as a text
file, but that is irrelevant.

SSH implementations on QNX version 2 will read the *binary*
(from QNX's point of view) file containing \r, \n, \r\n.

Such an implementation, if it wishes, might convert publickey files
files to a a format the QNX does consider to be a text file
(by removing the \r, \n, or \r\n delimiters and inserting
record seperators) but this is an implementation detail.

Such an implementation might also choose to support reading
files stored in the QNX native format... again, an implementation
detail.

The whole purpose of the spec is to define a file format that
can be read by multiple implementations, spanning multiple
platforms.

Thanks,

Joseph

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 08 Apr 2005 16:15:36 +1200

der Mouse <[email-masked]> squeeked:

>And that is why I think that aspect should be fixed: it unreasonably and
>unnecessarily constrains implementations.

There's a simple way to solve this debate.

Is anyone on this list (which seems to include most SSH implementors) going to
have their SSH implementation inconvenienced by the current text?  That is,
does it affect any real SSH implementation?  If it directly affects your code,
please let us know.

(As I've already mentioned, my code runs on OSes that optionally have record-
style files, and one that AFAIK only has record-style files, and I'm not
inconvenienced in any way, the spec is fine for me).

>It prompted me to go read 2822 and 2045 with this in mind, and I am surprised
>and discouraged to find that those specs do include such specification and
>that when they are supposedly applied to local storage, they have thus been
>(almost universally, in my experience) "implemented" by ignoring their line-
>termination aspects.  Most such implementations are therefore not
>implementations of those specs at all, but rather of closely related specs,
>never formally codified, which use OS-native conventions for representing
>line boundaries.

"Gee, look at all these specs and implementations (many of which have been
around for years), they're all interpreting them incorrectly except for me".

Peter (who still can't believe we're actually debating something like this.
       It's trigraphs all over again).

---

From: der Mouse <[email-masked]>
Date: Fri, 8 Apr 2005 00:20:40 -0400 (EDT)

> Is anyone on this list (which seems to include most SSH implementors)
> going to have their SSH implementation inconvenienced by the current
> text?  That is, does it affect any real SSH implementation?  If it
> directly affects your code, please let us know.

Probably not.  It certainly won't affect the code I write; it'll just
mean the resulting files won't conform unless the text file format
underlying the interfaces I use actually has line terminations (which
is something I can't easily determine when writing at the C level).

> (As I've already mentioned, my code runs on OSes that optionally have
> record-style files, and one that AFAIK only has record-style files,
> and I'm not inconvenienced in any way, the spec is fine for me).

No, it won't inconvenience you, unless you bother to actually implement
the spec as written, instead of its apparent intent - and probably not
even then unless you're on an OS where the local convention for text
files isn't to use line terminators.  And even *then*, it won't unless
you care about the difference between a file that uses the local
conventions for text files and a file that manages to use line
terminators despite the local conventions being otherwise.

>> It prompted me to go read 2822 and 2045 with this in mind, and I am
>> surprised and discouraged to find that those specs do include such
>> specification and that when they are supposedly applied to local
>> storage, they have thus been (almost universally, in my experience)
>> "implemented" by ignoring their line-termination aspects.
> "Gee, look at all these specs and implementations (many of which have
> been around for years), they're all interpreting them incorrectly
> except for me".

More likely, just implementing their apparent intent rather than
implementing the spec as written.  If the current language stands,
that's basically what I'll do for publickeyfile (but I'll be careful to
not claim conformance, of course).

> Peter (who still can't believe we're actually debating something like
> this.  It's trigraphs all over again).

I wouldn't be, except that I'd like to be able to conform without
having to go to extreme lengths to do so (like making sure that if it's
built on VMS it uses a stream-LF file rather than a varying-record file
for output, something I'm not even sure how to do from C).

I also want the spec to be as good as possible.  It really is quite
good; this one point of line terminations, small as it is, is the
largest (in my opinion) flaw I found in the whole thing.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: "denis bider" <[email-masked]>
Date: Fri, 8 Apr 2005 19:17:47 +0200

It is fine for the public key spec to explain that the ability to parse any
CR/LF line termination is desired. However, the draft does so clumsily and
without explaining the problem. The strength of this requirement needs to be
reduced to make it a recommendation, and it needs to be explained that the
requirement is there so that no human intervention is required to make
public key files work after being transferred in binary form, e.g. using
SFTP version 3 (the most common mechanism for transferring public keys).

---

From: Damien Miller <[email-masked]>
Date: Sat, 09 Apr 2005 08:43:01 +1000

> does it affect any real SSH implementation?  If it directly affects your code,

I agree that this debate is utterly silly and no, it doesn't effect
OpenSSH.

-d