Hi WG, In draft-ietf-sidr-rpki-algs Section 3 it was recommended to explore the idea of supporting multi-signatures to facilitate the process of algorithm agility. At the draft team we have been doing just that.
This is a rather complex issue because it touches basic concepts in the RPKI
design and most of SIDR documents. At the IETF78 meeting we will have only 10
minutes of discussion for all algorithm agility issues, so we wanted to present
our findings to the mailing list to start the discussion.
The main conclusion that we would like to arrive is if we should draft the
algorithm agility document as if multi-signatures is possible. In order to be
able to answer that question, I will send two separated emails with the
following questions:
1- which are the requirements that would justify multi-signature
support from the algorithm roll-over? and what are the impacts in CA and
validators implementations?
2- what changes would be needed in current SIDR document?
Some context:
- Multi-signature is not supported in RFC 5280, which means that certificates
and CRL will need to be single signed. This fact implies that in order to
perform the algorithm transition, during the roll-over period, parallel
structure will need to be maintained to attest an entity "right of use" of its
resources in the context of RPKI. Depending on how the repositories are
managed, the different RPKI hierarchies may or may not share common publication
points.
- RFC 5652 defines the SignerInfos type as a set of SignerInfo objects. This
means that a single CMS object can support several signatures and also carry
several certificates associated with each one of those signatures.
By allowing multiple signature in the CMS objects, the idea is that different
PKI trees are maintained but used to verify the same CMS signed objects. Some
use cases will be explored in a separate email.
When analyzing the impact of multiple signatures in the current SIDR documents,
we only considered the ROA and Manifest objects. The provisioning protocol and
the TA CMS objects are both signed by non-RPKI CAs and thus were not analyzed.
Regards,
Roque (for the algorithm agility team).
Note: Multi-signature support for ROAs were already explored in this WG in a
different context.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
