Subject: Re: [VCARDDAV] Initial inquiry into vCard extension

From: DataPacRat <[email-masked]>
Date: Fri, 28 Jun 2013 10:57:12 -0400

On Fri, Jun 28, 2013 at 9:36 AM, Skip Levens <[email-masked]> wrote:
> I for one am curious about putting data (what was valid when) IN  the vCard vs some managing framework?
>
> All sounds very interesting...

If it works better, then it could be possible to move the VHASH block
to some other form; and to have the AUTHORITY and CONFIDENCE names in
the VHASH block rather than VCARD. However, that would still leave
describing which fields are covered by which time periods, which would
be tricky to do from outside the vCard itself - eg, if there are
multiple telephone numbers, then how would you know which X-TEL-DATE
(or equivalent) goes with which TEL entry?

I'm not sure that moving AUTHORITY and CONFIDENCE out of VCARD /would/
be best. If they're outside, then they wouldn't be authenticated by
the cryptographic hash; and if that's the case, then it would be easy
enough for a malicious vCard writer to take an existing vCard, write
in a false CONFIDENCE number, and thereby spoof the whole Bayesian
analysis, claiming either a higher or lower level of confidence in the
vCard's data than the asserting authority really has in it.

As for moving the VHASH block away from VCARD, possibly out of the
vCard altogether, it may help for me to describe one of my sample use
cases. (I have other use-cases, but this one is most relevant here.)

Two entities connect their chat clients over the Tor network. So far,
neither of them knows who the other is; and in order to maximize
privacy and security, at least one of them claims no data from the
chat will be stored (or at least, stored in unencrypted form). A
wishes to assert to B that A is the same entity who B exchanged
messages with on a Tor-based forum. A sends B a vCard containing the
forum-post's pseudonym, A's current chat-pseudonym, and signed with
the forum-poster's public key. Fortunately, B has software which can
take such a vCard, and verify the hash and which key it is signed
with.

The more closely the authentication hash is attached to the vCard,
then the fewer hoops that have to be jumped through, and the easier
the whole process would be. Ideally, it can be made so easy as to
become part of the automated background infrastructure, requiring as
little attention from the user as is currently needed to use HTTPS
instead of HTTP.

Thank you for your time,
--
DataPacRat
"No man spreads a lie with so good grace as he that believes it." --
John Arbuthnot

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 28 Jun 2013 11:24:22 -0400

Hi DataPacRat,

> vCard's data than the asserting authority really has in it.

The problem with hashing is that there is currently no defined form for a 
"canonical" vCard. This is important because vCards are often changed when 
stored - those changes typically being only syntactic changes (e.g. 
re-ordering or properties, changing lowercase names to uppercase), but in 
some cases can involve actual additions, removals or changes to existing 
properties (e.g., some server strip out inline PHOTOs and store them 
separately, or a SOURCE property might be added to indicate where it 
originally came from). All of those would of course invalidate a hash of 
the original vCard data. Remember, many systems don't even store the vCard 
data itself, instead preferring to parse it out into their own schema and 
then reconstitute the vCard when exporting.

Now, the syntactic changes could we worked around by defining a canonical 
form, possible rules would be: uppercase all vCard property/parameter/token 
names, alphabetize order of properties and parameters, etc.

Another approach might be to do what DKIM does for email: namely add a HASH 
property that lists the set of properties that were actually signed - or go 
even further and embed the originally signed vCard data as part of the hash 
property itself.

All of the above is ugly and almost certainly unreliable. What might be 
better is something more akin to what Skip suggested. e.g., make the 
AUTHORITY property actually point to the authoritative vCard data - e.g. it 
could be an https URI. Then clients that want to verify whether the vCard 
data they have is valid would have to go get the authoritative data in some 
secure manner (verifying SSL certs, hashs etc) and then do their own 
comparison of that with the current data. Clients can then do their own 
comparisons/canonicalizations as needed and account for known "mismatches" 
such as the possibility of PHOTO stripping etc.

> take such a vCard, and verify the hash and which key it is signed

I really don't think this should be done with vCards as the cryptographic 
content in this exchange (you really should get security experts to review 
what you are trying to do rather than vCard experts). Instead think about 
using real certificates to do this. Now, maybe it might be worthwhile 
defining an x509 extension attribute for an embedded vCard, so more 
detailed contact information could be embedded in a public key - not sure 
if something like that already exists, but it might be useful.

-- 
Cyrus Daboo

---

From: DataPacRat <[email-masked]>
Date: Fri, 28 Jun 2013 15:03:48 -0400

> originally came from). All of those would of course invalidate a hash of the
> original vCard data. Remember, many systems don't even store the vCard data
> itself, instead preferring to parse it out into their own schema and then
> reconstitute the vCard when exporting.

This is indeed an issue - basically the same one that results from
transforming a vCard into a jCard or hCard. Given the variety of
software that does different things to vCards, I'm not entirely sure
that there can be a full solution to this; but any solution which
expands the range of situations for which a vCard's data can remain
authenticated is to the good.

> names, alphabetize order of properties and parameters, etc.

This seems reasonable enough, and easy to accomplish, at least for an
"authenticated vCard" extension to the basic vCard spec. It may also
be enough to allow for straight transformations of vCards, such as
into jCards, to be reversed back into a vCard for a hash to be
compared to.

> even further and embed the originally signed vCard data as part of the hash

The latter feels... a tad wince-inducing. It's easy enough to do -
instead of merely signing the original vCard with one's private key,
just encrypt the whole thing and publish it. Either way, using the
authenticator's public key will reveal that that private key was used.
But it would increase the size of the authentication block
considerably. Perhaps it could be included as an option, for
authenticators who want to be absolutely sure that the original
vCard's data survives through any transformation the vCard itself is
run through.

The former option definitely catches my interest. In an earlier
attempt at solving this problem, I tried to have two categories of
data: fields which were asserted by the authority with the described
level of reliability, and fields that were included as mere
unauthenticated commentary. Eg, to have the assertion that
"[email-masked] asserts with 80 decibans confidence that
[email-masked] and [email-masked] are the same
person; also, without any particular confidence, there's an associated
website at www.datapacrat.com". Regaining that draft's functionality
wouldn't be a bad thing.

As an initial thought: perhaps the VHASH block can contain, at the
start, an optional name-field which lists which of the three
authentication described so far methods is in use (signature of full
vCard, encryption of full vCard, signature of particular vCard
fields); and, if that field isn't there, then the VHASH is assumed to
be a particular one.

> such as the possibility of PHOTO stripping etc.

While not necessarily a bad idea, this approach goes against the grain
of one of my goals: to avoid, as much as possible, any reliance on
third-party references (outside of whatever authentication data either
communicating party has already cached locally). I would like this
system to work when it's two computers connected through a classic
dial-up modem on POTS, neither of which has any internet connection at
all for the duration.

> defining an x509 extension attribute for an embedded vCard, so more detailed
> contact information could be embedded in a public key - not sure if
> something like that already exists, but it might be useful.

The inspiration that initially sparked this project was when a few
Certificate Authorities were found to have issued some bogus
certificates, and some discussion of the brittleness of the CA system.
The approach I'm working on is, essentially, to allow anybody and
their grandmother to be able to act as ad-hoc CAs; replacing the
necessity of having absolute reliance in every major CA with Bayesian
analysis of any particular ad-hoc authority's trustworthiness. vCards
already contain about 95% of what such a system would require; and the
extensions to the vCard format which would allow for this don't seem
to interfere with any existing vCard functionality, and said
extensions offer an interesting selection of potential additional uses
as well.

That said, I welcome any and all constructive criticism. If you know
of any particular security experts who would be willing to be
contacted about this, or any relevant WGs (perhaps pkix?) or mailing
lists, I would be more than happy to get in touch with them.

Thank you for your time,
--
DataPacRat
"A little learning is not a dangerous thing to one who does not
mistake it for a great deal." -- William A White

---

From: DataPacRat <[email-masked]>
Date: Fri, 28 Jun 2013 17:01:42 -0400

> property that lists the set of properties that were actually signed

Thinking more about Cyrus's suggestion; it could be use to create a couple
of tags within the VCARD block itself, without requiring a separate VHASH
block at all. In the short term, X-HASH-LIST and X-HASH tags could solve
/enough/ of the problem I'm working on to allow some initial
experimentation of 'signed vCards' in software.

-- 
Thank you for your time,
-- 
DataPacRat

---

From: DataPacRat <[email-masked]>
Date: Sat, 29 Jun 2013 14:20:41 -0400

On Sat, Jun 29, 2013 at 12:11 PM, Skip Levens <[email-masked]> wrote:
> Seems like a good approach

Let me see if I can pull together the full collection of X-things for
a preliminary version of "signed vCards":

* Property: X-AUTHORITY

Value: A text field describing the entity issuing the vCard, or who
makes the claim that the data within it is accurate. Preferably, a
field used as part of another vCard, allowing chains of one vCard
describing the authority, which signs a vCard allowing that entity to
sign others, etc. Eg, an email address, domain name, social media
profile, UID, IM address, etc.

* Property: X-CONFIDENCE

Value: An integer or float, describing the Bayesian confidence the
X-AUTHORITY has that the data is accurate, measured in decibans.

* Set of properties: X-abcd-DATE

Values: An ISO 8601 date, time, date-time, or period, for the property
for which the "abcd" field is being described. Eg, if an email address
is being described for the year 2012, then the corresponding
X-EMAIL-DATE could have the value 2012-01-01/P1Y. (In case of multiple
properties of the same type, the X-abcd-DATE should immediately follow
the property it refers to, and should contain the same properties such
as ALTID, to ensure it remains associated with the correct property
even during transformations into other formats, such as hCard or
jCard.)

* Property: X-HASH-LIST

Value: A list of properties for which the cryptographic authentication
is being asserted. If multiple properties of the same type are in the
vCard, but not all of them are being signed, then enough of the
parameters (eg, ALTID) should be included to differentiate which are
part of the hash.

* Property: X-HASH

Value: An ASCII-armored hash, containing a cryptographic signature of
a text stream consisting of the properties and values listed in
X-HASH-LIST. Presumably, it is to be compared to the X-AUTHORITY's
public key, preferably asserted in a previous vCard with the KEY
property. (If no X-HASH-LIST property is present, then it should be
assumed that every property and value, save for X-HASH itself, are
included.)

Does that sound like a decent basis to proceed on to hash out the
infrastructure elsegroup, while discussion continues here about,
possibly, working out an Internet Draft/RFC with permanent versions of
these properties (or possibly swapping out the X-abcd-DATE property
for a DATE parameter, etc)? (After all, if there can be an RFC just to
assert the birth-place, death-day, and death-place properties, then
surely being able to add signatures to a vCard offers at least as much
utility...)

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Jun 2013 14:36:13 -0400

If you're going to propose something in this direction, I suggest:
- getting rid of the "X-" stuff.  Just use "AUTHORITY", and whatever,
- making CONFIDENCE a parameter on the AUTHORITY property, rather than
having it as a separate property, as it specifically modifies AUTHORITY and
has no meaning on its own, and
- making "abcd-DATE" into some sort of parameter on applicable properties.

What you suggest below still has issues with canonical values as input to
the hash.  You'll also need to build in hash algorithm agility, at least.

Barry

On Saturday, June 29, 2013, DataPacRat wrote:

> On Sat, Jun 29, 2013 at 12:11 PM, Skip Levens <[email-masked]<javascript:;>>
> wrote:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: DataPacRat <[email-masked]>
Date: Sat, 29 Jun 2013 14:51:46 -0400

> - getting rid of the "X-" stuff.  Just use "AUTHORITY", and whatever,

Agreed. The X- stuff is merely to allow immediate experimentation
elsegroup, without having gone through the RFC standardization process
first.

> has no meaning on its own, and

I can live with that.

> - making "abcd-DATE" into some sort of parameter on applicable properties.

I can live with that, as well.

> the hash.

This is what I initially described as "giving me fits", before I came
up with a VHASH block outside the VCARD block. It's where I expect I'm
likeliest to make a significant error, and could use the greatest
amount of feedback.

> You'll also need to build in hash algorithm agility, at least.

I'm hoping to draw heavily on vCard's existing KEY property, and
generally allow the HASH property to inherit the algorithm from the
appropriate authority's vCard's KEY reference. If that causes too much
headache, then another option may be to add a HASHKEY property, or
possibly a HASHKEY parameter to HASH, to explicitly refer to which KEY
is being used.

Thank you for your time,
--
DataPacRat
"What you don't know will kill you." -- The Cynic's Book of Wisdom

---

From: DataPacRat <[email-masked]>
Date: Sat, 29 Jun 2013 21:27:01 -0400

As a related thought; would it be sufficiently useful to add a tag to state
which of the other fields in that vCard is to be preferred for sorting and
identification purposes? For example, webfinger and webfist use an email
address as the unique identification string; Apple seems to use UID; and
I'm trying to work with vCards that have little more than a Twitter handle.

As a minor variation of the above, perhaps instead of a single canonical ID
string, a list in preferential order, to allow for better interoperability
between systems requiring different sorts of ID strings.

-- 
Thank you for your time,
-- 
DataPacRat