IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: x509



On Thu, 31 Jan 2002, Markus Friedl wrote:
> >      string    "ssh-rsa"
> >      string    dss_signature_value
> > 
> > dss_signature_value is the DER encoded value of the Dss-Sig-Value as
> > defined in rfc2459.

Ouch, the above should have been ssh-dss of course, copy/paste error :-).

> the exact format for a "x509v3-sign-rsa" type signature
> is not specified, i.e.:
> 
> is it
> 	string	"x509v3-sign-rsa"
> 	string	"DER-encoded format à la RFC2459"

This should be the right form (it's the only thing one can deduce from the
transport draft).

> because the definition for the "x509v3-sign-rsa" type cert is:
> 	string	"x509v3-sign-rsa"
> 	byte[n]	"DER-encoded cert"

Yes, but the encodings for ssh-dss/ssh-rsa keys and signature differs in
the same way (i.e. the key is byte[n] and the signature is enclosed in a
string.

> moreover, implementations supporting x509 (e.g. ssh.com)
> currently send
> 	string	"DER-encoded cert"
> without even sending the key type.

This is obviously wrong, since this is the only thing specifically stated
in the draft as:

   Certificates and public keys are encoded as follows:
     string   certificate or public key format identifier
     byte[n]  key/certificate data

This is a unique definition in my oppinion, though it has happened before
that ssh.com implementors have confused the definitions of byte[n] and
string if I remember it correctly...

> additionally, the draft says:
>    The key type MUST always be explicitly known (from algorithm
>    negotiation or some other source).  It is not normally included in
>    the key blob.
...
> so, i'm confused by the draft and the implementations.

Yeah, I totally agree that it's kind of confusing, however since it's
strictly defined in some sense (in the case of single keys/certs apart
from the sentence: "The certificate part may have be a zero length
string,..." which occurs after the definition) in the draft I don't care
:-).

However, the signature-blob should be equally well defined as you said
along the lines of:

   Signatures are encoded as follows:
     string   certificate or public key format identifier
     string   signature_blob (as defined by algorithm used)

OR, one might say that the format should be same as for 
Certificates/public keys with the argument that the ssh-dss/ssh-rsa 
signature_blob formats are really:

	string signature_blob (as defined by draft)

On the subject of whether to use PKCS7 or not I'm not sure what it would
add, it's a generic enclosure where the algorithm et.c. is explicitly
given along with some other specifics but the format of the signature
itself is still as defined in rfc2459 and PKCS1 (for DSA/RSA keys) hence
it would suffice IMHO to just use the formats defined without further
"complexity".

Cheers,

/Mats




Home | Main Index | Thread Index | Old Index