Why not let algorithm identifier dictate the number of signatures and their
syntax?
From: Spasm [mailto:spasm-bounces@xxxxxxxx] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <ryan-ietf@xxxxxxxxxx>; era@xxxxxxx
Cc: 'SPASM' <spasm@xxxxxxxx>; x500standard@xxxxxxxxxxxxx
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 <spasm-bounces@xxxxxxxx <mailto:spasm-bounces@xxxxxxxx> > On Behalf
Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: era@xxxxxxx <mailto:era@xxxxxxx>
Cc: SPASM <spasm@xxxxxxxx <mailto:spasm@xxxxxxxx> >; x500standard@xxxxxxxxxxxxx
<mailto:x500standard@xxxxxxxxxxxxx>
Subject: Re: [lamps] Double signatures
On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <era@xxxxxxx
<mailto:era@xxxxxxx> > 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?
