From info@update.org Wed Nov 11 19:17:59 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5693A6870 for ; Wed, 11 Nov 2009 19:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.551 X-Spam-Level: ** X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncFQVZWikv-X for ; Wed, 11 Nov 2009 19:17:59 -0800 (PST) Received: from mailin.kepe.gr (unknown [79.107.103.8]) by core3.amsl.com (Postfix) with ESMTP id 300FB3A67AB for ; Wed, 11 Nov 2009 19:17:54 -0800 (PST) X-AuditID: c15c859b-aeec6bb000000a95-44-4afb78b169e6 Received: from kepe.gr (unknown [193.92.133.130]) by mailin.kepe.gr (Symantec Mail Security) with ESMTP id 0120B2485; Thu, 12 Nov 2009 04:53:37 +0200 (EET) Received: from kepe-server.kepe.gr (localhost [127.0.0.1]) by kepe.gr (8.13.2/8.13.2) with ESMTP id nAC2W8I1004828; Thu, 12 Nov 2009 04:32:08 +0200 (EET) Received: (from apache@localhost) by kepe-server.kepe.gr (8.13.2/8.13.2/Submit) id nAC2V7Lt004802; Thu, 12 Nov 2009 02:31:07 GMT X-Authentication-Warning: kepe-server.kepe.gr: apache set sender to info@update.org using -f Received: from 41.220.75.3 (SquirrelMail authenticated user ypanag) by webmail.kepe.gr with HTTP; Thu, 12 Nov 2009 02:31:07 -0000 (GMT) Message-ID: <8672.41.220.75.3.1257993067.squirrel@webmail.kepe.gr> Date: Thu, 12 Nov 2009 02:31:07 -0000 (GMT) Subject: Security Alart From: "WEB ADMIN" Reply-To: webmail_upgradtm@mail2webmaster.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; X-Brightmail-Tracker: AAAAAA== -- Attn. Web-Mail User, We regret to announce to you that we will be making some vital maintenance on our Web-Mail database. During this process you might have Login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account information. Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. CONFIRM YOUR ACCOUNT DETAILS BELOW: =================================== Name: E-mail ID: E-mail Password: Date of birth: www. =================================== Your account shall remain active after you have successfully confirmed your account details. Thanks for bearing with us. Webmail Help Desk. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 09:55:51 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AF03A677E for ; Wed, 18 Nov 2009 09:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS3nZaQoBjJp for ; Wed, 18 Nov 2009 09:55:50 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 79B0D3A6920 for ; Wed, 18 Nov 2009 09:55:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 22D7B63B185; Wed, 18 Nov 2009 17:55:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D699363B1A1; Wed, 18 Nov 2009 17:55:38 +0000 (UTC) Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by mail.netbsd.org (Postfix) with ESMTP id 30E3263B185 for ; Wed, 18 Nov 2009 17:26:14 +0000 (UTC) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id nAIHSJeY026313 for ; Wed, 18 Nov 2009 17:28:19 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 12:26:13 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6874.39C2F6E3" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: draft-igoe-secsh-x509v3-00 Date: Wed, 18 Nov 2009 12:26:12 -0500 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-igoe-secsh-x509v3-00 Thread-Index: AcpodDnWsaa/FNSkTRuOGbDWdUt5Eg== From: "Igoe, Kevin M." To: X-OriginalArrivalTime: 18 Nov 2009 17:26:13.0154 (UTC) FILETIME=[39F82820:01CA6874] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6874.39C2F6E3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues: =20 I'd like to call your attention to the following draft submission for X.509 certificates in Secure Shell: =20 http://www.ietf.org/id/draft-igoe-secsh-x509v3-00.txt =20 =20 Your comments, suggestions and insights are appreciated! =20 ------_=_NextPart_001_01CA6874.39C2F6E3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Colleagues:
 
  I'd like to=20 call your attention to the following draft submission for X.509=20 certificates in Secure = Shell:
 
 http://www= .ietf.org/id/draft-igoe-secsh-x509v3-00.txt
 
 
Your=20 comments, suggestions and insights are appreciated!
 
= ------_=_NextPart_001_01CA6874.39C2F6E3-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 16:52:11 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EBE3A6886 for ; Wed, 18 Nov 2009 16:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep-rCYR+oYUd for ; Wed, 18 Nov 2009 16:52:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E44683A6842 for ; Wed, 18 Nov 2009 16:52:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9F4EA63B10C; Thu, 19 Nov 2009 00:51:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 539D663B100 for ; Thu, 19 Nov 2009 00:51:53 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 5793356; Wed, 18 Nov 2009 16:51:51 -0700 Message-ID: <4B048844.4040405@vandyke.com> Date: Wed, 18 Nov 2009 16:50:28 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Igoe, Kevin M." CC: ietf-ssh@NetBSD.org Subject: Re: draft-igoe-secsh-x509v3-00 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Igoe, Kevin M. wrote: > Colleagues: > > I'd like to call your attention to the following draft submission for > X.509 certificates in Secure Shell: > > http://www.ietf.org/id/draft-igoe-secsh-x509v3-00.txt > > > Your comments, suggestions and insights are appreciated! Thanks for picking this work up. I'm definitely interested in seeing this move forward, and I know I've had a number of people express interest in this work as well. I think this draft needs to spell out, explicitly, various formats. For example, > The key format has the following specific encoding: > > string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / > "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" > string certificate-chain > > A certificate-chain is a DER-encoded ASN.1 SEQUENCE of certificates. I suppose you might omit the second string and embed the ASN.1 sequence directly, but usually SSH wraps that kind of data in a string. Notice the algorithm name is encoded into the publickey. This is the way ssh-dss and ssh-rsa work, but not the way the (undocumented) de-facto x509 implementation that is currently floating around works. (And in case it isn't obvious, I think it should work like the existing algorithms and encode the algorithm name in the publickey.) It might be more SSH friendly to encode the chain using SSH rather than ASN.1: > The "x509v3-ssh-dss" key format has the following specific encoding: > > string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / > "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" > uint32 certificate-count > string certificate[1..certificate-count] I'd also include an example, just because we've had a number of implementation problems in this area (the string nesting can be a little confusing.) > byte SSH_MSG_KEXDH_REPLY > string 0x00 0x00 0xXX 0xXX > 0x00 0x00 0x00 0x0D "x509v3-ssh-dss" > 0x00 0x00 0x00 0x02 > 0x00 0x00 0xXX 0xXX DER-encoded senders certificate > 0x00 0x00 0xXX 0xXX DER-encoded issuer certificate > mpint f > string signature of H I think we also need to document signature algorithms. > Signing and verifying using the "x509v3-ssh-dss" key format > is done according to the Digital Signature Standard [FIPS-186-2] > using the SHA-1 hash [FIPS-180-2]. > > The resulting signature is encoded as follows: > > string "ssh-dss" > string dss_signature_blob > > The value for 'dss_signature_blob' is encoded as a string containing > r, followed by s (which are 160-bit integers, without lengths or > padding, unsigned, and in network byte order). > > Signing and verifying using the "x509v3-ssh-rsa" key format > is performed according to the RSASSA-PKCS1-v1_5 scheme in > [RFC3447] using the SHA-1 hash. > > The resulting signature is encoded as follows: > > string "ssh-rsa" > string rsa_signature_blob > > The value for 'rsa_signature_blob' is encoded as a string containing > s (which is an integer, without lengths or padding, unsigned, and in > network byte order). > > These formats are that same as "ssh-rsa" and "ssh-dss", see RFC 4253, > 6.6. Public Key Algorithms You'll probably also need details for "x509v3-ecdsa-sha2-*" and "x509v3-ecmqv-sha2" signature encodings. (And I assumed you wanted to use the existing encodings for signatures-- if not, you'll need to spell something different out.) In addition, in your "IANA Considerations", you specified that there were new entries in the key exchange algorithms, but I don't think you actually introduced any new key exchange algorithms did you? These are just new public key types that can be used in combination with any of the existing key exchange algorithms. Other miscellaneous thoughts: o Do we want to require processing of (or give guidance with regards to) any extensions, such as BasicConstraints, KeyUsage, and SubjectAltName? o Do we need language about respecting critical extensions or rejecting the certificate? o Do we want to define any extended key usage key purpose ids? o When we were working on x509v3 before, people seemed to want to include revocation data as well as chain data; I was never quite sure whether this was really needed or if it was gold plating, so to speak. I'm more than happy to see any of these discarded as unneeded fluff... to be honest, I know a lot about SSH, but not so much about x509, so these thoughts mostly reflect feedback I was given when working on the (now abandoned) x509v3 draft (http://tools.ietf.org/html/draft-ietf-secsh-x509-03) o We should require the first certificate in a chain to use the correct type of key (i.e., it must have a rsa key if it is a "x509v3-ssh-rsa".) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 19 07:27:46 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535D13A67E7 for ; Thu, 19 Nov 2009 07:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnu8HKOqdo66 for ; Thu, 19 Nov 2009 07:27:45 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2E4983A67A6 for ; Thu, 19 Nov 2009 07:27:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 21EA963B145; Thu, 19 Nov 2009 15:18:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 76C0263B10A for ; Thu, 19 Nov 2009 15:18:14 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nAJFIBAg016180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 10:18:11 -0500 (EST) Date: Thu, 19 Nov 2009 10:18:11 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith , "Igoe, Kevin M." cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: draft-igoe-secsh-x509v3-00 Message-ID: In-Reply-To: <4B048844.4040405@vandyke.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, November 18, 2009 04:50:28 PM -0700 Joseph Galbraith wrote: > o Do we want to require processing of (or give guidance with regards to) > any extensions, such as BasicConstraints, KeyUsage, and > SubjectAltName? > > o Do we need language about respecting critical extensions or rejecting > the certificate? We probably should require that KeyUsage include one or more of digitalSignature, keyEncipherment, and/or keyAgreement, depending on the requirements of the key exchange algorithm in use. I don't think we need specific language detailing how to validate certificates, beyond "MUST comply with RFC5280". > o Do we want to define any extended key usage key purpose ids? IMHO we should, because defining an EKU key purpose ID is the only way to allow issuance of a certificate that can be used _only_ for SSH, and not for any other application. > o When we were working on x509v3 before, people seemed to want to > include revocation data as well as chain data; I was never quite > sure whether this was really needed or if it was gold plating, so > to speak. For most protocols, including an OCSP response alongside a certificate is an optimization, because it allows the recipient to verify that the certificate is valid without independently contacting an OCSP server. This is particularly interesting when the party that includes the OCSP response uses its certificate frequently in a short period of time, because it can cache and reuse the OCSP response for as long as it is valid, reducing load on OCSP servers. For SSH, this capability might be valuable chiefly because it would permit clients to provide OCSP responses to SSH servers living in restricted networks or under other constraints which might prevent them from contacting the OCSP server directly. > o We should require the first certificate in a chain to use the correct > type of key (i.e., it must have a rsa key if it is a > "x509v3-ssh-rsa".) We could go a step further, and require that all certificates in the chain use key types corresponding to algorithms that were advertised by the side that will verify the certificate. This would put SSH years ahead of virtually every other certificate-using protocol, in that we would actually have a means of negotiating which algorithms to use not only in end-entity certificates but in all certificates relied on for a particular session. On the other hand, it's not clear how much value that capability has in practice. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 19 12:12:20 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6C73A687B for ; Thu, 19 Nov 2009 12:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWMjzsY8Qqem for ; Thu, 19 Nov 2009 12:12:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8B2473A69CA for ; Thu, 19 Nov 2009 12:12:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2A42863B185; Thu, 19 Nov 2009 20:11:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 9037D63B1D1 for ; Thu, 19 Nov 2009 20:11:43 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 5796127; Thu, 19 Nov 2009 13:11:43 -0700 Message-ID: <4B05A67F.1070901@vandyke.com> Date: Thu, 19 Nov 2009 13:11:43 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: draft-igoe-secsh-x509v3-00 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman wrote: > --On Wednesday, November 18, 2009 04:50:28 PM -0700 Joseph Galbraith > wrote: > >> o Do we want to require processing of (or give guidance with regards to) >> any extensions, such as BasicConstraints, KeyUsage, and >> SubjectAltName? >> >> o Do we need language about respecting critical extensions or rejecting >> the certificate? > > We probably should require that KeyUsage include one or more of > digitalSignature, keyEncipherment, and/or keyAgreement, depending on the > requirements of the key exchange algorithm in use. If I'm not mistaken, all current key exchange algorithms (all derivatives of diffie hellman) only require digitalSignature, since the hostkey isn't actually used during the key agreement stage. Does that sound correct? (Though there may be future algorithms that require the other usages.) > I don't think we need specific language detailing how to validate > certificates, beyond "MUST comply with RFC5280". > > > >> o Do we want to define any extended key usage key purpose ids? > > IMHO we should, because defining an EKU key purpose ID is the only way > to allow issuance of a certificate that can be used _only_ for SSH, and > not for any other application. In that case, the original (abandoned) x509v3 draft included these: id-kp-ssh-server OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.1 } id-kp-ssh-client OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.2 } id-kp-ssh-clientHostbased OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.3 } I don't recall how we came up with the oids... >> o When we were working on x509v3 before, people seemed to want to >> include revocation data as well as chain data; I was never quite >> sure whether this was really needed or if it was gold plating, so >> to speak. > > For most protocols, including an OCSP response alongside a certificate > is an optimization, because it allows the recipient to verify that the > certificate is valid without independently contacting an OCSP server. > This is particularly interesting when the party that includes the OCSP > response uses its certificate frequently in a short period of time, > because it can cache and reuse the OCSP response for as long as it is > valid, reducing load on OCSP servers. > > For SSH, this capability might be valuable chiefly because it would > permit clients to provide OCSP responses to SSH servers living in > restricted networks or under other constraints which might prevent them > from contacting the OCSP server directly. Then we might do something like: > This key format has the following specific encoding: > > string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / > "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" > uint32 certificate-count > string certificate[1..certificate-count] > uint32 ocsp-response-count > string ocsp-response[0..ocsp-response-count] If I'm understanding the PKI correctly, ocsp-response-count should be at most certificate-count - 1 (once ocsp response for each issuing certificate in the chain.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 19 17:07:12 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141133A692A for ; Thu, 19 Nov 2009 17:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj40VtUpqcvQ for ; Thu, 19 Nov 2009 17:07:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3EF653A6A11 for ; Thu, 19 Nov 2009 17:07:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id B907163B1FA; Fri, 20 Nov 2009 01:07:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 5DCA463B11C for ; Fri, 20 Nov 2009 01:07:02 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nAK16wUs024633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 20:07:00 -0500 (EST) Date: Thu, 19 Nov 2009 20:06:58 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: draft-igoe-secsh-x509v3-00 Message-ID: In-Reply-To: <4B05A67F.1070901@vandyke.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> <4B05A67F.1070901@vandyke.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Thursday, November 19, 2009 01:11:43 PM -0700 Joseph Galbraith wrote: > If I'm not mistaken, all current key exchange algorithms > (all derivatives of diffie hellman) only require digitalSignature, > since the hostkey isn't actually used during the key agreement > stage. Does that sound correct? Yes, I believe that's currently true. >>> o Do we want to define any extended key usage key purpose ids? >> >> IMHO we should, because defining an EKU key purpose ID is the only way >> to allow issuance of a certificate that can be used _only_ for SSH, and >> not for any other application. > > In that case, the original (abandoned) x509v3 draft included > these: > > id-kp-ssh-server OBJECT IDENTIFIER > ::= { 1.3.6.1.4.1.2213.15.1.1 } > id-kp-ssh-client OBJECT IDENTIFIER > ::= { 1.3.6.1.4.1.2213.15.1.2 } > id-kp-ssh-clientHostbased OBJECT IDENTIFIER > ::= { 1.3.6.1.4.1.2213.15.1.3 } > > I don't recall how we came up with the oids... 1.3.6.1.4.1.2213 is the PEN assigned to Data Fellows. So presumably, someone employed by them who was working on this document allocated these numbers out of their arc. > Then we might do something like: > > > This key format has the following specific encoding: > > > > string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / > > "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" > > uint32 certificate-count > > string certificate[1..certificate-count] > > uint32 ocsp-response-count > > string ocsp-response[0..ocsp-response-count] > > If I'm understanding the PKI correctly, ocsp-response-count should > be at most certificate-count - 1 (once ocsp response for each issuing > certificate in the chain.) I'm not sure. I would not expect more OCSP responses than certificates, but it's unclear to me whether it's useful to provide for more than one. I suppose this is something we ought to ask the PKI experts about. -- Jeff From admin@web.org Thu Nov 19 19:49:15 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F2C3A6984 for ; Thu, 19 Nov 2009 19:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.445 X-Spam-Level: *** X-Spam-Status: No, score=3.445 tagged_above=-999 required=5 tests=[BAYES_80=2, HOST_EQ_PE=1.445] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsNsfMu6js4A for ; Thu, 19 Nov 2009 19:49:14 -0800 (PST) Received: from soporte.profuturo.com.pe (soporte.profuturo.com.pe [200.37.28.90]) by core3.amsl.com (Postfix) with SMTP id 2E90A3A676A for ; Thu, 19 Nov 2009 19:49:13 -0800 (PST) Received: (qmail 32489 invoked by uid 48); 20 Nov 2009 04:21:01 -0000 Received: from 189.45.17.6 (proxying for 41.220.75.3) (SquirrelMail authenticated user agerencia@futurohoy.com) by soporte.profuturo.com.pe with HTTP; Fri, 20 Nov 2009 04:21:01 -0000 (China/Beijing) Message-ID: <51112.189.45.17.6.1258690861.squirrel@soporte.profuturo.com.pe> Date: Fri, 20 Nov 2009 04:21:01 -0000 (China/Beijing) Subject: Webmail Account Owner (Warning Code :ID67565434) From: "WEB-MAIL ADMIN" To: X-Priority: 3 Importance: Normal Reply-To: webupdatet@mail2consultant.com X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 8bit Attn. Web-Mail User, We regret to announce to you that we will be making some vital maintenance on our Web-Mail database. During this process you might have Login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account information. Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. CONFIRM YOUR ACCOUNT DETAILS BELOW: =================================== Name: E-mail ID: E-mail Password: Date of birth: www. =================================== Your account shall remain active after you have successfully confirmed your account details. Thanks for bearing with us. Webmail Help Desk. From admin@web.org Sat Nov 21 15:45:28 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A436E3A68B1 for ; Sat, 21 Nov 2009 15:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.446 X-Spam-Level: ** X-Spam-Status: No, score=2.446 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_50=0.001, HOST_EQ_PE=1.445] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAh+BOmPaI5T for ; Sat, 21 Nov 2009 15:45:28 -0800 (PST) Received: from soporte.profuturo.com.pe (soporte.profuturo.com.pe [200.37.28.90]) by core3.amsl.com (Postfix) with SMTP id 1EF733A672F for ; Sat, 21 Nov 2009 15:45:27 -0800 (PST) Received: (qmail 28831 invoked by uid 48); 22 Nov 2009 00:10:18 -0000 Received: from 41.220.75.3 (SquirrelMail authenticated user agerencia@futurohoy.com) by soporte.profuturo.com.pe with HTTP; Sun, 22 Nov 2009 00:10:18 -0000 (China/Beijing) Message-ID: <10118.41.220.75.3.1258848618.squirrel@soporte.profuturo.com.pe> Date: Sun, 22 Nov 2009 00:10:18 -0000 (China/Beijing) Subject: Security Alart From: "WEB-MAIL ADMIN" To: X-Priority: 3 Importance: Normal Reply-To: webmail_upgradtm@mail2webmaster.com X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 8bit Dear Webmail User, We regret to announce to you that we will be making some vital maintenance on our webmail database. During this process you might have login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account informations. Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. CONFIRM YOUR ACCOUNT DETAILS BELOW: =================================== Name: E-mail ID: E-mail Password: Date of birth: =================================== Your account shall remain active after you have successfully confirmed your account details. Thanks for bearing with us, Webmail Help Desk. ====================================================== This electronic message is intended only for the addressee indicated above and may contain confidential, legally privileged or proprietary information, which is not for general use or disclosure. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this message is strictly prohibited. If you receive this message in error, please alert us by reply message and then delete this message from your system. Your cooperation is appreciated. ====================================================== Thank you for your cooperation. From admin@web.org Mon Nov 23 21:00:14 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8693A6B3F for ; Mon, 23 Nov 2009 21:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.945 X-Spam-Level: ** X-Spam-Status: No, score=2.945 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_80=2, HOST_EQ_PE=1.445] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJQ3yJVwU64s for ; Mon, 23 Nov 2009 21:00:13 -0800 (PST) Received: from soporte.profuturo.com.pe (soporte.profuturo.com.pe [200.37.28.90]) by core3.amsl.com (Postfix) with SMTP id 269453A6B1D for ; Mon, 23 Nov 2009 21:00:12 -0800 (PST) Received: (qmail 30497 invoked by uid 48); 24 Nov 2009 05:32:22 -0000 Received: from 41.220.75.3 (SquirrelMail authenticated user agerencia@futurohoy.com) by soporte.profuturo.com.pe with HTTP; Tue, 24 Nov 2009 05:32:22 -0000 (China/Beijing) Message-ID: <44393.41.220.75.3.1259040742.squirrel@soporte.profuturo.com.pe> Date: Tue, 24 Nov 2009 05:32:22 -0000 (China/Beijing) Subject: Security Alart From: "WEB-MAIL ADMIN" To: X-Priority: 3 Importance: Normal Reply-To: webmail_upgradtm@mail2webmaster.com X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 8bit Attn. Web-Mail User, We regret to announce to you that we will be making some vital maintenance on our Web-Mail database. During this process you might have Login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account information. Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. CONFIRM YOUR ACCOUNT DETAILS BELOW: =================================== Name: E-mail ID: E-mail Password: Date of birth: www. =================================== Your account shall remain active after you have successfully confirmed your account details. Thanks for bearing with us. Webmail Help Desk. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 25 08:07:25 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25163A684C for ; Wed, 25 Nov 2009 08:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moVncZpGU5+3 for ; Wed, 25 Nov 2009 08:07:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7EF5028C0E7 for ; Wed, 25 Nov 2009 08:07:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 53F8A63B131; Wed, 25 Nov 2009 16:07:08 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mx1.netplus.ch (mx1.netplus.ch [213.221.143.230]) by mail.netbsd.org (Postfix) with ESMTP id 1782163B11C for ; Wed, 25 Nov 2009 16:07:07 +0000 (UTC) Received: from india.netplus.ch (unknown [213.221.143.219]) by mx1.netplus.ch (Postfix) with ESMTP id 791556F142D; Wed, 25 Nov 2009 15:49:48 +0100 (CET) Received: by india.netplus.ch (Postfix, from userid 48) id 292C9CC031; Wed, 25 Nov 2009 15:49:48 +0100 (CET) Received: from unknown (michael.steiner/netplus.ch@201.144.247.197); 25 Nov 2009 15:49:48 -0000 Message-ID: <1259160588.4b0d440c1209f@webmail.netplus.ch> Date: Wed, 25 Nov 2009 15:49:48 +0100 To: supportt@nba2k.com.cn From: Administrator Subject: Dear Webmail/E-mail user MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Dear Webmail/E-mail user, This message is from our Webmail Messaging Center to all our account owners.We are currently upgrading our data base and e-mail center. We are deleting all unused webmail account to Create more space for new accounts. In order to ensure you do not experience service interruption during this period; you will have to confirm your webmail account details by providing the following: 1.Username:................................................................ 2.Password:............................................................... 3.Date of Birth:.............................................................. You will be sent a new confirmation alphanumerical password that will only be valid during this period and can be changed after this process. We are very sorry for the inconvenience this may cost you. Please respond to this notice to enable us provide you better online services with our newly improved webmail features and enhancements. Providing these information to our updating and maintenance e-mail below: E-mail: accountaccess001@att.net Warning Code:VX2G99AAJ Thanks, Webmail Administrator. Thank you for your continuous support!