Re: [VCARDDAV] Signed vCards

Simon Perreault <simon.perreault@viagenie.ca> Tue, 16 July 2013 08:33 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 3CBC411E8271 for <vcarddav@ietfa.amsl.com>; Tue, 16 Jul 2013 01:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599]
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 2OP6s5VTXtXy for <vcarddav@ietfa.amsl.com>; Tue, 16 Jul 2013 01:33:35 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3058511E826F for <vcarddav@ietf.org>; Tue, 16 Jul 2013 01:33:33 -0700 (PDT)
Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 51CB440372; Tue, 16 Jul 2013 04:33:32 -0400 (EDT)
Message-ID: <51E5055E.5070009@viagenie.ca>
Date: Tue, 16 Jul 2013 10:33:34 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: DataPacRat <datapacrat@gmail.com>
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>
In-Reply-To: <CAB5WduBJEXSsV5T-1MA+05wkQ6CZs8PySwUaQaAHew0E7dErbQ@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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 08:33:36 -0000

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?

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