Per-Entity Metadata Working Group

["Cantor, Scott" <>]

> 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

Revocation checking is a client issue, not a server one. It is a major issue 
*if* you care about the certificate deeply, and it is true that browsers 
check CRLs or use OCSP more than they used to.

But server side code is much less likely to do those checks and in many cases 
there's no revocation checking at all when you use TLS for data origin 
authentication. I think ADFS will do the checking if the certfiicate has CRL 
extensions in it, but that's just me guessing.

Using a self-signed certificate has the advantage of clarity: you know 
there's no checking done and that a key compromise requires touching every 
server relying on it, and it's just a black swan event.

IJ's points are valid: there are definitely exposures with TLS as the basis 
of the security that are not exposures with offline signing. But equally 
there are attacks possible with signing that aren't possible with TLS if you 
trust the server cert. I certainly lean toward believing the advantages of 
signing outweigh those attacks, but I think the longer the validUntil window 
there, the more some use of TLS becomes attractive.

-- Scott