RE: [dss] DSS Core comments

[Trevor Perrin <trevp@trevp.net>]

Frederick,

Inline again..  I'm sifting out the points of agreement, just to keep 
things short.


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

I'll give it a shot.



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

You're right.



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

I think eliminating it wouldn't preclude anything; I'll look into this and 
start a thread about 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)

Or the client could specify a RefURI like "#someFragment", to produce an 
enveloped signature that doesn't cover the *entire* enveloping document, 
but just a particular fragment of it.

So I don't think we need to give guidance to the client on setting RefURI 
in enveloped documents - he should be able to figure it out himself.



>FJH I thought the transform was not required as long as the rules are 
>followed,

I guess you could omit the Enveloped Signature Transform, and use an XPath 
or some other transform that does the exact same thing.  But you need to 
use *some* sort of transform that removes the <ds:Signature> from the 
signature calculation, I'm pretty sure.


>  but do not see text in the XMLDigSig spec regarding this, so it is safer 
> to require the transform.

I don't think we need to *require* anything, for enveloped signatures.  The 
text in 3.3.1 and 3.3.2 is informative, not normative - it tells a client 
how to use the protocol to produce an enveloped signature, but it doesn't 
affect the protocol itself.

I'll add something to clarify that.




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

The <AudienceRestrictionCondition> is used inside of a <Conditions> - the 
<Conditions> has time constraints, so we could use that.

But I'm not sure it's appropriate - the <IntendedAudience> option is only 
used on the <SignRequest> to give guidance to the server.  The client says 
"this signature is for Bob", and the server says "okay, well I know Bob 
trusts my key X, so I'll sign with that", or something like that.

The SAML conditons are used in the Assertion so the Relying Party can 
determine if the Assertion is still valid, at some future date.

But since a DSS server consumes the <IntendedAudience> immediately, time 
constraints aren't needed for that purpose.

Maybe they're needed for some other purpose you're thinking of?


Trevor