Re: [pkix] Syntax of Subject Alternative Names field in a certificate

Jeffrey Walton <noloader@gmail.com> Tue, 16 April 2024 12:58 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19096C14F610 for <pkix@ietfa.amsl.com>; Tue, 16 Apr 2024 05:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F86h4hJbCsvS for <pkix@ietfa.amsl.com>; Tue, 16 Apr 2024 05:57:57 -0700 (PDT)
Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA70C14F5F9 for <pkix@ietf.org>; Tue, 16 Apr 2024 05:57:57 -0700 (PDT)
Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5aa28cde736so2547825eaf.1 for <pkix@ietf.org>; Tue, 16 Apr 2024 05:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713272276; x=1713877076; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EsM6nGw7ysNfMVRUHPJnzCbO3v6wHO384YuXBv5Iqb8=; b=HmcE4/xZBKIStjb/E/8gBEFJNVRsyY6OEWmrlnHDxRXwtU2XpC4KrU2z/3HRaGL6y/ zpo8dLsXdyl2ULXN/e0VA0S9vUHJ1IfMXXDgHYPVDNsow3gXyWYLtdpzWvfOBsI6EE4h DqnGKuu2Ikp14NZwfyGvwOfEvgE87Kt+3RZeUUSwWBj/teoPVaGb6dIYhrULrEJ0PQh8 5d+QrVJb05C+aqYOrNveqodA6NKq+eNA46GSKgG/GcK44Dm1W0S6qk+3E87/8sf2Emku S7T3M27dkaK2uWFLwyDzv11RAZpBfLzI9Hcrlh+ClNXDIjqUXqlUKvg5HuQQ3zHuOjIP 9KRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713272276; x=1713877076; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EsM6nGw7ysNfMVRUHPJnzCbO3v6wHO384YuXBv5Iqb8=; b=wdVFpN/hzft63sBY22ZYw8S0JGtfhR/aqYKRYIw67kfUX+ZP7olJ3ih8fUKCTvRlzi tMZKowG8PkuTteanGWQJvgua6B2dxuPMibzhmJplX7U0pEGigJ/lxg2O42f5MpnZv41o R6Om3w6DFKbrwQO/IlQ2YOE4WLrTkPPoo950KYrhuYu6KSrM5aC34ydOcSRx+CdfeUVX MV3gZP0Pc9lpY6LPmsUoSjgf/8+mnwXX5jNT8qF+By7sKNS4dlr0AblBZaiNiVyfGRe5 0lpt3vwjEFOTzWUHSkZe5FzcHGg0cYpxe5dE0uNEh/lL6XDGs8lF6FdM3gqXtgujurlW e4PA==
X-Gm-Message-State: AOJu0YxclhRMP17K1o7sNxtunIvygZf4EK4MHuI6v5GR9A/9dqQ3BvJY TAF0K6QCIQtLw2n1phrVj+sTTS60OTEuIRN3jl8mE00lkQxKWepzKoxMRAvCZPV8+KcmqZvCcbV 6GE7fYf9fl8WgUQYhbZFLmV7LAz4ftRcA
X-Google-Smtp-Source: AGHT+IGrLUtXglm+xfG29DyCJy4UK+SY9u1ZP+E9kGt/E109Y5dw/zqrbLQz2LnVWBO+9sir8wPXMIX38b865yyjyrg=
X-Received: by 2002:a05:6870:420f:b0:22e:c4e7:8aba with SMTP id u15-20020a056870420f00b0022ec4e78abamr15735076oac.47.1713272276577; Tue, 16 Apr 2024 05:57:56 -0700 (PDT)
MIME-Version: 1.0
References: <BY1PR15MB6150E0A016987E14C1991B40EF082@BY1PR15MB6150.namprd15.prod.outlook.com> <BY1PR15MB6150B48C505432B45AC299F5EF082@BY1PR15MB6150.namprd15.prod.outlook.com>
In-Reply-To: <BY1PR15MB6150B48C505432B45AC299F5EF082@BY1PR15MB6150.namprd15.prod.outlook.com>
Reply-To: noloader@gmail.com
From: Jeffrey Walton <noloader@gmail.com>
Date: Tue, 16 Apr 2024 08:57:45 -0400
Message-ID: <CAH8yC8nrdF0T7snPN9TXgPNzin+h1xJz3nXarP1EM1HsD-8kKA@mail.gmail.com>
To: Andreas Maier <maiera@de.ibm.com>
Cc: IETF pkix mailing list <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072f732061636490a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/VI3ohmkMrUJf_1H6E_KVF03l86k>
Subject: Re: [pkix] Syntax of Subject Alternative Names field in a certificate
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2024 12:58:02 -0000

On Tue, Apr 16, 2024 at 8:12 AM Andreas Maier <maiera@de.ibm.com> wrote:

> Hi, I am trying to understand what the syntax is for the string value of
> the Subject Alternative Names field, particularly when it contains multiple
> entries.
>
> I was hopeful to find that in https://datatracker.ietf.org/doc/html/rfc5280 which as a section 4.2.1.6 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6> “Subject Alternative Name” but I could not get that out of the syntax description in there.
>
> I can find examples which seem to suggest it is a comma-separated list of items, each of which has a type indicator (e.g. “DNS”), as in:
>
> DNS:{hostname1},IP:{ip2},email:{email},URI:{uri4}
>
> Some sources for the examples:
>
>    - https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html
>    -
>    https://support.hpe.com/hpesc/public/docDisplay?docId=sf000094754en_us&docLocale=en_US&page=index.html
>    -
>    https://www.linode.com/docs/guides/using-openssls-subjectaltname-with-multiple-site-domains/
>     use:
>
> Where is the syntax of the Subject Alternative Names field documented in
> an RFC?
> Are the type indicators mandatory or optional?
>

According to RFC 5280, Section 4.2.1.6 (p. 38):

SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

Use Peter Gutmann's dumpasn1 to inspect the octets that make up the SAN in
the certificate.

Jeff