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 20:31 UTC

Date: Thu, 18 Jul 2013 16:30:48 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <5D94A744E2BD96079A9E529A@caldav.corp.apple.com>
In-Reply-To: <51E82F93.5080109@cs.tcd.ie>
References: <20130718003748.2045.65683.idtracker@ietfa.amsl.com> <533259592EFE6C6AB8016877@caldav.corp.apple.com> <51E82F93.5080109@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2652"
Cc: draft-ietf-jcardcal-jcard@tools.ietf.org, jcardcal@ietf.org, jcardcal-chairs@tools.ietf.org, The IESG <iesg@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 18, 2013 at 7:10:27 PM +0100 Stephen Farrell 
<stephen.farrell@cs.tcd.ie> wrote:

> Say some s/w knows that the vCard foobar attribute is sensitive
> because the person who wrote the code has read the relevant RFC
> and it said to be careful.
>
> Now the vCard -> jCard translation code is generic and so the
> person who wrote that code doesn't know that foobar is sensitive.
>
> Isn't there now a new danger that the foobar JSON object/array
> might go astray since nobody's written s/w having read the RFC
> that says foobar is sensitive?

That is not a NEW danger - it could just as well happen with vCard data 
sent as text or XML! In all of those cases it is up to the application 
developer to understand the semantics and requirements of each 
property/parameter they deal with. There are already cases of 
vCard/iCalendar libraries or apps that fail to parse or roundtrip X- 
properties or parameters.

> I'm not sure what'd be right to say about that, but I'm not
> convinced that just saying the above (that translating doesn't
> "impose or remove and security considerations") is sufficient.
>
> And I can imagine that the jCard version of stuff might get to
> unexpected places, so I think this could be a real issue.

Again - any format of vCard can go to unexpected places and be mistreated. 
It has always been a requirement of the app developers to understand the 
semantics of the properties and parameters. That point can be re-iterated 
if you want. Here is my proposal for a total replacement of the current 
Security Considerations:

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

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