Re: [Jcardcal] Stephen Farrell's Discuss on draft-ietf-jcardcal-jcard-05: (with DISCUSS and COMMENT)

Cyrus Daboo <cyrus@daboo.name> Thu, 18 July 2013 17:54 UTC

Date: Thu, 18 Jul 2013 13:54:34 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Message-ID: <533259592EFE6C6AB8016877@caldav.corp.apple.com>
In-Reply-To: <20130718003748.2045.65683.idtracker@ietfa.amsl.com>
References: <20130718003748.2045.65683.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2132"
Cc: draft-ietf-jcardcal-jcard@tools.ietf.org, jcardcal-chairs@tools.ietf.org, jcardcal@ietf.org
Subject: Re: [Jcardcal] Stephen Farrell's Discuss on draft-ietf-jcardcal-jcard-05: (with DISCUSS and COMMENT)
Precedence: list

Hi Stephen,

--On July 17, 2013 at 5:37:48 PM -0700 Stephen Farrell 
<stephen.farrell@cs.tcd.ie> wrote:

> vCards can be used to represent unexpected stuff that
> might have security issues, e.g. see RFC 6869.
> Aren't you missing a security consideration here
> along the lines of saying that a vCard->jCard
> translator that knows the generic syntax but does not
> know the sensitivity associated with various vCard
> things is very very liable to get something wrong
> leading to unexpectd exposures? I'm not sure what
> text might work for that, nor am I sure if we can
> really ensure that a vCard->jCard convertor (or
> vice-versa) will really understand the security
> issues with the translations they are doing.

I am weighing in on this because it speaks to the original design goals for 
all the vCard/iCalendar alternate data formats (XML and JSON).

These alternative formats have been designed purely as alternative 
"syntaxes" for the original data formats. They are not intended to have any 
impact on the semantics of the actual data itself. Thus these specs are 
primarily concerned with doing the translation between the data formats, 
and that in itself does not introduce security issues, nor should it - of 
course with the proviso that the "rules" defined int he spec are correctly 
followed.

To address this point perhaps the following replacement for the first 
paragraph in Security Considerations would work (note this tries to fix 
some issues from the SecDir review too):

    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. As a result, all of the security considerations that
    relate to the underlying vCard data, as described in Section 9 of
    [RFC6350], are applicable here.

-- 
Cyrus Daboo

[Jcardcal] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Stephen Farrell
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Philipp Kewisch
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo