- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 2 Feb 2010 14:05:20 +0100
- To: Magnus Nystrom <mnystrom@microsoft.com>
- Cc: Thomas Roessler <tlr@w3.org>, XML Security Working Group WG <public-xmlsec@w3.org>
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 13:05:23 UTC