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?
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
==== 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.
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.
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.
==== 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.)
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
