RE: Potential issues in XML Schema files pointed out from XML Sig v1.1?

I see. Apparently there may be cause for errata. I am not sure if we can assemble a quorum at this point, but you did get 3 responders on this “dead” list. 

 

Hal

 

From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] 
Sent: Wednesday, June 10, 2015 5:16 AM
To: public-xmlsec@w3.org
Subject: Re: Potential issues in XML Schema files pointed out from XML Sig v1.1?

 

Dear all,

Sorry for not reacting before....unexpected problems...

As for problem #1, I am not aware of the source of the problem, but at present there are two URLs that contradict each other:

In clause 10 of W3C Recommendation one finds the following URL pointing to the XML Schema for types and elements in  HYPERLINK "http://www.w3.org/2000/09/xmldsig""http://www.w3.org/2000/09/xmldsig#"   namespace:
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-schema.xsd

While in the XML Schema file at http://www.w3.org/TR/xmldsig-core1/xmldsig1-schema.xsd, which is pointed out by the W3C Recommendation one reads:
<include schemaLocation=HYPERLINK "http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core.xsd""http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core.xsd"/>

Not sure if this is to be considered an administrative configuration issue, being pieces of text that appears in XML Schema files pointed from an official W3C Recommendation, but the relevant thing here, in my opinion, is to fix this contradiction as soon as the W3C rules allow.

As for the problem#2, even seeing your point, I also know that other XML security related specifications well known and widespread make use of the schemaLocation attribute within import elements...below follow some examples:

1. XKMS 2.0, at http://www.w3.org/TR/xkms2/Schemas/xkms.xsd, includes the following imports to xml sig and xml encryption:

<import namespace=HYPERLINK "http://www.w3.org/2000/09/xmldsig""http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
<import namespace=HYPERLINK "http://www.w3.org/2001/04/xmlenc""http://www.w3.org/2001/04/xmlenc#" schemaLocation="xenc-schema.xsd"/>

2. OASIS SAML 2.0 xml schema at http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd, imports once again xml sig and xml encryption:

<import namespace=HYPERLINK "http://www.w3.org/2000/09/xmldsig""http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
<import namespace=HYPERLINK "http://www.w3.org/2001/04/xmlenc""http://www.w3.org/2001/04/xmlenc#" schemaLocation="xenc-schema.xsd"/>

I am pretty sure that there will be other specs out there using this attribute, as I am also pretty sure that there will be other not using it....this leads me to think that there is not such an unanimity among experts about the strict need to avoid the schemaLocation attribute in XML Schema files. Once said that, I would support Hal's view on the possibility of W3C having a written requirement on the topic...but also I am curious about the fact that there seem to be opinions on the topic that clearly lead to opposed conclusions (although this is not uncommon in technology, is it? :-) 

Regards

Juan Carlos.
El 09/06/15 a las 17:28, Hal Lockhart escribió:

My point was that at least in the case of problem #1, no change to the specification is needed or desirable. I presume (based on the existence of the schemalocation attribute) that the W3C has a policy of hosting official specifications so they can be retrieved from the location specified by the schemalocation attribute. Since this is an official specification of the working group which has been properly approved, the schemalocation it specified is the one that the W3C must support, therefore, this is an administrative configuration issue, not an error in the specification.
 
WRT to problem #2, I have no recollection of how and why it came to be omitted, but I prefer to think we left out schemalocation for exactly the reasons Scott cites. If however, the W3C has a written requirement that all official specifications must provide a schemalocation element, then we should amend this errata. Otherwise I would argue that it is merely a matter of incorrect expectations.
 
Hal
 
 

-----Original Message-----
From: Frederick Hirsch [mailto:w3c@fjhirsch.com]
Sent: Monday, June 08, 2015 3:47 PM
To: Juan Carlos Cruellas
Cc: Hal Lockhart; HYPERLINK "mailto:public-xmlsec@w3.org"public-xmlsec@w3.org
Subject: Re: Potential issues in XML Schema files pointed out from XML
Sig v1.1?
 
Juan Carlos
 
I think these issues warrant an errata item, so we can consider that.
Do you have specific proposed fixes for your second item?
 
However as Scott and Hal point out, it should not be an implementation
blocker given that retrievals from the w3c site is not best.
 
regards, Frederick
 
Frederick Hirsch
Chair XML Security WG
 
fjhirsch.com
@fjhirsch
 
 

On Jun 8, 2015, at 1:06 PM, Juan Carlos Cruellas

HYPERLINK "mailto:cruellas@ac.upc.edu"<cruellas@ac.upc.edu> wrote:

 
Thanks for this Scott and Hal,
 
I see your point...however, I tend to think that there is no point in

having a driver file that points to nowhere, and IMHO this should be
changed to point to the right place: as it is  now it is basically
making a wrong statement.

 
Also, even if I agree in that security issues would advice that

implementers get copies of the XML Schema files and get them from their
local store, to put in xmlsig11 the right pointer to the xmlsig, would
publicly declare within this XML Schema file where to get that other
xml schema...then implementers could store them wherever they
want....or do you think that doing that this could bring some security
issue for implementers that once downloaded the right xml schema files
just make use of these locally stored files?

 
Juan Carlos
El 08/06/15 a las 17:52, Hal Lockhart escribió:

If you really need this capability, the easiest solution would be to

ask Admin at W3C to establish the required alias URI.

 
As Scott has pointed out, the need to retrieve the schema should be

rare and not a routine operational process.

 
Hal
 

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
Sent: Monday, June 08, 2015 7:40 AM
To: HYPERLINK "mailto:public-xmlsec@w3.org"public-xmlsec@w3.org
Subject: Potential issues in XML Schema files pointed out from XML
Sig v1.1?
 
Dear all,
 
When looking at the XML Schema files pointed by XML Sig v1.1 I have
found the following:
 
1. At the so-called "driver" file, at
http://www.w3.org/TR/xmldsig-core1/xmldsig1-schema.xsd, I have
noticed the following include:
 
<include
schemaLocation=HYPERLINK "http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core.xsd""http://www.w3.org/TR/2008/REC-xmldsig-core-
HYPERLINK "http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core.xsd"20080610/xmldsig-core.xsd"/>
 
Please note that trying to retrieve a file from the URI within
schemaLocation attribute results in a file not found error
(404)....instead making a retrieve operation on
HYPERLINK "http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-schema.xsd""http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-
HYPERLINK "http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-schema.xsd"schema.xsd"
results in the correct file.
 
 
 
 
2. At the xml schema file in
http://www.w3.org/TR/xmldsig-core1/xmldsig11-schema.xsd,
corresponding to the xml schema for types and elements within
xmldsig11 namespace, the two first lines are:
 
<schema targetNamespace=HYPERLINK "http://www.w3.org/2009/xmldsig11""http://www.w3.org/2009/xmldsig11#"
version="0.1" elementFormDefault="qualified"> <import
namespace=HYPERLINK "http://www.w3.org/2000/09/xmldsig""http://www.w3.org/2000/09/xmldsig#"/>
 
but the import element does not have the schemaLocation attribute
that allows applications to automatically retrieve the xml schema
defining types and elements for xmldsig namespace...shouldn't it be
such a schemaLocation with a value
http://www.w3.org/TR/2008/REC-xmldsig-core-
20080610/xmldsig-core-schema.xsd?
 
 
Could you please confirm if you also see them as issues that could
need to be fixed? and if so, could you please make an estimation on
how and when they could be fixed?
 
 
Best regards
 
Juan Carlos.