Re: [dss] DSS Core comments

[Trevor Perrin <trevp@trevp.net>]

Hi Frederick,

inline -


At 10:36 PM 12/2/2003 -0500, Frederick.Hirsch@nokia.com wrote:

>Trevor,
>
>Here are some additional questions and comments on Draft 7 of the core 
>protocol , 25 Nov 03, referenced by
>line number:
>
>Section 1, line 118.
>Generally a profile restricts a specification, perhaps this line should be 
>rephrased:
>
>"The core protocols may also be profiled to constrain optional features 
>and define extension points."

People like EPM might want to add new options, as well as constrain 
things.  Maybe the word 'profile' isn't exactly right for this, but in lieu 
of a better word, I like the sentence as is.

In particular, I thought an 'extension point' was the place where 
extensions are added, not the extensions themselves?  Saying "...and define 
extension points" sounds more complex and vague to me than "...and add 
additional features".



>Section 1.1, lines 133-140
>
>We may want to add that the prefixes are not normative, only the 
>namespaces to which they refer

Agree.


>  and that a change of namespace URI will be required if there are 
> significant changes to the processing rules.

Can we just add a single sentence, like:
"If a future version is needed, it will use a different namespace."? (text 
from XKMS).

Or does anyone want more sophisticated versioning?  For example, see SAML 
section 4 for a more elaborate approach:
http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf 



>Section 1.3
>Even though this will be revised, should we change QNames to URIs at line 188

Yeah, I think the Overview needs several things updated, particularly on 
the relationship between time-stamping and the other protocols, and on our 
time-stamps.  Though it's mostly still good.

I'll try to update it for the next version, unless you'd like to do so.


>
>Section 2.4.1
>Should ID be required?

The ID on an InputDocument is only needed when used in conjunction with an 
option that refers to the document.  Since that's probably only rarely, it 
could be optional.  Maybe we could just add a sentence or two explaining this?

In the Signing protocol, it's needed with these options:
  - 3.4.8 SignedReferences (which documents to sign, and apply transforms to)
  - 3.4.10 SignaturePlacement (which document to insert the signature in)

In the Verifying protocol, with:
  - 4.5.12 ReturnTransformedDocument (which document to return a 
transformed version of)


>
>Section 2.4.2
>[271] Add clarifying sentence:
>The element content of <XMLData> or <Base64Data>, including all 
>whitespace, is the input to the signature reference hash function - this 
>surrounding element is not included.

Agree.


>
>Section 2.5
>[325, 326] Rename element Signature to be "SignatureObject"
>I think Signature is too close to ds:Signature, to lead to confusion

Agree.


>
>[371] should XPath have "use="optional" in the schema definition? (this 
>change also applies to the schema document)

If the whole document was a signature?  Sure.

Another question is whether the <dss:SignaturePtr> is even a desirable 
feature.  It's only there for a case such as the 3.4.10 SignaturePlacement 
option, where the signature is being returned inside an input document, so 
the <dss:SignatureObject> just points to it, instead of including a copy of 
the signature.

But maybe that's getting too fancy, and we should just include a 
copy?  Dunno, I'll make a separate post about this.


>
>Section 2.6
>Agree with Nick on OptionalOutputs

Agree.


>[376-377] Maybe rephrase to
>  "The <OptionalInputs> element contains options associated with the 
> processing of the request.", since the options may affect processing or 
> what is returned, and not just refine the input.

Agree.


>
>[386] Do we want to define OptionalInputs and OptionalOutputs using a 
>Sequence of dss:AnyType, since the text says it is a sequence of one or 
>more Input or Output items?

dss:AnyType is a sequence of <xs:any>.


>
>Section 2.7 [390] Does discussion of URI vs QName apply to results? (Could 
>a result be signed and a QName value cause canonicalization issues?)

SAML and XKMS use QNames, for result codes.  I guess just cause they're 
shorter.  Do other people want to switch to URIs here, too?


>
>Section 3
>[430] This section is focused on XML Signature (e.g processing rules), yet 
>the request could be to create a CMS signature, for example.
>Should we define a signature type SignRequest attribute with default for 
>xml signature (type anyURI, e.g 
><http://www.w3.org/2000/09/xmldsig>http://www.w3.org/2000/09/xmldsig)?
>Not an option, because it is basic to the core processing rules? (this is 
>alternative placement versus 3.4.4 option SignatureType)

We could.  It's hard to say what's "basic to the core processing rules" and 
what isn't, though - and keeping things as options means profiles have the 
latitude to omit them.

For example, a profile might just decide "I always produce XML signatures, 
I don't want to bother with the SignatureType option".  But if this is a 
non-optional part of the protocol, then every profile, and thus every 
server, must know how to handle this field.

Not a big deal, but that's just an argument for sticking with a really 
minimal core, and leaving most things as options.


>
>Section 3.1, [437] typo, "A list..."

Yup.


>
>Section 3.3
>[482] Rephrase step 1 suggestion:
>1. The server either hashes the element content of each <XMLData> or 
><Base64Data> element contained within a <Document> element, or copies the 
>hash conveyed in the element content of a <DocumentHash> element contained 
>within a <Document> element. All whitespace is preserved.

How about:

1.  The server hashes the contents of each <Document> element:  If the 
<Document> contains <XMLData>, the server hashes the entire contents of the 
<XMLData> element, excluding the start and end tags.  If the <Document> 
contains <Base64Data>, the server base64-decodes the element content and 
hashes the result.

2.  The server forms a <ds:Reference> for each input document out of its 
RefURI, RefType, <ds:Transforms>, and the hash value that was calculated in 
step 1 (for a <Document>) or transmitted to the server (for a <DocumentHash>).


>
>[485] ] I suggest we add a sentence before step 3:
>At this point the server creates an XML Digital Signature using the 
>References created in Step 2, according to the processing rules in the XML 
>Digital Signature recommendation. This is briefly outlined as follows, but 
>the normative reference is XML Dsig:

How about replacing steps 3 and 4 with:

3.  The server creates an XML Digital Signature using the References 
created in Step 2, according to the processing rules in the XML Digital 
Signature recommendation.


>
>Section 3.3.2
>[496] Add a sentence, "When the server creates an enveloped signature, the 
>ds:Reference MUST/SHOULD have a URI with value "". The 
>EnvelopedSignatureTransform is not required, but may be used

I'm not sure I understand.

Are you saying the client must set InputDocuments/Document/@RefURI to "", 
for an enveloped signature?  I'm not sure that's true, can't the client set 
it to, say, "#someFragment", if that's what's being signed?

And why is the EnvelopedSignatureTransform not required?  I thought it was 
necessary, for enveloped signatures.


>
>Section 3.4.5
>[527] Does this mean that an 
><ds:Object><ds:SignatureProperties><dss:Timestamp> is added to an XML Sig? 
>Should be clear what it means to add a timestamp.

What exactly it means will depend on the Type of timestamp you're 
requesting, and the type of signature you're adding it to (XML-DSIG, CMS).

And even with XML-DSIG, there might be different ways of attaching 
time-stamps.  For example, XAdES has a particular structure for signature 
properties, that dictates where you put time-stamps, but a different 
profile of XML-DSIG might place timestamps differently.

So I think this is necessarily kinda underspecified, in the core; we'll 
have to let profiles specify the details.


>
>Section 3.4.6
>[537] Should we reuse saml:AudienceRestrictionConditionType for 
>IntendedAudience ?
>Having the time constraint seems useful (notbefore, notonorafter) for 
>relying on the signature by this audience, using URI to specify relying party

I think the time constraints are part of saml:ConditionsType, not 
saml:AudienceRestrictionConditionType.  I'm not quite sure what they'd mean 
in this context?

Using dss:NameType lets us express different name forms, such as 
Distinguished Names, and Windows domain-qualified names, which I don't 
think there are URI schemes for.


>
>Section 3.4.7
>[550] why isn't the schema  simply <xs:element name="KeySelector" 
>type="ds:KeyInfoType" /> ?

The advantage is that it's a little more legible, this way.  Also, Rich 
liked it cause we could add an extensibility point to <KeySelector>, to 
future-proof it.  Though I realize we didn't do this, and probably should:
http://lists.oasis-open.org/archives/dss/200310/msg00071.html

At the time, I think you supported this:
http://lists.oasis-open.org/archives/dss/200310/msg00083.html

So would you agree to making <KeySelector> extensible, but otherwise 
leaving as-is?


>
>Section 3.4.8
>[558] I do not understand SignedReferences - should this say that it 
>supports applying additional transforms to Reference creation in step 2?

Yeah, this needs to be explained in more detail.

The intention is that it not only applies additional transforms, but that 
it overrides the assumption made in Basic Processing that there's a 1-to-1 
correspondence between input documents and ds:References.

Instead, there's now a 1-to-1 correspondence between SignedReferences and 
ds:References, but multiple SignedReferences can refer to the same Input 
Document.

So with the SignedReferences option, you only need to send the document 
once, even though you request a signature that covers multiple 
differently-transformed versions of it.


>It doesn't seem to specify the RefURI or RefType so cannot replace 
>processing step 2

RefURI and RefType are still taken from the Input Document.

If multiple ds:References refer to the same Input Document, the 
ds:References will have the same URI and Type attributes, but will have 
different Ids.

That's why RefURI and RefType are attributes on Input Documents, whereas 
RefId is an attribute on SignedReference.

Maybe we should also make RefId an attribute on Input Documents, with the 
proviso that it will be overriden by any RefId on SignedReferences.  Hmm... 
not sure.


>
>Section 3.4.9
>[598] Should property identifiers be URIs instead of QNames? (also schema 
>document and line [622]

Since properties are probably XML elements, they can naturally be described 
as QNames.  For example, to request the XAdES property xades:SigningTime, 
you can just send "xades:SigningTime".

So I think we should stick with QNames, but add that rationale to the spec.


>
>Section 3.4.10
>[634] Add sentence, if correct:
>"  The signature is placed immediately after the closing element of the 
>specified element. "

Agree.


>
>Section 4
>Similar comment about bringing signature type up to attribute on VerifyRequest
>
>Section 4.2
>As Nick noted in SignRequest, [706] rename Outputs to  OptionalOutputs

Agree.


>
>Section 4.3
>[728] Step 2 applies to References within SignedInfo, perhaps word
>"For each <ds:Reference> within <ds:SignedInfo> in the <ds:Signature>, the 
>server finds..."

Agree.


>
>Indicate Manifest reference hash checking is not performed by default, and 
>only is if option VerifyManifests is present (refer to 4.5.5)

Agree.


>
>Section 4.5
>
>I think that options that are common to both requests and responses should 
>be in a single section, so we don't duplicate them and possibly introduce
>inconsistencies (e.g. ServiceProfile, ServicePolicy, ClaimedIdentity) - 
>e.g. add section 2.8, Common Options

Agree.


>
>Section 4.5.4
>At first glance this IgnoreMissingInputDocuments option appears to be 
>inconsistent with XML Dsig processing rules which require ds:SignedInfo 
>ds:Reference checking, but may be ok if distributed processing shared with 
>the client is assumed.

Right.  We had a requirement for "selective verification", where the client 
says "whether or not references should be verified".


>  In that case perhaps the client should explicitly signal which 
> references it has checked.

That would be complicated, I think.


>  Even so, this is a security threat, since any document change would be 
> undetected without hash verification for the document the relying party 
> is examining.
>
>I propose we eliminate this option since Manifests cover this purpose and 
>avoid these ambiguities and risks, or at least making it clear within the 
>signature that Manifest processing rules are being followed.

I agree, not because of Manifests, but because just sending the right 
hashes is easy enough that I don't think we need an option, just for this.


>
>Section 4.5.8
>Should we diverge from XKMS and use URIs instead of QNames
>
>Section 4.5.9
>What does it mean to rely upon signing time?

That's meant to distinguish between a signed attribute added by the signer, 
and a separate time-stamp from a TSA.

How about renaming the attribute to "Timestamped", with text explaining the 
above?


>
>Section 4.5.11
>I'm having trouble with this wording. Does this mean what is returned is a 
>new signature, with the same information as the original signature, 
>potentially with some additional ds:References, thus providing "signature 
>refresh"? If not a new signature, I don't see how the signature can be 
>securely updated without breaking verification.

More likely what's added are unsigned attributes, which add additional 
timestamps or validation data (certificates, CRLs, etc.) to the original 
signature.  Since they're unsigned, they don't break the signature even 
though they're inside the <ds:Signature> element.

But I suppose this could also be a new signature, calculated over the same 
ds:References.

The details will depend on the Type attribute, which different profiles 
will define.

I'll add text to explain.


>
>Section 5.3
>Perhaps rephrase:
>"Using ds:SignatureType allows conventional digital signature 
>implementations to validate the signature, but additional processing is 
>required to validate
>the timestamp properties "(TstInfo, steps 6-9,11 in processing rules 5.6)

Agree.


>
>Section 7.1
>We might want to make this URN consistent with Oasis conventions, (e.g. 
>what WSS is proposing?)

The URN "urn:oasis:names:tc:dss:1.0" is consistent with SAML and XACML; at 
one point this convention was part of the TC guidelines, but it's been 
removed with no new guidance that I'm aware of.

What's WSS proposing?


>
>Section 7.1.1
>[1054] Should URI be urn:oasis:names:tc:dss:1.0:name-format:unspecified 
>(e.g. was dss missing?)

Yes.


>
>Section 9.1
>Seem to be extra years at [1138], [1141], [1142]?

Yes.


Trevor