Subject: Re: [VCARDDAV] Signed vCards

From: Kevin Marks <[email-masked]>
Date: Mon, 1 Jul 2013 03:32:05 -0700

do email addresses (or acct: extension thereof per webfinger/fist to
accomodate email-like jabber addresses) and http addresses cover all
practical IDs?
A twitter handle is a URL: @kevinmarks is shorthand for
https://twitter.com/kevinmarks
A facebook ID is an email or a URL - https://facebook.com/kevinmarks is the
same as [email-masked]

The hCard practice is uid's are URLs

Is there a case I'm missing here?

On Sun, Jun 30, 2013 at 8:13 PM, DataPacRat <[email-masked]> wrote:

> On Sat, Jun 29, 2013 at 9:27 PM, DataPacRat <[email-masked]> wrote:
> > 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.
>
> After some initial fiddling around; something at least resembling the
> above seems to be a near-necessity, for the various uses I've been
> able to work with so far.
>
> The tricky part seems to be that, when taking one authenticated vCard
> and using that identity as an authentication authority itself, there
> isn't any firm rule about what string to use as the identifier for
> that authority. Given that some vCards have email addresses and some
> don't; some have UIDs; some have Twitter handles; etc; there doesn't
> seem to be any practical way to declare that one particular sort of
> field /has/ to be used as a canonical ID-string. So having a
> PREFERRED-ID field to have the option to declare what string is most
> useful to be used as such would make implementing a full-fledged
> authentication system a heckuvalot easier.
>
> And once the field exists at all, it seems that allowing it to list
> more than one field, presumably in descending order of preference,
> would allow for easier interoperability between vCard systems
> containing different subsets of identifying information. Eg, "The UID
> is the preferred ID-string; but if your particular system doesn't
> handle that, you could use the email address instead, or failing that,
> the nickname."
>
>
> As a practical example; the webfist protocol uses email addresses as
> canonical ID strings, which, with a bit of hash function trickery,
> allows for relatively easy lookups in the webfist ID database. Having
> even just a short list of potential ID-strings could allow, if nothing
> else, all of them to be hashed into a similar database, so that in the
> future, someone seeking to authenticate that identity can lookup
> whichever one of those strings they happen to have available to them.
>
>
> So unless someone has a better idea, I'm definitely adding this to the
> signed vCard proposal. (And since we seem to have passed the initial
> inquiry stage, I'm updating the subject line accordingly.)
>
>
> Thank you for your time,
> --
> DataPacRat
> "Half of knowledge is knowing the questions." -- The Cynic's Book of Wisdom
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: DataPacRat <[email-masked]>
Date: Mon, 1 Jul 2013 09:42:07 -0400

> Is there a case I'm missing here?

One case: Identifying a user of a Tor-based forum which allows people
to register nicknames-and-passwords, but doesn't publish individual
member-pages anywhere on its .onion site. There's an identity there,
but no standard IM or email address, or URL to point to.

Another case: Since the system uses Bayesian confidence levels, it's
possible for an authority to use that as the whole point of issuing
vCards for persons who it's only mildly sure about. Eg, using the
PHOTO field as the main identity, adding a FN or NICKNAME, and using a
confidence level of the equivalent of around 60% surety, to have the
vCard state "We /think/ this pic is of this guy, but we could easily
be wrong".

Another: An authority can issue vCards for people who have no (other)
digital presence at all. There's an old practice, now mostly gone by
the wayside, of competent authorities writing letters of introduction
to identify their bearers, which signed vCards could revive with a
modern cryptographic twist.

Another: vCards don't have to be about people at all; one could be
issued with GEO and NICKNAME announce, eg, that a feature at
43.1012,-79.237 has the informal name of "Unexpected Tunnel".

Another: Since the proposal is to add DATE as a parameter which can be
used by any property, that would open up using GEO with DATE to allow
full four-dimensional time-and-space locations. For example, with a
bit of programming jiggery-pokery, a vCard could be issued with data
exported from a GPS, to state "So-and-so was at location A at 09:30, B
at 09:31, C at 09:32, etc - and I'm so confident this was the case,
I'm signing the whole thing". There's no particular reason such a
vCard would be required to use an EMAIL or URL to identify the
thingummy being described in such a way.

... and I'm sure there's more, since I came up with those in just a
few minutes of thought; but they should suffice as inspirational
examples.

Thank you for your time,
--
DataPacRat
"And perhaps the horse will learn to sing."

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Jul 2013 16:01:40 +0200

Is the idea here to tie authority to a particular attribute set within a
vCard?  Your issue is what to use as a distinguished name in some way
that is at all verifiable.  Can you get a bit more specific about your
use case?  As you mentioned, this can get quite messy.  I'm also aware
that somewhere along the way you're probably going to have to
canonicalize the information because vCards don't maintain ordering...

---

From: DataPacRat <[email-masked]>
Date: Mon, 1 Jul 2013 10:20:34 -0400

On Mon, Jul 1, 2013 at 10:01 AM, Eliot Lear <[email-masked]> wrote:
> use case?  As you mentioned, this can get quite messy.

While playing with vCard as a container for time-and-space data is a
fun exercise, my primary use case is identity authentication over
otherwise anonymized networks such as Tor. While some forums thereon
could be referred to using the proposed acct: URI, using the forum's
.onion address and the user's account name, not all are so easy to
work with. (Eg, "I'm the person who programmed the software which made
the edit at 2010-11-12T12:34:56 to wiki page XYZ on site ABC.onion
(whose server lay in the house that Jack built).")

> I'm also aware

It may be possible to get away without that by using the order of the
fields listed in HASHED-FIELDS (or whatever it gets called) as the
'canonical' order for that particular signing. Short of that, or if a
HASHED-FIELDS field is missing, alphabetical order is probably the
most practical way to go, which would ruffle the fewest feathers.

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 01 Jul 2013 17:50:04 +0200

> (whose server lay in the house that Jack built).")

Anytime anyone suggests a new way to do something with crypto, the 
obligatory "why not use PGP?" needs to be answered.

So... Why not use PGP? :)

Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Jul 2013 09:54:04 -0600

On 7/1/13 9:50 AM, Simon Perreault wrote:
>> While playing with vCard as a container for time-and-space data
>> is a fun exercise, my primary use case is identity authentication
>> over otherwise anonymized networks such as Tor. While some forums
>> thereon could be referred to using the proposed acct: URI, using
>> the forum's .onion address and the user's account name, not all
>> are so easy to work with. (Eg, "I'm the person who programmed the
>> software which made the edit at 2010-11-12T12:34:56 to wiki page
>> XYZ on site ABC.onion (whose server lay in the house that Jack
>> built).")
> 

Or S/MIME or something that's been around for a while.

But PGP is fine (I say as I sign this message with my PGP key).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: DataPacRat <[email-masked]>
Date: Wed, 3 Jul 2013 23:56:36 -0400

On a somewhat related subject, I'm still new to the IETF, and still
going through various semi-relevant RFCs. If nobody minds my asking;
once the general back-and-forth on the idea seems done, and the
significant feedback has been fed... what would the most appropriate
next step be? Should I start writing up a preliminary draft all by
myself, or make some sort of official proposal to the working group,
or let someone else take the lead, or...?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Wed, 3 Jul 2013 23:59:33 -0400

> So... Why not use PGP? :)

I've just realized that I might have misinterpreted at least part of
what you were asking. From what I understand of the current vCard
format, it would be easy enough to add the lines before and after that
result from using PGP to sign the VCARD block. Basically, the same
thing I'd suggested with a VHASH block, but using PGP's specific
algorithms and format. Is that what you were referring to?

Thank you for your time,

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Jul 2013 14:56:20 +0200

Hi,

> or let someone else take the lead, or...?

First, I would like to refer you to the Tao of the IETF.  It gives a
pretty good feel for how we do things.  Beyond that, a draft is always
welcome.  I think it would be useful to explain in that draft why
neither an S/MIME nor a PGP encrypted/signed object would do the job.

http://www.ietf.org/tao.html

Eliot

---

From: DataPacRat <[email-masked]>
Date: Thu, 4 Jul 2013 13:36:51 -0400

> http://www.ietf.org/tao.html

Thank you kindly for the reference; it's now near the top of my to-read pile.

To offer a new answer your question, there's a now-classic essay,
"Falsehoods Programmers Believe About Names", available through
https://tinyurl.com/locusBadNames , which could be adapted quite
easily to "email addresses" or "PGP keys" or "chains of certificate
authority trust". Online identities are often much more complicated
than having a single email address in one's PGP key identity field,
and adding a surprisingly small number of items to the vCard format
can allow for vCards to cover a much more comprehensive range of them.

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Wed, 10 Jul 2013 20:39:36 -0400

I've been sorting through my notes, and come up with a possible change to
the signed vCard proposal, which seems significant enough to solicit
comment on before I proceed further.

What I see as the core of using signed vCards to improve identity
declarations, is the CONFIDENCE property. In the current design, it's
applied solely to the AUTHORITY field, to indicate how confident that
authority is that all of the info signed in the vCard is accurate, and
describes the individual/group/etc in question. Due to the nature of
confidence measurements, I've been getting ready to use negative numbers of
decibans, with short vCards, for revocations (eg, "I'm no longer at this
email address").

However, an alternate approach would be to have CONFIDENCE, like DATE, be
applicable to any field. This would allow a single signed vCard to contain
fields of different confidence levels ("I'm 80% sure this is his Twitter
account, and 60% sure this is his email address"). Combining it with DATE
allows for even easier descriptions of when which accounts are being used,
and which aren't. (As a practical example: announcing revocations of a PGP
public key, after misplacing the private one.) However, this does come at
the cost of a mild increase in complexity; and there may be further
ramifications or improvements worth discussing.

So: changing CONFIDENCE to be a generic modifier: good idea or bad idea?

-- 
Thank you for your time,
-- 
DataPacRat

---

From: DataPacRat <[email-masked]>
Date: Sun, 14 Jul 2013 00:28:47 -0400

After some thought, there does seem to be at least one use case where
having CONFIDENCE fields for any vCard property may be troublesome: when
the confidence level is below 50%, and when the software reading the card
isn't specifically design for vCards.

One of the handiest things about vCards is that no matter which version is
being used, it's fairly safe for a piece of reader software to simply
ignore any tags or fields that it doesn't understand. However, a signed
vCard written to revoke an association with an ID string, such as by using
a DATE field with a low CONFIDENCE field, could break this; as the card is
expressing the opposite of a piece of identity, but ignoring the unknown
fields could lead a piece of software to conclude the opposite.

I'm not sure that it's possible to easily resolve this issue, since dealing
with such complicated identities is the whole point of my proposal. As a
first thought - would it help to adjust the version number for signed
vCards, such as from "4.0" to "4.0s"?

-- 
Thank you for your time,
-- 
DataPacRat

---

From: DataPacRat <[email-masked]>
Date: Mon, 15 Jul 2013 13:00:51 -0400

On Sun, Jul 14, 2013 at 12:28 AM, DataPacRat <[email-masked]> wrote:
> After some thought, there does seem to be at least one use case where having
> CONFIDENCE fields for any vCard property may be troublesome: when the
> confidence level is below 50%, and when the software reading the card isn't
> specifically design for vCards.
>
> being used, it's fairly safe for a piece of reader software to simply ignore
> any tags or fields that it doesn't understand. However, a signed vCard
> written to revoke an association with an ID string, such as by using a DATE
> field with a low CONFIDENCE field, could break this; as the card is

In case anyone's interested, my current working draft reads:

A vCard which is compatible with the signed vCard extensions MAY add
an 's' to the version number.
A vCard which uses any of the signed vCard extensions SHOULD add an
's' to the version number.
A vCard which uses a negative number in the CONFIDENCE property (ie,
has a confidence of under 50%) MUST add an 's' to the version number.

Thank you for your time,

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Jul 2013 19:12:37 +0200

> has a confidence of under 50%) MUST add an 's' to the version number.

What's the purpose of the 's'?

Why isn't the mere presence of a property a sufficient indicator?

Simon

---

From: DataPacRat <[email-masked]>
Date: Mon, 15 Jul 2013 17:39:05 -0400

> Why isn't the mere presence of a property a sufficient indicator?

My reasoning is that a piece of software can claim to be vCard-4.0
compatible by interpreting the standard specification, and simply
dropping and ignoring any properties that it doesn't understand (such
as the BIRTHPLACE property introduced in RFC 6474). For the properties
I'm proposing for signed vCards, that behaviour will still lead to
acceptable results... with the exception of signed vCards used for
revocation, those with CONFIDENCEs of <50%. Adjusting the version
number for that particular case will allow such programs to still
claim full compatibility with the 4.0 spec, even if they misinterpret
revocation vCards.

Another option that comes to mind could be to roll up the new tags
from RFCs 6473 and 6474 along with the signed vCard tags into the base
spec, and call the whole thing vCard 4.1.

Thank you for your time,

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jul 2013 10:33:34 +0200

> claim full compatibility with the 4.0 spec, even if they misinterpret

That means you want to prevent UAs that don't understand your new
properties from reading those special revocation vCards, correct?

The reason being that those special revocation vCards contain
information that is known to not be trustworthy, correct?

If so, why is it necessary that revocation vCards contain that
untrustworthy information?

Simon

---

From: DataPacRat <[email-masked]>
Date: Tue, 16 Jul 2013 10:10:08 -0400

> properties from reading those special revocation vCards, correct?

Assuming that 'UA' means something along the lines of 'user agent',
that seems close. There's no way to actually prevent a program from
reading a signed vCard, but changing the version number offers an easy
way to identify what's going wrong if they do.

> information that is known to not be trustworthy, correct?

Close enough.

> untrustworthy information?

Er, well, because it's rather difficult to say "I will no longer be
using email address [email-masked]" without including the text [email-masked]".

Here's a typical use case: A person has lost the USB flash-drive
containing their PGP secret key. So they have to generate a new one.
Unfortunately, the current standard for revoking a PGP key requires
generating a revocation certificate signed by that key's secret key...
which is infeasible in this scenario. While using a signed vCard to
announce the revocation isn't cryptographically secure (which is why
PGP/GnuPG didn't include such functionality), on a practical level,
it's possible to accumulate a number of public keys on PGP keyservers
with little indication of which are still active, which are
deprecated, and which were never issued by you in the first place. A
signed vCard may not be absolute proof, but it can be significant
evidence for which PGP keys to use and which to avoid.

For a concrete example of this use case, if you wanted to contact a
particular figure who's been mentioned in the news recently, with a
minimal chance of third-party intercepting it, then which of the keys
listed at http://pgp.mit.edu:11371/pks/lookup?search=snowden&op=index
should you pick? The one from 2009, or 2010, or last March, or one of
the more recently-published ones? The individual in question could
issue a signed vCard using the KEY property and himself as an
authority to give some indication; and people who know him could issue
near-identical signed vCards using themselves as the authority, to add
further evidence that the information is accurate.

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Wed, 17 Jul 2013 22:05:01 -0400

On Monday, 15 July 2013, DataPacRat wrote:

> <[email-masked] <javascript:;>> wrote:
> spec, and call the whole thing vCard 4.1
>

After a bit of thought, I'm going to suggest that the 4.1 approach isn't
the best. There's a significant difference between current standard vCards
and the signed vCard approach: a program which fully decodes the latter
needs a full set of cryptographic subroutines. There seems to be some
benefit in allowing for some vCard decoders that remain light and nimble,
while also providing the option for cryptographically authenticated ones.

So, unless there's feedback otherwise, I think that I'll have the draft
stick with adding an 's' to the version number for crypto-based vCards.

-- 
Thank you for your time,
-- 
DataPacRat