Re: [lamps] Double signatures

["Dr. Pala" <[e-mail]>]

Hi Panos, all,

that is correct - since the new OIDs for the Key and the Signatures 
would be new, clients would fail since they do not know the "composite" 
algorithm :D

Although developing support for it should not be too difficult, the 
solution it is not meant to be backward compatible as we want 
applications to be able to fail if they do not even know they were 
supposed to generate or verify multiple signatures instead of just one.

 From a usage perspective, I am leaning towards the need for the owner 
of the certificates to generate signatures with all the keys, and for 
the entity that validates the signatures it should validate all the 
signatures it supports and may accept signatures even if it does not 
understand all the algorithms (this is more an application decision 
based on the risk and threat model).

As I said, this solution fits not only certificates, but also OCSP 
responses, CRLs, CMS, PKCS#7, etc. and that is part of what is 
interesting for us :D I still need to check what are the needed changes 
for other formats like PKCS#1/#8/#12 for storing the composite public 
and private keys (this part still missing), but I hope that solving that 
part will not be too difficult...

Cheers,
Max


On 9/20/18 7:26 AM, Panos Kampanakis (pkampana) wrote:
>
> Hi Max,
>
> To rephrase Eric’s question, would the CompositeKey+CompositeSig 
> proposal be backwards compatible with existing systems?
>
> I mean it gives you the change to use more than one algos in case you 
> don’t trust all of them. But an old client wouldn’t be able to just 
> use the traditional key+sig unless he was upgraded to understand 
> CompositeKey+CompositeSig and its OIDs, right?
>
> Panos
>
> *From:*Spasm [mailto:[e-mail]] *On Behalf Of *Erik Andersen
> *Sent:* Friday, September 14, 2018 11:49 AM
> *To:* 'SPASM' <[e-mail]>; Directory list 
> <[e-mail]>
> *Subject:* Re: [lamps] Double signatures
>
> The double signature is intended as a migration tool.
>
> In the normal operation, only one signature is used (the native 
> signature). When it is realized that the signature algorithm will be 
> too week i some future, the migration period starts and an 
> alternative, assuming stronger signature is provided for those able to 
> handle it. Legacy systems will ignore this alternative signature. 
> After the migration period, there will be no alternative signature and 
> the new stronger signature will be the native signature.
>
> Does that make sense?
>
> Erik
>
> *Fra:*Massimiliano Pala [mailto:[e-mail]]
> *Sendt:* 12 September 2018 23:01
> *Til:* Russ Housley <[e-mail] <mailto:[e-mail]>>
> *Cc:* SPASM <[e-mail] <mailto:[e-mail]>>; Erik Andersen 
> <[e-mail] <mailto:[e-mail]>>
> *Emne:* Re: [lamps] Double signatures
>
> Hi Russ, all,
>
> my personal position is that the signer MUST use all the keys that 
> have digitalSignature set, the verifier shall verify all the 
> signatures for which it does have support for.
>
> The rationale for this is that if I certify a public key in the 
> certificate, you should be able to use the private key to generate the 
> signature, therefore the approach is the same as usual: sign with your 
> key. In this case, it just happens that to generate the signature you 
> have to generate multiple ones and then combine them together.
>
> For the application that verifies those signatures, it is always a 
> question of what is the threshold that is acceptable for the 
> application (in terms of risk) in case it does not support all of the 
> algorithms that are used to generate the composite signature. Ideally 
> it would verify all, but it may decide to verify less (at least one).
>
> I also saw the other e-mail from Jim on this topic and I think it 
> could be a good idea - the use of the two OIDs is another way to go to 
> codify the validation process required. Technically, that makes sense 
> to me, however I am conflicted as this approach requires that the 
> signer has an understanding of what the verifier's capabilities are... 
> I think that defining two OIDs for the signatures could still be 
> useful because the signer might then decide the 
> "recommended"/"intended" verification behavior... I can see some 
> use-cases that might have a composite key with { RSA, EC } and the 
> "Must-Verify-All" OID for the signature, and another use-case where we 
> have a composite key with { RSA, HASH-BASED } and for the signature 
> "Must-Verify-At-Least-One".
>
> Does this make sense?
>
> Cheers,
> Max
>
> On 9/12/18 6:12 AM, Russ Housley wrote:
>
>     Max:
>
>     During a transition to quantum-resistant signatures, a signer
>     wants to put a traditional signature and a quantum-resistant
>     signature on an object.  Given your description of keyUsage and
>     extendedKeyUsage, both would have the digitalSignature bit set.
>      How does a client know if just one or both signatures must be valid?
>
>     As Jim Schaad already said, RFC 5752 talks about this issue when a
>     CMS SignedData contains more than one SignerInfo.
>
>     Russ
>
>         On Sep 11, 2018, at 4:45 PM, Max Pala <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         Hi All,
>
>         I am working on a similar - but different - solution, in
>         particular I solve the issue of (a) being able to combine more
>         than one public key, (b) only one (actually two) OIDs
>         required, and (c) simply the processing by re-utilizing the
>         same data structures we have today.
>
>         I particular, I define a “composite public key” and “composite
>         signature”.
>
>         The first one encodes in the key value’s BITSTRING the DER
>         value of the SEQUENCE of public keys (each of which is a the
>         subjectPublicKeyInfo structure) and uses a specific OID that
>         identifies the public key type. The parameters of the
>         compositeKey algorithm can be used to encode the keyUsage and
>         the extendedKeyUsage for each of the keys in the composite key.
>
>         The same approach is used for the “Composite Signature” case
>         where the value of the signature is the DER representation of
>         the SEQUENCE of signatures made with each of the keys.
>
>         As soon as I have some spare time, I will submit the draft -
>         maybe this could be discussed in Bangkok?
>
>         This simple idea allows us to have all the other procedures
>         related to PKIs work - this means we can combine ECC with RSA
>         or with a Quantum-Resistant algorithm (when finally available
>         and standardized). A step forward for the deployment of
>         hybrid-PKIs where multiple Lagos for keys can be used to
>         authenticate data, certs, revocation data, etc... we plan to
>         use this in our infrastructures to provide a transitional path
>         for post-Quantum transition and to further improve the
>         algorithm-agility capability of PKIs.
>
>         What do you think?
>
>         Cheers,
>
>         Max
>
>         ---
>
>         Cheers,
>
>         Max
>
>         On Sep 11, 2018, at 8:38 AM, Tim Hollebeek
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Unfortunately, “not every combination needs to be covered”
>             introduces a lot of politics around choosing which
>             combinations “need to be covered”, a subject on which
>             inevitably not everyone agrees.  I would rather avoid all
>             those discussions and the unnecessary work they represent.
>
>             I personally don’t think a single AlgID which implies a
>             SEQUENCE of ALG IDs is an improvement over a SEQUENCE of
>             ALG IDs, or its moral equivalent.  For simple hybrid use
>             cases, there is also a lot of value in having the
>             classical algorithm ID being the same as it usually is, to
>             allow easier interoperability with older systems that
>             don’t understand the newer algorithms (and can blissfully
>             ignore them).
>
>             -Tim
>
>             *From:*Santosh Chokhani <[e-mail]
>             <mailto:[e-mail]>>
>             *Sent:*Tuesday, September 11, 2018 10:29 AM
>             *To:*Tim Hollebeek <[e-mail]
>             <mailto:[e-mail]>>; 'Erik Andersen'
>             <[e-mail] <mailto:[e-mail]>>; 'SPASM'
>             <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*RE: [lamps] Double signatures
>
>             Thanks Tim.
>
>             There are ways to accommodate your concern.
>
>             One way to handle this is defining a single Alg ID A which
>             implies a SEQUENCE of ALG IDs and define the relying party
>             rules in terms of its ability to process one or all ALG IDs.
>
>             Another way to do this is not every combination needs to
>             be covered and the user community defines its own  Alg ID
>             Xi which maps to a SEQUENCE of ALG IDs.
>
>             *From:*Spasm [mailto:[e-mail]]*On Behalf
>             Of*Tim Hollebeek
>             *Sent:*Tuesday, September 11, 2018 10:03 AM
>             *To:*Erik Andersen <[e-mail] <mailto:[e-mail]>>;
>             'SPASM' <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*Re: [lamps] Double signatures
>
>             Doesn’t the combinatoric explosion render this completely
>             impractical?
>
>             You need N_c x N_pq algorithm identifiers just to handle
>             the simple hybrid use case where a single classical
>             algorithm is being used in conjunction with a single
>             post-quantum algorithm.
>
>             And there are people who want to use multiple post-quantum
>             algorithms to hedge against potential yet to be discovered
>             weaknesses in post-quantum algorithms.
>
>             I’m not really looking forward to trying to allocate or
>             manage O(N_c x N_pq^3) algorithm identifiers…
>
>             -Tim
>
>             *From:*Spasm <[e-mail]
>             <mailto:[e-mail]>>*On Behalf Of*Erik Andersen
>             *Sent:*Tuesday, September 11, 2018 3:10 AM
>             *To:*'SPASM' <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*Re: [lamps] Double signatures
>
>             Hi Santosh,
>
>             You have proposed something like this before. It still
>             puzzling in my brain. As I understand, it requires that we
>             define a particular algorithm that has a parameter that
>             includes the things you suggest. It is worthy to be analysed.
>
>             Erik
>
>             *Fra:*Spasm [mailto:[e-mail]]*På vegne
>             af*Santosh Chokhani
>             *Sendt:*10 September 2018 19:18
>             *Til:*'Jim Schaad' <[e-mail]
>             <mailto:[e-mail]>>; 'Ryan Sleevi'
>             <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Cc:*'SPASM' <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Emne:*Re: [lamps] Double signatures
>
>             Why not let algorithm identifier dictate the number of
>             signatures and their syntax?
>
>             *From:*Spasm [mailto:[e-mail]]*On Behalf
>             Of*Jim Schaad
>             *Sent:*Monday, September 10, 2018 1:07 PM
>             *To:*'Ryan Sleevi' <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Cc:*'SPASM' <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*Re: [lamps] Double signatures
>
>             Ryan,
>
>             The discussion in London dealt with a completely different
>             proposal than this one. While I think there are problems
>             with this that need to be dealt with they are mostly not
>             the same set.
>
>             Erik,
>
>             Why is this considered to be a preferred solution to
>             defining a new signature algorithm which contains as the
>             parameter the sequence of algorithm identifiers and as the
>             signature value a sequence of signature values.  The
>             problem with just defining the extension to SIGNED is that
>             one needs to make sure that the set of signature
>             algorithms and parameters are also part of the data to be
>             signed and I am not seeing that highlighted here.
>
>             Jim
>
>             *From:*Spasm <[e-mail]
>             <mailto:[e-mail]>>*On Behalf Of*Ryan Sleevi
>             *Sent:*Monday, September 10, 2018 8:53 AM
>             *To:*[e-mail] <mailto:[e-mail]>
>             *Cc:*SPASM <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*Re: [lamps] Double signatures
>
>             On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 Hi Folk,
>
>                 In ITU-T we have plans to allow for double signatures
>                 using the SIGNED parametrized data type defined in
>                 X.509 to cope with situation as described in the
>                 internet draft: “Multiple Public-Key Algorithm X.509
>                 Certificates (draft-truskovsky-lamps-pq-hybrid-x509-01)”
>
>                 We suggest to enhance the SIGNED data type as shown below:
>
>                 *SIGNED{ToBeSigned} ::= SEQUENCE {*
>
>                 *COMPONENTS OF SIGNATURE,*
>
>                 *.......**,*
>
>                 *altAlgorithmIdentifier
>                 AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,*
>
>                 *altSignature BIT STRING OPTIONAL *
>
>                 ***}****(WITH COMPONENTS {..., altAlgorithmIdentifier
>                 PRESENT, altSignature PRESENT } |*
>
>                 *WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT,
>                 altSignature ABSENT } )*
>
>                 **
>
>                 We are open to comments. We know that IETF is not a
>                 heavy user of this data type.
>
>                 We have no intention to use this extended data type
>                 for certificates and CRLs.
>
>                 For your information, SIGNATURE is defined as:
>
>                 *SIGNATURE ::= SEQUENCE {*
>
>                 *algorithmIdentifier
>                 AlgorithmIdentifier{{SupportedAlgorithms}},*
>
>                 *signature BIT STRING,*
>
>                 *....... }*
>
>             From the discussions in London (101), there were a number
>             of challenges identified during the discussion -
>             https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt-
>             that fundamentally questioned that approach.
>
>             Has the ITU-T addressed or resolved those concerns? Are
>             they not applicable for some reason specific to ITU-T?
>
>         _______________________________________________
>         Spasm mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/spasm
>
> -- 
>
> Best Regards,
>
> Massimiliano Pala, Ph.D.
>
> CableLabs
> Principal Architect
> Security Services, R&D
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm