Subject: [lamps] Comments on draft-ounsworth-pq-composite-sigs -01

From: Jim Schaad <[email-masked]>
Date: Sat, 13 Jul 2019 21:49:34 -0700

1.  In section 1 - The EDNOTE suggestion for how to do encryption seems to
be totally wrong and probably unworkable.  

2. In section 2.2 EDNOTE1 - I am completely in favor of the current usage
with PARAMS absent.

3. In section 2.5 - It took me a bit to decide it was correct, but you
should probably document why the algorithm identifiers are not next to the
signature values.  (... needs to be able to be signed ....)  And this should
probably be a recommended thing to do - i.e. for CMS that additional
parameter is needed.

4. In section 2.6 - If you can tell me how to accept BER and not DER I would
probably by a drink or two.  A better way would be to say MUST accept DER
and MAY (should?) accept BER.

5.  In section 3.1 - Doing sub-set signing would worry me in general due to
the fact than an attack could be made by removing elements from the
signature and signature algorithm list.  At the moment that is not possible
because the public key would not have the right number of elements.  However
there are several situations where the signature algorithm is not included
in the signed value thus permitting this attack.

6. Section 3.2 - I do not believe that you can get away with not specifying
the partial evaluation of signature algorithm.   One of the main arguments
that you are giving for this is that not all of the signature algorithms may
be known.

 Insert step 1.5 - Filter the list of signature algorithm to those
implemented by the evaluation code.

7. Section 3.2 - The last paragraph in this section is not going to make me
very happy.  Specifically the text following "but" would appear to
contradict the evaluation in the current step 2.

8. Section 4.1 - Yes it is obvious - having it does not really any
downsides.

9. Section 4.2 - I don't understand the section header here.  Was that just
a mistake?

10.  Section 4.2 - It seems that a lot of this might be done by referencing.
For example the privateKey field is encoded as in Section X.Y

11. Section 6.1 -  I would want to put in a note that the checkPolicy
algorithm can very from a single algorithm is fine to a set of algorithms is
required or as long as the algorithms are not all "known bad".  Some
description of different possibilities would be good.

12. In the ASN.1 module, a comment about adding pk-Composite to the class
set PublicKeyAlgorithms (as defined in RFC 5280) is required.

Jim

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 17 Jul 2019 15:21:42 +0000

Jim,

Thank you very much for the detailed reading and feedback!

We will see what other discussion comes up during IETF105, and do another editing pass afterwards.

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Saturday, July 13, 2019 11:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [EXTERNAL]Comments on draft-ounsworth-pq-composite-sigs -01

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

1.  In section 1 - The EDNOTE suggestion for how to do encryption seems to be totally wrong and probably unworkable.  

2. In section 2.2 EDNOTE1 - I am completely in favor of the current usage with PARAMS absent.

3. In section 2.5 - It took me a bit to decide it was correct, but you should probably document why the algorithm identifiers are not next to the signature values.  (... needs to be able to be signed ....)  And this should probably be a recommended thing to do - i.e. for CMS that additional parameter is needed.

4. In section 2.6 - If you can tell me how to accept BER and not DER I would probably by a drink or two.  A better way would be to say MUST accept DER and MAY (should?) accept BER.

5.  In section 3.1 - Doing sub-set signing would worry me in general due to the fact than an attack could be made by removing elements from the signature and signature algorithm list.  At the moment that is not possible because the public key would not have the right number of elements.  However there are several situations where the signature algorithm is not included in the signed value thus permitting this attack.

6. Section 3.2 - I do not believe that you can get away with not specifying
the partial evaluation of signature algorithm.   One of the main arguments
that you are giving for this is that not all of the signature algorithms may be known.

 Insert step 1.5 - Filter the list of signature algorithm to those implemented by the evaluation code.

7. Section 3.2 - The last paragraph in this section is not going to make me very happy.  Specifically the text following "but" would appear to contradict the evaluation in the current step 2.

8. Section 4.1 - Yes it is obvious - having it does not really any downsides.

9. Section 4.2 - I don't understand the section header here.  Was that just a mistake?

11. Section 6.1 -  I would want to put in a note that the checkPolicy algorithm can very from a single algorithm is fine to a set of algorithms is required or as long as the algorithms are not all "known bad".  Some description of different possibilities would be good.

12. In the ASN.1 module, a comment about adding pk-Composite to the class set PublicKeyAlgorithms (as defined in RFC 5280) is required.

Jim