Subject: x.509 signature clarification?

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 5 Jul 2001 13:09:39 -0600

We've been looking at x.509 certificates, as specified in
the draft and as implemented by SSH Communications in their
3.0 release, and have come to the conclusion that the
draft is underspecified.

From the transport draft 4.6 (pg. 11):

> The "x509v3-sign-rsa" method indicates that the certificates, the public
> key, and the resulting signature are in X.509v3 compatible DER-encoded
> format. The formats used in X.509v3 is described in [RFC-2459]. This
> method indicates that the key (or one of the keys in the certificate) is
> an RSA-key.

Looking at RFC 2459, it appears that it describes the profile
for x.509 certificates, but doesn't really specify anything about 
signature encoding.  I think this reference can be dropped.

For x.509 certificates using rsa keys, SSH Communications 3.0
appears to be using PKCS #1 with MD5.  I'm not sure what they
are doing for DSS signatures.

There appears to be two areas where the draft needs clarification:

1. Which digest algorithm should be used?  (Given that we use
   SHA1 for ssh-rsa keys, this would seem the natural choice.)

2. What should the format of the signature be?

I'm tempted to suggest that the signature is in PKCS #7
format, though this seems to be a bit of an overkill...
it would however, address both the above problems, because
the digest algorithm would be specified as part of the PKCS #7
packet.  We might consider specifying a PKCS #7 signature,
with an "external signature" and no included certificates
or CRL information.

Joseph Galbraith
[email-masked]

---

From: Thor Simon <[email-masked]>
Date: Thu, 5 Jul 2001 15:50:15 -0400

> with an "external signature" and no included certificates

Actually, I think that if we were to go with PKCS #7 (which might
not really be such a bad idea) we'd want to fill out the certificate
as fully as possible, including CRL information.  Look what's happened
to people who've failed to do so (e.g. VeriSign, who ended up in the
unenviable position of having issued bogus certificates but being unable
to revoke them!).

Certainly we should not specify that the CRL field is *not* to be
filled in.

Thor

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 6 Jul 2001 13:36:10 -0600

> Certainly we should not specify that the CRL field is *not* to be

Hmm... the certificate itself has already
been communicated via the SSH protocol, which
is why I wrote what I did.  But, on the other hand,
it might be nice to be able to include other
certificates from the chain in the signature.

I think that CRLs in a PKCS #7 signature
are "hotlist" items intended as one method
of propagating revocations and to allow the
verifier to update it's certificate database.

They clearly can't be used to validate the
Certificate in use, since if I'm an attacker
using a compromised certificate, I'm certainly
not going to tell you it's been revoked!

On the other hand, it seems much cleaner to
 accept PKCS #7 entirely, rather then try
to specify PKCS #7 minus this feature and
that feature.  So, I think you're right,
if we decide to go with PKCS #7, we shouldn't
restrict what fields can be used.

I original thought that I PKCS #7 had a lot
of information that was not applicable to
SSH applications or was redundant... but,
on further thought, (and having actually
implemented a decoder / encoder now), it
seems that most of the information is useful
to us in the SSH context.  So perhaps PKCS #7
isn't an overkill.

Would implementers find it overly burdensome to
implement PKCS #7?  Or are most people using
crypto libraries that would already do this
for them?

For myself, my crypto library produces PKCS #7,
so it would actually be more convenient for me...
otherwise, I have to decode the PKCS #7 packet
on the signing side and build a PKCS #7 packet
on the verifying side.

Joseph Galbraith
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 07 Jul 2001 09:26:39 +0200

> are doing for DSS signatures.

I think it would make sense to use the same signature encoding as for
ssh-rsa.

> format, though this seems to be a bit of an overkill...

Do you think there's something wrong with the encoding used for
ssh-rsa and ssh-dss? If not, I think it is a bad idea to add
complexity by adding yet another encoding for the same thing.

I don't have any plans to support x.509 at all in the foreseeable
future, but if I did, I would want a single function for doing x.509:
I'd pass a the ssh "key-blob" and a "resource accessed" id (typically
username or hostname) to the x.509 code, and get back the public key,
or NULL if certificate and local configuration did not imply access
rights.

From then on, I'd like to be able to treat it as a vanilla rsa/dss key
and forget about x.509.

Regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Sat, 7 Jul 2001 17:41:52 +0200

>    SHA1 for ssh-rsa keys, this would seem the natural choice.)

yes, i think there is no reason to switch back to MD5,
so this is probably an implementation bug.  Older
software from F-secure uses MD5 for "ssh-rsa", too.

> format, though this seems to be a bit of an overkill...

i don't see why we cannot use the current "ssh-rsa" encoding:
transfer a x509 certificate in addition to "ssh-rsa" encoded
signature?

since "x509v3-sign-rsa" is not specified in detail, it should be
dropped from the draft and replaced by something like
	"x509v5-ssh-rsa"
meaning:
	public key is transfered in "x509v3" format and
	the current "ssh-rsa" is used for encoding for signatures.

i think all the confusion is due to the fact that a single
identifier is used for specifying to encoding of
	keys, certificates and signatures.

i don't see why the current signature formats cannot
be used together with x509 certificates.

-markus