Support custom XML element IDs

[LeonardoReino]

Hi!

The internal service of my country for electronic billing established a especific format for the values of the diferent attributes from the nodes. In especif, have to be generated 8 random integers between 1 and 100k, where their names are:

Certificate_number Signature_number SignedProperties_number SignedInfo_number SignedPropertiesID_number Reference_ID_number SignatureValue_number Object_number

and they are put into the sing like this example:

  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:etsi="http://uri.etsi.org/01903/v1.3.2#" Id="Signature" & Signature_number>
        <ds:SignedInfo Id="Signature-SignedInfo" & SignedInfo_number>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <ds:Reference Id="SignedPropertiesID" & SignedPropertiesID_number Type="http://uri.etsi.org/01903#SignedProperties" URI="#Signature" & Signature_number & "-SignedProperties">
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>**************************</ds:DigestValue>
            </ds:Reference>
            <ds:Reference URI="#Certificate" & Certificate_number>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>*************************</ds:DigestValue>
            </ds:Reference>
            <ds:Reference Id="Reference-ID-" & Reference_ID_number URI="#comprobante">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>**************************************</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue Id="SignatureValue" & SignatureValue_number>
           *************************************************************************
        </ds:SignatureValue>
        <ds:KeyInfo Id="Certificate" & Certificate_number>
            <ds:X509Data>
                <ds:X509Certificate>
                    ********************************************************************
                </ds:X509Certificate>
            </ds:X509Data>
            <ds:KeyValue>
                <ds:RSAKeyValue>
                    <ds:Modulus>
                        *******************************************************
                    </ds:Modulus>
                    <ds:Exponent>AQAB</ds:Exponent>
                </ds:RSAKeyValue>
            </ds:KeyValue>
        </ds:KeyInfo>
        <ds:Object Id="Signature" & Signature_number & "-Object" & Object_number>
            <etsi:QualifyingProperties Target="#Signature" & Signature_number>
                <etsi:SignedProperties Id="Signature" & Signature_number & "-SignedProperties" & SignedProperties_number>
                    <etsi:SignedSignatureProperties>
                        <etsi:SigningTime>2022-03-15T00:00:00-00:00</etsi:SigningTime>
                        <etsi:SigningCertificate>
                            <etsi:Cert>
                                <etsi:CertDigest>
                                    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                                    <ds:DigestValue>**************************</ds:DigestValue>
                                </etsi:CertDigest>
                                <etsi:IssuerSerial>
                                    <ds:X509IssuerName>**************************************************</ds:X509IssuerName>
                                    <ds:X509SerialNumber>**************************************************</ds:X509SerialNumber>
                                </etsi:IssuerSerial>
                            </etsi:Cert>
                        </etsi:SigningCertificate>
                    </etsi:SignedSignatureProperties>
                    <etsi:SignedDataObjectProperties>
                        <etsi:DataObjectFormat ObjectReference="#Reference-ID-" & Reference_ID_number>
                            <etsi:Description>contenido comprobante</etsi:Description>
                            <etsi:MimeType>text/xml</etsi:MimeType>
                        </etsi:DataObjectFormat>
                    </etsi:SignedDataObjectProperties>
                </etsi:SignedProperties>
            </etsi:QualifyingProperties>
        </ds:Object>
    </ds:Signature>

My first question is according to this issue, how can I change these attribute values?

And my last issue became when I see the third Reference child of SignedInfo, in Transform Algorithm I get "http://www.w3.org/TR/2001/REC-xml-c14n-20010315", when should be "http://www.w3.org/2000/09/xmldsig#enveloped-signature"

         <ds:Reference Id="xmldsig-d08580b3-bdfa-4868-afc6-69e56e30238c-ref0" URI="">
  ..............................................................  </ds:Reference>

<ds:Reference URI="#xmldsig-d08580b3-bdfa-4868-afc6-69e56e30238c-keyinfo">
............................................................................
            </ds:Reference>
            <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-d08580b3-bdfa-4868-afc6-69e56e30238c-signedprops">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>0MjQ0yhZii6L5l6t8bl2FokxeSI=</ds:DigestValue>
            </ds:Reference>

I dont know what parameter I'm forgetting to generate this Transform Algorithm.

My code is:

 KeyingDataProvider kp = FileSystemKeyStoreKeyingDataProvider
                .builder("pkcs12", "C:/Cert/mycert.pfx", SigningCertificateSelector.single())
                .storePassword(new DirectPasswordProvider("MyPass"))
                .entryPassword(new DirectPasswordProvider("MyPass"))
                .fullChain(true)
                .build();

        BasicSignatureOptions config = new BasicSignatureOptions();
        config.includePublicKey(true);
        config.includeSigningCertificate(SigningCertificateMode.SIGNING_CERTIFICATE);
        config.signKeyInfo(true);

        XadesSigner signer = new XadesBesSigningProfile(kp)
                .withBasicSignatureOptions(config)
                .withSignatureAlgorithms(new SignatureAlgorithms()
                        .withSignatureAlgorithm("RSA", ALGO_ID_SIGNATURE_RSA_SHA1)
                        .withDigestAlgorithmForReferenceProperties(ALGO_ID_DIGEST_SHA1) // CERT DIGEST con SHA1
                        .withDigestAlgorithmForDataObjectReferences(ALGO_ID_DIGEST_SHA1) //Tres REFERENCE child con SHA1

                )

                .newSigner();

        DataObjectFormatProperty obj2 = new DataObjectFormatProperty("text/xml");
        obj2.withDescription("contenido comprobante")
        ;

        DataObjectDesc obj = new DataObjectReference("")
                .withTransform(new EnvelopedSignatureTransform())
                .withDataObjectFormat(obj2)

                ;

        signer.sign(new SignedDataObjects(obj), documento.getDocumentElement());

I hope can you help me, thanks for your attention.

[luisgoncalves]

Hi,

Regarding the first question, about changing how IDs are generated, that's not supported. The library already generates unique IDs for all the elements. Are you sure that the official service requires that, or could it be from an example? It's a weird requirement.

As for the second question, the "enveloped signature" transform does not need to be used in the Reference covering SignedProperties, as this element is contained in the signature itself. It needs to be added to the main Reference (URI="") to exclude the signature itself from the verification, otherwise the input node set would be different between signature generation and verification.

[luisgoncalves]

Any comments?

[AndresN17]

Hi Leonardo and Luis, it seems that we have the same problem, I sort out changing the attributes manually like this:

NodeList nlist1 = doc.getElementsByTagName("ds:Signature");
Node node1 = nlist1.item(0);
 if (node1.getNodeType() == Node.ELEMENT_NODE) {
        Element element1 = (Element) node1;
        element1.setAttribute("Id", "Signature650221");
} 

But I have a doubt regarding the references, xades4j added the references in this order plus the Transform in every node:

<ds:Reference Id="Reference-ID-710529" URI="#comprobante">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>XOsCPUqZFf9hRrJBAel4GrtfrlM=</ds:DigestValue>
         </ds:Reference>
<ds:Reference URI="#Certificate146350">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>UcHaXo1js6VvbZctwRWkjfRyZWU=</ds:DigestValue>
</ds:Reference>
<ds:Reference Id="SignedPropertiesID840289" Type="http://uri.etsi.org/01903#SignedProperties" URI="#Signature482168-SignedProperties212516">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>1W0e9rJig6rub+M1b92SdlEaj+Q=</ds:DigestValue>
 </ds:Reference>

And in every example that I have the references are in this order and only one reference have the transform:

<ds:Reference Id="SignedPropertiesID840289" Type="http://uri.etsi.org/01903#SignedProperties" URI="#Signature482168-SignedProperties212516">
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
                <ds:DigestValue>206vj2Yzs4Vstq8fIV5NMxzDWZ4=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#Certificate1463504">
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
                <ds:DigestValue>iJ20AKGJWw+sx4tl4xjUfHZT8GE=</ds:DigestValue>
</ds:Reference>
 <ds:Reference Id="Reference-ID-710529" URI="#comprobante">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
                <ds:DigestValue>mvxOCvXBxztcFdr5XGMrJnQreuc=</ds:DigestValue>
 </ds:Reference>

I don't test yet if the order or the transform nodes are a problem with the validation in the SRI (internal rents service), but in that case there is a way to change it with xades4j? or I have to do it manually?

And one last thing, when xades4j sign the document it adds this expression 
 to every line of the content of the key, for example:

<ds:Modulus>4Mpvx9EMjNmHr6CVjWokW1T0G9y7dYFZ64gz/5FakFNrBnBjeAhub44U+KiYiAyqsneM7gLwPxcK&#13;
CzAJBgNVBAYTAkVDMRswGQYDVQQKExJTRUNVUklUWSBEQVRBIFMuQS4xMDAuBgNVBAsTJ0VOVElE&#13;
ix6Kar02Jgh249DPXMhPJAOAA90kzX1Otz+sneVaK0bsqGbAiu13X74bgj7f7aOncWZ85vKN1NWj&#13;
BgkqhkiG9n0HQQAEDDAKGwRWOC4xAwIDqDANBgkqhkiG9w0BAQsFAAOCAQEAJm4rV5HfMzng6gYD&#13;
qHZOuiZIhc6DsVlxK65H3NCEZ5aLc6quGwrdvQ==</ds:Modulus>

and it's the same with X509Certificate and SignatureValue, if you have any advice or idea I appreciate it and thanks for the information!

[luisgoncalves]

Element IDs

Are you sure that the verifier service imposes a structure on those? I've seen this question a couple of times, but nobody confirmed that. It's a really weird requirement, so I don't want to add support for customizing the IDs if it isn't really needed. Keep in mind that if you change the IDs of Reference elements after the signature is created, you'll break the signature value. xades4j tries its best to get you away from mangling with XML

Transforms

The order of the references doesn't matter. As for the C14N transform, the XML-DSIG reference processing model always adds an implicit canonicalization if the result of processing the reference + transforms is a node set. Being explicit shouldn't be an issue.

Base64 encoding

Isn't that just a new line or similar? Is it actually causing issues? Those XML elements are marshalled by Apache Santuario (used by xades4j), so there isn't much we can do.

[AndresN17]

Well I tested the signed xmls one with the Ids changed and other without and as you say if I change the Id's the signature turns invalid, reading the official requirements they don't explicit say that we have to change or have the ids like that, I think was a missunderstanding with the official example that the entity gave us and the developers of my country take that as granted and spreaded the information.

The example:

<ds:Signature xmlns:ds= ”http: www.w3.org 2000 09 xmldsig#” xmlns:etsi= ”http: uri.etsi.org 01903 v1.3.2#” Id= ”Signature620397”>
      <ds:SignedInfo Id= ”Signature-SignedInfo814463”>
         <ds:CanonicalizationMethod Algorithm= ”http: www.w3.org TR 2001 REC-xml-c14n-20010315”></ds:CanonicalizationMethod>
         <ds:SignatureMethod Algorithm= ”http: www.w3.org 2000 09 xmldsig#rsa-sha1”></ds:SignatureMethod>
         <ds:Reference Id= ”SignedPropertiesID157683” Type= ”http: uri.etsi.org 01903#SignedProperties” URI= ”#Signature620397-SignedProperties24123”>
            <ds:DigestMethod Algorithm= ”http: www.w3.org 2000 09 xmldsig#sha1”></ds:DigestMethod>
            <ds:DigestValue>
               <null
                  <etsi:SignedProperties> →
            </ds:DigestValue>
         </ds:Reference>
         <ds:Reference URI= ”#Certificate1562780”>
            <ds:DigestMethod Algorithm= ”http: www.w3.org 2000 09 xmldsig#sha1”></ds:DigestMethod>
            <ds:DigestValue>
               <null
            </ds:DigestValue>
         </ds:Reference>
         <ds:Reference Id= ”Reference-ID-363558” URI= ”#comprobante”>
            <ds:Transforms>
               <ds:Transform Algorithm= ”http: www.w3.org 2000 09 xmldsig#enveloped-signature”></ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm= ”http: www.w3.org 2000 09 xmldsig#sha1”></ds:DigestMethod>
            <ds:DigestValue>
               <null
            </ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue Id= ”SignatureValue398963”>
         <null
      </ds:SignatureValue>
      <ds:KeyInfo Id= ”Certificate1562780”>
         <ds:X509Data>
            <ds:X509Certificate>
               <null
            </ds:X509Certificate>
         </ds:X509Data>
         <ds:KeyValue>
            <ds:RSAKeyValue>
               <ds:Modulus>
                  <null
               </ds:Modulus>
               <ds:Exponent>AQAB</ds:Exponent>
            </ds:RSAKeyValue>
         </ds:KeyValue>
      </ds:KeyInfo>
      <ds:Object Id= ”Signature620397-Object231987”>
         <etsi:QualifyingProperties Target= ”#Signature620397”>
            <etsi:SignedProperties Id= ”Signature620397-SignedProperties24123”>
               <etsi:SignedSignatureProperties>
                  <etsi:SigningTime>2012-03-05T16:57:32-05:00</etsi:SigningTime>
                  <etsi:SigningCertificate>
                     <etsi:Cert>
                        <etsi:CertDigest>
                           <ds:DigestMethod Algorithm= ”http: www.w3.org 2000 09 xmldsig#sha1”></ds:DigestMethod>
                           <ds:DigestValue>
                              xUQewsj7MrjSfyMnhWz5DhQnWJM=
                              </d
                        </etsi:CertDigest>
                        <etsi:IssuerSerial>
                           <ds:X509IssuerName>CN=AC BANCO CENTRAL DEL
ECUADOR,L=QUITO,OU=ENTIDAD DE CERTIFICACION DE INFORMACION-ECIBCE,O=BANCO CENTRAL DEL
ECUADOR,C=EC</ds:X509IssuerName>
                           <ds:X509SerialNumber>1312833444</ds:X509SerialNumber>
                        </etsi:IssuerSerial>
                        </etsi:Cer
                  </etsi:SigningCertificate>
               </etsi:SignedSignatureProperties>
               <etsi:SignedDataObjectProperties>
                  <etsi:DataObjectFormat ObjectReference= ”#Reference-ID-363558”>
                     <etsi:Description>contenido
comprobante</etsi:Description>
                     <etsi:MimeType>text/xml</etsi:MimeType>
                  </etsi:DataObjectFormat>
                  </etsi:SignedDataObjectProperti
            </etsi:SignedProperties>
         </etsi:QualifyingProperties>
      </ds:Object>
   </ds:Signature>

The tool that I used to test the signature was this https://www.xolido.com/lang/ that is recommended by the authority of my country, I don't test yet with the official service but I will do it this week, to add more information the librarys that uses the SRI( the authority) are this https://github.com/gdiazs/MITyCLib , so if the creators of that libraries recommend to use xades4j I don't think that I'll have problems with the official service, if any problem pop ups I will add more information.

[luisgoncalves]

Closing due to inactivity. Reopen if needed.

[GuasaPlay]

Hello @AndresN17, did you manage to successfully implement the signature for the XML files and that they are valid for the SRI? I'm trying to do my implementation, but I have not succeeded, maybe you could help me with some suggestion or tip, I would be eternally grateful. 🙏

[xprl-gjf]

@LeonardoReino, @AndresN17, @GuasaPlay - I too am attempting to migrate an existing solution for SRI electronic facturas in Ecuador from MITyCLib to xades4j. Documents signed using the existing MITyCLib implementation are accepted and validated by SRI. My xades4j code is identical to the examples in this issue, but SRI rejects the documents:

{"mensaje":[{"identificador":"39","mensaje":"FIRMA INVALIDA","informacionAdicional":"La firma es invalida [Firma inválida. El certificado firmante no es válido.]","tipo":"ERROR"}]}

(documents are signed with the same certificate as was used with the previous MITyCLib implementation).

I haven't found a solution. I know SRI use MITyCLib to perform the validation; perhaps that library has some 'quirks' in validation that are not met when signing with xades4j.

My code is at sri-efactura-core #1.

It would be great to know if any of you have been able to solve this?

[hanadderia]

Element IDs

Are you sure that the verifier service imposes a structure on those? I've seen this question a couple of times, but nobody confirmed that. It's a really weird requirement, so I don't want to add support for customizing the IDs if it isn't really needed. Keep in mind that if you change the IDs of Reference elements after the signature is created, you'll break the signature value. xades4j tries its best to get you away from mangling with XML

Transforms

The order of the references doesn't matter. As for the C14N transform, the XML-DSIG reference processing model always adds an implicit canonicalization if the result of processing the reference + transforms is a node set. Being explicit shouldn't be an issue.

Base64 encoding

Isn't that just a new line or similar? Is it actually causing issues? Those XML elements are marshalled by Apache Santuario (used by xades4j), so there isn't much we can do.

Hello Luis,

Above is a screenshot of our vendor documentation. They explicitly require IDs to start with an underscore ("_") followed by a universally unique identifier. Additionally, they request the removal of IDs from the Signature and Signature Value elements.

[luisgoncalves]

@hanadderia are you sure this is validated by the vendor? The structure of the IDs is a detail that shouldn't matter. I can understand that the verifier wants to check that there is a Reference referencing KeyInfo and using Id references makes that simple. But I don't understand why the actual value of the Id would matter.

Support to customize Ids is something I'd prefer not adding to the library, because I don't see any value in it.

[hanadderia]

Thanks, @luisgoncalves, for your prompt response. You are correct; there is no value in pursuing this. It appears that our vendor is validating against the schema before verifying the actual signature.

Additionally, they are requiring us to remove the Id attribute from the following nodes:

• ds:Signature.
• ds:Reference.
• ds:SignatureValue.

I will follow up with them to address and hopefully resolve this issue.

[luisgoncalves]

@hanadderia great. Perhaps they can relax this requirement a bit, or they have some reasoning for it that I missed.

If really needed, I can try to think of a way to incorporate this in the library. Or perhaps you could fork the repo and change the code as needed for your use case. Get back to me here if it comes to that.

[micromange]

I have the exact same problem as hanadderia when it comes to the format of the id. We have a requirement specification that has this exact requirement but I also found this specification from the European Central Bank that also has it:

ESMIG UDFS

[luisgoncalves]

@micromange

You're referring to section 2.1.5 in that spec, correct? The text there is ver similar to what @hanadderia shared previously (it seems to be related to the same "message format" or similar).

As I mentioned before, this is a very weird requirement. Are you sure that the verifying system imposes this requirement? Also, are you sure that the spec you shared it up-to-date and still in use (the file you linked seems to be a diff or similar)?

This has come up a couple of times, but in some cases the requirement was actually just incorrectly extrapolated fromexamples, or people were able to work around it (e.g. @hanadderia didn't bring it up again, although a follow-up issue #288 was created to support not including the SigningCertificate property).

For me it's surprising that a spec - namely from EU entities - has such requirements, even more when some of those go against other XML signature specs, namely the XAdES Baseline profile (which recommends adding the SigningCertificate property).

Anyway, if this is coming up again and preventing people from using xades4j, I guess I'll have to do something about it. Looks like the safest option is to allow customizing any element ID that xades4j needs to use... I'm wondering if adding IDs in elements where they are not required is also causing issues.

Thoughts? @hanadderia what did you do about the IDs in the different elements? Do you have more inputs to this?

[hanadderia]

Hello @luisgoncalves,

The ID-related aspect wasn't originally part of the specification, but the vendor software is validating the message against the XSD schema, causing the request to fail, and leaving us without a workaround. As a result, we had to make manual changes after forking the repository.

[luisgoncalves]

Thanks for the input @hanadderia . So the vendor only allows ID in specific elements, namely KeyInfo and SignedProperties? I.e. in the elements that really need IDs according to the mentioned specification (so that they can be referenced from a Reference). Or are there other restrictions in that schema?

[micromange]

@luisgoncalves

"You're referring to section 2.1.5 in that spec, correct?" Yes, exactly.

Well, I think we all agree that it is a weird requirement but unfortunately we can not just ignore it and hope no one will notice that we do not follow it. When big players, in this case the European Central Bank, writes specifications their requirements has a tendency to spread and become "de-facto" standards regardless if they really makes sense or not.

It think it should be easy to add settings where you can set your own prefixes and suffixes to the id:s in xades4j since they already have the UUID part.

[luisgoncalves]

Yeah, I agree @micromange . I wasn't aware of the ECB specification until you brought it up, which is when I changed my mind.

I'm re-opening this issue to add a way to customize the element IDs. I'm not what do to about the presence of IDs in elements that don't strictly require them. This seems to have been an issue in some cases, but I need to see the impact on the implementation. IIRC, xades4j adds IDs upfront for some elements - namely References - so that code that may need to point to those later doesn't have to worry about IDs...

Was this also an issue in your case?

[micromange]

Well we have not got that far yet but we have also evaluated to use esig/dss and it does not support this either and for them it is even harder to support this since they generate a deterministic base id first and then just add prefixes to it (keyinfo-, id-,...) which means that you always know what to use in the references.

Which makes perfect sense of course if these kinds of requirements would not have existed.

[luisgoncalves]

I see. I'll try to find some time soon to work on the custom IDs part to start with, and put up a branch that you can use to test it.

[luisgoncalves]

@micromange / @hanadderia

I've pushed the iss259-custom-element-ids branch with a first version of support for custom element IDs. It can be configured in the signing profile:

.withElementIdGenerator(ElementIdGeneratorFactory.uuid("_", null))

It still needs some tweaks, but it should support your scenario. Can you build from that branch and give it a try, please?

[micromange]

@luisgoncalves I've tried it now and it works like a charm. Nicely done and thank you for listening.

[luisgoncalves]

Great @micromange . I'll merge that soon.

@hanadderia I also looked into only adding ID attributes when needed, namely to References and SignatureValue. In some cases they must be added, e.g. when CounterSignature property is used then the SignatureValue of the counter-signed signature must be referenced, and the simplest way to do that is by using an ID reference. But they can be added lazily/on-demand.

I think I'll be able to do that, except for the Signature element, because the ID is needed for the Target attribute of QualifyingProperties. From XAdES 1.4.1 section 6.2:

The mandatory Target attribute MUST refer to the Id attribute of the corresponding ds:Signature. Its value MUST be an URI with a bare-name XPointer fragment.

Since xades4j currently always adds QualifyingProperties, Signature needs to have an ID.

[luisgoncalves]

Also implemented lazy addition of element IDs (Reference, SignatureValue, Object)

[hanadderia]

Thanks @luisgoncalves.