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

Philipp Kewisch <> Sun, 21 July 2013 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97D4D21F9E3B; Sun, 21 Jul 2013 12:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-JlIoxrdOJn; Sun, 21 Jul 2013 12:02:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c01::236]) by (Postfix) with ESMTP id DD56121F9CA9; Sun, 21 Jul 2013 12:02:27 -0700 (PDT)
Received: by with SMTP id d10so3425711eaj.13 for <multiple recipients>; Sun, 21 Jul 2013 12:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=0oWZ+OM2eqoIW4QxYMxwmqjz4k08xmYeF13+10nPAuo=; b=0UHpa/fbZuxmBOC9bmRSbJ5tY+7c8Hk4YTwzMZ0mG5gpfTpz6/fZB+tZs1jscwPRkr 7GlT1wzlLwlf11c8tC9cx9n0oUvK5yPRtj8bNy9Fgiu3yqQrNu6sjbM/I6uPsIAC/IjU KJs2/dxIzI0nRTCJ/RlB7//14qfKQASUcD0Av32RTxhDvA8wU+xzDsotuj98LXMuuFBn W5hvR2tOY16+BCsOHWHw+HWi2Bk3E2YeKIMMph2f124O1G64yq0xPsNBbqlxo14MdQYI rna/RsaJlIBjaQ3ch/QK5C7mycAIXs/H553LfNgBLeC9hdAw7gpJN7fLnFTvvie/EK/Q P7Ew==
X-Received: by with SMTP id p7mr24517918eef.16.1374433345863; Sun, 21 Jul 2013 12:02:25 -0700 (PDT)
Received: from ( []) by with ESMTPSA id ci50sm44927901eeb.12.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 12:02:25 -0700 (PDT)
Message-ID: <>
Date: Sun, 21 Jul 2013 21:02:24 +0200
From: Philipp Kewisch <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0
MIME-Version: 1.0
To: Stephen Kent <>, secdir <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090209010507030803070906"
X-Mailman-Approved-At: Sun, 21 Jul 2013 12:09:53 -0700
Cc:, 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: Sun, 21 Jul 2013 19:02:31 -0000

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".

    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.

    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:

    The use of JSON as a format does have security risks.  Section 7 of
    [RFC4627] discusses these risks.

    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.