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 <[email protected]>
---
Found this while bringing up PCI device authentication, which involves
validating the Subject Alternative Name in certificates.
I double-checked all ASN.1 modules in the tree and this seems to be
the only one affected by the issue.
crypto/asymmetric_keys/x509_akid.asn1 | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_akid.asn1 b/crypto/asymmetric_keys/x509_akid.asn1
index 1a33231..c7818ff 100644
--- a/crypto/asymmetric_keys/x509_akid.asn1
+++ b/crypto/asymmetric_keys/x509_akid.asn1
@@ -14,15 +14,15 @@ CertificateSerialNumber ::= INTEGER ({ x509_akid_note_serial })
GeneralNames ::= SEQUENCE OF GeneralName
GeneralName ::= CHOICE {
- otherName [0] ANY,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
+ otherName [0] IMPLICIT OtherName,
+ rfc822Name [1] IMPLICIT IA5String,
+ dNSName [2] IMPLICIT IA5String,
x400Address [3] ANY,
directoryName [4] Name ({ x509_akid_note_name }),
- ediPartyName [5] ANY,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER
+ ediPartyName [5] IMPLICIT EDIPartyName,
+ uniformResourceIdentifier [6] IMPLICIT IA5String,
+ iPAddress [7] IMPLICIT OCTET STRING,
+ registeredID [8] IMPLICIT OBJECT IDENTIFIER
}
Name ::= SEQUENCE OF RelativeDistinguishedName
@@ -33,3 +33,13 @@ AttributeValueAssertion ::= SEQUENCE {
attributeType OBJECT IDENTIFIER ({ x509_note_OID }),
attributeValue ANY ({ x509_extract_name_segment })
}
+
+OtherName ::= SEQUENCE {
+ type-id OBJECT IDENTIFIER,
+ value [0] ANY
+ }
+
+EDIPartyName ::= SEQUENCE {
+ nameAssigner [0] ANY OPTIONAL,
+ partyName [1] ANY
+ }
--
2.40.1
On Tue, Sep 26, 2023 at 11:46:41AM +0200, Lukas Wunner wrote:
> 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 <[email protected]>
> ---
> Found this while bringing up PCI device authentication, which involves
> validating the Subject Alternative Name in certificates.
>
> I double-checked all ASN.1 modules in the tree and this seems to be
> the only one affected by the issue.
>
> crypto/asymmetric_keys/x509_akid.asn1 | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt