Wes Groleau wrote: > On 05-30-2011 06:40, Ian Goddard wrote: >> Richard Smith wrote: >>> They've signed it with their private key rather than the original >>> source's private key. This is easily detectable. >> >> Not really. You would end up with two versions of the record, each >> correctly signed with a private key. You only know which is the original >> version if you know the original source. > > A checksum encrypted by a private key ..... > It's still an "I'm Spartacus" situation. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On 05-29-2011 21:56, Bob Melson wrote: > generated. At this point, dunno quite WHY you'd want to preserve the *IDs > in a merge, not least because they serve no purpose in, ummmm, validating And because doing so subverts the purpose for which they were originally abused. An ID generated to uniquely identify a particular record (even though there is no good reason for doing so) is now attached to a _different_ record. (How do I persuade #%^$% Thunderbird to stop trying to "help" me attach a file every time I use the word "attach" ?) -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 05-30-2011 06:40, Ian Goddard wrote: > Richard Smith wrote: >> They've signed it with their private key rather than the original >> source's private key. This is easily detectable. > > Not really. You would end up with two versions of the record, each > correctly signed with a private key. You only know which is the original > version if you know the original source. A checksum encrypted by a private key ..... -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 05-30-2011 19:08, Richard Smith wrote: > I do wonder whether something like this might be able to restore some > credibility to massively collaborative genealogies like Ancestry's > "One World Tree", and Family Search's "Ancestral File". At the > moment, these have lots of really good, accurate information in them, > and also a vast amount of complete nonsense that devalues the whole As I've complained about in other thread, many of Ancestry's practices convince me that credibility is far below selling subscriptions in their priority list. They have apparently figured out that most people will believe anything and so "anything" is what they offer. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 05-29-2011 18:23, Ian Goddard wrote: > So someone transcribes a record of ol' Mort & writes out his surname > with a capitalised initial because that's what's in the original and > someone else transcribes the same record exactly except that they give > the surname in upper case because that's the convention they adopt. > Oops! Different checksums. There are different checksum algorithms. One might write one that does certain trivial transforms before summing to avoid such differences. But even if the records are identical in content, typography, and layout, that alone doesn't guarantee they represent the same person. And since the checksum by itself is useless, the data must be sent--at which point you could do your own comparison without the checksum. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 05-29-2011 11:57, Ian Goddard wrote: > Bob Melson wrote: >> Y'all'd have to check the archives for the down'n'dirty, but Wes and I >> and >> I don't remember who all else had a discussion of this very thing (_UID, >> _UUID, _GUID) some time back. I contended then that UUID (Universal >> Unique ID) and it's close kin, UID and GUID, meant that the number >> assigned to Cousin Mortimer should be the same universally - here, there, >> wherever it appears. Not so. The "universe" is the machine where the >> data appears and on which the software resides by which the UUID is >> generated and it's only there that it's guaranteed to be unique. > > I think you were right the first time providing the relevant standards > are being followed. See the discussion at > http://en.wikipedia.org/wiki/Universally_Unique_Identifier _No_. It is an algorithm designed to ensure that a UUID generated by any machine will never be the same as any other generated by the same machine OR any other machine. (Whether it meets that requirement is another issue.) Clearly that is in opposition to the desire for an algorithm that will generate an ID that _is_ the same as some other. What Bob wants is something most of us want, but few of us expect to ever get. But it is _not_ a UUID. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On May 30, 3:44 pm, Ian Goddard <[email protected]> wrote: > The bottom line is, does the extra baggage add sufficient or, indeed, > any value to a genealogical system? It's a good question, and the honest answer is I don't know. If it's sufficiently unobtrusive, then perhaps it could be. I do wonder whether something like this might be able to restore some credibility to massively collaborative genealogies like Ancestry's "One World Tree", and Family Search's "Ancestral File". At the moment, these have lots of really good, accurate information in them, and also a vast amount of complete nonsense that devalues the whole project. It's not an idea I've fully thought through, but I do think it would be possible to implement a massively distributed genealogy along these lines that doesn't suffer from the credibility problems usually associated with such projects. And I'm pretty sure that making it possible to see with complete confidence who had contributed what is a necessary part of that. So yes, I think it might have it's place. Richard

Richard Smith wrote: > [Pulling together the replies to two posts by Ian Goddard as they seem > to overlap.] > > On May 30, 11:40 am, Ian Goddard <[email protected]> wrote: > >>>> 3. If someone did decide to massage a record they could simply re-sign >>>> it with their own private key so the advantages could be illusory. >>> They've signed it with their private key rather than the original >>> source's private key. This is easily detectable. >> Not really. You would end up with two versions of the record, each >> correctly signed with a private key. You only know which is the >> original version if you know the original source. > > Well, a signed piece of a data is only as trustworthy as the signing > party. All that the digital signature guarantees is that the data > hasn't been changed since it was signed. How the data was produced is > beyond the scope of a digital signature. Specifically: digital > signatures are not designed to prevent or detect unauthorised copying. > > If you have two versions of the record, each correctly signed, then > you have to make a decision on which (if either) party you trust. But > this is just the same if you've only got one piece of signed data? > Should you trust the author? Even today, with unsigned data, you have > that problem. > > On May 30, 11:06 am, Ian Goddard <[email protected]> wrote: > >> Someone picks up a copy of one of someresource.org's records and wants >> to check the digital signature. They can't because the public key is no >> longer there. Unless, of course, copies of the public key are also >> being distributed with the other records. > > It's a common enough problem, and I think allowing for signed > distribution of the old key is the usual way to handle it. > > It should be standard practice for applications to store the public > key of any source they've ever used. This allows for detection of a > man-in-the-middle attack -- in practice, we probably don't care too > much about this in a genealogy application, but assuming we're using > an existing PKI, we'll get it for free. > > Suppose someresource.org (who originally signed the data) is no more > and you decide to send me a copy of some of the data that you had > downloaded from the site. You have a copy of their public key > (because your software stores these indefinitely), and a copy of the > signed data. So you sign both of these and pass them on to me. > > So I now have your public key, their public key signed by you, and > their data signed by them and then by you. Perhaps I now make some > inferences based on this data -- for example, how the individuals > named in it are related. Some time later, I may wish to pass this on: > so I sign your public key; add my signature to yours on the > someresource.org key and on the data from them; and encode my > inferences and sign them. I then hand over four things to the third > party, who simultaneously gets my public key. > > What we're forming is a chain of trust. We all trust someresource.org > to ship data of a good quality, double-checked against the sources. I > trust you to be honest -- that is, not to alter the data from > someresource.org and then re-sign it with a different key. It doesn't > matter whether or not I trust you to be a good genealogist. The third > party who I pass everything on to needs to trust me to be honest and > competent to make the inferences I have and trust you to be honest. > > A few years later, I might get a copy of the someresource.org key from > someone else, and I can now verify that you were indeed being honest > in passing the data on to me. This might make me more inclined to > trust you in the future. > > And so on... > >> OK, so instead of everyone publishing their keys alongside the record >> they publish them at someotherresource.org. But 10 years later..... > > The solution there is to have lots of sites all storing keys, and all > acting as backups of each other. This already exists. They're called > public key servers. Assuming a genealogy application uses an existing > PKI, it can simply make use of existing key servers. It's incredibly > unlikely that all of these would vanish simultaneously, and because > there are lots of them, someone wishing to compromise the system would > need to compromise most of the key servers simultaneously. That's > highly unlikely to happen. > > And with the advent of key servers, a large part of the chain of trust > vanishes. If I got data from A via B, C, D and E, then without a key > server, I need to trust each of these parties; but with a key server, > I only need to trust everything back from the earliest link in the > chain that has a key on a public key server. So if B, D and E all > have keys on some key servers, then I only need to trust A and B; and, > of course, the key servers themselves, but trust there is established > by vote across many servers. > > The good thing about this sort of distributed system is that many of > the problems have already been solved -- often by peer-to-peer > networks with nefarious purposes. The bottom line is, does the extra baggage add sufficient or, indeed, any value to a genealogical system? -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Richard Smith wrote: > On May 29, 11:23 pm, Ian Goddard <[email protected]> wrote: >> 1. XML introduces even more variations. Consider, for example; >> >> <EmptyTag></EmptyTag> >> <EmptyTag/> >> >> both of which are equivalent but will checksum differently. > > There's something called XML Canonicalisation that handles all of the > low-level aspects of this. There may still be a need for application- > level canonicalisation, if there are several ways of expressing the > same information, such as: > > <persona id="p1"> > <name>John Smith</name> > <relation type="father" ref="p2"/> > </persona> > <persona id="p2"> > <name>George Smith</name> > </persona> > > and > > <persona id="p1"> > <relation type="father"> > <persona id="p2"> > <name>George Smith</name> > </persona> > </relation> > </persona> If the schema is sufficiently tied down this shouldn't be a problem - you'd only allow one form of expression. >> 3. If someone did decide to massage a record they could simply re-sign >> it with their own private key so the advantages could be illusory. > > They've signed it with their private key rather than the original > source's private key. This is easily detectable. Not really. You would end up with two versions of the record, each correctly signed with a private key. You only know which is the original version if you know the original source. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Bob Melson wrote: >> 2. The PKI would also have to be distributed. > > Moot. See above. What I had in mind was this: someresource.org publishes a load of useful stuff and digitally signs it with the public key also being published on the site. The records from this site are much used and passed from one researcher to another so the records become part of a distributed database. 10 years later someresource.org goes off-line - it's funding runs out; it was a one-man operation and the one man looses interest or dies; whatever. Someone picks up a copy of one of someresource.org's records and wants to check the digital signature. They can't because the public key is no longer there. Unless, of course, copies of the public key are also being distributed with the other records. OK, so instead of everyone publishing their keys alongside the record they publish them at someotherresource.org. But 10 years later..... -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On Sun, 29 May 2011 19:56:38 -0600, Bob Melson <[email protected]> wrote: >> And if you merge two of those records, believing that they are same >> person, will the resulting record have TWO unique identifiers? >> >Well if your merge works like the ones I'm familiar with, you have a choice >of which fields of Record B to merge into Record A, so you could use A's >*ID or B's. Or you could delete both and cause yet a third to be >generated. At this point, dunno quite WHY you'd want to preserve the *IDs >in a merge, not least because they serve no purpose in, ummmm, validating >the records. *IDs are just large numbers, the utility of which in >genealogy appears to be undefined. RINs are smaller numbers than UIDs, and I use them for identifying people in my main database. I have several rough research databases for particular surnames or areas (for which I use PAF), and if I copy anything from there to my main database, or vice versa, I used the RIN from my main database as a "Custom ID". No doubt a large number could serve the same purpose, but a smaller one works just as well. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

On May 30, 8:46 am, Steve Hayes <[email protected]> wrote: > RINs are smaller numbers than UIDs, and I use them for identifying people in > my main database. No. Using the term UID here is just adding more confusion. A UID stands for unique identifier, but there's no requirement for it to be universally unique. All that's required is that it's unique within some defined set -- e.g. INDIs in a GEDCOM file. So RINs and UUIDs (or GUIDs) are both perfectly good examples of a UID. What you actually meant is that RINs are smaller numbers than UUIDs. That's true. The term UID is sufficiently loosely defined, that we cannot say anything useful about it, and it's best to avoid the term. Richard

[Pulling together the replies to two posts by Ian Goddard as they seem to overlap.] On May 30, 11:40 am, Ian Goddard <[email protected]> wrote: > >> 3. If someone did decide to massage a record they could simply re-sign > >> it with their own private key so the advantages could be illusory. > > > They've signed it with their private key rather than the original > > source's private key. This is easily detectable. > > Not really. You would end up with two versions of the record, each > correctly signed with a private key. You only know which is the > original version if you know the original source. Well, a signed piece of a data is only as trustworthy as the signing party. All that the digital signature guarantees is that the data hasn't been changed since it was signed. How the data was produced is beyond the scope of a digital signature. Specifically: digital signatures are not designed to prevent or detect unauthorised copying. If you have two versions of the record, each correctly signed, then you have to make a decision on which (if either) party you trust. But this is just the same if you've only got one piece of signed data? Should you trust the author? Even today, with unsigned data, you have that problem. On May 30, 11:06 am, Ian Goddard <[email protected]> wrote: > Someone picks up a copy of one of someresource.org's records and wants > to check the digital signature.  They can't because the public key is no > longer there.  Unless, of course, copies of the public key are also > being distributed with the other records. It's a common enough problem, and I think allowing for signed distribution of the old key is the usual way to handle it. It should be standard practice for applications to store the public key of any source they've ever used. This allows for detection of a man-in-the-middle attack -- in practice, we probably don't care too much about this in a genealogy application, but assuming we're using an existing PKI, we'll get it for free. Suppose someresource.org (who originally signed the data) is no more and you decide to send me a copy of some of the data that you had downloaded from the site. You have a copy of their public key (because your software stores these indefinitely), and a copy of the signed data. So you sign both of these and pass them on to me. So I now have your public key, their public key signed by you, and their data signed by them and then by you. Perhaps I now make some inferences based on this data -- for example, how the individuals named in it are related. Some time later, I may wish to pass this on: so I sign your public key; add my signature to yours on the someresource.org key and on the data from them; and encode my inferences and sign them. I then hand over four things to the third party, who simultaneously gets my public key. What we're forming is a chain of trust. We all trust someresource.org to ship data of a good quality, double-checked against the sources. I trust you to be honest -- that is, not to alter the data from someresource.org and then re-sign it with a different key. It doesn't matter whether or not I trust you to be a good genealogist. The third party who I pass everything on to needs to trust me to be honest and competent to make the inferences I have and trust you to be honest. A few years later, I might get a copy of the someresource.org key from someone else, and I can now verify that you were indeed being honest in passing the data on to me. This might make me more inclined to trust you in the future. And so on... > OK, so instead of everyone publishing their keys alongside the record > they publish them at someotherresource.org.  But 10 years later..... The solution there is to have lots of sites all storing keys, and all acting as backups of each other. This already exists. They're called public key servers. Assuming a genealogy application uses an existing PKI, it can simply make use of existing key servers. It's incredibly unlikely that all of these would vanish simultaneously, and because there are lots of them, someone wishing to compromise the system would need to compromise most of the key servers simultaneously. That's highly unlikely to happen. And with the advent of key servers, a large part of the chain of trust vanishes. If I got data from A via B, C, D and E, then without a key server, I need to trust each of these parties; but with a key server, I only need to trust everything back from the earliest link in the chain that has a key on a public key server. So if B, D and E all have keys on some key servers, then I only need to trust A and B; and, of course, the key servers themselves, but trust there is established by vote across many servers. The good thing about this sort of distributed system is that many of the problems have already been solved -- often by peer-to-peer networks with nefarious purposes. Richard

On Sun, 29 May 2011 12:46:21 -0600, Bob Melson <[email protected]> wrote: >It appears, however, that Cousin Mortimer's record will result in a unique >ID on every machine on which a *ID is generated, so for N copies of the >record on N machines there will be N unique identifiers. And that raises >a question about the utility of those identifiers - if every one is >unique, how do/can we know that they refer to the same record? And if you merge two of those records, believing that they are same person, will the resulting record have TWO unique identifiers? -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

On Sun, 29 May 2011 21:06:40 +0100, "Harrison Genealogy" <[email protected]> wrote: >Steve > >You can create ANY field ie call it EVENT if you want to and the search on >that .... But I don't think you can link such a field to peop.le amd organisations. >As I said before download the demo and have a play ! I did that a long time ago. And as I remember it it was a program for keeping track of source documents, not events. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

Bob Melson wrote: > On Sunday 29 May 2011 09:57, Ian Goddard ([email protected]) opined: > >> Bob Melson wrote: >>> Y'all'd have to check the archives for the down'n'dirty, but Wes and I >>> and I don't remember who all else had a discussion of this very thing >>> (_UID, >>> _UUID, _GUID) some time back. I contended then that UUID (Universal >>> Unique ID) and it's close kin, UID and GUID, meant that the number >>> assigned to Cousin Mortimer should be the same universally - here, >>> there, >>> wherever it appears. Not so. The "universe" is the machine where the > > My original (erroneous?) contention was that identical data should result > in identical UUIDs irrespective of where generated, so that Cousin > Mortimer's record will produce the same UUID whether done on your machine > or mine or somebody else's. As Wes pointed out, this effectively > describes a checksum and, in honesty, I have to admit that that's very > much how I conceptualized *IDs. > > It appears, however, that Cousin Mortimer's record will result in a unique > ID on every machine on which a *ID is generated, so for N copies of the > record on N machines there will be N unique identifiers. And that raises > a question about the utility of those identifiers - if every one is > unique, how do/can we know that they refer to the same record? > > The other component of my now thoroughly beaten-down original belief was > that the *IDs were somehow akin to a digital signature, on the order > of "none genuine without this ID". Assuming _that_ and that I've > published my public key, anybody coming across ol' Mort's record anywhere > could verify (1) that it came from me and (2) whether it's identical with > the original. That obviously won't work with *IDs as they are at present. > (Still, I find the idea of a per record digital signature attractive, tho' > that's an entirely different topic for discussion). > So someone transcribes a record of ol' Mort & writes out his surname with a capitalised initial because that's what's in the original and someone else transcribes the same record exactly except that they give the surname in upper case because that's the convention they adopt. Oops! Different checksums. Another example. Older church registers tend to have headings for year and month (or a page heading for year with intermediate headings for month) and just the day of month on a per record. So the transcriber has to make up his own way of representing dates which might differ from transcriber to transcriber so again ol' Mort could get his name transcribed using the same convention but get the dates represented differently. Again, different checksums. So the checksumming depends not only on the data but also on the way it was transcribed. And of course, different representations could be imposed by the S/W which might insist on upper-case surnames or different date formats. I think there are two separate issues. One is the unambiguous identification of the same publication and the other is its authentication. The latter is the more difficult. Not only are there the sort of problems I've outlined above but also the problem of maintaining a PKI (public key infrastructure). When I suggested what was, in effect, a distributed database using exchanges of UUID-labeled XML records I considered the possibility of digital signing. On balance I decided to leave it out as: 1. XML introduces even more variations. Consider, for example; <EmptyTag></EmptyTag> <EmptyTag/> both of which are equivalent but will checksum differently. 2. The PKI would also have to be distributed. 3. If someone did decide to massage a record they could simply re-sign it with their own private key so the advantages could be illusory. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

f/fgeorge wrote: > On Sun, 29 May 2011 16:37:39 +0100, Ian Goddard > <[email protected]> wrote: > >> singhals wrote: >>> WHY would I want to keep them separate once I've decided they're the >>> same person? My bc, my mc, and my son's bc all refer to ME as ME; what >>> would be the POINT of keeping ME in there 3 times? >> This is the crux of the problem. Your certs all have a /name/ on them. >> Those or just that, names. The names are not /you/. They point to >> you but they are an entirely different type of entity (or object or >> thing or whatever term you wish to use) in reality and therefore really >> should be represented by different types of entity in a database. >> >> So you don't have /you/ in there three times, you have /you/ in there >> once, each of the /names/ from the three certs in there once each and >> three /links/ between the names and you. >> >> Now you might think this is overkill because the names are all the same >> (assuming the name on your son's bc is your maiden name because if not >> you have two variants there already). But if so this is just one >> possibility. At the other extreme I have an ancestor whose surname was, >> in the current dominant spelling hereabouts, Dearnley but in the past >> varied quite a bit and whose first name was rendered so variably that I >> have no idea what it was supposed to be as it goes from Hammond to Amon >> and most points in between. So it makes a lot of sense to have a single >> point where you can standardise the name and link all the variants to >> it. It also makes a lot of sense to be able to attach some sort of >> epithet to disambiguate people of the same name such as my run of 4 >> William Goddards. > > The program TMG lets you put in variant spellings of a name in ONE > record but does not, I don't think, let you then search on them. So in > essence you have to chose one or show the tree or ancestry chart of > someone if you forget hte name. Or in the worst case it is easy to > end up with the same person several times because each time you find > them the info is slightly different and you can't find that they ARE > in fact already in there. Now you CAN put thomas/tomas/tom all on one > line so when you search on thomas you will see the variants, but I > have not found out how to search on tomas and then see the guy. Gramps also does that. So, I'm sure, do many others. But it's the wrong way round. This model attaches alternative names to people. So you have: 1. Events -> Person -> Names in records of event Compare it with: 2. Events -> Names in records of events -> Links -> Person Now, tell, me, which of those actually follows the sequence in which you work things out? And how do you deal with: John, son of William Goddard bapt 30 Jun 1753 John, son of Jonathan Goddard bapt 16 Sep 1753 John Goddard, aged 61 buried 24 Dec 1814 Clearly the John in the burial (and various other records) could be either of the first two. It took me years to gather various bits of circumstantial evidence which, taken together, helped me decide which. In the interim there is no S/W that I know of which would allow me to record that I had an adult which could with 50/50 probability be either of two infants because what's there follows alternative 1 which assumes I will know who's who & merge the John of one of the baptisms with the John of the burial with no error - because picking apart erroneous merges is a complete pain. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Steve You can create ANY field ie call it EVENT if you want to and the search on that .... As I said before download the demo and have a play ! Regards Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Hayes Sent: 29 May 2011 17:38 To: [email protected] Subject: Re: Event-based database software for historians, biographers and genealogists - redux On Sun, 29 May 2011 17:05:26 +0100, "Harrison Genealogy" <[email protected]> wrote: >Steve > >Yes it will ... I give all those persons I've identified a Personal >Reference No and then just do a search for that unique number. But a person is not the same thing as an event. You are not your best friend's 21st birthday party, even if you were present at it. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk ------------------------------- To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message

On Sunday 29 May 2011 19:15, Steve Hayes ([email protected]) opined: > On Sun, 29 May 2011 12:46:21 -0600, Bob Melson <[email protected]> > wrote: > >>It appears, however, that Cousin Mortimer's record will result in a >>unique ID on every machine on which a *ID is generated, so for N copies >>of the >>record on N machines there will be N unique identifiers. And that raises >>a question about the utility of those identifiers - if every one is >>unique, how do/can we know that they refer to the same record? > > And if you merge two of those records, believing that they are same > person, will the resulting record have TWO unique identifiers? > Well if your merge works like the ones I'm familiar with, you have a choice of which fields of Record B to merge into Record A, so you could use A's *ID or B's. Or you could delete both and cause yet a third to be generated. At this point, dunno quite WHY you'd want to preserve the *IDs in a merge, not least because they serve no purpose in, ummmm, validating the records. *IDs are just large numbers, the utility of which in genealogy appears to be undefined. Swell Ol' Bob > > -- > Steve Hayes from Tshwane, South Africa > Web: http://hayesfam.bravehost.com/stevesig.htm > Blog: http://methodius.blogspot.com > E-mail - see web page, or parse: shayes at dunelm full stop org full stop > uk -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine

On May 29, 11:23 pm, Ian Goddard <[email protected]> wrote: > So someone transcribes a record of ol' Mort & writes out his surname > with a capitalised initial because that's what's in the original and > someone else transcribes the same record exactly except that they give > the surname in upper case because that's the convention they adopt. > Oops! Different checksums. [snip another similar example] The problem exists the other way around, too. Suppose I want to record that a relative (but I've forgotten exactly who) told me that my grandfather had a second-cousin called John Smith who lived in London. There must be lots of John Smiths in London, many of whom are second cousins to someone's grandfather, so we get the same checksum for several different people (or for anecdotes about different people if the checksum applies at the source level). Even if "my grandfather" is always interpreted as *my* grandfather, rather than the author's grandfather, it's quite possible that it might still refer to multiple people. After all, it's a common name; doubly so in the family of someone with the surname Smith. > I think there are two separate issues.  One is the unambiguous > identification of the same publication and the other is its authentication. > > The latter is the more difficult.  Not only are there the sort of > problems I've outlined above but also the problem of maintaining a PKI > (public key infrastructure). > > When I suggested what was, in effect, a distributed database using > exchanges of UUID-labeled XML records I considered the possibility of > digital signing.  On balance I decided to leave it out as: It's not a trivial problem, but large parts of it have been solved. "XML DSIG" is a good search term for more information. > 1. XML introduces even more variations.  Consider, for example; > > <EmptyTag></EmptyTag> > <EmptyTag/> > > both of which are equivalent but will checksum differently. There's something called XML Canonicalisation that handles all of the low-level aspects of this. There may still be a need for application- level canonicalisation, if there are several ways of expressing the same information, such as: <persona id="p1"> <name>John Smith</name> <relation type="father" ref="p2"/> </persona> <persona id="p2"> <name>George Smith</name> </persona> and <persona id="p1"> <relation type="father"> <persona id="p2"> <name>George Smith</name> </persona> </relation> </persona> > 2. The PKI would also have to be distributed. Most such infrastructures are already distributed. I think implementing a new PKI from scratch would be a lot of work for no obvious benefit, when compared to using an existing PKI. > 3. If someone did decide to massage a record they could simply re-sign > it with their own private key so the advantages could be illusory.oul They've signed it with their private key rather than the original source's private key. This is easily detectable. Of course, if they were the original source and have subsequently decided to alter it and resign it, that's not something you can detect. But the point of cryptographic signatures is to allow you to verify that the data is the form the author sent it in, not to verify when the author produced it and whether he's subsequently altered it. Richard