[Sidrops] Re: New I-D: draft-yoshikawa-sidrops-pqc-rpki-00 (PQC signature profile for RPKI)

["[e-mail]" <[e-mail]>]

Hi Loganaden,

Thank you for the information.

The fact that FN-DSA is not yet standardized is also one of the reasons I currently lean toward ML-DSA.
Your point about implementation difficulty from a vendor perspective is also very helpful.

I will take this into account in the section.

Kind regards,

Tomoki
________________________________
差出人: Loganaden Velvindron <[e-mail]>
送信日時: 2026年6月25日 12:54
宛先: [e-mail] <[e-mail]>
CC: Job Snijders <[e-mail]>; [e-mail] <[e-mail]>
件名: Re: [Sidrops] Re: New I-D: draft-yoshikawa-sidrops-pqc-rpki-00 (PQC signature profile for RPKI)

For the rationale section,
I would argue to be cautious with FN-DSA (aka Falcon) as it is
currently hard to get right due
to it requiring constant time operations. It has been a challenge to get right.

Please see an example of a bug here:
https://x.com/bwesterb/status/1509583201848672258

I'm not sure whether router vendors will want to take a chance on FN-DSA.




On Thu, 25 Jun 2026 at 07:30, [e-mail]
<[e-mail]> wrote:
>
> Hi Job,
>
> Thanks, that makes the mixed-tree construction clear!
>
> I'll work the manifest/product key-consistency rule and the certificate
> signature vs. SPKI distinction into the draft. More broadly, I'd like to
> take the feedback from this thread - mixed-tree, composites, and the
> BGPsec scope - and work it into -01 as a more coherent revision rather
> than piecemeal.
>
> Kind regards,
> Tomoki
>
> ________________________________
> 差出人: Job Snijders <[e-mail]>
> 送信日時: 2026年6月22日 20:48
> 宛先: [e-mail] <[e-mail]>
> CC: [e-mail] <[e-mail]>
> 件名: Re: [Sidrops] Re: New I-D: draft-yoshikawa-sidrops-pqc-rpki-00 (PQC signature profile for RPKI)
>
> On Mon, Jun 22, 2026 at 11:09:56AM +0000, [e-mail] wrote:
> > Thank you for the clarification!
> >
> > My earlier statement that BGPsec was outside the scope was too broad, and
> > the distinction makes sense now.
> >
> > I will split it as follows:
> >
> > * The BGPsec UPDATE signature algorithm and the use of the public key
> >   carried in a BGPsec Router Certificate are matters for IDR and
> >   RFC 8608.
> > * The signatures on BGPsec Router Certificates, their issuing CA
> >   certificates, and the associated CRLs are part of RPKI repository
> >   maintenance and remain within the SIDROPS scope, including any updates
> >   needed to RFC 6485/7935/8209.
> >
> > I will revise the draft accordingly. The RPKI signature profile should
> > cover the certificates and CRLs associated with BGPsec Router
> > Certificates, while the algorithm used to sign BGPsec UPDATE messages
> > remains separate.
> >
> > Thank you again for correcting the BGPsec scope distinction!
>
>
> Expressed as a simple rule: all the products listed on a given manifest
> MUST be signed with the same key, and that key also MUST be the key that
> was used to sign that manifest.
>
> The above rule must be checked by RPs, otherwise you'd end up with gaps
> in the certification chains, which would be a security issue.
>
> To produce mixed certification chains: sign with algorithm X over a CA
> certificate that has as SPKI a public key of algorithm Y, and sign that
> CA's manifest using algorithm Y. (Somewhat similar to how BGPsec router
> certificates are signed with RSA-2048 but contain a P-256 public key in
> their SPKI.)
>
> Kind regards,
>
> Job
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]