[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: Re: Re: FW: [dss]: A first quick Shot at section 4.4 and section 4.6.1
Hi Tommy, Nick and all
Better error handling escalating problems rendering validation outcome
impossible to <ResultMajor> instead of an indetemined case, is a good
compromise and a solution to the issue. Now the service can respond with
"successful+valid", "successful+invalid", "{Requester,Responder}Error
+explanation" or "[some unsuccessful ResultMajor]+explanation". The
latter is a perfect substitute for an indeterminate case as for certain
cases it is neither the requesters nor the responders fault that the
outcome was not determinable and a
CurrentlyInsufficientInformationAvailiable or similar ResultMajor might
be useful as it is not as strong as an error.
For section 4.6.1 I'd suggest to use
urn:oasis:names:tc:dss:1.0:resultminor:validXMLDSigCore:hasManifestResults
and to put normative text that it is only indicating core validity and
not overall validity which might have failed due to conditions of the
manifest expected differently by the client.
Could you please draft the new text for ResultMajor, 4.4 and 4.6.1 with
the relevant amendments, thanks in advance.
best regards
Konrad
Nick Pope wrote:
> Tommy - Seems OK for me
>
> Konrad, - Are you OK with this direction?
>
>
> Tommy - could you have a go a revising the wording of Konrad's
> submission to incororate what is proposed.
>
> Nick
>
> -----Original Message-----
> *From:* Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
> *Sent:* 26 January 2006 23:05
> *To:* Nick Pope
> *Cc:* OASIS DSS TC
> *Subject:* [Norton AntiSpam] Re: Re: FW: [dss]: A first quick Shot at
> section 4.4 and section 4.6.1
>
> > I am not sure about "untrusted key". I would expect that this would
> be invalid.
>
> Sounds right.
>
> > What about "indetermined check optional input". ...
> My previous argument for
> urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults
> implies that
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs
> goes.
>
> >My understanding is that the resulkts of checking the manifest
> validation should not effect the
> >MinorResult.
>
> That's my view.
>
> Regards,
> Tommy
>
> On 1/26/06, *Nick Pope* <pope@secstan.com <mailto: pope@secstan.com>>
> wrote:
>
> I am not sure about "untrusted key". I would expect that this
> would be invalid.
>
> Perhaps your suggestion of Valid, invalid and other errors.
>
> What about "indetermined check optional input". I am not sure
> that this is needed. Any optional inputs should be checked
> anyway. My understanding is that the resulkts of checking the
> manifest validation should not effect the MinorResult.
>
> Nick
>
> -----Original Message-----
> *From:* Tommy Lindberg [mailto: tommy.lindberg@gmail.com
> <mailto:tommy.lindberg@gmail.com>]
> *Sent:* 26 January 2006 10:48
> *To:* Nick Pope
> *Cc:* OASIS DSS TC
> *Subject:* [Norton AntiSpam] Re: FW: [dss]: A first quick Shot
> at section 4.4 and section 4.6.1
>
> Hi Nick -
>
> If I understand you correctly you want to rename:
>
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:untrustedKey
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:referencedDocumentNotPresent
>
>
> to
>
> urn:oasis:names:tc:dss:1.0:resultminor:indeterminate:indeterminateKey
> urn:oasis:names:tc:dss:1.0:resultminor:indeterminate:untrustedKey
> urn:oasis:names:tc:dss: 1.0:resultminor:indeterminate:referencedDocumentNotPresent
>
>
> What I thought the values in question could be moved up in
> the hierarchy:
>
> urn:oasis:names:tc:dss: 1.0:resultminor:indeterminateKey
> urn:oasis:names:tc:dss:1.0:resultminor:untrustedKey
> urn:oasis:names:tc:dss:1.0:resultminor:referencedDocumentNotPresent
>
> and allowing another ResultMajor than
> urn:oasis:names:tc:dss:1.0:resultmajor:Success.
>
> a)
> urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
> urn:oasis:names:tc:dss:1.0:resultminor:referencedDocumentNotPresent
>
> b)
> urn:oasis:names:tc:dss:1.0:resultmajor:{Requestor,Responder}Error
> urn:oasis:names:tc:dss: 1.0:resultminor:indeterminateKey
>
> Maybe it is six of one and half a dozen of the other.
>
> Regards,
> Tommy
>
> On 1/25/06, *Nick Pope* <pope@secstan.com
> <mailto: pope@secstan.com>> wrote:
>
> Tommy,
>
> I agree that the content of ResultMessage has to be free
> text and that all we can do is provide guidance.
>
> I think that the use of a hierachy of values in the
> ResultMinor space is the way to go.
>
> Where we differ is the need for "indetermined" as well as
> valid and invalid as the first level. Without this branch
> how would you indicate that the server does not have
> sufficient information to evaluate whether the signature
> is valid or not, for example:
> a) The document in the signature references is not
> currently available? [that is in the core XML signature
> not in the manifest]
> b) The does not have the necessary information
> (certificates, revocation status) to decide if the
> siging key is valid.
>
> I recognise that for some signatures the server may always
> have the information necessary to decide valid / invalid,
> but this will not be true for all signature policies.
>
> I cannot understand without the "indeterminate"
> ResultMinor value the server can signal this situation.
> Perhaps you can explain
>
> Nick
>
>
>
>
> -----Original Message-----
> *From:* Tommy Lindberg
> [mailto:tommy.lindberg@gmail.com
> <mailto:tommy.lindberg@gmail.com>]
> *Sent:* 24 January 2006 23:30
> *To:* Nick Pope
> *Cc:* OASIS DSS TC
> *Subject:* Re: FW: [dss]: A first quick Shot at
> section 4.4 and section 4.6.1
>
> Nick, Konrad -
>
> ResultMessage appears to be for free text that ends up
> in a log file or an error dialog and I don't
> believe the spec should require specific text here. I
> propose the spec instead (strongly) encourages
> a precise problem description or diagnostic.
>
> As regards the <ResultMinor> value space; I still
> don't see the need for values starting with
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined.
>
> In the case of XMLSIG, my view is that a DSS service
> should only make statements about XMLSIG
> core validation. If Manifests were validated then this
> is indicated with
> urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults.
>
> >Another example is the absence of a referenced
> Document, in such a case
> >the signature also isn't determinable. However in such
> a case even the
> >core validity of the signature isn't determinable.
>
> I suggest that this is an erronous condition that
> should be flagged differently
> e.g. with a RequesterError.IncompleteRequest
> resultmajor/resultminor pair.
>
> In the case that the signature validation key cannot
> be determined I propose that this too is
> reported with a distinct resultmajor/resultminor value
> pair e.g.
> {Requester,Responder}Error.NoValidationKey depending
> on whether or not the policy
> expects/requires the validation key inband.
>
> Regards,
> Tommy
>
> On 1/23/06, *Nick Pope* <pope@secstan.com
> <mailto:pope@secstan.com>> wrote:
>
> All,
>
> Forwarding proposal from Konrad on handling of
> result codes & manifest
> validation base with response from myself, for
> discussion at today's DSS
> call.
>
> Nick
>
> > --- snip ---
> >
> > 4.4 Result Codes
> > Whether the signature succeeds or fails to
> verify, the server will
> > return the Success <ResultMajor> code.
> > The <ResultMinor> URI MUST be one of the
> following values, or some other
> > value defined by some profile of this specification.
> > The values listed below indicate whether the
> signature or timestamp is
> > valid, invalid or indetermined.
> >
> > urn:oasis:names:tc:dss:1.0:resultminor:valid
> > urn:oasis:names:tc:dss:1.0:resultminor:invalid
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined
> >
> > These Resultminor values can optionally be
> further qualified by the
> > optional output
> <ProcessingDetails>(<ValidationDetails>), if and
> only if
> > a client specified
> <ReturnProcessingDetails>(<ReturnValidationDetails>)
> > in the <VerifyRequest>/<OptionalInputs>.
> >
> > The <ResultMinor> also MAY be further qualified
> by a <ResultMessage> and
> > implementors are encouraged to do so.
> >
> > The following rules SHALL be followed to bind a
> certain scenario to a
> > <ResultMinor> and a <ResultMessage> as follows,
> their numberings give a
> > priority that shall be followed (1.1 = highest
> priority) to determine
> > the <ResultMinor>. If more than one Rule matches
> the <ResultMessage>s
> > SHALL be concatenated. This MAY be extended by
> optional inputs and
> > profiles, but extensions SHALL not contradict
> these rules.
> >
>
> For all the rules given below the ResultMessage
> SHOULD contain the given
> words or alternative words with the same meaning
> in the relevant language.
>
> > * Rule 1.1: The signature or timestamp is valid.
> Furthermore, the
> > signature or timestamp covers all of the input
> documents just as they
> > were passed in by the client.
> > <ResultMinor>: urn:oasis:names:tc:dss:
> 1.0:resultminor:valid
> > <ResultMessage>: "Valid signature all Documents
> > covered".
> >
> > * Rule 1.2: The signature or timestamp is valid.
> However, the signature
> > or timestamp does not cover all of the input
> documents that were passed
> > in by the client.
> > <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:valid
> > <ResultMessage>: "WARNING Valid signature, not
> > all Documents covered (referenced)".
>
> Suggest " .... not all documents reference in
> request are covered by
> signature"
>
> >
> > * Rule 2.1: The signature fails to verify,
> indicating that the message
> > was modified in transit, or that the signature
> was performed incorrectly.
> > <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:invalid
> > <ResultMessage>: "WARNING Invalid signature, at
> > least one covered document was modified".
>
> Suggested ".... at least one document covered by
> signature was modified."
> >
> > * Rule 2.2: The signature is performed by a key
> the server considers
> > suspect. For example, the signing key may have
> been revoked, or it may
> > be a different key from what the server is
> expecting the signer to use.
> > <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:invalid
> > <ResultMessage>: "WARNING Signature invalid, due
> > to an untrusted Key".
> >
> > * Rule 3.1: A <ds:Reference> element is present
> in the <ds:Signature>
> > containing a full URI, but the corresponding
> input document is not
> > present in the request.
> > <ResultMinor>:
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:in
> > determined
> > <ResultMessage>: "WARNING Valid signature, but a
> > required Documents is not available".
> >
>
> [Not convinced about need for
> ":xmldsigcore:indetermined", if we are to
> extend the result code tree I would suggest that
> we have an explicit result
> minor code.]
>
> > * Rule 3.2:. The server could not determine
> whether the signing key is
> > valid. For example, the server might not have
> been able to construct a
> > certificate path to the signing key.
> > <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined
> > <ResultMessage>: "WARNING Signature validity
> > indetermined, due to an indeterminate Key".
>
> [Following on from above, what is the distinction
> about this not being
> "xmldsigcore:indetermined"]
> >
> > --- snip ---
> >
> > The following scenario is probably better to be
> dealt with by issuing an
> > unsuccessful <ResultMajor>, but this needs
> further consideration:
> > * The signature or its contents are not
> appropriate in the current
> > context. For example, the signature may be
> associated with a signature
> > policy and semantics which the DSS server
> considers unsatisfactory.
>
> [I would say that the signature is invalid if it
> does not meet the
> requirements of the policy. I am not sure I
> understand what "not
> appropriate" or "unsatisfactory" means.]
>
> * Rule 4.1:. The signature does not meet the
> requirements of the policy in
> force for the signature being validated.
> <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:signaturepolicyerror
> <ResultMessage>: "WARNING Signature invalid,
> failed to meet requirements of
> signature policy"
> Note: It is recommended that additional words are
> added providing more
> details.
>
> >
> > --- snip ---
> > 4.6.1 Optional Input <VerifyManifests> and Output
> <VerifyManifestResults>
> > The presence of this element instructs the server
> to validate manifests
> > in an XML signature.
> > On encountering such a document in step 2 of
> basic processing, the
> > server shall repeat step 2 for all the
> <ds:Reference> elements within
> > the manifest. In accordance with [XMLSIG] section
> 5.1, DSS Manifest
> > validation does not affect a signature's core
> validation. The results of
> > verifying individual <ds:Reference>'s within a
> <ds:Manifest> are
> > returned in the <dss:VerifyManifestResults>
> optional output. For
> > example, a client supplies the optional input
> <VerifyManifests>, then
> > the returned <ResultMinor> is
> > urn:oasis:names:tc:dss:
> 1.0:resultminor:indetermined:xmldsigcore:(valid |
> > invalid | indetermined) (according to the XMLDSig
> core validity and the
> > rules above mutatis mutandis) and the optional output
> > <VerifyManifestResults> is to be returned
> indicating the status of the
> > manifest validation.
> >
> > 4.4.1 Result Codes for <VerifyManifest>
> > In the case of <VerifyManifest> being sent the
> rules above are extended
> > as follows:
> >
> > urn:oasis:names:tc:dss:
> 1.0:resultminor:indetermined:xmldsigcore:valid
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:invalid
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:in
> > determined
> >
> > The following rule SHALL amend the rules in
> section 4.4.
> >
> > ... A <ds:Reference> element is present in a
> <ds:Manifest> containing a
> > full URI, but the corresponding input document is
> not present in the
> > request and <VerifyManifest> optional input was
> given.
> > <ResultMinor>:
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:(valid
> |
> > invalid | indetermined) (according to the XMLDSig
> core validity and the
> > rules above mutatis mutandis)
>
> [I would keep anything about <verifyManifest> in
> 4.6.1. I don't follow the
> reason for this text for 4.4.1. A simple note
> regarding manifests would be
> sufficient.]
>
> Replace with:
>
> Note: The result code for core validation is not
> affected by the results of
> any manifest verification. See 4.6.1 for optional
> input and output for
> Verify Manifest.
>
> > ...
> > --- snip ---
> > .... we need some more text here
> >
> > best regards
> > Konrad
> >
> > Tommy Lindberg wrote:
> > > Hi Konrad -
> > >
> > > > Considering all values above, it has to be
> noted that the
> > <ResultMinor>
> > > > is not limited to core validity of XMLDsig
> signature verification even
> > > > not if resultminor would only take the values
> starting with 1.2.
> > >
> > > My current view on this (still) is that the DSS
> core validation
> > > processing should
> > > reflect the XMLSIG Core Validation requirements
> and that the
> > > ResultMinor value
> > > space should also reflect that. In other
> words, that there should be
> > > two values
> > > in the core related to signature validity:
> > >
> > > 1.2.1 urn:oasis:names:tc:dss:1.0:resultminor:valid
> > > 1.2.2
> urn:oasis:names:tc:dss:1.0:resultminor:invalid
> > >
> > > If a third one is required - one that draws the
> callers attention to
> > > the presence of
> > > manifest validation results - I propose that
> its value also reflects
> > > valid core-validation
> > > and additionally contains a hint that
> Manifest's were also validated.
> > > The caller can in
> > > this case consult the VerifyManifestResults for
> details on what
> > > References (in the Manifest)
> > > did and did not validate. Something like:
> > >
> > > 1.2.3
> urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults
> > >
> > > Personally, I don't think this third
> resultminor is necessarily
> > > required - if the caller specifies
> > > <VerifyManifests> in the request he knows to
> look out for manifest
> > > verification results.
> > >
> > > ProcessingDetails currently defines a Type
> attribute value:
> > >
> > > urn:oasis:names:tc:dss:1.0:detail:Manifest
> > >
> > > which according to the current text indicates
> "Whether the manifests
> > > in the XML signature verified correctly." It is
> probably of interest
> > > to provide {Valid,Invalid,Indeterminate}Detail
> at a per Reference
> > > basis so I propose modifying the text to:
> "Whether a manifest
> > > reference in the XML signature verified
> correctly."
> > >
> > > I don't mind renaming ProcessingDetails to
> ValidationDetails but I
> > > think it should remain optional and that
> <ReturnProcessingDetails> in
> > > that case should stay and become
> <ReturnValidationDetails>.
> > >
> > > Regards,
> > > Tommy
> > >
> > > On 12/9/05, *Konrad Lanz*
> <Konrad.Lanz@labs.cio.gv.at
> <mailto:Konrad.Lanz@labs.cio.gv.at>
> > > <mailto: Konrad.Lanz@labs.cio.gv.at
> <mailto:Konrad.Lanz@labs.cio.gv.at>>> wrote:
> > >
> > > Dear Tommy and all,
> > >
> > > The status quo (committee draft 3)
> concerning the <Result> element
> > > returned in a <SignResponse> or
> <VerifyResponse> is as follows:
> > >
> > > The <Result>/<ResultMajor> indicates
> whether processing was
> > a success
> > >
> (urn:oasis:names:tc:dss:1.0:resultmajor:Success)
> and the server
> > > was able
> > > to return a response that either carries a
> signature in a
> > > <SignResponse>
> > > or a statement about the validity of a
> signature (timestamp).
> > > If processing was not successful the server
> responds with a
> > >
> (urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError)
> if it could
> > > determine that the processing error
> occurred due to a malformed
> > > request
> > > or inconsistent data sent by the client
> otherwise a ResponderError
> > >
> (urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError)
> is returned
> > > assuming that the failure was caused by the
> server.
> > >
> > > The <Result>/<ResultMinor> currently offers
> a set of values for 1.
> > > successful processing and 2. erroneous
> processing. (I numbered
> > > them to
> > > ease the discussion. Profile editors are
> welcome to
> > contribute further
> > > <ResultMinor> values as this will enable a
> broader view on
> > the issue).
> > > 1. can be further divided in sign (1.1) and
> verify (1.2) specific
> > > <ResultMinor> values however there are
> currently none for the sign
> > > request. 1.2 can be divided in valid
> signature/timestamp (1.2.1)
> > > responses, invalid signature/timestamp
> (1.2.2) responses and
> > > indeterminable signature ( 1.2.3) responses.
> > >
> > > 1.2.1.1 <http://1.2.1.1> < http://1.2.1.1>
> > >
> urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures
> > > 1.2.1.2 <http://1.2.1.2> < http://1.2.1.2>
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
> > > 1.2.1.3 <http://1.2.1.3> < http://1.2.1.3>
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransform
> > edDocuments
> > > 1.2.1.4 <http://1.2.1.4> < http://1.2.1.4
> <http://1.2.1.4>>
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocum
> > entsReferenced
> > >
> > >
> > > 1.2.2.1 <http://1.2.2.1> < http://1.2.2.1>
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
> > > 1.2.2.2 <http://1.2.2.2> < http://1.2.2.2>
> > >
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
> > > 1.2.2.3 <http://1.2.2.3> < http://1.2.2.3>
> > > urn:oasis:names:tc:dss:
> 1.0:resultminor:invalid:untrustedKey
> > > 1.2.2.4 <http://1.2.2.4> < http://1.2.2.4>
> > >
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
>
> > > 1.2.2.5 <http://1.2.2.5> < http://1.2.2.5>
> > >
> urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature
> > >
> > > 1.2.3
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs
> > >
> > > 2.1
> urn:oasis:names:tc:dss:1.0:resultminor:NotAuthorized
> > > 2.2 urn:oasis:names:tc:dss:
> 1.0:resultminor:NotSupported
> > > 2.3
> urn:oasis:names:tc:dss:1.0:resultminor:NotParseableXMLDocument
> > > 2.4
> urn:oasis:names:tc:dss:1.0:resultminor:XMLDocumentNotValid
> > > 2.5 urn:oasis:names:tc:dss:
> 1.0:resultminor:XPathEvaluationError
> > > 2.6
> urn:oasis:names:tc:dss:1.0:resultminor:MoreThanOneRefUriOmitted
> > >
> > > 1.2.3 The introduction of 1.2.3 became
> necessary as
> > <ds:Manifest> (cf.
> > >
> http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest
> > >
> <http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest
> <http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest>>
> and
> > >
> http://www.w3.org/TR/xmldsig-core/#sec-Manifest)
> > > <
> http://www.w3.org/TR/xmldsig-core/#sec-Manifest%29>
> mandates that
> > > applications may reserve reference
> validation decision logic to
> > > themselves.
> > > In our case this means that only clients
> will be able to decide upon
> > > validity themselves, based on the
> information given in
> > > <VerifyManifestsResults>. Note that this is
> only relevant if the
> > > optional input <VerifyManifests> was sent
> as and <ds:Manifest> are
> > > treated as normal documents otherwise.
> > >
> > > Considering all values above it has to be
> noted that the
> > <ResultMinor>
> > > is not limited to core validity of XMLDsig
> signature
> > verification even
> > > not if resultminor would only take the
> values starting with 1.2.
> > >
> > > There is a need to discuss the relations
> between <ResultMinor>,
> > > <ProcessingDetails> and
> <VerifyManifestsResults>.
> > >
> > > My feeling is that a lot of things dealt
> with in <ResultMinor>
> > > should be
> > > rather in <ProcessingDetails>. I also think
> that <ProcessingDetails>
> > > should be rather called <ValidationDetails>
> as it seems that would
> > > reflect what they really are. And
> <VerifyManifestResults> should be
> > > merged into it.
> > >
> > > So we could and should limit <ResultMinor> to
> > >
> > > 1.2.1
> urn:oasis:names:tc:dss:1.0:resultminor:valid
> > > 1.2.2
> urn:oasis:names:tc:dss:1.0:resultminor:invalid
> > > 1.2.3
> > > urn:oasis:names:tc:dss:
> > >
> 1.0:resultminor:indetermined:checkOptionalOutputs
> > >
> > > and leave values 2.1 - 2.6 as they are.
> > >
> > > The only and probably more sensible
> alternative would be to
> > > abandon the
> > > values starting with 1 and to limit
> <ResultMinor> to add more
> > > verbosity
> > > to unsuccessful processing. On the other
> hand we should elaborate
> > > <ValidationDetails> (<ProcessingDetails>)
> to a compulsory output
> > > element
> > > for <VerifyRequst> and model the validation
> verbosity level inside
> > > <ValidationDetails>.
> > >
> > > To conclude, I think the introduction of
> more <ResultMinor> values
> > > will
> > > cause that we leave the route of designing
> an xml protocol and we
> > > would
> > > start to model structure inside URNs.
> > >
> > > best regards
> > > Konrad
> > >
> > > This mail is related to Action [05-11-28-04]
> > >
> > > P.S.: I think I mentioned previously
> already that 1.2.1.3 <http://1.2.1.3>
> > > <http://1.2.1.3>
> > >
> > urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransform
>
> > edDocuments
> > >
> > > should be abandoned because the client does
> not specify transforms
> > > on a
> > > verify request and a server only performs
> the transforms inside
> > > <ds:Reference>/<ds:Transforms>.
> > >
> > >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave
> the OASIS TC that
> generates this mail. You may a link to this group
> and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]