SECDIR review of
        draft-ietf-jcardcal-jcard-05




 




I reviewed this document as part of the
        security
        directorate's ongoing effort to review all IETF documents being
        processed by
        the IESG.

  

These comments
        were written
        primarily for the benefit of the security area directors.

  

Document editors and WG
        chairs should treat
        these comments just like any other last call comments.




 




This
        document describes a JSON format for vCard data, as previously
        defined in RFC
        6350. 




 




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.




 




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.




 




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.