Reviewer: Phillip Hallam-Baker Review result: Serious Issues This draft does not contain a substantive security considerations which is arguably OK insofar as it links to the main spec which does have one and addresses the issue of serialization/deserialization security adequately. The small problem is that the draft does not consider the question of generation loss when converting between formats repeatedly. Consider the case that Alice sends Bob's contact to Carol. We can imagine conversions from vCard to JSON and back and the result is not necessarily what was started with and in some cases this matters. The possibility that Carol ends up communicating with someone who is not Bob is always a consideration. The bigger problem is that neither draft considers the security role that contact exchanges play when the contacts contain public keys. And what is the value of a contact that does not? Very little in my view. The contacts catalogs/address book is in my view the overlooked control point for interoperable, end-to-end secure messaging. If Alice has Bob's contact information in her personal contacts catalog, she can communicate with him without the need to rely on any other party. If not, she is reliant on a third party which is always trustED but not always trustWORTHY. All I need to establish interoperable messaging with Alice is the ability to click on a link in my contacts catalog and have it spawn off the messaging application Alice uses whether that is Zoom, Signal, Skype or CALEA-Express. The drafts don't consider this dimension at all which is a problem because exchange of contact information carries an implicit authentication even if there is no cryptographic integrity or authentication means. If Alice gives Bob her contact information, Bob is going to assume it trustworthy and authentic regardless of whether the channel itself offers any security controls. One of the best arguments for creating a JSON format for contact information in my view is precisely so that they can be wrapped in a JSON-friendly envelop format such as JOSE or DARE. This is exactly what I plan to do, rather than specify my own contact information format, I simply define a contact assertion whose payload is a JSON contact. So if Alice and Bob meet in person, they can effect an authenticated contact exchange with a 2^240 work factor by means of a QR code exchange. Obviously, the security considerations section for THAT exchange needs to be considerably more comprehensive and consider the validation of credentials, yadda yadda because it is asserting a high assurance exchange. But even where no authentication etc. is considered, there must be a disclaimer to state that these questions have not been considered. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
