xades4j: как создать подпись с преобразованием в справочнике по подписанным свойствам

Я получил пример подписи xades, которую мне нужно воспроизвести с помощью xades4j («как шаблон»).

Пример подписи такой (отрывок):

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-qualifyingproperties-yada-yada">
    <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <ds:Reference URI="#xmldsig-signedproperties-yada-yada">
            <ds:Transforms>
                <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue>yada-yada-yada-yada-yada-yada-yada</ds:DigestValue>
        </ds:Reference>
(...)

Я знаю, что эта ссылка не совместима с xades, потому что там нет атрибута Type.

Моя проблема связана с преобразованием в этой ссылке. Я не могу найти, как установить этот параметр с помощью xades4j. Можно ли это сделать?

Кроме того, я не знаю, имеет ли это здесь смысл, потому что в верхней части подписи говорится, что метод канонизации один, а в ссылке на подписанные свойства говорится, что метод канонизации другой... Я правильно это читаю?


xml-dsig xades4j
person brun0sa    schedule 11.09.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы не можете задавать преобразования для ссылки на подписанные свойства. Это мотивировано обоими:

  1. неуверенность в необходимости - подписываемый ресурс (фактический элемент подписанных свойств) фактически генерируется xades4j, поэтому не имеет особого смысла разрешать внешнее управление.
  2. безопасность — произвольные преобразования не могут быть разрешены, потому что библиотека должна быть уверена, что ссылка указывает на элемент SignedProperties.

Вероятно, единственное преобразование, которое можно было бы использовать, — это канонизация, но XML-DSIG уже указывает, что если разыменованный ресурс является набором узлов, он должен быть канонизирован перед дайджестом с использованием C14N в качестве алгоритма по умолчанию, который будет использовать xades4j/santuario. В вашем примере алгоритм такой же, с той разницей, что он включает ноды комментариев при генерации дайджеста.

Что касается наличия двух алгоритмов канонизации, то это потому, что они разные: тот, что используется в преобразованиях ссылки, применяется к результату разыменования этого объекта данных. с другой стороны, тот, что вверху, указывает алгоритм канонизации, который используется в элементе SignedInfo для получения фактических входных данных подписи (поток октетов).

person lgoncalves    schedule 11.09.2014
comment
Полностью согласен со вторым пунктом. Также с первым с точки зрения производителя. Но если я верификатор, то (очевидно) хочет проверить подпись, имеющую преобразование канонизации в ссылке signedProperties. Должен ли я учитывать преобразование или нет? Лично я бы предпочел не использовать преобразование в этой ссылке и использовать указанное значение по умолчанию для простоты и ясности. Но я должен играть с тем, что они мне дают... - person brun0sa; 12.09.2014
comment
Хорошо, если трансформация есть, xades4j будет использовать ее при обработке ссылки. Что вы можете сделать, так это проанализировать объекты данных на выходе проверки и проверить, есть ли какое-либо преобразование, которое вы считаете небезопасным. Типа белый список. - person lgoncalves; 12.09.2014
comment
Это может быть глупый вопрос, но... Вы сказали, что алгоритм канонизации тот же, но с включенными комментариями. В примере это xml-exc-c14n и REC-xml-c14n-20010315 (без учета комментариев). Это то же самое? - person brun0sa; 01.10.2014
comment
Я имел в виду, что REC-xml-c14n-20010315#withComments — это то же самое, что и XML-DSIG по умолчанию (REC-xml-c14n-20010315), но с комментариями. - person lgoncalves; 07.10.2014