Re: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt

Tero Kivinen <> Fri, 04 March 2011 10:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84A633A68AF; Fri, 4 Mar 2011 02:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wINhU0NZ+M1Q; Fri, 4 Mar 2011 02:35:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0DA8B3A6827; Fri, 4 Mar 2011 02:35:31 -0800 (PST)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id p24AaaIU025108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2011 12:36:36 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id p24AaZed001497; Fri, 4 Mar 2011 12:36:35 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Fri, 4 Mar 2011 12:36:35 +0200
From: Tero Kivinen <>
To: Oscar Novo <>
In-Reply-To: <>
References: <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 9 min
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Mar 2011 10:35:33 -0000

Oscar Novo writes:
> The authors of this document understand the Security considerations
> as a general guidelines for the implementers, rather than a set of
> absolute requirement for this specification. It might be the case in
> some particular scenarios where the confidentiality can be ignored.
> For this reason, we decided not to impose confidentiality (using
> SHOULD instead of MUST) in the document and to leave that decision
> to the administrator of the conference.

I can understand that, and I agree that on some scenarios the
confidentiality can be ignored. But I do think that is the case when
the database actually holds confidential information like passwords. I
would be happy for text saying that if database has no confidential
information then confidentiality may be ignored, but if in most cases
I think it does include confidential information and then it needs to
be protected.

Anyways I think this is to point the fact out to iesg, they can decide
whether it is appropriate or not. Usually protocols have required
confidentiality when there are tihngs like passwords to be protected.

> The same reason applies to the definition in this document of
> 'private elements'. Privacy is a subjective expectation and the
> definition of private elements in the conference depends very much
> on the context of such conference. As you point out, every country,
> company, association or entity would have a completely different
> meaning of privacy. For this reason, we just decided to suggest some
> control and integrity of the data ( by using access control rules)
> in the security section instead of imposing it:

The current security considerations section does not say anything
about the privacy issue, and I think this is big omission.

I am not sure if any real world requirement can be given, but I think
the security considerations section should point out that the database
has privacy related information stored in it and that should be taken
in to consideration when deciding how the database is protected, and
who has access to it.

The privacy issue also brings up new topic, namely the lifetime of the
data in the database. I do not know whether the entry stays in
database only during the conference, or whether it stays there
forever. For privacy information storing it long times can cause