Re: [VCARDDAV] Signed vCards

DataPacRat <datapacrat@gmail.com> Tue, 16 July 2013 14:10 UTC

Return-Path: <datapacrat@gmail.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA0E21E80A7 for <vcarddav@ietfa.amsl.com>; Tue, 16 Jul 2013 07:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHdRyIw22Qeq for <vcarddav@ietfa.amsl.com>; Tue, 16 Jul 2013 07:10:10 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id E64F221E80A1 for <vcarddav@ietf.org>; Tue, 16 Jul 2013 07:10:09 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id ey16so4180427wid.9 for <vcarddav@ietf.org>; Tue, 16 Jul 2013 07:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.194.216.99 with SMTP id op3mr1404675wjc.52.1373983808992; Tue, 16 Jul 2013 07:10:08 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Tue, 16 Jul 2013 07:10:08 -0700 (PDT)
In-Reply-To: <51E5055E.5070009@viagenie.ca>
References: <CAB5WduA09GVZ7j2q4e9aM-CYBj27_deKT=VHhVL0+gzG1yRq0A@mail.gmail.com> <CAD6ztsqqQwbN_-yv9+-tHuh8X1MfBRKEqF6ugH=0avHTuKxzWA@mail.gmail.com> <CAB5WduCO7mNPAqgqYWXmceog3wVNox5reUAjsCQRUXRQB0Wftw@mail.gmail.com> <51D18BC4.5030300@cisco.com> <CAB5WduAJSiqEjsw+DUo4Emy-Tw30nTw1WA2MshxJAfHN1sh0WA@mail.gmail.com> <51D1A52C.6000806@viagenie.ca> <CAB5WduDEe+tC21L6AbW0HRzTf5Z6L0oCA+M4X8_p1ERK0rFPtA@mail.gmail.com> <51D570F4.1020204@cisco.com> <CAB5WduC9OQDknwZj5PHQ0t8Y4V1vtpafeJuZXsnhrWKSmDfwFQ@mail.gmail.com> <CAB5WduC-m-TH9a1WrFY6QX8cQ2bJ8EgOD8+swEwpVxM7my42UA@mail.gmail.com> <CAB5WduBgpkQO+-4iNDspxR7X7JKeFU3UfjfiPd7qWWr7QRY3ew@mail.gmail.com> <CAB5WduCG356V5bHH8-7PYUtF3VqW5VRM-e=N0h7rbAJN51sSuA@mail.gmail.com> <51E42D85.4060806@viagenie.ca> <CAB5WduBJEXSsV5T-1MA+05wkQ6CZs8PySwUaQaAHew0E7dErbQ@mail.gmail.com> <51E5055E.5070009@viagenie.ca>
Date: Tue, 16 Jul 2013 10:10:08 -0400
Message-ID: <CAB5WduC6y1JJettoTFTDxrE5LnHWJDMrB=CAj-yjCjVSatqKEQ@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "vcarddav@ietf.org" <vcarddav@ietf.org>
Subject: Re: [VCARDDAV] Signed vCards
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 14:10:11 -0000

On Tue, Jul 16, 2013 at 4:33 AM, Simon Perreault
<simon.perreault@viagenie.ca> 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 a@b.com" without including the text 'a@b.com".


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