CAcert Code Development list.

[Ian G <iang AT iang.org>]

On 22/05/10 4:19 AM, Pieter van Emmerik wrote:
> Does this comply wit the Practice On Names -
> http://wiki.cacert.org/PracticeOnNames ;?
> I did not have a look at the code, but if it checks for abbreviations
> and does not allow anything
> which does not match with the name in the account (like translations) it
> might be acceptable.


The CPS covers OpenPGP signatures, and if you look at the table in CPS 
4.3.1 plus the statement in 4.2.3, it's probably easy to conclude that 
only Assured Names can be put in.

http://www.cacert.org/policy/CertificationPracticeStatement.php

*According to Assurance Policy* we can have many assured names.  The 
problem is that the software does not cope with more than one name. 
Sadly ...

What then would be more useful is a patch that leads us closer to that 
goal:  multiple names, and Assurance Points over the names, not the account.

This is likely not a trivial code patch, it probably requires table & 
data shuffling.  Malte, do you fancy looking into that?

There is one alternative.  You propose to Policy Group a change to 
exclude all OpenPGP signing from the CPS.  Then, you can do what you 
like ... well, almost, in that you'll have more freedom at least.

iang


> Just a question as I do not apply patches, even am I involved in
> approving a path.
>
> Regards,
> Pieter van Emmerik
>
> Op 21-5-2010 16:50, Malte S. Stretz schreef:
> > Hi,
> >
> > I just tried to have my GPG key signed with CAcert and it was refused.
> > The
> > issue was that I have entered my full middle name in CAcert, but
> > prefer to use
> > the abbreviated version in reality. There is a hack in the Wiki on how to
> > circumvent this, but thats suboptimal.
> >
> > Here is a patch which makes verifyName() accept the most common
> > abbreviated
> > version (ie.as I use it), too. This should be fine and isn't a regression
> > information wise as the code already accepts a key with "$fname
> > $lname" even
> > if you have a $mname set.
> >
> > As you can see I changed the whole function to use a loop over an array
> > instead of the repeated string concatenations. This makes it not only
> > more
> > readable (I think), but also simpler to extend and simplifies the
> > check for the
> > suffix (which is allowed for all combinations).
> >
> > Maybe the code here should be even more flexible, eg. people from some
> > countries (France?) seem to prefer to have their last name in upper
> > cases, so
> > a case insensitive comparison might work better. Also, I noticed that
> > while
> > suffixes are allowed, titles/prefixes aren't. Once I am "Dr. Malte S.
> > Stretz" I
> > will come back with another patch ;) For now the attached one should
> > be fine.
> >
> > Cheers,
> > Malte