Subject: Re: [Cfrg] Hash verifier's certificate and use of implicit certificates (was RE: Why hash verifier's key?)

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 11 Aug 2015 11:04:01 +0000

+1

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: William Whyte
Sent: Tuesday, August 11, 2015 07:00
To: Stephen Farrell; CFRG
Subject: Re: [Cfrg] Hash verifier's certificate and use of implicit certificates (was RE: Why hash verifier's key?)

Hi Stephen --

>> Bottom line: I think all of this would be better done at a higher
s/w layer, if at all. And this is also stuff to do later, if at
all, and not on this particular critical path.

I accept all that, but doesn't the same thing apply to taking the public key
as an additional input? I'm saying that either the signature algorithm
should have a "public key info" input that accepts more than simply the
public key, or it should all be handled at the application layer. I'm happy
with either of those but don't like requiring that the public key and only
the public key is input through a special additional API field.

This is slightly orthogonal to the question of whether or not to use
implicit certs, BTW. The primary value of hashing the cert is to avoid
misbinding attacks. It also happens to be the case that for implicit certs,
hashing the public key only causes a performance hit. So again the point is
not to require an API for hashing the cert, but to say that we should either
have a general public key info input or handle hashing the public key at the
application layer.

Cheers,

William

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, August 11, 2015 6:44 AM
To: William Whyte; CFRG
Subject: Re: [Cfrg] Hash verifier's certificate and use of implicit
certificates (was RE: Why hash verifier's key?)

Hi William,

On 11/08/15 11:03, William Whyte wrote:
> [certificate as input]

FWIW, I'm unconvinced that the added complexity of certificate
handling of any sort at this level is at all worthwhile. For
example, if the input is supposed to be a certificate, is the
signing engine supposed to verify that it's a "good" cert? That
would add huge mostly-useless complexity. If nothing is verified,
then why not suggest just being able to bind an additional octet
string? And in that latter case, why isn't that just a part of
the to-be-signed data? I don't think there's a useful thing to
do here in general.

If implicit certs do need a different API then by all means
someone can define one, but I don't think that niche should be
used to determine the generic API.

Lastly, including any such additional complexity will mean that
CFRG miss the boat for some IETF working groups that have been
waiting quite a while already for the new curves work to complete.
Adding new wrinkles at this stage in the game would be
counterproductive IMO, esp. when we're so close to being done.

Bottom line: I think all of this would be better done at a higher
s/w layer, if at all. And this is also stuff to do later, if at
all, and not on this particular critical path.

Cheers,
S.

_______________________________________________
Cfrg mailing list
[email-masked]
https://mail.ietf.org/mailman/listinfo/cfrg