4 ms·

At some level, a certificate is an identity. If I’ve trusted a cert then I know that anyone using it has the private key, no matter their IP or dns name. Being

At some level, a certificate is an identity. If I’ve trusted a cert then I know that anyone using it has the private key, no matter their IP or dns name. Being able to do that for a local device would be very nice—I could connect to whatever up it dhcp-ed to and be sure I was talking to the right thing.

tialaramex 9y ago
That deserves a hard stare. If I trust the certificate on my chat server to be _the certificate for my chat server_ that doesn't suddenly make it OK to present that certificate if you're claiming to be my bank, or my operating system vendor, or Hacker News. The local device should have a _name_ and then we can issue it a certificate for that _name_ and know we're really talking to the same thing as last time. DHCP and other address allocation protocols don't (needn't) change the name.
- nybble41 9y ago
  I think we should just take the same approach that I2P and Tor take for naming, and base the domain name on the public key. Local devices automatically get a domain like gmaf2cgbn3q2be3vaaytrev3qyxcksemkdxtzefq5bl3542uyf3q.local, which they can advertise via mDNS, and the browser accepts a self-signed certificate for a public key which matches this fingerprint just as if it were "domain validated". The domain stays the same so long as the key does, so the user can bookmark the page for their own device and be sure that when they navigate back to that domain they're getting the same device and not some imposter—effectively making this equivalent to "trust on first use". Edit: Changed "on the certificate" to "on the public key". It might be necessary to regenerate the certificate periodically, e.g. to update the expiration date, and that shouldn't affect the domain name.