meta user
network profile
| bio | website | cs.uwaterloo.ca/~j5clark |
|---|---|---|
| location | Toronto, Canada | |
| age | 32 | |
| visits | member for | 2 years, 6 months |
| seen | May 13 at 14:01 | |
| stats | profile views | 86 |
Postdoctoral fellow interested in authentication and cryptographic voting.
|
May 8 |
awarded | Nice Question |
|
Nov 19 |
awarded | Yearling |
|
Sep 11 |
comment |
CRIME - How to beat the BEAST successor? This publication may also be relevant: "TLS Compression Fingerprinting and a Privacy-aware API for TLS." It is possible the browsers disabled compression because of this result. cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/… |
|
Aug 14 |
awarded | Caucus |
|
Jul 24 |
comment |
Domain name expiration and TLS @Bruno Correct. I envision it as only detecting domains that have gone through the entire 75 day drop process. I think it safe to assume that the domain has changed hands after this. I wouldn't trust the information provided in whois records enough to try and discern ownership transfers from the information itself. It is a simple mechanism to detect the clear cut cases (and could have an option to warn on any change). |
|
Jul 24 |
comment |
Domain name expiration and TLS @Bruno It wouldn't reject in that case. But in 11 months, if the domain wasn't renewed by the same entity, then it would. The domain reg would 1 month old and the cert would be issued at least 11 months prior. |
|
Jul 24 |
comment |
Domain name expiration and TLS After thinking about this, it seems the browser is better positioned to address this issue. It could compare the registration date for the domain from the whois record with the certificate issuing date, and only accept if the certificate date is later in time. |
|
Jul 24 |
comment |
Domain name expiration and TLS Thanks Bruno. My question is more about the last paragraph of your answer: is it common practice for a CA to consider/monitor domain expiration? Do browsers consider this issue in their root certificate policies? |
|
Jul 23 |
awarded | Student |
|
Jul 23 |
asked | Domain name expiration and TLS |
|
Jun 8 |
awarded | Constituent |
|
Jun 8 |
awarded | Caucus |
|
Jan 10 |
awarded | Announcer |
|
Nov 19 |
awarded | Yearling |
|
Oct 7 |
awarded | Nice Answer |
|
Aug 18 |
awarded | Nice Answer |
|
Aug 9 |
awarded | Enthusiast |
|
Aug 2 |
comment |
Secure Internet Polling ... Finally, the difference between E2E systems and closed source software is that the former can be understood. It requires expertise but it is an open protocol. With closed source software, even if you are an expert, you cannot validate its behaviour. |
|
Aug 2 |
comment |
Secure Internet Polling ... Systems like Scantegrity still allow traditional manual recounts, and all the E2E enhancements can be ignored. Another system I worked on, Eperio, allows the whole tally proof to checked with only file encryption and basic spreadsheet commands. These systems are not understandable to your standards but they are progress. Also, inevitably elections will involve technical aspects. The math of selecting precincts for manual recounts so that a specific target for statistical certainty can be achieved can become complex, for example... |
|
Aug 2 |
comment |
Secure Internet Polling @hendrik I agree with you: understandability is very important. It's my opinion that given the trade-off between truly verifiable elections (verify every precinct at a time of your choosing after the election) that are not understandable because of cryptography, and non-verifiable elections (or verifiable only by being physically present at a single polling place for the entire day) that are understandable, I choose the former. That said, it is important to make E2E elections as understandable as possible. cont... |
