Re: [secdir] secdir review of draft-ietf-jcardcal-jcal-09
Philipp Kewisch <kewisch@gmail.com> Thu, 20 March 2014 22:58 UTC
Return-Path: <kewisch@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215971A0930; Thu, 20 Mar 2014 15:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-8TEYA98XwL; Thu, 20 Mar 2014 15:58:14 -0700 (PDT)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 84CFA1A0920; Thu, 20 Mar 2014 15:58:13 -0700 (PDT)
Received: by mail-bk0-f45.google.com with SMTP id na10so119171bkb.32 for <multiple recipients>; Thu, 20 Mar 2014 15:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=jeaOCeUwzKJjTSdvFrsVYMZa2IhKbr05893N5xV7PRw=; b=0Y58dcJ4v2wyzVTmL+VlsXrEcDqVAbtwt4KNtXPHPzAIhRFWdx6vgFTVJmN0DgtKOC O0IjLsLY9pyk2R6KsXleImoyUP1bOhO39Ci3fw2QmFMhlFLzOAb4r9OJ62/0yCY+Pkto G6MDVM6NXtTEUOSn+cwg/wNDjaDzs6va64ByqMRYc2D1QnDHCEMbGudSMa37MrL0OsH6 erWTK6eusOH/QxyYlRltWKQJw574f8+RDZB/OT0S7JeRsagXAqqEwFIkviCFt1Pjb4NE HsZvNDAEoK/V3kYtO9cS2uc3+OwpK22FP9kfTy+N4CRArbhCw8AiJ3j8Hrt3FBg8Tcge +pfg==
X-Received: by 10.204.81.14 with SMTP id v14mr24662970bkk.3.1395356283871; Thu, 20 Mar 2014 15:58:03 -0700 (PDT)
Received: from [192.168.2.104] (p5DC1549E.dip0.t-ipconnect.de. [93.193.84.158]) by mx.google.com with ESMTPSA id c15sm3417762bky.13.2014.03.20.15.58.02 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Mar 2014 15:58:03 -0700 (PDT)
Message-ID: <532B727A.9060500@gmail.com>
Date: Thu, 20 Mar 2014 23:58:02 +0100
From: Philipp Kewisch <kewisch@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-jcardcal-jcal.all@tools.ietf.org" <draft-ietf-jcardcal-jcal.all@tools.ietf.org>
References: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com>
In-Reply-To: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com>
Content-Type: multipart/alternative; boundary="------------000000020609080709090205"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/p7cPdKY4ElMQ9OH5ulMmXvww6q0
Subject: Re: [secdir] secdir review of draft-ietf-jcardcal-jcal-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 22:58:16 -0000
Hi Klaas, thank you for your corrections. Here is my feedback: > - Paragraph 3 (converting from iCal to jCal): > > The text looks very much like production rules, why not give ABNF? (Ah wait, now that I have read the full document I see that that appears in Appendix B, I think you should at least point to Appendix B here) The ABNF is considered informative, I was told for jCard that not too much weight should be put into it. Nevertheless, I am happy to mention it if you like. How is this for the introduction to section 3? OLD This section describes how iCalendar data is converted to jCal using a simple mapping between the iCalendar data model and JSON elements. NEW This section describes how iCalendar data is converted to jCal using a simple mapping between the iCalendar data model and JSON elements. Aside from the formal description in this section, an informative ABNF is specified in Appendix B. END > - Paragraph 3.4 and onwards > > It is unclear to me when you write for example "Each individual iCalendar property is represented in jCal by …" whether you really mean to write: "Each individual iCalendar property MUST be represented in jCal by…." > I assume you want to be normative in specifying the format? Thanks, I've changed it (almost) as you suggested. OLD Each individual iCalendar property is represented in jCal by an array with three fixed elements, followed by one or more additional elements, depending on if the property is a multi-value property as described in Section 3.1.2 of [RFC5545]. NEW In jCal, each individual iCalendar property MUST be represented by an array with three fixed elements, followed by one or more additional elements, depending on if the property is a multi-value property as described in Section 3.1.2 of [RFC5545]. END > - Paragraph 9.2 should RFC4627 not be a normative rather than informative reference? Yes, indeed. I've changed this and also updated references to rfc7159. While doing this I noticed that we referenced a regex that was in rfc4627 but no longer in rfc7159. I've made some changes: OLD With this in mind, a parser for JSON data should be used for jCal that is aware of the security implications. For example, the use of JavaScript's eval() function is only allowed using the regular expression in Section 6 of [RFC4627]. A native parser with full awareness of the JSON format should be preferred. NEW With this in mind, a parser for JSON data should be used for jCal that is aware of the security implications. For example, the use of JavaScript's eval() function is considered an unacceptable security risk, as described in [RFC7159], Section 12. A native parser with full awareness of the JSON format should be preferred. END Regards, Philipp
- [secdir] secdir review of draft-ietf-jcardcal-jca… Klaas Wierenga (kwiereng)
- Re: [secdir] secdir review of draft-ietf-jcardcal… Barry Leiba
- Re: [secdir] secdir review of draft-ietf-jcardcal… Philipp Kewisch
- Re: [secdir] secdir review of draft-ietf-jcardcal… Klaas Wierenga (kwiereng)