[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGNATURE in spki-960705.txt
Paul,
At 01:55 PM 7/5/96 -0700, PALAMBER.US.ORACLE.COM wrote:
>>SIGNATURE: <hash alg>,<PK alg>,<sig value>,<body hash>
>
>This seems too complicated... why not just define a "signature" in your
>notation as:
>
>SIGNATURE: <sig value>
[...]
>SIG-TYPE: <sig type value>
>SIGNATURE: <sig value>
>
>So, SIGNATURE is a mandatory field (in the context of our signed object
>discussion) and SIG-TYPE is optional. The definition of the information
>carried in "sig value" would be based on the type indicated by SIG-TYPE
>(either implicitly or explicitly). This reduces the information carried by
>signatures using the recommended set of algorithms.
That was my original inclination. However, I believe we need to expect a
variety of PK algorithms. We have two already, each with its own community
of interest (RSA, DSA). We might also need to allow for a choice of hash
algorithms. I'm inclined to advocate SHA-1 and discount MD5 -- but who
knows when the next better hash algorithm will come along....
What I'm trying to avoid is a <sig type value> that looks like a symbol from
RSA's BSAFE (using "_" to concatenate different fields into a single very
long name). If you want SIG-TYPE, I'd want it to have:
SIG-TYPE: <hash_alg>,<PK_alg>,<pack_alg>
You might have it live inside the cert body (removing the desire to hash
those fields in with the <body hash>). However, we might find someone
signing a cert body with a Fortezza card using DSA while someone else signs
it with RSA. (e.g., in a DUAL-SIG cert which bridges between the Fortezza
and the RSA world). So -- it makes sense to bring it out of the cert body.
I included <body hash> in order to make it clear which cert or other thing
is being signed. It's my desire to have a signature be detached from the
thing it signs. The certificate body might even have been transmitted at a
different time and be in a local cache.
The signature is either a single line or a block.
So:
SIGNATURE: <hash_alg>,<PK_alg>,<pack_alg>,<sig_value>,<body_hash>
takes the place of
BEGIN: "signature on Carl's cert"
SIG-TYPE: <hash_alg>,<PK_alg>,<pack_alg>
SIGNED-THING: <body_hash>
SIGNATURE: <sig_value>
END:
However, I understand your desire. If you have the multi-line form, you can
have defaults (e.g., RSA, SHA-1, random padding, preceeding BEGIN/END block)
for each of the fields -- leaving you with only the SIGNATURE line, in which
case the BEGIN/END isn't necessary.
It certainly saves space ... but maybe not much. Each of the usual alg
fields is 1 byte long. The big space user is the <body_hash> at 18 to 22
bytes. For compactness, we could have an abbreviation (like length 0) for
the body hash to mean "the body you last saw in this byte stream".
How do you feel about having additional variants of SIGNATURE in which some
fields are wired down, e.g.,
RSA-SHA-SIGNATURE: <sig_value>,<body_hash>
[meaning SIGNATURE: SHA-1,RSA,RandomMSB,<sig_value>,<body_hash> ]
and a similar
DSA-SHA-SIGNATURE: <sig_value>,<body_hash>
as long as we don't start enumerating all possible ones (and running low on
tag values)? [In those, we could have <body_hash> of length 0 mean "the
last body seen", although that's a slight complication in the parsing code.]
Back to you.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+--------------------------------------------------------------------------+