Subject: [sidr] Multi-signature support and Algorithm agility. The Gratuitous duplication case.

From: Roque Gagliano <[email-masked]>
Date: Wed, 21 Jul 2010 15:26:35 +0200

Hi WG,

This email continues the discussion on the previous one on support for multi-signatures to support algorithm agility on RPKI. 

The first thing that is important to study are the requirements and use cases for multi-signature support in RPKI. The intention is to discuss the gratuitous duplication use case and determinate the need for multi-signature support for ROAs.

If we use the current specification for ROAs and Manifest. Every single-signed ROA will need to be duplicated to generate another single-signed ROA using the new algorithms set. 

This duplication of information has an impact on the CA that will need to maintain separate objects with the same configurations. Relaying parties will be unaffected, they only need to support the new set of algorithms.

When the Relying Parties validate two ROAs (ROA1 and ROA2) that have the same eContent but have been signed with different algorithms set, we may have the following cases:
	a- ROA1 and ROA2 validate using the current ROA validation process independently for each one of them --> Valid entry.
	b- Neither ROA1 nor ROA2 validate using their respective validation process --> Invalid entry.
	c- Either ROA1 or RO2 validate using their independent validation process. As the current validation process for ROA1 and ROA2 are independent, the eContent in ROA1 will be validated and the assertion given by ROA1 (which is the same one as in ROA2) would be valid.

By publishing a single, multi-signed ROA, there is a single object that needs to be published by the CA software and a One-to-One relationship between configured object (eContent) and published object (the ROA). If we apply the "make before break" principle, the validation of a multiple-signed ROA should consider as sufficient that one of the certificates that sings the objects succeeds to validate it.

Use case comments:
	- We cannot force all ROAs to be multiple signed during roll over period, it should be a MAY. So, gratuitous duplications will alway be possible, even today they are.
	- The "make before break" principle give us the same results by validating multiple ROAs with the current specification and the support of multi-signature in ROAs: the sufficient condition.

	- During the roll-ove period, by using the current specification, the CA softwares will increase its complexity by needing to construct multiple ROA objects per configuration. This could be prevented by allowing multiple signatures in a ROA. The validation tool complexity for multiple-signed ROAs is that for each objects, it will have more than one possible validation path to follow.

I look forward to receive your comments.

Regards,
Roque (for the algorithm agility team).