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

Philipp Kewisch <> Sun, 21 July 2013 21:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0B7C21F9D13 for <>; Sun, 21 Jul 2013 14:01:35 -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 qsZphz-s0FcI for <>; Sun, 21 Jul 2013 14:01:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c01::235]) by (Postfix) with ESMTP id 67CD521F9CE7 for <>; Sun, 21 Jul 2013 14:01:32 -0700 (PDT)
Received: by with SMTP id a15so3483319eae.12 for <>; Sun, 21 Jul 2013 14:01:31 -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=Z3ePPG+s5mJsBM382DF7jY/oGU6S8tjHHki/yUgMvZM=; b=V/w0LMVnk7RDh/iSXDy3tNxOQBTqdA2VrKf+9cBmZGntyLCPTsarv4FWf6qLxIQN9S bCpaUAjG9QIVv6hgutb9Ncb1wsqFCO3Nc/Yu05ERba3MYD8BYOGLf6qfOgOXaSGV+uPR fYMRdwcXnqqjArIfWkme+elRvrad+YRVkNlqpZoSBuXNFbeJxGHcvKAkPHU/sncuJsKr gaz6E2GayQHsurFXmY+kNVqz7oajmWfuIyH0PWXk1doPmTkAw5eZhi2AS0/s3Ly43Jjr X9ODHMUgbCW426ygdyGV0E4tOOvChw3/Bqemxw3cmhNK3kc8DnsqZA1btbRt+7rCyNUb YX+Q==
X-Received: by with SMTP id o45mr24949837eea.9.1374440491511; Sun, 21 Jul 2013 14:01:31 -0700 (PDT)
Received: from ( []) by with ESMTPSA id c3sm45736286eev.3.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 14:01:31 -0700 (PDT)
Message-ID: <>
Date: Sun, 21 Jul 2013 23:01:29 +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="------------080003000905010709010709"
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 21:01:36 -0000

On 7/17/13 10:15 PM, Stephen Kent wrote:
> 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.
Sorry, I would like to again modify the security considerations in 
reaction to Stephen Farell's DISCUSS/COMMENT and the discussion around 
it. Please ignore my previous reply to the SECDIR review. Here are the 
some of the discussion links for reference:
(one more message by me from a few minutes ago, no link on the archive yet)

Proposed changes, replacing the whole security considerations section:

    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.

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

    This specification defines how vCard data can be "translated" between
    two different data formats - the original text format and JSON - with
    a one-to-one mapping to ensure all the semantic data in one format
    (properties, parameters and values) are preserved in the other. It
    does not change the semantic meaning of the underlying data itself,
    or impose or remove any security considerations that apply to the
    underlying data.

    The use of JSON as a format does have its own inherent security risks
    as discussed in Section 7 of [RFC4627].  Even though JSON is
    considered a safe subset of JavaScript, it should be kept in mind
    that a flaw in the parser processing JSON could still impose a threat
    which doesn't arise with conventional vCard data.

    With this in mind, a parser for JSON data should be used for jCard
    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.

    In addition, it is expected that this new format will result in vCard
    data being more widely disseminated (e.g., with use in web
    applications rather than just dedicated "contact managers").

    In all cases, application developers have to conform to the semantics
    of the vCard data as defined by [RFC6350] and associated extensions,
    and all of the security considerations described in Section 9 of
    [RFC6350], or any associated extensions, are applicable.