Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Jul 2016 19:02:16 +0300

On Mon, Jun 13, 2016 at 10:12:55AM +0000, Dang, Quynh (Fed) wrote:
> Hi all,
> 
> Prehash or non-prehash, choosing the one which works well for all uses
> (not just signing certs) is the right thing to do. I don¹t know how much
> the non-prehash version is actually used right now (different from how
> much it is supported in libraries).

Well, I think that anything that:
- technically _could_ sign "not technically constrained" CA certificate
  (regardless of if the key was ever intended to do that), and
- _could_ ever sign anything that even partially comes from external
  sources (this includes cross-certs).

Should use non-prehash.

The reason for this is that non-prehash versions look to be
_substantially_ weaker against attacks to the hash function (going by
historical percedent), and the ultimate nightmare scenario is attacker
managing to collide issued data with unconstrained CA certficate.

Also, if one looks at the basic signed data items that float around in
various PKIs, those include:

- Certificates
- OCSP responses
- CRLs

Now, certificates and should be fairly small. Few kilobytes (or at
most few tens of kilobytes for certs with PQ key in them) or so.

OCSP responses should be even smaller. On order of 100 bytes for
signed size?

This leaves CRLs, which could potentially be largish. But are
those actually used that much? I did search for CRL for one
practicular very high-activity WebPKI cert, and couldn't
find it (it might not even exist). 

So presumably using non-prehash for everything would be feasible.

-Ilari

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 22 Jul 2016 23:56:24 +0000

> Le 22 juil. 2016 à 18:02, Ilari Liusvaara <[email-masked]> a écrit :
> 

> […]

> find it (it might not even exist). 

I have encountered large CRLs in the past (large=tens of MB), and we’ll encounter more in the future.
With eIDAS, a CA issuing qualified certificates MUST produce CRLs containing expired certificates, so they will only be growing, and they’ll be used long after the certificate has expired (and also after the CA itself has expired). OCSP is not mandatory for such certificates.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 23 Jul 2016 07:15:33 +0300

> On 23 Jul 2016, at 2:56 AM, Erwann Abalea <[email-masked]> wrote:
> 
> 

CRLs are large, but they’re available all at once. You can’t sign them several entries at a time, because the tbsCertList is a SEQUENCE as is the revokedCertificates list. You have to have all the data up front with the length field.  Pre-hashing doesn’t save you from storing the entire CRL in memory.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Fri, 22 Jul 2016 22:21:48 -0700

On Jul 22, 2016 9:15 PM, "Yoav Nir" <[email-masked]> wrote:
> > With eIDAS, a CA issuing qualified certificates MUST produce CRLs
containing expired certificates, so they will only be growing, and they’ll
be used long after the certificate has expired (and also after the CA
itself has expired). OCSP is not mandatory for such certificates.
>
> CRLs are large, but they’re available all at once. You can’t sign them
several entries at a time, because the tbsCertList is a SEQUENCE as is the
revokedCertificates list. You have to have all the data up front with the
length field.  Pre-hashing doesn’t save you from storing the entire CRL in
memory.

PKCS 11 has an init, advance, finish API for signing. HSM devices might
have much less RAM then the hosts.

Of course this API can make signatures without prehashing any verifier will
verify, in one pass.
>
> Yoav
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Yoav Nir <[email-masked]>
Date: Sat, 23 Jul 2016 12:51:41 +0300

> On 23 Jul 2016, at 8:21 AM, Watson Ladd <[email-masked]> wrote:
> 
> 
> On Jul 22, 2016 9:15 PM, "Yoav Nir" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> > > On 23 Jul 2016, at 2:56 AM, Erwann Abalea <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >
> > >> Le 22 juil. 2016 à 18:02, Ilari Liusvaara <[email-masked] <mailto:[email-masked]>> a écrit :
> > >>
> PKCS 11 has an init, advance, finish API for signing. HSM devices might have much less RAM then the hosts.
> 
> 

Ah, OK, thanks. I get the issue now. BTW: the infamous DoD CRL went to hundreds, not tens of MB.

Yoav