Last Call Review of draft-ietf-calext-jscontact-vcard-06
review-ietf-calext-jscontact-vcard-06-secdir-lc-hallam-baker-2023-03-26-00

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.