Subject: [Curdle] WGLC on draft-ietf-curdle-pkix-02

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Nov 2016 23:55:21 -0400

Hi,

This message starts a Working Group Last Call (WGLC) for
draft-ietf-curdle-pkix-02.

The version to be reviewed is
https://tools.ietf.org/html/draft-ietf-curdle-pkix-02

Please send your comments, questions, and edit proposals to the WG mail
list until November 16th, 2016.  If you believe that the document is ready
to be submitted to the IESG for consideration as a Standards Track RFC
please send a short message stating this.

Yours,

Rich and Daniel

---

From: Daniel Migault <[email-masked]>
Date: Sat, 5 Nov 2016 07:52:01 -0400

Hi,

I reviewed the current version of the draft. Most comments are editorial,
but I have two questions or clarifications. One concerns the use of ctx and
the other the restriction to non prehash signatures for CA.

Please find my comments/questions on the current draft below.

Yours,

Daniel

1.  Introduction

   In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards-
   curve Digital Signature Algorithm (EdDSA) is described along with a
   recommendation for the use of the Curve25519 and Curve448.  EdDSA has
   defined two modes, the PureEdDSA mode without pre-hashing, and the
   HashEdDSA mode with pre-hashing.  The Ed25519ph and Ed448ph algorithm
   definitions specify the one-way hash function that is used for pre-
   hashing.  The convention used for identifying the algorithm/curve

Josefsson & Schaad         Expires May 4, 2017                  [Page 2]

Internet-Draft            Safe curves for X.509             October 2016

   combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode,
   with Ed25519ph and Ed448ph for the HashEdDSA mode.  The use of the
   OIDs is described for public keys, private keys and signatures.

   MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] but
the current draft does not not seeem to consider Ed25519ctx in HashEdDSA
mode?
   OK the explanation is in section 6. Maybe that would worth mentioning
Ed25515ctx has not been ignored or forgotten. I understand the motivation
for not OIDzing Ed25515ctx now, but it looks to me strange that we only
partially standardize OIDs for EdDSA, by not considering context either in
Ed448 or Ed25515ctx. Would it be unreasonable to  add id-Ed448ctx and
id-Ed25519ctx while leaving id-Ed448 with null context ?

3.  Curve25519 and Curve448 Algorithm Identifiers

   In this document we defined six new OIDs for identifying the
   different curve/algorithm pairs.  The curves being Curve25519 and
   Curve448.  The algorithms being ECDH, EdDSA in pure mode and EdDSA in
   pre-hash mode.  For all of the OIDs, the parameters MUST be absent.
   Implementations SHOULD NOT accept a parameters value of NULL.

MGLT: ECDH has not been defined earlier. Introduction talks about Diffie
Hellamn. Maybe we could introduce ECDH in the intro while presenting the X*
notations.

4.  Subject Public Key Fields

   Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value
   as being a byte string.  It should be noted that the public key is
   computed differently for each of these documents, thus the same
   private key will not produce the same public key.

MGLT: Reading the text it looks to me the document are incompatible. Maybe
some text could clarify this situation. Even though the curves remains the
same in both document the described usage are different DH [RFC7748] or
signature [I-D.irtf-cfrg-eddsa]. In this case, this leads to different
public key associated to the same private key.

5.  Key Usage Bits

   CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
   the creation of certificates or CRLs.  This is implied by the fact
   that those algorithms are not listed in the previous paragraph.
   Additionally OCSP responders SHOULD NOT use the pre-hash versions of
   the EdDSA algorithms when generating OCSP responses.  No restriction
   is placed on generation of OCSP requests.

   AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
   the creation of attribute certificates or attribute CRLs [RFC5755].

MGLT: Just for clarification. We do not use the prehash version because the
signature input must be the key, and prehash considers the hash as outside
the signature scheme ? It looks to me that the constraint on CA is inspired
from the recommendations of RFC5755. Am I correct ?

6.  EdDSA Signatures

   In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context
   value, specific to an application, to be provided to the signing
   operation.  This value is used to force different signatures to be
   generated for different applications.  Along with the defintion of

 MGLT: s/defintion/definition

13.  Security Considerations

   In the original design of Ed25519 signatures, there was a known
   attack between the pure and the pre-hash version of the signatures.
   This has sense been corrected in the final version of the design.

 MGLT: s/sense/since

On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault <[email-masked]
> wrote:

> The version to be reviewed is https://tools.ietf.org/html/
> draft-ietf-curdle-pkix-02
>

---

From: Brian Smith <[email-masked]>
Date: Mon, 7 Nov 2016 17:43:06 -1000

>    is placed on generation of OCSP requests.

This doesn't make sense to me. Isn't the goal of the prehash scheme was to
support the signing of large things on systems without large amounts of
memory? Why would CRLs (which may be large) be MUST NOT while OCSP
responses are SHOULD NOT? It seems like the MUST NOT should be on
certificates and OCSP responses and OCSP requests, which are all small.
IIRC, there was some debate on whether CRLs should be allowed to use the
prehash variants since CRLs could be large. I personally thing all of the
cases mentioned in this paragraph should be MUST NOT.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Jim Schaad <[email-masked]>
Date: Mon, 7 Nov 2016 20:08:23 -0800

From: Curdle [mailto:[email-masked]] On Behalf Of Brian Smith
Sent: Monday, November 07, 2016 7:43 PM
To: Daniel Migault <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02

Daniel Migault <[email-masked] <mailto:[email-masked]> > wrote:

5.  Key Usage Bits

This doesn't make sense to me. Isn't the goal of the prehash scheme was to support the signing of large things on systems without large amounts of memory? Why would CRLs (which may be large) be MUST NOT while OCSP responses are SHOULD NOT? It seems like the MUST NOT should be on certificates and OCSP responses and OCSP requests, which are all small. IIRC, there was some debate on whether CRLs should be allowed to use the prehash variants since CRLs could be large. I personally thing all of the cases mentioned in this paragraph should be MUST NOT.

[JLS] There was a discussion on this.  In my opinion, there was not a consensus that was reached at that time.  I have been busy getting wine done so I did not ever get back to trying a third time to figure out a consensus for this.  It will definitely be on the discussion list for the F2F but I am more than willing to start a discussion here again.

The reason that CRLs are current a MUST NOT is that certificates and CRLs are almost always generated using the same key as the certificate is.  We do not want to be in the situation where the same key is used with different algorithms, so allowing pre-hash schemes on CRLs also allows pre-hash schemes on certificates.

I could go either way for OCSP responses.

Jim

Cheers,

Brian

-- 

https://briansmith.org/

---

From: Jim Schaad <[email-masked]>
Date: Mon, 7 Nov 2016 20:23:29 -0800

Comments are in-line

One question below for you to answer about public keys.

There should be an open discussion on contexts and if we should punt or do.

Jim

From: Curdle [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Saturday, November 05, 2016 4:52 AM
To: curdle <[email-masked]>
Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02

Hi, 

I reviewed the current version of the draft. Most comments are editorial, but I have two questions or clarifications. One concerns the use of ctx and the other the restriction to non prehash signatures for CA. 

Yours, 

Daniel

1.  Introduction

   MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] but the current draft does not not seeem to consider Ed25519ctx in HashEdDSA mode?
   OK the explanation is in section 6. Maybe that would worth mentioning Ed25515ctx has not been ignored or forgotten. I understand the motivation for not OIDzing Ed25515ctx now, but it looks to me strange that we only partially standardize OIDs for EdDSA, by not considering context either in Ed448 or Ed25515ctx. Would it be unreasonable to  add id-Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null context ? 

[JLS] I do not think it would be reasonable at this time to create the OIDs for having contexts for a couple of reasons.  1) I don’t think we understand how they should be used and thus if we should assign a different OID for each different context or if there should be one OID for all contexts.  2) It is not clear that using contexts is actually going to deliver on what was promised – see the discussion by Ilari about the use of contexts for DNSSEC.

I would agree that it makes sense to pull the text from section 6 to this location so that it is dealt with upfront.

MGLT: ECDH has not been defined earlier. Introduction talks about Diffie Hellamn. Maybe we could introduce ECDH in the intro while presenting the X* notations. 

[JLS] it makes sense to use that as part of the introduction of DH.

MGLT: Reading the text it looks to me the document are incompatible. Maybe some text could clarify this situation. Even though the curves remains the same in both document the described usage are different DH [RFC7748] or signature [I-D.irtf-cfrg-eddsa]. In this case, this leads to different public key associated to the same private key.   

[JLS] I am not really clear what you think needs to be added here.  I think that what you are asking for is basically what the text says.  Are you just asking for some expanded text or some different text?

5.  Key Usage Bits

MGLT: Just for clarification. We do not use the prehash version because the signature input must be the key, and prehash considers the hash as outside the signature scheme ? It looks to me that the constraint on CA is inspired from the recommendations of RFC5755. Am I correct ?

[JLS] The big reason for this is no longer a true statement following some changes to the document in the July/August timeframe.   However, there are still recommendations in [RFC-EdDSA] that inspire this recommendation.  Use of pre-hash allows for two attack points rather than a single attack point.
 
6.  EdDSA Signatures

[JLS] Will do

 MGLT: s/sense/since

[JLS] Will do

On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-pkix-02. 

The version to be reviewed is https://tools.ietf.org/html/draft-ietf-curdle-pkix-02

Please send your comments, questions, and edit proposals to the WG mail list until November 16th, 2016.  If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Yours, 

Rich and Daniel

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Nov 2016 00:35:08 -0500

Hi Jim,

Thanks for the response and clarifications.  I come also with the
conclusion that is is not clear how ctx would be useful with X509. In
DNSSEC there even has been a consensus to not use it. So I am fine not
having IOD for Ed25519ctx and Ed448ctx. If anyone see a real need for
creating  Ed25519ctx and Ed448ctx please inform the WG.

nits:
Section 4. I cannot figure out what confused me, the text looks clear to
me.

Section 5: The following sentence is really clarifying. "Use of pre-hash
allows for two attack points rather than a single attack point."

On Mon, Nov 7, 2016 at 11:23 PM, Jim Schaad <[email-masked]> wrote:

> *From:* Curdle [mailto:[email-masked]] *On Behalf Of *Daniel
> Migault
> *Sent:* Saturday, November 05, 2016 4:52 AM
> *To:* curdle <[email-masked]>
> *Subject:* Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02
>
>
>
> Hi,
>
>    MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa]
> but the current draft does not not seeem to consider Ed25519ctx in
> HashEdDSA mode?
> [JLS] I do not think it would be reasonable at this time to create the
> OIDs for having contexts for a couple of reasons.  1) I don’t think we
> understand how they should be used and thus if we should assign a different
> OID for each different context or if there should be one OID for all
> contexts.  2) It is not clear that using contexts is actually going to
> deliver on what was promised – see the discussion by Ilari about the use of
> contexts for DNSSEC.
>
> I would agree that it makes sense to pull the text from section 6 to this
> location so that it is dealt with upfront.
>
>
>
> [JLS] I am not really clear what you think needs to be added here.  I
> think that what you are asking for is basically what the text says.  Are
> you just asking for some expanded text or some different text?
>
>
>
> 5.  Key Usage Bits
>
> MGLT: Just for clarification. We do not use the prehash version because
> the signature input must be the key, and prehash considers the hash as
> outside the signature scheme ? It looks to me that the constraint on CA is
> inspired from the recommendations of RFC5755. Am I correct ?
>
> [JLS] The big reason for this is no longer a true statement following some
> changes to the document in the July/August timeframe.   However, there are
> still recommendations in [RFC-EdDSA] that inspire this recommendation.  Use
> of pre-hash allows for two attack points rather than a single attack point.
>
> 6.  EdDSA Signatures
>
> On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault <
> [email-masked]> wrote:
>
> Hi,
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 21 Nov 2016 10:07:01 -0500

Hi,

My interpretation is that there is a consensus the CRL MUST NOT use prehash
scheme. Do we have any consensus for 1) OCSP request and 2) OCSP response ?

Yours ,
Daniel

On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Curdle [mailto:[email-masked]] *On Behalf Of *Brian Smith
> *Sent:* Monday, November 07, 2016 7:43 PM
> *To:* Daniel Migault <[email-masked]>
> *Cc:* curdle <[email-masked]>
> [JLS] There was a discussion on this.  In my opinion, there was not a
> consensus that was reached at that time.  I have been busy getting wine
> done so I did not ever get back to trying a third time to figure out a
> consensus for this.  It will definitely be on the discussion list for the
> F2F but I am more than willing to start a discussion here again.
>
>
>
> The reason that CRLs are current a MUST NOT is that certificates and CRLs
> are almost always generated using the same key as the certificate is.  We
> do not want to be in the situation where the same key is used with
> different algorithms, so allowing pre-hash schemes on CRLs also allows
> pre-hash schemes on certificates.
>
>
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 21 Nov 2016 10:24:39 -0800

I think that we cannot do a restriction on OCSP requests.  One cannot know in advance what the algorithm that a client wants to use.  Allowing both here is not a big problem for key usages.

The question on OCSP responses has to do with if you think that the OCSP responder is going to be using the same key as the CA or is independently operated.  In the first case the restriction to pure is justified.  In the second case the only reason for it is to restrict the set of things that must be implemented.  When I wrote the text I assumed that the first case was more often the case, but I have no data to back that up.

Jim

From: Curdle [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Monday, November 21, 2016 7:07 AM
To: Jim Schaad <[email-masked]>
Cc: curdle <[email-masked]>; Brian Smith <[email-masked]>
Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02

Hi, 

My interpretation is that there is a consensus the CRL MUST NOT use prehash scheme. Do we have any consensus for 1) OCSP request and 2) OCSP response ?

Yours ,

Daniel

On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: Curdle [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Brian Smith
Sent: Monday, November 07, 2016 7:43 PM
To: Daniel Migault <[email-masked] <mailto:[email-masked]> >
Cc: curdle <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02

5.  Key Usage Bits

Jim

Cheers,

Brian

-- 

https://briansmith.org/

_______________________________________________
Curdle mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/curdle

---

From: Daniel Migault <[email-masked]>
Date: Wed, 30 Nov 2016 14:37:23 -0500

Hi Jim,

I was thinking the second way. Given the first possibility it might be wise
to restrict the responses. The current version mentions SHOULD NOT. Does
anyone wants to comment on it ? If so provide feed back by the end of the
week please.

"""

 """

Yours,
Daniel

On Mon, Nov 21, 2016 at 1:24 PM, Jim Schaad <[email-masked]> wrote:

> I think that we cannot do a restriction on OCSP requests.  One cannot know
> in advance what the algorithm that a client wants to use.  Allowing both
> here is not a big problem for key usages.
>
>
>
> The question on OCSP responses has to do with if you think that the OCSP
> responder is going to be using the same key as the CA or is independently
> operated.  In the first case the restriction to pure is justified.  In the
> second case the only reason for it is to restrict the set of things that
> must be implemented.  When I wrote the text I assumed that the first case
> was more often the case, but I have no data to back that up.
>
>
>
> Jim
>
>
>
>
>
> *Sent:* Monday, November 21, 2016 7:07 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* curdle <[email-masked]>; Brian Smith <[email-masked]>
>
> My interpretation is that there is a consensus the CRL MUST NOT use
> prehash scheme. Do we have any consensus for 1) OCSP request and 2) OCSP
> response ?
>
> Yours ,
>
> Daniel
>
>
>
>
>