[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: fredette@theory.lcs.mit.edu (Matt Fredette)*Subject*: Re: public key algorithm naming*From*: Carl Ellison <cme@Cybercash.COM>*Date*: Tue, 07 Apr 1998 10:40:57 -0400*Cc*: spki@c2.net*In-Reply-To*: <199804062210.AA02783@magpie.lcs.mit.edu>*Sender*: owner-spki@c2.net

-----BEGIN PGP SIGNED MESSAGE----- At 06:10 PM 4/6/98 -0400, Matt Fredette wrote: >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 3.8.3.1 <sig-val> in draft-ietf-spki-cert-structure-05.txt that >reads: > > 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. Matt, the reason to provide this outside the interior of an RSA block would be if the hash needs to be computed by one computer while another does the RSA operation. I have seen crypto processor designs that want the hash value (or the name of the hash algorithm and the actual message body) before they receive the signature value. BSAFE, for example, is constructed this way. So is RSAREF. Hardware devices that imitate those end up acting this way. With such an architecture, you need to know the hash algorithm before you have done the RSA operation. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQCVAwUBNSo6+BN3Wx8QwqUtAQF/pgQAiVWS03JHz9jwy7/+Y8of7pYe16u87qfB IW7WB63CnKFczV0rUUbX7Q9r4zlAyQHpfvU9S0JCeiqhs23jJtg5gTAuTUW5PQt6 4rAkR25UvLJbnAihvnAnL7DxQFMs1cbflzZ8W/0aP9tJfu41LSEWPrSUMuiH1FJQ TxObKR7TG+w= =8hhM -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+

**Re: public key algorithm naming***From*: fredette@theory.lcs.mit.edu (Matt Fredette)

- Prev by Date:
**Re: public key algorithm naming** - Next by Date:
**Re: public key algorithm naming** - Prev by thread:
**Re: public key algorithm naming** - Next by thread:
**Re: public key algorithm naming** - Index(es):