From recovered-from-private-archive Thu Mar 23 23:05:06 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Received: by mail.netbsd.org (Postfix, from userid 0) id 6D2D363B18D; Wed, 1 Mar 2006 15:41:59 +0000 (UTC) Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id AE0E363B180 for ; Wed, 1 Mar 2006 15:41:56 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8606875; Wed, 01 Mar 2006 08:42:00 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Please publish attached draft-ietf-secsh-publickeyfile-12.txt Precedence: list Content-Type: multipart/mixed; boundary="------------090405080108070400040307" To: Internet-Drafts@ietf.org, ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org MIME-Version: 1.0 From: Joseph Galbraith Date: Wed, 01 Mar 2006 08:41:51 -0700 X-Original-To: ietf-ssh@netbsd.org Message-ID: <4405C0BF.1000409@vandyke.com> This is a multi-part message in MIME format. --------------090405080108070400040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks, Joseph --------------090405080108070400040307 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-12.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-12.txt" Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: September 2, 2006 R. Thayer The Tillerman Group March 1, 2006 SSH Public Key File Format draft-ietf-secsh-publickeyfile-12.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. Galbraith & Thayer Expires September 2, 2006 [Page 1] Internet-Draft SSH Public Key File Format March 2006 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. Private Use Headers . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires September 2, 2006 [Page 2] Internet-Draft SSH Public Key File Format March 2006 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Galbraith & Thayer Expires September 2, 2006 [Page 3] Internet-Draft SSH Public Key File Format March 2006 2. Introduction The SSH protocol supports the use of public/private key pairs in order to perform perform authentication based on public-key cryptography. However, in order to use public-key authentication in the SSH protocol, public keys must first be exchanged between client and server. This document formally describes an existing public-key file format which can be used with any of the common existing file transfer mechanisms in order to exchange public keys. The SSH protocol also uses public/private key pairs to authenticate the server. In this scenario, it is important to verify that the public key provided by the server is indeed the server's public-key. This document describes a mechanism for creating a short text string that uniquely represents a particular public key, called fingerprinting. Galbraith & Thayer Expires September 2, 2006 [Page 4] Internet-Draft SSH Public Key File Format March 2006 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 8-bit bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires September 2, 2006 [Page 5] Internet-Draft SSH Public Key File Format March 2006 encoded in UTF-8. [RFC3629] 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.) 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. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted. Compliant implementations MUST function correctly if the quotation marks are omitted. 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. 3.3.3. Private Use Headers Headers with header-tags beginning with "x-" are reserved for private use. 3.4. Public Key File Body The body of a public-key file is the base64 encoded ([RFC2045]) public-key data as specified by [RFC4253], section 6.6: Galbraith & Thayer Expires September 2, 2006 [Page 6] Internet-Draft SSH Public Key File Format March 2006 string certificate or public key format identifier byte[n] key/certificate data As with all other lines, each line in the body MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implementers should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimiters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 bytes to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires September 2, 2006 [Page 7] Internet-Draft SSH Public Key File Format March 2006 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires September 2, 2006 [Page 8] Internet-Draft SSH Public Key File Format March 2006 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public-key data as specified by [RFC4253]. (This is the same data that is base64 encoded to form the body of the public-key file.) The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires September 2, 2006 [Page 9] Internet-Draft SSH Public Key File Format March 2006 5. IANA Considerations 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]. Galbraith & Thayer Expires September 2, 2006 [Page 10] Internet-Draft SSH Public Key File Format March 2006 6. 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. The public-key fingerprint method presented here relies on the MD5 one-way hash function, which is known to have certain weaknesses regarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance. MD5 is used here for historical reasons. Galbraith & Thayer Expires September 2, 2006 [Page 11] Internet-Draft SSH Public Key File Format March 2006 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires September 2, 2006 [Page 12] Internet-Draft SSH Public Key File Format March 2006 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires September 2, 2006 [Page 13] Internet-Draft SSH Public Key File Format March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Thayer Expires September 2, 2006 [Page 14] --------------090405080108070400040307-- From recovered-from-private-archive Thu Mar 23 23:05:06 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20060226220951.GA24363@chiark.greenend.org.uk> To: ietf-ssh@netbsd.org CC: hartmans-ietf@mit.edu References: <20060226220951.GA24363@chiark.greenend.org.uk> <20060226220951.GA24363@chiark.greenend.org.uk> MIME-Version: 1.0 From: Joseph Galbraith Date: Wed, 01 Mar 2006 08:43:53 -0700 Received: by mail.netbsd.org (Postfix, from userid 0) id 215F563B18E; Wed, 1 Mar 2006 15:43:58 +0000 (UTC) Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 46E4C63B180 for ; Wed, 1 Mar 2006 15:43:57 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8606885; Wed, 01 Mar 2006 08:44:02 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <4405C139.8000403@vandyke.com> 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 recovered-from-private-archive Thu Mar 23 23:05:06 2006 User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii In-Reply-To: <4405C139.8000403@vandyke.com> (Joseph Galbraith's message of "Wed, 01 Mar 2006 08:43:53 -0700") To: Joseph Galbraith Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Sam Hartman References: <20060226220951.GA24363@chiark.greenend.org.uk> <4405C139.8000403@vandyke.com> <4405C139.8000403@vandyke.com> Date: Wed, 01 Mar 2006 14:02:43 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 9B9C463B1E4; Wed, 1 Mar 2006 19:02:52 +0000 (UTC) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id EE45463B129 for ; Wed, 1 Mar 2006 19:02:51 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F2963E006A; Wed, 1 Mar 2006 14:02:43 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: 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 recovered-from-private-archive Thu Mar 23 23:05:06 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org In-Reply-To: Content-Type: text/plain; charset=us-ascii To: ietf-ssh@netbsd.org References: Mime-Version: 1.0 From: Jacob Nevins Date: Thu, 2 Mar 2006 21:52:45 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 5EB3D63B356; Thu, 2 Mar 2006 21:52:47 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 9608763B324 for ; Thu, 2 Mar 2006 21:52:46 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FEvj3-0007PM-00 for ietf-ssh@netbsd.org; Thu, 02 Mar 2006 21:52:45 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060302215245.GA20681@chiark.greenend.org.uk> Sam Hartman writes: > 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. 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: 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]. 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 recovered-from-private-archive Thu Mar 23 23:05:06 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: Joseph Galbraith , Michael Wing MIME-Version: 1.0 From: Joseph Galbraith Date: Thu, 02 Mar 2006 17:48:17 -0700 Received: by mail.netbsd.org (Postfix, from userid 0) id 1F30263B11C; Fri, 3 Mar 2006 00:48:19 +0000 (UTC) Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8864B63B112 for ; Fri, 3 Mar 2006 00:48:18 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8629942; Thu, 02 Mar 2006 17:48:23 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Tracking Numbers... Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <44079251.1070307@vandyke.com> Monitors: 835383799120 835383799110 Computer: 835383799109 Thanks, Joseph From recovered-from-private-archive Thu Mar 23 23:05:06 2006 To: ietf-ssh@netbsd.org In-Reply-To: <20060302215245.GA20681@chiark.greenend.org.uk> References: <20060302215245.GA20681@chiark.greenend.org.uk> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Date: Fri, 03 Mar 2006 22:30:32 +1300 Received: by mail.netbsd.org (Postfix, from userid 0) id A76A663B1EB; Fri, 3 Mar 2006 09:51:57 +0000 (UTC) Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id DAA6563B125 for ; Fri, 3 Mar 2006 09:51:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id F17DE35726 for ; Fri, 3 Mar 2006 22:30:24 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30553-20 for ; Fri, 3 Mar 2006 22:30:24 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id D756A34DDE for ; Fri, 3 Mar 2006 22:30:24 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D32293774E for ; Fri, 3 Mar 2006 22:30:24 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FF6cK-000379-00 for ; Fri, 03 Mar 2006 22:30:32 +1300 Delivered-To: ietf-ssh@netbsd.org Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: Jacob Nevins 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 recovered-from-private-archive Thu Mar 23 23:05:07 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org In-Reply-To: Content-Type: text/plain; charset=us-ascii To: ietf-ssh@netbsd.org References: Mime-Version: 1.0 From: Jacob Nevins Date: Fri, 3 Mar 2006 10:37:41 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 7BDB363B358; Fri, 3 Mar 2006 10:37:43 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id C6ADF63B371 for ; Fri, 3 Mar 2006 10:37:42 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FF7fJ-0002uc-00 for ietf-ssh@netbsd.org; Fri, 03 Mar 2006 10:37:41 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: Re: [(nowhere)] FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060303103741.GA9587@chiark.greenend.org.uk> Peter Gutmann writes: > I'd like to suggest one more, at the end of section 3.2: > > Note that this differs from the widely-used PEM format [...] There's already a whole section (3.5) on this subject. From recovered-from-private-archive Thu Mar 23 23:05:07 2006 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Internet-Drafts@ietf.org Date: Fri, 03 Mar 2006 15:50:01 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id DF60C63B201; Fri, 3 Mar 2006 21:00:45 +0000 (UTC) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by mail.netbsd.org (Postfix) with ESMTP id F21A663B1FA for ; Fri, 3 Mar 2006 21:00:44 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k23Ko1vP022407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFHDt-0005Gj-IY; Fri, 03 Mar 2006 15:50:01 -0500 Delivered-To: ietf-ssh@netbsd.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-12.txt Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: --NextPart 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-12.txt Pages : 14 Date : 2006-3-3 This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-12.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-12.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-3110228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3110228.I-D@ietf.org> --OtherAccess-- --NextPart-- From recovered-from-private-archive Thu Mar 23 23:05:07 2006 Thread-index: AcZAQ8/TnHlItSJwQi++JqsxQoXYFg== Thread-topic: [MailServer Notification]Attachment Blocking Notification X-Mailer: Microsoft CDO for Exchange 2000 Content-type: text/plain; charset=utf-8 To: i-d-announce@ietf.org X-OriginalArrivalTime: 05 Mar 2006 10:59:02.0243 (UTC) FILETIME=[CFF2F330:01C64043] Cc: ietf-ssh@netbsd.org MIME-version: 1.0 From: Administrator@mci.com Date: Sun, 05 Mar 2006 10:59:02 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 1D48663B3B5; Sun, 5 Mar 2006 11:04:07 +0000 (UTC) Received: from omzesmtp01.mci.com (omzesmtp01.mci.com [199.249.17.7]) by mail.netbsd.org (Postfix) with ESMTP id 5F98363B12F for ; Sun, 5 Mar 2006 11:04:06 +0000 (UTC) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IVN00761IIGMT@firewall.mci.com> for ietf-ssh@netbsd.org; Sun, 05 Mar 2006 10:59:05 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0IVN00FGOIIGDP@dgismtp01.mcilink.com> for ietf-ssh@netbsd.org; Sun, 05 Mar 2006 10:59:04 +0000 (GMT) Received: from usashfe001.mcilink.com ([153.39.73.77]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0IVN00F3IIIFE1@dgismtp01.mcilink.com> for ietf-ssh@netbsd.org; Sun, 05 Mar 2006 10:59:04 +0000 (GMT) Received: from usashms003.mcilink.com ([153.39.82.133]) by usashfe001.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 05 Mar 2006 10:59:03 +0000 Received: from mail pickup service by usashms003.mcilink.com with Microsoft SMTPSVC; Sun, 05 Mar 2006 10:59:02 +0000 Delivered-To: ietf-ssh@netbsd.org Content-class: urn:content-classes:message Importance: normal Subject: [MailServer Notification]Attachment Blocking Notification X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-transfer-encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <026101c64043$cfd3f980$85522799@mcilink.com> Warning to Recipient: Action taken by attachment blocking. From recovered-from-private-archive Thu Mar 23 23:05:07 2006 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on basm.cerias.purdue.edu Content-Type: TEXT/PLAIN; charset=US-ASCII To: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Cristina Nita-Rotaru X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on basm.cerias.purdue.edu Date: Sun, 5 Mar 2006 22:50:17 -0500 (EST) X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: by mail.netbsd.org (Postfix, from userid 0) id 4C0D963B1CD; Mon, 6 Mar 2006 03:55:32 +0000 (UTC) Received: from basm.cerias.purdue.edu (basm.cerias.purdue.edu [128.10.243.21]) by mail.netbsd.org (Postfix) with ESMTP id D02AC63B181 for ; Mon, 6 Mar 2006 03:55:30 +0000 (UTC) Received: from basm.cerias.purdue.edu (crisn@localhost [127.0.0.1]) by basm.cerias.purdue.edu (8.13.4/8.13.4/PURDUE_CERIAS-2.0) with ESMTP id k263oHlq018797 for ; Sun, 5 Mar 2006 22:50:18 -0500 (EST) Received: from localhost (crisn@localhost) by basm.cerias.purdue.edu (8.13.4/8.13.4/Submit) with ESMTP id k263oHSR018793 for ; Sun, 5 Mar 2006 22:50:17 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org X-Virus-Status: Clean Subject: CFP: SecureComm 2006 [abstract due March 24] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: Dear Colleague, Please find attached the call for participation for the Second IEEE Communications Society/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2006) to be held in Baltimore, MD from Aug. 28 to Sept. 1, 2006. The complete information is available on the website: www.securecomm.org We apologize if you receive multiple copies of this message. Please feel free to distribute this to colleagues who might be interested. Best Regards, SecureComm 2006 Organizing Committee ******************************************************************* CALL FOR PAPERS SecureComm 2006 Second IEEE Communications Society/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks Baltimore, MD, USA, Aug. 28 - Sep. 1, 2006 URL: http://www.securecomm.org CO-SPONSORED BY: IEEE Communications Society (www.comsoc.org) CreateNet (www.create-net.it) In Cooperation with ACM SIGSAC ******************************************************************* The scope of Securecomm 2006 has been broadened since the inaugural 2005 event. Topics of interest encompass research advances in ALL areas of secure communications and networking. Topics in other areas (e.g., formal methods, database security, secure OS/software, theoretical cryptography, e-commerce) will be considered only if a clear connection to privacy and/or security in communication/networking is demonstrated. Securecomm aims to bring together security and privacy experts in academia, industry and government as well as practitioners, standards developers and policy makers. Securecomm also serves as a venue for learning about state-of-the-art in security and privacy research. Presentations reporting on cutting-edge research results are supplemented by panels on controversial issues and invited talks on timely and important topics. Areas of interest include, but ARE NOT limited to, the following: ----------------------------------------------------------------- * Security & Privacy in Wired, Wireless, Mobile, Hybrid, Sensor, Ad Hoc networks * Network Intrusion Detection and Prevention, DoS Countermeasures * Firewalls, Routers, Filters and Malware detectors * Public Key Infrastructures and Other Security Architectures * Secure Web Communication * Communication Privacy and Anonymity * Secure/Private E-commerce * Secure Routing, Naming/Addressing, Network Management * Security & Privacy in Pervasive and Ubiquitous Computing, e.g., RFIDs PAPERS: Technical papers describing original unpublished research are solicited. Submissions must not be concurrently under review by a conference, journal or any other venue that has proceedings. Authors of the highest-quality accepted papers will be invited to submit extended version of their papers to a special issue of ACM Transactions on Information and System Security (TISSEC). SHORT PAPERS: Continuing with the last year's model, in addition to full papers, Securecomm 2006 invites submission of pithy concise technical papers (also describing original unpublished research). Such papers may represent work-in-progress or small -- yet novel -- research results that do not warrant a full paper. SUBMISSION INSTRUCTIONS: Only PostScript or PDF formats are accepted for all submissions. Full paper submissions must not exceed 10 pages in IEEE conference style, two-column format, not including the bibliography. Well-marked appendices of up to 2 pages are allowed but will be read only at the discretion of reviewers. Short paper submissions are limited to 4 pages total. IEEE Communications Society and Create-Net policy states that all accepted SecureComm 2006 papers must have at least one registration at the regular rate. For authors co-authoring multiple papers, one regular registration is valid for up to two papers. All submitted papers will be judged based on their quality through *double-blind* reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Complete paper submission instructions will be available at the conference website. The Title/Abstract MUST be registered by March 24, 11.50PM PST and final paper uploaded by April 1, 2006, 11.50PM PST. PANELS: Panels that examine innovative, controversial, or otherwise provocative issues of interest are solicited. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should submit proposals to the Panels Co-Chairs by March 18, 2006. WORKSHOPS: Workshop proposals on topics related to the broader theme of the conference are solicited. Workshop proposals should not exceed 3 pages, including biographical sketches of the main organizers, completed description of the workshop topic and its potential interest to the community and relevance to Securecomm, and a detailed draft CFP. Potential workshop organizers should submit proposals to the Workshops Chair by February 1, 2006. RESEARCH DEMOS: Informal proposals for research demos are solicited. Proposals will be reviewed and selection will be made based on the perceived value to the research community and interest level for the conference attendees. Proposals should not exceed 3 pages and should include: the focus area, technologies involved, specific equipment to be used, demo layout and space required. Please submit proposals to the Research Demos Chair(s) by June 1, 2006. IMPORTANT DATES --------------- TECHNICAL Paper submissions due: March 24, 2006 (Title/Abstract) April 1, 2006 (Full Paper) NOTIFICATION date: May 31, 2006 Camera-ready version due: June 24, 2006 Conference Dates: Aug. 28 - Sep. 1, 2006 For information regarding the conference, please visit http://www.securecomm.org or contact one of the Chairs below. CONFERENCE ORGANIZING COMMITTEE General Co-Chairs ----------------- Mukesh Singhal, University of Kentucky, singhal@cs.uky.edu John Baras, University of Maryland, College Park, baras@isr.umd.edu Technical Program Co-Chairs --------------------------- Steve Kent, BBN, kent@bbn.com Gene Tsudik, UC Irvine, gts@ics.uci.edu Workshops Chair --------------- G. Manimaran, Iowa State University, gmani@iastate.edu Panels Co-Chairs ---------------- Bruno Crispo, Vrije Universiteit, Netherlands, crispo@few.vu.nl Avishai Wool, Technion, Israel, yash@eng.tau.ac.il Research Demos/Exhibits Chair ----------------------------- Tom Karygiannis, NIST, karygiannis@nist.gov Sponsorships Chair ------------------ Byrav Ramamurthy, University of Nebraska, Lincoln, byrav@cse.unl.edu Publicity Co-Chairs ------------------- Peng Liu, Penn State University, pliu@ist.psu.edu Cristina Nita-Rotaru, Purdue University, crisn@cs.purdue.edu Publication Chair ----------------- Farooq Anjum, Telcordia Technologies, fanjum@telcordia.com Steering Committee: ------------------- Imrich Chlamtac (Chair), Create-Net Krishna M. Sivalingam (Co-Chair), University of Maryland, Baltimore County Gene Tsudik, University of California, Irvine Brian Bigalke, (Staff Liaison, IEEE Communications Society) TECHNICAL PROGRAM COMMITTEE ------------------------------------------- N. Asokan Nokia Research Giuseppe Ateniese Johns Hopkins University Tuomas Aura Microsoft Research Dirk Balfanz PARC Bharat Bhargava Purdue Matt Bishop University of California, Davis Levente Buttyan Budapest University of Technology Srdjan Capkun Technical University of Denmark Claude Castelluccia Inria Rhone-Alpes Tom Chen Southern Methodist University Bruno Crispo Vrije Universitet Breno de Medeiros University of Central Florida Robert Deng Singapore Management University Xuhua Ding Singapore Management University Glenn Durfee PARC Bao Feng Institute for Infocomm Research Dieter Gollmann Technical University of Hamburg-Harb Richard Han University of Colorado at Boulder Tom Karygiannis NIST Yongdae Kim University of Minnessota Christopher Kruegel Technical University of Vienna Kwok-Yan Lam Tsinghua University Brian LaMacchia Microsoft Carl Landwehr University of Maryland Wenke Lee Georgia Tech Albert Levi Sabanci University, Ninghui Li Purdue Peng Liu Pennsylvania State University Luigi Mancini Unversity of Rome - La Sapienza Fabio Massacci University of Trento Ludovic Me' Supelec Pietro Michiardi Eurecom Institute Refik Molva Eurecom Institute Mats Naslund Ericsson Research Pekka Nikander Ericsson Nomadiclab Cristina Nita-Rotaru Purdue Radha Poovendran University of Washington Byrav Ramamurthy University of Nebraska-Lincoln Michael Roe Microsoft Research Sanjeev Setia George Mason University Cliff Wang Army Research Laboratory Helen Wang Microsoft Research Ron Watro BBN Dirk Westhoff NEC Research Susanne Wetzel Stevens Institute of Technology Avishai Wool Tel Aviv University Shouhuai Xu University of Texas, San Antonio Xiaowei Yang University of California, Irvine Bulent Yener Rensselauer Polytechnic Institute Jeong Hyun Yi Samsung Advanced Institute of Technology Jianying Zhou Institute for Infocomm Research Alf Zugenmaier DoCoMo Labs ************************************************************************ From recovered-from-private-archive Thu Mar 23 23:05:07 2006 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on basm.cerias.purdue.edu Content-Type: TEXT/PLAIN; charset=US-ASCII To: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Cristina Nita-Rotaru X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on basm.cerias.purdue.edu Date: Sun, 5 Mar 2006 22:49:50 -0500 (EST) X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: by mail.netbsd.org (Postfix, from userid 0) id 713D163B1D6; Mon, 6 Mar 2006 04:10:38 +0000 (UTC) Received: from basm.cerias.purdue.edu (basm.cerias.purdue.edu [128.10.243.21]) by mail.netbsd.org (Postfix) with ESMTP id 00BAB63B1A0 for ; Mon, 6 Mar 2006 04:10:36 +0000 (UTC) Received: from basm.cerias.purdue.edu (crisn@localhost [127.0.0.1]) by basm.cerias.purdue.edu (8.13.4/8.13.4/PURDUE_CERIAS-2.0) with ESMTP id k263nonn018759 for ; Sun, 5 Mar 2006 22:49:50 -0500 (EST) Received: from localhost (crisn@localhost) by basm.cerias.purdue.edu (8.13.4/8.13.4/Submit) with ESMTP id k263noST018755 for ; Sun, 5 Mar 2006 22:49:50 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org X-Virus-Status: Clean Subject: CFP: SecureComm 2006 [abstract due March 24] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: Dear Colleague, Please find attached the call for participation for the Second IEEE Communications Society/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2006) to be held in Baltimore, MD from Aug. 28 to Sept. 1, 2006. The complete information is available on the website: www.securecomm.org We apologize if you receive multiple copies of this message. Please feel free to distribute this to colleagues who might be interested. Best Regards, SecureComm 2006 Organizing Committee ******************************************************************* CALL FOR PAPERS SecureComm 2006 Second IEEE Communications Society/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks Baltimore, MD, USA, Aug. 28 - Sep. 1, 2006 URL: http://www.securecomm.org CO-SPONSORED BY: IEEE Communications Society (www.comsoc.org) CreateNet (www.create-net.it) In Cooperation with ACM SIGSAC ******************************************************************* The scope of Securecomm 2006 has been broadened since the inaugural 2005 event. Topics of interest encompass research advances in ALL areas of secure communications and networking. Topics in other areas (e.g., formal methods, database security, secure OS/software, theoretical cryptography, e-commerce) will be considered only if a clear connection to privacy and/or security in communication/networking is demonstrated. Securecomm aims to bring together security and privacy experts in academia, industry and government as well as practitioners, standards developers and policy makers. Securecomm also serves as a venue for learning about state-of-the-art in security and privacy research. Presentations reporting on cutting-edge research results are supplemented by panels on controversial issues and invited talks on timely and important topics. Areas of interest include, but ARE NOT limited to, the following: ----------------------------------------------------------------- * Security & Privacy in Wired, Wireless, Mobile, Hybrid, Sensor, Ad Hoc networks * Network Intrusion Detection and Prevention, DoS Countermeasures * Firewalls, Routers, Filters and Malware detectors * Public Key Infrastructures and Other Security Architectures * Secure Web Communication * Communication Privacy and Anonymity * Secure/Private E-commerce * Secure Routing, Naming/Addressing, Network Management * Security & Privacy in Pervasive and Ubiquitous Computing, e.g., RFIDs PAPERS: Technical papers describing original unpublished research are solicited. Submissions must not be concurrently under review by a conference, journal or any other venue that has proceedings. Authors of the highest-quality accepted papers will be invited to submit extended version of their papers to a special issue of ACM Transactions on Information and System Security (TISSEC). SHORT PAPERS: Continuing with the last year's model, in addition to full papers, Securecomm 2006 invites submission of pithy concise technical papers (also describing original unpublished research). Such papers may represent work-in-progress or small -- yet novel -- research results that do not warrant a full paper. SUBMISSION INSTRUCTIONS: Only PostScript or PDF formats are accepted for all submissions. Full paper submissions must not exceed 10 pages in IEEE conference style, two-column format, not including the bibliography. Well-marked appendices of up to 2 pages are allowed but will be read only at the discretion of reviewers. Short paper submissions are limited to 4 pages total. IEEE Communications Society and Create-Net policy states that all accepted SecureComm 2006 papers must have at least one registration at the regular rate. For authors co-authoring multiple papers, one regular registration is valid for up to two papers. All submitted papers will be judged based on their quality through *double-blind* reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Complete paper submission instructions will be available at the conference website. The Title/Abstract MUST be registered by March 24, 11.50PM PST and final paper uploaded by April 1, 2006, 11.50PM PST. PANELS: Panels that examine innovative, controversial, or otherwise provocative issues of interest are solicited. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should submit proposals to the Panels Co-Chairs by March 18, 2006. WORKSHOPS: Workshop proposals on topics related to the broader theme of the conference are solicited. Workshop proposals should not exceed 3 pages, including biographical sketches of the main organizers, completed description of the workshop topic and its potential interest to the community and relevance to Securecomm, and a detailed draft CFP. Potential workshop organizers should submit proposals to the Workshops Chair by February 1, 2006. RESEARCH DEMOS: Informal proposals for research demos are solicited. Proposals will be reviewed and selection will be made based on the perceived value to the research community and interest level for the conference attendees. Proposals should not exceed 3 pages and should include: the focus area, technologies involved, specific equipment to be used, demo layout and space required. Please submit proposals to the Research Demos Chair(s) by June 1, 2006. IMPORTANT DATES --------------- TECHNICAL Paper submissions due: March 24, 2006 (Title/Abstract) April 1, 2006 (Full Paper) NOTIFICATION date: May 31, 2006 Camera-ready version due: June 24, 2006 Conference Dates: Aug. 28 - Sep. 1, 2006 For information regarding the conference, please visit http://www.securecomm.org or contact one of the Chairs below. CONFERENCE ORGANIZING COMMITTEE General Co-Chairs ----------------- Mukesh Singhal, University of Kentucky, singhal@cs.uky.edu John Baras, University of Maryland, College Park, baras@isr.umd.edu Technical Program Co-Chairs --------------------------- Steve Kent, BBN, kent@bbn.com Gene Tsudik, UC Irvine, gts@ics.uci.edu Workshops Chair --------------- G. Manimaran, Iowa State University, gmani@iastate.edu Panels Co-Chairs ---------------- Bruno Crispo, Vrije Universiteit, Netherlands, crispo@few.vu.nl Avishai Wool, Technion, Israel, yash@eng.tau.ac.il Research Demos/Exhibits Chair ----------------------------- Tom Karygiannis, NIST, karygiannis@nist.gov Sponsorships Chair ------------------ Byrav Ramamurthy, University of Nebraska, Lincoln, byrav@cse.unl.edu Publicity Co-Chairs ------------------- Peng Liu, Penn State University, pliu@ist.psu.edu Cristina Nita-Rotaru, Purdue University, crisn@cs.purdue.edu Publication Chair ----------------- Farooq Anjum, Telcordia Technologies, fanjum@telcordia.com Steering Committee: ------------------- Imrich Chlamtac (Chair), Create-Net Krishna M. Sivalingam (Co-Chair), University of Maryland, Baltimore County Gene Tsudik, University of California, Irvine Brian Bigalke, (Staff Liaison, IEEE Communications Society) TECHNICAL PROGRAM COMMITTEE ------------------------------------------- N. Asokan Nokia Research Giuseppe Ateniese Johns Hopkins University Tuomas Aura Microsoft Research Dirk Balfanz PARC Bharat Bhargava Purdue Matt Bishop University of California, Davis Levente Buttyan Budapest University of Technology Srdjan Capkun Technical University of Denmark Claude Castelluccia Inria Rhone-Alpes Tom Chen Southern Methodist University Bruno Crispo Vrije Universitet Breno de Medeiros University of Central Florida Robert Deng Singapore Management University Xuhua Ding Singapore Management University Glenn Durfee PARC Bao Feng Institute for Infocomm Research Dieter Gollmann Technical University of Hamburg-Harb Richard Han University of Colorado at Boulder Tom Karygiannis NIST Yongdae Kim University of Minnessota Christopher Kruegel Technical University of Vienna Kwok-Yan Lam Tsinghua University Brian LaMacchia Microsoft Carl Landwehr University of Maryland Wenke Lee Georgia Tech Albert Levi Sabanci University, Ninghui Li Purdue Peng Liu Pennsylvania State University Luigi Mancini Unversity of Rome - La Sapienza Fabio Massacci University of Trento Ludovic Me' Supelec Pietro Michiardi Eurecom Institute Refik Molva Eurecom Institute Mats Naslund Ericsson Research Pekka Nikander Ericsson Nomadiclab Cristina Nita-Rotaru Purdue Radha Poovendran University of Washington Byrav Ramamurthy University of Nebraska-Lincoln Michael Roe Microsoft Research Sanjeev Setia George Mason University Cliff Wang Army Research Laboratory Helen Wang Microsoft Research Ron Watro BBN Dirk Westhoff NEC Research Susanne Wetzel Stevens Institute of Technology Avishai Wool Tel Aviv University Shouhuai Xu University of Texas, San Antonio Xiaowei Yang University of California, Irvine Bulent Yener Rensselauer Polytechnic Institute Jeong Hyun Yi Samsung Advanced Institute of Technology Jianying Zhou Institute for Infocomm Research Alf Zugenmaier DoCoMo Labs ************************************************************************ From recovered-from-private-archive Thu Mar 23 23:05:07 2006 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Internet-Drafts@ietf.org Date: Tue, 07 Mar 2006 02:50:01 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id C7E5363B272; Tue, 7 Mar 2006 07:58:00 +0000 (UTC) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mail.netbsd.org (Postfix) with ESMTP id CCDE363B275 for ; Tue, 7 Mar 2006 07:57:59 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k277o1BX025943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGWxF-0002jL-M9; Tue, 07 Mar 2006 02:50:01 -0500 Delivered-To: ietf-ssh@netbsd.org Subject: I-D ACTION:draft-ietf-secsh-x509-03.txt Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: --NextPart 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 : X.509 authentication in SSH Author(s) : O. Saarenmaa, J. Galbraith Filename : draft-ietf-secsh-x509-03.txt Pages : 10 Date : 2006-3-6 This document specifies how X.509 certificates and signatures are used within the Secure Shell protocol for user and server authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-x509-03.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-x509-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6192903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-x509-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-x509-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6192903.I-D@ietf.org> --OtherAccess-- --NextPart-- From recovered-from-private-archive Thu Mar 23 23:05:07 2006 User-Agent: Thunderbird 1.5 (X11/20060313) Content-Type: text/plain; charset=ISO-8859-1 To: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Oskari Saarenmaa Date: Wed, 15 Mar 2006 16:51:00 -0800 Received: by mail.netbsd.org (Postfix, from userid 0) id 4374B63B282; Thu, 16 Mar 2006 01:11:15 +0000 (UTC) Received: from fsmail-out.f-secure.com (fsmail-out.f-secure.com [193.110.109.20]) by mail.netbsd.org (Postfix) with ESMTP id 5262463B111 for ; Thu, 16 Mar 2006 01:11:14 +0000 (UTC) Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 391E15BAB7 for ; Thu, 16 Mar 2006 02:51:22 +0200 (EET) Received: from fsintra.f-secure.com (fsintra.f-secure.com [10.128.128.79]) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.50.59 Release) with SMTP; Thu, 16 Mar 2006 00:51:21 -0000 (envelope-from ) Received: from [127.0.0.1] (info.f-secure.com [193.110.108.50]) by fsintra.f-secure.com (Postfix) with ESMTP id 702C05BD5F for ; Thu, 16 Mar 2006 02:51:20 +0200 (EET) Delivered-To: ietf-ssh@netbsd.org Subject: Comments on draft-ietf-secsh-x509-03 Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <4418B674.1020402@f-secure.com> X-Enigmail-Version: 0.93.2.0 Some comments on the new x509 draft based on off-list emails and discussions at IETF-64 and Connectathon: The reason for including OCSP responses in "x509v3-sign" was that the peer might not have access to (or might not want to access) the OCSP or CRL server if it is behind a firewall for example. OCSP responses are signed, so the peer can trust them, but we should add some text to security considerations about this. The signature format for "x509v3-sign" needs to be specified in more detail, specifically the OID is an US-ASCII text representation of the identifier, and the signature is encoded as specified in RFC 3279. "x509v3-sign-rsa-sha1" and "x509v3-sign-dss-sha1" formats could be dropped, the only argument for defining them was that they are pretty close to what many implementations did before any of the x509/ssh stuff was documented. But as they're just "pretty close to" existing implementations, defining them with new names and slightly different formats won't buy any interoperability and only adds redundancy. There were also some concerns that we might not actually need three different EKUs for SSH, and should define just one or two. As I see it there are three pretty distinctive ways to use certificates in SSH so each of them could use their own EKU definition, but I have no strong feelings about the issue. Any comments/feedback are welcome. Cheers, Oskari From recovered-from-private-archive Thu Mar 23 23:05:07 2006 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Content-Type: text/plain; charset=us-ascii; format=flowed In-Reply-To: <4418B674.1020402@f-secure.com> To: Oskari Saarenmaa CC: ietf-ssh@netbsd.org References: <4418B674.1020402@f-secure.com> <4418B674.1020402@f-secure.com> MIME-Version: 1.0 From: Roumen Petrov X-Accept-Language: bg, ru, de-de, de, en-us, en Date: Fri, 17 Mar 2006 00:15:16 +0200 Received: by mail.netbsd.org (Postfix, from userid 0) id 74ECA63B109; Thu, 16 Mar 2006 22:43:05 +0000 (UTC) Received: from mail.host.bg (mail.host.bg [87.120.40.5]) by mail.netbsd.org (Postfix) with ESMTP id 7E68463B158 for ; Thu, 16 Mar 2006 22:43:04 +0000 (UTC) Received: from [85.130.38.35] (85-130-38-35.1699525.ddns.cablebg.net [85.130.38.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.host.bg (Postfix) with ESMTP id 7BD401632F9; Fri, 17 Mar 2006 00:14:30 +0200 (EET) Delivered-To: ietf-ssh@netbsd.org Subject: Re: Comments on draft-ietf-secsh-x509-03 Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <4419E374.8020804@roumenpetrov.info> Oskari Saarenmaa wrote: > Some comments on the new x509 draft based on off-list emails and > discussions at IETF-64 and Connectathon: > > [SNIP] The signature format for > "x509v3-sign" needs to be specified in more detail, specifically the OID > is an US-ASCII text representation of the identifier, and the signature > is encoded as specified in RFC 3279. May be the signature format should be part of public key algorithm name. The client shouldn't guess which signature format is supported by server and shouldn't send blindly signed authentication request. Other possibility is to extend 'public key authentication method' with new message[s]. May be a new response SSH_MSG_USERAUTH_X509_OK: byte SSH_MSG_USERAUTH_X509_OK string public key algorithm name from the request, i.e. "x509v3-sign" string public key blob from the request name-list signature algorithms supported by server. In first case we should define many names without to change protocol, but the client should send a certificate with diferent algorithm names until server accept one or reject all. Then client can begin with next certificate and so on and so forth. In second case is with just one name, but require protocol changes. :-\ May be SHA1 algorithm is sufficient. The problem with hash algorithms exist for rsa/dss keys too. Regards, Roumen Petrov From recovered-from-private-archive Thu Mar 23 23:05:07 2006 Received: by mail.netbsd.org (Postfix, from userid 0) id ADCF663B16E; Thu, 16 Mar 2006 23:12:58 +0000 (UTC) Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by mail.netbsd.org (Postfix) with ESMTP id AC0DF63B114 for ; Thu, 16 Mar 2006 23:12:57 +0000 (UTC) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id k2GNCuWV031398; Thu, 16 Mar 2006 15:12:56 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id k2GNCu6T031397; Thu, 16 Mar 2006 15:12:56 -0800 Delivered-To: ietf-ssh@netbsd.org Subject: RFC 4419 on Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol Precedence: list To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org From: rfc-editor@rfc-editor.org Date: Thu, 16 Mar 2006 15:12:56 -0800 X-Original-To: ietf-ssh@netbsd.org Message-ID: <200603162312.k2GNCu6T031397@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4419 Title: Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol Author: M. Friedl, N. Provos, W. Simpson Status: Standards Track Date: March 2006 Mailbox: markus@openbsd.org, provos@citi.umich.edu, wsimpson@greendragon.com Pages: 10 Characters: 18356 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-dh-group-exchange-05.txt URL: http://www.rfc-editor.org/rfc/rfc4419.txt This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From recovered-from-private-archive Thu Mar 23 23:05:07 2006 To: ietf-ssh@netbsd.org, oskari.saarenmaa@f-secure.com In-Reply-To: <4418B674.1020402@f-secure.com> References: <4418B674.1020402@f-secure.com> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Date: Mon, 20 Mar 2006 16:11:00 +1200 Received: by mail.netbsd.org (Postfix, from userid 0) id 4BE3B63B373; Mon, 20 Mar 2006 04:31:50 +0000 (UTC) Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id F193163B371 for ; Mon, 20 Mar 2006 04:31:48 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id DA582347D5; Mon, 20 Mar 2006 16:10:55 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19991-26; Mon, 20 Mar 2006 16:10:55 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id B1374344CC; Mon, 20 Mar 2006 16:10:55 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8B40637752; Mon, 20 Mar 2006 16:10:55 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FLBjQ-0002gT-00; Mon, 20 Mar 2006 16:11:00 +1200 Delivered-To: ietf-ssh@netbsd.org Subject: Re: Comments on draft-ietf-secsh-x509-03 Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: Oskari Saarenmaa writes: >Any comments/feedback are welcome. I have some comments (these may be best read to the sound of an Alka-seltzer fizzing in a glass :-). Section 3.1.1 is self-contradicting, first there's a paragraph saying you shouldn't use eKU, and then the following paragraph tells you what to set eKU to. Is this an editing error where one of the two paragraphs was supposed to have been removed, or was it deliberate? If it's deliberate, why are there two contradicting requirements? Wouldn't it be better to use the existing, universally-implemented client/serverAuth eKU's instead of inventing new, incompatible ones? The latter strategy practically guarantees that they'll never see support in any mainstream PKI software, which kind of defeats the point of using standard X.509 certs to contain the keys. Section 4's use of OCSP is IMHO a bad move, it hard-codes a particular revocation-checking mechanism into the exchange while excluding all others. What if you're using CRLs for checking? What about signed attestations? The explicit hardcoding of OCSP constrains implementors into a single mechanism for checking, and excludes all others. In addition, much of this section seems to be reinventing the wheel that the TLS folks spent ages thrashing out. From the history of TLS, it's going to take endless tweaks and revisions to get this into a form where it works for all users. Since what's being done here is identical to what TLS does, except for a minor difference in encoding (TLS uses uint24's instead of uint32's for lengths, otherwise the two formats are identical), it would be better to simply refer to the TLS sections that cover this same material and build on the experience they've gained with this. The algorithm-encoding in section 4 is also a bad move. Firstly, it's incompatible with the existing well-established SSH method for doing this, so you now need to implement two parallel and incompatible algorithm-encoding methods, one for all of SSH except SSH-with-X.509, and another for SSH-with- X.509 only. In addition since there are vast numbers of redundant OIDs (there's half a dozen or more for SHA-1 alone), you'd need to provide a central registry in the SSH docs for each allowed value, in which case you're simply duplicating the existing (non-OID) SSH algorithm registry. Finally, the dotted form for text-mode OIDs is incorrect, this is an aberration found in some IETF texts but isn't valid ASN.1. The correct form has spaces, not dots. (The fact that this error has made it into the spec is an example of why using OIDs is not a good idea, just stick with the standard SSH algorithm IDs). Section 5 should probably be removed, like the OCSP use it seems to hardcode a pile of arbitrary restrictions on usage on the use of X.509 certs in SSH. Why do you need to verify the full chain? Even the PKIX spec never requires this, it merely requires verification up to a trust anchor. If you have an explicitly trusted EE cert, you don't need to look at the other certs at all. In addition if you subscribe to some of the more peculiar ideas in PKIX, the concept of a "chain" doesn't really exist any more since you're now dealing with a full graph with unpredictable semantics. The requirement to refuse a cert if no OCSP responses are included extends the comment I made about section 4, this *forces* you to use OCSP, whether you want to, or whether it's appropriate, or not. This section really doesn't have any place in this document, how an implementation handles the certificates it receives is purely a local policy issue . Overall I think this document should restrict itself to specifying the basic formats, and leave cert-processing details and policy issues to things like PKIX, who have generated thousands of pages (literally!) of documentation on this. Also, since what's being done here is identical to what TLS has spent several years working on, re-using the results of the TLS work would help avoid the need to re-work the SSH stuff once people start rediscovering the various issues that the TLS folks have already dealt with. Peter. From recovered-from-private-archive Thu Mar 23 23:05:07 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: To: Peter Gutmann CC: ietf-ssh@netbsd.org, oskari.saarenmaa@f-secure.com References: MIME-Version: 1.0 From: Joseph Galbraith Date: Mon, 20 Mar 2006 09:41:58 -0700 Received: by mail.netbsd.org (Postfix, from userid 0) id A4E8663B193; Mon, 20 Mar 2006 16:38:04 +0000 (UTC) Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id E644C63B174 for ; Mon, 20 Mar 2006 16:38:03 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8701485; Mon, 20 Mar 2006 09:38:03 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Re: Comments on draft-ietf-secsh-x509-03 Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <441EDB56.5040900@vandyke.com> > Overall I think this document should restrict itself to specifying the basic > formats, and leave cert-processing details and policy issues to things like > PKIX, who have generated thousands of pages (literally!) of documentation on > this. Also, since what's being done here is identical to what TLS has spent > several years working on, re-using the results of the TLS work would help > avoid the need to re-work the SSH stuff once people start rediscovering the > various issues that the TLS folks have already dealt with. This was our original intent (and if you look at the first couple of versions of the document, what we did.) However, it seemed like people wanted more out of the draft. I'd be really happy to go back to simply describing how to encode x.509 certificates and signatures in the SSH protocol and call this draft done. But-- I guess we need people who care about this to come out of the woodwork and speak up now about what the working group wants out of this document. Thanks, Joseph From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Received: by mail.netbsd.org (Postfix, from userid 0) id B0DF563B1B9; Mon, 20 Mar 2006 17:18:38 +0000 (UTC) Received: from carter-zimmerman.mit.edu (unknown [IPv6:2001:df8:0:128:20e:9bff:fecf:3248]) by mail.netbsd.org (Postfix) with ESMTP id 029D763B1B7 for ; Mon, 20 Mar 2006 17:18:37 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A6A69E0053; Mon, 20 Mar 2006 12:09:38 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org Subject: draft-ietf-secsh-publicfile must be dealt with this week or it will not be published Precedence: list Content-Type: text/plain; charset=us-ascii To: ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org MIME-Version: 1.0 From: Sam Hartman Date: Mon, 20 Mar 2006 12:09:38 -0500 X-Original-To: ietf-ssh@netbsd.org Message-ID: Folks, I had indicated that publickfile needed to be dealt with by March. I was unaware of a process issue that makes this even more critical than I had expected. If the document is not approved by Friday it would need to come back on a telechat and receive additional reviews before it could be approved. So, publickeyfile needs to be dealt with this week or I will withdraw my sponsorship of the document and remove it from the publication process. I strongly recommend that people interested in seeing this document get published work with IANA at their office hours to find text acceptable to IANA. You should coordinate with the authors and WG, but the people doing the work need not be the authors. From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org In-Reply-To: <200602102119.k1ALJaMx013767@g13.icann.org> Content-Type: text/plain; charset=us-ascii To: iana-drafts@icann.org Cc: ietf-ssh@netbsd.org References: <200602102119.k1ALJaMx013767@g13.icann.org> Mime-Version: 1.0 From: Jacob Nevins Date: Mon, 20 Mar 2006 20:26:45 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 2D3BB63B17F; Mon, 20 Mar 2006 20:26:47 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 56EDC63B11D for ; Mon, 20 Mar 2006 20:26:46 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FLQxh-0003JH-00; Mon, 20 Mar 2006 20:26:45 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: Re: FW: Please re-review draft-ietf-secsh-publickeyfile [I06-050928-0006] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060320202645.GA19226@chiark.greenend.org.uk> Michelle writes: > However, the IANA Considerations section still needs work. There is not > much detail regarding what type of registry, are these values, what are > the registration procedures, etc. > > If you need for me to look at a new version of the IANA Considerations > section, please let me know. Sam Hartman tells us (the SECSH WG) that this document needs to reach closure by this Friday. Therefore, as a matter of some urgency, can you review this proposed "IANA considerations" section (relative to ) and let us know whether it does what you need, so that we can progress the document?: 5. IANA Considerations Section 3.3 defines a new namespace of "Header-tags". These are US- ASCII strings of maximum length 64 characters, and are case- insensitive. 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]. (In addition, we know we need to make the [RFC2434] reference normative.) Thanks in advance. From recovered-from-private-archive Thu Mar 23 23:05:08 2006 To: galb-list@vandyke.com, pgut001@cs.auckland.ac.nz In-Reply-To: <441EDB56.5040900@vandyke.com> Cc: ietf-ssh@netbsd.org, oskari.saarenmaa@f-secure.com References: <441EDB56.5040900@vandyke.com> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Date: Tue, 21 Mar 2006 23:09:31 +1200 Received: by mail.netbsd.org (Postfix, from userid 0) id AC36663B10F; Tue, 21 Mar 2006 11:09:26 +0000 (UTC) Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id D95B463B11A for ; Tue, 21 Mar 2006 11:09:25 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 2606B343CB; Tue, 21 Mar 2006 23:09:24 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09271-17; Tue, 21 Mar 2006 23:09:24 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id AA54C34103; Tue, 21 Mar 2006 23:09:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8410B37757; Tue, 21 Mar 2006 23:09:23 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FLejz-00065X-00; Tue, 21 Mar 2006 23:09:31 +1200 Delivered-To: ietf-ssh@netbsd.org Subject: Re: Comments on draft-ietf-secsh-x509-03 Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: Joseph Galbraith writes: >This was our original intent (and if you look at the first couple of versions >of the document, what we did.) Yeah, I wondered why it'd changed so suddenly. >I'd be really happy to go back to simply describing how to encode x.509 >certificates and signatures in the SSH protocol and call this draft done. > >But-- I guess we need people who care about this to come out of the woodwork >and speak up now about what the working group wants out of this document. I'd prefer to just have the format documented and call it done. Fiddling with certificate-management policy is something that other WGs have spent (literally) years over, and reached consensus only in the sense that everyone was equally unhappy with the result... I'd say document the bits on the wire, and leave the policy side to someone else to write up in their own draft. Peter. From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=us-ascii To: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Jacob Nevins Date: Wed, 22 Mar 2006 14:33:44 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 6D75A63B283; Wed, 22 Mar 2006 14:33:46 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 9520D63B127 for ; Wed, 22 Mar 2006 14:33:45 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FM4PA-00064k-00 for ietf-ssh@netbsd.org; Wed, 22 Mar 2006 14:33:44 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: [galb@vandyke.com: Re: draft-ietf-secsh-publickeyfile] Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060322143344.GA17803@chiark.greenend.org.uk> Joseph is having trouble posting to the list, so I'm sending this message on his behalf: ----- Forwarded message from Joseph Galbraith ----- From: Joseph Galbraith To: Jacob Nevins Subject: Re: draft-ietf-secsh-publickeyfile Date: Tue, 21 Mar 2006 17:24:15 -0700 Jacob Nevins wrote: > As you may have seen on ietf-ssh, Sam Hartman says this document will > get knocked back if it hasn't shown progress by Friday. (Quite how much > progress, I'm not sure.) I'm keen for it to get published, since it's > widely used and there's nothing fundamentally wrong with it. Yes I saw it; I incorporated your changes, excepting I used 'requested to create' instead of 'required to create' > I've put together revised text for the IANA section (which is I think > all that's needed), and pointed IANA at it by email the day before last > (email CC'd to the list) to see if it addresses their concerns, but had > no reply yet. > > Do you have any way of contacting IANA more directly? Do you know if > phoning them is likely to be useful? I did phone them both yesterday and today, but haven't managed to talk to the right person (which I believe is Michelle Cotton.) I don't have an email address for her and haven't been able to find one on the list either. I actually tried to post this to the mailing list and got bounced with 'greylisting active' or some such :-( > If IANA respond, or indeed if they don't respond soon (say by tomorrow), > it'll be necessary to get a new draft published pronto. Will you be able > to do this? Indeed, can I, technically, and would you have any objection > to my doing so if so? I'll publish tomorrow around noon one way or the other. Thanks, Joseph ----- End forwarded message ----- From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Content-Type: multipart/mixed; boundary="------------010301040702070408030100" To: Internet-Drafts@ietf.org CC: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Joseph Galbraith Date: Wed, 22 Mar 2006 20:59:56 -0700 Received: by mail.netbsd.org (Postfix, from userid 0) id ABCDB63B162; Thu, 23 Mar 2006 03:55:57 +0000 (UTC) Received: from vandyke.com (216.184.10.33.unused.swcp.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 0A41E63B150 for ; Thu, 23 Mar 2006 03:55:54 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8728597; Wed, 22 Mar 2006 20:55:53 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Please publish attached draft-ietf-secsh-publickeyfile-13.txt Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <44221D3C.6000009@vandyke.com> This is a multi-part message in MIME format. --------------010301040702070408030100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------010301040702070408030100 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-13.txt" Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: September 23, 2006 R. Thayer The Tillerman Group March 22, 2006 SSH Public Key File Format draft-ietf-secsh-publickeyfile-13.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 23, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. Galbraith & Thayer Expires September 23, 2006 [Page 1] Internet-Draft SSH Public Key File Format March 2006 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. Private Use Headers . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires September 23, 2006 [Page 2] Internet-Draft SSH Public Key File Format March 2006 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Galbraith & Thayer Expires September 23, 2006 [Page 3] Internet-Draft SSH Public Key File Format March 2006 2. Introduction The SSH protocol supports the use of public/private key pairs in order to perform perform authentication based on public-key cryptography. However, in order to use public-key authentication in the SSH protocol, public keys must first be exchanged between client and server. This document formally describes an existing public-key file format which can be used with any of the common existing file transfer mechanisms in order to exchange public keys. The SSH protocol also uses public/private key pairs to authenticate the server. In this scenario, it is important to verify that the public key provided by the server is indeed the server's public-key. This document describes a mechanism for creating a short text string that uniquely represents a particular public key, called fingerprinting. Galbraith & Thayer Expires September 23, 2006 [Page 4] Internet-Draft SSH Public Key File Format March 2006 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 8-bit bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires September 23, 2006 [Page 5] Internet-Draft SSH Public Key File Format March 2006 encoded in UTF-8. [RFC3629] 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.) 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. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted. Compliant implementations MUST function correctly if the quotation marks are omitted. 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. 3.3.3. Private Use Headers Headers with header-tags beginning with "x-" are reserved for private use. 3.4. Public Key File Body The body of a public-key file is the base64 encoded ([RFC2045]) public-key data as specified by [RFC4253], section 6.6: Galbraith & Thayer Expires September 23, 2006 [Page 6] Internet-Draft SSH Public Key File Format March 2006 string certificate or public key format identifier byte[n] key/certificate data As with all other lines, each line in the body MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implementers should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimiters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 bytes to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires September 23, 2006 [Page 7] Internet-Draft SSH Public Key File Format March 2006 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires September 23, 2006 [Page 8] Internet-Draft SSH Public Key File Format March 2006 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public-key data as specified by [RFC4253]. (This is the same data that is base64 encoded to form the body of the public-key file.) The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires September 23, 2006 [Page 9] Internet-Draft SSH Public Key File Format March 2006 5. IANA Considerations Section 3.3 defines a new namespace of "Header-tags". These are US- ASCII strings of maximum length 64 characters, and are case- insensitive. IANA is requested 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]. Galbraith & Thayer Expires September 23, 2006 [Page 10] Internet-Draft SSH Public Key File Format March 2006 6. 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. The public-key fingerprint method presented here relies on the MD5 one-way hash function, which is known to have certain weaknesses regarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance. MD5 is used here for historical reasons. Galbraith & Thayer Expires September 23, 2006 [Page 11] Internet-Draft SSH Public Key File Format March 2006 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires September 23, 2006 [Page 12] Internet-Draft SSH Public Key File Format March 2006 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires September 23, 2006 [Page 13] Internet-Draft SSH Public Key File Format March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Thayer Expires September 23, 2006 [Page 14] --------------010301040702070408030100-- From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii In-Reply-To: <44221D3C.6000009@vandyke.com> (Joseph Galbraith's message of "Wed, 22 Mar 2006 20:59:56 -0700") To: Joseph Galbraith Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 From: Sam Hartman References: <44221D3C.6000009@vandyke.com> <44221D3C.6000009@vandyke.com> Date: Thu, 23 Mar 2006 09:43:54 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id E43E563B122; Thu, 23 Mar 2006 14:44:02 +0000 (UTC) Received: from carter-zimmerman.mit.edu (unknown [IPv6:2001:df8:0:128:20e:9bff:fecf:3248]) by mail.netbsd.org (Postfix) with ESMTP id 436F963B12B for ; Thu, 23 Mar 2006 14:44:02 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9AF6AE0053; Thu, 23 Mar 2006 09:43:54 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org Subject: Re: Please publish attached draft-ietf-secsh-publickeyfile-13.txt Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: *sigh* I realize that my original message was much less clear than could have been useful. 1) IANA was holding office hours Monday through Wednesday at the meeting. I was really hoping that someone who cared about this draft would physically go talk to IANA. Sadly, it is past Wednesday. 2) Publishing a new draft was not such a good idea. If It comes out today, then we may be OK, but I was really hoping for new text approved by IANA that I could include in an RFC editor note. I believe I've already mentioned once for this draft that new versions should not be submitted without explicit approval of the AD. We'll see what we can do if you can get IANA approval by Friday. From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Thunderbird 1.5 (Windows/20051201) Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: To: Sam Hartman CC: ietf-ssh@netbsd.org References: <44221D3C.6000009@vandyke.com> MIME-Version: 1.0 From: Joseph Galbraith Date: Thu, 23 Mar 2006 09:22:42 -0700 Received: by mail.netbsd.org (Postfix, from userid 0) id C49E863B19A; Thu, 23 Mar 2006 16:18:40 +0000 (UTC) Received: from vandyke.com (216.184.10.33.unused.swcp.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 06D2263B112 for ; Thu, 23 Mar 2006 16:18:39 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8729943; Thu, 23 Mar 2006 09:18:38 -0700 Delivered-To: ietf-ssh@netbsd.org Subject: Re: Please publish attached draft-ietf-secsh-publickeyfile-13.txt Content-Transfer-Encoding: 7bit Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <4422CB52.3010003@vandyke.com> Sam Hartman wrote: > > *sigh* > > I realize that my original message was much less clear than could have > been useful. > > 1) IANA was holding office hours Monday through Wednesday at the > meeting. I was really hoping that someone who cared about this > draft would physically go talk to IANA. Sadly, it is past > Wednesday. Ahh... sorry, I didn't have that option-- not physically in the region. > 2) Publishing a new draft was not such a good idea. If It comes out > today, then we may be OK, but I was really hoping for new text > approved by IANA that I could include in an RFC editor note. > > I believe I've already mentioned once for this draft that new versions > should not be submitted without explicit approval of the AD. I'm sorry... I must not have read that email thoroughly enough. > We'll see what we can do if you can get IANA approval by Friday. I'm not sure if you are asking me to do something else at this point, or just saying if it happens, good, else bad. Is there something I should do at this point? If so, what? Thanks, Joseph From recovered-from-private-archive Thu Mar 23 23:05:08 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=us-ascii To: ietf-action@ietf.org Cc: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Jacob Nevins Date: Thu, 23 Mar 2006 18:39:16 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id C2BEC63B1C2; Thu, 23 Mar 2006 18:39:17 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 1DEC663B15D for ; Thu, 23 Mar 2006 18:39:17 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FMUiK-0002ED-00; Thu, 23 Mar 2006 18:39:16 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: IETF mailing list archive for SECSH WG not being updated Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060323183916.GB6130@chiark.greenend.org.uk> The IETF archive for the SECSH working group mailing list at does not appear to have been updated since February 10. There has been list traffic since then. When this happened before, a WG member said that NetBSD have an archive which can probably be used to fill in any gaps, if necessary. I don't know if that's still true. From recovered-from-private-archive Thu Mar 23 23:05:08 2006 X-RT-Loop-Prevention: Inquiry Reply-To: ietf-action@ietf.org Content-Type: text/plain; charset="utf-8" To: ietf-ssh@netbsd.org Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) In-Reply-To: References: MIME-Version: 1.0 From: "Scott Blomquist via RT" Date: Thu, 23 Mar 2006 15:40:47 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 1FF2463B229; Thu, 23 Mar 2006 21:12:52 +0000 (UTC) Received: from ticket.ietf.org (stiedprtick1.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 7526B63B100 for ; Thu, 23 Mar 2006 21:12:51 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FMWbv-0007DD-2s for ietf-ssh@netbsd.org; Thu, 23 Mar 2006 15:40:47 -0500 X-RT-Original-Encoding: utf-8 Delivered-To: ietf-ssh@netbsd.org Subject: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated RT-Originator: ietf-admin@techsquare.com Precedence: list Sender: ietf-ssh-owner@NetBSD.org RT-Ticket: Inquiry #85608 X-Original-To: ietf-ssh@netbsd.org Message-ID: > [ietf-ssh@netbsd.org - Thu Mar 23 13:49:59 2006]: > > The IETF archive for the SECSH working group mailing list at > > does not appear to have been updated since February 10. There has been > list traffic since then. > > When this happened before, a WG member said that NetBSD have an > archive which can probably be used to fill in any gaps, if necessary. > I don't know if that's still true. > Ok I have re-subscribed an address here. I could not find any text archives. Have any pointers? sb. Scott Blomquist From ietf-ssh-owner@NetBSD.org Fri Mar 24 20:24:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMxVp-0000z1-DF for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 24 Mar 2006 20:24:17 -0500 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMxVo-0004i3-4W for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 24 Mar 2006 20:24:17 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 3B91D63B2A4; Sat, 25 Mar 2006 01:24:15 +0000 (UTC) To: secsh-tyoxbijeg7-archive@lists.ietf.org From: majordomo@NetBSD.org Subject: Welcome to ietf-ssh Reply-To: majordomo@NetBSD.org Message-Id: <20060325012415.3B91D63B2A4@mail.netbsd.org> Date: Sat, 25 Mar 2006 01:24:15 +0000 (UTC) X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb -- Welcome to the ietf-ssh mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ietf-ssh or from another account, besides secsh-tyoxbijeg7-archive@lists.ietf.org: unsubscribe ietf-ssh secsh-tyoxbijeg7-archive@lists.ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: This mailing list hosts the IETF Secure Shell working group, founded to produce an IETF standard based on the popular "SSH" protocol. See http://www.ietf.org/html.charters/secsh-charter.html for more information regarding the working group and the current status of its documents. If you are unfamiliar with the IETF, you should review http://www.ietf.org/overview.html for an overview of the IETF and its standards process. Participation from any interested party is welcome. New subscribers are encouraged to review the recent archives of the list. [This list was formerly hosted at ietf-ssh@clinet.fi, but has been moved here due to reliability problems with the old host.] From recovered-from-private-archive Thu Mar 23 23:50:02 2006 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Internet-Drafts@ietf.org Date: Thu, 23 Mar 2006 18:50:02 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 2E4E563B2A7; Thu, 23 Mar 2006 23:50:05 +0000 (UTC) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by mail.netbsd.org (Postfix) with ESMTP id 41B2163B2A6 for ; Thu, 23 Mar 2006 23:50:03 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2NNo2vP010951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMZZ4-0001EZ-50; Thu, 23 Mar 2006 18:50:02 -0500 Delivered-To: ietf-ssh@netbsd.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-13.txt Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: --NextPart 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-13.txt Pages : 14 Date : 2006-3-23 This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-13.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-13.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-23165528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23165528.I-D@ietf.org> --OtherAccess-- --NextPart-- From recovered-from-private-archive Fri Mar 23 23:55:31 2006 User-Agent: Mutt/1.5.9i Reply-To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=us-ascii To: Scott Blomquist via RT Cc: ietf-ssh@netbsd.org Mime-Version: 1.0 From: Jacob Nevins Date: Thu, 23 Mar 2006 23:55:31 +0000 Received: by mail.netbsd.org (Postfix, from userid 0) id 4742363B2AA; Thu, 23 Mar 2006 23:55:33 +0000 (UTC) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 89EC763B2A9 for ; Thu, 23 Mar 2006 23:55:32 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FMZeN-0006Ti-00; Thu, 23 Mar 2006 23:55:31 +0000 Delivered-To: ietf-ssh@netbsd.org Content-Disposition: inline Subject: Re: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated Precedence: list Sender: ietf-ssh-owner@NetBSD.org X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060323235531.GA20807@chiark.greenend.org.uk> Scott Blomquist writes: > [Jacob Nevins:] > > When this happened before, a WG member said that NetBSD have an > > archive which can probably be used to fill in any gaps, if necessary. > > I don't know if that's still true. > > Ok I have re-subscribed an address here. I could not find any text > archives. Have any pointers? I don't know about any NetBSD archive, but I do have access to a local archive which covers the relevant period, in fact. I've cleaned it up and will send it to you under separate cover. From recovered-from-private-archive Fri Mar 24 14:58:42 2006 Received: by mail.netbsd.org (Postfix, from userid 0) id E5FFD63B14C; Fri, 24 Mar 2006 14:58:44 +0000 (UTC) Received: from carter-zimmerman.mit.edu (unknown [IPv6:2001:df8:0:128:20e:9bff:fecf:3248]) by mail.netbsd.org (Postfix) with ESMTP id 5803063B303 for ; Fri, 24 Mar 2006 14:58:44 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 40AC2E0053; Fri, 24 Mar 2006 09:58:42 -0500 (EST) Delivered-To: ietf-ssh@netbsd.org Subject: Found way to deal with publickeyfile Precedence: list To: ietf-ssh@netbsd.org From: Sam Hartman Sender: ietf-ssh-owner@NetBSD.org Date: Fri, 24 Mar 2006 09:58:42 -0500 (EST) X-Original-To: ietf-ssh@netbsd.org Message-ID: <20060324145842.40AC2E0053@carter-zimmerman.mit.edu> So, assuming that IANA is OK with the text, I think we're done. I have it holding in a semi-approved state right now, which will be sufficient to avoid full re-review by the IESG. We're now waiting for IANA. From recovered-from-private-archive Fri Mar 24 20:45:40 2006 X-RT-Loop-Prevention: Inquiry Reply-To: ietf-action@ietf.org Content-Type: text/plain; charset="utf-8" To: ietf-ssh@netbsd.org Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) In-Reply-To: References: MIME-Version: 1.0 From: "Scott Blomquist via RT" Date: Fri, 24 Mar 2006 15:56:40 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 7570363B1C5; Fri, 24 Mar 2006 20:56:41 +0000 (UTC) Received: from ticket.ietf.org (stiedprtick1.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id C708F63B101 for ; Fri, 24 Mar 2006 20:56:40 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FMtKq-0002Qs-0X for ietf-ssh@netbsd.org; Fri, 24 Mar 2006 15:56:40 -0500 X-RT-Original-Encoding: utf-8 Delivered-To: ietf-ssh@netbsd.org Subject: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated RT-Originator: ietf-admin@techsquare.com Precedence: list Sender: ietf-ssh-owner@NetBSD.org RT-Ticket: Inquiry #85608 X-Original-To: ietf-ssh@netbsd.org Message-ID: > [ietf-ssh@netbsd.org - Thu Mar 23 20:48:04 2006]: > > Scott Blomquist writes: > > [Jacob Nevins:] > > > When this happened before, a WG member said that NetBSD have an > > > archive which can probably be used to fill in any gaps, if necessary. > > > I don't know if that's still true. > > > > Ok I have re-subscribed an address here. I could not find any text > > archives. Have any pointers? > > I don't know about any NetBSD archive, but I do have access to a local > archive which covers the relevant period, in fact. I've cleaned it up > and will send it to you under separate cover. > > > Thanks. I have put both files in place and I have confirmed the subscription so I should be getting updates now. sb. Scott Blomquist From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 28 14:54:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKGR-0000s7-Eu for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 28 Mar 2006 14:54:03 -0500 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOKGN-0003lC-On for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 28 Mar 2006 14:54:03 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 606CB63B382; Tue, 28 Mar 2006 19:53:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from exfe02.ist.local (exfe02.ist.psu.edu [130.203.135.180]) by mail.netbsd.org (Postfix) with ESMTP id 6723B63B133 for ; Tue, 28 Mar 2006 19:53:44 +0000 (UTC) Received: from EMAIL.ist.local ([130.203.135.182]) by exfe02.ist.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 14:53:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: SECURECOMM 2006 - Extended Deadline Date: Tue, 28 Mar 2006 14:53:37 -0500 Message-ID: <90B48DD852C2474C964E296211A9A132010587E9@EMAIL.ist.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECURECOMM 2006 - Extended Deadline Thread-Index: AcZSoVFpvsf2gUYGRbGltaX5wZbzrQ== From: "Peng Liu" To: X-OriginalArrivalTime: 28 Mar 2006 19:53:37.0678 (UTC) FILETIME=[4DE62AE0:01C652A1] Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Dear Colleague, Despite the large number of submissions attracted so far, many extension requests were made. We therefore announce a (final) one-week extension to the Securecomm 2006 submisison deadline -- April 8, PST. The CFP is attached below.=20 The complete information is available on the website: www.securecomm.org We apologize if you receive multiple copies of this message. Please feel free to distribute this to colleagues who might be interested. Best Regards, SecureComm 2006 Organizing Committee ******************************************************************* CALL FOR PAPERS SecureComm 2006 Second IEEE Communications Society/CreateNet International Conference on Security and Privacy in Communication Networks Baltimore, MD, USA, Aug. 28 - Sep. 1, 2006 URL: http://www.securecomm.org CO-SPONSORED BY: IEEE Communications Society (www.comsoc.org) CreateNet (www.create-net.it) In Cooperation with ACM SIGSAC ******************************************************************* The scope of Securecomm 2006 has been broadened since the inaugural 2005 event. Topics of interest encompass research advances in ALL areas of secure communications and networking. Topics in other areas (e.g., formal methods, database security, secure OS/software, theoretical cryptography, e-commerce) will be considered only if a clear connection to privacy and/or security in communication/networking is demonstrated. Securecomm aims to bring together security and privacy experts in academia, industry and government as well as practitioners, standards developers and policy makers. Securecomm also serves as a venue for learning about state-of-the-art in security and privacy research. Presentations reporting on cutting-edge research results are supplemented by panels on controversial issues and invited talks on timely and important topics. Areas of interest include, but ARE NOT limited to, the following: ----------------------------------------------------------------- * Security & Privacy in Wired, Wireless, Mobile, Hybrid, Sensor, Ad Hoc networks * Network Intrusion Detection and Prevention, DoS Countermeasures * Firewalls, Routers, Filters and Malware detectors * Public Key Infrastructures and Other Security Architectures * Secure Web Communication * Communication Privacy and Anonymity * Secure/Private E-commerce * Secure Routing, Naming/Addressing, Network Management * Security & Privacy in Pervasive and Ubiquitous Computing, e.g., RFIDs PAPERS: Technical papers describing original unpublished research are solicited. Submissions must not be concurrently under review by a conference, journal or any other venue that has proceedings. Authors of the highest-quality accepted papers will be invited to submit extended version of their papers to a special issue of ACM Transactions on Information and System Security (TISSEC). SHORT PAPERS: Continuing with the last year's model, in addition to full papers, Securecomm 2006 invites submission of pithy concise technical papers (also describing original unpublished research). Such papers may represent work-in-progress or small -- yet novel -- research results that do not warrant a full paper. SUBMISSION INSTRUCTIONS: Only PDF formats are accepted for all submissions. Full paper submissions must not exceed 10 pages in IEEE conference style, two-column format, not including the bibliography. Well-marked appendices of up to 2 pages are allowed but will be read only at the discretion of reviewers. Short paper submissions are limited to 5 pages total. IEEE Communications Society and Create-Net policy states that all accepted SecureComm 2006 papers must have at least one registration at the regular rate. For authors co-authoring multiple papers, one regular registration is valid for up to two papers. All submitted papers will be judged based on their quality through *double-blind* reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper PDF file. Please submit the paper through the COCUS System using the following three steps. 1. By clicking on the link "http://cocus.create-net.it" you will be re-directed to the COCUS site. Click on Register to create an account, if you do not have one. 2. Once you have an account, log in and click on Event List. Scroll down to* SECURECOMM *and choose the Submit Paper Link. 3. Fill in the details (title, authors, abstract, classifications, etc) and register the paper by March 24, 2006. Full paper must be uploaded by April 1, 2006. PANELS: Panels that examine innovative, controversial, or otherwise provocative issues of interest are solicited. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should submit proposals to the Panels Co-Chairs by March 18, 2006. WORKSHOPS: Workshop proposals on topics related to the broader theme of the conference are solicited. Workshop proposals should not exceed 3 pages, including biographical sketches of the main organizers, completed description of the workshop topic and its potential interest to the community and relevance to Securecomm, and a detailed draft CFP. Potential workshop organizers should submit proposals to the Workshops Chair by February 1, 2006. RESEARCH DEMOS: Informal proposals for research demos are solicited. Proposals will be reviewed and selection will be made based on the perceived value to the research community and interest level for the conference attendees. Proposals should not exceed 3 pages and should include: the focus area, technologies involved, specific equipment to be used, demo layout and space required. Please submit proposals to the Research Demos Chair(s) by June 1, 2006. IMPORTANT DATES --------------- TECHNICAL Paper submissions due: March 24, 2006 (Title/Abstract) April 1, 2006 (Full Paper) NOTIFICATION date: May 31, 2006 Camera-ready version due: June 24, 2006 Conference Dates: Aug. 28 - Sep. 1, 2006 For information regarding the conference, please visit http://www.securecomm.org or contact one of the Chairs below. CONFERENCE ORGANIZING COMMITTEE General Co-Chairs ----------------- Mukesh Singhal, University of Kentucky, singhal@cs.uky.edu John Baras, University of Maryland, College Park, baras@isr.umd.edu Technical Program Co-Chairs --------------------------- Steve Kent, BBN, kent@bbn.com Gene Tsudik, UC Irvine, gts@ics.uci.edu Workshops Chair --------------- G. Manimaran, Iowa State University, gmani@iastate.edu Panels Co-Chairs ---------------- Bruno Crispo, Vrije Universiteit, Netherlands, crispo@few.vu.nl Avishai Wool, Technion, Israel, yash@eng.tau.ac.il Research Demos/Exhibits Chair ----------------------------- Tom Karygiannis, NIST, karygiannis@nist.gov Sponsorships Chair ------------------ Byrav Ramamurthy, University of Nebraska, Lincoln, byrav@cse.unl.edu Publicity Co-Chairs ------------------- Peng Liu, Penn State University, pliu@ist.psu.edu Cristina Nita-Rotaru, Purdue University, crisn@cs.purdue.edu Publication Chair ----------------- Farooq Anjum, Telcordia Technologies, fanjum@telcordia.com Steering Committee: ------------------- Imrich Chlamtac (Chair), Create-Net Krishna M. Sivalingam (Co-Chair), University of Maryland, Baltimore County Gene Tsudik, University of California, Irvine Brian Bigalke, (Staff Liaison, IEEE Communications Society) TECHNICAL PROGRAM COMMITTEE --------------------------- N. Asokan Nokia Research Giuseppe Ateniese Johns Hopkins University Tuomas Aura Microsoft Research Dirk Balfanz PARC Bharat Bhargava Purdue Matt Bishop University of California, Davis Levente Buttyan Budapest University of Technology Srdjan Capkun Technical University of Denmark Claude Castelluccia Inria Rhone-Alpes Tom Chen Southern Methodist University Giovanni Di Crescenzo Telcordia Research Bruno Crispo Vrije Universitet Breno de Medeiros University of Central Florida Robert Deng Singapore Management University Xuhua Ding Singapore Management University Glenn Durfee PARC Bao Feng Institute for Infocomm Research Dieter Gollmann Technical University of Hamburg-Harb Richard Han University of Colorado at Boulder Tom Karygiannis NIST Yongdae Kim University of Minnessota Christopher Kruegel Technical University of Vienna Kwok-Yan Lam Tsinghua University Brian LaMacchia Microsoft Carl Landwehr University of Maryland Wenke Lee Georgia Tech Albert Levi Sabanci University, Ninghui Li Purdue Peng Liu Pennsylvania State University Luigi Mancini Unversity of Rome - La Sapienza Fabio Massacci University of Trento Ludovic Me' Supelec Pietro Michiardi Eurecom Institute Refik Molva Eurecom Institute Mats Naslund Ericsson Research Pekka Nikander Ericsson Nomadiclab Cristina Nita-Rotaru Purdue Radha Poovendran University of Washington Byrav Ramamurthy University of Nebraska-Lincoln Michael Roe Microsoft Research Sanjeev Setia George Mason University Cliff Wang Army Research Laboratory Helen Wang Microsoft Research Ron Watro BBN Dirk Westhoff NEC Research Susanne Wetzel Stevens Institute of Technology Avishai Wool Tel Aviv University Shouhuai Xu University of Texas, San Antonio Xiaowei Yang University of California, Irvine Bulent Yener Rensselauer Polytechnic Institute Jeong Hyun Yi Samsung Advanced Institute of Technology Jianying Zhou Institute for Infocomm Research Alf Zugenmaier DoCoMo Labs ************************************************************************ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 29 06:57:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZJ4-0004Ip-3C for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 29 Mar 2006 06:57:46 -0500 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZJ1-0000XA-QK for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 29 Mar 2006 06:57:46 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 17C9163B1E6; Wed, 29 Mar 2006 11:57:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 5857563B10A for ; Wed, 29 Mar 2006 11:57:40 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1FOZIx-00084Q-00; Wed, 29 Mar 2006 12:57:39 +0100 Date: Wed, 29 Mar 2006 12:57:39 +0100 From: Jacob Nevins To: Scott Blomquist via RT Cc: ietf-ssh@netbsd.org Subject: Re: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated Message-ID: <20060329115738.GA26731@chiark.greenend.org.uk> Reply-To: ietf-ssh@netbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Scott Blomquist writes: > Thanks. I have put both files in place This is fine, thanks. > and I have confirmed the subscription so I should be getting updates > now. I'm not convinced this is working. There are five recent messages on the list which are not in the archive at , not including the one I'm writing now. One of these arrived after the message I'm replying to: <90B48DD852C2474C964E296211A9A132010587E9@EMAIL.ist.local> subject "SECURECOMM 2006 - Extended Deadline". The only message in 'current' that's not in the copy I sent you is a "Welcome to ietf-ssh" message. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 30 16:11:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4QQ-0000Cy-Ht for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 30 Mar 2006 16:11:26 -0500 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4QP-0008Br-6T for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 30 Mar 2006 16:11:26 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 4AAFD63B4E7; Thu, 30 Mar 2006 21:11:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ticket.ietf.org (stiedprtick1.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 8DDBF63B136 for ; Thu, 30 Mar 2006 21:11:21 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FP4QK-0002q0-R5 for ietf-ssh@netbsd.org; Thu, 30 Mar 2006 16:11:20 -0500 Subject: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated From: "Scott Blomquist via RT" Reply-To: ietf-action@ietf.org In-Reply-To: Message-ID: X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #85608 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: ietf-admin@techsquare.com To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 30 Mar 2006 16:11:20 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d > [ietf-ssh@netbsd.org - Wed Mar 29 06:57:42 2006]: > > Scott Blomquist writes: > > Thanks. I have put both files in place > > This is fine, thanks. > > > and I have confirmed the subscription so I should be getting updates > > now. > > I'm not convinced this is working. > > There are five recent messages on the list which are not in the archive > at , not including > the one I'm writing now. > > One of these arrived after the message I'm replying to: > <90B48DD852C2474C964E296211A9A132010587E9@EMAIL.ist.local> > subject "SECURECOMM 2006 - Extended Deadline". > > The only message in 'current' that's not in the copy I sent you is a > "Welcome to ietf-ssh" message. > Yah it doesn't seem correct, but the messages that are coming in are getting there. The message you sent above got in. Let's see if this one gets in. sb.