parsing gpg-key block

[Ole Rixmann]

Hi Group,
i am very thankfull for the information i got about the rfc from dkg.

But now i have a problem which i can't solve with the rfc, so maybe
someone can help me again ;)

I am parsing a clear-signed signature of a text document (signature-type
0x01), the data to be signed is a json-string without newlines.... so
nothing to replace with <CR><LF>.

and the first 16 bits of my hash never match the first 16 bits provided
from the signature.... and as it is with hashs its hard to debug what is
wrong with my input...

a piece of example-data that i want to check:
{"2011-01-13 13:00":"cno","2011-01-13
14:00":"cno","2011-01-14":"cno","2011-01-15 13:00":"cno"}
this is prepended to the part of the signature-packet which is described
in section 5.2.4, although i'm not sure about my byte-array to string
conversion, but i first want to make sure that i'm not missing some
newlines or other data from the signed text....

maybe i should prepend this ?
(without the lines starting with -----) ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

{"2011-01-13 13:00":"cno","2011-01-13
14:00":"cno","2011-01-14":"cno","2011-01-15 13:00":"cno"}
-----BEGIN PGP SIGNATURE-----

or the json-string with a newline at the end?

Thanks in advance,
Ole Rixmann



Am 14.01.11 00:19, schrieb Daniel Kahn Gillmor:
> Hi Ole--
>
> On 01/13/2011 12:59 PM, Ole Rixmann wrote:
>> this is my first post ;)
> welcome!
>
>> I need to check gpg-rsa-signatures in JavaScript and for this to happen
>> i have
>> to parse key blocks produced with
>> "gpg --armor --export-options export-minimal --export 0xid".
>> To do the checking i need the rsa-parameters (like n and g) but i have
>> no clue how to extract them.
>> With "gpg --debug-all --list-packets keyfile" i get a whole lot of stuff
>> and i think the parameters are in there ;)
>> but it doesn't look good.
>>
>> So maybe someone can give me a hint?
> You're asking about some arcana, and your best reference for details is
> probably the RFC -- the OpenPGP format itself is specified in RFC 4880:
>
>   https://tools.ietf.org/html/rfc4880
>
> export-minimal will usually produce nothing but:
>
> Public Keys:
>
>   https://tools.ietf.org/html/rfc4880#section-5.5.2
>
> User IDs:
>
>  https://tools.ietf.org/html/rfc4880#section-5.11
>
> and self-issued signatures:
>
>  https://tools.ietf.org/html/rfc4880#section-5.2
>
> There may also be subkeys (which look like primary keys, but have a
> slightly different header), user Attributes (like user IDs, but jpegs
> instead of strings), and direct-key signatures.
>
> Signatures can of course have many different kinds of subpackets, which
> makes robust parsing of them a bigger project.  But if you just want the
> RSA key material, you can ignore the signatures of course.  This would
> mean that you wouldn't be able to verify that they key belongs to
> whoever you hope it belongs to (at least, not through OpenPGP).  Only
> you can say whether that tradeoff makes sense for your particular
> application.
>
>> I would also be interested in information about exactly how gpg does
>> signing wit rsa/sha-1.
> You probably want the info about "computing signatures":
>
>   https://tools.ietf.org/html/rfc4880#section-5.2.4
>
> hth,
>
> 	--dkg
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110122/8963a8b6/attachment.pgp>