Remember this: A public key is an identity. It is an identity which
is bound to the private key.
Sure...
That would be a bad idea IMO. I don't want a certificate from XYZ CA nor do
I want them to know anything about me. I'm happy to use ZXY and YXZ CA
however. I'd make simply another request through the same UI...
What would they know about you that couldn't be harvested from email
lists? That you have a public key, and an email address that you use
that public key with?
So that I would receive even more up-sale spam that my private key isn't
secure anymore from CAs I don't care? No thanks! Neither would I like to
bother subscribers which didn't meant to receive and use a certificate
from StartCom in first place. I think this is a bad idea.
I said "to request class-1 validation" -- you call it "verification",
but aside from the terminology I meant the same thing: you must
verify/validate that a given private key can be used to decrypt
something sent to the email address claimed.
Re-read about Class 1 validation and Mozilla minimum requirement for
email / client certificates. No CA is allowed to issue client certs for
S/MIME without performing an email ping or similar verification method.
This way, you don't have to trust the
email program, you only receive an email address and a public key, you
send a specially-formatted message to the email address that
Thunderbird can auto-parse, have it decrypt the thing with the private
key, send another request with the same email address and the
encrypted nonce, and have it deliver the certificate.
Yes, this sounds better. We certainly could make those hooks easier and even
automate, agreed. I'd like to see support for such an idea and involvement
perhaps by Gerv and Johnath too. If it's going to be an agreed standard
procedure, allowing all interested CAs in NSS to participate I must say it
sounds interesting.
I would very much like to see this standardized. I would prefer not
to limit it only to the NSS-included CAs, instead allowing a
specially-formatted link from any privately-run online community to
enable a request to be sent to that privately-run community's
certification system.
I wouldn't like to promote the use of un-audited and perhaps insecure
CAs, sorry. Neither does it make sense to use them if the root doesn't
exist - and having the root imported via such a back-door of certificate
import/install utility isn't great either.
Honestly, you could do this with StartSSL's system as it stands right
now -- you verify email addresses for 30 days, and there's no reason
you couldn't simply accept a key submission and request to link it to
one of the verified email addresses, and issue the certificate on the
spot. (In fact, you already practically do this, just with the manual
CSR pasting system or keygen tag.)
Yes, more or less this is correct, but I'm certain that the technical
details could be worked out. Different CAs would have different
requirements and we'd have to align and find a common ground between the
ones which care to participate and contribute to the discussion and
standard.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
