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: Magnus Nystrom <mnystrom@microsoft.com>
Date: Tue, 2 Feb 2010 16:31:49 +0000
To: Thomas Roessler <tlr@w3.org>
CC: XML Security Working Group WG <public-xmlsec@w3.org>
Message-ID: <D744D68428430B4F9C81DE8A4D595068021F75@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Well, creating an informational RFC for this PKCS #5 amendment is quite some work. And including the markup seems to create an opportunity for unintended deviations given that you would have the markup in two places.

I do not view the PKCS documents as any more vendor-specific than, e.g. the SECG documents (which we do refer to normatively). The PKCS process is an open one with participation from multiple parties, and one which has been around for a long time as well (almost 20 years!).

Best,
-- Magnus


> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-
> request@w3.org] On Behalf Of Thomas Roessler
> Sent: Tuesday, February 02, 2010 5:05 AM
> 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, 2 February 2010 16:32:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 February 2010 16:32:24 GMT