Subject: [TLS] trusted_ca_keys

From: Natasha Rooney <[email-masked]>
Date: Thu, 4 May 2017 13:26:02 +0000

Hi all!

Apologies for the odd and potentially silly question. GSMA are working on future SIM specifications which use TLS and previously included the trusted_ca_keys to allow a client to inform a server which particular key(s) from a CA it is supporting. In TLS 1.3 the ‘trusted_ca_keys’ extension is no longer used. It does have the “certificate_authority” extension however, but it seems to only identify the CA organisation by its DistinguishedName. If the CA supports multiple keys – how can a client point a particular cert/key of that CA?*

Thanks and sorry for posting to the group!

Natasha

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 4 May 2017 16:43:28 +0300

On Thu, May 04, 2017 at 01:26:02PM +0000, Natasha Rooney wrote:
> 
> GSMA are working on future SIM specifications which use TLS and
> previously included the trusted_ca_keys to allow a client to
> inform a server which particular key(s) from a CA it is
> supporting. In TLS 1.3 the ‘trusted_ca_keys’ extension is no
> longer used. It does have the “certificate_authority” extension
> however, but it seems to only identify the CA organisation by its
> DistinguishedName. If the CA supports multiple keys – how can a
> client point a particular cert/key of that CA?*

The certificate should have its own DN, use that.

This doesn't fully solve designating by key, as multiple issuing
CAs can share a key.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 13:45:20 +0000

> The certificate should have its own DN, use that.

She's saying that it *doesn't.*

SubjectDN is not unique.  IssuerDN/Serial is unique, but this extension use that.

---

From: [email-masked] (Martin Rex)
Date: Thu, 4 May 2017 16:50:47 +0200 (CEST)

> SubjectDN is not unique.  IssuerDN/Serial is unique, but this extension use that.

SubjectDN of a *Certificate Authority* **MUST** be unique.

There is some wording in PKIX and X.509 which creates the impression
that a CA could be re-using the same Subject DName with different keys,
but such an interpretation is a formally provable defect of the PKIX
specification.

Creating a certificate chain *MUST* be possible on the issuer name->
subject name chaining alone.  Support for chaining by subjectKeyId
is truely *OPTIONAL* based on the requirements in the specification,
so reuse of the same DName with a different key would break certificate
chaining (and verification) that is performed on the issuer->subject
chain alone and is therefore prohibited.

Support for the SubjectKeyIdentifier and AuthorityKeyIdentifier
X.509v3 extensions is explicitly just *RECOMMENDED* and can therefore
be absent from a perfectly PKIX-conforming minimum requirements RP.
PKIX-conforming CA MUST NOT break minimum-requirements RPs, e.g.
by creating/issuing CA certificates with identical subject names but
different public keys. 

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 14:58:07 +0000

> There is some wording in PKIX and X.509 which creates the impression that a
> CA could be re-using the same Subject DName with different keys, but such
> an interpretation is a formally provable defect of the PKIX specification.

Any links you can point to?

I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally prevent CA2 from issuing a sub-ca with the exact same DN.  Can you explain what I am missing?

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 4 May 2017 18:16:33 +0300

On Thu, May 04, 2017 at 02:58:07PM +0000, Salz, Rich wrote:
> I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally
> prevent CA2 from issuing a sub-ca with the exact same DN.  Can you
> explain what I am missing?

The organization info (O, L, ST, C, etc...) is supposed to differ in
that case (CN is just one field of DN), rendering the full DNs
distinct.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Thu, 4 May 2017 17:19:34 +0200 (CEST)

Salz, Rich wrote:
[ Charset windows-1252 unsupported, converting... ]
> I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally prevent CA2 from issuing a sub-ca with the exact same DN.  Can you explain what I am missing?
 
Such an action will create two mutually exclusive PKIs, PKIs that
are *NOT* allowed to ever be bridged.  Bridging them or would open security
problem in the design of CRL processing rules for a collision
of distinct subCA names, because those rules say that a signature on
a CRL is valid, if the CRL signer cert can be verified under the same
root as the CA.

PKIX (rfc5280) about AuthorityKeyIdentifier X.509v3 extension:

https://tools.ietf.org/html/rfc5280#section-4.2.1.1

   The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.

While it is a requirement for conforming CAs to place AuthorityKeyIdentifiers
into issued certificates, using it for building or verifying certificate
chains by RPs is purely optional "faciliate".

If re-using the same CA DName for certs with different keys would be allowed,
then chain building and chain verifying would become *DESPERATELY* dependent
on support *AND* use of AuthorityKeyIdentifier->SubjectKeyIdentifier.

-Martin

PS:

Coincidentally, this also implies that "self-issued" (rather than self-signed)
certificates are a "myth".  While they can be created technically, they are
*ALWAYS* in violation of requirements of the specification(s).

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 15:25:03 +0000

> The organization info (O, L, ST, C, etc...) is supposed to differ in that case (CN
> is just one field of DN), rendering the full DNs distinct.

But where and how is that enforced, or enforceable?  Again, any links to show I'm wrong?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 15:26:58 +0000

> If re-using the same CA DName for certs with different keys would be
> allowed, then chain building and chain verifying would become
> *DESPERATELY* dependent on support *AND* use of
> AuthorityKeyIdentifier->SubjectKeyIdentifier.

Or, it could use subject/issuer.  Or it could try all the matching CA DName certs it has.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 May 2017 11:31:10 -0400

> On May 4, 2017, at 10:58 AM, Salz, Rich <[email-masked]> wrote:
> 

You forgot that all the CA certificates are of course published in the global X.500
directory.  And it is of course not possible for two CAs to have the same directory
DN.  [ DNs in the global directory are of necessity distinct. ]

:-)

Apologies for sending this as SMTP email over IP, with any luck it'll still make
it to your X.400 mailbox via a suitable IP<->X.25 connected gateway.

-- 
	Viktor.

P.S.  I've found one brave SMTP server out there whose TLS certificate took a
bold minimalist departure from PKIX.  Note the null subject, issuer and lack
of subjectAltNames.  This works just fine with DANE for SMTP, but could give
some peers a bit of indigestion.  The server administrator demonstrates a clear
understanding of what's essential in a DANE 3 1 1 certificate for SMTP (with
perhaps a "let anyone who can't deal with it fix their system" attitude):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: c3:26:2b:13:ca:b1:36:72
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: 
        Validity
            Not Before: Jul 27 14:59:59 2014 GMT
            Not After : Nov 27 14:59:59 3013 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (4096 bit)
                Modulus (4096 bit): ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59
            X509v3 Authority Key Identifier: 
                keyid:98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
        ...
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

---

From: [email-masked] (Martin Rex)
Date: Thu, 4 May 2017 17:31:54 +0200 (CEST)

Salz, Rich wrote:
[ Charset UTF-8 unsupported, converting... ]
> But where and how is that enforced, or enforceable?  Again, any links to show I'm wrong?

In theory: using  Directory Name  SubjectNameConstraints to enforce
a hierarchical Naming on all Subject Names and one single hierarchy
of CAs.

(Just that this doesn't work for dozens of independent PKIs environments
 like the SSLiverse...)

-Martin

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 4 May 2017 15:38:47 +0000

Feel better Jason!  

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Thursday, May 4, 2017 10:58 AM
To: [email-masked]
Cc: Natasha Rooney <[email-masked]>; [email-masked]
Subject: Re: [TLS] trusted_ca_keys

> that a CA could be re-using the same Subject DName with different 
> keys, but such an interpretation is a formally provable defect of the PKIX specification.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.