[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [dss] review comments
Carlos,
I am forwarding to you suggestions where changes might be necessary and his
thoughts on other issues that you raise.
I must highlight that at this stage with only a week or two to the deadline
we have for going to public review we are limiting ourselves to correction
of errors and area where the text is unclear. Addition of new functionality
or alterative approaches to make implementation more straightforward will
have to either:
a) be addressed in a profile,
b) the next version of the core.
Changes can only be made where we have explicit change proposal.
Bearing this in mind I ask you to resubmit you comments identifying areas
for future work in a profile / next version of the core, and providing text
where changes are considered to be absolutely necessary, as soon as possible
for final resolution at next Mondays focus group meeting.
Thanks for your efforts in contributing to the work of the committee, it is
only through the help of committee members that we can achieve a successful
result.
Nick Pope
-----Original Message-----
From: Konrad Lanz [mailto:Konrad.Lanz@iaik.tugraz.at]
Sent: 10 July 2006 22:16
To: Nick Pope
Cc: Juan Carlos Cruellas
Subject: Re: [dss] review comments
Hi Carlos, Nick and all
thanks for reviewing the core Document, here are my comments:
There are 14 things that could be clarified/changed pretty straight
forward before voting.
Carlos can you please make the relevat suggestions and get back to Nick,
JC and myself.
best regards
Konrad
Carlos Gonzalez-Cadenas wrote:
> 1. 2.4.1 Type DocumentBaseType
> 1. RefURI / RefType
cf. to WD44 lines 168, 967 - 969 I hope that makes things clearer.
> This applies also for the RefType element.
again please cf. to lines 168, 967 - 969.
> 2. SchemaRefs
> i. [...] it's difficult to find any practical case (unless the
schemas are duplicated) in which we can validate the document against
the first schema and also against another schemas included.
That was also not intended, the intention is that the first schema is
the one to be used for validation and the other schemata (btw. we should
rename <Schemas> to <Schemata> in the public review preiod) are included
or imported by the first one directly or transitively similar to what
you ask in ii.) .
So if that was not clear we should change lines 317 - 319 as follows:
If a <Schemas> element is referred to by SchemaRefs the document is
assumed to be valid against the first <Schema> inside <Schemas> The
remaining schemas may occur in any order and are included or imported
either directly or indirectly by the first schema.
> ii. [...] handle schema importing via
> [...] with no schemaLocation attribute: Imagine the case (it's common
in the practice) of a schema inside the request that imports other
schema that is also included in the request (inline importing).
you would supply the schemata as the second, third .... schema inside
<Schemas>.
> [...] with a schemaLocation attribute: To be able to validate, the
server should download the schema.
That is currently out of scope, however if your implementation supports
that that's a feature (but you'll have to be careful when retrieving
anything from the web to retrieve it in a secure way).
again you would supply the schemata as the second, third .... schema
inside <Schemas> and use some kind of resource manager on the serevr.
> I think the two cases should be analyzed to see 1) if we're
supporting them and
Yes we do support imported included schemata, however a client should
send them along in the request, or a specific application of DSS will
need to have them available on the server (that's however currently not
covered by the text, however it is also not prohibited).
Also refer to lines 708 - 710 to use xml:id instead of supplying schemata.
> 2) how to do it.
It is currently out of scope how to retrieve the relevant schemata as we
assume the client will sent them along with the document, if needed.
Btw. my opinion about this is that schema validation is also not very
well covered in XMLDSig on which we heavily rely on.
Maby we should approach the w3c-ietf-xmldsig@w3.org mailing list in the
future as this seems to be the more appropriate place to discuss this
further.
cf: http://www.w3.org/TR/xmldsig-core/#sec-o-Reference
[...] Transforms is an optional ordered list of processing steps that
were applied to the resource's content before it was digested.
Transforms can include operations such as canonicalization,
encoding/decoding (including compression/inflation), XSLT, XPath,
*XML schema validation*, or XInclude.
> Even if no change is done, maybe some clarification should be added
to the text
*CHANGE1*
We could put a note at the end of section 3.3.1 and 4.3 that explicitly
allows server implementations to store or cache schemata, however I
consider this an implementation issue and the default should be to ask
the client to send them, along.
Either way if you do full schema validation on signing you will you will
have to reflect any changes schema validation does to your documents in
the <ds:Transforms> so that others will be able to verify your
signatures if they use schemata just to identify id attributes. (cf.
3.3.1 d. v.)
Alternatively you can use schema validation just for identifying id
attributes and touch the documents as little as possible.
There is not a lot we in DSS can change about this, again if you have
ideas: w3c-ietf-xmldsig@w3.org
> 2. 2.5 Element <SignatureObject>
> 1. dss:SignatureObject and dss:Document asymmetry: Please see my last
email with that subject.
We know that already, it is a good point however, and that's the reason
why I asked the committee quite a while ago to add the note at the end
of section 4.3.
I doubt there is time to change that however that is already on the
Agenda for Version 2.
> 1. XMLDSig example: The real DSS example (<SignaturePtr xmlns:ds=".)
is given less importance than the XMLDSig one. I would eliminate the
XMLDSig example and put the DSS one in its place.
Talk to JC about that please.
> 3. 2.6 Element <Result>
> 1. Error code conventions: some conventions about error codes should
be taken, as they're not symmetric, some examples
> i. if we look to
urn:oasis:names:tc:dss:1.0:resultminor:incorrectSignature and also
> urn:oasis:names:tc:dss:1.0:resultminor:HasManifestResults [...]
*CHANGE2*
I agree, make a suggestion and sent that to the list ASAP.
> ii. some others use more than one word separed by semicolon
urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature instead
of, for example,
urn:oasis:names:tc:dss:1.0:resultminor:inappropriateSignature
*CHANGE3*
I agree, make a consistent suggestion and sent that to Stefan and the
list ASAP.
> 4. 2.8.1 Optional Input <ServicePolicy>
> 1. Can't obtain applicable service policy: This is an issue similar
to the one we've found in <VerificationTime>. Before the latest
addition, one could assert to the server the verification time, but was
impossible to obtain the verification time used by the server. So
<VerificationTime> was renamed to <UseVerificationTime> (the use verb
reflects the assertive nature of the optional input), and a new optional
input/output was added
<ReturnVerificationTimeInfo>/<VerificationTimeInfo>, allowing clients to
obtain the verification time applied by the server.
*CHANGE4*
I agree, however this has low priority and could also be done in the
public review period.
> In this case, we also can't obtain the applicable service policy. I
propose to use the same strategy, refactor the actual <ServicePolicy> to
<UseServicePolicy> and add a new optional input / output
<ReturnServicePolicyInfo>/<ServicePolicyInfo>.
*CHANGE5*
I agree, however this has low priority and could be handled in version 2.
CHANGES 4,5 if you make a concrete text proposal that could be agreed on
in the next meeting that's fine with me as long as the returned
<ServicePolicyInfo> is a simple URI.
<np>
As this is an extension I suggest this is handled in v2</np>
> 2. Sub-policies
I really doubt there is time to change that.
<np>I am not sure that this extra complexity is necessary. Extension for v2
in necessary</np>
> 5. 2.8.2 Optional Input <ClaimedIdentity>
> 1. <ClaimedIdentity> and <RequesterIdentity>: Are these two ways of
doing the same? (authenticating the request). If so, I would recommend
to keep only one, reducing complexity for the implementers.
Nick, please clarify.
<np>These two elements have different functions. ClaimedIdentity is on
optional input in the DSS request for carry a claimed ID that needs to be
authenticated by some means. RequesterIdentity is a property of a XML
signature that can be used when a server signs on behalf of another party to
indicate the id of the entity on whose behalf he is signing. The value in
the requesterIdentity MAY be set to the ClaimedIdentity but they do not have
the same function.
We cannot change the RequesterIdentity element as it is being referenced in
another OASIS committee draft (court filing). However, if this helps could
do:
Change 5b
Replace "ClaimedIdentity" with "ClaimedRequesterIdentity".
> 1. Examples: Is it possible to add some annex or annexes including
how to use <ClaimedIdentity> in several major cases (i.e. signatures,
SAML assertions, passwords)?. I think it's worth the effort for two
reasons 1) maximizing practical/technical interoperability (common-case)
without restricting to any other ways to do it 2) security
considerations that could be analyzed apply for almost any of the former
cases (signatures, SAML assertions, passwords). I've done some
preliminary work in my profiles that could be used as a starting point
for discussion.
Good point, we should try to add this in the public review period.
<np>If we have text we can easily add which doesn't effect the standard we
could do this, but we shouldn't ourselves plan to make any significant
changes to this version when released.
> 6. 3.2 Element <SignResponse>
> 1. <SignatureObject>: Typo, replace it's by its.
A line number would be helpful.
> 7. 3.3.4 Process Variant for <Base64Data>
> 1. Step 1.b: What should be the behaviour when the IncludeObject's
ObjId attribute is present? (also applies for XML input documents)
cf. to 3.5.6.1 step 1. c. i. which is always executed. (there is a typo
of --> if)
*CHANGE6*
The server generates the new <ds:Object> and sets its Id attribute to
the value indicated in ObjId attribute if the optional input if present.
> 8. 3.4 Basic Processing for CMS Signatures
> 1. Step 1.b: I don't understand this text: "This octet stream has to
be returned as <TransformedDocument>/<Base64XML>
The <SignResponse> will also contains the optional output
<TransformedDocument> containing <Base64XML>.
*CHANGE7* Lines 976 - 979
For CMS signatures that are external/detached/"without eContent", this
octet stream has to be returned as <TransformedDocument>/ <Base64XML>.
Note: Other CMS signatures return the signed Data anyway.
> 3. Step 2.a: Why step 1.c?. Should it be step 1.e?.
> BTW, can we move the <DocumentHash> references in 3.4 to 3.4.1?.
*CHANGE8*
That is a good Idea could you please supply some text.
> 9. 3.5.6 Optional Input <IncludeObject>
> I see this optional input somewhat confusing and open to
interpretation. I suggest some revision to the whole optional input.
*CHANGE9*
Good point, please supply some text.
> 1. It's not said explicitly that multiple occurrences for this
optional input are allowed.
True.
> 2. createReference:
if createReference == false you simply add a ds:Object but you do not
create a reference for it.
> i. I see possible collisions with another ways of creating references.
There shouldn't be as lines 1228 - 1230 should prevent that.
> 1. When we have a RefURI expression that points to the enveloped
document (by means of an appropriate ObjId): In this case, which is the
behaviour if we have createReference asserted to true?.
Some Examples that work (I'm not sure about the xpointer syntax but you
should get the idea):
* RefURI = #xpointer(id('some-id')) and ObjectId = 'some-id'
* RefURI = #some-id and ObjectId = 'some-id'
* RefURI = here()/ancestor::ds:Signature/ds:Object[1] and ObjectId omitted
* RefURI = here()/ancestor::ds:Signature/ds:Object[@id = 'some-id'] and
ObjectId 'some-id'
* RefURI omitted and ObjectId omitted
> Creating two references?.
No, only one Reference, always.
> 2. When using <SignedReferences>: I was assuming that this optional
input completely manages the reference creation. But, in this case, we
could also have two or more references (the ones included by
SignedReferences and other one included by <IncludeObject>).
No that's wrong as a <SignedReferences> element only changes the
creation of a ds:Reference.
You can think of it that way:
There will be a <ds:Reference> for every <SignedReference> element, but
none a document referred to by a <SignedReference>/WhichDocument.
There will be further a <ds:Reference> for every other input document if
it has not been covered by other processing already (cf. section 3.5.6.1
Lines 1228 - 1230).
*CHANGE10*
Let's add a note clarifying the above, in an appropriate Location.
> If we want to preserve the priority/exclusivity of <SignedReferences>
when managing reference creation, we could add specific wording to solve
that issue.
> 3. 3.5.6.1 XML DSig Variant
> i. Why do we have a XMLDSig variant if the optional input is only for
XMLDSig signatures?
*CHANGE11*
Good point that's an historical artefact as 3.5.7 was added later.
Please instruct Stefan to change that.
> ii. With respect to the text "This <Document> (or documents) MUST
include a "same-document" RefURI attribute . which references the data
to be signed"
> 1. Under section 3.3 processing rules, this will force the server to
create a <ds:Reference> pointing to the enveloped document, then there's
no need for createReference attribute, as we're always protecting the
enveloped document (and therefore excluding the possibility for the
non-protecting case described in the createReference definition).
However that was intended by the design. (c.f. QualifyingProperties of
XAdES are not to be signed).
> 2. What happens if the referred document doesn't have a
"same-document" RefURI? (no behaviour / error codes defined).
*CHANGE12*
Carlos, please make a suggestion.
> iii. With respect to the text "Clients MUST generate requests in a
way that some <ds:Reference>'s URI values actually will reference the
<ds:Object> generated by the server once this element will have been
included in the <ds:Signature> produced by the server"
> 1. What happens with the enveloping-but-not-protecting case?.
That is not covered as you might just as well create an enveloping or
detached signature and embed it into what ever you want after
processing, if you pay attention with your references.
> 2. Too much responsibility on the client side. my understanding:
I agree, see the examples I have given above for <IncludeObject> however
hat was the greatest common divisor at the time this was specified.
>"okay, as we have many ways to do it, don't forget to use one". I
think that we should make this easier, and harden the processing rules
to avoid ambiguity.
I think the most you can do currently is to check the supplied RefURI
and issue an error if the client does any bad.
If you have a Proposal please go ahead, but I doubt we'll have time to
change this now, the best thing would be to save this for version 2.
> 10. 3.5.8 Optional Input <SignaturePlacement>
> 1. In a similar way as <IncludeObject>, we have the concurrence of
the <RefURI> attribute and, in this case, the CreateEnvelopedSignature
element.
> i. What happens if RefURI is not RefURI=""?.
*CHANGE13*
Carlos, please make a suggestion, at the time this was specified the
committee was hesitant adding any more error messages.
Please consider reusing
urn:oasis:names:tc:dss:1.0:resultminor:NotSupported
urn:oasis:names:tc:dss:1.0:resultminor:GeneralError.
> ii. Can we use <XPathAfter> and <XPathFirstChildOf> at the same time?.
No they are XOR.
*CHANGE14*
A note could be added.
> 11. Compliant implementations
> Is it planned to add a compliance section for the protocol?
I would advocate fore this, but not at this stage. Please check with HAL
what the usual way of doing this is.
--
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at
Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]