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

[Stephen Kent <[e-mail]>]

Pjillip,

I like the tone of the new text, but it does need some edits to be
more readable:
> NEW:
>    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 semantics (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 introduce a 
> vulnerability
>    which doesn't arise with conventional vCard data.
>
>    With this in mind, any parser used with jCard data should be 
> security-aware.  For example, the use of
>    JavaScript's eval() function is allowed only after applying the regular
>    expression in Section 6 of [RFC4627].  A native parser with full
>    awareness of the JSON format is preferred.
>
>    In addition, it is expected that this new format will result in vCard
>    data being more widely disseminated (e.g., used in web
>    applications rather than just dedicated "contact managers").
>
>    In all cases, application developers MUST 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.
>
>