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
