>Does it make things slightly harder to process, or does it actually break >X.509? >Consider the scenario of a person who wishes to manage different >"certificate profiles" but not have to worry about different keys. For >example, he may want to sign messages as one person within the company, >using a cert with his Org, OrgUnit and Title, but outside the company he >wants to use a simpler cert that just has his name and email address in >it. Why should both of those certs be forced to use different keys? My image of these processes is a keycentric one. If you get a signature, accepting the signature involves a) the cryptographic correctness of the signature and b) my policy accepting the certificate given. If one has 2 certificates for one key, the decision will not depend on the key only, but also on the certificate given. I consider this to be not ok. I would like to be able to use protocols that do not need to provide me with a suitable certificate - I could have a local cache or so. Carrying certificates around is not so great, considering the space such things use to take. Assuming a working infrastructure, I could ask some CA-service to deliver a cert if I don't have it in my cache. If there would be more than one, leading to different trust decisions, this would be a drawback. Peter
BEGIN:VCARD VERSION:2.1 N:Lipp;Peter;; FN:Peter Lipp ORG:Styria; TITLE: TEL;WORK;VOICE:+43 316 873 5513 TEL;HOME;VOICE: TEL;VOICE:Graz TEL;WORK;FAX:A-8042 ADR;WORK:;;;;;; LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A, =0D=0A EMAIL;PREF;INTERNET:plipp@iaik.tu-graz.ac.at REV:19980304T101555Z END:VCARD
Attachment:
smime.p7s
Description: application/pkcs7-signature