[xmlsec] Manifest References

[Aleksey Sanin]

I am not 100% sure I understand your question. If you are asking
if an invalid Reference URI inside Manifest should generate an
error or not, then I don't think it is covered by the spec.
I can see it both ways.

Aleksey

On 6/4/17 4:03 AM, Dan Seguin wrote:
> Thanks for the considered reply. (And thank you for maintaining this
> excellent code base and resource).
> 
> My question was if processing an unsupported URI within a Reference
> block inside of a Object/Manifest block is considered a valid error
> within the Processing Rules
> <https://www.w3.org/TR/xmldsig-core/#sec-Processing>.   
> 
> Why are any References being processed in a Object/Manifest block? Any
> failure is acceptable, hence the Manifest block for pre- or pos-
> processing of applications. (Yes?)
> 
>> 2) Separately, the Object element (m09) is processed and digests are > calculated/validated but this does not impact the signature > validation.
> 
> It seems that References in Object/Manifest should not cause a halt in
> xmlsec processing, even when well formed, and that might include
> unsupported (to libxml2) URIs. 
> 
> Thoughts?
> 
> Dan
> 
> On 2017-06-02 12:28 PM, Aleksey Sanin wrote:
>> Let me try to explain using the example from the spec > (https://www.w3.org/TR/xmldsig-core/#sec-o-Manifest): > > [   ] ...
> [m01]   <Reference URI="#MyFirstManifest" [m02] >
> Type="http://www.w3.org/2000/09/xmldsig#Manifest"> [m03] > <Transforms>
> [m04]       <Transform >
> Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [m05] > </Transforms>
> [m06]     <DigestMethod >
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [m07] >
> <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=</DigestValue> [m08] >
> </Reference> [   ] ... [m09] <Object> [m10]   <Manifest >
> Id="MyFirstManifest"> [m11]     <Reference> [m12]     ... [m13] >
> </Reference> [m14]     <Reference> [m15]     ... [m16] > </Reference>
> [m17]   </Manifest> [m18] </Object> > > > What is happening here is the
> following: > > 1) The Reference element (m01) refers to the same
> document and the > digest is calculated/validated against the Manifest
> node (m10) > according to the usual XMLDsig rules. The signature
> validation fails > if there is a digest mismatch. > > 2) Separately, the
> Object element (m09) is processed and digests are > calculated/validated
> but this does not impact the signature > validation. The xmlsec library
> returns the status of the validation > in
> xmlSecDSigCtx::manifestReferences list. > > In the code,
> xmlSecDSigReferenceCtxProcessNode() fails with an error > only if there
> is a real processing error (e.g. malformed Reference > object). The
> digest mismatch results in  dsigRefCtx->status to be > set to
> xmlSecDSigStatusInvalid. The > xmlSecDSigCtxProcessManifestNode() DOES
> NOT check dsigRefCtx->status > (in comparison
> xmlSecDSigCtxProcessReferences() DOES and fails if it > is not
> xmlSecDSigStatusSucceeded). > > There are tests for this (e.g. >
> tests/merlin-xmldsig-twenty-three/signature.xml). > > > Best, Aleksey >
>> > > > Aleksey > > On 6/2/17 2:22 AM, Dan Seguin wrote: >> Greetings,
>>> >> I have a question about signing and validating Signatures where >>
> Manifest blocks are present. >> >> My understanding (if correct) from
> the XMLDSIG spec is that >> References within Manifest blocks can fail
> the digest operation or >> de-referencing of an URI, and not be
> considered a failure for >> signing or validation. >> >> In cases where
> the Manifest block is Reference'd from a SignedInfo >> Reference, the
> whole block is digested (with whatever is in there) >> whether or not
> the digesting occurred on the internal Manifest >> Reference entries. >>
>>> I'm seeing that xmlsec functions throw an error that halts the >>
> signing or verification if the References inside a Manifest block >>
> can't be processed. >> >> Is this correct? >> >> From xmldsig.c,
> function xmlSecDSigCtxProcessManifestNode, there is >> this snippet: >>
>>>> /* calculate references */ cur = >>>
> xmlSecGetNextElementNode(node->children); while((cur != NULL) && >>>
> (xmlSecCheckNodeName(cur, xmlSecNodeReference, xmlSecDSigNs))) { >>> /*
> create reference */ dsigRefCtx = >>>
> xmlSecDSigReferenceCtxCreate(dsigCtx, >>>
> xmlSecDSigReferenceOriginManifest); if(dsigRefCtx == NULL) { >>>
> xmlSecError(XMLSEC_ERRORS_HERE, NULL, >>>
> "xmlSecDSigReferenceCtxCreate", XMLSEC_ERRORS_R_XMLSEC_FAILED, >>>
> XMLSEC_ERRORS_NO_MESSAGE); return(-1); } >>> >>> /* add to the list */
> ret = >>> xmlSecPtrListAdd(&(dsigCtx->manifestReferences), dsigRefCtx);
>>>> if(ret < 0) { xmlSecError(XMLSEC_ERRORS_HERE, NULL, >>>
> "xmlSecPtrListAdd", XMLSEC_ERRORS_R_XMLSEC_FAILED, >>>
> XMLSEC_ERRORS_NO_MESSAGE); >>>
> xmlSecDSigReferenceCtxDestroy(dsigRefCtx); return(-1); } >>> >>> /*
> process */ ret = xmlSecDSigReferenceCtxProcessNode(dsigRefCtx, >>> cur);
> if(ret < 0) { xmlSecError(XMLSEC_ERRORS_HERE, NULL, >>>
> "xmlSecDSigReferenceCtxProcessNode", >>> XMLSEC_ERRORS_R_XMLSEC_FAILED,
> "node=%s", >>> xmlSecErrorsSafeString(xmlSecNodeGetName(cur)));
> return(-1); } >>> >>> /* we don;t care if Reference processing failed
> because * it's >>> Manifest node */ cur =
> xmlSecGetNextElementNode(cur->next); >> >> The call to
> xmlSecDSigReferenceCtxProcessNode exits >>
> xmlSecDSigCtxProcessManifestNode if there's a failure, sending the >>
> error upstream. >> >> For producing a Signature (from template) with a
> Manifest block >> (with pre-calculated Digest from an application and
> populated with >> an URI that is NOT processable) this isn't a problem
> if setting >> dsigCtx->flags |= XMLSEC_DSIG_FLAGS_IGNORE_MANIFESTS. >>
>>> However, for ingesting Signatures from external entities, Manifest >>
> blocks may have to be processed to verify (reference) digests >> before
> verifying signature. On failure, I'd assume that whatever >> digests are
> there are then used for signature validation. >> >> I would rather not
> use the IGNORE flag on validation. >> >> Guidance? >> >> Cheers. >> >>
>>> >> >> >> >> >> >> >> >>
> _______________________________________________ xmlsec mailing >> list
> xmlsec at aleksey.com >> http://www.aleksey.com/mailman/listinfo/xmlsec >> >