Re: [VCARDDAV] Signed vCards

DataPacRat <> Sun, 14 July 2013 04:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4D3D11E80CC for <>; Sat, 13 Jul 2013 21:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id alrtHzujKzdH for <>; Sat, 13 Jul 2013 21:28:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id A310921F8EC2 for <>; Sat, 13 Jul 2013 21:28:49 -0700 (PDT)
Received: by with SMTP id n57so9270524wev.0 for <>; Sat, 13 Jul 2013 21:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kTEY60DvZgn5v1XWJSimw/BHET13uZ3I9j1WTkwjvX0=; b=dYDnznMG1OCAdK7IULq2YM/wrBT3fsNZYvlQm1vbkQ+21ThIbTzpmbEjXzbVIx6lad uRy2onngXTpqAe5WEVh2TzwJL+hjBKtQRxIdq1ioJpLoUsq5HXrv3fPKBDz1JZfzoMGn vD1Wi0RfAfFT8ZWbd7dcvYXSG1XxLSMbnmvA59whT//kfzOiQKSa90OnYbW1bfdDqUkt J/OsBCT3zWP9HyGwLc89r9TIKxwo+1c2+Ydx5l3jAj6iHTHlz9sWOdPVUpc6rXGPsH/6 Ml76cKHxBUohTf0303LXVBnX7AHuddg1f6eAazStv4fU7sXMyaaaUm9UvaLl0yg2qG+y QOMA==
MIME-Version: 1.0
X-Received: by with SMTP id wz4mr28244024wjc.28.1373776127590; Sat, 13 Jul 2013 21:28:47 -0700 (PDT)
Received: by with HTTP; Sat, 13 Jul 2013 21:28:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Sun, 14 Jul 2013 00:28:47 -0400
Message-ID: <>
From: DataPacRat <>
To: Eliot Lear <>
Content-Type: multipart/alternative; boundary="089e014940501608e104e1712e10"
Cc: "" <>
Subject: Re: [VCARDDAV] Signed vCards
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Jul 2013 04:28:50 -0000

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"?

On Wednesday, 10 July 2013, DataPacRat wrote:

> 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

Thank you for your time,