On Mon, Jun 29, 2020 at 09:59:09AM -0400, Russ Housley wrote: > > Wrt to the technical argument: > > > > [email protected] is an interesting example, because i hate receiving > > these > > emails, so i would LOVE to see a normative RFC saying that these type of > > email addresses MUST NOT get certificates. However, technically i think that > > is not defensible, because obviously (to me) its perfect valid for a > > mailbox to not receive or not to send emails. Its to me just a controlled > > subject > > with a name/address. > > > > And customer harrasment departments are of course also > > interested to be protected from phishing and the like, so they will > > of course also use certificates for mails from [email protected] as soon > > as enough customers would understand security (*sigh*). And i am willing > > to take any bet with you, that there will be nothing from the IETF that > > normatively says this should not be done. > > No. I go not agree. The [email protected] mailbox is not ever used to > communicate with the party that holds the private key. So, it should not be > bound to the subject public key in a certificate.
Why can [email protected] not have the private key for the certificate which has [email protected] in its rfc822Name ? Are you excluding the option for any validation procedure that does not include an actual ?challenge? email to the email address ? Remember that in a private PKI environment ALL names in a certificate could be assigned to the entity based on a validation that by itself may not show up in the certificate at all. E.g.: When i become employee of a company, someone might see my drivers license, but the company PKI generated cert for me in that enrollment process would not have any info from that drivers license, but just my name in the SNand company email address in the rfc822Name SAN. On a USB TPM stick. To sign my email, or whatever else. Oh, and i was hired to be responsible to send harrassment emails to customers, so i get a second USB TPM stick to use specifically for this job role and it has only rfc822Name email address with [email protected]. Cheers Toerless > Russ _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
