2023-10-21 13:23:44 +02:00
|
|
|
-- SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
--
|
|
|
|
-- Copyright (C) 2008 IETF Trust and the persons identified as authors
|
|
|
|
-- of the code
|
|
|
|
--
|
2015-07-20 21:16:26 +01:00
|
|
|
-- X.509 AuthorityKeyIdentifier
|
|
|
|
-- rfc5280 section 4.2.1.1
|
|
|
|
|
|
|
|
AuthorityKeyIdentifier ::= SEQUENCE {
|
|
|
|
keyIdentifier [0] IMPLICIT KeyIdentifier OPTIONAL,
|
|
|
|
authorityCertIssuer [1] IMPLICIT GeneralNames OPTIONAL,
|
|
|
|
authorityCertSerialNumber [2] IMPLICIT CertificateSerialNumber OPTIONAL
|
|
|
|
}
|
|
|
|
|
|
|
|
KeyIdentifier ::= OCTET STRING ({ x509_akid_note_kid })
|
|
|
|
|
|
|
|
CertificateSerialNumber ::= INTEGER ({ x509_akid_note_serial })
|
|
|
|
|
|
|
|
GeneralNames ::= SEQUENCE OF GeneralName
|
|
|
|
|
|
|
|
GeneralName ::= CHOICE {
|
X.509: Add missing IMPLICIT annotations to AKID ASN.1 module
The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the
one in appendix A.2 uses IMPLICIT TAGS.
The kernel's simplified asn1_compiler.c always uses EXPLICIT TAGS, hence
definitions from appendix A.2 need to be annotated as IMPLICIT for the
compiler to generate RFC-compliant code.
In particular, GeneralName is defined in appendix A.2:
GeneralName ::= CHOICE {
otherName [0] OtherName,
...
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
...
}
Because appendix A.2 uses IMPLICIT TAGS, the IA5String tag (0x16) of a
dNSName is not rendered. Instead, the string directly succeeds the
[2] tag (0x82).
Likewise, the SEQUENCE tag (0x30) of an OtherName is not rendered.
Instead, only the constituents of the SEQUENCE are rendered: An OID tag
(0x06), a [0] tag (0xa0) and an ANY tag. That's three consecutive tags
instead of a single encompassing tag.
The situation is different for x400Address and directoryName choices:
They reference ORAddress and Name, which are defined in appendix A.1,
therefore use EXPLICIT TAGS.
The AKID ASN.1 module is missing several IMPLICIT annotations, hence
isn't RFC-compliant. In the unlikely event that an AKID contains other
elements beside a directoryName, users may see parse errors.
Add the missing annotations but do not tag this commit for stable as I
am not aware of any issue reports. Fixes are only eligible for stable
if they're "obviously correct" and with ASN.1 there's no such thing.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-09-26 11:46:41 +02:00
|
|
|
otherName [0] IMPLICIT OtherName,
|
|
|
|
rfc822Name [1] IMPLICIT IA5String,
|
|
|
|
dNSName [2] IMPLICIT IA5String,
|
2015-07-20 21:16:26 +01:00
|
|
|
x400Address [3] ANY,
|
|
|
|
directoryName [4] Name ({ x509_akid_note_name }),
|
X.509: Add missing IMPLICIT annotations to AKID ASN.1 module
The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the
one in appendix A.2 uses IMPLICIT TAGS.
The kernel's simplified asn1_compiler.c always uses EXPLICIT TAGS, hence
definitions from appendix A.2 need to be annotated as IMPLICIT for the
compiler to generate RFC-compliant code.
In particular, GeneralName is defined in appendix A.2:
GeneralName ::= CHOICE {
otherName [0] OtherName,
...
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
...
}
Because appendix A.2 uses IMPLICIT TAGS, the IA5String tag (0x16) of a
dNSName is not rendered. Instead, the string directly succeeds the
[2] tag (0x82).
Likewise, the SEQUENCE tag (0x30) of an OtherName is not rendered.
Instead, only the constituents of the SEQUENCE are rendered: An OID tag
(0x06), a [0] tag (0xa0) and an ANY tag. That's three consecutive tags
instead of a single encompassing tag.
The situation is different for x400Address and directoryName choices:
They reference ORAddress and Name, which are defined in appendix A.1,
therefore use EXPLICIT TAGS.
The AKID ASN.1 module is missing several IMPLICIT annotations, hence
isn't RFC-compliant. In the unlikely event that an AKID contains other
elements beside a directoryName, users may see parse errors.
Add the missing annotations but do not tag this commit for stable as I
am not aware of any issue reports. Fixes are only eligible for stable
if they're "obviously correct" and with ASN.1 there's no such thing.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-09-26 11:46:41 +02:00
|
|
|
ediPartyName [5] IMPLICIT EDIPartyName,
|
|
|
|
uniformResourceIdentifier [6] IMPLICIT IA5String,
|
|
|
|
iPAddress [7] IMPLICIT OCTET STRING,
|
|
|
|
registeredID [8] IMPLICIT OBJECT IDENTIFIER
|
2015-07-20 21:16:26 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
Name ::= SEQUENCE OF RelativeDistinguishedName
|
|
|
|
|
|
|
|
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
|
|
|
|
|
|
|
|
AttributeValueAssertion ::= SEQUENCE {
|
|
|
|
attributeType OBJECT IDENTIFIER ({ x509_note_OID }),
|
|
|
|
attributeValue ANY ({ x509_extract_name_segment })
|
|
|
|
}
|
X.509: Add missing IMPLICIT annotations to AKID ASN.1 module
The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the
one in appendix A.2 uses IMPLICIT TAGS.
The kernel's simplified asn1_compiler.c always uses EXPLICIT TAGS, hence
definitions from appendix A.2 need to be annotated as IMPLICIT for the
compiler to generate RFC-compliant code.
In particular, GeneralName is defined in appendix A.2:
GeneralName ::= CHOICE {
otherName [0] OtherName,
...
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
...
}
Because appendix A.2 uses IMPLICIT TAGS, the IA5String tag (0x16) of a
dNSName is not rendered. Instead, the string directly succeeds the
[2] tag (0x82).
Likewise, the SEQUENCE tag (0x30) of an OtherName is not rendered.
Instead, only the constituents of the SEQUENCE are rendered: An OID tag
(0x06), a [0] tag (0xa0) and an ANY tag. That's three consecutive tags
instead of a single encompassing tag.
The situation is different for x400Address and directoryName choices:
They reference ORAddress and Name, which are defined in appendix A.1,
therefore use EXPLICIT TAGS.
The AKID ASN.1 module is missing several IMPLICIT annotations, hence
isn't RFC-compliant. In the unlikely event that an AKID contains other
elements beside a directoryName, users may see parse errors.
Add the missing annotations but do not tag this commit for stable as I
am not aware of any issue reports. Fixes are only eligible for stable
if they're "obviously correct" and with ASN.1 there's no such thing.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-09-26 11:46:41 +02:00
|
|
|
|
|
|
|
OtherName ::= SEQUENCE {
|
|
|
|
type-id OBJECT IDENTIFIER,
|
|
|
|
value [0] ANY
|
|
|
|
}
|
|
|
|
|
|
|
|
EDIPartyName ::= SEQUENCE {
|
|
|
|
nameAssigner [0] ANY OPTIONAL,
|
|
|
|
partyName [1] ANY
|
|
|
|
}
|