Thank you! On Tue, Jan 29, 2019 at 3:38 AM Tim Bruijnzeels <[email protected]> wrote: > > Hi Alberto, > > [removing the email addresses which I think are no longer valid] > > I am not an author of this RFC, but I wanted to share my interpretation as an > implementer of CA and RP software. > > > On 28 Jan 2019, at 19:46, Alberto Leiva <[email protected]> wrote: > > > > I have three questions: > > > > ==== 1 ==== > > > > Section 4.8.8.1 has the following paragraph: > > > > This extension MUST have an instance of an accessMethod of id-ad- > > caRepository, with an accessLocation form of a URI that MUST specify > > an rsync URI [RFC5781]. (...) 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. > > > > Those MUSTs confuse me. What is the intent behind them? > > I agree that this is somewhat confusing. My interpretation of this is that > the text tries to leave the option for future transport protocols, other than > rsync, open. However, there are no accepted other transport protocols defined > at this time. > > > 1. Exactly one of the caRepositories MUST be URI, and MUST be RSYNC: > > > > caRepository URI RSYNC > > caRepository other whatever > > caRepository other whatever > > caRepository other whatever > > > > 2. Exactly one of the URI caRepositories MUST be RSYNC: > > > > caRepository URI RSYNC > > caRepository URI other > > caRepository URI other > > caRepository other whatever > > > > 3. There MUST be at least one RSYNC URI caRepository: > > > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository URI whatever > > caRepository other whatever > > > > 4. (Unlikely, I realize) All of the caRepositories which are URIs MUST > > be RSYNC: > > > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository other whatever > > caRepository MUST be a URI, not other. There MUST be one and only one rsync. > There MAY, in future, other URIs for 'alternate URI access mechanisms' - one > for each. However, no other such mechanisms are defined. > > So, for all intents and purposes you can expect 1 and only 1 SIA of the type > caRepository and it MUST use rsync. > > > > > ==== 2 ==== > > > > Is the above verdict supposed to be consistent with the other Access > > Descriptions in the RFC? They generally use somewhat different wording: > > > > AIA: > > > > The preferred > > URI access mechanisms is "rsync", and an rsync URI [RFC5781] MUST be > > specified with an accessMethod value of id-ad-caIssuers. (...) > > Other accessMethod URIs referencing the same object MAY also be > > included in the value sequence of this extension. > > One, rsync. And the value of the AIA is rather limited. It provides a hint to > where the parent certificate may be found, but this may be incorrect without > invalidating the object. Typically the certificate is found through top-down > validation so the parent CA certificate is already known. > > > > CA SIA.rpkiManifest: > > > > This extension MUST have an instance of an AccessDescription with an > > accessMethod of id-ad-rpkiManifest, (...) > > with an rsync URI [RFC5781] form of accessLocation. (...) > > Other accessDescription elements MAY exist for the id-ad-rpkiManifest > > accessMethod, where the accessLocation value indicates alternate > > access mechanisms for the same manifest object. > > Again my interpretation is that there can be only one SIA of this type in > practice, and it MUST be rsync. > > > > > EE SIA: > > > > This extension MUST have an instance of an accessMethod of id-ad- > > signedObject, (...) > > with an accessLocation form of a URI that MUST include an rsync URI > > [RFC5781]. (...) Other accessDescription > > elements may exist for the id-ad-signedObject accessMethod, where the > > accessLocation value indicates alternate URI access mechanisms for > > the same object, ordered in terms of the EE's relative preference for > > supported access mechanisms. > > > > Other AccessMethods MUST NOT be used for an EE certificates's SIA. > > Same.. > > Except that in this case I really feel that this is a formality. This SIA > points to the object itself. I assume that you won't need this information > once you have found the object. > > > ==== 3 ==== > > > > Section 4.8.8.2: > > > > Other AccessMethods MUST NOT be used for an EE certificates's SIA. > > > > It seems that this requirement has been superseded by RFC 8182: > > > > 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]: > > (...) > > This extension MUST use an accessMethod of id-ad-rpkiNotify (...) > > > > Has it been superseded? Or does the second quote only apply to CA > > certificates? (which would make the word "produce" seemingly out of > > place.) > > > > (Aside: 8182 does not appear in the 6487 Updated By list.) > > Good point, and I see another omission upon re-reading RFC8182 (RRDP) - of > which I am a co-author.. > > The SIA defined in section 3.2 of RFC8182 is intended as an addition to the > existing SIAs defined in RFC6487. Furthermore it is only expected to be > present in CA certificates, since these are the only currently defined RPKI > objects for which signed products may be found. Including the > id-ad-rpkiNotify in an SIA of en EE certificate of e.g. a manifest does not > hurt, but it's also pointless. This intent is phrased in the last paragraph > of 3.2: > > The accessLocation MUST be an HTTPS URI as defined in [RFC7230] that > will point to the Update Notification File for the Repository Server that > publishes > the products of this Certificate Authority certificate. > ^^^^^^^^^^^^^^^^^^^^ > > But this is not phrased as clearly as it could have been. > > > > > > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
