In the area that we have been discussing (e-ID), we have mainly been discussing use of a single ID. Indeed, in the Europen GIF modelling exercise (found in Vol 3 of OSCIE at http://www.eeurope-smartcards.org/B2-Index.htm) the concept is of a single "official identity" with two certificates/key pairs: one for authentication, the other for signature. Attributes are not permitted, and indeed nothing else is permitted in the application holding the ID - this is not so much technical as related to responsibilities: the ID app issuer is only responsible for your official identity. If attributes are required, or even other IDs, they go in another app managed by the same or another organisation.
To spare the feelings of those who might have problems with the idea of one's ID being a number, GIF suggests using the combination of your name, date of birth and probably gender as the ID, with a reference number in the register added on. Peter ----- Original Message ----- From: "Anders Rundgren" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 12, 2004 5:21 PM Subject: [Muscle] Multiple certs/key - Banned > Some interesting info from another list > > It is interesting to note that the use of a single key-pair for > multiple certificates still is fairly often touted by promoters > of smart cards. Usually due to limitations in private key storage > and generation. > > Anders > > PS I never thought this was a such a great idea BTW DS > > ----- Original Message ----- > From: "John Boyer" <[EMAIL PROTECTED]> > To: "Gregor Karlinger" <[EMAIL PROTECTED]>; "w3c.xmldsig ML" <[EMAIL PROTECTED]> > Sent: Friday, March 12, 2004 17:52 > Subject: RE: XAdES - More secure than XML Dsig? > > > > > <gregor> > However, I do not think that modelling the signer role per using different > certs for the same key is a good practice. Rather the relying party should > deduce this from the context, for instance from the data being signed (as > you do it in the paper world as well), or from another signature attribute > which XadES provides (Signer Role). > </gregor> > > Yes, reading this chain I got the same feeling as Gregor that the CAs issuing > multiple certs per the same key pair had crossed the line of the intent of > the system and were now using the self-signing ability of XML DSig or XAdES > to fix the hack. > > A key pair is supposed to be assigned to a unique identity. If, within a system, > that means (name+role), then that is what should be assigned the key pair. > To say that (name+role) is the identity, but we assign the key pair to name > opens up the real possibility of abuse of the system. > > To wit, how is the relying party supposed to know whether or not a cert is the > unique wrapper for a given key pair? Therefore, how can generic signature engines > be written? Must they be told to require signatures that sign the certificate as > part of the core validation? > > Conversely, because it's not part of core validation, shouldn't the CA's have > stayed away from this practice? > > John Boyer, Ph.D. > Senior Product Architect and Research Scientist > PureEdge Solutions Inc. > > _______________________________________________ > Muscle mailing list > [EMAIL PROTECTED] > http://lists.musclecard.com/mailman/listinfo/muscle > > _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
