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

[Stephen Kent <[e-mail]>]

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.