On 10/20/11 3:00 AM, Stephen Hanna wrote: > I have 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 defines a new value for the vCard kind property: > application. This value is to be used for vCards that represent > software applications. > > The Security Considerations section of this document states: > > Use of vCards to represent software applications is not envisioned to > introduce security considerations beyond those specified for vCards > in general as described in [VCARD]. > > However, the Security Considerations section of [VCARD] doesn't > seem adequate to the task. It merely points out that vCards don't > have any security protections and therefore SHOULD be transported > over a secure mechanism such as S/MIME or PGP if security is a > concern. This advice may be adequate if the vCard is only used > to transmit contact information for a person but it's generally > not adequate when the vCard contains information about a software > application. For example, this draft suggests that the KEY property > can be used to convey a public key associated with an application. > What a weak way to convey a public key! Will the recipient be able > to determine whether the key is accurate? How might the key be > revoked if necessary? No provisions are made for this. Other vCard > properties such as URL may cause problems if malicious. > > Without proper security protections, the application vCard kind > seems like a great tool for phishing and social engineering. > Attackers can forge an email apparently from a trusted party, > including an application vCard and instructions to click on it > to see something cool. A naive email client may easily decide > that clicking on an application vCard should run the application > referenced in the vCard or visit the URL in the vCard or whatever. > > I suggest that the Security Considerations section of the draft > be updated to include specific warnings that the contents of an > application vCard should be considered untrustworthy and dangerous > unless they have been securely delivered from a trustworthy source. > Even then, there's a real possibility that the source may have > been compromised before the vCard was sent. So information > obtained from vCards should not be regarded as ipso facto > trustworthy. Software should not act on information contained > in a vCard unless there's a strong reason to believe it's > accurate. And the KEY property SHOULD NOT be used for an > application. Instead, more robust techniques for managing > software public keys should be used. That all seems reasonable, and in general the deployment I have seen enables an entity to obtain the vCard from the application itself (e.g., in XMPP a server can advertise its own vCard, so it is the canonical source of information about itself, and that information can be obtained over a TLS-protected channel). However, I think the same concerns you raise apply to vCards in general and really belong in the core vCard specification (RFC 6350 or its replacement) -- for example, an attacker could append someone else's vCard to an email message directed to me, and if I (or my email client) blindly accepts the vCard then I could accept the vCard information (including URLs, KEYs, etc.), thus leading me to be misdirected (phishing), to use the wrong KEY when interacting with someone, etc. What in your concern is *specific* to vCards containing a KIND value of "application"? Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf