Skip to Content.
Sympa Menu

cacert-policy - Re: [CAcert-Policy] Brainstorming Session on Names

Subject: Policy-Discussion

List archive

Re: [CAcert-Policy] Brainstorming Session on Names


Chronological Thread 
  • From: Sebastian Kueppers <cacert AT kueppers.ath.cx>
  • To: Policy-Discussion <cacert-policy AT lists.cacert.org>
  • Subject: Re: [CAcert-Policy] Brainstorming Session on Names
  • Date: Tue, 25 Sep 2007 23:20:35 +0200
  • List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
  • List-id: Policy-Discussion <cacert-policy.lists.cacert.org>

Hi!

Evaldo: Thank your for starting this discussion, I'm begging for such a
policy for about a year now...

Bernhard Froehlich schrieb:
> Evaldo Gardenali schrieb:
>> Hi
>>
>> During the meeting, we came to the fact that currently we don't have a
>> policy regarding names. I think we would need one, because I know or
>> heard about the following situations:
>>
>> - Countries that have strict matching on First Name and Last Name
>> - Countries that have strict matching on First Name, Middle Names,
>> Last Name
>> - Countries that allow you to have 20 first names to choose from at
>> appropriate times
>> - Countries that allow people to have a single name (a first conclusion
>> would be that first name = last name, but it shouldnt appear twice
>> - Countries that have fuzzy matching on First Name (so if you abbreviate
>> from "Foobarblahblahblah" to "Foozie" its okay, provided that its usual
>> to do so)
>>   
> 
> Another one not so uncommon around here:
> - People changing their last name after marriage

I think that is a minor problem, because (at least in germany) you'll
get an official certificate stating the change of name.

>> I have heard some more, but cant remember right now... maybe I will add
>> here.

Swiss people can omit their second surname, if they have one (that's
what I've been told, please correct me if I'm mistaken)

In germany academic titles _can_ be used and be added to the identity
papers, but they don't have to (as in Austria).

>> I would like ideas regarding CAcert policy for names, so we can actually
>> serve people without creating more problems than we already have, and
>> eventually solving some.
>>   
> The only idea that occured to me: The name(s) have to be the same on the
> ID document.
> Of course this creates new problems, like names in unusual character
> sets or lots of names on the document, different capitalisation and
> several more.
> I guess we'll have to leave the final decision to the assurer, who may
> accept "locally well known" variants on names.

I think that would cause problems with non-local assurers on events...
And even if we leave the choice to the assurer: It quite upsets the
users if one assurer has no problem with a special name and another one
refuses to assure him because of the name.
No doubt that any assurer has the right to refuse assurances, but I
think that such incidents may not happen because all interpretation on
names is left to the assurer...
(take my name for an example: I have an umlaut (ü) in it. If I
correspond with others by email I usually rewrite it to 'ue'.
If there are still issues with CAcert certificates and UTF-8 I think we
should (better: we have to) provide a possibility to avoid these issues.
Either by making the certificates working with UTF-8 or by allowing
transliteration of problematic characters.

> For example one thing I always considered ok was the german "eszet" (�)
> character which is represented in ID cards as SZ, since ID cards only
> use capital chars. But of course the name might have been czech or
> hungarian where "sz" is a not so uncommon combination...

Another problem are the Certificates itself. If I remember correctly
there have been some issues about UTF-8 and X.509 certificates...
And if we allow substitution of loacal special chars into some
ASCII-counterpart we would need a comprehensive list of allowed
substitutions.


Greetings
Sebastian

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.16.

Top of Page