Hi All, I see this erratum went to sidr@ but not sidrops@. I suspect there is considerable overlap between the two lists, but just in case, I thought I’d add sidrops before any disposition is decided for the erratum. The discussion so far is at https://mailarchive.ietf.org/arch/msg/sidr/7ZwQsV9gsqEgZurkf1nAtCvlZes/
If you do have an opinion and haven’t chimed in yet, now would be a good time. Thanks, —John > On Nov 4, 2022, at 7:38 AM, RFC Errata System <[email protected]> > wrote: > > The following errata report has been submitted for RFC8182, > "The RPKI Repository Delta Protocol (RRDP)". > > -------------------------------------- > You may review the report below and at: > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7239__;!!NEt6yMaO-gk!Hmh7ECsx8QBjyj3iaVOY12TDeyhe2F4SPyvBI49N5TT_-a7Coy9Z9a_jFJ4nat5SkUTodPX9IcgXbnT_H_fC5A$ > > -------------------------------------- > Type: Technical > Reported by: Job Snijders <[email protected]> > > Section: 3.2 > > Original Text > ------------- > Certificate Authorities that use RRDP MUST include an instance of an > SIA AccessDescription extension in resource certificates they > produce, in addition to the ones defined in [RFC6487]: > > Corrected Text > -------------- > Certificate Authorities that use RRDP MUST include an instance of an > SIA AccessDescription extension in CA resource certificates they > produce, in addition to the ones defined in [RFC6487]: > > Notes > ----- > Between draft-ietf-sidr-delta-protocol-04 and > draft-ietf-sidr-delta-protocol-05 a bit of text was removed (perhaps because > it was considered redundant). But, unfortunately that snippet helped > establish important context as to what types of certificates are expected to > contain the id-ad-rpkiNotify accessMethod inside the Subject Information > Access extension. The text that was removed: > > """ > Relying Parties that do not support this delta protocol MUST MUST NOT > reject a CA certificate merely because it has an SIA extension > containing this new kind of AccessDescription. > """ > > From the removed text is is clear that id-ad-rpkiNotify was only expected to > show up on CA certificates. However, without the above text, Section 3.2 of > RFC 8182 is somewhat ambiguous whether 'resource certificates' is inclusive > of EE certificates or not. > > RFC 6487 Section 4.8.8.2 sets expectations that only id-ad-signedObject is > expected to show up in the SIA of EE certificates "Other AccessMethods MUST > NOT be used for an EE certificates's SIA." > > The ambiguity in RFC8182 led to one RIR including id-ad-rpkiNotify in the SIA > of the EE certificate of all signed objects they produce (such as ROAs). The > RIR indicated they'll work to remove id-ad-rpkiNotify from all EE > certificates their CA implementation produces. > > It should be noted that the presence of id-ad-rpkiNotify in EE certificates > is superfluous; Relying Parties can't use the rpkiNotify accessMethod in EE > certificates for any purpose in the validation decision tree. > > (Verifying this Errata does not block a future transition from rsync to > https; as RFC6487 Section 4.8.8.2 leaves room for additional instances of > id-ad-signedObject with non-rsync URIs) > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8182 (draft-ietf-sidr-delta-protocol-08) > -------------------------------------- > Title : The RPKI Repository Delta Protocol (RRDP) > Publication Date : July 2017 > Author(s) : T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
