[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: persistent identities

> From: "Perry E. Metzger" <perry@piermont.com>
> The Swiss Bank's decision procedure in this case is simple:
> "he who can sign with the private key associated with the public key
> associated with this account at our bank may make deposits and
> withdrawals, or change the public key bound to the account". The bank
> is free to bind an account number to that public key so that it may
> maintain continuity of accounting records across key changes, or not
> to, as its computers and programmers prefer.

The bank's internal procedures are largely irrelevant.  The purpose
of a certificate is to convey information from an issuer (the bank)
to a relying party (the merchant) to allow a subject (the account holder)
to do something without requiring the relying party to contact the issuer
every time.  If the certificate does not contain a persistent identity
managed by the issuer, then the relying parties all have to do the
bookkeeping if they wish to ensure continuity across key refreshes
(using something like the mapping auth that started this discussion).

> In any case, as has been mentioned here in the
> past, this isn't the X.509 bashing or discussion list, its the SPKI
> list.

The PKIX (X.509) community has already learned something from the SPKI
community - that the user's counter-signature on a certificate may be

If the SPKI community believes that there is nothing of value to be
learned from X.509, fine.  However, there may be some SPKI users who
are open to ideas, regardless of their origin.  I was addressing my
comments to them.