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

Re: public key algorithm naming

> Message-Id: <3ogyelfij.fsf@kmac.terisa.com>
> fredette@theory.lcs.mit.edu (Matt Fredette) writes:
> > > Message-Id: <>
> > 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
> > encoding.
> Matt, I'm having a really hard time reading your message to see
> what it is you currently believe. Is the above text a quote or
> your current position?

Yeah, I had a hard time presenting that bit.  It's both a quote of Carl
and something that I agree with.  Carl helped me out with:

] Message-Id: <>
] Eric,
]         Matt's wording was a little muddled here.  PKCS-1 *is* the encoding
] algorithm he was talking about.
]         What you and I agreed was that the PKCS-1 needs to be specified.  
] If all you specify is "rsa", then I have an unpacking algorithm that can 
] pull the hash of my own construction out of an RSA-PKCS1 block.


> > 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.
> To be honest, this seems like a bad plan. Better to come down on one
> side or the other than to allow both.

Allowing both doesn't bother me, but that's just me.  What kind of problems
do you see?

> > -  For Section <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 
> >    time.
> This doesn't seem very convenient. Having the digest algorithm name 
> available separately is an excellent idea from an implementation
> perspective. In particular, some crypto APIs do not actually let you
> get the text that was signed, but rather require you to input the
> digest, with an API like so:

OK, I agree, and note that the algorithm used is still available separately
in the current grammar, in the <hash> in <signature>.

] >There's another quibble I have with all of this: PKCS-1 is both
] >a message padding AND a format for RSA key encoding. But PKIX does
] >NOT use the PKCS-1 RSA key encoding. Consequently, having a 
] >key tagged as rsa-pkcs1 seems kind of confusing.
] Are you suggesting we should write and name our own packing algorithm?
] What does PKIX call its algorithm?
]  - Carl

I guess it's bad foresight that they talked about two things (message
padding and key encoding) in one document.  But since it's very clear in
SPKI that we only use an S-expression format for RSA keys, typing those
S-expressions rsa-pkcs1, to talk about the message padding, also doesn't 
bother me.  It's not 100% crystal clear, but it's not too bad.


Matt Fredette
fredette@bbnplanet.com, fredette@mit.edu, fredette@theory.lcs.mit.edu
"The first time the Rolling Stones played, three people came."