DER кодиране - Как да конвертирате имплицитния етикет в явен етикет

Имам сертификат X.509, който съдържа набор от данни със следния таг IMPLICIT [0]:

A0 81 C6 (value)...

И имам този откъс от стандартен документ:

Тагът IMPLICIT [0] не се използва за DER кодиране, а по-скоро се използва таг EXPLICIT SET OF. Това означава, че DER кодирането на етикета EXPLICIT SET OF, а не на етикета IMPLICIT [0], ТРЯБВА да бъде включено заедно с октетите за дължина и съдържание на стойността.

Търсих много наоколо, но не мога да разбера какво точно изисква стандартът. Търся малко пояснение.

РЕДАКТИРАНЕ: Ето стандарта, който следвам: http://tools.ietf.org/html/rfc3852

Опитвам се да проверя подписа X.509 и трябва да изчисля дайджеста на съобщението, за да направя това. Този сертификат включва незадължителните SignedAttributes в типа SignerInfo. Хеширах подписаното съдържание и проверих, че дайджестът на съобщението в SignedAttributes е правилен. Стандартът казва, че ако SignedAttributes присъства, той трябва да бъде хеширан и криптиран, за да се създаде подпис на сертификата. Стандартът също така казва, че етикетът на SignedAttributes трябва да бъде променен, както е обсъдено в първоначалния въпрос.

Ето граматиката Asn.1 за SignerInfo:

SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

encryption tags encoding x509 cryptography
person Ben    schedule 03.09.2010    source източник
comment
В конкретно разширение ли е?   -  person Bruno    schedule 03.09.2010
comment
Полето SignedAttributes на SignerInfo. Ето стандарта, който следвам - tools.ietf.org/html/rfc3852#section- 5.4 Така че се опитвам да проверя подписа на този X.509 сертификат и трябва да получа данните, които са подписани от сертификата. Този сертификат включва незадължителното поле SignedAttributes и според стандарта цялото това поле (таг, дължина и стойност) се хешира и криптира, за да се създаде подписът. Но когато се опитам да проверя подписа с тази стойност, това не успява. Мисля, че трябва да променя етикета по някакъв начин.   -  person Ben    schedule 03.09.2010

Отговори (1)


arrow_upward
8
arrow_downward

Не съм сигурен как да тълкувам този коментар. Какъв стандарт четеш? Имате ли граматиката на ASN.1 за структурата?

Явният таг е като обвивка около някакъв основен тип. Например основният тип може да е SEQUENCE. Той е кодиран с универсалния таг SEQUENCE, 0x30. Но за да се избегне неяснота в начина, по който SEQUENCE трябва да се интерпретира в обхващащата структура, тя е обвита в EXPLICIT структура със специфичен за контекста таг. От фрагмента по-горе не става ясно какво представлява този етикет.

Предполагам, че това, което имат предвид, е синтаксис като [0] EXPLICIT SET OF foo, който (използвайки примера от първоначалния въпрос като стойност) ще бъде кодиран като (hex) A0 81 C9 31 81 C6 (value) ...

Обърнете внимание, че оригиналната стойност, която е била маркирана със специфична за контекста нула (A0), е била повторно маркирана с универсален SET OF (31).

Добре, в този случай мисля, че това, което имат предвид е, че когато подписвате атрибутите, вместо да използвате неявния таг, подписът се изчислява върху тага SET OF. Ако това имат предвид, добавянето на „ИЗРИЧНО“ наистина размъти водите, но каквото и да е. Ако случаят е такъв, тогава кодирането ще бъде просто 31 81 C6 (value) ... (заменете специфичния за контекста 0xA0 с универсален SET OF 0x31).

person erickson    schedule 03.09.2010
comment
Редактирано, за да отговори на някои от вашите въпроси. Ще опитам вашето предложение, благодаря. - person Ben; 03.09.2010
comment
@Ben - вижте моята актуализация. Мисля, че първото ми предположение беше извън базата. - person erickson; 03.09.2010
comment
смяната на A0 на 31 беше първата ми мисъл. Опитах това и не можах да накарам проверката да премине. Мисля, че промяната на A0 на 31 е правилна, тъй като има логичен смисъл, така че може да имам различен проблем. - person Ben; 03.09.2010
comment
Преодолях куп други проблеми и разбрах, че A0 до 31 е правилен. - person Ben; 23.09.2010