Re: [Sidrops] Multiple publication points in certificate

["Hove, K.W. van (Koen, Student M-CS)" <[e-mail]>]

Hi Job, all,

I did indeed see that draft from sidr. If it is possible, then it might make the repository migrations as touched upon by Tim yesterday far simpler (as you could go from "A" to "A and B" to "B").

I quickly created a certificate with two RRDP points. The TAL for it can be found here: https://p-91dd2bba-7290-4399-baa4-4114f4b25e33.rpki.koenvh.nl/koenvh-P.tal 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            79:6a:49:49:3d:05:6d:17:2a:ba:b5:79:65:d8:46:82:16:52:77:ef
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=226f435fd04b482d853462ad40735c05bd34b8f2
        Validity
            Not Before: Jul 28 09:25:51 2022 GMT
            Not After : May 16 09:25:51 2032 GMT
        Subject: CN=226f435fd04b482d853462ad40735c05bd34b8f2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d3:0f:ca:b4:9c:2b:0b:c2:3b:22:6f:1e:bb:52:
                    08:06:72:6b:1f:29:99:83:38:6d:af:fd:2e:ad:de:
                    e4:7f:ab:fd:8c:92:4e:4d:4d:b3:b3:5f:83:49:3a:
                    f1:83:d8:48:0f:5a:45:91:5a:e2:b2:ba:5e:bc:a9:
                    a2:6d:7d:af:85:94:81:6e:59:c1:0f:17:8e:ad:ff:
                    40:35:74:ac:72:75:a2:72:dc:99:ae:1f:d2:89:56:
                    86:aa:55:ef:22:1d:25:7b:e5:77:0a:a6:1a:de:55:
                    39:10:57:f9:4f:53:21:ed:c3:01:39:6f:09:d0:7a:
                    16:26:71:86:3d:0b:dd:99:25:73:63:d5:84:df:f5:
                    30:15:b0:bd:60:bf:41:33:3f:3f:b1:82:04:ac:4b:
                    cc:ac:56:c6:81:4a:db:40:a7:04:8c:1c:68:32:de:
                    4d:e2:4a:ed:77:27:1c:24:b8:cf:4b:df:94:43:ce:
                    6c:a9:8f:86:ff:d7:c3:e4:78:15:15:ee:f7:89:01:
                    f2:04:eb:35:1b:a9:6d:19:c0:5a:d3:5f:d4:52:9f:
                    cc:9f:e0:57:bf:a1:a2:8f:e0:e4:e8:64:8e:bb:d1:
                    f9:0b:62:a5:8c:90:62:c5:6c:7e:52:34:b1:81:1a:
                    b7:35:ca:49:86:9d:19:90:25:62:29:aa:a8:e6:af:
                    84:5f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                22:A0:53:E0:41:42:C7:B8:F0:CA:A4:51:F5:94:38:EF:EE:E0:1D:09
            X509v3 Authority Key Identifier: 
                keyid:22:A0:53:E0:41:42:C7:B8:F0:CA:A4:51:F5:94:38:EF:EE:E0:1D:09

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            Subject Information Access: 
                1.3.6.1.5.5.7.48.10 - URI:rsync://p-91dd2bba-7290-4399-baa4-4114f4b25e33.rpki.koenvh.nl/repository/koenvh.mft
                1.3.6.1.5.5.7.48.13 - URI:https://p-91dd2bba-7290-4399-baa4-4114f4b25e33.rpki.koenvh.nl/notification.xml
                1.3.6.1.5.5.7.48.13 - URI:https://p-91dd2bba-7290-4399-baa4-4114f4b25e33.rpki.koenvh.nl/notification2.xml
                CA Repository - URI:rsync://p-91dd2bba-7290-4399-baa4-4114f4b25e33.rpki.koenvh.nl/repository/

            X509v3 Certificate Policies: critical
                Policy: 1.3.6.1.5.5.7.14.2

            sbgp-ipAddrBlock: critical
                0.0.....0....0.....0....
            sbgp-autonomousSysNum: critical
                0...0.0
..........
    Signature Algorithm: sha256WithRSAEncryption
         6f:36:7d:e7:81:68:46:b4:1c:af:b6:13:8e:ff:30:2f:a1:c9:
         aa:a8:98:60:a9:68:0c:21:64:c4:90:48:f9:e3:c6:89:c9:f0:
         da:0f:82:af:3f:c6:75:d0:82:43:b1:1f:2d:47:10:57:c0:77:
         4b:6f:70:ba:b9:9d:c4:e2:1d:0c:4e:9a:2c:88:6a:39:83:c2:
         c0:48:73:fa:f1:2c:c6:87:0c:cb:14:37:d9:71:2b:7b:1e:d5:
         5b:89:ea:9d:aa:ce:9c:8d:bd:7a:fa:41:51:d2:eb:ed:83:2a:
         18:14:9c:bf:be:a6:2e:86:b5:4f:9a:11:4a:9e:da:b9:97:f2:
         1e:90:43:d4:2d:9f:21:fe:a0:16:b3:e0:3a:a3:41:a6:c1:cf:
         4d:6d:35:f2:d5:00:de:05:ee:68:bf:69:36:b4:1f:e2:69:27:
         ba:da:34:a7:52:48:7e:ff:68:7f:20:c5:e4:32:da:24:fb:01:
         cb:93:a9:dd:6c:d1:a1:dd:08:11:f3:17:01:82:ff:95:cf:89:
         bb:ee:60:39:b6:fc:0a:c9:df:c1:c9:c2:52:ef:ad:03:39:9c:
         8d:12:6b:42:ef:6e:01:5e:01:32:18:41:91:b6:3b:e2:ec:dd:
         fa:84:9e:a4:0e:54:56:35:fa:cc:e5:3f:24:dc:bd:33:25:ef:
         53:bd:e8:df

So far it seems that:
- Routinator only visits the first
- OctoRPKI only visits the second
- rpki-client outputs "RFC 6487 section 4.8: SIA: rpkiNotify already specified" and visits neither
- FORT outputs "Extension 'SIA' has multiple 'rpkiNotify' HTTPS URIs." and visits neither

So current behaviour seems to be quite diverging. 

Cordially,
Koen van Hove

From: Job Snijders <[e-mail]>
Date: Wednesday, 27 July 2022 at 22:51
To: Hove, K.W. van (Koen, Student M-CS) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Sidrops] Multiple publication points in certificate
Hi Koen,

On Wed, Jul 27, 2022 at 08:17:03PM +0000, Hove, K.W. van (Koen, Student M-CS) wrote:
> Recently I investigated strategies to make ROAs more resilient to
> outages by publishing them at multiple publication points. During the
> discussion, I noticed that the SIA AccessDescription extension on
> certificates, specifically the id-ad-rpkiNotify accessMethod
> referenced in RFC 8182 section 3.2, does not mention that there can
> only be one. As far as I can see, there is no restriction in the
> standard that there must be at most one for each type. In theory
> multiple RRDP URIs (or rsync URIs for that matter) should be possible.
> Is this correct, or did I overlook something? And if so, what is the
> expected behaviour when multiple are defined? 

There is some prior work that might be of interest to you:

    https://datatracker.ietf.org/doc/html/draft-ietf-sidr-multiple-publication-points

Specifically section 4, which notes:

    "The support for multiple operators in the RPKI Certificate
    Authority (CA) and End Entity (EE) certificates is supported as the
    RFC 5082 allows multiple repository publication point operators as
    the SIA, AIA and CRLDP are implemented as sequences. Consequently,
    no changes are needed on the existing RPKI standard and this section
    could be considered informative."

I am not sure what the expected behavior would be when multiple are
specified in the Subject Information Access extension.

I believe rpki-client (at the moment of writing) only uses a single
id-ad-rpkiNotify access description entry (if encountered) and will
ignore additional entries (if multiple exist).

Reviving draft-ietf-sidr-multiple-publication-points (or starting from
scratch in a new document); outlining what the desired strategy is, is
a possibility. I suspect an argument can be made that if multiple
id-ad-rpkiNotify are specified, an RP has to contact *all* publication
points, to increase its chances of finding the Manifest with the highest
ManifestNumber (I imagine multiple pubpoints existing, increases the
chances of them those being out-of-sync with each other.

I look forward to your findings.

Kind regards,

Job