Re: x509

[Markus Friedl <markus%openbsd.org@localhost>]

> > 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.

ok, but 'blobs' using non-transport-draft types are usually encoded as
	string	blob

> > 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
> :-).

hm, a "zero length string" would be
	int32	0

> 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)

-m