jsdsi-users

[Jsdsi-users] Re: SPKI-related questions

[Sameer A. <aj...@gm...>]

Yes, JSDSI should be hashing the canonical representation of the
public key.  This is implemented using new Hash(principal), where
principal might be a PublicKey or PublicKeyHash.

S

P.S. I gave you the wrong address for the list: it's
jsd...@li...


On 6/6/05, ale...@f-...
<ale...@f-...> wrote:
> Hello Sameer,
>=20
> I sent the below message to jsdsi-users but received the "undeliverable"
> notification back. Would appreciate your help. Thank you.
>=20
>=20
> >Sure.  You should send mail to jsd...@sf... rather than directly
> >to me, as some of the other JSDSI developers may be better able to
> >answer your questions.
>=20
>=20
> Hello.
>=20
> When representing a principle by the hash of its public key,
> what exactly JSDSI applies the hash function to? Is that a full
> S-exp representation of the public key, like
> (10:public-key(14:rsa-pkcs1-sha1...)),
> or something different?
>=20
> Thank you.
>=20
> Regards,
>=20
> Alexey
>=20
>=20
>=20


--=20
Sameer
http://ajmani.net

[Jsdsi-users] Re: SPKI-related questions

[<ale...@f-...>]

Hello,

At 09:38 6.6.2005 -0400, Sameer Ajmani wrote:
>Yes, JSDSI should be hashing the canonical representation of the
>public key.  This is implemented using new Hash(principal), where
>principal might be a PublicKey or PublicKeyHash.


I may be in error, but apparently JSDSI computes hashes and signatures
not on object representations in certificates but on its own internal
representations, at least in some cases.
In our case, types of public keys were originally specified as "rsa-pkcs-sha1",
and JSDSI converted that to simply "rsa" (which is all right when done 
internally)
and then computed hashes and signatures with the short form of the type.
Sure, the result didn't match hashes and signatures in the certificates.

I believe this is not a correct behavior, because some things in SPKI are not
specified rigorously. Since different implementations may represent certain
types and objects in different, but valid, ways, all verification computations
should be applied to data found in certificates, in their original form.

I'd be happy to know that the above problem is due to my misunderstanding.
Otherwise, it's gonna be real hard to achieve JSDSI compatibility with other
implementations even in the simplest cases. I'd appreciate your comment.

Thanks.

Best regards,

Alexey

[Jsdsi-users] Re: SPKI-related questions

[Sameer A. <aj...@gm...>]

You are correct -- this is a bug.  The error is in jsdsi.PublicKey:
200 =09=09if (type.startsWith("rsa")) {
201 =09=09=09return RSAPublicKey.parseRSAPublicKey(key, "RSA", uris);

This ought to be:
return RSAPublicKey.parseRSAPublicKey(key, type, uris);

But I believe we changed it at some point because this type did not
match the algorithm names expected by the underlying crypto package.=20
But as you point out, this is clearly the wrong thing to do.  For now,
you might try changing this line to see if that fixes your problem.=20
If this fails in the crypto package, let us know.

Also, I noticed that there's some significant code duplication:
RSAPublicKey parseRSAPublicKey is copied twice with just a small
change in signature (URL vs. URI).  The right way to imeplement this
is for the URL version to conver the URLs to URIs (using
Util.convert()) and call the URI version.
Sean -- I believe you implemented this -- can you fix it?

Thanks,
Sameer

On 6/9/05, ale...@f-...
<ale...@f-...> wrote:
> Hello,
>=20
> At 09:38 6.6.2005 -0400, Sameer Ajmani wrote:
> >Yes, JSDSI should be hashing the canonical representation of the
> >public key.  This is implemented using new Hash(principal), where
> >principal might be a PublicKey or PublicKeyHash.
>=20
>=20
> I may be in error, but apparently JSDSI computes hashes and signatures
> not on object representations in certificates but on its own internal
> representations, at least in some cases.
> In our case, types of public keys were originally specified as "rsa-pkcs-=
sha1",
> and JSDSI converted that to simply "rsa" (which is all right when done
> internally)
> and then computed hashes and signatures with the short form of the type.
> Sure, the result didn't match hashes and signatures in the certificates.
>=20
> I believe this is not a correct behavior, because some things in SPKI are=
 not
> specified rigorously. Since different implementations may represent certa=
in
> types and objects in different, but valid, ways, all verification computa=
tions
> should be applied to data found in certificates, in their original form.
>=20
> I'd be happy to know that the above problem is due to my misunderstanding=
.
> Otherwise, it's gonna be real hard to achieve JSDSI compatibility with ot=
her
> implementations even in the simplest cases. I'd appreciate your comment.
>=20
> Thanks.
>=20
> Best regards,
>=20
> Alexey
>=20
>=20
>=20


--=20
Sameer
http://ajmani.net

[Jsdsi-users] Re: SPKI-related questions

[<ale...@f-...>]

Sameer,


>You are correct -- this is a bug.  The error is in jsdsi.PublicKey:
>...
>
>This ought to be:
>return RSAPublicKey.parseRSAPublicKey(key, type, uris);
>...
>If this fails in the crypto package, let us know.


Thanks for the prompt responding. We'll try what you suggest tomorrow,
I'll let you know the result.

Regards,

Alexey