Subject: [TLS] TLS 1.3 certificate delegation?

From: Andy Lutomirski <[email-masked]>
Date: Thu, 07 Nov 2013 11:51:58 -0800

I'm not sure that this is in scope for TLS 1.3, but if it were part of
TLS 1.3 then servers could send different certificates to clients
depending on TLS version.

Currently, if an organization wants to use a wildcard certificate, every
web server must possess (or at least be able to use) the associated
private key.  Similarly, if an organization wants to use short-lived
keys, it must ask its CA to sign a large number of short-lived certificates.

In principle, a server could present a certificate chain like this:

1. trusted root
    |
    V
2. intermediate CA  (owned by outside authority)
    |
    V
3. non-CA (wildcard?) certificate  (owned by the server's operator)
    |
    V
4. short-lived or domain-specific certificate

Clients will reject this chain as invalid (it contains an intermediate
(#3) that isn't a CA).

It would be a departure from established practice, but, if certificate
#3 permits signing, then there's nothing insecure about this certificate
chain.  Whoever has the private key associated with certificate #3 is
permitted to host the domains described by the common name and
subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
they're willing to delegate authority to certificate #4, they should be
able to.

In principle, current standards allow something like this by using a CA
certificate with a name constraint as #3, but this is completely broken
in practice.

If TLS 1.3 were to change the validation rules to allow this type of
certificate chain, then there would be several benefits:

 - Organizations could deploy ECDSA without involving the certificate
issuers.

 - Organizations could buy a single wildcard certificate and then
delegate authority to their servers however they like.

 - Servers could generate very short-lived delegated certificates to get
a good approximation of PFS without using DHE/ECDHE.  (Google's QUIC
does something very much like this.  They use fixed ECDH "certificates"
called "server configs" that contain a public curve25519 parameter,
which results in a much less computation than any TLS 1.2 key exchange
mode.)

Backwards compatibility is sometimes possible.  For example, a server
could present its real certificate to old clients (and use DHE) but
present a temporary delegated certificate to TLS 1.3 clients.

--Andy

---

From: Carl Wallace <[email-masked]>
Date: Thu, 07 Nov 2013 12:08:21 -0800

>4. short-lived or domain-specific certificate

Proxy certificates should accomplish what you want. See RFC3820.

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 7 Nov 2013 12:15:10 -0800

> Proxy certificates should accomplish what you want. See RFC3820.

Interesting -- I'd never noticed that.

That being said, proxy certificates are essentially useless unless all
clients support them.  In the absence of mandatory support or a client
extension indicating acceptance of proxy certificates, they won't be
used.

--Andy

---

From: Carl Wallace <[email-masked]>
Date: Thu, 07 Nov 2013 12:26:35 -0800

>extension indicating acceptance of proxy certificates, they won't be

Of course, but the same goes for notional hybrid server/CA certificates
too, no?  There is apparently some support for proxy certificates in
Apache.  I've no idea what it's used for or how well it works though.

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 7 Nov 2013 12:49:33 -0800

> Apache.  I've no idea what it's used for or how well it works though.

Right.

My point is that, if something like this shows up as a mandatory
feature in TLS 1.3, then it becomes usable.  I would use it on
public-facing websites, for example.

--Andy

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 06:17:33 +0100 (CET)

> Apache.  I've no idea what it's used for or how well it works though.  

The TLS implementations that have the least excuse for ignoring
what travels in the Server's Certificate TLS handshake
message are the TLS clients -- and TLS clients outnumber TLS servers
by maybe three orders of magnitudes.

What Apache consciously/officially supports might be largely irrelevant
when OpenSSL is used -- because that seems to blissfully send arbitrary
data from two files (cert and chain) provided that the contents
can be ASN.1 decoded as X.509v3 containers.  So whatever the admin
manages to put in these files, Apache will send obediently and with
eyes closed. 

-Martin

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 7 Nov 2013 22:04:29 -0800

> manages to put in these files, Apache will send obediently and with

This is, I think, mostly irrelevant -- if I know that my clients
understand delegated certificates or proxy certificates or whatever,
then I'll find a way to get my server to send them.

ISTM that, as long as there's momentum behind a developing a better
TLS, it would make sense to use the same version upgrade to improve
the certificate situation.  (Proxy certificates aren't the only big
improvements possible -- a clean way to support DNSSEC-based
certificates would be great, too.)

FWIW, there's precedent for using new TLS versions to expand the set
of allowable certificates.  If I"m reading it correctly, TLS 1.2
allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
will reject those.

--Andy

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 08:21:09 +0100 (CET)

> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below

TLSv1.1 will certainly not reject those.
It is only rfc4492 that incorrectly alleges that those should be rejected.

And an implementation of TLSv1.2 client that would accept an ECDSA
EE server cert signed by an RSA cert when TLSv1.2 is negotiated,
but would reject the very same server certificate when TLSv1.1 is
negotiated (but would accept it with TLSv1.1 when a pure ECC
cert path is present) would yield "seriously broken" on my scorecard.

A number of TLS specs are plastered with rfc2119-violating
and therefore bogus and void requirements.

I somewhat optimistic that a number of implementations ignore
those bogus requirements already.  Fixing the remaining implementations
to ignore those bogus requirements might turn out to be easier than
fixing the documents, though...

What I find confusing about rfc4492 is how the hash for digitally-signed
is selected & signalled for TLSv1.0 and TLSv1.1--that seems somewhat
undefined in the document.

But then, using ECDSA with TLS would be pretty suicidal.  (EC)DSA are
an extremly brittle algorithms, i.e. "cryptoglycerin", and while
rfc6979 might help in producing k in constant time, the algorithm
for computing the inverse of k as specified in FIPS 186-4 Appendix C.1
is not a constant-time algorithm, and might leak sufficient "implicit hint"
about k that it makes the signing process "vulnerable to catastrophic
failures" when it is performed inband/online, such as in TLS, where
the server must sign each ServerKeyExchange handshake message inband.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Fri, 08 Nov 2013 04:39:38 -0800

>certificates would be great, too.)

As would end-to-end authentication when proxies are in use:
http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01.

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 08 Nov 2013 15:29:15 +0100

> It is only rfc4492 that incorrectly alleges that those should be rejected.

I think you are wrong: Section 7.4.2 of RFC 4346 states

                              Unless otherwise specified, the signing
      algorithm for the certificate MUST be the same as the algorithm
      for the certificate key.

Section 7.4.2 of RFC 5246 states
                                                                  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.

Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 08 Nov 2013 15:36:55 +0100

> they're willing to delegate authority to certificate #4, they should be

It is a bad idea to introduce violations of PKIX standards (RFC 5280) in TLS  1.3.

-- 
Johannes

---

From: Bill Frantz <[email-masked]>
Date: Fri, 8 Nov 2013 07:56:26 -0800

> It is a bad idea to introduce violations of PKIX standards (RFC 5280) in TLS  1.3.

Please explain why.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, CA 95032

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Nov 2013 11:16:13 -0500

> Please explain why.

TLS uses certificates.  Certificates use the CA structure.  The CA structure has a particular trust model.  PKIX [dr]efines an instance of that trust model. PKIX is used throughout the Internet when X.509 certificates are used, almost exclusively.  It is hard to write trust-path code and get it right. Adding a new complexity for this one special case (even if it is a major user) makes library re-use harder, and is could well make all certificate-using software on the same computer open to buggy and/or confusing behavior.

"If you want PGP you know where to get it."

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 17:34:32 +0100 (CET)

>       algorithm for the certificate MUST be the same as the algorithm

The history of this obvious defect starts in rfc2246.

There exists no such artificial limitation in SSLv3, and when I looked
at implementations I've been using for interop testing a few
years ago (Microsoft SChannel, OpenSSL, Firefox), they would
happily interoperate with an RSA server cert signed by a CA with a
DSA key.  To me it looks like most implementors were either not
aware of this bogus, backwards-incompatible requirement,
or they applied common sense and deliberately ignored it.

One can not "violate" rfc2119 Section 6 more than with the above
statement, so it is null and void.

Not only is this method "must be the same algorithm" not required
for interop, it is the the worst possible way to impair interop
without a cause.

-Martin

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 8 Nov 2013 08:37:06 -0800

> TLS uses certificates.  Certificates use the CA structure.  The CA structure has a particular trust model.  PKIX [dr]efines an instance of that trust model. PKIX is used throughout the Internet whe…

This doesn't necessarily need to change the PKIX validation algorithm
at all [1].  Rather than presenting a proxy certificate, the server
could present a standard (valid according to PKIX / TLS 1.2 rules)
certificate and *separately* present a chain of public keys, each
signed by the previous one and marked with validity times, where the
first public key is signed by the server certificate and the last
public key is compatible with the key exchange algorithm.  (To keep it
simple, the allowable final key types could be limited to fixed DH
parameters and RSA/ECDSA signing keys -- there's no reason to support
traditional RSA key exchange here.)

None of this needs to be in X.509 format.  An advantage of *not* using
X.509 is that libraries can't make the mistake of asking clients to
validate these keypairs -- clients should validate the actual PKIX
certificate instead.

There's no need for revocation, OSCP stapling, or related mechanisms
-- the validity periods can be kept short enough that a validly signed
key is equivalent to a valid, fresh OCSP response.

This is a lot like how QUIC works.  I think Google got that part of
the protocol right.

Of course, the downside of this approach is that it's a much more
intrusive change in the TLS protocol (proxy certificates don't require
any protocol change except some indication from the client that it
accepts proxy certificates).

--Andy

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Nov 2013 11:45:18 -0500

> Rather than presenting a proxy certificate, the server could present a standard (valid according to PKIX / TLS 1.2 rules) certificate and *separately* present a chain of public keys, ... None of this needs to be in X.509 format.

I'm curious what this new and different but similar structure would be like.   And whether the intended use of this stuff justifies the complexity and creation of all this new stuff, or breaking PKIX compatibility.

I think one way to not break with PKIX is to define a new extendedKeyUsage attribute that says "can sign short-term SSL cert chains"

	/r$

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 17:52:18 +0100 (CET)

> It is a bad idea to introduce violations of PKIX standards

It is actually not a violation of PKIX.  However, behaviour is undefined.

PKIX (rfc5280) inherited this from X.509, and it has been spelled out
in rfc5280-clarifications:

  http://tools.ietf.org/html/rfc6818#section-2

  2. Update to RFC 5280, Section 3.2: "Certification Paths and Trust"

     Add the following paragraph to the end of RFC 5280, Section 3.2:

  | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
  | that use of self-issued certificates and self-signed certificates
  | issued by entities other than CAs are outside the scope of this
  | specification.  Thus, for example, a web server or client might
  | generate a self-signed certificate to identify itself.  These
  | certificates and how a relying party uses them to authenticate
  | asserted identities are both outside the scope of RFC 5280.

"outside the scope of rfc5280".

which essentially means that TLSv1.3 could actually specify
whatever semantics it sees fit.  The problem that may arise, however
is that passing a certification path with such a
"self-issued certificate issued by an entity other than a CA"
to a _vanilla_ PKIX/rfc5280 or X.509 certificate path validation
function might not give you the result that you may be looking
for, likely applying CA checks on the end entity cert above
the proxy cert and aborting path validation with an error.

-Martin

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 08 Nov 2013 17:55:44 +0100

> I think one way to not break with PKIX is to define a new extendedKeyUsage attribute that says "can sign short-term SSL cert chains"

not breaking PKIX means that basic contraints must be set to CA=TRUE. Furthermore, the new EKU would have to be limited
t a particular domain.

Another way not to break PKIX would be to use the PKIX standard mechanism mentioned by Andy: CA certificates with name
constraints. If this was required to be supported in TLS 1.3  why should it be less likely to work in practice than a
completely new concept?

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 08 Nov 2013 18:21:17 +0100

>   | asserted identities are both outside the scope of RFC 5280.

Interesting, this clarification in RFC 5280bis escaped my attention.

However, self-issued implies that both certificates share the same Common Name. So this paragraph only applies to the
scenario sketched by Andy when the server identity (sub domain) is encoded _only_ in SubjectAltName (dNSName). This is
recommended by RFC 2818 anyway.

-- 
Johannes

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 8 Nov 2013 09:33:02 -0800

> I'm curious what this new and different but similar structure would be like.   And whether the intended use of this stuff justifies the complexity and creation of all this new stuff, or breaking PK…

A little like the server config mechanism here:

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 8 Nov 2013 09:43:17 -0800

> not breaking PKIX means that basic contraints must be set to CA=TRUE. Furthermore, the new EKU would have to be limited

Please don't -- that will just cause the certificate authorities to
charge more for these certificates.

The problem AIUI with X.509 constraints in general is that they only
apply to the next certificate down the chain, which means that there's
plenty of room to get the spec wrong and make it useless [1].

If TLS 1.3 adds a new mechanism here, I think that the validation rule
should be clearer: the standard CA=FALSE certificate that's involved
must be valid for the domain *and* each delegated certificate must
also be valid for the domain.  This means that you don't need to check
that each delegated certificate's constraints are a subset of their
parents'.  (For example, there's no need to make it illegal for a
CA=FALSE certificate for foo.example.com to delegate to a
*.example.com certificate; instead it's enough to say that the
*.example.com certificate won't be accepted for bar.example.com
because its signer isn't valid for that domain.  Similarly, you don't
need to think about all the different kinds of names in X.509 and
their interactions.)

(I suppose this is a problem w/ the non-X.509 approach in QUIC --
there's no way for a wildcard certificate to delegate just one of its
subdomains.)

[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/

--Andy

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 08 Nov 2013 11:25:24 -0800

>    a departure from TLS 1.1, which required that the algorithms be the

I don't believe that there was ever a requirement for a client to reject
a certificate chain based on the signature algorithms.  The requirement
is for what a server must send to the client when it has no knowledge
about the client's capabilities.  The cipher suite list sent by a client
provides a hint at its capabilities, but it was made explicit in TLS 1.2.

It would be a bad idea to send an RSA key signed with ECDSA, for example,
without knowing that the client can handle ECDSA.  That is the purpose
of the signature_algorithms extension.

If a client were to receive a certificate containing an RSA key that is
signed by ECDSA, and it happens to know how to validate ECDSA, there is
no reason to abort the connection.

Mike

---

From: Rob Stradling <[email-masked]>
Date: Fri, 08 Nov 2013 22:40:24 +0000

On 08/11/13 17:43, Andy Lutomirski wrote:
<snip>
> apply to the next certificate down the chain,

Disagree.  I'd say the reverse is true.

The Basic Constraints pathLenConstraint field (RFC5280 4.2.1.9)...
   "...gives the maximum number of non-self-issued intermediate
    certificates that may follow this certificate in a valid
    certification path."

The Name Constraints extension (RFC5280 4.2.1.10)...
  "...indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located."

> which means that there's

OpenSSL 0.9.8 doesn't process Name Constraints, but OpenSSL 1.0.0+ does. 
  So upgrade.  :-)

> If TLS 1.3 adds a new mechanism here,

...then implementers might "get the spec wrong and make it useless"?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 8 Nov 2013 15:04:17 -0800

On Fri, Nov 8, 2013 at 2:40 PM, Rob Stradling <[email-masked]> wrote:
> OpenSSL 0.9.8 doesn't process Name Constraints, but OpenSSL 1.0.0+ does.  So
> upgrade.  :-)
>
>

If it's widely used (possibly even by default in some implementation)
to use short-term fixed DH parameters a la QUIC, then implementations
won't have the opportunity to screw it up.

--Andy

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 09 Nov 2013 10:55:11 +0100

>>        algorithm for the certificate MUST be the same as the algorithm
Taking this out of context is not helpful
The specificatiosn makes staements about what the sender has to
do, not what the receiver has to verify.

7.4.2. Server Certificate

> or they applied common sense and deliberately ignored it.
What is bogus in restricting a sender to be conservative?
> statement, so it is null and void.
Be strict in what you send, that's violated by some, be liberal
in what to receive, this enhances interop in some cases.

> without a cause.NO
Only if a receiver misinterpretes the rulles about what a sender MUST do as
'you have to verify this and reject if you can detect it'. But that is not what
is written.

By default a receiver can accept any kinf of garbage, not verify
signatures, etc.

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Nov 2013 21:27:06 +0100 (CET)

Peter Sylvester wrote:
> The specifications makes statements about what the sender has to

The words in the TLS specification do not say who should to what.
With your rationale, this is a mere prayer addressed at nobody.  :)

> What is bogus in restricting a sender to be conservative?

As if the _sender_ (implementation!!) had a choice.

Which TLS implementations are prepared of handling two server certificates
that differ only in the CAs signature algorithm (i.e. same server public
key, same name attributes, same key usages)?

That would be bridging PKIs at the end-entity level.  I assume
that bridging is normally done at the CA level.

And how many real-world TLS servers are actually configured
with such almost-twins server certificates?

The vast majority of Web Servers have only a single server
certificate, and those that have different certs, either
have certificates ditinct by public key algorithm or distinct
by (server)name.

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 13 Nov 2013 10:41:26 +0100

> With your rationale, this is a mere prayer addressed at nobody.  :)
The spec doesn't say: "The client MUST reject the certficate message
if the  certficate signing algo is not the same as the algo for the signd key."

Among the 4 possibilities the MUST could apply, i.e.,

1 - to the sender AND the receiver
2 - to the sender only
3 - to the receiver only
4 - to nobody

at least 2 seems non controversal (the wording, not the
staement itsself!).

Concerning 1, As soon as a client can verify the signature
and can use the key, they accept the cert anyway as you say.

Other protocol texts have better wordings indicating
what a cerator must do and what a receiver must do.

The sentence about 'prayer' remains obscure to me.
"Wunschdenken" for whom?

Ok..
>>> or they applied common sense and deliberately ignored it.
It ssems at least useful to me to distinguish client and server implementation.
Since in the above examples are clients, ok. They ignore it, and they can.
> As if the _sender_ (implementation!!) had a choice.
One can now look whether the requirements are
useful for the sender.  As for the DSA/RSA combination,
the requirement doesn't seem necessary. well, some
implementation might not like SHAxxx in the CA signature.

> key, same name attributes, same key usages)?
In which scenario you would need 2 certs if you follow
the requirement but only one if not?

Any logic for several does not create more difficulties than the
support for SNI. At least, one or more  callbacks that presents the more
or less interpreted client hello data (in a defined order)
to the application or to configuration module (as with mod_ssl)
of the application.
This in not rocket science, well, rocket science is still faster:-),
  and, as far as I can tell from the SNI experience, it is implementatable
with reasonable technical effort (opening the door to
a cathedral is another story).

> that bridging is normally done at the CA level.
If the signing algo of the cert differs, then I think the
CA key (DSA vs RSA for example) may be different.
I would think that different signing algorithm mean
different CA profiles.
> with such almost-twins server certificates?

Probably none, people keep asking me whether one needs
to support SSL V3.
At least with SNI, code in apache is there since 5 years.

> have certificates ditinct by public key algorithm or distinct
I am lost.

I agree that we talk about one sentence

and I think that we also agree that the discussion can be
about the server only (since there is no restriction to the client
and clients may accept differences anyway.

What I was saying is only that if the server respects that, i.e.
there is only ONE algorithm. In reality, this does not apply
to the RSA/DSA combination because all clients support both.

Going back: If the servers wants to have two different types of
keys, it needs two certs?
I interate the advocatus diaboli argument: If you have two
value, you can fail for two reasons, if you have one, you *may*
have better chances.
Where does this requirement actually harm?
What are the possible errors:

Error message: "You server presents a certificate that we are
able to use but unfortunately, we cannot verify the certficate
because we do not have  the code to do verify the intermediate
certificate at level 42."

Hm, or was that to get rid of CA certs with MD5.

Best
/P