[Bug]: Authority Information Access Extension Verify

[dulanshuangqiao]

Contact Details

[email protected]

Version

ubutun 5.7.6

Description

./configure make sudo make install ./testsuite/testsuite.test wolfSSL is configured and built by default

Reproduction steps

Use this script for certificate verification

// gcc -g verify.c -o verify -lwolfssl
#include <stdlib.h>
#include <wolfssl/ssl.h>
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/error-crypt.h>

int wolfSSL_Verify_PEM(char * cac, char * ec){
int ret = 0;

// to create a new wolfSSL cert manager
WOLFSSL_CERT_MANAGER* cm;
cm = wolfSSL_CertManagerNew();
if (cm == NULL){
	printf("Creating a new wolfSSL_CertManager failed!\n");
	exit(1);
}

// to load cac to the created wolfSSL_CertManager
ret = wolfSSL_CertManagerLoadCA(cm, cac, NULL);
if (ret != SSL_SUCCESS){
	printf("Loading cac to the created wolfSSL_CertManager failed!\n");
	exit(2);
}

// to verify the ec in the created wolfSSL_CertManager
ret = wolfSSL_CertManagerVerify(cm, ec, SSL_FILETYPE_PEM);
if (ret != SSL_SUCCESS){
	printf("wolfSSL_CertManagerVerify filed and with return code %d and error message %s\n",
		 ret,
		 wolfSSL_ERR_reason_error_string(ret));
}
else{
	printf("The target cert has passed through verification.\n");
}

// to free cm
wolfSSL_CertManagerFree(cm);

return ret;
}

int main(int argc, char ** argv){
char * cac = argv[1];
char * ec = argv[2];
wolfSSL_Verify_PEM(cac, ec);
return 0;
}

./verify RootCA.pem Cert174107818015D1.pem ./verify RootCA.pem Cert17410781804D1.pem ./verify RootCA.pem Cert174107818018D1.pem wolfSSL_CertManagerVerify failed with return code -140 and error message ASN parsing error, invalid input

Expected result: Consistent with OpenSSL、GnuTLS:verified.

Cert174107818015D1.pem、Cert17410781804D1.pem、Cert174107818018D1.pem has the Authority Information Access extension, but the extension value is empty.

wolfsslAIA.zip

Relevant log output

[ColtonWilley]

Hello @dulanshuangqiao

So while openssl does verify these certs, I have determined this encoding is not valid under RFC 5280. Per section 4.2.2.1, the authority information access encoding is specified as:

AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

As you can see, it is specified as a sequence of (1...MAX), and thus an extension value of zero bytes is not a valid encoding. OpenSSL seems to be more generous than us and allow this, but we will not be extending the code to support non-valid encodings. Please let me know if this clears up the issue or if you still have any questions remaining.

[dulanshuangqiao]

你好@dulanshuangqiao

因此，虽然 openssl 确实验证了这些证书，但我确定这种编码在 RFC 5280 下无效。根据第 4.2.2.1 节，权威信息访问编码指定为：

AuthorityInfoAccessSyntax ::= 访问描述的序列大小（1..MAX）

如您所见，它被指定为 (1...MAX) 的序列，因此零字节的扩展值不是有效编码。OpenSSL 似乎比我们更慷慨，允许这样做，但我们不会扩展代码以支持无效编码。如果这解决了问题或者您还有任何问题，请告诉我。

I reported my doubts in #8573