[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] DSS Core comments
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]