Re: [lamps] PQ-composite OR or K-of-N logic

Serge Mister <Serge.Mister@entrust.com> Sat, 23 April 2022 14:15 UTC

Return-Path: <Serge.Mister@entrust.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97C3A1571; Sat, 23 Apr 2022 07:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gXUIrRDZ5mm; Sat, 23 Apr 2022 07:15:03 -0700 (PDT)
Received: from mx07-0015a003.pphosted.com (mx07-0015a003.pphosted.com [185.132.183.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745433A1570; Sat, 23 Apr 2022 07:15:03 -0700 (PDT)
Received: from pps.filterd (m0242864.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23NDCFRG019228; Sat, 23 Apr 2022 09:15:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=mail1; bh=doUZ2VxxawTnIj1oyPsrZbHh4yxSdyefK++pqHrnknU=; b=A+iDxS/dv7B1+32B9x4qy07sMcgSTnXJohg1QM1hr+MCdBgf10u0yIY1vsQ7Y6gUs7od bav7BhBQZ6frr/9ukRz5jdUy9NcTRdIWLzil9cs3wKubLb8YJeheuIVxphdAQPz32wTE wmoxNp8vMcWw8banB4esM1SrVokLdXG6nk868IoRoAfkJCf6N/YolpFjqUzA5/9S7FvS jI8r14w/vSZ7PrISgFJyt9NrqhBXLm7KEvuvawcBeok4BSZWV/ujuUQIkkjhmeHXRn9y 6tmUPsKjsmoWJ6OONn7Mw5n6TP+ggbP8HCcHqbMYhNBcDGXVFGYobgsRlRfpMfu6/YzE fw==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 3fme52ggc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Apr 2022 09:14:59 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JJrZk/IKfXktqqWjg9FS+MbHRpvk6nKrreNMU6gDaswcuxLMl9kYgbX550chGEQqBttYCzmxVNGwYGSDCAHGq1OKTWqfFlWDeefPuUZoa5hBz1QPLAZc8VOtPyOYL6gC9yCHsLV3C/DTxSnPE3cuMedcMQkakRIRnmyTog7URTTLta7ucfq0vR61mt6y2ZNe7aU35Xb2DwJ2VVMHhKbR57gnL13DxpGfTJobG+titBYNdmSsDClSGLBeC3dd9DKHymvLQyJE4k2dsKsr8FnHEv0Ig6i6E/4iGoHgDGVPqJ0tbhq0F4sd46Gcn+petCqHr8w/ln2FnMw9iLmMXv++BA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=doUZ2VxxawTnIj1oyPsrZbHh4yxSdyefK++pqHrnknU=; b=FjdWEekjxnVagKBT25XVmADXM0dxYU1p82Rt70Pj76D2NusGrgt39MleJx6HjTgy4AqjPBE2b4a8t4h1m4U6ZgOK3IkJEsicCdClso/cqwJWCjVatGPOF2bvlZd2lf++zVoTDAeIuu/mEK2b98qecinBt+A8cOOr6nr/K/goltk5Gbiz1d3tCi1lHB0gpUaVwoFR4bOi2nrc/1QA5BmlOQvvB59ITHlZqcwwXKdzHqfQ0O8yA5MyjR9X1D+IKJFp9J1Np+SWMjj+WMPMdEYDMkDzeq63jsPzTPEcslcDkaAvubKTtDXcIACu4h4Wo5TAL+396uQ/nXQ3Aaw4IYXq+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from DM6PR11MB3802.namprd11.prod.outlook.com (2603:10b6:5:143::30) by BN0PR11MB5695.namprd11.prod.outlook.com (2603:10b6:408:163::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.13; Sat, 23 Apr 2022 14:14:55 +0000
Received: from DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::e041:a6c2:afd0:da85]) by DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::e041:a6c2:afd0:da85%7]) with mapi id 15.20.5186.019; Sat, 23 Apr 2022 14:14:54 +0000
From: Serge Mister <Serge.Mister@entrust.com>
To: "Kampanakis, Panos" <kpanos=40amazon.com@dmarc.ietf.org>
CC: LAMPS <spasm@ietf.org>
Thread-Topic: Re: [lamps] PQ-composite OR or K-of-N logic
Thread-Index: AQHYVsABI6qKAEk3Bku3A/xLzjJfHKz9gwrw
Date: Sat, 23 Apr 2022 14:14:54 +0000
Message-ID: <DM6PR11MB3802936F1411B4015CBC40A496F69@DM6PR11MB3802.namprd11.prod.outlook.com>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <29E39FB1-D8E5-40E9-AFC0-5A8EBBB705DF@vigilsec.com> <DM6PR11MB38025338B4FA3AED0AA99E3196F79@DM6PR11MB3802.namprd11.prod.outlook.com> <43b496274de5472480b4467fe84d3d86@EX13D01ANC003.ant.amazon.com>
In-Reply-To: <43b496274de5472480b4467fe84d3d86@EX13D01ANC003.ant.amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 938ed06f-4c22-4b90-9664-08da2533a3e0
x-ms-traffictypediagnostic: BN0PR11MB5695:EE_
x-microsoft-antispam-prvs: <BN0PR11MB5695BFC61624198B4675221096F69@BN0PR11MB5695.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rt+D/YsOGPaFSsoi6whWt9VpbJpe2s87e6O2mngNoOVio4N0oOCs3Agky9uMpjzqMq1OucM7UGEwNCtP8kkMXS57wGDvzvVKAWSXXJXAVMs8phca59EGKdyFDl/FBJ18F2/hea/qzhE+ngFxYcWVenP7LLYwR9x1v5qW4KOtTc2JEdeEDrvnLdXcNlB99omsSB3bff+jKkDM2+6y0DmPDXETSPVibNw7bQFarIsitWP/U/po8jNwlIhv+9mqL21xJ93xqSuk5HhlA/c11QaQWrqT9EgpkyWhUG1m/+I8glV1rjHTWtfmDbh8gZNWB9FxGp/MUqQ0sYYc1NR/r6tBWkzkX/mSGu6hHx69xZrjO2yiudJ980a0en2/wNhOWDAE3+g4f6THRkl1mCRHjlJmR2R1oeFsspNhEgSjZ+2jOMm0CIEej5Jo83HM6kXrckNlWzNMzSIBE38NoK7rXNjLNg2KoHRLDaZIq1+xc9lu3taJM/Sazjq0DhL+waT8k+OEsLvPto6qE115Xz/1k1HC5ApqT+AyQ0Nncl+XlEfeFS0Anr6Po0WvqysW8qE+bswaLL/s+gD0OvLUtAPejf7Z1A8EPkzbPEmOeVbGZp7L+pVUEN2bYeb/2QRqzjr8O3pac4ZvXh7vu27bn0amZu2CdvGWqsrh1tzFfpU3WXFdpJGsRzwr5r+MqU7zT4bMQY7H+k6GfoCK9ol786ebZr4fViuIQUk59IRJNwNHHDRrjiy9Df8nwCHolJEgfDxefU+ecnwcZ8E+inXbPgrBAUlZAx6bV2mXD4DSygRPpfBhf+8/P7mnDhiAEV34gsUJSLI65STqL5jZoUNJok0oGtAWXw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3802.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(316002)(7696005)(66476007)(66446008)(66556008)(122000001)(38070700005)(6506007)(38100700002)(2906002)(86362001)(508600001)(8936002)(53546011)(66946007)(76116006)(64756008)(55016003)(71200400001)(33656002)(26005)(5660300002)(966005)(83380400001)(9686003)(186003)(52536014)(4326008)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: kxcG1brDvZZpxqoS+YNKglPemGU4BtUSObrdunIm/q/md8v70S80/EOJYp+cpBTpePfMS2Jz4wc9w4jc0wbLh81ZrM6Dc0PqavdWBK2Jh//5JUyxorSpwPjsj1j39Ge/u90Yw6xxWgsGvZRD5len+ObFk2G0hrbNHXVdnJy4V9K26UsPMftHw0Ugt8vYVWKmtZJgI4S9EKzXFwdmZxEqWxyloBc8eAr9yl+tJVbdf2b0Z1jIyYtMA1qaKncpa1VkbP6q6cWdAzaxNA7JW6kp8mKxPxKmpFPjB5r6G0Y5dgXl1GQmWjCZUIp+UZJkGxz0QrYT/QNt2g9M80k+U2PAUsJv4ri1e7FH/wKeL6/O86hsO6XOPTIOY2EWewQEpbfrcbf9seZ+looL+h3araL3Kopd72w0dkjwkT9B2dCkznsGeZ0Nsb3MJxHAGRj75R8AnowLfVm7WTjUCOeJm/GGJdA7ZqC020k6+fA9v3EKkNIIO8vWxQAEExqJyFjIpsB77ha9Ymt7x2gwvnD0Od/zfhjaQ9OnS1Fwflq8dOdeaanr7OfSdc71asVmPaAtmDkwNg9e73T8m9kcPZy3zMNys+9BQLgFKuvQVZuBKvDb2n8OCWc3eymLBX+X1OxfOTd05b3eQZvnq6PQ2TaSXGdjo0B00X7w5XYNPAC14U9esq33NIes8GwBXweulGi7fTk7ZmbPV2rOUsOqJf8CMgfMAPHqyacgbXRfj3+DGh6WrImZKWCUO1cmO4xM7GyyeJOFGP8buqv0EKjSIjP1jQgWqs0peSaHo6V7rulhrHxiXGWoQatFlU4+9JLQ5uC4Ls26Ra1OmyfXS4r8zwH0BVfb+VDaO38CDtzgwmTHC+Pz0talp4lMQfu7UTuvtRD3KBgNRTdM2CY81cDBM6eNPizbZjIhgYKIg6AtKRtq+WiazVvFnj0oZs+uEvuIxB8fc3DTJVZHYlysyRVdYg9X1fPUPzMbrKu4ITOhac/Os3P8N+eneFKC8aSaDhvmXwYSqwCoS+Oi7vD/i3tvdAFJ5uMGNaShOAWArm8KbVikcKzB/V4lQaT8wfEHGQf3rAt3NJQ/9IHzh0ABB4SAfe/JzMK0MW76yyKjOFu3jEXuHmmq4/bY6hJoCzRkbtAWMBK6kr5ThWO7SpoXo9xdPY3q0szgZ9GmPn3gRWgIkhfuxJabK5DXVNci6We10v7kS5dp+7Wn3QbbiEVNKQI1rHfP2o9837F7rIdq9U+eq8oEiatGYsBNDUwb8Anv0Da5ynNcCM2NeykzJ7qKbC0QUQN7lY3gt3DRHUxwILOPayaYv2D+tCSXCGsHYWldg9Vo7WiqvfGN5YKVtq+HjeJrD9jTb5FylsLGdajlLyfkdLljdP7r8nQn7PPRvIQw7Rz8fMrIK/HzO5EggBT71YFSH6dpnvlOx2CjbRfjRxpd2zW34OCtExHGW97DxUO5LoQwr7kmSaue+XnJ2Q7Ddx7aeCYygXjaqzDqt3P2/I3D77VofJpfmzfMQ9IYaasZ4KVXOgLaH8dml2vaGnTOHC5WazDpjoLREUp8lfQpu1hpX4JYbMflTSytPqEtHaBvoHrP3kMVkwek0eTloYoY6hp3hjoPa8cO01eeY8OOzLjM4q/Jvx5dUe26nUlL0Rz/7iYAKmbFNYDPEIpF12nG/b83YTA17CM2q2+RR1vQqy1A8+Pim7xwD0BJdqAfYpN9+0ZBSqCtLLqsMNNnahz2RWhDVLvtdTsOxQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3802.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 938ed06f-4c22-4b90-9664-08da2533a3e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2022 14:14:54.9154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9WtEIpbXx+ac5LVEF8H3bUj2e0mIhh9mwrWS2cp55Dk52xTLXj1s0NHPj6S8jZCS+XqeweL3O48BAyu9DaM9YgRhBt2CGg/YW+2HUN8nn0M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR11MB5695
X-Proofpoint-GUID: 62cpQuhLQKg0LFpbvsQKIlAVPy-qb0NI
X-Proofpoint-ORIG-GUID: 62cpQuhLQKg0LFpbvsQKIlAVPy-qb0NI
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-23_01,2022-04-22_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 spamscore=0 suspectscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204230067
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/5vCrv9390Pt1_X1mFkWeujZdmxY>
Subject: Re: [lamps] PQ-composite OR or K-of-N logic
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2022 14:15:09 -0000

Hi Panos,

Suppose we have a signature algorithm with parameters:

  - id-composite-signature
  - params specifying either AND (the verifier must verify all component signatures), or Any (the verifier must verify at least one component signature)

and also a generic id-composite-key OID that (just) identifies a composite key

In SubjectPublicKeyInfo, one could specify:

  1. id-composite-key - This would allow use of the key pair with any signature scheme compatible with composite keys 

  2. id-composite-signature (without parameters)  - This would allow use of the key pair with this signature algorithm only, in either AND or Any mode

  3. id-composite-signature with params AND - This would allow use of the key pair only with this signature algorithm in AND mode

  4. id-composite-signature with params Any - This would allow use of the key pair only with this signature algorithm in Any mode (not sure why one would choose this option - if Any is ok, AND is ok too)

So now the key owner (or certificate issuer) can limit a composite key's use to a particular algorithm, or leave it open.  Does that help?

I'm thinking that someone using composite for compatibility would choose option 1 or maybe 2.

Someone who is starting to lose trust in RSA but also doesn't quite trust the PQ algorithm would choose 3.  The CA would be asserting that verifying just one of the component signatures is not enough to ascertain that the signature is associated with the identity named in the certificate.


Serge

-----Original Message-----
From: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> 
Sent: Friday, April 22, 2022 11:12 PM
To: Serge Mister <Serge.Mister@entrust.com>
Cc: LAMPS <spasm@ietf.org>
Subject: [EXTERNAL] RE: Re: [lamps] PQ-composite OR or K-of-N logic

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

______________________________________________________________________
Hi Serge, 

>   - OIDs that identify specific signature algorithms, possibly with parameters, that could be specified in SubjectPublicKeyInfo and would then limit use of the composite key to that signature algorithm (and specified parameters, if they are specified).

I am not following how that ties to the OR logic. Are you suggesting that a signer has two public keys (which will go in its cert) and the corresponding public key OID will say "sign with one key but the other one does not matter" (something like OR logic)? If the signer has two keypairs he better trust both algorithms to sign with. 

Panos


-----Original Message-----
From: Serge Mister <Serge.Mister=40entrust.com@dmarc.ietf.org> 
Sent: Friday, April 22, 2022 2:24 PM
To: Russ Housley <housley@vigilsec.com>; Kampanakis, Panos <kpanos@amazon.com>
Cc: LAMPS <spasm@ietf.org>
Subject: [UNVERIFIED SENDER] RE: [EXTERNAL] Re: [lamps] PQ-composite OR or K-of-N logic

Hello all,

As I mentioned on the call, I'm not fully convinced that deciding which signatures a relying party must verify is entirely a decision for the relying party.  When an entity obtains a certificate from a CA, signatures verifiable with the certificate are attributed to the entity named in the certificate.  The certificate holder then wouldn't want a weak key bound to their identity.  If a composite key can be used in "OR" mode, the key is weakened when any of the algorithms is weakened.

This view is supported I think by RFC 4055 section 1.2 which states that the rsaEncryption OID implies that "the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP" and also "When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information".

Applying this idea to composite, and in line with the idea that it is the signature algorithm that should dictate whether signing and verification require all or only some of the component signatures to be generated/verified, I'm picturing that we could have:

  - An OID that identifies a composite public key, that is agnostic to how those keys are used (similar to rsaEncryption)
  - OIDs that identify specific signature algorithms, possibly with parameters, that could be specified in SubjectPublicKeyInfo and would then limit use of the composite key to that signature algorithm (and specified parameters, if they are specified).

The latter OIDs would also be used in SignatureAlgorithm fields.

Serge

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Friday, April 22, 2022 12:41 PM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>
Cc: LAMPS <spasm@ietf.org>
Subject: [EXTERNAL] Re: [lamps] PQ-composite OR or K-of-N logic

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

______________________________________________________________________
(No hats)

On the call, many people expressed concern that the approach in the I-D tries to bind the signature verification policy to a public key.  These people prefer an approach where the relying party applies their own policy.  I tend to agree that the verifier should determine the policy.

Russ

> On Apr 21, 2022, at 11:00 PM, Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> wrote:
>
> Hi all,
>
> This was discussed in the interim meeting yesterday, but I promised to also bring it up to the list.
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/__;!!FJ-Y8qCqXTj2!ffo5wF8YG-Y6-Yy18R5u7wBsVKkWkyeR7qUlRxq7XBZvfx0AboetFja4fsrL-voFL9twTLwMovXZX-7WEwPpKF88kw$  includes a Composite-OR and a Composite-OR-Legacy mode. And Mike also mentioned K-of-N logic in the meeting. These allow for the signer to define the verification logic of the composite signature. As many pointed out in the interim meeting yesterday, it is counter intuitive for the signer to tell the verifier what to verify. If the verifier does not trust one of the signatures in the composite signature it can make a decision on what to do based on its policy. It could fail unless all sigs verify or do something else.
>
> Adding granularity in the signature to tell the signer what to do not only changes what we know and use today, but it also opens cans of worms with complexity and mistakes that could happen in implementations.
>
> I suggest to just define one mode. That is a composite sig is two signatures of the same thing with two algorithms using two keys. The signer is supposed to verify the composite signature. How it does that is beyond this draft.
>
> Rgs,
> Panos

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ffo5wF8YG-Y6-Yy18R5u7wBsVKkWkyeR7qUlRxq7XBZvfx0AboetFja4fsrL-voFL9twTLwMovXZX-7WEwMko2CdcA$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.