Re: PublicKeyFile Format Security Considerations

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

Revised the Public-key file format Security Considerations
based on comments:

- Removed use of vague term "sensitive".
- Added in text suggestion from Ran.

Is the blurb about information disclosure by "Comment" headers
too strong, unnecessary or OK?

thanks, Brent

----
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.

  Implementors are cautioned to verify the correctness of the encoding/decoding
  routines used to save and read files in this format. A malfunctioning
  decoder used to read public-key data will most likely produce 
  invalid data with unknown cryptographic properties. In the worst
  case this cata could be vulnerable various forms of cryptographic attack.

  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.

--Brent

----- Original Message ----- 
From: "RJ Atkinson" <rja%extremenetworks.com@localhost>
To: <sommerfeld%east.sun.com@localhost>
Cc: "Brent McClure" <mcclure%swcp.com@localhost>; <ietf-ssh%NetBSD.org@localhost>
Sent: Saturday, July 26, 2003 8:44 AM
Subject: Re: PublicKeyFile Format Security Considerations 


> 
> On Friday, Jul 25, 2003, at 19:25 America/Montreal, Bill Sommerfeld 
> wrote:
> >>   The file format described by this document provides no mechanism
> >>   to verify the integrity or otherwise detect tampering of the
> >>   data stored in such files. It is the responsibility of the parties
> >>   that create or exchange files written in this format to ensure that
> >>   appropriate access controls are applied to such files, and that
> >>   the files, if transfered, are exchanged over a trusted channel.
> >>
> >>   The data encoded using this file format is sensitive.
> >
> > "sensitive" in what sense?
> >
> >>   Implementors are cautioned to verify the correctness of the
> >>   encoding/decoding routines used to save and read files in this
> >>   format. A malfunctioning decoder used to read a public-key file
> >>   will most likely produce unsound data of unknown cryptographic
> >>   properties that in the worst case could be vulnerable various
> >>   forms of cryptographic attack.
> 
> Suggested text fragment:
> 
> "Given the potential of an adversary tampering with data stored
> in such files on filesystems, system-specific measures (e.g.
> Access Control Lists, UNIX permissions, other Discretionary
> and/or Mandatory Access Controls) SHOULD be used to protect
> these files."
> 
> (edit to taste)
> 
> Ran
>