RE: [dss] DSS Core comments

[<Frederick.Hirsch@nokia.com>]

Trevor

Thanks for the responses to my comments and questions. I have some inline
comments to the remaining questions/comments you had that do not have new threads, prefixed with FJH.

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Wednesday, December 03, 2003 4:43 AM
> To: Hirsch Frederick (NMP-MSW/Boston); dss@lists.oasis-open.org
> Subject: Re: [dss] DSS Core comments
>
>
>
> 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".
>
>
FJH OK, not a major point, can refine it later if needed.

>
>
> >  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).
>
FJH I think for now we should stay with simplicity and add the simple sentence.


>
> >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.
>
FJH It might be simpler for you while you are editing since it is only a few paragraphs
let me know

> >
> >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?
>
FJH That would be helpful.

>> >[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.
>
FJH I was referring to what I thought was a mismatch between the schema definition and the text
which indicated optionality.

> 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.
>
>
FJH I was thinking about eliminating SignaturePtr as well, but don't want to preclude use cases in core. I
think a profile could disallow it.
> >
> >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.
>
FJH I  was thinking the server should set the URI to "" when it knows it is generating an enveloped signature, which means that the  signature covers the entire document that includes it, but that does not preserve comments, so maybe this is not correct. Better to leave it to the client to specify the URI (e.g. URI='#xpointer(/)' for this document with comments)

FJH I thought the transform was not required as long as the rules are followed, but do not see text in the XMLDigSig spec regarding this, so it is safer to require the transform.

> >
> >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?
>

FJH I believe AudienceRestrictionConditionType is derived from ConditionsType, so
they are applicable. I think it means that the assertion is appropriate for the specified
relying party, but only during that period of time. Sounds useful to constrain reliance.

>
> >
> >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?
>
>
FJH Yes I think so.

> 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.
>
>
FJH Thanks for the explanation. I don't think we need to make this change right now.



>
> >  In that case perhaps the client should explicitly signal which
> > references it has checked.
>
> That would be complicated, I think.
>
FJH Agree

>
> >  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.
>
>

FJH So does the TC agree to remove the IgnoreMissingInputDocuments option?


> >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?
>
FJH I think the explanation is necessary.


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

FJH this deserves a separate thread.