Re: [Sidrops] Multiple publication points in certificate

[Geoff Huston <[e-mail]>]

RFC6487: SIA (sec 4.8.8.1)

   Other accessDescription elements with
   an accessMethod of id-ad-caRepository MAY be present.  In such cases,
   the accessLocation values describe alternate supported URI access
   mechanisms for the same directory.  The ordering of URIs in this
   accessDescription sequence reflect the CA's relative preferences for
   access methods to be used by RPs, with the first element of the
   sequence being the most preferred by the CA.





> 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


Seems that the relevant standard specifies that a relying party should work with the entire list of URIs 
listed in the certificate’s SIA field and  work through them until success or until all locally supported
URI access methods have been tried. The CA provides the CA-preferred order to test the URI list, but the
Relying Party can apply its own  preference to the list of course.


regards,

   Geoff



> On 28 Jul 2022, at 7:36 am, Hove, K.W. van (Koen, Student M-CS) <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops