"ITU-T X.691（2021）：ASN.1 PER技术规范"

ASN.1

ITU-T

需积分: 9 46 浏览量更新于2024-01-31 收藏 1.02MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

ITU-T X.691（2021）技术规范是关于ASN.1 PER的一项标准，由国际电信联盟下属的ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY部门制定。该规范旨在规定ASN.1编码规则中的Packed Encoding Rules (PER)的具体标准，以便在数据网络、开放系统通信和安全领域中实现统一的数据交换和通信规范。 Abstract Syntax Notation One (ASN.1) 是一种用于描述数据结构和交换格式的标记语言，被广泛应用于通信协议、数据交换和接口定义等领域。而ITU-T X.691规范则专门规定了ASN.1编码规则中的Packed Encoding Rules (PER)，旨在为不同系统间的数据交换提供高效、可靠的编码规范。 ITU-T X.691规范的制定对于推动数据网络、开放系统通信和安全领域的发展具有重要意义。通过规范化数据交换的编码规则，可以实现不同系统之间的数据交互，促进通信协议的统一和标准化，提高了通信系统的互操作性和可靠性。而且，规范化的编码规则还有助于提高系统的性能和效率，减少了数据传输和解析过程中的不必要开销，提升了数据交换的速度和效率。除此之外，ITU-T X.691规范还为相关领域的技术人员、研发人员和工程师提供了一个统一的标准，使得他们在设计、开发和实施数据网络、开放系统通信和安全设施时能够遵循同一的规范和要求，从而降低了技术开发和实施过程的复杂性和风险，并有助于提高整体系统的质量和可靠性。总的来说，ITU-T X.691规范在推动数据网络、开放系统通信和安全领域的发展方面发挥了重要作用。它通过规范化ASN.1编码规则中的Packed Encoding Rules (PER)，为数据交换和通信提供了统一的标准和规范，从而提高了数据交换的效率、可靠性和安全性，促进了整个领域的发展和进步。ITU-T X.691标准的发布将有助于推动数据网络、开放系统通信和安全领域的技术创新和发展，为未来的通信领域带来更加便利和安全的通信环境。

资源详情

资源推荐

ISO/IEC 8825-2:2021 (E)

4 Rec. ITU-T X.691 (02/2021)

3.7.12 field-list: An ordered set of bit-fields that is produced as a result of applying these encoding rules to components

of an abstract value.

3.7.13 indefinite-length: An encoding whose length is greater than 64K-1 or whose maximum length cannot be

determined from the ASN.1 notation.

3.7.14 fixed-length type: A type such that the value of the outermost length determinant in an encoding of this type

can be determined (using the mechanisms specified in this Recommendation | International Standard) from the type

notation (after the application of PER-visible constraints only) and is the same for all possible values of the type.

3.7.15 fixed value: A value such that it can be determined (using the mechanisms specified in this Recommendation |

International Standard) that this is the only permitted value (after the application of PER-visible constraints only) of the

type governing it.

3.7.16 known-multiplier character string type: A restricted character string type where the number of octets in the

encoding is a known fixed multiple of the number of characters in the character string for all permitted character string

values. The known-multiplier character string types are IA5String, PrintableString, VisibleString,

NumericString, UniversalString and BMPString.

3.7.17 length determinant: A count (of bits, octets, characters, or components) determining the length of part or all

of a PER encoding.

3.7.18 normally small non-negative whole number: A part of an encoding which represents values of an unbounded

non-negative integer, but where small values are more likely to occur than large ones.

3.7.19 normally small length: A length encoding which represents values of an unbounded length, but where small

lengths are more likely to occur than large ones.

3.7.20 non-negative-binary-integer encoding: The encoding of a constrained or semi-constrained whole number into

either a bit-field of a specified length, or into a bit-field (octet-aligned in the ALIGNED variant) of a specified length, or

into the minimum number of octets that will accommodate that whole number encoded as a non-negative-binary-integer

which provides representations for whole numbers greater than or equal to zero, as specified in 11.3.

NOTE – The value of a non-negative-binary-number is derived by numbering the bits in the contents octets, starting with bit 1 of

the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2

, where

N is its position in the above numbering sequence. The value of the non-negative-binary-number is obtained by summing the

numerical values assigned to each bit for those bits which are set to one.

3.7.21 outermost type: An ASN.1 type whose encoding is included in a non-ASN.1 carrier or as the value of other

ASN.1 constructs (see 11.1.1).

NOTE – PER encodings of an outermost type are always an integral multiple of eight bits.

3.7.22 PER-visible constraint: An instance of use of the ASN.1 constraint notation which affects the PER encoding

of a value.

3.7.23 relay-safe encoding: A complete encoding of an abstract syntax value which can be decoded (including any

embedded encodings) without knowledge of the environment in which the encoding was performed.

3.7.24 semi-constrained whole number: A whole number which is constrained by PER-visible constraints to exceed

or equal some value "lb" with the value "lb" as a permitted value, and which is not a constrained whole number.

NOTE – Semi-constrained whole numbers occur in the encoding of the length of unconstrained (and in some cases constrained)

character, octet and bit string types, the count of the number of components in unconstrained (and in some cases constrained)

sequence-of and set-of types, and the value of an integer type that has been constrained to exceed some minimum value.

3.7.25 simple type: A type that is not a composite type.

3.7.26 textually dependent: A term used to identify the case where if some reference name is used in evaluating an

element set, the value of the element set is considered to be dependent on that reference name, regardless of whether the

actual set arithmetic being performed is such that the final value of the element set is independent of the actual element

set value assigned to the reference name.

NOTE – For example, the following definition of Foo is textually dependent on Bar even though Bar has no effect on Foos set of

values (thus, according to 10.3.6 the constraint on Foo is not PER-visible since Bar is constrained by a table constraint and Foo is

textually dependent on Bar).

MY-CLASS ::= CLASS { &name PrintableString, &age INTEGER } WITH SYNTAX{&name , &age}

MyObjectSet MY-CLASS ::= { {"Jack", 7} | {"Jill", 5} }

Bar ::= MY-CLASS.&age ({MyObjectSet})

Foo ::= INTEGER (Bar | 1..100)

3.7.27 unconstrained whole number: A whole number which is not constrained by PER-visible constraints.

NOTE – Unconstrained whole numbers occur only in the encoding of a value of the integer type.

ISO/IEC 8825-2:2021 (E)

Rec. ITU-T X.691 (02/2021) 5

4 Abbreviations

For the purposes of this Recommendation | International Standard, the following abbreviations apply:

ASN.1 Abstract Syntax Notation One

BER Basic Encoding Rules of ASN.1

CER Canonical Encoding Rules of ASN.1

DER Distinguished Encoding Rules of ASN.1

PER Packed Encoding Rules of ASN.1

16K 16384

32K 32768

48K 49152

64K 65536

5 Notation

This Recommendation | International Standard references the notation defined by Rec. ITU-T X.680 | ISO/IEC 8824-1.

6 Convention

6.1 This Recommendation | International Standard defines the value of each octet in an encoding by use of the terms

"most significant bit" and "least significant bit".

NOTE – Lower layer specifications use the same notation to define the order of bit transmission on a serial line, or the assignment

of bits to parallel channels.

6.2 For the purposes of this Recommendation | International Standard, the bits of an octet are numbered from 8

to 1, where bit 8 is the "most significant bit" and bit 1 the "least significant bit".

6.3 The term "octet" is frequently used in this Recommendation | International Standard to stand for "eight bits".

The use of this term in place of "eight bits" does not carry any implications of alignment. Where alignment is intended, it

is explicitly stated in this Recommendation | International Standard.

7 Encoding rules defined in this Recommendation | International Standard

7.1 This Recommendation | International Standard specifies four encoding rules (together with their associated

object identifiers) which can be used to encode and decode the values of an abstract syntax defined as the values of a

single (known) ASN.1 type. This clause describes their applicability and properties.

7.2 Without knowledge of the type of the value encoded, it is not possible to determine the structure of the encoding

(under any of the PER encoding rule algorithms). In particular, the end of the encoding cannot be determined from the

encoding itself without knowledge of the type being encoded.

7.3 PER encodings are always relay-safe provided the abstract values of the types EXTERNAL, EMBEDDED PDV and

CHARACTER STRING are constrained to prevent the carriage of OSI presentation context identifiers.

7.4 The most general encoding rule algorithm specified in this Recommendation | International Standard is

BASIC-PER, which does not in general produce a canonical encoding.

7.5 A second encoding rule algorithm specified in this Recommendation | International Standard is

CANONICAL-PER, which produces encodings that are canonical. This is defined as a restriction of implementation-

dependent choices in the BASIC-PER encoding.

NOTE 1 – CANONICAL-PER produces canonical encodings that have applications when authenticators need to be applied to

abstract values.

NOTE 2 – Any implementation conforming to CANONICAL-PER for encoding is conformant to BASIC-PER for encoding. Any

implementation conforming to BASIC-PER for decoding is conformant to CANONICAL-PER for decoding. Thus, encodings

made according to CANONICAL-PER are encodings that are permitted by BASIC-PER.

7.6 If a type encoded with BASIC-PER or CANONICAL-PER contains EMBEDDED PDV, CHARACTER STRING or

EXTERNAL types, then the outer encoding ceases to be relay-safe unless the transfer syntax used for all the EMBEDDED

PDV, CHARACTER STRING and EXTERNAL types is relay safe. If a type encoded with CANONICAL-PER contains

ISO/IEC 8825-2:2021 (E)

6 Rec. ITU-T X.691 (02/2021)

EMBEDDED PDV, EXTERNAL or CHARACTER STRING types, then the outer encoding ceases to be canonical unless the

transfer syntax used for all the EMBEDDED PDV, EXTERNAL and CHARACTER STRING types is canonical.

NOTE – The character transfer syntaxes supporting all character abstract syntaxes of the form {iso standard 10646

level-1(1) ....} are canonical. Those supporting {iso standard 10646 level-2(2) ....} and {iso

standard 10646 level-3(3) ....} are not always canonical. All the above character transfer syntaxes are relay-safe.

7.7 Both BASIC-PER and CANONICAL-PER come in two variants, the ALIGNED variant, and the UNALIGNED

variant. In the ALIGNED variant, padding bits are inserted from time to time to restore octet alignment. In the

UNALIGNED variant, no padding bits are ever inserted.

7.8 There are no interworking possibilities between the ALIGNED variant and the UNALIGNED variant.

7.9 PER encodings are self-delimiting only with knowledge of the type of the encoded value. Encodings are always

a multiple of eight bits. When carried in an EXTERNAL type they shall be carried in the OCTET STRING choice alternative,

unless the EXTERNAL type itself is encoded in PER, in which case the value may be encoded as a single ASN.1 type

(i.e., an open type). When carried in OSI presentation protocol, the "full encoding" (as defined in Rec. ITU-T X.226 |

ISO/IEC 8823-1) with the OCTET STRING choice alternative shall be used.

7.10 The rules of this Recommendation | International Standard apply to both algorithms and to both variants unless

otherwise stated (but see 9.2 and 9.3).

7.11 Annex C is informative, and gives recommendations on which combinations of PER to implement in order to

maximize the chances of interworking.

8 Conformance

8.1 Dynamic conformance is specified by clause 9 onwards.

8.2 Static conformance is specified by those standards which specify the application of these Packed Encoding

Rules.

NOTE – Annex C provides guidance on static conformance in relation to support for the two variants of the two encoding rule

algorithms. This guidance is designed to ensure interworking, while recognizing the benefits to some applications of encodings

that are neither relay-safe nor canonical.

8.3 The rules in this Recommendation | International Standard are specified in terms of an encoding procedure.

Implementations are not required to mirror the procedure specified, provided the bit string produced as the complete

encoding of an abstract syntax value is identical to one of those specified in this Recommendation | International Standard

for the applicable transfer syntax.

8.4 Implementations performing decoding are required to produce the abstract syntax value corresponding to any

received bit string which could be produced by a sender conforming to the encoding rules identified in the transfer syntax

associated with the material being decoded.

NOTE 1 – In general there are no alternative encodings defined for the BASIC-PER explicitly stated in this Recommendation |

International Standard. The BASIC-PER becomes canonical by specifying relay-safe operation and by restricting some of the

encoding options of other ISO/IEC Standards that are referenced. CANONICAL-PER provides an alternative to both the

Distinguished Encoding Rules and Canonical Encoding Rules (see Rec. ITU-T X.690 | ISO/IEC 8825-1) where a canonical and

relay-safe encoding is required.

NOTE 2 – When CANONICAL-PER is used to provide a canonical encoding, it is recommended that any resulting encrypted hash

value that is derived from it should have associated with it an algorithm identifier that identifies CANONICAL-PER as the

transformation from the abstract syntax value to an initial bitstring (which is then hashed).

9 PER encoding instructions

9.1 PER encoding instructions can be associated with a type in accordance with the provisions of Rec. ITU-T X.680

| ISO/IEC 8824-1 and Rec. ITU-T X.695 | ISO/IEC 8825-6.

NOTE 1 – The application of some PER encoding instructions can make it impossible to encode all the abstract values of the type.

Where this can arise, the specific PER encoding instruction identifies the problem. It is a designers decision, based on the possible

need to use multiple encoding rules, whether to add an explicit constraint on the type in order to restrict the range of abstract values

to those that can be handled by the encoding using the PER encoding instruction. This can make the specification less readable,

but ensures that all encoding rules can encode all allowed abstract values, making relaying possible without errors.

NOTE 2 – Each PER encoding instruction starts with an identifying keyword that unambiguously identifies that encoding

instruction.

9.2 If the ALIGNED version of either BASIC-PER or CANONICAL-PER is in use, then all PER encoding

instructions shall be silently ignored and have no affect on the encoding.

ISO/IEC 8825-2:2021 (E)

Rec. ITU-T X.691 (02/2021) 7

9.3 If the UNALIGNED version of either BASIC-PER or CANONICAL-PER is in use, then if a type has an

associated encoding instruction, the following subclauses shall apply.

9.3.1 If the identifying keyword is not known, then a "not supported" error message shall be issued.

9.3.2 If the identifying keyword is known, the procedures of this Recommendation | International Standard shall be

modified by the amendments to those procedures that are specified by the PER encoding instruction (see Rec.

ITU-T X.695 | ISO/IEC 8825-6).

NOTE 1 – If multiple PER encoding instructions are associated with a type, then the amendments specified for all of them shall be

applied.

NOTE 2 – It is an error in the register of PER encoding instructions if amendments produced by two or more separate encoding

instructions conflict and it is not stated that they are mutually exclusive.

10 The approach to encoding used for PER

10.1 Use of the type notation

10.1.1 These encoding rules make specific use of the ASN.1 type notation as specified in Rec. ITU-T X.680 |

ISO/IEC 8824-1, and can only be applied to encode the values of a single ASN.1 type specified using that notation.

10.1.2 In particular, but not exclusively, they are dependent on the following information being retained in the ASN.1

type and value model underlying the use of the notation:

a) the nesting of choice types within choice types;

b) the tags placed on the components in a set type, and on the alternatives in a choice type, and the values

given to an enumeration;

c) whether a set or sequence type component is optional or not;

d) whether a set or sequence type component has a DEFAULT value or not;

e) the restricted range of values of a type which arise through the application of PER-visible constraints

(only);

f) whether a component is an open type;

g) whether a type is extensible for PER encoding.

10.2 Use of tags to provide a canonical order

This Recommendation | International Standard requires components of a set type and a choice type to be canonically

ordered independent of the textual ordering of the components. The canonical order is determined by sorting the outermost

tag of each component, as specified in Rec. ITU-T X.680 | ISO/IEC 8824-1, 8.6.

10.3 PER-visible constraints

NOTE – The fact that some ASN.1 constraints may not be PER-visible for the purposes of encoding and decoding does not in any

way affect the use of such constraints in the handling of errors detected during decoding, nor does it imply that values violating

such constraints are allowed to be transmitted by a conforming sender. However, this Recommendation | International Standard

makes no use of such constraints in the specification of encodings.

10.3.1 Constraints that are expressed in human-readable text or in ASN.1 comment are not PER-visible.

10.3.2 Variable constraints are not PER-visible (see Rec. ITU-T X.683 | ISO/IEC 8824-4, 10.3 and 10.4).

10.3.3 User-defined constraints (see Rec. ITU-T X.682 | ISO/IEC 8824-3, 9.1) are not PER visible.

10.3.4 Table constraints are not PER-visible (see Rec. ITU-T X.682 | ISO/IEC 8824-3).

10.3.5 Component relation constraints (see Rec. ITU-T X.682 | ISO/IEC 8824-3, 10.7) are not PER-visible.

10.3.6 Constraints whose evaluation is textually dependent on a table constraint or a component relation constraint are

not PER-visible (see Rec. ITU-T X.682 | ISO/IEC 8824-3).

10.3.7 Constraints on restricted character string types which are not (see Rec. ITU-T X.680 | ISO/IEC 8824-1,

clause 41) known-multiplier character string types are not PER-visible (see 3.7.16).

10.3.8 Pattern constraints are not PER-visible.

10.3.9 Subject to the above, all size constraints are PER-visible.

剩余71页未读，继续阅读

poseidonwy001

粉丝: 0
资源: 6

会员权益专享

"ITU-T X.691（2021）：ASN.1 PER技术规范"

ITU-T X.691

ASN.1（抽象语法表示） 规范之X.691

X.691-ASN.1 encoding rules - Specification of Packed Encoding Rules (PER)

5g c-v2x.asn

python2-asn1crypto-0.23.0-2.el7.noarch: [errno 256] no more mirrors to try.

ASN.1 Editor在哪里下载

unable to load certificate 140175323400080:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1220: 140175323400080:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:386:Type=X509

JAVA怎么解决java.lang.ClassCastException: org.bouncycastle.asn1.DERApplicationSpecific cannot be cast to org.bouncycastle.asn1.ASN1Sequence

定义ASN.1模块的开始和结束分别是什么

pythran -e .\build\lib\pycrate_asn1dir\NRPPa.py -o nrppa.hpp时报错：CRITICAL:pythran:I am in trouble. Your input file does not seem to match Pythran's constraints... .\build\lib\pycrate_asn1dir\NRPPa.py: error: Module 'pycrate_asn1rt.utils' not found.

asn.1 rsa java_android - RSA公钥生成失败：“错误：0c0000be：ASN.1编码例程：OPENSSL_internal：WRONG_TAG” - 堆栈内存溢出...

openssl加密报错unable to load Private Key 1:error:0909006C:PEM routines:get_name:no start line:../../dist/crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY pkeyutl: Error initializing context

"Cobalt Strike Server Found C2: HTTP @ 45[.]79[.]66[.]231:8443 C2 Server: 45[.]79[.]66[.]231,/en_US/all[.]js Country: United States (AS63949) ASN: AKAMAI-AP Akamai Technologies, Inc."，这段话是twitter上一个安全博主发的一个推文，你能从这段话中提取出ioc吗？

关于Itext 报错-java.lang.NoClassDefFoundError: org/bouncycastle/asn1/ASN1Encodable

-----BEGIN RKRD.der----- MCAGCiqGSIb3DQEJGQMxEgQQFn6w5yeB5JQBEiM0RVZneA== -----END RKRD.der-----请使用openssl接口解码上述数据，并给出详细的代码解析出oid，nid和随机数167EB0E72781E4940112233445566778

那我本来要改的文件名是bad.asn1那改后是怎样的

java.lang.ClassCastException: org.bouncycastle.asn1.DERApplicationSpecific cannot be cast to org.bouncycastle.asn1.DERSequence

sm4 加密 报错-java.lang.NoClassDefFoundError: org/bouncycastle/asn1/ASN1Encodable

常见ASN.1 编码类型16进制表示

常见ASN.1 编码类型

会员权益专享

最新资源

ASN.1（抽象语法表示）规范之X.691

sm4 加密报错-java.lang.NoClassDefFoundError: org/bouncycastle/asn1/ASN1Encodable