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 14:58:50 +0000

I strongly support hashing certificate instead of public key, and think it would make much more sense.

And an entity verifying signatures but not validating certificates involved - how reasonable is that...?
‎
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Farrell
Sent: Tuesday, August 11, 2015 10:16
To: William Whyte; CFRG
Subject: Re: [Cfrg] Hash verifier's certificate and use of implicit certificates (was RE: Why hash verifier's key?)

On 11/08/15 15:08, William Whyte wrote:
> NC(PK) SHOULD
> be ENC(A), the encoding of the public key, and is ENC(A) unless otherwise
> specified, but MAY be an application-specified identifier for the public
> key such as a public key certificate. ***

I still have the same issue with that. Either the signer checks
something or it does not. If it does not, the change is pointless
and all can and should be done via a higher level API. If the signer
does check something then we're back to the fatal error as well
as the s/w engineering complexity downsides involved in any
certificate checking of any sort. And that's not to mention the
issue that the signer cannot always know the inputs the verifier
will use to check a certificate, e.g. years later.

Sorry to be negative... but I'm completely negative wrt this change;-)

S.

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

---

From: Taylor R Campbell <[email-masked]>
Date: Tue, 11 Aug 2015 15:34:18 +0000

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

   And an entity verifying signatures but not validating certificates
   involved - how reasonable is that...?

Bake a code-signing public key into your application and it can verify
updates without exposing itself to the large class of vulnerabilities
demonstrated in OpenSSL x.509 ASN.1 parsing code.

If you later want to include a notion of certification or delegation
you can push an update that includes logic to do that.  But there's no
need to impose that complexity a priori.

---

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

>demonstrated in OpenSSL x.509 ASN.1 parsing code.

Yes… But keys tend to outlive their usefulness, so to say… And as time
goes by, reliance on (and use of) “raw” public keys IMHO would diminish.

>need to impose that complexity a priori.

You have a point. I’d still say that one should be able to include in the
hash either a public key (for now :) OR a certificate, with my preference
towards certificate. Yes I realize that allowing both types would require
some signaling - unless unambiguously clear from the protocol itself.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 11 Aug 2015 19:10:06 +0300

> goes by, reliance on (and use of) “raw” public keys IMHO would diminish.

In any sort of "online" scenario, certificates are just pointless
complexity. Raw public keys are entierely appropriate for such uses,
while certificates are inappropriate.

-Ilari

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 11 Aug 2015 09:54:28 -0700

I have an alternative idea. Maybe protocols which use certificates and need to prevent identity misbinding should sign something which includes the certificates. Maybe that something could be, say, the hash of all the handshake messages which have been exchanged so far. Does this sound like a good mitigation?

Cheers,
-- Mike

Sent from my phone.  Please excuse brevity and typos.

>> On Aug 11, 2015, at 09:10, Ilari Liusvaara <[email-masked]> wrote:
>>

---

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

>while certificates are inappropriate.

I completely don’t understand this. E.g. Is TLS (or IPsec) an “online”
scenario? Is S/MIME...?