W3C home > Mailing lists > Public > public-xmlsec@w3.org > February 2010

RE: ISSUE-186: What is the normative content of section 5.4.2? (PBKDF2) [Enc11 (XML Encryption 1.1)]

From: <aldrin.dsouza@rsa.com>
Date: Tue, 9 Feb 2010 01:47:10 -0500
Message-ID: <901E1BC8E8EF9345BB8FB1EE99D0F31605AF7D06@CORPUSMX70B.corp.emc.com>
To: <tlr@w3.org>
Cc: <public-xmlsec@w3.org>
Hello Thomas,

>From an RSA perspective, it could take a long time to get a new document
describing the schema additions to PKCS#5v2.0 edited and through the RFC
process. We'll need to obtain some further internal review here before
proceeding and the process might impose an extended delay on XML Encryption
1.1 which is something we'd like to avoid. It'd be good to get a sense of
how much the group prefers the alternatives.

The current text of section 5.4.2 clearly distinguishes the functional part
of the algorithm (which is already an RFC) from the schema addendum. If we
can not refer to the PKCS document, we could, as you suggested, redefine the
required schema elements in the XML-Encryption spec itself. We already do
something similar for OAEP [1]. The algorithm identifier can also be defined
like the one we use for OAEP, say with a '#pbkdf2' suffix.

What do you think?

thanks,
--
ajd.

[1]: http://www.w3.org/TR/xmlenc-core1/#sec-RSA-OAEP

-----Original Message-----
From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On 
Behalf Of Thomas Roessler
Sent: Tuesday, February 02, 2010 6:35 PM
To: Magnus Nystrom
Cc: Thomas Roessler; XML Security Working Group WG
Subject: Re: ISSUE-186: What is the normative content of section 5.4.2? 
(PBKDF2) [Enc11 (XML Encryption 1.1)]

On 29 Jan 2010, at 06:35, Magnus Nystrom wrote:

> I don't quite understand your concern here, Thomas. In my opinion, this 
> section does define a profile of PKCS #5 v2.0 Amd.1 - it specifies 
> requirements on certain elements and also explains how instances of types 
> defined in the PKCS document is to be used within XMLENC 1.1. The algorithm 
> is also clearly marked as optional.

It wasn't entirely clear to me that we're actually describing a profile (as 
opposed to simply repeating what's in the vendor spec in question).

The other point of uneasiness here is that the document we're referencing and 
profiling here is, after all, a vendor specification in the first place.  I'd 
rather, e.g., point at an (even informational) RFC [which is what we do for 
PKCS #5 proper], or see if we could include the mark-up in the XML Encryption 
spec proper.  It seems light-weight enough.

Aldrin, I wonder what you think about this from an RSA perspective?

> And I don't see what difference it makes if the algorithm identifier is 
> defined elsewhere? As long as it is clearly stated where the algorithm (and 
> the XML schema) is defined I don't see why there should be confusion?

On the namespace URI question (and my apologies for not having caught this 
much earlier), there's in fact a general expectation that W3C specifications 
use w3.org namespaces, see <http://www.w3.org/2005/07/13-nsuri>:

> Director approval is required for all other namespace URIs. In particular:
>
> 	. The Director may authorize a group to use a namespace URI that does not 
> begin with http://www.w3.org/. The Director expects the organization that 
> allocates the URI to have a clear persistence policy associated with the 
> URI, to make a commitment to longevity of service, and to provide 
> information about how the URI will be maintained in the event of the demise 
> of the host organization.





Received on Tuesday, 9 February 2010 06:48:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 February 2010 06:48:52 GMT