"A.R. (Tom) Peters" wrote: (* 1 *)
> Do we make it a policy that for all people who took one or more
> exams, the certification status can be polled anyway ? (i.e., we won't
> tell that he failed the L.II exams 5 times, but just that he has an LPIC-1
> certification since date so-and-so).
> Or do we make it a policy not to disclose this information unless the
> candidate made explicit that he wants to participate in this service?
I don't think it should be the policy to quantify the competence level of the
"certifyee", by listing how many times he failed a particular exam. It should not
be given out to other persons, even if the certifyee requests it. I can think of
no valid reason to give out such information, and "certifyee" hubris is not a valid
reason for LPI. It is also likely that once employers find out that the
information is available, they will force a job applicant to provide ID numbers and
access codes as a pre-condition to employment. This is counterproductive to the
goal of identifying otherwise competent administrators.
It might be a good idea to put up barriers to the testee, himself. Limiting
descriptions of test results to one result per request would effectively eliminate
the employer problem. Even then, this should only be done after the inquiring
testee provides the place and date of the test, and the test ID given at the time
of the exam. I assume that all testees will be automatically mailed their results
once, after the exam.
Human beings will be handling this information for LPI. Human beings make
mistakes. Lawyers sue Human beings who make mistakes. It is wasteful of resources
for LPI staffers to defend lawsuits that do not relate to: "Can *this* applicant
keep *this* Linux system running?"
>
> The other major issue is, what do we use as a unique personal
> identifier? There are several options:
>
> A) full names
> + personal
> - probably not unique
> - variant spelling
>
> B) social security code
> + personal and unambiguous, but:
> - different format in different countries
> - maybe not unique (the same number for different persons in different
> countries)
> - illegal to use by a non-government agency in some countries (e.g.
> Canada)
>
> C) generated unique ID (number)
> + unique, unambiguous
> - semi-secret (what is the ID of a certain person?)
> - not personal: people may claim an ID that isn't theirs but they know
> it has a high level of certification; how can an outsider check the fraud?
> - easy to poll for the certification status of all candidates (by
> polling all possible ID's) instead of just an individual.
>
> The typical use for the certification-verification service would be that
> a prospective employer can check the certification status of a candidate.
>
> (* 2a *)
> Do we want the employer to be able to do that independent of the
> candidate, i.e. he is able to guess or obtain the ID used in our database?
> Or do we require active participation by the candidate, who would need
> to disclose his semi-secrte ID ?
> The answer to this question determines the type of ID we can use.
>
> We want the prospective employer also to be able to verify that the
> status actually belongs to that person, so a name should probably be used
> in the procedure.
>
> (* 2b *)
> Do we require the name as part of the input data for the
> certification-verification service ? (if a valid answer is returned, the
> name matched the rest of the ID); it is easy to make errors in names
> however.
> Or do we return the name with the certification status ? (so he can
> check that the ID belonged to the candidate): this may be vulnerable to
> breach of privacy.
It might be prudent for there to be several identifying codes. Data storage is
cheap. Computing is cheap. Database engines are powerful. One code/key would be
for the main database. Nothing should be on the main database computer except the
database and the database access tools. The main database computer should be behind
its own firewall. Another code/key would be for the certification database. The
certification database should also be on its own computer behind its own firewall.
Access to the certification database would not mean access to the main database.
Another, different, code would be mailed to an applicant prior to the test. She
would have to provide it to the proctor at the time of the exam, and put it on her
exam sheet.
An internally generated, non-obvious, unique, Gray code as a key for the
certfication database, coupled with the certifyee's name would limit inquiries to
proper requests. A plus would be that most invalid code/keys would be
self-identifying. Without the codes, and the names to match them, malicious
persons will have a difficult time committing fraud. Relatively loose spelling
rules will still provide powerfull checks on Gray coded keys. E.g. Q110916A,
Quaddafi could match Q110916A, Kadaffi.
In the interest of integrity of LPI, the certifyee's name should be required as
part of the verification of the inquiry, and it should be included in the response
to the inquiry. Other than an E-mail address for the certifyee to be notified
about each inquiry, there should be no other identifying information on the
certification database. Responses to inquiries should not pass through the hands
of the certifyee, but should go directly to the party making the inquiry. The name
and e-mail address of the party making the inquiry should be added to the main
database, under information about the certifyee.
Assume every criminal Hacker and two-bit con artist in the world will consider
it his own personal holy grail to break into this system, and either prevent anyone
else from accessing it, or adding his own information and certifications.
The integrity of LPI is at stake on every transaction. If it ever hits the
headlines that LPI permitted someone to commit fraud, due to laxness on the part of
LPI, the efforts of everyone on this project will be wasted.
Lots of words. Too many "should"s. Lots of other, valid, ways to solve these
problems.
Andy Walker
________________________________________________________________________
This message was sent by the linux-cert mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
