[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: public key algorithm naming
> Message-Id: <email@example.com>
> thanks for the discussion.
> I'd like to hear from others in the group as well. If it's just `
> the two of us, interested in this, we can have lunch in LA and work it out
> between us.
> - Carl
I just reread all of this thread. Here's what I've got:
> Message-Id: <199803122141.AA09925@magpie.lcs.mit.edu>
> IMO, the hash algorithm you use to sign is as important a part of "you"
> as your key parameters are. It serves to define you as much as anything,
> in the digital world, where everything comes from signatures. Listing
> your hash algorithm beside your key parameters gives it this important
> meaning - since keys get signed as parts of certificates and are also
> listed in ACLs. The way I see it, a signature from someone with your
> same key parameters but using a different hash function is not you.
This dates to the days, not so long ago :o, when I didn't know that PKCS-1
encodes the hash algorithm name into the value that is signed. Now that I
know that, my view of the world has changed a lot.
In a conversation Carl and I had at IETF, he remarked that he had convinced
Eric Rescorla that the signature encoding algorithm does need to be part
of a key's name. Here's the argument: if encoding algorithm could be
specified on a signature-by-signature basis, I might construct a new,
not-unreasonable encoding algorithm that, with certs of my choosing, lets
me reuse your RSA-PKCS1 signatures as signatures using my marvelous new
I'm assuming that everyone buys this (I do).
> Message-Id: <firstname.lastname@example.org>
> - Carl
> P.S. If we end up following your suggestion, of divorcing the
> hash algorithm from RSA key specifications, then that <sig-val> could
> hold the hash algorithm for informational use only. In fact,
> I realize now that the BNF does not need to change in response to the
> decision we make on this item ...
Right. To take the "informational" idea a little bit farther, I think that
<sig-val> should *never* hold the hash algorithm name when it can be inferred
(= it was specified as part of the signing key's name) or recovered (= the
encoding used by the signing key includes it). I.e., I think that the part
of Section 18.104.22.168 <sig-val> in draft-ietf-spki-cert-structure-05.txt that
For rsa-pkcs1 (should that option be preferred by the working group
over the specification of hash algorithm in the <pub-sig-alg-id>),
<sig-val> would need to be:
<sig-val>:: "(" "rsa-pkcs1-sig" <hash-alg-name> <byte-string> ")" ;
should be removed. This keeps all old signatures and signature parsers valid.
> Message-Id: <199803130009.QAA01360@itech.terisa.com>
> > On the other side of this, Ron Rivest far prefers to declare them up front.
> That wasn't quite what I understood Ron's position to be. Maybe we could
> get Ron to take a crack at explaining himself.
To try to summarize my position:
- I'd like to leave this unchanged from the current draft, and cement it:
<pub-sig-alg-id>:: "rsa-pkcs1-md5" | "rsa-pkcs1-sha1" | "rsa-pkcs1" |
"dsa-sha1" | <uri> ;
If someone using RSA wants to specify a hash that they'll stick with
forever, let them, but remind them that they can't change it - that
the hash name factors into hashes of the key and key equality tests,
and forces signatures to be made using that hash. If someone doesn't
want to specify their hash, also let them.
- For Section 22.214.171.124 <sig-val>, I'd like:
<sig-val> depends on the <pub-sig-alg-id> -- the algorithm listed in
the public key.
For rsa-pkcs1-md5 and rsa-pkcs1-sha1, <sig-val> is a <byte-string> --
the value of the RSA signature operation using the specified hash function.
For rsa-pkcs1, <sig-val> is a <byte-string> -- the value of the RSA
signature operation, using a hash function that was chosen at signing
For dsa-sha1, <sig-val> is a <dsa-sig-val>:
<dsa-sig-val>:: "(" "dsa-sha1-sig" "(" "r" <byte-string> ")"
"(" "s" <byte-string> ")" ")" ;
The patch release of my code coming out sometime this week will behave
email@example.com, firstname.lastname@example.org, email@example.com
The first time the Rolling Stones played, three people came."