| Message ID | be8ab09429d55c6cfc52ee0e43bf021ffb384152.1695720715.git.lukas@wunner.de |
|---|---|
| State | Accepted |
| Commit | a1e452026e6d7d16253b29b9d19d3c99a5066726 |
| Headers | show |
| Series | X.509: Add missing IMPLICIT annotations to AKID ASN.1 module | expand |
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 <lukas@wunner.de> > --- > 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.
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 + }
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> --- 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(-)