Subject: Re: [Curdle] Some work for the group

From: Daniel Migault <[email-masked]>
Date: Thu, 9 Mar 2017 16:44:56 -0500

Hi,

The pkix draft blocks the publication of other drafts so  we need to move
it forward as soon as possible. The blocking discussion whether or not we
should have the EdDSA prehash version for CA. Currently, the choice between
the two variants is rather seen as a policy choice from the CA and I have
not seen any strong argument for not having this variant. Interoperability
issue has been raised, but not exposed.

If there are any strong argument against having the two variants please
provide them clearly by March 14 on the list.

If we have no strong reasons against having the two variants, I suggest we
agree on an updated version with the two variants  before the IETF in
Chicago. Does it sounds reasonable for everyone ?

Yours,
Daniel

On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault <[email-masked]
> wrote:

> Thanks for the information Nikos.
>
> I agree that we should find a concensus on whether the pre-hashed version
> should considered or not.
>
> One reason for not considering it is interoperability issue. Could we
> describe them a bit deeper ?
>
> Yours,
>
> Daniel
>
> -----Original Message-----
> From: Nikos Mavrogiannopoulos [mailto:[email-masked]]
> Sent: Monday, February 20, 2017 4:39 AM
> To: Brian Smith <[email-masked]>
> Cc: Daniel Migault <[email-masked]>; Phillip Hallam-Baker <
> [email-masked]>; Dang, Quynh (Fed) <[email-masked]>; Jim
> Schaad <[email-masked]>; Curdle <[email-masked]>; Salz, Rich <
> [email-masked]>
> Subject: Re: [Curdle] Some work for the group
>
> On Thu, 2017-02-02 at 19:13 -1000, Brian Smith wrote:
> > Nikos Mavrogiannopoulos <[email-masked]> wrote:
> > > Brian Smith wrote:
> > > > Besides the security issue, my understanding is that using the
> > > > prehash variant would result in lots of interop failures as,
> > > > AFAICT, there isn't going to be much support for it in
> > > > verification libraries.
> > >
> > > Isn't that orthogonal to the question? If the prehash version is
> > > going to cause interop issues is not affected by the text quoted
> > > above.
> > > Your
> > > comment is on whether including the prehashed version at all.
> >
> > No, it's not orthogonal. If we don't include the prehash version at
> > all, there won't be interop failures. Again, I don't see any
> > significant support for the prehash variant on the verification side.
>
> As I said your argument is about adding this variant, and not about the
> actual question which is whether it should be treated specially with
> regards to CA usage.
>
> > It's a bad idea to let or encourage CAs sign things using an algorithm
> > that most verifiers are unlikely to implement.
>
> Could you please clarify what do you mean by most? (I personally intended
> to implement only the prehashed variant not the other because it is the
> only variant that be used with HSMs). However, if there is a consensus that
> the prehashed variant shouldn't be used, we shouldn't drag it in the
> proposal.
>
> regards,
> Nikos
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Mar 2017 08:24:49 +0000

> Chicago. Does it sounds reasonable for everyone ?

Sorry - I don't recall the arguments for supporting both.
And we ought I think be against multiple options where
those are not needed.

Can you summarise the argument as to why we need both
variants? (A pointer to the list archive will be fine
if that's all that's needed.)

Thanks,
S.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 10 Mar 2017 03:45:53 -0500

I believe [1] that started the thread we have not really been able to find
consensus.  [2] provides one justification for restricting the adoption of
only one variant, but I do not see this strongly supported.

My understanding of the situation is that there is a demand for supporting
both variant and we do not have strong argument saying only one needs to be
supported.
If a single variant is adopted for now, I would like to avoid is to design
something that prevent the adoption of the pother variant later if needed.

Yours,
Daniel

[1] https://www.ietf.org/mail-archive/web/curdle/current/msg00544.html
[2] https://www.ietf.org/mail-archive/web/curdle/current/msg00561.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Mar 2017 09:01:01 +0000

Thanks Daniel,

> both variant and we do not have strong argument saying only one needs to be

FWIW, I'm not sure that I've seen any strong support for adding the
pre-hash variant from those who implement or deploy but I might
have missed that. I don't think "but we might want to do it in
future" is good enough for that.

The reason I'm pushing back on this is that if we get even a few CAs
using pre-hash then everyone else will have to, or else we'll end up
with a lack of interop. Such interop breakage would provide a strong
argument to not define both options IMO.

> something that prevent the adoption of the pother variant later if needed.

That seems perfectly reasonable. Though even if an RFC says "you
MUST NOT do X" we can always later obsolete or update that with
another RFC that says "now you can do x":-)

Cheers,
S.

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Mar 2017 11:35:24 -0500

Does anyone see the need for pre-hash for anything other than CRLs?

Russ

> On Mar 9, 2017, at 4:44 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> The pkix draft blocks the publication of other drafts so  we need to move it forward as soon as possible. The blocking discussion whether or not we should have the EdDSA prehash version for CA. Currently, the choice between the two variants is rather seen as a policy choice from the CA and I have not seen any strong argument for not having this variant. Interoperability issue has been raised, but not exposed. 
> 
> If there are any strong argument against having the two variants please provide them clearly by March 14 on the list. 
> 
> If we have no strong reasons against having the two variants, I suggest we agree on an updated version with the two variants  before the IETF in Chicago. Does it sounds reasonable for everyone ?
> 
> Yours, 
> Daniel 
> 
> 
> 
> 
> 
> On Mon, Feb 20, 2017 at 9:32 AM, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> I agree that we should find a concensus on whether the pre-hashed version should considered or not.
> 
> One reason for not considering it is interoperability issue. Could we describe them a bit deeper ?
> 
> Yours,
> 
> Daniel
> 
> From: Nikos Mavrogiannopoulos [mailto:[email-masked] <mailto:[email-masked]>]
> To: Brian Smith <[email-masked] <mailto:[email-masked]>>
> Cc: Daniel Migault <[email-masked] <mailto:[email-masked]>>; Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>>; Dang, Quynh (Fed) <[email-masked] <mailto:[email-masked]>>; Jim Schaad <[email-masked] <mailto:[email-masked]>>; Curdle <[email-masked] <mailto:[email-masked]>>; Salz, Rich <[email-masked] <mailto:[email-masked]>>
> > Nikos Mavrogiannopoulos <[email-masked] <mailto:[email-masked]>> wrote:
> > > Brian Smith wrote:
> As I said your argument is about adding this variant, and not about the actual question which is whether it should be treated specially with regards to CA usage.
> 
> Could you please clarify what do you mean by most? (I personally intended to implement only the prehashed variant not the other because it is the only variant that be used with HSMs). However, if there is a consensus that the prehashed variant shouldn't be used, we shouldn't drag it in the proposal.
> 
> regards,
> Nikos
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 18:48:10 +0200

> Does anyone see the need for pre-hash for anything other than CRLs?

I don't. AFAICT, even 4kB is plenty for most certificates (even blogspot
certs, which have lots of SANs fit into 4kB).

The only objects in PKIX that aren't very likely to fit into 4kB are
CRLs.

-Ilari

---

From: Daniel Migault <[email-masked]>
Date: Mon, 13 Mar 2017 10:45:14 -0400

Hi,

My current understanding is that the consensus on using the pure variant
only except for CRL, and that CRL may use the prehash.

If anyone disagrees, please let us know.

Yours,
Daniel

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 13 Mar 2017 16:40:19 +0100

On Mon, 2017-03-13 at 10:45 -0400, Daniel Migault wrote:
> Hi, 
> 
> My current understanding is that the consensus on using the pure
> variant only except for CRL, and that CRL may use the prehash. 

I am not sure what are you asking to disagree with. What would agreeing
with that statement imply? I have not seen, in the mailing list at
least, a discussion which can be summarized as the consensus is that
only CRLs may use the prehash. 

If for example, it works for CRLs why not for signing large files?

To clarify, my point is raising the issue with the pre-hashed algorithm
previously, is to prevent hashing context-specific algorithms or
algorithms with restrictions in a new document. If an algorithm is bad
or has no usefulness, it should not be defined at all, period. If it is
known to be of use, has no weaknesses and can be used fine, there
should be no exceptions or asterisks. If your intention is to put
another MUST NOT for that particular algorithm, I'm against this.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Mar 2017 15:44:17 +0000

The pre-hash is not known to be bad, although it can be risky for some systems. The goal is to not have risky things if we don't need them. So far, the only use-case that has had support is CRL's, which are less likely to be risky since the same keypair generally signs certificates. In the interest of progressing the draft, we are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all other uses.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Mar 2017 19:21:33 +0200

Speaking as an implementer of a relying party, if pre-hash is a MAY for CRLs on the CA side, it becomes a MUST on the relying party side. I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement it if I want interoperability.  I also MUST implement the non pre-hashed EdDSA, because certificates are very likely to be signed with that.

So unless there’s a very good reason to sign CRLs with the pre-hashed version, I’d rather that it be MUST NOT for all uses.

The claim has been made that future hardware (current hardware does not implement EdDSA) will not be able to hold an entire CRL all at once in memory, and therefore will need to be fed this CRL one chunk at a time, implying the need for a pre-hash. However, the size of CRLs is entirely determined by CA policy. The size of a CRL is bounded by the number of certificates that share the same CDP. A CA can set this value to any number from 1 to all the certificates ever issued, and it can set the value so that it fits the hardware limitations without pre-hashing.

I don’t think forcing the relying parties (all several billions of them) to implement both variations is better than forcing CAs to adjust the parameter of ce

> On 13 Mar 2017, at 17:44, Salz, Rich <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Mar 2017 20:02:15 +0000

On 13/03/17 17:21, Yoav Nir wrote:
> Speaking as an implementer of a relying party, if pre-hash is a MAY
> for CRLs on the CA side, it becomes a MUST on the relying party side.
> I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement
> it if I want interoperability.  I also MUST implement the non
> pre-hashed EdDSA, because certificates are very likely to be signed
> with that.
> 
> So unless there’s a very good reason to sign CRLs with the pre-hashed
> version, I’d rather that it be MUST NOT for all uses.
> 
> The claim has been made that future hardware (current hardware does
> not implement EdDSA) will not be able to hold an entire CRL all at
> once in memory, and therefore will need to be fed this CRL one chunk
> at a time, implying the need for a pre-hash. However, the size of
> CRLs is entirely determined by CA policy. The size of a CRL is
> bounded by the number of certificates that share the same CDP. A CA
> can set this value to any number from 1 to all the certificates ever
> issued, and it can set the value so that it fits the hardware
> limitations without pre-hashing.
> 
> I don’t think forcing the relying parties (all several billions of
> them) to implement both variations is better than forcing CAs to
> adjust the parameter of ce

With no hats: +1

There's also the argument about rarely exercised code paths
bring a recipe for bad outcomes. It seems like the pre-hash
stuff will all be part of such code-paths.

S.

>> The pre-hash is not known to be bad, although it can be risky for
>> some systems. The goal is to not have risky things if we don't need
>> them. So far, the only use-case that has had support is CRL's,
>> which are less likely to be risky since the same keypair generally
>> signs certificates. In the interest of progressing the draft, we
>> are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST
>> NOT for all other uses.
>> 
>> -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team 
>> _______________________________________________ Curdle mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/curdle
> 
> 
> 
> _______________________________________________ Curdle mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/curdle
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Mar 2017 20:18:54 +0000

Speaking as an individual, and a member of a team likely to implement this (OpenSSL), I am also against pre-hash; I think Yoav has provided an adequate work-around.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 14 Mar 2017 08:59:44 +0100

On Mon, 2017-03-13 at 15:44 +0000, Salz, Rich wrote:
> them.

I guess your definition of risky here is that it is as secure as the
existing signature schemes?

>  So far, the only use-case that has had support is CRL's, which are
> less likely to be risky since the same keypair generally signs
> certificates. In the interest of progressing the draft, we are asking
> if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all
> other uses.

I disagree. It should not be defined _at all_. There is very little
point to define a signature scheme which is used for some purposes
only. It would be unique, and would introduce complexity that is
unnecessary. There are other signature schemes that work fine
irrespective of the input size.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 14 Mar 2017 10:32:48 +0100

> irrespective of the input size.

And to clarify further. If I remember well, I had added the pre-hashed
option in the early draft of Simon and my hope was to spark discussion
and decide on a single variant, _not_ to have both in the final
document. I was expecting the pre-hashed to be standardized due to the
fact that it does not require changes to existing APIs to be used, and
does not require the whole data for signing. The other option would
need more implementation work, but on the other hand bring additional
benefits in terms of digital signature guarantees.

That's why I insist on dropping the pre-hashed variant at this point.
If there is no support for it being the main algorithm, it should not
be there. Supporting both variants with one specially limited, it would
only lead to incompatibilities and complex code. Incompatibilities
because some implementations will chose the easy path of including the
variant that fits their existing design (pre-hashed more likely), and
complex code because at some point they will figure they  have to
support both variants to be compatible with certs or CRLs issued by XYZ
CA.

If there is need for the pre-hashed variant, it can be done in a
different document.

regards,
Nikos

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 11:49:59 +0000

Hi Yoav,

Is it reasonable to think that there will be constrained devices which need to handle CRL lists ?

If the answer is yes, without the pre-hash option, those devices would need to either: (1) buffer large messages (costly) or (2) verify multiple CRL lists every time (costly) if the CA creates multiple CRL lists every time with the non-prehash option.

If only one option were to be used, the pre-hash would be the best choice because it works well everywhere, not like the non-prehash one.

Quynh.

From: Curdle <[email-masked]<mailto:[email-masked]>> on behalf of Yoav Nir <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 13, 2017 at 12:21 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>, Curdle <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Curdle] Some work for the group

On 13 Mar 2017, at 17:44, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
The pre-hash is not known to be bad, although it can be risky for some systems. The goal is to not have risky things if we don't need them. So far, the only use-case that has had support is CRL's, which are less likely to be risky since the same keypair generally signs certificates. In the interest of progressing the draft, we are asking if pre-hash is a MAY for CRL's and a SHOULD NOT or MUST NOT for all other uses.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz
_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 14:37:14 +0200

The code that I write generally runs on devices no weaker than phones. I don’t know if there are constrained devices that will need to handle CRLs. The trend seems to be moving away from CRLs and adopting OCSP responses instead.

It seems odd to me to believe that embedded systems will process CRLs in a time where web browsers running on PCs have stopped doing that. Even if they do, making really small CRLs for them seems like a good idea.  But stapling OCSP responses seems like an even better idea.

Yoav

> On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> From: Curdle <[email-masked] <mailto:[email-masked]>> on behalf of Yoav Nir <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: Nikos Mavrogiannopoulos <[email-masked] <mailto:[email-masked]>>, Curdle <[email-masked] <mailto:[email-masked]>>
>>> On 13 Mar 2017, at 17:44, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
>>> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 12:44:32 +0000

From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 14, 2017 at 7:37 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Rich Salz <[email-masked]<mailto:[email-masked]>>, Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>, Curdle <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Curdle] Some work for the group

It seems odd to me to believe that embedded systems will process CRLs in a time where web browsers running on PCs have stopped doing that. Even if they do, making really small CRLs for them seems like a good idea.

That would be costly because they need to verify multiple signatures every time.

Quynh.

 But stapling OCSP responses seems like an even better idea.

Yoav

On 14 Mar 2017, at 13:49, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Yoav,

Quynh.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 12:43:37 +0000

Hiya,

(No hats still:-)

> which need to handle CRL lists ?

One could imagine a universe in which that mattered, but it
is not this universe. Memory constrained devices that need to
consume giant CRLs do not seem to be real. But feel free
to point me at a product data sheet if there is one.

IMO real constrained devices will not be downloading giant
CRLs for power and/or bandwidth reasons. (Well, and because
it'd be silly;-)

> 
> If the answer is yes, without the pre-hash option, those devices
> would need to either: (1) buffer large messages (costly) or (2)
> verify multiple CRL lists every time (costly) if the CA creates
> multiple CRL lists every time with the non-prehash option.
> 
> If only one option were to be used, the pre-hash would be the best
> choice because it works well everywhere, not like the non-prehash
> one.

"Everywhere" there really meaning "that other universe where
giant CRLs for memory constrained devices matter"?

I think we can ditch or otherwise say to not use the pre-hash
stuff safely. Adding it or allowing its use is less safe.

(I'm not as hardline as Nikos that it ought not be defined at
all, but only because if we don't define it now with a MUST
NOT or SHOULD NOT, then someone will come along later and
define it causing all the confusion/complexity anyway so I
don't see that omitting it here gains that much, but I'd be
ok with doing so.)

Cheers,
S.

> 
> Quynh.
> 
> From: Curdle
> <[email-masked]<mailto:[email-masked]>> on behalf
> of Yoav Nir <[email-masked]<mailto:[email-masked]>> Date:
> Monday, March 13, 2017 at 12:21 PM To:
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>> Cc: Nikos
> Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>, Curdle
> <[email-masked]<mailto:[email-masked]>> Subject: Re: [Curdle] Some
> work for the group
> 
> On 13 Mar 2017, at 17:44, Salz, Rich
> <[email-masked]<mailto:[email-masked]>> wrote: The pre-hash is
> not known to be bad, although it can be risky for some systems. The
> goal is to not have risky things if we don't need them. So far, the
> only use-case that has had support is CRL's, which are less likely to
> be risky since the same keypair generally signs certificates. In the
> interest of progressing the draft, we are asking if pre-hash is a MAY
> for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior
> Architect, Akamai Technologies Member, OpenSSL Dev Team IM:
> [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 14:51:47 +0200

> On 14 Mar 2017, at 14:44, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> 
> 
> From: Yoav Nir <[email-masked] <mailto:[email-masked]>>
> To: 'Quynh' <[email-masked] <mailto:[email-masked]>>
> Cc: Rich Salz <[email-masked] <mailto:[email-masked]>>, Nikos Mavrogiannopoulos <[email-masked] <mailto:[email-masked]>>, Curdle <[email-masked] <mailto:[email-masked]>>

Why?  I don’t know much about embedded devices but I do know that they almost always connect to the same server (often a cloud-based mothership) all the time.  These are not browsers.

Yoav

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 13:18:29 +0000

Stephen,

Your point is very perfect to me!

We, the IETF, are a very important international standard body and our standards and recommendations have tremendous impact on improving security and services that the internet provides.

I would like our products to continue to provide great solutions to as many users as possible.   At least, when signing large files, the pre-hash works better than the non-prehash. And, the hash-then-sign scheme has worked well since the digital signature was invented when the hash function is secure.

Regards,
Quynh.

From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 14, 2017 at 7:43 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, Yoav Nir <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>, Curdle <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Curdle] Some work for the group

Hiya,

(No hats still:-)

On 14/03/17 11:49, Dang, Quynh (Fed) wrote:
Hi Yoav,
Is it reasonable to think that there will be constrained devices
which need to handle CRL lists ?

Cheers,
S.

Quynh.
From: Curdle
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> on behalf
of Yoav Nir <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> Date:
Monday, March 13, 2017 at 12:21 PM To:
"[email-masked]<mailto:[email-masked]><mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> Cc: Nikos
Mavrogiannopoulos <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, Curdle
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> Subject: Re: [Curdle] Some
work for the group
Speaking as an implementer of a relying party, if pre-hash is a MAY
for CRLs on the CA side, it becomes a MUST on the relying party side.
I MAY receive a CRL signed with pre-hashed EdDSA, so I MUST implement
it if I want interoperability.  I also MUST implement the non
pre-hashed EdDSA, because certificates are very likely to be signed
with that.
So unless there’s a very good reason to sign CRLs with the pre-hashed
version, I’d rather that it be MUST NOT for all uses.
The claim has been made that future hardware (current hardware does
not implement EdDSA) will not be able to hold an entire CRL all at
once in memory, and therefore will need to be fed this CRL one chunk
at a time, implying the need for a pre-hash. However, the size of
CRLs is entirely determined by CA policy. The size of a CRL is
bounded by the number of certificates that share the same CDP. A CA
can set this value to any number from 1 to all the certificates ever
issued, and it can set the value so that it fits the hardware
limitations without pre-hashing.
I don’t think forcing the relying parties (all several billions of
them) to implement both variations is better than forcing CAs to
adjust the parameter of ce
On 13 Mar 2017, at 17:44, Salz, Rich
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote: The pre-hash is
not known to be bad, although it can be risky for some systems. The
goal is to not have risky things if we don't need them. So far, the
only use-case that has had support is CRL's, which are less likely to
be risky since the same keypair generally signs certificates. In the
interest of progressing the draft, we are asking if pre-hash is a MAY
for CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior
Architect, Akamai Technologies Member, OpenSSL Dev Team IM:
[email-masked]<mailto:[email-masked]><mailto:[email-masked]> Twitter: RichSalz
_______________________________________________ Curdle mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________ Curdle mailing list
[email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/curdle

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Mar 2017 11:05:04 -0400

> On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
>> Even if they do, making really small CRLs for them seems like a good idea.
> 
> 

Quynh:

That is not correct.  The CRL Distribution Point (CRLDP) extension in a certificate identifies the (small) CRL that will include the certificate if it is ever revoked.  The replying party only needs to check the identified CRL.  See Section 4.2.1.13 of RFC 5280 if you want details.

Russ

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 17:04:44 +0000

Hi Russ,

From: Russ Housley <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 14, 2017 at 10:05 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Curdle <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Curdle] Some work for the group

On Mar 14, 2017, at 8:44 AM, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Quynh:

Right. So, the CA now needs to manage a growing number of distribution points for their certificates. I don’t see why the CA likes to do that to avoid a hash off-line.

Quynh.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Mar 2017 17:10:57 +0000

> Right. So, the CA now needs to manage a growing number of distribution points for their certificates. I don’t see why the CA likes to do that to avoid a hash off-line. 

They can be defined algorithmically, such as {fixedurl}/cert-serial-number  Or perhaps truncated part of the serial number.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 17:19:32 +0000

From: "Salz, Rich" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 14, 2017 at 12:10 PM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: Curdle <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Curdle] Some work for the group

Currently, it is so simple: just an URI. That method would require some sort of management scheme here. If a fixed URL is used, the client must verify the right digital signature among many others.

Quynh.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Mar 2017 17:26:26 +0000

I am sorry I wasn’t being clear.  The crlDP is in the certificate.  The CA can generate the value algorithmically and divide it up into as small pieces as needed, statelessly.  A client can fetch just the CRL(s) it needs.  A CA for IoT doesn’t need one CRL that covers all devices, and pre-hash doesn’t seem needed (not speaking as chair).

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 17:35:42 +0000

Date: Tuesday, March 14, 2017 at 12:26 PM

I am sorry I wasn’t being clear.  The crlDP is in the certificate.  The CA can generate the value algorithmically and divide it up into as small pieces as needed, statelessly.  A client can fetch just the CRL(s) it needs.

This creates things more complicated and more room for errors for both sides unnecessarily.

A CA for IoT doesn’t need one CRL that covers all devices, and pre-hash doesn’t seem needed (not speaking as chair).

The point is which option works better.

Quynh.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Mar 2017 17:53:44 +0000

> This creates things more complicated and more room for errors for both sides unnecessarily. 

Since the replying party already needs to know about crlDP, how does it complicate clients?  I can see that it is a bit more work for CA's.

> The point is which option works better.

There are many metrics to consider, including if having two algorithms globally deployed is part of being better.

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Mar 2017 14:00:31 -0400

> Right. So, the CA now needs to manage a growing number of distribution points for their certificates. I don’t see why the CA likes to do that to avoid a hash off-line. 

This is not the list for this discussion, but CAs use CRLDP so that they can manage the maximum size of the CRLs.  This helps relying parties by avoiding the latency for a large download.

Russ

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 17:58:05 +0000

Date: Tuesday, March 14, 2017 at 12:53 PM

Hi Rich,

I think that only the pre-hash version  would be the best.

Quynh.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 18:37:31 +0000

Hi Quynh,

I'm sorry but I've no idea how your mail is responsive to mine.

To re-iterate: there is IMO no justification at all for pre-hash
based on constrained devices and CRLs.

Your arguments that there are are unconvincing.

And nobody has pointed at any real device that does need
pre-hash.

Cheers,
S.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Mar 2017 22:49:14 +0000

Yoav Nir <[email-masked]> writes:

>It seems odd to me to believe that embedded systems will process CRLs in a
>time where web browsers running on PCs have stopped doing that. Even if they
>do, making really small CRLs for them seems like a good idea.  But stapling
>OCSP responses seems like an even better idea.

SCADA stuff typically doesn't process CRLs, but for an entirely different
reason than you think.  If you revoke a process controller's cert, it can take
it offline, which is the worst thing that can happen.  So CRLs are ignored, as
is OCSP.  Expiry dates in certs are also ignored (I'm currently involved in a
discussion over whether setting an expiry year of '9999' is valid according to
the X.509 spec), for the same reason, and because in SCADA you care about
availability, not enforcing the CA's 12-month billing cycle.

Also, ID information is frequently ignored because there's no meaningful way
to represent it in a cert, the device is identified by post-cert-use protocols
(e.g. DNP3 when run over TLS).

The only bit that consistently isn't ignored is the public key.  You
parse/pass over the cert contents until you get to the subjectPublicKeyInfo,
then extract what's there and go with that.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 22:55:22 +0000

On 14/03/17 22:49, Peter Gutmann wrote:
> (I'm currently involved in a
> the X.509 spec),

We standardised a value for "never." I forget where that's defined
but I bet Russ knows:-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 22:58:32 +0000

> We standardised a value for "never." I forget where that's defined

Ah - there it is, in 5280:-) [1]

"
   To indicate that a certificate has no well-defined expiration date,
   the notAfter SHOULD be assigned the GeneralizedTime value of
   99991231235959Z.
"

S.

[1] https://tools.ietf.org/html/rfc5280#section-4.1.2.5

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Mar 2017 19:11:19 -0400

> On Mar 14, 2017, at 6:55 PM, Stephen Farrell <[email-masked]> wrote:
> 

Russ

---

From: [email-masked]
Date: Tue, 14 Mar 2017 22:25:13 -0400

It complicates the clients by requiring the client to make sure that it got the correct partition.

Sent from my iPhone

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Mar 2017 02:26:32 +0000

> It complicates the clients by requiring the client to make sure that it got the

It is in the certificate as the crlDistributionPoint extension, which the client should already handle

---

From: [email-masked]
Date: Tue, 14 Mar 2017 22:36:19 -0400

It probably not relate to the topic at hand but what you say is insufficient.  See RFC 5280 or use common sense 

When the CA signs bunch of partitions to mitigate substitution attack the IDP in the partition must be matched with the CDP in the certificate

I won't belabor this but suggest you read section 6 of RFC 5280 carefully. 

Sent from my iPhone

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Mar 2017 02:41:53 +0000

> I won't belabor this but suggest you read section 6 of RFC 5280 carefully.

Please do explain more.  If the key signing an entire CRL is the same as the key signing CDP CRL's, and the revocation list is partitioned solely to make it smaller, such as to fit in an IoT lightbulb, then what changes?

But separate from that, do you want pre-hash signatures supported?  You would be the second person.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 08:24:15 +0200

Hi, Santosh

Partitioning one big CRL into two CRLs makes things more complicated. That is true.

But partitioning the CRL into 1000 small pieces instead of 100 medium-sized pieces adds a little processing requirement to the CA, but no additional complexity for either side.

As it is, all CAs partition their CRLs. The complexity already exists on all sides. And relying parties have to make sure they got the right CRL anyway since they have no way of knowing whether or not the CA partitions the CRL.

So in summary, CRLs are already partitioned. We don’t think CRL processing is even a thing on constrained devices, but in case we’re wrong all that is needed to make CRLs smaller is a tweak of parameter on the CA with zero additional code.

Yoav

> On 15 Mar 2017, at 4:36, [email-masked] wrote:
>

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 15 Mar 2017 16:49:27 +0000

> Le 14 mars 2017 à 23:49, Peter Gutmann <[email-masked]> a écrit :
> 

31/12/9999 is a valid date (so far).
31/12/1999 23:59:59 may not exist (we don’t know yet if a negative leap second will be introduced), and it may not be the last second of the day (positive leap second). However, as a magical value, 99992131235959Z is a correct GeneralizedTime.
99991231235960 is also a correct GeneralizedTime. 99991231240000 isn’t.

Anyway, for X.509, the nextUpdate field of a CRL is optional. Only RFC2459+ makes it mandatory.
X.509 CRL processing algorithm (Annex C) correctly handles a missing nextUpdate.

Cordialement,
Erwann Abalea

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 18:56:20 +0200

> On 15 Mar 2017, at 18:49, Erwann Abalea <[email-masked]> wrote:
> 
>> 
> 31/12/1999 23:59:59 may not exist

I was there…

;-)

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 15 Mar 2017 17:10:18 +0000

Bonjour,

> Le 14 mars 2017 à 19:37, Stephen Farrell <[email-masked]> a écrit :
> 
> 
> Hi Quynh,
> 

I did. On Safenet LunaCA4 (I don’t remember the firmware version), sending more than 2 or 3MB for signing (with a CKM_RSA_PKCS mechanism) returns an error.
I don’t remember the exact error, we switched to hash the payload on caller side, and I don’t know if the error persists with later versions (LunaCA4 is a discontinued product).

Cordialement,
Erwann Abalea

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Mar 2017 13:59:47 -0400

Rich,

I have not read up on the pre hash to opine.  So, I will pass on it since I
do not want to render an uninformed opinion.  That is why I said this does
not relate to issue at hand....(because I do not have an opinion, informed
or otherwise).  Also, I do not implement things.  So, my views if there are
any would be useful in security and interoperability context.  

I am happy to answer your question on CRL.  (I chimed in because I did not
wish implementers to implement PK enablement insecurely).  So, let us say
that CA signs full and complete CRL and partitions CRL1, CRL2, CRLn.  What
determines that a CRL is full and complete, is the absence of IDP in CRL.  I
am keeping this simple to not get into indirect CRL etc.  So, when the
client does not see an critical IDP extension, it knows the CRL is complete
and can use it to determine the revocation status of any certificate issued
by the CA.

Now, let us say that a Certificate with serial  X has CRL DP whose DP point
is X.  Let us say CA asserts X in the IDP of CRLm.  Now, if you went to the
CRL DP, assuming we do not trust the Internet and the CRL DP serving
resource (which typically is not CA), if it served any of the CRLs other
than CRLm, you are guaranteed to not see X in the list even if revoked.
That is because the CA advertises it to appear only in CRLm.  To mitigate
this threat, the DP in CRL DP of the certificate must be matched to the DP
in IDP if IDP is present and DP is present in the IDP.  All of this is
codified in X.509 and in 5280.

If you still wish to discuss, I recommend we have a private communication
since I am sure this is either old hat to folks on the list or they do not
care.

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 10:42 PM
To: [email-masked]
Cc: Dang, Quynh (Fed) <[email-masked]>; Russ Housley
<[email-masked]>; Curdle <[email-masked]>
Subject: RE: [Curdle] Some work for the group

> I won't belabor this but suggest you read section 6 of RFC 5280 carefully.

Please do explain more.  If the key signing an entire CRL is the same as the
key signing CDP CRL's, and the revocation list is partitioned solely to make
it smaller, such as to fit in an IoT lightbulb, then what changes?

But separate from that, do you want pre-hash signatures supported?  You
would be the second person.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Mar 2017 14:03:14 -0400

Yoav,

For most of your comments, I agree.

But I would not say most CA partition CRL or how do you know you got the right partition. 

Implementations I deal with issue CRL without IDP ensuring CRL are complete.  IDP in CRL is supposed to be critical so that relying parties know that it could be a partition.  I am being succinct rather than a big discussion on it.  You can read the X.509 Normative Annex or RFC 5280 get additional details and refinements.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2017 2:24 AM
To: [email-masked]
Cc: Rich Salz <[email-masked]>; Dang, Quynh (Fed) <[email-masked]>; Curdle <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: [Curdle] Some work for the group

Hi, Santosh

Yoav

> It probably not relate to the topic at hand but what you say is 
> insufficient.  See RFC 5280 or use common sense
> 
> When the CA signs bunch of partitions to mitigate substitution attack 
> the IDP in the partition must be matched with the CDP in the 
> certificate
>

---

From: Carl Wallace <[email-masked]>
Date: Wed, 15 Mar 2017 14:31:55 -0400

On 3/15/17, 2:24 AM, "Curdle on behalf of Yoav Nir"
<[email-masked] on behalf of [email-masked]> wrote:

>But partitioning the CRL into 1000 small pieces instead of 100
>medium-sized pieces adds a little processing requirement to the CA, but
>no additional complexity for either side.
>
>As it is, all CAs partition their CRLs. The complexity already exists on
>all sides. And relying parties have to make sure they got the right CRL
>anyway since they have no way of knowing whether or not the CA partitions
>the CRL.
>
>So in summary, CRLs are already partitioned. We don’t think CRL
>processing is even a thing on constrained devices, but in case we’re
>wrong all that is needed to make CRLs smaller is a tweak of parameter on
>the CA with zero additional code.

Tweaking so the partition size is one would yield a per end user
certificate CRL. Every cert would get a unique DP, these corresponding
CRLs could be stapled easily to anything, downloading would be faster
where necessary and the overall bandwidth usage more efficient in some
cases than OCSP since each CRL would report only the status of the
certificate of interest. The revocation status of unused or seldom used
certificates would never impact any relying party. We're pretty far beyond
the hurdles to using partitioned CRLs, even if full CRLs remain the
preferred choice in some environments.

>>the IDP in the partition must be matched with the CDP in the certificate
>> 
>>>> It complicates the clients by requiring the client to make sure that
>>>>it got the
>>>> correct partition.

I don't see where checking a partitioned CRL to make sure you have the
right one need be any more complicated than making sure you have the right
OCSP response. It eliminates some potential issues that may occur when
interacting with an OCSP responder, i.e., no potential for the responder
to elect to use a different hash algorithm than found in the request,
which really complicates knowing if you got the right response.

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Mar 2017 14:52:09 -0400

> On Mar 15, 2017, at 2:31 PM, Carl Wallace <[email-masked]> wrote:
> 
> 

I think you are suggesting that the Certificate would contain the CRLDistributionPoints extension with something like this:

   DistributionPoint ::= SEQUENCE {
        distributionPoint containing a URL like http://the_CAs_domain/crl/cert_serial_number.crl <http://the_cas_domain/crl/cert_serial_number.crl> }

Then, the CRL would contain the IssuingDistributionPoint extension with something like this:

   IssuingDistributionPoint ::= SEQUENCE {
        distributionPoint containing a URL like http://the_CAs_domain/crl/cert_serial_number.crl <http://the_cas_domain/crl/cert_serial_number.crl> }

If the two URLs are not exactly the same, then the relying party would have to fetch the CRL using the URL in the certificate.

Computing the signatures for single-certificate CRLs is exactly the same about of work for the CA as pre-computing an OCSP responses for each certificate.

Russ

---

From: Carl Wallace <[email-masked]>
Date: Wed, 15 Mar 2017 14:59:01 -0400

>> <snip>
> I think you are suggesting that the Certificate would contain the
> CRLDistributionPoints extension with something like this:
> 
>         distributionPoint containing a URL like
> http://the_CAs_domain/crl/cert_serial_number.crl }
> 
>         distributionPoint containing a URL like
> http://the_CAs_domain/crl/cert_serial_number.crl }
> 
> If the two URLs are not exactly the same, then the relying party would have to
> fetch the CRL using the URL in the certificate.
> 
> Computing the signatures for single-certificate CRLs is exactly the same about
> of work for the CA as pre-computing an OCSP responses for each certificate.

Right. I agree similar workload for CA as responder, but less bandwidth and
less work for the relying party assuming the OCSP responses contain > 1
certificates.  You make a good point though that the certificate provides an
easy failover if a substitution is attempted (same as with OCSP). One knock
is substantially more use of the CA key (vs delegation) but not having to
check delegation also results in less work for the relying party.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 21:32:03 +0000

On 15/03/17 17:10, Erwann Abalea wrote:
>> And nobody has pointed at any real device that does need pre-hash.
> 
> I did. On Safenet LunaCA4 (I don’t remember the firmware version),
> sending more than 2 or 3MB for signing (with a CKM_RSA_PKCS
> mechanism) returns an error. I don’t remember the exact error, we
> switched to hash the payload on caller side, and I don’t know if the
> error persists with later versions (LunaCA4 is a discontinued
> product).

Small, challenged, internet of (crap) things devices won't
be signing CRLs. I'm personally not concerned about CA signing
devices, if someone wants to design one of those to support
eddsa and build in such a limitation then they deserve what
they get IMO.

So I don't consider that a real device of the type in
question nor do I consider it a reason to include pre-hash.

S.

> 
> Cordialement, Erwann Abalea
> 
>> 
>> Cheers, S.
>> 
>>> We, the IETF, are a very important international standard body
>>> and our standards and recommendations have tremendous impact on
>>> improving security and services that the internet provides.
>>> 
>>> I would like our products to continue to provide great solutions
>>> to as many users as possible.   At least, when signing large
>>> files, the pre-hash works better than the non-prehash. And, the
>>> hash-then-sign scheme has worked well since the digital signature
>>> was invented when the hash function is secure.
>>> 
>>> Regards, Quynh.
>>> 
>>> From: Stephen Farrell
>>> <[email-masked]<mailto:[email-masked]>> 
>>> Date: Tuesday, March 14, 2017 at 7:43 AM To: 'Quynh'
>>> <[email-masked]<mailto:[email-masked]>>, Yoav Nir
>>> <[email-masked]<mailto:[email-masked]>>,
>>> Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>,
>>> Curdle <[email-masked]<mailto:[email-masked]>> Subject: Re:
>>> [Curdle] Some work for the group
>>> 
>>> 
>>> Hiya,
>>> 
>>> (No hats still:-)
>>> 
>>> On 14/03/17 11:49, Dang, Quynh (Fed) wrote: Hi Yoav, Is it
>>> reasonable to think that there will be constrained devices which
>>> need to handle CRL lists ?
>>> 
>>> One could imagine a universe in which that mattered, but it is
>>> not this universe. Memory constrained devices that need to 
>>> consume giant CRLs do not seem to be real. But feel free to point
>>> me at a product data sheet if there is one.
>>> 
>>> IMO real constrained devices will not be downloading giant CRLs
>>> for power and/or bandwidth reasons. (Well, and because it'd be
>>> silly;-)
>>> 
>>> multiple CRL lists every time with the non-prehash option. If
>>> only one option were to be used, the pre-hash would be the best 
>>> choice because it works well everywhere, not like the
>>> non-prehash one.
>>> 
>>> all, but only because if we don't define it now with a MUST NOT
>>> or SHOULD NOT, then someone will come along later and define it
>>> causing all the confusion/complexity anyway so I don't see that
>>> omitting it here gains that much, but I'd be ok with doing so.)
>>> 
>>> Cheers, S.
>>> 
>>> Quynh. From: Curdle 
>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
>>> on behalf of Yoav Nir
>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
>>> Date: Monday, March 13, 2017 at 12:21 PM To: 
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> Cc:
Nikos
>>> Mavrogiannopoulos
>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>,
>>> Curdle 
>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
>>> Subject: Re: [Curdle] Some work for the group Speaking as an
>>> implementer of a relying party, if pre-hash is a MAY for CRLs on
>>> the CA side, it becomes a MUST on the relying party side. I MAY
>>> receive a CRL signed with pre-hashed EdDSA, so I MUST implement 
>>> pre-hashed EdDSA, because certificates are very likely to be
>>> signed with that. So unless there’s a very good reason to sign
>>> CRLs with the pre-hashed version, I’d rather that it be MUST NOT
>>> for all uses. The claim has been made that future hardware
>>> (current hardware does not implement EdDSA) will not be able to
>>> hold an entire CRL all at once in memory, and therefore will need
>>> to be fed this CRL one chunk at a time, implying the need for a
>>> pre-hash. However, the size of CRLs is entirely determined by CA
>>> policy. The size of a CRL is bounded by the number of
>>> certificates that share the same CDP. A CA can set this value to
>>> any number from 1 to all the certificates ever issued, and it can
>>> set the value so that it fits the hardware limitations without
>>> pre-hashing. I don’t think forcing the relying parties (all
>>> several billions of them) to implement both variations is better
>>> than forcing CAs to adjust the parameter of ce On 13 Mar 2017, at
>>> 17:44, Salz, Rich 
>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
>>> wrote: The pre-hash is not known to be bad, although it can be
>>> risky for some systems. The goal is to not have risky things if
>>> we don't need them. So far, the only use-case that has had
>>> support is CRL's, which are less likely to be risky since the
>>> same keypair generally signs certificates. In the interest of
>>> progressing the draft, we are asking if pre-hash is a MAY for
>>> CRL's and a SHOULD NOT or MUST NOT for all other uses. -- Senior 
>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
>>> Twitter: RichSalz _______________________________________________
>>> Curdle mailing list 
>>> list [email-masked]<mailto:[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Mar 2017 00:01:05 +0200

> On 15 Mar 2017, at 19:10, Erwann Abalea <[email-masked]> wrote:
> 
> Bonjour,
> 
>> Le 14 mars 2017 à 19:37, Stephen Farrell <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> 
>> Hi Quynh,
>> 

Thanks, but 2-3 MB is quite large. Larger than any CRL I want to be downloading in the middle of a TLS handshake or an IKE exchange.

>60% of Internet users have connection speeds of under 10 Mbps (according to Akamai) and when we’re using mobile phones we’re often getting less than that.

I haven’t done a good survey, but checking a few CRLs (for google, the IETF and a few more) I found most real CRLs to be between many hundreds of bytes and a few tens of thousands of bytes. The largest I found was just over 1 MB.  The Safenet hardware can easily handle all of these.

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Mar 2017 23:26:01 +0000

Erwann Abalea <[email-masked]> writes:

>31/12/1999 23:59:59 may not exist (we don’t know yet if a negative leap
>second will be introduced), and it may not be the last second of the day
>(positive leap second). However, as a magical value, 99992131235959Z is a
>correct GeneralizedTime. 99991231235960 is also a correct GeneralizedTime.
>99991231240000 isn’t.

So the one problem with this approach, which I've mentioned to a few people
off-list, is that the original source of the question has identified
approximately zero implementations (he counted them twice) that support this
special-case date.  There's probably something out there somewhere that
implements it, but it's not going to fly for a general-use case.  My advice
was to just ignore cert expiry dates like everyone else in this situation
does, but apparently there's a requirement for standards-compliance... maybe I
should do an RFC on "How to make certs work with SCADA", a.k.a. "How to apply
common sense" (in other words nothing terribly clever, just some text that
people can point to to show they're complying with it).

Peter.

---

From: "Manger, James" <[email-masked]>
Date: Thu, 16 Mar 2017 02:17:07 +0000

Even "zero implementations" should still mean (almost) all implementations correctly treat 99991231235959Z as meaning "has not expired" for at least the next 7,982 years. Not long enough?

--
James Manger

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Thursday, 16 March 2017 10:26 AM
To: Erwann Abalea <[email-masked]>
Cc: Dang, Quynh (Fed) <[email-masked]>; Nikos Mavrogiannopoulos <[email-masked]>; Curdle <[email-masked]>; Yoav Nir <[email-masked]>; Rich Salz <[email-masked]>
Subject: Re: [Curdle] Some work for the group

Erwann Abalea <[email-masked]> writes:

>31/12/1999 23:59:59 may not exist (we don't know yet if a negative leap
>99991231240000 isn't.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Mar 2017 03:12:35 +0000

Manger, James <[email-masked]> writes:

>Even "zero implementations" should still mean (almost) all implementations
>correctly treat 99991231235959Z as meaning "has not expired" for at least the
>next 7,982 years. Not long enough?

It's more likely they'll treat it as "invalid date".  Any 32-bit
implementation will do so by default even if it tries to parse the value since
it's after 2038, and I'm assuming 64-bit ones reject it too based on it being
an obviously-invalid date value, thus the "zero implementations support this"
[0].  The "zero implementations support this" really does mean "zero
implementations support this", not "zero implementations support this but I
think they should so we'll assume they do".

Insert side-debate about how many crypto implementations happily accept any
old rubbish from the other side without any checking.  Missing key exchange in
the SSL handshake?  No problem, we'll continue with an all-zero key.  All-zero
data values in the signature on a file?  Seems legit, I'm sure they just
accidentally forgot to add the signature.  Etc.

Peter.

[0] Meaning, as mentioned previously, "we were unable to identify an
    implementation that supports this".

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 16 Mar 2017 09:55:04 +0100

On Thu, 2017-03-16 at 03:12 +0000, Peter Gutmann wrote:
> implementations support this", not "zero implementations support this
> but I think they should so we'll assume they do".

Which implementations have you checked? I was so surprised by your
statement (the Y2038 problem is known for so long, I doubt it is not
already solved in major implementations), that I actually checked both
openssl and gnutls on a 32-bit system.

On that system gnutls printed a certificate with the special date set
as expiring on:
  Thu Dec 31 23:23:23 UTC 2037 - the actual date gnutls will consider
it valid to

while openssl reported it as expiring on:
  Dec 31 23:59:59 9999 GMT - the date saved in the certificate

Both were able to validate the certificate on dates up to end of 2037.
OpenSSL could further validate the certificate for the first days of
2038. The system could not address time past that, so I gave up.

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Mar 2017 17:02:42 -0400

> On Mar 16, 2017, at 4:55 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

I am aware of one implementation skips the expiration check when is sees this value.

Russ

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Mar 2017 23:43:42 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>Which implementations have you checked? 

I didn't, the comment was forwarded to me one of the people who were
discussing it.  Since it's embedded, I'm guessing a pile of embedded
libraries, but I don't have any direct access to the discussion.

>  Dec 31 23:59:59 9999 GMT - the date saved in the certificate

What does a 32-bit version do?

My code just relies on mktime(), with two pages of special-case handling for
times close to 2038 (some mktime()s do odd things when you get within a few
years of that date), just plain broken mktime()s, and other oddities, e.g.:

	/* Some broken apps set dates to 1/1/1970, handling times this close 
	   to the epoch is problematic because once any possible DST 
	   adjustment is taken into account it's no longer possible to
	   represent the converted time as a time_t unless the system allows
	   it to be negative (Windows doesn't, many Unixen do, but having
	   cryptlib return a negative time value is probably a bad thing).  
	   To handle this, if we find a date set anywhere during January 1970 
	   we manually set the time to zero (the epoch) */

So on a 64-bit system it'd do the same as OpenSSL and on a 32-bit system it'd
do whatever the local mktime() ends up doing, provided one of the many fixup
checks aren't triggered in which case it'll get pegged at the time_t version
of 0 or INT_MAX.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 17 Mar 2017 10:39:37 +0100

> What does a 32-bit version do?

My comments were for the 32-bit versions of gnutls and openssl.

> checks aren't triggered in which case it'll get pegged at the time_t

What we used in gnutls is to include a correct mktime() and have dates
after 2038 map to the time_t representing 2037-12-31 23:23:23 in 32-bit 
systems (I believe that was originally used by gnupg).

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Mar 2017 10:21:10 +0000

>My comments were for the 32-bit versions of gnutls and openssl.

Hmm, I wonder how it manages to deal with a date past 2038 when time_t is 32-
bits?

>What we used in gnutls is to include a correct mktime() and have dates after
>2038 map to the time_t representing 2037-12-31 23:23:23 in 32-bit systems (I
>believe that was originally used by gnupg).

I thought about doing that, but then it wouldn't be consistent with the
system-provided mktime(), and some customers value consistency above accuracy
- having my code provide a different time value than the system mktime() is a
bad thing, even if the system mktime() is wrong.  For example the Tandem NSK
mktime() gets funny for dates after about 2030, but since it's used by some
very large banks and they don't want inconsistency in the handling of time
values, the system mktime() gets used, warts and all.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 17 Mar 2017 12:52:56 +0000

> Hmm, I wonder how it manages to deal with a date past 2038 when time_t is
> 32- bits?

OpenSSL does not use time_t for its cert date manipulations.