Hi Michael, Looks great. Many thanks for putting it together! -Ben On Mon, Nov 22, 2021 at 11:45:36PM -0500, Michael Douglass wrote: > > On 11/16/21 20:53, Benjamin Kaduk wrote: > > Hi Michael, Catherine, > > > > Catherine -- thanks for the review! > > > > Michael -- thanks for the proposed text. It's certainly better than > > nothing, and we could iterate further if needed. > > In particular, I wonder if we actually want to duplicate some of the > > considerations from RFC 3986 that also apply to XML references, such as the > > lack of a stability guarantee that fetching the referred-to resource will > > actually produce the same results over time and for all entities that might > > be performing the fetch operation. > > Thanks Ben. > > I can do that. Clearly the security section in RFC3986 is applicable to > any URI. > > For XML documents it may also be the case that the reference is invalid > or becomes so over time. > > === OLD === > > 10. Security Considerations > > Applications using the LINK property need to be aware of the risks > entailed in using the URIs provided as values. See [RFC3986] for a > discussion of the security considerations relating to URIs. > > The CONCEPT and redefined RELATED-TO property have the same issues in > that values may be URIs. > > === END OLD === > > === NEW === > > 10. Security Considerations > > Applications using the LINK property need to be aware of the risks > entailed in using the URIs provided as values. See section 7 of > [RFC3986] for a discussion of the security considerations relating to > URIs. > > In particular note section 7.1 "Reliability and Consistency" of > [RFC3986] which points out the lack of a stability guarantee for > referenced resources. > > When the value is a REFERENCE type the targeted data is an XML > document or portion thereof. Consumers need to be aware of the > security issues related to XML processing - in particular those > related to XML entities. See [RFC4918] - Section 20.6. Additionally > note that the reference may be invalid or become so over time. > > The CONCEPT and redefined RELATED-TO property have the same issues in > that values may be URIs. > > === END NEW === > > > > > Thanks, > > > > Ben > > > > On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote: > >> On 10/26/21 14:49, Catherine Meadows via Datatracker wrote: > >>> Reviewer: Catherine Meadows > >>> Review result: Has Issues > >>> > >>> This draft describes increases the expressive and scope of relationships that > >>> can be defined in iCalendar. It updates the already existing RELATED-TO by > >>> allowing UID and URI as values and introduces a GAP parameter to specify the > >>> length of time between two events. It also introduces three new properties: > >>> CONCEPT (roughly, category), LINK (typed reference to external meta-data or > >>> related resources), and REFID(used to identify a key that identifies all > >>> components that use that REFID). The syntax of the relationships is given and > >>> intended use cases are described. > >>> > >>> The introduction of greater expressiveness does not by itself introduce > >>> security considerations, but the introduction of references to external sources > >>> does, specifically for URIs, which are allowed as arguments of the RELATED-TO, > >>> CONCEPT, and LINK properties. The authors of this document are aware of this, > >>> and refer the reader to [RFC3986] for more information. I agree that the > >>> security considerations related to use of URIs proposed in this draft are > >>> covered by this RFC. > >>> > >>> I wonder though, if the document shouldn’t concern a similar warning about the > >>> data type REFERENCE. This refers to an XML document or a portion of an XML > >>> document. Since XML can also be used as an attack vector, a mention in the > >>> Security Considerations Section would seem appropriate. > >> I agree with the sentiment. I thought it would be easy to find a > >> document with such a section - however the XML spec itself doesn't have > >> a security section. There is at least section 20.6 in RFC4918 (WebDAV) > >> which talks about external entities. Perhaps something like this: > >> > >> When the value is a REFERENCE type the targeted data is an XML document > >> or portion thereof. Consumers need to be aware of the security issues > >> related to XML processing - in particular those related to XML entities. > >> See RFC4918 - Section 20.6 > >> > >> > >> > >>> > >>> > >> _______________________________________________ > >> secdir mailing list > >> secdir@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/secdir > >> wiki:https://trac.ietf.org/trac/sec/wiki/SecDirReview -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
