在证书上，subjectAltName中的电子邮件地址应为哪种类型 [英] On certificates, what type should E-mail addresses be when in subjectAltName

问题描述

一点点背景: 我正在使用M2Crypto和Django构建证书颁发机构，因此请在投票关闭前先三思.话题！ :)

Little bit of background: I'm building a certificate authority using M2Crypto and Django, so please think twice before voting to close this as off topic! :)

我的方法是通过电子邮件地址标识最终用户，并明显地自己发出他们的自签名信任锚，但是我应该如何存储他们的身份"?

My approach is that end-users are identified by e-mail addresses and their self-signed trust-anchors are issued obviously by themselves, but how should I store their 'identity'?

我曾经在野外看到许多证书，这种做法是将邮件地址存储为subjectAltName = rfc822:[e-mail]，但是

I've seen many certificates out there in the wild where the practice has been to store mail addresses as subjectAltName = rfc822:[e-mail], but googling suggest that the standard way would be subjectAltName = email:[e-mail].

两者之间有没有任何差异?如果是，则首选哪个?

Is there any difference between the two, and if so, which one is preferred?

推荐答案

两者之间是否有任何区别，如果有的话，哪个是更可取的?

Is there any difference between the two, and if so, which one is preferred?

并非如此；这取决于您使用的PKI配置文件. PKI和X509是狂野的西部.

Not really; and it depends on the PKI profile you are using. PKI and X509 are the wild, wild, west.

如果您在组织内部运行私有PKI，则如何操作都无关紧要.选择一些东西并始终如一地做.

If you are running a Private PKI internal to you organization, it does not matter how you do it. Pick something and do it consistently.

在网络上通常使用PKIX并在RFC 5280中指定， Internet X.509公钥基础结构证书和证书吊销列表(CRL)配置文件.根据4.1.2.6，主题:

On the web its generally PKIX and specified in RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. According to 4.1.2.6, Subject:

Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject
alternative name extension (Section 4.2.1.6) to describe such
identities.  Simultaneous inclusion of the emailAddress attribute in
the subject distinguished name to support legacy implementations is
deprecated but permitted.

然后是第4.2.1.6节，主题备用名称:

Then Section 4.2.1.6, Subject Alternative Name:

When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name.  The format of an
rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821].
A Mailbox has the form "Local-part@Domain".  Note that a Mailbox has
no phrase (such as a common name) before it, has no comment (text
surrounded in parentheses) after it, and is not surrounded by "<" and
">".

请注意，它既不使用rfc822:[e-mail]也不使用email:[e-mail].就像我说的那样，它是荒野，荒野的西部.您应该为任何事情做好准备.

Notice that it does not use either rfc822:[e-mail] or email:[e-mail]. Like I said, its the wild, wild west. You should be prepared for anything.

您还拥有CA/浏览器论坛及其颁发证书的标准.感兴趣的两个文档是:

You also have the CA/Browser Forums and their standards for issuing certificates. The two documents of interest are:

• 基准证书要求
• 扩展的验证证书要求

• Baseline Certificate Requirements
• Extended Validation Certificate Requirements

但是它们回溯到RFC 5280.

But they defer back to RFC 5280.

您看到的rfc822:和email:可能是由软件添加的，用于演示.例如，要枚举使用OpenSSL的SAN，您的功能应类似于:

The rfc822: and email: you are seeing is probably added by software for presentation. For example, to enumerate the SANs using OpenSSL, your function would look similar to:

void print_san_name(X509* const cert)
{
    int success = 0;
    GENERAL_NAMES* names = NULL;
    unsigned char* utf8 = NULL;

    do
    {
        if(!cert) break; /* failed */

        names = X509_get_ext_d2i(cert, NID_subject_alt_name, 0, 0 );
        if(!names) break;

        int i = 0, count = sk_GENERAL_NAME_num(names);
        if(!count) break; /* failed */

        for( i = 0; i < count; ++i )
        {
            GENERAL_NAME* entry = sk_GENERAL_NAME_value(names, i);
            if(!entry) continue;

            if(GEN_DNS == entry->type)
            {
                int len1 = 0, len2 = -1;

                len1 = ASN1_STRING_to_UTF8(&utf8, entry->d.dNSName);
                if(utf8) {
                    len2 = (int)strlen((const char*)utf8);
                }

                if(len1 != len2) {
                    fprintf(stderr, "Strlen and ASN1_STRING size do not match (embedded null?):"
                                    " %d vs %d\n", len2, len1);
                    /* Handle error */
                }

                /* Do something with utf8 */

                if(utf8) {
                    OPENSSL_free(utf8), utf8 = NULL;
                }
            }
            else if(GEN_EMAIL == entry->type)
            {
                ...
            }
            ...
        }

    } while (0);

    if(names)
        GENERAL_NAMES_free(names);

    if(utf8)
        OPENSSL_free(utf8);
}

(对不起，我没有一个方便提取IA5Strings的示例).

(Sorry I don't have an example that extracts the IA5Strings handy).

在上面，请注意类型:GEN_DNS或常规DNS名称.这用于www.example.com之类的名称. OpenSSL具有其中一些类型，以下来自x509v3.h:

In the above, notice the type: GEN_DNS or general DNS name. That's used for names like www.example.com. OpenSSL has a few of those types, and below is from x509v3.h:

#define GEN_OTHERNAME   0
#define GEN_EMAIL       1
#define GEN_DNS         2
#define GEN_X400        3
#define GEN_DIRNAME     4
#define GEN_EDIPARTY    5
#define GEN_URI         6
#define GEN_IPADD       7
#define GEN_RID         8

您的证书查看器或演示软件可能显示rfc822:或email:，因为它遇到的是GEN_EMAIL类型.

Your certificate viewer or presentation software is probably displaying rfc822: or email: because it encountered a type GEN_EMAIL.

当您查看OpenSSL的配置文件时，您将看到例如:

When you look at OpenSSL's configuration file, you will see, for example:

...
[ v3_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer:always
subjectAltName         = email:[e-mail]
issuerAltName          = issuer:copy

不是将email:逐字复制到SAN中.相反，它告诉OpenSSL在字段中使用GEN_EMAIL类型.

The email: is not copied verbatim into the SAN. Rather, it tells OpenSSL to use the GEN_EMAIL type for the field.

如果您的证书查看器或演示软件不是 添加前缀，则可能是解析专有名称.

If your certificate viewer or presentation software is not adding the prefix, then its probably parsing a Distinguished Named.

关于专有名称，彼得·古特曼(Peter Gutmann)很久以前告诉我(摘自他的电子邮件):在DN中粘贴您想要的任何内容，并仅显示有用的位".就像我说的，它是荒野，荒野的西部.

As for what's in a distinguished name, Peter Gutmann told me a long time ago (taking from his email): "Stick anything you want in the DN and present only the bits that are useful". Like I said, its the wild, wild west.

电子邮件地址也可能显示在OID下.例如， 1.2.840.113549.1.9.1 arc .这是对SAN的补充.这就是为什么下面的图像带有标签电子邮件地址"的原因.

Email addresses might show up under an OID, too. For example, the 1.2.840.113549.1.9.1 arc. That's in addition to the SAN. Its why the image below has that label "Email Address".

Peter Gutmann有 X509样式指南.从他的描述中得出:它描述了各种X.509证书实现细节和陷阱，提供了有关做什么和不做什么的建议，最后列出了要在现有实现中查找的已知错误和问题.

Peter Gutmann has an X509 Style Guide. Taken from his description: it describes various X.509 certificate implementation details and pitfalls, provides recommendations on what to do and what not to do, and finishes with a list of known bugs and problems to look out for in existing implementations.

最后，这是Startcom颁发的用户证书.他们提供免费证书，并在需要时向您收取吊销费用(因为这就是费用所在).这与其他CA完全相反，其他CA负责对撤销进行收费，并在不需要时将其收入囊中;)

Finally, here's a user certificate issued by Startcom. They offer free certificates and charge you for revocation if needed (because that's where the cost lies). That's diametrically opposed to other CAs who charge for the revocation up front and pocket it if not needed ;)

第一个是X509证书:

The first is the X509 certificate:

第二个是使用Gutmann的dumpasn1进行的证书转储(从www.cs.auckland.ac.nz/~pgut001获取dumpasn1.c和dumpasn1.cfg；使用gcc dumpasn1.c -o dumpasn1进行编译；然后复制到).请注意，没有rfc822:或email:前缀:

And second is the dump of the certificate using Gutmann's dumpasn1 (get dumpasn1.c and dumpasn1.cfg from www.cs.auckland.ac.nz/~pgut001; compile with gcc dumpasn1.c -o dumpasn1; and copy into /usr/local/bin). Notice there is not rfc822: or email: prefix:

这篇关于在证书上，subjectAltName中的电子邮件地址应为哪种类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！