From admin@web.org Wed Dec 2 06:53:45 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 072D93A63EC for ; Wed, 2 Dec 2009 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.445 X-Spam-Level: **** X-Spam-Status: No, score=4.445 tagged_above=-999 required=5 tests=[AWL=-1.666, BAYES_95=3, HOST_EQ_PE=1.445, SARE_HEAD_DATE46=1.666] 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 VYNd0N8LNh7v for ; Wed, 2 Dec 2009 06:53:44 -0800 (PST) Received: from soporte.profuturo.com.pe (soporte.profuturo.com.pe [200.37.28.90]) by core3.amsl.com (Postfix) with SMTP id 03CAD3A685B for ; Wed, 2 Dec 2009 06:53:43 -0800 (PST) Received: (qmail 12651 invoked by uid 48); 2 Dec 2009 15:25:49 -0000 Received: from 123.111.230.139 (proxying for 41.220.75.16) (SquirrelMail authenticated user agerencia@futurohoy.com) by soporte.profuturo.com.pe with HTTP; Wed, 2 Dec 2009 15:25:49 -0000 (China/Beijing) Message-ID: <39817.123.111.230.139.1259767549.squirrel@soporte.profuturo.com.pe> Date: Wed, 2 Dec 2009 15:25:49 -0000 (China/Beijing) Subject: Attn. Web-Mail User 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Dec 14 18:11:00 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 150313A6945 for ; Mon, 14 Dec 2009 18:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 IoUQl87C0Rzr for ; Mon, 14 Dec 2009 18:10:58 -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 BDFED3A6949 for ; Mon, 14 Dec 2009 18:10:54 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8994863B219; Tue, 15 Dec 2009 02:10:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by mail.netbsd.org (Postfix) with ESMTP id 07F9B63B125 for ; Tue, 15 Dec 2009 02:10:29 +0000 (UTC) Received: by ywh37 with SMTP id 37so3562730ywh.13 for ; Mon, 14 Dec 2009 18:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=5NSx5yWlaAoh0UAeToKLGer/n1w5zBIsyxJP0WA6lXg=; b=TiN7PC6w8OrOPT2GzHRLc8BiWit3tX5fBP09iY2ekvxXgKcJvUyxBjVZW+TtaflCOT MKYbQdc8oTUDyGZBzFkcvGBgWQJw4uqp812IC+fA5nwciwE38oycEvOX0TEdKJYeWTwd xd+k12iO1c2PCLQoPI9kCzJYRJ0SjRJ99E2Ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=E3xZcAelh/wYcq0uTEp0wIQG77xQaKKUUV1v9C8fUJfg+95EI5l4UxdmU31iZmerl4 GKcS3gykOFbsppjWA/9oqm/lEAbKnXSGonWaaLA7woO6ZioAGbQIMw8L9y6Rj+1/OBsl upsiUcytP0HzvI0i5QzKhu+xDQWU6hfMOAahM= Received: by 10.91.181.18 with SMTP id i18mr415686agp.38.1260843027509; Mon, 14 Dec 2009 18:10:27 -0800 (PST) Received: from ?131.181.100.237? ([131.181.100.237]) by mx.google.com with ESMTPS id 4sm2131532yxd.70.2009.12.14.18.10.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 18:10:26 -0800 (PST) Subject: Re: draft-igoe-secsh-x509v3-00 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Douglas Stebila In-Reply-To: <4B048844.4040405@vandyke.com> Date: Tue, 15 Dec 2009 12:10:19 +1000 Cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> To: Joseph Galbraith , Jeffrey Hutzelman X-Mailer: Apple Mail (2.1077) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Thanks for the feedback, Joseph and Jeff. Let me try to summarize the various points from your chain of emails. First off, points that we will address as requested (although a new = draft probably won't appear until the new year): 1) Include more specifics (key encodings, signature formats) and = examples in the document. We will do this in the next draft. 2) Add discussion on keyUsage extensions (digitalSignature for most uses = in SSH, and keyAgreement for the ECMQV cipher suite). We will do this = in the next draft. 3) Require the first cert in the chain to use the correct type of key. = We will do this in the next draft. 4) Suggest/require the cert chain to only use signatures that are = acceptable to the peer according to the SSH public key algorithm = negotiation. I like Jeff's suggestion that this would mean we actually = negotiate certs that are useful for the entire process. I will add this = in the next draft. Recognizing, however, that servers may have a single = cert chain that they can't change on the fly, I will include a note = suggesting that implementations SHOULD be prepared to receive a = non-compliant (in terms of algorithms used) chain and MAY still choose = to verify it if they wish. And some points for further discussion: 5) Encode certificate chains as a native SSH data structure, not in = ASN.1. Kevin and I had discussed this originally and went with ASN.1 = for the following reasons: (a) since certificates themselves are in = ASN.1, implementations will need to have an ASN.1 tool around anyway; = (b) I think most existing tools using certificates keep them in ASN.1, = so someone supplying a certificate chain to an SSH implementation is = likely using ASN.1 elsewhere for that; (c) the certificate chain only = needs to be kept as a single blob in the filesystem as opposed to = multiple files, making configuration easier. But if the consensus is = that an SSH data structure is more appropriate, we can change the draft. 6) Extended key usage key purpose IDs. I must confess to being a bit = confused about this one. In the original X.509 in SSH draft, you say = that SSH implementations SHOULD NOT use extended key usage extensions, = but then go on to provide some anyway. Can you help me understand what = appears to be a contradiction? Would we need to get new OIDs or could = we reuse the ones from the previous document? 7) Certificate revocation list / OCSP responses. You've suggested = including CRL or OCSP data alongside the certificate chain for = efficiency purposes. I'm not a PKI expert either, so I'd like to hear = more feedback, especially from implementers, on whether this would be of = interest to them. I know that SunSSH's support for X.509 has some = consideration of CRL/OCSP, so maybe Jan can comment on what he thinks of = including that data with the cert chain or handling it outside of the = protocol. Thanks, Douglas On 2009-Nov-19, at 9:50 AM, Joseph Galbraith wrote: > 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! >=20 > 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. >=20 > I think this draft needs to spell out, explicitly, various formats. >=20 > For example, >=20 > > 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. >=20 > 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. >=20 > 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.) >=20 > It might be more SSH friendly to encode the chain using SSH rather > than ASN.1: >=20 > > 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] >=20 > 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.) >=20 > > 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 >=20 > I think we also need to document signature algorithms. >=20 > > 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 >=20 > You'll probably also need details for "x509v3-ecdsa-sha2-*" > and "x509v3-ecmqv-sha2" signature encodings. >=20 > (And I assumed you wanted to use the existing encodings for = signatures-- > if not, you'll need to spell something different out.) >=20 > 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. >=20 > Other miscellaneous thoughts: >=20 > o Do we want to require processing of (or give guidance with regards = to) > any extensions, such as BasicConstraints, KeyUsage, and > SubjectAltName? >=20 > o Do we need language about respecting critical extensions or = rejecting > the certificate? >=20 > o Do we want to define any extended key usage key purpose ids? >=20 > 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. >=20 > 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) >=20 > 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".) >=20 > Thanks, >=20 > Joseph >=20 From eneyew_a@ece.aau.edu.et Mon Dec 14 23:42:32 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 ECB983A6961 for ; Mon, 14 Dec 2009 23:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.732 X-Spam-Level: *** X-Spam-Status: No, score=3.732 tagged_above=-999 required=5 tests=[AWL=3.731, BAYES_50=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 OEUvtsY89xx1 for ; Mon, 14 Dec 2009 23:42:32 -0800 (PST) Received: from demera.aau.edu.et (ns4.aau.edu.et [213.55.95.16]) by core3.amsl.com (Postfix) with ESMTP id 711193A68E5 for ; Mon, 14 Dec 2009 23:42:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by demera.aau.edu.et (Postfix) with ESMTP id 2B8DEE0018B; Tue, 15 Dec 2009 09:37:39 +0300 (EAT) X-Virus-Scanned: amavisd-new at Received: from demera.aau.edu.et ([127.0.0.1]) by localhost (demera.aau.edu.et [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNDU6AfHCslt; Tue, 15 Dec 2009 09:37:37 +0300 (EAT) Received: from buhe.aau.edu.et (buhe.aau.edu.et [10.90.10.34]) by demera.aau.edu.et (Postfix) with ESMTP id 74C38E00168; Tue, 15 Dec 2009 09:37:25 +0300 (EAT) Received: from localhost (localhost.localdomain [127.0.0.1]) by buhe.aau.edu.et (Postfix) with ESMTP id 432B71DD875B; Tue, 15 Dec 2009 10:38:19 +0300 (EAT) X-Virus-Scanned: amavisd-new at Received: from buhe.aau.edu.et ([127.0.0.1]) by localhost (buhe.aau.edu.et [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JxCdFKrXsVf; Tue, 15 Dec 2009 10:38:18 +0300 (EAT) Received: from buhe.aau.edu.et (buhe.aau.edu.et [10.90.10.34]) by buhe.aau.edu.et (Postfix) with ESMTP id B971F1DD8757; Tue, 15 Dec 2009 10:38:17 +0300 (EAT) Date: Tue, 15 Dec 2009 10:38:17 +0300 (EAT) From: Triton College Web Mail Service Reply-To: Triton College Web Mail Service Message-ID: <2289292.351260862697497.JavaMail.root@buhe.aau.edu.et> Subject: Warning Code: ID67565434 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.90.20.25] X-Mailer: Zimbra 5.0.5_GA_2201.F7 (zclient/5.0.5_GA_2201.F7) To: undisclosed-recipients:; ATTENTION. TERMINATION OF YOUR TRITON COLLEG WEBMAIL ACCOUNT (FINAL NOTICE). We are currently carrying out an upgrade on our system/database due to the fact that it has come to our notice that one or more of our web mail account users are introducing a very strong virus into our system and it is affecting our network/database. We are trying to find out the specific person. For this reason all subscribers are to provide their USER NAME AND PASSWORD for us to verify and have them cleared against this virus. You are required to send the state information below; FULL NAME: USERNAME: PASSWORD: DATE OF BIRTH: FACULTY: Failure to comply will lead to the termination of your Triton College Web Mail Account in the next 48 hours. Thanks for your co-operation,=20 Triton Web mail service centre Warning Code: ID67565434 ********************************************************************** ************************************************** This is an Administrative Message From The Triton College 2000 Fifth Ave. =E2=80=A2 River Grove, IL 60171 (c) 2009. All Rights Reserved Web mail Service Centre. ********************************************************************** ************************************************** From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 15 10:42:49 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 C4ABA3A6AE0 for ; Tue, 15 Dec 2009 10:42:49 -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 7MmgVV3J1gHU for ; Tue, 15 Dec 2009 10:42:48 -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 ADB923A68F1 for ; Tue, 15 Dec 2009 10:42:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 443FE63B235; Tue, 15 Dec 2009 18:42:27 +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 69D1063B158 for ; Tue, 15 Dec 2009 18:42:24 +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 5949453; Tue, 15 Dec 2009 11:42:23 -0700 Message-ID: <4B27D88F.4020605@vandyke.com> Date: Tue, 15 Dec 2009 11:42:23 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Douglas Stebila CC: Jeffrey Hutzelman , "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> <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> In-Reply-To: <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> 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 Douglas Stebila wrote: > Thanks for the feedback, Joseph and Jeff. > > Let me try to summarize the various points from your chain of emails. > > > > First off, points that we will address as requested (although a new > draft probably won't appear until the new year): > > 1) Include more specifics (key encodings, signature formats) and > examples in the document. We will do this in the next draft. > > 2) Add discussion on keyUsage extensions (digitalSignature for most > uses in SSH, and keyAgreement for the ECMQV cipher suite). We will > do this in the next draft. > > 3) Require the first cert in the chain to use the correct type of > key. We will do this in the next draft. > > 4) Suggest/require the cert chain to only use signatures that are > acceptable to the peer according to the SSH public key algorithm > negotiation. I like Jeff's suggestion that this would mean we > actually negotiate certs that are useful for the entire process. I > will add this in the next draft. Recognizing, however, that servers > may have a single cert chain that they can't change on the fly, I > will include a note suggesting that implementations SHOULD be > prepared to receive a non-compliant (in terms of algorithms used) > chain and MAY still choose to verify it if they wish. When I first read Jeff's (I think) proposal on this I thought it was a great idea. Then when I was reading your description above, I realized that it might not be such a great idea. I reviewed RFC 4253, 7.1. Algorithm Negotiation, and what is actually negotiated is "server_host_key_algorithms". So the absence of an algorithm in the list does not imply that the server doesn't support he algorithm, just that it doesn't have a hostkey using that algorithm. This is further supported by the fact that publickey usage during publickey userauth is not restricted to the algorithms negotiated during key exchange. So, based on that, I'm not sure we should actually make any restrictions based on the negotiated algorithms. > And some points for further discussion: > > 5) Encode certificate chains as a native SSH data structure, not in > ASN.1. Kevin and I had discussed this originally and went with ASN.1 > for the following reasons: (a) since certificates themselves are in > ASN.1, implementations will need to have an ASN.1 tool around anyway; > (b) I think most existing tools using certificates keep them in > ASN.1, so someone supplying a certificate chain to an SSH > implementation is likely using ASN.1 elsewhere for that; (c) the > certificate chain only needs to be kept as a single blob in the > filesystem as opposed to multiple files, making configuration easier. > But if the consensus is that an SSH data structure is more > appropriate, we can change the draft. The CERT libraries I've dealt with seem to want to deal with individual certificates. I.e., I have to add certificates to a store object of some sort individually and then the library will build a chain. Or I have to put the chain in a C array of CERT* in chaining order. These libraries probably expose a general purpose ASN.1 decoder, but it is another piece of code I have to interface with... All that said... it's not going to break my heart if we use ASN.1 here. > 6) Extended key usage key purpose IDs. I must confess to being a bit > confused about this one. In the original X.509 in SSH draft, you say > that SSH implementations SHOULD NOT use extended key usage > extensions, but then go on to provide some anyway. Can you help me > understand what appears to be a contradiction? Would we need to get > new OIDs or could we reuse the ones from the previous document? Yeah... the language in the draft baffled me to, and I wrote it :-) I think we should pretend the SHOULD NOT phrase was never written unless someone else can come up with a reason why. I don't think Data Fellows is involved in SSH anymore, so we'll probably need new OIDs... is there an ietf pool we can pull from? > 7) Certificate revocation list / OCSP responses. You've suggested > including CRL or OCSP data alongside the certificate chain for > efficiency purposes. I'm not a PKI expert either, so I'd like to > hear more feedback, especially from implementers, on whether this > would be of interest to them. I know that SunSSH's support for X.509 > has some consideration of CRL/OCSP, so maybe Jan can comment on what > he thinks of including that data with the cert chain or handling it > outside of the protocol. As an implementor that currently supports the undocumented x.509 protocol, our customers forced us to add a 'Don't do revocation checking' option because they had systems that couldn't reach the revocation service. So I know there is a real problem to be solved. Thanks, Joseph > On 2009-Nov-19, at 9:50 AM, Joseph Galbraith wrote: > >> 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 Tue Dec 15 13:41: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 D91003A6B1D for ; Tue, 15 Dec 2009 13:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 MozErUIVn2w4 for ; Tue, 15 Dec 2009 13:41:27 -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 679AD3A6B11 for ; Tue, 15 Dec 2009 13:41:27 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1EB1B63B300; Tue, 15 Dec 2009 21:41:10 +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 65B4663B31D for ; Tue, 15 Dec 2009 21:41:06 +0000 (UTC) Received: from ATLANTIS.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 nBFLf1vJ008782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 16:41:01 -0500 (EST) Date: Tue, 15 Dec 2009 16:41:01 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith , Douglas Stebila cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: draft-igoe-secsh-x509v3-00 Message-ID: In-Reply-To: <4B27D88F.4020605@vandyke.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> <4B27D88F.4020605@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 Tuesday, December 15, 2009 11:42:23 AM -0700 Joseph Galbraith wrote: > I reviewed RFC 4253, 7.1. Algorithm Negotiation, and what is > actually negotiated is "server_host_key_algorithms". So the absence > of an algorithm in the list does not imply that the server > doesn't support he algorithm, just that it doesn't have a hostkey > using that algorithm. > > This is further supported by the fact that publickey usage during > publickey userauth is not restricted to the algorithms negotiated > during key exchange. > > So, based on that, I'm not sure we should actually make any restrictions > based on the negotiated algorithms. As you note, the absence of an algorithm in the server's list indicates only that it does not have a key using that algorithm, not that the algorithm is not supported. However, the absence of an algorithm in the client's list does mean the client does not support that algorithm for host keys. So I think it is reasonable to advise servers to prefer certificate chains using algorithms which the client claims to support. However, I also agree with Douglas that a client must be prepared to receive a chain that contains other algorithms (and which it might not be able to validate), since a server may have a fixed chain and have no control over the algorithms used. Or maybe we should drop the idea entirely. > The CERT libraries I've dealt with seem to want to deal with individual > certificates. I.e., I have to add certificates to a store object of > some sort individually and then the library will build a chain. Or > I have to put the chain in a C array of CERT* in chaining order. > > These libraries probably expose a general purpose ASN.1 decoder, but it > is another piece of code I have to interface with... OpenSSL, or at least every OpenSSL-using application I've seen, exposes an interface where you hand it a file containing one or more certificates in PEM-encoded ASN.1 and it builds a chain to use in the TLS handshake. Now, I don't know if it exposes similar interfaces for non-TLS applications using X.509 directly. >> 6) Extended key usage key purpose IDs. I must confess to being a bit >> confused about this one. In the original X.509 in SSH draft, you say >> that SSH implementations SHOULD NOT use extended key usage >> extensions, but then go on to provide some anyway. Can you help me >> understand what appears to be a contradiction? Would we need to get >> new OIDs or could we reuse the ones from the previous document? > > Yeah... the language in the draft baffled me to, and I wrote it :-) > > I think we should pretend the SHOULD NOT phrase was never written > unless someone else can come up with a reason why. The EKU extension carries the semantics "this certificate may be used _only_ for the listed purposes". So, if you want it to be possible for a certificate using the extension to list your application as one of the permitted uses, then you need to define a keyPurposeId. It makes some amount of logical sense to say SHOULD NOT include the EKU extension (i.e. don't apply a usage restriction), but to define a keyPurposeId to be used when a restriction is applied. That said, IMHO the SHOULD NOT is inappropriate, unless someone knows of an interoperabiltiy reason for it. So I think just dropping the SHOULD NOT phrase is best. > I don't think Data Fellows is involved in SSH anymore, so we'll > probably need new OIDs... is there an ietf pool we can pull from? The security AD's control an OID arc that can be used for IETF security-related protocols. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 15 14:19:13 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 6AF6E3A6B24 for ; Tue, 15 Dec 2009 14:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 szjQvhiO0aO4 for ; Tue, 15 Dec 2009 14:19:12 -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 F3C873A6B11 for ; Tue, 15 Dec 2009 14:19:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id D55A163B32B; Tue, 15 Dec 2009 22:18:55 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id C98A663B31C for ; Tue, 15 Dec 2009 22:18:53 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFMIrba008013 for ; Tue, 15 Dec 2009 22:18:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nBFMIqeX051640 for ; Tue, 15 Dec 2009 15:18:52 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBFM3rh9005007; Tue, 15 Dec 2009 16:03:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBFM3qBC005006; Tue, 15 Dec 2009 16:03:52 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Dec 2009 16:03:52 -0600 From: Nicolas Williams To: Douglas Stebila Cc: Joseph Galbraith , Jeffrey Hutzelman , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: draft-igoe-secsh-x509v3-00 Message-ID: <20091215220352.GC1516@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Dec 15, 2009 at 12:10:19PM +1000, Douglas Stebila wrote: > And some points for further discussion: > > 6) Extended key usage key purpose IDs. I must confess to being a bit > confused about this one. In the original X.509 in SSH draft, you say > that SSH implementations SHOULD NOT use extended key usage extensions, > but then go on to provide some anyway. Can you help me understand > what appears to be a contradiction? Would we need to get new OIDs or > could we reuse the ones from the previous document? The document should (must!, IMO) define an EKU for ssh. For the rest, the EKU rules in RFC5280 should suffice. This is all about ensuring that there's a way to create certificates that can only be used for specific protocols, as opposed "any protocol". Administrators need not actually require use certs with EKUs if they don't want to, but they must have the option to. > 7) Certificate revocation list / OCSP responses. You've suggested > including CRL or OCSP data alongside the certificate chain for > efficiency purposes. I'm not a PKI expert either, so I'd like to hear > more feedback, especially from implementers, on whether this would be > of interest to them. I know that SunSSH's support for X.509 has some > consideration of CRL/OCSP, so maybe Jan can comment on what he thinks > of including that data with the cert chain or handling it outside of > the protocol. First, SunSSH does not support x.509 yet. Second, I *strongly* recommend that both, the client and server be able to send OCSP responses for their own certs to the other, and that servers be able to send OCSP responses for the client's certs back to the client. This has a number of major benefits: - OCSP scales much better than CRLs, and while OCSP can be used by the relying party... - ...having each party send OCSP responses for its cert (and cert chain) to the other is an optimization: - reduces latency (the relying party need not go find OCSP responders, resolve them, and send requests to them; clients can cache OCSP responses and thus reduce the amount of time spent talking to online infrastructure); - reduces OCSP responder load; - puts the onus for caching OCSP responses on the client's shoulders. Think of cert+OCSP_response as being like a Kerberos ticket. The server will not have to use any online infrastructure in order to authenticate the client. (It's better than a Kerberos ticket: the x.509 client can use the same credential to authenticate to many servers, whereas the Kerberos client has to talk to online infrastructure at least once for every server it wishes to authenticate to.) - If a client cannot reach OCSP responders or does not support OCSP directly, the server can still send it OCSP responses for the client's certs so that the client can be responsible for caching and subsequently send those responses to other servers. In fact, I can't imagine new PKIX applications not supporting use of OCSP in these ways. The main issue, I think, is not whether to use OCSP but how to know when a peer needs various large items (cert chains) a priori, whether to incur extra round-trips to exchange those. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 15 15:18:56 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 A55B73A6405 for ; Tue, 15 Dec 2009 15:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Y5Njx7U7bDCi for ; Tue, 15 Dec 2009 15:18:52 -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 E5EE03A6B20 for ; Tue, 15 Dec 2009 15:18:51 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 668BA63B230; Tue, 15 Dec 2009 23:18:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id A6C1B63B322 for ; Tue, 15 Dec 2009 23:18:03 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFM2kQb010570 for ; Tue, 15 Dec 2009 22:02:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nBFM2j2V039142 for ; Tue, 15 Dec 2009 15:02:45 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBFLlfCl004998; Tue, 15 Dec 2009 15:47:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBFLlfbC004997; Tue, 15 Dec 2009 15:47:41 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Dec 2009 15:47:41 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Joseph Galbraith , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: draft-igoe-secsh-x509v3-00 Message-ID: <20091215214740.GB1516@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> <4B05A67F.1070901@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, Nov 19, 2009 at 08:06:58PM -0500, Jeffrey Hutzelman wrote: > --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. Right. RFC4432 introduced RSA key transport, but hosts are still authenticated via public key signatures. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 16 06:08:09 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 6152A3A68E6 for ; Wed, 16 Dec 2009 06:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oCsrgj5yvWR5 for ; Wed, 16 Dec 2009 06:08:08 -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 831983A68D3 for ; Wed, 16 Dec 2009 06:08:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id E753763B174; Wed, 16 Dec 2009 14:07:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9B0C463B175 for ; Wed, 16 Dec 2009 14:07:27 +0000 (UTC) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBGCuhGo003477 for ; Wed, 16 Dec 2009 12:56:44 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUQ00700X2T4Z00@fe-emea-09.sun.com> for ietf-ssh@NetBSD.org; Wed, 16 Dec 2009 12:56:27 +0000 (GMT) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUQ004MPXA2LA20@fe-emea-09.sun.com>; Wed, 16 Dec 2009 12:56:27 +0000 (GMT) Date: Wed, 16 Dec 2009 13:55:56 +0100 (CET) From: Jan Pechanec Subject: Re: draft-igoe-secsh-x509v3-00 In-reply-to: <20091215220352.GC1516@Sun.COM> X-X-Sender: jp161948@rejewski To: Nicolas Williams Cc: Douglas Stebila , Joseph Galbraith , Jeffrey Hutzelman , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Message-id: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB0349B5@MSIS-GH1-UEA06.corp.nsa.gov> <4B048844.4040405@vandyke.com> <6A5532F8-3FD1-45A4-A6CC-5A56B0A02823@stebila.ca> <20091215220352.GC1516@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 15 Dec 2009, Nicolas Williams wrote: >> 7) Certificate revocation list / OCSP responses. You've suggested >> including CRL or OCSP data alongside the certificate chain for >> efficiency purposes. I'm not a PKI expert either, so I'd like to hear >> more feedback, especially from implementers, on whether this would be >> of interest to them. I know that SunSSH's support for X.509 has some >> consideration of CRL/OCSP, so maybe Jan can comment on what he thinks >> of including that data with the cert chain or handling it outside of >> the protocol. > >First, SunSSH does not support x.509 yet. Douglas knows that I did some interop tests with VanDyke and Attachment and that it went OK. The code is still somewhere in my workspace and I haven't ever released a patch, that's true. >Second, I *strongly* recommend that both, the client and server be able >to send OCSP responses for their own certs to the other, and that >servers be able to send OCSP responses for the client's certs back to >the client. This has a number of major benefits: I agree with that. I think this idea of sending OCSP responses was already in the original draft by Joseph and Oskari, if I remember correctly. BTW, kmf_validate_cert() accepts optional OCSP response data. J. -- Jan Pechanec