Subject: [lamps] Double signatures

From: "Erik Andersen" <[email-masked]>
Date: Mon, 10 Sep 2018 16:56:42 +0200

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,

  ... }

Erik

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 10 Sep 2018 11:52:53 -0400

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <[email-masked]> wrote:

> in the internet draft: “Multiple Public-Key Algorithm X.509 Certificates
> (draft-truskovsky-lamps-pq-hybrid-x509-01)”
>
>
>
> *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.
>
>
>
> *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?

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Sep 2018 10:06:58 -0700

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 <[email-masked]> On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: [email-masked]
Cc: SPASM <[email-masked]>; [email-masked]
Subject: Re: [lamps] Double signatures

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <[email-masked] <mailto:[email-masked]> > 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)”

  COMPONENTS OF SIGNATURE,

  ...,

  altAlgorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}} 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.

SIGNATURE ::= SEQUENCE {

  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?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 10 Sep 2018 13:17:59 -0400

Why not let algorithm identifier dictate the number of signatures and their syntax?

From: Spasm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <[email-masked]>; [email-masked]
Cc: 'SPASM' <[email-masked]>; [email-masked]
Subject: Re: [lamps] Double signatures

Ryan,

Erik,

Jim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: SPASM <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  .... }

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 10 Sep 2018 19:00:39 +0000

Hi Jim,
I think the issues brought up about draft-truskovsky-lamps-pq-hybrid-x509 are pretty similar even if the altSig information is added in the signed data type if that sig coexists with the traditional sig. Can you elaborate why are you saying otherwise?
Panos

Ryan,

Erik,

Jim

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: [email-masked]<mailto:[email-masked]>
Cc: SPASM <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Folk,

SIGNATURE ::= SEQUENCE {

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Sep 2018 12:42:07 -0700

First – they say that this is not going to done in certificates which means that all of the questions dealing with certificates  have gone out the window.

Second – the issue around semantics of multiple parallel signatures is always dependent on the application being used.   This is how things are defined for CMS which has the same issue (RFC 5752).  Since this is not for certificates, that is not immediately a problem for the IETF.  If one did the define a signature algorithm, one could even encode much of these semantic rules into the algorithm definition either directly in the OID or as parameters.

Third – processing issues for this are quite simple.  The version that was presented in LAMPs had a lot of problems in doing the order of signing and building the resulting item as there needed to be at least two different passes of encoding which needed to do the same things.  That is not an issue here as the exact same bytes are signed by all of the signature algorithms in question.

Jim

From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Monday, September 10, 2018 12:01 PM
To: Jim Schaad <[email-masked]>
Cc: 'SPASM' <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [lamps] Double signatures

Hi Jim, 

Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: 'SPASM' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  .... }

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 11 Sep 2018 09:01:10 +0200

HI Jim,

You have a good point here that also been bothering me for the last couple of days. I am still trying to find a way.

Erik

Fra: Jim Schaad [mailto:[email-masked]] 
Sendt: 10 September 2018 19:07
Til: 'Ryan Sleevi' <[email-masked]>; [email-masked]
Cc: 'SPASM' <[email-masked]>; [email-masked]
Emne: RE: [lamps] Double signatures

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ...,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ... }

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 11 Sep 2018 09:10:14 +0200

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:[email-masked]] På vegne af Santosh Chokhani
Sendt: 10 September 2018 19:18
Til: 'Jim Schaad' <[email-masked]>; 'Ryan Sleevi' <[email-masked]>; [email-masked]
Cc: 'SPASM' <[email-masked]>; [email-masked]
Emne: Re: [lamps] Double signatures

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  .... }

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 11 Sep 2018 14:02:37 +0000

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 <[email-masked]> On Behalf Of Erik Andersen
Sent: Tuesday, September 11, 2018 3:10 AM
To: 'SPASM' <[email-masked]>; [email-masked]
Subject: Re: [lamps] Double signatures

Hi Santosh,

Erik

Til: 'Jim Schaad' <[email-masked] <mailto:[email-masked]> >; 'Ryan Sleevi' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  .... }

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 11 Sep 2018 10:28:58 -0400

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:[email-masked]] On Behalf Of Tim Hollebeek
Sent: Tuesday, September 11, 2018 10:03 AM
To: Erik Andersen <[email-masked]>; 'SPASM' <[email-masked]>; [email-masked]
Subject: Re: [lamps] Double signatures

-Tim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Erik Andersen
Sent: Tuesday, September 11, 2018 3:10 AM
To: 'SPASM' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  .....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ..... }

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 11 Sep 2018 14:38:22 +0000

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 <[email-masked]> 
Sent: Tuesday, September 11, 2018 10:29 AM
To: Tim Hollebeek <[email-masked]>; 'Erik Andersen' <[email-masked]>; 'SPASM' <[email-masked]>; [email-masked]
Subject: RE: [lamps] Double signatures

Thanks Tim.

From: Spasm [mailto:[email-masked]] On Behalf Of Tim Hollebeek
Sent: Tuesday, September 11, 2018 10:03 AM
To: Erik Andersen <[email-masked] <mailto:[email-masked]> >; 'SPASM' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  .....,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ..... }

---

From: Max Pala <[email-masked]>
Date: Tue, 11 Sep 2018 20:45:41 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

-Tim

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 11, 2018 10:29 AM
To: Tim Hollebeek <[email-masked]<mailto:[email-masked]>>; 'Erik Andersen' <[email-masked]<mailto:[email-masked]>>; 'SPASM' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [lamps] Double signatures

Thanks Tim.

From: Spasm [mailto:[email-masked]] On Behalf Of Tim Hollebeek
Sent: Tuesday, September 11, 2018 10:03 AM
To: Erik Andersen <[email-masked]<mailto:[email-masked]>>; 'SPASM' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

-Tim

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Erik Andersen
Sent: Tuesday, September 11, 2018 3:10 AM
To: 'SPASM' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

Hi Santosh,

Erik

Fra: Spasm [mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 10 September 2018 19:18
Til: 'Jim Schaad' <[email-masked]<mailto:[email-masked]>>; 'Ryan Sleevi' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'SPASM' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Emne: Re: [lamps] Double signatures

From: Spasm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'SPASM' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

Ryan,

Erik,

Jim

  ......,

SIGNATURE ::= SEQUENCE {
  ...... }

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Sep 2018 22:04:23 -0400

Erik,

A couple of points I’m hoping you might clarify:

1. You said “We have no intention to use this extended data type for certificates and CRLs.”  In X.509-2016, Certificate and CertificateList use the following ASN.1:
 
	Certificate ::= SIGNED{TBSCertificate}
 
	CertificateList ::= SIGNED{CertificateListContent}

So to pull off what you’re suggesting (i.e., never using these with Certificate and CertificateList) what exactly are going to do - redefine Certificate and CertificateList, put some kind of constraint on ToBeSigned in SIGNED, … ?

2. You also said "We know that IETF is not a heavy user of this data type”, where this is SIGNED.  That’s a true statement because the IETF initially didn’t make use of the AuthenticationFramework SIGNED parameterized types because RFC 5280 uses the ’88 modules and parameterized types were’t a thing in ’88; in ’88 it was a SIGNED MACRO and it was a pain so it was redefined in a bits-on-the-wire compatible way.  For those IETF RFCs that prefer to use the ’02 and ’08 syntax, a SIGNED parameterized type is defined in RFC 5912 and is used in RFCs 5911, 5912, and 6268 (and maybe others) to define 30+ ASN.1 modules.  So while "SIGNED” is not used much in the context of the 8000+ RFCs it can be used by just about every RFC that uses ASN.1.

Despite the fact SIGNED wasn’t defined exactly the same, they still resulted in the same encoding, namely algorithm parameters (OID+parameters) and signature (a bit string); same as the earlier ’88 syntaxes.  I have this sinking feeling that making a change to this is going to cause some problems somewhere despite the fact we can do fancy things with the ASN.1.

spt

> On Sep 11, 2018, at 03:01, Erik Andersen <[email-masked]> wrote:
> 
> HI Jim,
>  
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Sep 2018 08:12:49 -0400

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 <[email-masked]> wrote:
> 
> Hi All,
> 
> On Sep 11, 2018, at 8:38 AM, Tim Hollebeek <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> From: Santosh Chokhani <[email-masked] <mailto:[email-masked]>> 
>> To: Tim Hollebeek <[email-masked] <mailto:[email-masked]>>; 'Erik Andersen' <[email-masked] <mailto:[email-masked]>>; 'SPASM' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: Spasm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Tim Hollebeek
>> To: Erik Andersen <[email-masked] <mailto:[email-masked]>>; 'SPASM' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: Spasm <[email-masked] <mailto:[email-masked]>> On Behalf Of Erik Andersen
>> To: 'SPASM' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> Fra: Spasm [mailto:[email-masked] <mailto:[email-masked]>] På vegne af Santosh Chokhani
>> Til: 'Jim Schaad' <[email-masked] <mailto:[email-masked]>>; 'Ryan Sleevi' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> Cc: 'SPASM' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: Spasm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jim Schaad
>> To: 'Ryan Sleevi' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> Cc: 'SPASM' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: Spasm <[email-masked] <mailto:[email-masked]>> On Behalf Of Ryan Sleevi
>> Cc: SPASM <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Folk,
>>  
>> 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 <https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt> - that fundamentally questioned that approach.
>>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Sep 2018 07:59:34 -0700

Russ,

There are two easy ways to indicate this.  The first would be to allocate multiple oids

oid-One-Is-Ok-Multi-Sig

oid-All-Required-Multi-Sig

The second would be to put a int value before the sequence of signature oids with the number of signatures that needed to validate so you could do 3 of n need to validate.

Jim

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, September 12, 2018 5:13 AM
To: Massimiliano Pala <[email-masked]>
Cc: SPASM <[email-masked]>; Erik Andersen <[email-masked]>
Subject: Re: [lamps] Double signatures

Max:

Russ

On Sep 11, 2018, at 4:45 PM, Max Pala <[email-masked] <mailto:[email-masked]> > wrote:

Hi All,

What do you think?

Cheers,

Max

---

Cheers,

Max

On Sep 11, 2018, at 8:38 AM, Tim Hollebeek < <mailto:[email-masked]> [email-masked]> wrote:

-Tim

From: Santosh Chokhani < <mailto:[email-masked]> [email-masked]> 
Sent: Tuesday, September 11, 2018 10:29 AM
To: Tim Hollebeek < <mailto:[email-masked]> [email-masked]>; 'Erik Andersen' < <mailto:[email-masked]> [email-masked]>; 'SPASM' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: RE: [lamps] Double signatures

Thanks Tim.

From: Spasm [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Tim Hollebeek
Sent: Tuesday, September 11, 2018 10:03 AM
To: Erik Andersen < <mailto:[email-masked]> [email-masked]>; 'SPASM' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [lamps] Double signatures

-Tim

From: Spasm < <mailto:[email-masked]> [email-masked]> On Behalf Of Erik Andersen
Sent: Tuesday, September 11, 2018 3:10 AM
To: 'SPASM' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [lamps] Double signatures

Hi Santosh,

Erik

Fra: Spasm [ <mailto:[email-masked]> mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 10 September 2018 19:18
Til: 'Jim Schaad' < <mailto:[email-masked]> [email-masked]>; 'Ryan Sleevi' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'SPASM' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Emne: Re: [lamps] Double signatures

From: Spasm [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'SPASM' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [lamps] Double signatures

Ryan,

Erik,

Jim

From: Spasm < <mailto:[email-masked]> [email-masked]> On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To:  <mailto:[email-masked]> [email-masked]
Cc: SPASM < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [lamps] Double signatures

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen < <mailto:[email-masked]> [email-masked]> wrote:

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ......,

SIGNATURE ::= SEQUENCE {

  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> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt - that fundamentally questioned that approach.

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

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 12 Sep 2018 15:01:25 -0600

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 <[email-masked]
>> <mailto:[email-masked]>> 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.
>>
>> 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.
>>
>> 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
>> <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>>> <mailto:[email-masked]>> 
>>> *Sent:* Tuesday, September 11, 2018 10:29 AM
>>> *To:* Tim Hollebeek <[email-masked]
>>> <mailto:[email-masked]>>; 'Erik Andersen' <[email-masked]
>>> <mailto:[email-masked]>>; 'SPASM' <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *Subject:* RE: [lamps] Double signatures
>>>  
>>> Thanks Tim.
>>>  
>>> 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:[email-masked]] *On Behalf Of *Tim
>>> Hollebeek
>>> *Sent:* Tuesday, September 11, 2018 10:03 AM
>>> *To:* Erik Andersen <[email-masked] <mailto:[email-masked]>>; 'SPASM'
>>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>> 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.
>>>  
>>> *From:* Spasm <[email-masked]
>>> <mailto:[email-masked]>> *On Behalf Of *Erik Andersen
>>> *Sent:* Tuesday, September 11, 2018 3:10 AM
>>> *To:* 'SPASM' <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *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:[email-masked]] *På vegne af *Santosh
>>> Chokhani
>>> *Sendt:* 10 September 2018 19:18
>>> *Til:* 'Jim Schaad' <[email-masked]
>>> <mailto:[email-masked]>>; 'Ryan Sleevi'
>>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *Cc:* 'SPASM' <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *Emne:* Re: [lamps] Double signatures
>>>  
>>> *From:* Spasm [mailto:[email-masked]] *On Behalf Of *Jim Schaad
>>> *Sent:* Monday, September 10, 2018 1:07 PM
>>> *To:* 'Ryan Sleevi' <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>> *Cc:* 'SPASM' <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *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 <[email-masked]
>>> <mailto:[email-masked]>> *On Behalf Of *Ryan Sleevi
>>> *Sent:* Monday, September 10, 2018 8:53 AM
>>> *To:* [email-masked] <mailto:[email-masked]>
>>> *Cc:* SPASM <[email-masked]
>>> <mailto:[email-masked]>>; [email-masked]
>>> <mailto:[email-masked]>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>>
>>>  
>>>
>>>     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
>>>     *  ......,*
>>>     *  altAlgorithmIdentifier 
>>>     AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,*
>>>     *  **} (WITH COMPONENTS {..., altAlgorithmIdentifier PRESENT,
>>>     altSignature PRESENT } |*
>>>     *     WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT, 
>>>     altSignature ABSENT } )*
>>>     * *
>>>     *  ...... }*
>>> 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? 

-- 
Best Regards,
Massimiliano Pala, Ph.D.
CableLabs
Principal Architect
Security Services, R&D

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Sep 2018 22:13:18 +0100

Hiya,

Not really replying to Erik (though I agree with Sean's comments),
but before adopting any work on multiple signatures in x.509, I'd
much prefer for the IETF to consider whether there are other/better
ways to handle these issues. TBH, that's partly because I'm pretty
bored with x.509 (the first code I wrote for x.509 was >25 years
ago;-), but substantively, it may be that other solutions could be
better. For example, CT as-deployed didn't really try to solve the
problem of mis-issuance from within the x.509 framework, and has
arguably been one of the most positive developments in PKI in recent
years.

S.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 12 Sep 2018 17:47:26 -0400

You can also add a bit map in the composite alg OID parameters field for which ones must be verified. 

From: Spasm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, September 12, 2018 11:00 AM
To: 'Russ Housley' <[email-masked]>; 'Massimiliano Pala' <[email-masked]>
Cc: 'SPASM' <[email-masked]>; 'Erik Andersen' <[email-masked]>
Subject: Re: [lamps] Double signatures

Russ,

oid-One-Is-Ok-Multi-Sig

Jim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Russ Housley
Sent: Wednesday, September 12, 2018 5:13 AM
To: Massimiliano Pala <[email-masked] <mailto:[email-masked]> >
Cc: SPASM <[email-masked] <mailto:[email-masked]> >; Erik Andersen <[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] Double signatures

Max:

Russ

Hi All,

What do you think?

Cheers,

Max

---

Cheers,

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ......,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ...... }

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 14 Sep 2018 14:20:20 +0200

Hi Sean,

What I meant was that the optional addition to the SIGNED data type shall be absent for the two cases. However, I am slowly coming to the opinion that we should define a new data type and leave the SIGNED data type as it is to avoid confusion.

Best regards,

Erik

-----Oprindelig meddelelse-----
Fra: Spasm [mailto:[email-masked]] På vegne af Sean Turner
Sendt: 12 September 2018 04:04
Til: Erik Andersen <[email-masked]>
Cc: SPASM <[email-masked]>; [email-masked]
Emne: Re: [lamps] Double signatures

Erik,

 

spt

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 14 Sep 2018 17:49:19 +0200

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:[email-masked]] 
Sendt: 12 September 2018 23:01
Til: Russ Housley <[email-masked]>
Cc: SPASM <[email-masked]>; Erik Andersen <[email-masked]>
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

Max: 

Russ

Hi All, 

What do you think?

Cheers, 

Max

--- 

Cheers, 

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ......,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ...... }

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.

Principal Architect
Security Services, R&D

---

From: Stiepan <[email-masked]>
Date: Fri, 14 Sep 2018 16:00:01 +0000

I think this makes fully sense Erik:

Leaving too much choice is what then leads to all sorts of downgrading attacks.

Best regards,
Stiepan

Stiepan A. Kovac
President
itk AVtobvS SARL
Jussy + Fribourg

Envoyé depuis ProtonMail mobile

-------- Message d'origine --------
On 14 sept. 2018 à 17:49, Erik Andersen a écrit :

>>> On Sep 11, 2018, at 8:38 AM, Tim Hollebeek <[email-masked]> wrote:
>>>
>>> Spasm mailing [email-masked]
> [CableLabs]

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 20 Sep 2018 13:26:26 +0000

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:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, September 14, 2018 11:49 AM
To: 'SPASM' <[email-masked]>; Directory list <[email-masked]>
Subject: Re: [lamps] Double signatures

Does that make sense?

Erik

Fra: Massimiliano Pala [mailto:[email-masked]]
Sendt: 12 September 2018 23:01
Til: Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: SPASM <[email-masked]<mailto:[email-masked]>>; Erik Andersen <[email-masked]<mailto:[email-masked]>>
Emne: Re: [lamps] Double signatures

Hi Russ, all,

Does this make sense?

Cheers,
Max

Russ

On Sep 11, 2018, at 4:45 PM, Max Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

What do you think?

Cheers,
Max

---

Cheers,
Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

  .......,

SIGNATURE ::= SEQUENCE {
  ....... }

Has the ITU-T addressed or resolved those concerns? Are they not applicable for some reason specific to ITU-T?
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm

--
Best Regards,
Massimiliano Pala, Ph.D.
[CableLabs]
Principal Architect
Security Services, R&D

---

From: Jim Schaad <[email-masked]>
Date: Thu, 20 Sep 2018 10:35:37 -0700

Panos,

The same would be true if you extended the structure to have two signatures in it as is proposed in the SIGNED macro below.  Systems which can only parse a single signature there would be unable to use objects which had both signatures in that location.  This is one of the reasons that it is stated that there is no plan to use this for Certificates and CRLs at this time.

jim

From: Spasm <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, September 20, 2018 6:26 AM
To: Massimiliano Pala <[email-masked]>
Cc: 'SPASM' <[email-masked]>; Directory list <[email-masked]>; Erik Andersen <[email-masked]>
Subject: Re: [lamps] Double signatures

Hi Max,

Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, September 14, 2018 11:49 AM
To: 'SPASM' <[email-masked] <mailto:[email-masked]> >; Directory list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] Double signatures

Does that make sense?

Erik

Til: Russ Housley <[email-masked] <mailto:[email-masked]> >

Hi Russ, all,

Does this make sense?

Cheers,
Max

Max: 

Russ

Hi All, 

What do you think?

Cheers, 

Max

--- 

Cheers, 

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  .......,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ....... }

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.

Principal Architect
Security Services, R&D

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Sep 2018 11:44:22 -0600

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:[email-masked]] *On Behalf Of *Erik Andersen
> *Sent:* Friday, September 14, 2018 11:49 AM
> *To:* 'SPASM' <[email-masked]>; Directory list 
> <[email-masked]>
> 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:[email-masked]]
> *Sendt:* 12 September 2018 23:01
> *Til:* Russ Housley <[email-masked] <mailto:[email-masked]>>
> *Cc:* SPASM <[email-masked] <mailto:[email-masked]>>; Erik Andersen 
> <[email-masked] <mailto:[email-masked]>>
> 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.
>
> 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
>
>     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
>
>         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.
>
>         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
>         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
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             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
>             *From:*Santosh Chokhani <[email-masked]
>             *Sent:*Tuesday, September 11, 2018 10:29 AM
>             *To:*Tim Hollebeek <[email-masked]
>             <mailto:[email-masked]>>; 'Erik Andersen'
>             <[email-masked] <mailto:[email-masked]>>; 'SPASM'
>             <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *Subject:*RE: [lamps] Double signatures
>
>             Thanks Tim.
>
>             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:[email-masked]]*On Behalf
>             Of*Tim Hollebeek
>             *Sent:*Tuesday, September 11, 2018 10:03 AM
>             *To:*Erik Andersen <[email-masked] <mailto:[email-masked]>>;
>             'SPASM' <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *Subject:*Re: [lamps] Double signatures
>
>             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.
>
>             I’m not really looking forward to trying to allocate or
>             manage O(N_c x N_pq^3) algorithm identifiers…
>
>             -Tim
>
>             *From:*Spasm <[email-masked]
>             <mailto:[email-masked]>>*On Behalf Of*Erik Andersen
>             *Sent:*Tuesday, September 11, 2018 3:10 AM
>             *To:*'SPASM' <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *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:[email-masked]]*På vegne
>             af*Santosh Chokhani
>             *Sendt:*10 September 2018 19:18
>             *Til:*'Jim Schaad' <[email-masked]
>             <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             <mailto:[email-masked]>
>             *Cc:*'SPASM' <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *Emne:*Re: [lamps] Double signatures
>
>             *From:*Spasm [mailto:[email-masked]]*On Behalf
>             Of*Jim Schaad
>             *Sent:*Monday, September 10, 2018 1:07 PM
>             *To:*'Ryan Sleevi' <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             <mailto:[email-masked]>
>             *Cc:*'SPASM' <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *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 <[email-masked]
>             <mailto:[email-masked]>>*On Behalf Of*Ryan Sleevi
>             *Sent:*Monday, September 10, 2018 8:53 AM
>             *To:[email-masked] <mailto:[email-masked]>
>             *Cc:*SPASM <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             *Subject:*Re: [lamps] Double signatures
>
>             On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen
>             <[email-masked] <mailto:[email-masked]>> 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)”
>
>                 *COMPONENTS OF SIGNATURE,*
>
>                 *.......**,*
>
>                 *altAlgorithmIdentifier
>                 *altSignature BIT STRING OPTIONAL *
>
>                 ***}****(WITH COMPONENTS {..., altAlgorithmIdentifier
>                 PRESENT, altSignature PRESENT } |*
>
>                 *WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT,
>                 altSignature ABSENT } )*
>
>                 **
>
>                 *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-
>             Has the ITU-T addressed or resolved those concerns? Are
>             they not applicable for some reason specific to ITU-T?
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Sat, 22 Sep 2018 03:08:26 +0000

Hi Max, Jim,

Agreed. In summary, there are too good proposals (Erik, Max’s) that can combine multiple PKs and Sigs. That would allow us to us more than one PQ algos if they are not trusted.

draft-truskovsky-lamps-pq-hybrid allows for backwards compatibility by defining one only PQ key and sig as non-critical extensions.

I wonder if the two concepts could be merged. Meaning use the composite key + sigs can non-critical extensions. Old clients disregard the PQ extensions. New clients verify the classical  and the PQ algos defined in the composite OID contained in the non-critical extension.

Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: Thursday, September 20, 2018 1:44 PM
To: [email-masked]
Subject: Re: [lamps] Double signatures

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

From: Spasm [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, September 14, 2018 11:49 AM
To: 'SPASM' <[email-masked]><mailto:[email-masked]>; Directory list <[email-masked]><mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

Does that make sense?

Erik

Hi Russ, all,

Does this make sense?

Cheers,
Max

Russ

Hi All,

What do you think?

Cheers,
Max

---

Cheers,
Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

SIGNATURE ::= SEQUENCE {

--
Best Regards,
Massimiliano Pala, Ph.D.
[CableLabs]
Principal Architect
Security Services, R&D

Spasm mailing list

---

From: Jim Schaad <[email-masked]>
Date: Fri, 21 Sep 2018 21:18:05 -0700

Panos,

Without a really detailed analysis of your proposal and how it will interact with existing code I could not possibly support it.   A quick list of problems that I would list (without thought) are:

1.	Historically, lots of people cannot get DER encoding correct.  Peter Gutmann has a huge collection of certificates that were issued by CAs that were not correctly DER encoded.  
2.	Everybody who wants to support PQ algorithms is now required to add a DER encoder to their systems.  For things which only consume certificates, crls, cms objects this means that they now have enlarged code size.
3.	I have no idea what the rules are for matching CRLs and certificates in terms of signature algorithms, I would assume that you need the same protections for CRLs.
4.	You are not signing the alt signature algorithm as part of the TBS (easy to fix)
5.	How are the certificates for the issuer setup?  Are there separate certificates or the same certificate?
6.	Just how badly does this affect the path building code as it now needs to be modified to have additional inputs.
7.	Do you want to change the AKI field to make chain building better or are you going to cause non-supporting systems to potentially start downloading lots of other certificates as well.  
8.	Same issues applying to CRL distribution points – it would potentially be more efficient to have separate CRLs rather than combined ones as you could not use the extension in that case.
9.	How is AIA going to work.
10.	If you require that the same algorithms be used, what happens with OCSP responses and delegated CRL issuers?’

Jim

From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Friday, September 21, 2018 8:08 PM
To: Dr. Pala <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: RE: [lamps] Double signatures

Hi Max, Jim,

Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: Thursday, September 20, 2018 1:44 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

Hi Panos, all,

Cheers,
Max

Hi Max,

Panos

From: Spasm [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, September 14, 2018 11:49 AM
To: 'SPASM'  <mailto:[email-masked]> <[email-masked]>; Directory list  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [lamps] Double signatures

Does that make sense?

Erik

Fra: Massimiliano Pala [ <mailto:[email-masked]> mailto:[email-masked]] 
Sendt: 12 September 2018 23:01
Til: Russ Housley < <mailto:[email-masked]> [email-masked]>
Cc: SPASM < <mailto:[email-masked]> [email-masked]>; Erik Andersen < <mailto:[email-masked]> [email-masked]>
Emne: Re: [lamps] Double signatures

Hi Russ, all,

Does this make sense?

Cheers,
Max

Max: 

Russ

On Sep 11, 2018, at 4:45 PM, Max Pala < <mailto:[email-masked]> [email-masked]> wrote:

Hi All, 

What do you think?

Cheers, 

Max

--- 

Cheers, 

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  .......,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ....... }

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.

Principal Architect
Security Services, R&D

---

From: Tim Hollebeek <[email-masked]>
Date: Sat, 22 Sep 2018 11:33:09 +0000

How are chain/path building, AIA, and so on affected?  Alternative signatures just give alternative information that can be either be used separately or additionally to verify a particular certificate signature.  How you find valid certificates and put them together into a chain seems to me to be completely independent of how you validate a particular signature.

Problem 5 seems like a particularly odd objection.  I haven’t seen a proposal for separate certificates.  Indeed, that is one of the things that I think is very wise to avoid, as it has caused significant problems in the past, most recently for example with SHA1 / SHA-256 transition.  The entire point of including multiple signatures with different algorithms is to avoid the need to have separate hierarchies for the old and new ways of doing things.  

There seem to be some assumptions built into your list of problems that I think are important to unpack, discuss, and resolve first.

-Tim

From: Spasm <[email-masked]> On Behalf Of Jim Schaad
Sent: Saturday, September 22, 2018 12:18 AM
To: 'Panos Kampanakis (pkampana)' <[email-masked]>
Cc: [email-masked]
Subject: Re: [lamps] Double signatures

Panos,

 

Jim

From: Panos Kampanakis (pkampana) <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, September 21, 2018 8:08 PM
To: Dr. Pala <[email-masked] <mailto:[email-masked]> >; Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [lamps] Double signatures

Hi Max, Jim,

Panos

Hi Panos, all,

Cheers,
Max

Hi Max,

Panos

Does that make sense?

Erik

Hi Russ, all,

Does this make sense?

Cheers,
Max

Max: 

Russ

Hi All, 

What do you think?

Cheers, 

Max

--- 

Cheers, 

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ........,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ....... }

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.

Principal Architect
Security Services, R&D

---

From: Jim Schaad <[email-masked]>
Date: Sat, 22 Sep 2018 14:48:37 -0700

Tim,

Except for the case of self-issued certificates, I almost never care about processing a single certificate.  Rather I am going to process a chain of certificates that goes back to a trust root. Comparing this to the SHA1/SHA-256 transition I don’t think is very relevant.  In that case one could be using the same public key value with different signature algorithms.  Here we are looking at using two completely different public key structures, i.e. an EdDSA and a Hash-based signature.  This means that both public keys need to be findable from some issuer certificate.  This proposal does not have any way of encoding the multiple public keys.   From this I make the assumption that there is a single certificate for each of the public keys, which can have multiple signatures on it.   If the public keys are in their own certificates, then you get lots of fun in terms of trying to build the chains and all of the things that I pointed to are relevant.  If the public keys are in a single certificate then this is not documented.

jim

From: Tim Hollebeek <[email-masked]> 
Sent: Saturday, September 22, 2018 4:33 AM
To: Jim Schaad <[email-masked]>; 'Panos Kampanakis (pkampana)' <[email-masked]>
Cc: [email-masked]
Subject: RE: [lamps] Double signatures

-Tim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Jim Schaad
Sent: Saturday, September 22, 2018 12:18 AM
To: 'Panos Kampanakis (pkampana)' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] Double signatures

Panos,

 

Jim

Hi Max, Jim,

Panos

Hi Panos, all,

Cheers,
Max

Hi Max,

Panos

Does that make sense?

Erik

Hi Russ, all,

Does this make sense?

Cheers,
Max

Max: 

Russ

Hi All, 

What do you think?

Cheers, 

Max

--- 

Cheers, 

Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

 

Hi Folk,

  COMPONENTS OF SIGNATURE,

  ........,

SIGNATURE ::= SEQUENCE {

  signature            BIT STRING,

  ....... }

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.

Principal Architect
Security Services, R&D

---

From: Daniel Van Geest <[email-masked]>
Date: Sat, 22 Sep 2018 23:12:16 +0000

Hi Jim,

The intention of draft-truskovsky-lamps-pq-hybrid-x509 was that the public key in SubjectAltPublicKeyInfoExt extension is an alternative to the public key in SubjectPublicKeyInfo (though depending on policy, both verifying signatures could be required).  The alternative key pair is bound to the primary key pair, and both will be associated with the same issuing certificate.  This is why we didn’t add alternative AKI or SKI extensions.  Otherwise, the certificate chain would turn into a certificate tree as you point out, greatly increasing the difficulty of processing them.

The next version of the draft will make this requirement explicit.

I don’t understand your statement “This proposal does not have any way of encoding the multiple public keys.”  The alternative public key is encoded in the SubjectAltPublicKeyInfoExt extension.  If you mean there’s no way of encoding > 1 alternative keys (i.e. > 2 total keys in the certificate) then you are correct.  To keep things simple (I know, I know, it’s X.509, that ship has sailed) we restricted it to a single alternative key/signature.  To get multiple alternative keys/signatures, one could define a new AlgorithmIdentifier specifying multiple keys and signatures, as mentioned earlier in the thread.  This can be specified in a separate draft if desired, and the AlgorithmIdentifier could be used in the SubjectAltPublicKeyInfoExt and AltSignatureAlgorithmExt extensions (with the multiple signatures encoded in the AltSignatureValueExt extension) in order to get multiple alternative keys/signatures (with backwards compatibility), or the AlgorithmIdentifier could be used in the RFC5280 fields in order to get multiple keys/signatures (without backwards compatibility).

Thanks,
Daniel

On 2018-09-22, 11:49 PM, "Spasm on behalf of Jim Schaad" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Tim,

jim

-Tim

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Jim Schaad
Sent: Saturday, September 22, 2018 12:18 AM
To: 'Panos Kampanakis (pkampana)' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

Panos,

Jim

From: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 21, 2018 8:08 PM
To: Dr. Pala <[email-masked]<mailto:[email-masked]>>; Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [lamps] Double signatures

Hi Max, Jim,

Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: Thursday, September 20, 2018 1:44 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Double signatures

Hi Panos, all,

Cheers,
Max

Does that make sense?

Erik

Hi Russ, all,

Does this make sense?

Cheers,
Max

Russ

Hi All,

What do you think?

Cheers,
Max

---

Cheers,
Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

  .........,

SIGNATURE ::= SEQUENCE {

--
Best Regards,
Massimiliano Pala, Ph.D.
[CableLabs]
Principal Architect
Security Services, R&D

Spasm mailing list

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 24 Sep 2018 15:26:48 +0000

Thanks Jim. Agreed. A lot of details to hash out.

I didn’t want to lose track of the backwards compatibility offered in draft-truskovsky-lamps-pq-hybrid. And also wanted to leverage the composite PK and Sig for the case where we don’t fully trust on PQ scheme that Max and Erik’s proposal are trying to address. Another issue there is size. Some PQ candidates have really big sizes, so I don’t think there will be a combinatorics issue for cases where the PK+Sig are transferred on the fly.

I think there is value here to be articulated, but we need to be cognizant of all the points you are bringing up and find the devil in the details.

Panos

From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, September 22, 2018 12:18 AM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]
Subject: RE: [lamps] Double signatures

Panos,

Jim

Hi Max, Jim,

Panos

Hi Panos, all,

Cheers,
Max

Does that make sense?

Erik

Hi Russ, all,

Does this make sense?

Cheers,
Max

Russ

Hi All,

What do you think?

Cheers,
Max

---

Cheers,
Max

-Tim

Thanks Tim.

-Tim

Hi Santosh,

Erik

Ryan,

Erik,

Jim

SIGNATURE ::= SEQUENCE {

--
Best Regards,
Massimiliano Pala, Ph.D.
[CableLabs]
Principal Architect
Security Services, R&D

Spasm mailing list