Re: PublicKeyFile Format Security Considerations

["Brent McClure" <mcclure%swcp.com@localhost>]

----- Original Message ----- 
From: "Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>
....
> It does seem to be the case that the text we're discussing covers a
> subject that is assumed to be obvious in just about every other IETF
> document.  If we want to say ``don't write buffer overflows, and
> verify your data, and stuff'' in a very general way, it might be
> appropriate to write up a protocol-independent RFC saying those
> things, and have the security considerations section of every RFC
> refer to that generic, protocol-independent writeup.  This discussion
> makes me wonder if it is a bug that there is no RFC talking about
> buffer overflows, as far as I know.  There *is* an RFC about random
> numbers, for example.  But I'm sure an RFC about buffer overflows is
> beyond the scope of this working group.
> 
> If there is a specific reason why being careful about parsing the data
> is more important, or more difficult, or more subtle with an ssh
> public key file than in a generic case of parsing data, then
> explaining that would be useful.

I can't make a case that this parsing of the encoded key data presents
a specific condition that warrants it being mentioned. So, unless 
someone else can then I'll drop it from the security considerations.

So, here's the text as I currently have it, does this work?

----
Security Considerations

  The file format described by this document provides no mechanism
  to verify the integrity or otherwise detect tampering with the
  data stored in such files. Given the potential of an adversarial
  tampering with this data, system-specific measures (e.g. Access Control Lists, 
  UNIX permissions, other Discretionary and/or Mandatory Access Controls) 
  SHOULD be used to protect these files. Also, if the contents of these 
  files are transferred it SHOULD be done over a trusted channel.

  The header data allowed by this file format could contain an unlimited range of
  information. While in many environments the information conveyed by this
  header data may be considered innocuous public information, it may constitute
  a channel through which information about a user, a key or its use may be
  disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, 
  Home Phone:..."). The presence and use of this header data SHOULD be 
  reviewed by sites that deploy this file format.

thanks, Brent