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).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
