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

[Loganaden Velvindron <[e-mail]>]

I've created a pr on the github repo.



On Thu, 25 Jun 2026, 09:16 [e-mail], <
[e-mail]> wrote:

> 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]
>