Subject: I-D ACTION:draft-ietf-secsh-x509-02.txt

From: [email-masked]
Date: Fri, 15 Jul 2005 15:50:02 -0400

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 SSH2
	Author(s)	: O. Saarenmaa, J. Galbraith
	Filename	: draft-ietf-secsh-x509-02.txt
	Pages		: 8
	Date		: 2005-7-15
	
The X.509 extension specifies how X.509 keys and signatures are used
   within the SSH2 protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-x509-02.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.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 16 Jul 2005 18:34:00 +0200

>    within the SSH2 protocol.

*** EKU

RFC3280 claims serverAuth and clientAuth EKU is for
  -- TLS WWW server authentication
and
  -- TLS WWW client authentication

Sure you want to overload that meaning TLS and SSH server/client
authentication ?

Should my http possibly run with the same certificate as my ssh server? So
if my http server is compromised, it will expose my users to that stolen
certificate when they try to contant that server.

I think you should make up your own object identifiers.

*** PKCS.7

[PKCS.7.1993] is kind of oldish, RFC3852 defines CMS now.

*** Certificates

in "4.  Use in SSH2 Protocol" there is certificate data defined:

       string    DER encoded x.509v3 certificate data

How may certificates is this, one, or a chain ? If the pki is deeper then
grass, one level, (a real tree), it might good to send the whole chain
(excluding the trust anchor)

*** x509v3-sign

"4.3 x509v3-sign" talkes about "DER encoded PKCS7 data", I assume that is
DER encocded SignedData from CMS. I think that should be more explicit.

I read over the document again when get back from the movie.

Love