Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05

Stephen Kent <> Mon, 22 July 2013 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E77221E80C4; Mon, 22 Jul 2013 08:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AuNsZpAwxtv0; Mon, 22 Jul 2013 08:11:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B6BB211E811E; Mon, 22 Jul 2013 08:11:24 -0700 (PDT)
Received: from ([]:44774 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1V1HlK-0007jN-Hd; Mon, 22 Jul 2013 11:10:59 -0400
Message-ID: <>
Date: Mon, 22 Jul 2013 11:10:58 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Philipp Kewisch <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030002080403000709060907"
Cc: secdir <>,, "" <>,, Barry Leiba <>, Pete Resnick <>
Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2013 15:11:44 -0000


Thanks for the edits.  They address my concerns.

On 7/21/13 3:02 PM, Philipp Kewisch wrote:
> On 7/17/13 10:15 PM, Stephen Kent wrote:
>> This document cites the Security Considerations section of original 
>> vCard RFC (noted above) as the primary content for its Security 
>> Considerations section. It asserts that no new security concerns 
>> arise with respect to _calendar data_, because this specification 
>> merely maps the original vCard data to a new format.However, it then 
>> cites the Security Considerations section of the JSON specification 
>> (RFC 4627) noting that there are additional security risks that arise 
>> from using JSON to represent vCard data! To me these two statements 
>> seem somewhat contradictory, but that can be addressed by refining 
>> the wording here.
>> More worrisome is the fact that this very brief section mentions only 
>> calendar data security. Does that mean that no other type of vCard 
>> use, when using JSON encoding, creates any new security concerns? 
>> This document is much broader in scope than just iCal data (the 
>> subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused 
>> comment seems out of place.
> Yes, this was a copy/paste fail from the jCal draft. I've corrected 
> both instances of "calendar" to "vCard".
> OLD:
>    For security considerations specific to calendar data, see Section 9
>    of [RFC6350].  Since this specification is a mapping from vCard, no
>    new security concerns are introduced related to calendar data.
> NEW:
>    For security considerations specific to vCard data, see Section 9 of
>    [RFC6350].  Since this specification is a mapping from vCard, no new
>    security concerns are introduced related to vCard data.
>> RFC 6350's Security Considerations section notes few concerns that 
>> are Vcard-specific; most of the comments in that section relate to 
>> the need to provide security for vCards when they are transported, 
>> e.g., via email. All of these concerns are equally applicable here, 
>> as indicated, without the calendar data comment.
> Taken care of by the previous change.
>> RFC 4627's security considerations section turns out to be an 
>> indirect reference to two paragraphs in the IANA Considerations 
>> section! (This seems silly and it's not clear why that document was 
>> published with such an obvious structural error, but ...). The 
>> security concern cited in 4627 is that JavaScript (JS) is a scripting 
>> language and thus JSON might be used to execute malicious JS. However 
>> JSON is intended to be a "safe" subset of JS, i.e., it should be able 
>> to be evaluated in JS without security concerns, if it is properly 
>> constrained.The text in 4627 provides two regular expressions that 
>> can be invoked to strip any characters that might cause security 
>> problems. I'd feel a lot more comfortable if this text were 
>> explicitly replicated in this I-D, and the I-D _mandated_ this 
>> processing step before passing the Jcard data to JS. (It might even 
>> make sense as a post processing step as part of the vCard to JCard 
>> processing described in Section 3.) The level of indirection 
>> currently used in the Security Considerations section, and the casual 
>> advisory nature of the original text might easily be overlooked by an 
>> implementer.
>> Finally, the notion of JSON as "safe" JS subset assumes that the 
>> parser processing the JSON does not have a security flaw. Such flaws 
>> have been identified, one as recently as February of this year. It 
>> might be good to note that this represents a new type of security 
>> concern that would not arise in a conventional vCard context.
> As most popular JavaScript implementations use JSON.parse() for 
> parsing JSON data, I don't see the need to put this into Section 3. 
> I've changed the text to include the regex and a little more 
> information from what you wrote via email, let me know what you think:
> OLD:
>    The use of JSON as a format does have security risks.  Section 7 of
>    [RFC4627] discusses these risks.
> NEW:
>    The use of JSON as a format does have security concerns.  Even though
>    JSON is considered a safe subset of JavaScript, this does not ensure
>    that the parser processing JSON does not have a security flaw. When
>    processing jCard data, this concern should be taken into account as
>    it doesn't arise with conventional vCard data.
>    As with JSON, when passing jCard data to JavaScript's eval()
>    function, certain precautions must be taken to ensure that no
>    security issues arise.  Specifically, all characters not enclosed in
>    strings MUST exclusively be in the set of characters that form JSON
>    tokens.  This can be quickly determined in JavaScript with two
>    regular expressions and calls to the test and replace methods.
>    var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
>           text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
>       eval('(' + text + ')');
>    See also Section 7 of [RFC4627] for security considerations of the
>    JSON format.