On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any reduction of expiration time).
> I don't know if NSS has support for checking of SCTs (I can't pull the
> source at the moment to check), but it should fail if the SCT is
> missing, and otherwise behave like OCSP validation.

Embedding SCTs is not the only way SCTs can be delivered - they can come
in the SSL handshake or via OCSP. Requiring them to be embedded does
have the advantage that certificates now carry an unforgeable timestamp,
and it was something I proposed in a version of Mozilla's now-dormant CT
policy. But for various reasons, it's not necessarily practical to
require it in all circumstances (which is why the CT RFC defines
multiple mechanisms).

Firefox does have some support for checking SCT presence and validity,
but it's not turned on.

>> Are there any RA's left for Symantec?
> TBH, I'm not sure. I think Gervase asked for clarification on this
> point, but its hard to keep track of who could issue as an RA. I know
> quite a few got killed, but I'm not sure if there are any other subCAs
> based off re-reading posts in this thread.

Symantec say they have closed their RA program, only Apple and Google
are left in their GeoRoot program, and they have no other programs which
allow third parties to have issuance capability.

>> I believe the only reasonable interpretation of the "new root"
>> plan would be based on cross signing for trust by old Mozilla
>> browsers and other root programs.
> Won't the cross signature though have to be embedded in Firefox, or
> included in a server's SSL bundle for it to actually work?

The latter, yes. This is not difficult nor that unusual.

dev-security-policy mailing list

Reply via email to