Re: [VCARDDAV] Signed vCards

DataPacRat <> Tue, 16 July 2013 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BA0E21E80A7 for <>; Tue, 16 Jul 2013 07:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, WEIRD_PORT=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zHdRyIw22Qeq for <>; Tue, 16 Jul 2013 07:10:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) by (Postfix) with ESMTP id E64F221E80A1 for <>; Tue, 16 Jul 2013 07:10:09 -0700 (PDT)
Received: by with SMTP id ey16so4180427wid.9 for <>; Tue, 16 Jul 2013 07:10:09 -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:content-transfer-encoding; bh=rURG/ze/rAYoAuNy97n5Os54G67oYUwoqoGKWsjo6xc=; b=HP2me3Jrddl3y1A0PNohZ/4ffjiJCcMba2H+VzN6Rt9QT4X3sdmWoqwdiXu3a8qO4X FooVe/Kp0dQKhPzzcR50c6ssqrb3AkBSu1O2L9KoQDiot4vVuSSRgk9gzDWDjJMIV+az 0UWvCZezzrs96e3De7xnamhkMeLSVfVdEjmMMLh7f8UFF/iWhadYOHNZXIRS0X2G7Tge c7NMBxhrvpMsV9jxXonJgg1SX+UrDOMWLl95Qlx1nycsyp3a6m1Gsxt1YUR08OH3OHUo 59pTTJxClT4divGhA1Iw9g1TMxVss1IN+ec51Um1pxyRQPR8IlKxcxREvPtui+RQ9jW9 JCVQ==
MIME-Version: 1.0
X-Received: by with SMTP id op3mr1404675wjc.52.1373983808992; Tue, 16 Jul 2013 07:10:08 -0700 (PDT)
Received: by with HTTP; Tue, 16 Jul 2013 07:10:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 16 Jul 2013 10:10:08 -0400
Message-ID: <>
From: DataPacRat <>
To: Simon Perreault <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Tue, 16 Jul 2013 14:10:11 -0000

On Tue, Jul 16, 2013 at 4:33 AM, Simon Perreault
<> wrote:
> Le 2013-07-15 23:39, DataPacRat a écrit :
>>>> 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.
>>> What's the purpose of the 's'?
>>> 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.
> That means you want to prevent UAs that don't understand your new
> 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.

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

Close enough.

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

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

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
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,
"Then again, I could be wrong."