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

[Jim Schaad <[e-mail]>]

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