Per-Entity Metadata Working Group

[Tom Mitchell <>]

I feel like I’m missing something in this TLS debate. Like why there’s even a debate. Please illuminate me if that’s the case, and I apologize in advance for being dense.

To me, TLS is standard stuff. I don’t think we’re talking about anything more than a TLS certificate like that used for https://www.internet2.edu .

My answers to the relevant deployment questions below would be:

1) Any CA in the generally trusted set, with “InCommon RSA Server CA” being a likely candidate

2) 3 years like the TLS certificate at https://www.internet2.edu is fine, whatever is normal for the chosen CA

3) Revocation is handled by the CA just as it handles revocation of any other TLS certificate

On Sep 8, 2016, at 8:51 AM, Paul Caskey <> wrote:

To me, it feels like you may be reading too much into the requirements.

Why not just use a regular InCommon server SSL cert like all the other websites?

It mitigates certain attacks, which is what Scott (and others) was talking about yesterday.

-----Original Message-----
From: [] On Behalf Of Tom
Scavo
Sent: Thursday, September 08, 2016 7:47 AM
To: Per-Entity Metadata Working Group <>
Subject: [Per-Entity] deploying TLS on the MDQ server

The key word on the subject line is "deploy." Personally, I'm not convinced
that the benefits of TLS outweigh the costs (especially if we tighten
validUntil) but in order to advance the discussion, let me ask the relevant
deployment questions:

1) What CA signs the TLS server certificate?
2) What is the expiration date on the TLS certificate?
3) How do we handle revocation?

I'll give one possible deployment scenario:

1) The metadata signing key also signs the TLS server certificate.
2) TLS certificates are short-lived, on the order of days.
3) Revocation is not necessary (since TLS certificates are short-lived).

The above deployment has teeth but I'm afraid it is nontrivial to implement.
Are there other deployment scenarios that are easier to implement yet meet
our needs?

Tom