Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next
- home
- Storage & Size of certificates
- Systemic Risk
- IETF PKIX thread on other architectures
- A different architecture? (was Re: certificate path
- A different architecture? (was Re: certificate path
- A different architecture? (was Re: certificate path
- A different architecture? (was Re: certificate path
- A different architecture? (was Re: certificate path
- IETF PKIX CA scaling and SSL
- A PKI for the Internet
- Complexity and Integrity Issues
- more on complexity
- Integrity & Availability
- Anonymity and Integrity
- Identification and Privacy are not Antinomies
- comfort certificates
- Human Nature
- Human Nature
- U.S. & Ireland use digital signature
- U.S. & Ireland use digital signature
- U.S. & Ireland use digital signature
- more authentication & authorization
- EU digital signature initiative stalled
- AADS Strawman
- AADS Strawman ... more detail
- AADS Strawman ... more detail
- AADS Strawman ... more detail
- AADS Strawman ... more detail
- AADS Activity
- On leaving the 56-bit key length limitation
- On leaving the 56-bit key length limitation
- On leaving the 56-bit key length limitation
- On leaving the 56-bit key length limitation
- PKI/KRB
- digital signatures, technology experiments, and service operations
Storage of Certificates
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: Bill.Campbell@xxxxxxxx
cc: cert-talk@xxxxxxxx, narry@xxxxxxxx, set-discuss@xxxxxxxxmerce.Net
Subject: RE: Storage of Certificates
+----------------------------------------------------------------------+
This message was addressed to: set-discuss@xxxxxxxx
+----------------------------------------------------------------------+
... as an aside ... in the AADS model for x9.59 it is only necessary
to store the public key ... in the CADS model it may or may not be
necessary to store the full certificate ... although I do believe that
it would be necessary to be able to provide the full, exact
certificate on demand; whether that is a generated item or pulled for
storage ... i.e. logically a certificate could be stored in compressed
form ... starting with a file-system bit compressing methodology
... continuing on down thru application bit compressing methodology
... and then to application information compressing methodology
... i.e. those information components sufficient to regenerate the
exact certificate.
Logically file-system bit-compression and application information
compression of certificates should be equivalent to outside world
... as long as all were able to exactly render the original.
for related discussion on aads & cads see
https://www.garlic.com/~lynn/
------------------------------------------------------------------------
Brought to you by the CommerceNet Consortium <http://www.commerce.net>,
the premier industry association for companies working together to make
Internet commerce easy, trusted, and ubiquitous.
To: Bill.Campbell@xxxxxxxx
cc: cert-talk@xxxxxxxx, narry@xxxxxxxx, set-discuss@xxxxxxxxmerce.Net
Subject: RE: Storage of Certificates
+----------------------------------------------------------------------+
This message was addressed to: set-discuss@xxxxxxxx
+----------------------------------------------------------------------+
... oh yes, in the x9.59/aads implementation description ... virtual
documents is a form of information compression for passing the
necessary information thru backend legacy systems ... and is analogous
to information compression for storage of data.
------------------------------------------------------------------------
Brought to you by the CommerceNet Consortium <http://www.commerce.net>,
the premier industry association for companies working together to make
Internet commerce easy, trusted, and ubiquitous.
another characteristic of online validation.
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: IETF-PKIX@xxxxxxxx
Subject: [IETF-PKIX] another characteristic of online validation.
Mack Hicks wrote:
I have to voice my agreement with Mike that cross-certification
is not manageable (technical banking term - "scary".))
An example, the trusted relationships between UNIX nodes. One can
make the point that the Rhost kind of trust is similar to the
cross-certification model. Rhost type of trust has done nothing
but get lots of people into lots and lots of trouble.
Cross certification may look OK to field commanders in military
applications. Ya know -"Well that's Sam's group - he and I
played hockey together - Let's trust those guys."
Some people think banks trust each other through their Am Bnks Ass
number (like on the checks). Anyone who has gotten a bounced check
knows this is not the case. Knowing the "naming" and "addressing"
(name constraints!) does not increase the level of trust.
Keeping naming constraints current - or even manageable - is the
full time task for lots of people in the mainframe world.
Keeping that trust (usually in one place - like RACF or ACF2)
is a full time job that often goes horribly wrong.
So, for financial transactions, we are left with on-line status
verification. Is there any bank out there that wants to cross
certify? With whom?
- - - - - - - - - - - - -
Mack Hicks (415) 278-7230 -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <Mack.Hicks@xxxxxxxx>
another characteristic we've been exploring with x9.59 and aads is the
question of systemic risk introduced by inserting a dependency on
some other agency when completing a transaction. imagine a financial
institution with triple redundant implementation at three harden sites
spread around the country ... and now having to go out over the
internet and finding some CA operating in somebody's closet
in order to complete a transaction. How many people would like
to have "whether or not their paycheck got deposited in their
bank account" dependent on if a http "hit" was successful or not.
for some of the discussion see
https://www.garlic.com/~lynn/
A different architecture? (was Re: certificate path
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
Many of the infrastructures involving authorization ... include many
factors in addition to strong authentication, some real-time and some
not. Accont-based infrastructures have been a part of business
infrastructures for some time to bind together the necessary
information necessary to support authorization. The accont authority
digital signature model attempts to integrate public key registration
and digital signature authentication into the core business process
... as opposed to working on ways of figuring out what pieces might be
exportable to a certificate, then realizing that there are real-time
requirements ... which means real-time contact of the CA which is
maintaining various critical information.
As the number of attributes are exported into certificates increases
... and the real-time status of those attributes are required to be
maintained at the CA for authorization ... a CA would eventually begin
to migrate to becoming an accont authority. The current main
distinction of a CA is that it is maybe 20-30% handling cryptography
for certificates and 70-80% account management. As number of
attributes and real-time status requirements increase ... the role of
cryptography in the CA becomes smaller and smaller ... and the account
management starts to grow to 95+%.
From the financial infrastructure standpoint ... once past toy pilot
stage, it is much more cost effective to start with the most robust
account-management infrastructure in existance today and retrofit the
1-2% cryptography necessary to support digital signature
authentication ... than it is to try and upgrade CAs into
business-critical, industrial strength account management support.
A different architecture? (was Re: certificate path
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: aads & x9.59 (was RE: A different architecture? (was Re:
certificate path services [ was RE: NEW Data type for certificate
selection ? ])
... X9.59 (built on account authority digital signature model) left
financial industiries retail payments committee and on its way for
vote as the industry payment protocol standard.
drafts of x9.59 standard are at ansi-epay@xxxxxxxx mailing
list archive (also my presentation at NISSC a couple weeks ago). url
for the archive and other information on x9.59 and aads is on my
personal web site:
https://www.garlic.com/~lynn/
A different architecture? (was Re: certificate path
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
there are business operations with account-based systems with
>100million entries and raw data in tens of terabytes. for business
process that have to access the account record to complete the
transaction, splitting responsibility for the transaction between an
account infrastructure and a PKI infrastructure ... doesn't improve
availability ... it actually lowers it since now there has to be two
things that are operational for transaction completion i.e.
availability to complete is the product of the availability of the two
infrastructures; for availability to improve, transaction would have
to be able to complete even if the whole PKI infrastructure or the
whole account infrastructure was not operational (and since the
original premise was that at least the account infrastructure has to
be operational for the transaction to complete; adding a PKI
infrastructure can't improve the availibitliy)
A different architecture? (was Re: certificate path
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
PKI tends to represent a binding between some set of attributes and a
public key. Accounts have been used for a long time for attribute binding
in business scenerios.
If the PKI attributes start to take on real-time status requirements for
various business processes ... then a certificate approach will tend to
represent stale status ... and something else must be created to provide
real-time status. If business process completion is dependent on obtaining
that real-time status ... and some of the status has been PKI linked ...
and some of the status is core business process, account-record links ...
then availability is impacted (i.e. attribute status like requiring real
time information on whether a certificate is even still valid).
A different architecture? (was Re: certificate path
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
small note ... from business standpoint ... it might be better explained
that no directories no authentication infrastructure (which is the business
process/requirement) ... a PKI is then a method of implementing that
infrastructure. Part of the problem with starting with PKI as a solution
and then asking what the problem is .... one might might be led into
presuming that some of the existing PKIs deployed for independent pilots
are the structure one would automatically use as an integrated business
solution.
directories actually have other business needs independent of the
authentication infrastructure. in past life, looked at one customer that
had on the order of 6000 RDBMS where 90% of the data was common. schema
integration directory was needed just so that simple things like changing
the name on an account is consistently done thruout the business (side
problem was wide variety of different terms that were used in schemas for
common things like name).
A different architecture? (was Re: certificate path
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
... and the other serious problem that is starting to show up is the
privacy issues related to information that might be in a directory ....
even a name field might represent a privacy concern.
Scale (and the SRV record)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: Scale (and the SRV record)
spent a lot of time on the SSL portion of the web ... 94/95 working
out how to do/deploy electronic commerce operations. Current SSL
infrastructure uses server certificate for key exchange ... not for
authentication. To the extent that there is authentication done ... it
consists of checking the certificate issuer against a list that has
typically pre-installed in the browser (not checking on the
certificate owner). It is one of the reasons that I coined the term
certificate manufacturing .... to highlight manufacturing and
distributing certificates is typically only a small part of what has
become to be considered part of a PKI infrastructure.
I got possibly the first mutual authentication SSL deployed ... before
it was called SSL3. Again authentication was limited to verifying the
certificate issuer. The server certificate was essentially a comfort
device for all the clients ... the client certificates started out
essentially being "relying party" certificates .... but to do more
than simple certificate issuer authenitcation ... i had to check the
certificate owner information against an account database. At that
point it became evident that even relying party certificates were
redundant and superfluous in the transaction since I needed to reference the account
record (which already had copy of the public key, lots of attribute
binding ... as well as up-to-date real-time status).
A PKI for the Internet (was RE: Scale (and the SRV
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV
record))
while the current common certificate infrastructure model is SSL
... which baiscally checks if the certificate has been manufactured by
somebody in the list of known certificate manufactures/issuers (aka
CAs) .... the common authentication model on the internet is logging
on to the service provider.
This one is basically somebody signs up for an account and establishes
a password. When they want to use the internet ... they contact the
router, give their account name and proof of password. The router is
likely running something like radius ... in which case it forwards the
account name and password to an account authenticator.
For PKIX to address the most fundamental of internet authentication
requirements ... could involve the ISP issuing a relying party
certificate with just the account name (sidestepping liability and
privacy issues). The choice now would be would the ISP router accept
the certificate authentication at face-value ... or would it use a PKI
flavor of radius to contact an account authenticator .... for instance
to have more timely information on whether the account is in good
standing.
This is possibly the most fundamental current internet requirement
... and it illustrates again the extremely short step from relying
party certificates to the AADS model ... where if the account has to
be touched as part of the authentication/authoritization ... then it
is easily shown that shipping the certificate with the transaction is
redundant and superfluous (if somebody gives you a copy of something .... how many
million times do you have to send the same copy back to them
... before they realize that they don't have to see the copy if they
are already looking at the original stored in the account record).
Scale (and the SRV record)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: Scale (and the SRV record)
x9.59 attacked different parts of the problem .... in the case of the
common usage of SSL for the buy button .... X9.59 was designed to
insure the integrity of the financial infrastructure using only
digital signature for authentication and not requiring any encryption.
... i.e. while the SSL URL (& certificate) check is interesting
... the common usage for SSL is encryption connection between the
client and browser to protect something.
x9.59 insures the integrity of the financial infrastructure w/o
requiring SSL/encryption for protection. it has the advantage of
doing end-to-end integrity eliminating a lot of the opportunity for
fraud (security 101 teaches that any time you separate authentication
and authorization .... holes/opportunities for fraud open up). x9.59
also has the advantage that it works for all electronic environments
(not simply limited to internet).
one approach to the area that SSL URL checking addresses would be
having ISP boundary routers doing address filtering on origin address
of incoming packets. this can reduce many of the spoofing related
attacks (not just the one caught by the SSL URL checking) and provide
some evidence trail back to attack origins. other is general upgrade
of authentication procedures to public key ... both at boundary points
and infrastructure operations (like DNS).
i believe that public key infrastructure for authentication is good
thing. I believe that basic justification for certificates is to
provide authentication attribute binding for offline operations;
raising offline integrity closer to what online account-based
operations have. introducing certificates into an online account-based
operations can result in lowering the integrity ....
i.e. online account-based operations with public key authentication
(and no certificates) can have extremely high integrity. The
incremental increase in integrity offered by certificates would be
nominal and typically more than offset by the decrease in integrity
created by increased complexity (i.e. complexity all by itself creates
an integrity issue). The addition of certificate to an AADS PKI
.... would represent an integrity issue .... even if the certificate
was totally ignored ... since, at the very least, the level of
complexity is raised. To the extent that the certificate is not
ignored and represents something in the process .... it further
increases complexity (having to check the CA-signing key on the
certificate or checking a CRL represents complexity & integrity
issues)..... and to actually represent a net increase in integrity
there would have to some significant reduction in the account-based
operations (like eliminating the account-related operations
totally). A troublesome area for the elimination of the account-based
operations are real-time attributes and/or sensitive attributes that
raise privacy issues.
A pervasive example in the internet world are ISP account based
operations for internet service. There are real-time issues like has
the account been canceled and/or suspended (for say not paying the
bill). One might consider pre-paid accounts (like pre-paid phone
cards) ... with a certificate that was good for the pre-paid
period. However, accounts still might be cancelled ... which would
need reference to the account record. As soon as I have to touch an
account record .... then having the public key bound in the account
record is simpler and higher integrity than processing information
both in the account record and in a certificate (along with all the
baggage of validating the certificate & certificate infrastructure).
To: ietf-pkix@xxxxxxxx
Subject: Re: Scale (and the SRV record)
,,,, relying party certificates was something that a european
financial institution brought up at NISSC during e-commerce session
(issues addressed were business issues associated privacy and
liability .... wasn't technical issue regarding size or bandwidth,
etc). In discussions afterwards .... the processing flow is almost
identical to X9.59 and AADS .... the difference is that one of these
certificates flows along with the transaction and gets to the relying
party .... where (if they hadn't noticed) they had the original
(i.e. client was appending a copy of the certificate to the end of of
every transaction sent to the relying pary .... which had the original
... easy to show it was redundant and superfluous).
nissc web site is
http://csrc.nist.gov/nissc/1998/
but there is nothing there on that particular discussion.
They also mentioned an evidence server to validate parts of the
infrastructure. That part is also nearly identical to part of an overall
infrastructure that i've been presenting for last 8-9 months (which have
had included europeans in the audience).
A different architecture? (was Re: certificate path
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services was RE: NEW Data type for certificate selection ? ])
in order to complete a transaction/operation ... if a account record
has to be accessed at all (because of real-time, privacy or other
reasons), then seperating attributes into those in a certificate and
those in the account record can, at best, represent redundant and superfluous effort
and significant increase in complexity .... and at worst increase
various kinds of risk and significantly lower availability of the
infrastructure.
there is nothing implicit about partitioning the attributes needed to
complete a transaction/operation into several places ... however, each
such partitioning typically significantly increases complexity and
risk while lowering availability. Reasons for partitioning can include
requirements for account-based operations because of things like
real-time attributes and/or sensitivity/privacy issues associated with
attributes.
the simplest example is an existing online, account-based, electronic
authorization environment (say like an ISP RADIUS environment that
uses passwords for authentication). Contrast in terms of risk,
failure modes, complexity two implementation modes:
1) registering a public key in a RADIUS account record in lieu of a
password, modifying the RADIUS serrver to do digital signature
authentication with the registered public key, and modifying the
RADIUS client to accept a digital signature (in lieu of a password).
2) create a CA, create a CA database, create a CA customer call center
and/or tieing an existing customer call center into the CA database,
getting a signed CA certificate, registering public keys at the CA,
issuing certificates, modifying RADIUS client to accept certificate
and digital signature, modifying RADIUS server to verify certificate
and authenticate CA digital signature on the certificate, checking for
a CRL entry for the certificate, retrieving the CA's digital
certificate, verifying the CA's digital certificate and the digital
signature on the CA's digital signature, checking for a CRL entry for
the CA's digital signature (etc ... possibly on up to the root-CA
tree) and finally accessing the RADIUS account record.
First off, the transaction in neither mode will complete if the RADIUS
server and RADIUS account record is unavailable. However, in addition,
the second mode won't complete if none of the remaining PKI
infrastructure is unavailable (and/or if it chooses to continue in
spite of it being unavailble opens up fraud and risk potential
completing the operation w/o completing the authentication process).
At NISS conference last month a financial institution talked about
migration to relying party certificates because of privacy and
liability issues .... i.e. a certificate containing only the account
number and public key. In this scenerio, the certificate is stored in
the account record when the public key is registered and a copy
returned to the owner. This about reduces privacy, liability,
complexity, risk, availability and fraud exposures to a minimum
(associated with using both a certificate and an account record). At
this point, the question becomes why does the owner have to send a
digital signature and the certificate to the institution on every
operation .... if the institution already has the original of the
certificate. The downside risk is that the certificate signing key at
least becomes a point of attack ... unless the institution totally
ignores the sent certificate and alwas relies on the original in the
account for verifying the account owners digital signature ... in
which case sending the certificate even becomes more redundant and superfluous.
A different architecture? (was Re: certificate path
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: A different architecture? (was Re: certificate path
services was RE: NEW Data type for certificate selection ? ])
there are financial infrastructures that have much higher integrity
than any of the CAs or public key infrastructures (i.e. spending past
six years getting to the point where there is no down time). When my
wife & I were running skunk works in the 80s doing high speed data
transport & high availability product ... i coined the term disaster
servivability (to distinquish from disaster recovery ... requiring hot
operation with geographic seperation).
Part of insuring the integrity of a financial transaction is having
access to being able to complete every transaction. Places have gone
to the point of guarantee that all information is available in a
single place for the completion of the transaction .... bunkering that
single place with no-single-point-of-failure iredundancy and UPS with
diesel back-up; and then replicating the facility at two additional
bunkered sites (any single system at any single site is sufficient to
complete the transaction).
Having transaction completion dependency on any offiste data/function
lowers the integrity .... availability is the product of all the
availability numbers for all things that must be available for the
completion .... redundant availability is one minus the product of the
non-availability numbers. The financial redundent single site
availability number might be five nines (.99999). Triple redendant
geographic survivability then would be 1-(.00001*.00001*.00001). Not
having all information stored at each site necessary to complete the
transaction .... implies that at least two sites have to be
operational ... as well as the communication path between them. The
financial infrastructure has availability number of
1-(.00001*.00001*.00001). The communication path ... even with diverse
routing might be three nines (.999) and the 2nd site mght be four
nines (.9999).
The resulting availability for non-single-site-stored-data then is
something like:
(1-(.00001*.00001*.00001))*.999*.9999
that can be easily shown to be less than .9999 (since it is the
product of numbers that are all less than one ... and at least one of
the numbers is .9999 or less) ... which was the original unacceptable
number for (at least some) financial infrastructure which prompted the
original triple bunkered site with geographic dispersement in the
first place.
The alternative model to reach this level of availability w/o
requiring geographic redundancy with the single-site data model
.... is the simulation of some ECC/FEC possibly R/S 64/80 where all
eighty sites have independent failure modes (some mainframe memory
subsystems do 64/80 ECC). Small problem is resync'ing sites when some
have been offline and their information becomes stale (this is problem
in the three site replication also .... but is somewhat easier with
three ... than it would be with eighty).
In any case, just saying a CA &/or independent certificate directory
has high availability support with no-single-point-of-failure
.... doesn't necessarily show the whole scope of the issue. Taking an
existing operation that has effectively single-site completion
dependency (or even redundnat single-site completion architecture)
... and move to non-single-site completion paradigm ... involves (at
least) the local site, the communication modes between the sites, and
the 2nd site.
There are also issues of partitioning and locality specific failure
modes. An ISP might cover a geographic locality and provides
redundancy to handle availability levels up to major geogrpahic
specific outages .... but doesn't want to be subject to outages
outside local geographic area (i.e. ISP in california would survive
everything up to major earthquake in california ... but doesn't have
to survive a local major earthquake since all of the customers would
be down also). ISPs with geographic locality coverage only has to
survive failure modes that the majority of their customers would also
survive. National or international ISPs can create gegraphic centered
service centers to take advantage of geographic nature of some failure
modes. This gets into an area of failure mode management slightly
different from the raw statisticaly distribution probability mode of
handling failures.
anonymity in current infrastructure
From: Lynn Wheeler
To: micropay@xxxxxxxx
Subject: anonymity in current infrastructure
The financial industry draft standard X9.59 for all account-based
retail payments can provide anonymity ... even at point-of-sale
environments with the appropriate chipcard. Excerpt from overview at::
https://www.garlic.com/~lynn/aadsover.htm
With the appropriate smartcard, X9.59 can work at point-of-sale, even
improving the integrity of the current POS infrastructure, while
eliminating the necessity for any identity information in the payment
transactions (i.e. no name, address, phone no, etc). With the
appropriate smartcard, the account number and the digital signature on
the transaction would be sufficient to satisfy high integrity
requirements. A combination of the appropriate smartcard, digital
signature, and online network provides the financial industry the
necessary components to authenticate consumers at retail locations.
Identification and Privacy are not Antinomies
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: Identification and Privacy are not Antinomies
The X9.59 POS proposal is to use a chip-card to digital sign an X9.59
transaction.
At NISSC 21 in october ... there was a discussion of migration to
relying party certificates because of privacy and liabiilty
issues. Such a certificate could be as little as the account number
and the public key. In some sense, X9.59 extends that even further
... recognizing if the financial institution issued the key-owner a
"relying party" certificate .... then the financial institution
already has the original ... and therefor it is unnecessary to
repeatedly send a copy of the certificate back on ever transaction.
The next stage chip-card then has "on-card" biometrics to verify its
owner for purposes of doing a digital signature. The financial
instution, as part of registration, keeps track of the hardware
environment that houses the digital signing environment and can
perform risk assesment based on assurance level.
The X9.59 protocol is the same regardless of whether it is
point-of-sale, home web, internet, settop boxes, etc. There can be
flexability in the business process and the associated risk assesement
based on registring whether or not a chip-card is used for digital
signing, the assurance level of the chip-card .... and other factors
like if activation requires PIN, on-card biometrics, etc.
In this particular scenerio .... biometrics doesn't represent a
privacy issue .... since the card performs the biometrics ... and that
information is never exposed outside the card (anymore than the
private key .... or if used PIN activation instead ... the card PIN
activation value).
In all the scenerios .... the X9.59 bits flowing end-to-end are the
same ... its the hardware and the business processes at the end-points
that may vary.
Human Nature
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
however as per prior notes ... the idea was to have bodies that
already provide "comfort" to consumers in the physical world ... to
effectively issue statements/certificates to that fact in the
electronic world ... i.e. acquiring banks that have financial
liability for purchases at merchants, FDIC which insures deposits at
banks, goodhousekeeping which provides some guarantee about purchases,
etc. The original statement was about generating comfort certificates
w/o having to create any new buisness processes (& KISS).
Human Nature
From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
.... also many of these comforts cover the whole business operation
... not just whether the web site meets some standard; including
getting your money bank even if the company goes bankrupt ... or other
issues that have little or nothing to do with a web server operation.
Human Nature
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: E-CARM <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
my orietation/observation is that it is normally less costly to build
something from scratch for toy-pilots and/or technology demonstrations
than it is to modify an existing infrastructure. However, in the
transition to real live business ... there seems frequently to be a
cross-over point where it becomes more expensive to create a new
business infrastructure to wrapper independent technology tower
... than it would be to modify existing infrastructure.
an optimization is to recognize the cross-over point where the
independent towers have reached the limit of the usefullness and it
becomes cost-effective to do the business integration.
applied to comfort certificates ... it isn't the issue of the
certificates ... but the comfort ... the certificates are some
manifestation of that comfort. a consumer's perception of a merchant's
web server implementation may be only a trivial piece of the perceived
unknowns involved in dealing with a distant merchant that may be in a
different country on the other side of the world.
U.S. & Ireland use digital signature
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
useful "set" that could use certificates
what i've been calling "comfort" certificates ... issued by acquiring
banks (merchant financial institution) to their merchants ... that the
merchant can present to consumers (somewhat analogous to the card
association stickers you see in merchant windows).
consumers have some level of feeling that the banks stand behind the
merchant financially in case of consumer disputes.
for online we could also go with online AADS database
for comfort information (analogous to calling up the
better business bureau).
this isn't a "default" certificate as people may have been thinking in
terms of TTP certification authority ... this is just a certificate
that testifies/asserts an existing business process/relationship
(between a merchant and the merchant's financial institution).
however, for X9.59 we claim that it will work online, offline,
point-of-sale, settop, etc. one of the offline scenerios is shopping
from a CDROM and then submitting a x9.59 order via email (which can
complete in a single round-trip).
Since the authentication of the merchant information on the CDROM
would be an offline process ... then the solution is a (comfort)
merchant certificate on the CDROM i.e. fits my understanding of the
original design point for certificates ... providing level of
authentication in an offline environment where there would otherwise
not be any authentication at all.
This doesn't require certificates for the consumer since while the
merchant authentication and the ordering is offline ...the processing
of the order by the merchant is assumed to be "online" (in the sense
that the merchant would have an online connection to the financial
infrastructure).
... and of course more background on AADS & X9.59 at:
https://www.garlic.com/~lynn/
U.S. & Ireland use digital signature
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
the highest value for the comfort certificates will tend to be when
the consumer otherwise has the least trust/knowledge of the merchant.
internet transactions are quite skewed with the majority of them
occuring with a few large merchants. Such large merchants might even
be able to get by with self-signed public keys (not even a real
certificate) since the consumers will tend to have some amount of
trust via other paths (prior experience, word of mouth, advertising,
etc).
so while the comfort certificates may apply to the vast majority of
merchants (in terms of numbers) ... they will have the most meaning
for small percentage of total transactions (since the large merchants
representing the majority of the transactions will be accruing trust
via other means).
U.S. & Ireland use digital signature
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: FW: U.S. & Ireland use digital signature
as an aside .... it is also dependent on who needs to authenticate what.
in a consumer/merchant electronic commerce ... the merchant isn't
really interested in knowing who the person is ... but whether or not
the merchant will be paid. In fact, having the merchant identify the
consumer actually raises privacy issues. The real issue in x9.59
electronic commerce transaction ... is 1) not revealing identity
information because of the privacy issues and 2) not seperating
authentication and authorization.
It is not necessary to reveal identity information to merchants ... as
long as the merchantsl have some assurance that they will get
paid. Having the consumer's financial institution both authenticate
and authorize the payment (and notifying the merchants that they will
in fact receive funds) ... satisfies a basic security tenent.
In the consumer/merchant retail space ... (near) anonymous
transactions preserve privacy for the consumer.
In the more complex business/business space, it is likely that more
&/or different due diligence will be required than what is provided
by most certification authorities.
The opportunity is finding the set in electronic commerce where
default certification is sufficient and at the same time doesn't raise
privacy concerns.
Human Nature
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: "E-CARM" <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
CAs in CADS provide a binding between some set of attributes and a
public key. When a subject uses their public key for authentication
what trust do relying parties have in the binding of that
authentication to the bound attributes?
In AADS, the public key registration also provides a binding between
those attributes in the account record and the public key. Third party
trust is less of an issue here since the registering party and the
relying party tend to be the same.
However, it does bring up another dimension ... the attributes bound
in an AADS account record tend to have a direct correlation to the
business process (like remaining balance in a bank account); allowing
the account record with the digital signature to be sufficient to both
authenticate and authorize a digital transaction.
One of the trust issues in business transactions is whether there is
sufficient information (regardless of degree of trust) in the CADS
model to both authenticate and authorize a transaction (for instance,
holding a TTP CA liable if there is insufficient funds to cover a
payment/check payment). If there is inadequate and/or stale
information in the certificate for acceptable authorization, then the
certificate can be inadequate for authorization regardless of the
degree of trust). For majority of business transactions the degree of
trust may be beside the point if the attributes bound have little or
nothing to do with the business process (your checking account balance
six months ago may have little to do with whether a check will clear
today ... and even worse in the consumer/merchant retail space, the
attributes bound may represent privacy issues).
EU digital signature initiative stalled
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: EU digital signature initiative stalled
with regard to PKI, heavy infrastructurs, credit-card ... et al ....
financial industry has x9.59 draft standard for all account-based
payments (debit card, check, atm, crredit, etc) that has digitally
signed transactions w/o certificates. also in recent EU discussion
about certificate use ... there was comment about eu financial houses
using "relying party" certificates because of liability and privacy
issue (including some reference that a x509v3 fully identifying
individual would represent EU privacy problem in many transactions).
in x9, there was an exercise regarding relying party certificates ...
registering a public key with an institution ... the institution
creating a relying party certificate, storing the certificate in the
account record and sending a copy to the key-pair owner .... then in
digital signed account transactions sent to the relying party ... any
appending of the certificate to the transaction is redundant and superfluous
... since the relying party will reference the original from the
account record (negating the requirment to repeatedly send the
certificate copy back on every transaction).
some of the strength of the digital signature relies on the diligence
that the registration authority exercise in establishing the
attributes bound to the public key (and therefor associated with the
digital signature .... whether or not the registration authority
makes the business decision to also manufactur a certificate). In the
financial industry this frequently translates to risk A trivial
fall-out of the non-certificate, account operation is being able to
implement parameterised digital signature risk .... for instance
proportional to the credit-limit for a specific account. parameters
can be software private key environment, hardware token private key
environment, assurance level of hardware token housing private key,
whether hardware token is pin controlled or biometric contolled, types
of attributes bound to the public key, due diligence involved in
establishing attributes, etc.
All of these issues regarding process for registering a key and/or
environment in which digital signatures take place ... are totally
independent of whether a certificate is every manufactured as part of
the process. In the X9 standards draft for all account-based payments,
it is shown that there is significant benefit for having strongly
authenticated digital signature transactions even if an associated
certificate has never been manufactured (and even scernerios where
using certificates may actually decrease the integrity of the
operation).
AADS Strawman
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] AADS Strawman
Date: 12/09/98 10:11:23 PM
I was at a gathering a couple weeks ago where somebody demo'ed an ISO
complient contact card reader that went for something like $2.17. It
got me to thinking about why can't a secure chipcard for digital
signature be inexpensive and compete with magstrip card.
starting from that premise I've been working on a chip-card strawman
that could be ubiquously deployed and supported. It seems like there
has been a problem finding a compeling business reason for a chip-card
(especially in the US with the low telecom rates) .... and that in
search of the compeling business case ... more and more functions are
being thrown into chips, apparently in hopes of stumbling across the
silver bullet. The downside of this is the increase in chip & support
complexity ... driving up the cost and further aggravating the
business case problem.
the strawman proposal is looking at taking the opposite approach to
result in a compeling business case. The draft X9.59 standard (the
only electronic commerce payment standard) relies only on an AADS
infrastructure .... requring only a digital signature to support the
transactions. In previous AADS postings ... I've hypothesised (see
https://www.garlic.com/~lynn/) that a chip-card at the appropriate
assurance level could not only be used in the Internet sphere ... but
the same card could improve the integrity at point of sale w/o
requiring any identification information (i.e. a card that has no name
or other identification characteristics).
The strawman characteristics are:
- tempested
- immune to all known smartcard attacks
- pin-activiated (migrating to on-card biometric)
- tamper-evident with zeroization
- public/private key generated on the card
- private key is never divulged
- public key can be exported
- only function supported is EC/DSS
(elliptical curve version of FIPS186)
The objective is to compete in the magstrip card sphere in both price
and operation; using existing debit card plastics infrastructure to
personalize, record (public) key, mail, and activate card; while still
meeting very high integrity requirements. Almost no memory is required
(pin, and compact, short ECC public & private key) and very little
programming.
The objective is that the card could be used for all AADS operations
.... not limited to just AADS X9.59 payment operations ... supporting
applications (including all the high-value financial applications)
with a (simple) single function. Besides X9.59 AADS operation
... nearly any userid/password infrastructure is converted to AADS by
registering the public key in place of the password.
This userid/password translation to AADS can apply to Radius
authentication (possibly the dominant method used across the whole
internet by ISPs for authenticating their customers connecting to the
internet) as well as numerous of the webserver userid/passowrd
infrastructures. The simplest webserver scenerio involves keeping the
userid in a cookie (much like many systems do today) and replace
entering a password with transaction sent to the digital signature
strawman.
The strawman chip can be deployed in a privacy-neutral package
(i.e. no name, address, identification, etc) and still provide
high-integrity transactions using simple digital signature operation
(along with owner identification to the card).
The next interesting step is to see if it is possible to accelerate
adoption of contactless standard .... allowing the strawman to
be deployed in format neutral packaging. In the contactless
scenerio, a point-of-sale reader would be able to interact with
the strawman chip in almost any packaging:
- card
- watch
- cell phone
- ring
- PDA
The strawman characteristics then would be privacy neutral, format
neutral, high integrity and be simple enough to compete easily with
magstripe. Simple, single function along with multiple applications
support, including many high-value financial applications greatly
simplifies the problem of establishing a compeling business case (ROI
equation with a lowered "I" and a raised "R").
The strawman isn't attempting to address the mobile computing
infrastructure that some of the efforts are undertaking ... but it
isn't precluded from being included in some of the mobile computing
solutions, either as separate chip ... or incorporated into a small
corner of a much larger chip (becomes the basic strong authentication
ubiquous building block).
The infrastructure also lacks systemic risks .... no global secret
keys for operation (typical of many of the stored-value operations)
and no large numbers of cumbersome data objects all signed with the
same private key (typical of the CA-based authentication
infrastructures .... which might also include various identity
attributes raising privacy concerns).
AADS Strawman
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/19/98 09:57:34 PM
chips in magstripe quantities can get very close to the magstripe
price point .... somebody several years ago pointed out to me that
chips tend to $.10/chip in quantity ... you just have to get on the
interesting part of the curve. Also, when you take into account the
fully loaded costs of registration, personalization, mailing, and card
activation .... the plastic part of the equation tends to get absorbed
into all the other costs. Cutting the chip size and complexity by
possibly a factor of four helps with the effort.
AADS Strawman
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/10/98 11:51:49 PM
Taking it from another standpoint, the AADS strawman is attempting to
show cost/benefit of strong authentication function for a large number
of business processes .... and do it at very near the magstripe price
... and the asurance level provided to the infrastructure is
sufficient to justify its introduction even at a one-for-one swap
(ignoring for the moment the possibility of collapsing a large number
of existing authentication cards into a single AADS strawman).
The AADS strawman is an strong authentication chip and bears some
resemblance to smartcard chips. AADS is looking at the business
requirement for strong authentication and the associated value
proposition to the business infrastructures of deliverying a
cost-effective solution for just that single requirement at the
highest possible certified assurance level.
The problem with some of the smartcard solutions in the multi-function
arena is that they all seem to significantly increase the cost and
complexity compared to the aggresive simplification and volume pricing
taken for the AADS strawman .... in addition they impact the certified
assurance level of the delivered strong authentication function
(complexity testing, various types of contamination issues, introduced
viruses, etc).
This isn't a technology in search of a home .... this is a specific set of
business requirements for strong authentication and looking at the best
price/performance solution for meeting that requirement at the highest
possible certified assurance level.
There are a lot of smartcard possible functions .... i just haven't
been able to come up with a good reason for co-mingling the smartcard
functions in the AADS strawman strong authentication solution.
AADS Strawman
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
Date: 12/11/98 08:55:29 AM
- dosn't have to be perfect initially .... just has to be
significantly better risk proposition than current magstripe
- x9.59/aads deploys an infrastructure where the protocol stays the
same and it is possible to parmaterize the risk assesement on a
transaction by transaction at authorization by recording the assurance
level of the card & POS device .... merchants install higher assurance
POS ... or consumer upgrades card assurance level ... update the
associated account records to reflect the assurance level ... and the
authorization process the appropriate thing in the risk assesement of
the transaction. remember this is a business solution not a technical
solution
- not everything has to be perfect day one .... an infrastructure is
deployed that doesn't have to change ...... and it is possible to
accurately rate the assurance level and therefor parameterize the risk
of each transaction as to value of the transaction vis-a-vis the risk
& assurance level.
- both trusted input (PIN input at point of sale) and trusted
output/display (is transaction being signed reflect what is really
presented to consumer) can be an issue. On the parameterised risk
issue .... it is trivial to do things like knowing MCC of toy store,
max. transaction normally done at such MCC, certified assurance level
of termianl being used, normal transaction done by card owner,
assurance level of hardware housing signing operation. One of the
comments about contactless and format neutral ... is that PDA &
cell-phone housings can provide owner based trusted input and trusted
display ... which can just be reflected in various account records and
enter into the risk assesement for transaction.
- attacks on the card don't have to impossible ... just 1) attack
has to cost significantly more than the value limit allowed for the
card/device (part of the parameterised risk) and 2) attack take longer
than normal time to report lost/stolen card. Once the card is reported
lost/stolen ... that public/private key is invalid and new device is
issued. Either and/or both of these significantly reduce the risk &
fraud to the infrastructure.
- lost/stolen reports, change of address and re-issue become a point
of attack on the infrastructure and have to be dealt with
- stronger than magstripe and parameterised certified assurance of
the devices .... is simpler calculation and improved risk management
than some of the neural net stuff done today. POS and signing devices
can be incrementally upgraded and just reflected in the parameterised
risk calculation.
- infrastructure doesn't have systemic risk with global shared-secrets so
attack on a single card has to be done within window that card is normally
reported lost/stolen. this isn't about the perfect technology ... this is
about business requirement and reducing risk &/or better controlling risk
... as well as deploying an infrastructure that can be parameterised and
not needing total infrastructure swap in/out when technology changes.
AADS Strawman
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: [E-CARM] re: AADS Strawman
In many respects certificates are electronic analogs of hardcopy
licenses and credentials in the offline world. 30 years ago, the
credit card industry was using paper booklets of invalid card numbers
that were sent out monthly in support of an offline paradigm. The
credit card industry made the transition to electronic and the
paradigm shift to online all in one step. There could have been the
option of distributing electronic analogs of the invalid numbers
booklet .... but the shift was made to go both electronic and online
at the same time. Instead of doing just the electronic analogy part
while keeping the offline paradigm ... the shift was to an online
paradigm with online verification (which then eliminated the
requirement for invalid lists ... a vestige that is systematic of
offline operation).
certificates for the most part are targeted at sitatuions staying with
the offline paradigm but upgrading the hardcopy licenses/credentials
to electronic.
AADS Activity
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: AADS Activity
A new work item is going forward in X9 to standardize AADS ... and
another new work item is being proposed to do a XML variation on
X9.59/AADS payment protocol
In X9.59 there was a proposal to say something about optional
"certificate" support (i.e. a certificate-based PKI-variation in
addition to an AADS PKI). There was several institutions that strongly
objected on either 1) X9.59 is suppose to be a protocol for all
payments in all environments ... not limited to simply internet
... but also supporting point-of-sale ... as a result certificates
weren't part of a superset protocol and/or 2) for the
internet-specific subset, many institutions felt that they could do a
better job with AADS servers ... as opposed to certificates.
Certificates are in some sense electronic analogs to
licenses/credentials for offline processing paradigm. Thirty some
years ago, credit-card industry was doing monthly mailings of booklets
with invalid credit cards. They had the opportunity to go both
electronic ... and instead of just simply using electronic analogs of
the paper-based world ... they made the shift to electronic and from
offline paradigm to online paradigm in one move ... obsoleting the
requirement for having electronic analogy invalid booklets by doing
online positive authorizations. In a similar fashion, AADS provides an
electronic public key infrastructure in an online processing paradigm
(instead of just doing electronic analogs, but staying with the
offline paradigm).
The awareness of the difference between the offline and online PKI
processing paradigms has become even more pronounced in discussions with
various credentialing and licensing authorities. In the offline paradigm,
the licensing body has no way of knowing the number/amunt and/or type of
reliance on the electronic analog. The shift to both electronic and online
paradigm has higher upfront expense .... but it has the advantage of being
able to track the number and types of references. This becomes especially
appealing to various agencies responsible for licensing/credential
operations that have direct public/consumer interaction (more than
offsetting the additional costs for the online paradigm). Be able to
provide the electronic online paradigm service allows them direct contact
with the consumer/public they are supposedly serving (in some sense
"liability" insurance is a means of highling business processing "bugs" in
the offline model).
as another aside ... have updated much of glossary in this area on the
garlic pages that i maintain (in addition to the IETF RFC & standard
indexing .... also possible to get to garlic from URL point on the RFC
Editor's webpages).
- Internet RFC1983 -- or just: glossary or taxonomy
- Payment -- or just: glossary or taxonomy
- Terms merged from: ACH, FACSNET, FRBC, FRBM, FRBSF, GAO, NSCC, and misc.
- Financial -- or just: glossary or taxonomy
- Warning: Not for light of heart, the combined glossary and
taxonomy is nearly 3 megabytes and has been known to lock up some
browser versions on some platforms (more because of the number of
links than size of files). There are 5000 terms and 6000 definitions.
Terms merged from Payment Taxonomy & Glossary with Chicago Board of
Trade, C Harvey at Duke (Copyright, for non-commercial use only),
MidAmerica Commodity Exchange, New York Merchantile Exchange, New York
Stock Exchange, Office Thrift Supervision, Securities Exchange
Commission, and Treasury Management Association of Canada
- Security -- or just: glossary or taxonomy
- Terms merged from: AJP, CC1, CC2, FCv1, FIPS140, IEEE610, ITSEC,
Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983, TCSEC,
TDI, TNI, and misc
- X9F -- or just glossary or taxonomy
- Terms merged from X9F document glossaries: WD15782, X509, X9.8,
X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69.
Terms added from X9F TG-16 glossary document (identified by lower case
x9 instead of upper-case X9). Original source documents include:
X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23,
x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49,
x9.52, x9.55, x9.57, x9.62, x9.69, x9.xx. (981010)
On leaving the 56-bit key length limitation
Refed: **, - **, - **, - **, - **
SIDE NOTE: The "56-bit key length limitation" discussion somewhat
focused on the encryption key-length limitations of the Wassenaar
Arrangement
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
slight digression ... possibly 99% of the use currently is for
authentication & integrity ... not privacy .... it is just that keeping
information hidden is one way of addressing authentication & integrity.
X9.59 electronic payment protocol standard addressed the authentication &
integrity issue by requiring digital signature on the transactions with the
goal of preserving the integrity of the financial infrastructure with only
the digital signature (explicitly seperating the issues of integrity and
privacy).
example is that majority of online shopping is done in the clear
... and switch to SSL is done only for providing payment information
(i.e. knowing the account number can comprimise the integrity of the
infrastructure with fraudulent transactions &/or identity
theft). Furthermore ... name and address is used to help authenticate
the account number (for things like AVS ... address verification
system transaction). X9.59 demonstrates strong authentication on the
transaction using only digital signature (not requiring name and
address for authentication). As a result, digital signature strong
authentication indirectly contributes to privacy by not requiring
unecessary privacy information in the transaction.
similarly, primary use in ATM infrastructure is also for integrity.
Transaction digital signature is a generalized solution that can
provide end-to-end integrity (which the current information hiding
implementations don't do). In theory, In part, current 56-bit
protection can be percieved as a weakness because attacks represent
integrity attacks. If the infrastructure was changed to digitally
signed transaction (ala X9.59) ... and encapsulated inside cloaked
channels (solely for privacy concerns) ... the perception of the
relative weakness might change (since an attack return-on-investment
significantly changes ... with every transaction having end-to-end
integrity ... an attack would only yield minimal privacy information
... not any ability to do fraudulant transactions).
On leaving the 56-bit key length limitation
Refed: **, - **, - **
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
but does WA make a distinction between cryptography for digital
signature and cyptography for encryption (&/or information
hiding). x9.59 specifically specifies EC-DSS digital signature as
sufficient for preserving the integrity of the financial
infrastructure (and does not require encryption for integrity).
this is a separate issue from the strength of encryption for
information hiding. furthermore, much of the current use of
encryption/information hiding is subsumed by digital signed
transaction with end-to-end high integrity (i.e. longer key lengths
for digital signature for high integrity ... completely orthogonal to
the issue of strength of encryption for privacy).
X9.59 using account authority digital signature has the interesting
characteristic is the public key (as well as various levels of
certificate-based identity information) doesn't ride along on every
transaction ... i.e. AADS just has the basic transaction along with the
digital signature for end-to-end integrity.
SSL just masks the transaction while in-flight thru the internet
.... and doesn't provide any end-to-end integrity.
On leaving the 56-bit key length limitation
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
in the x9.59 financial infrastructure ... the client/consumer
originates a payment instructure and it is operated on by the
client/consumer's financial institution. X9.59 provides end-to-end
integrity on the payment instruction from the client/consumer all the
way thru to the client/consumer's financial institution. The objective
was a payment protocol that was to provide end-to-end high integrity
applicable for all consumer payments in all environments (internet,
atm machines, credit-card, debit-card, point-of-sale, set-top-boxes,
etc). From that standpoint, any possible internet component was
optional. The objective for X9.59 was to preserve the integrity
financial infrastructure for all electronic retail payments
(in so far as X9.59
payment transactions were concerned) using digital signature (and not
requiring encryption for integrity).
solutions just addressing an internet portion/flavor would have never
provided end-to-end integrity for the financial infrastructure
On leaving the 56-bit key length limitation
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: Re: [ECARM] On leaving the 56-bit key length limitation
as specific to internet infrastructure ...there was a thread on the
pkix mailing list about the most pervassive & ubiquious internet
authentication being userid/password implemented by radius (using by
large percentage of ISP for both routers and terminal servers
... from my rfc index:
https://www.garlic.com/~lynn/rfcietff.htm
select Term (term->RFC#) in the RFCs listed by section, and then
select "RADIUS" in the Acronym fastpath
part of the thread is at:
https://www.garlic.com/~lynn/aadsm2.htm#scale
proposed draft for AADS
https://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
I've even heard from at least one place that did a AADS/Radius
implementation for ipsec ... to provide the extra degree of
authentication timeleness (i.e using existing account management
business processes to manage real-time status).
generalized AADS & X9.59 (as well as internet and rfc) standard
information can be found at:
https://www.garlic.com/~lynn/
PKI/KRB
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: re: PKI/KRB
one of the differences between an AADS PKI and a CADS PI is respect to
real time information. The single-sign-on access systems are analogous
to door-badge reader access systems ... which come in both offline
(aka CADS PKI) and online (aka AADS PKI) varieties. The offline
systems tend to be used where there is lower security \concerns and/or
lower value. The online systems tend to have more concerns about being
able to react to realtime security concerns. Both paradigms are
deployed to meet the different business requirements.
Certificates bind public key authentication material to various kinds
of attributes, values &/or permissions. Business has been using
account records to bind authentication material, attributes and values
for eons ... with the advantage that the bindings tend to represent
real-time status/information ... not stale information that existing
at the time a certificate was manufactured. For business processes
that don't have online, real-time requirements, the stale-binding
represented by a certificate is satisfactory. Many business have been
using account records to serve this purposes for ages .... requiring
only that their technology for authentication be upgrading from
shared-secret to public key.
It might be useful to remember that at its core, a CADS has an AADS
implementation somewhere .... with attributes and other characteristic
bindings represented by account record. A CADS has chosen to
manufactur a certificate typically for trust propagation capability in
infrastructures that currently lack authentication business processes.
Both Radius (dominant authentication, sign-on method used by nearly
100% of the ISPs and corporate installations for PPP remote access
(including effectively nearly 100% of home internet & intranet access)
as well as Kerberos-base infrastructures are straight-forwardly
upgraded to AADS PKI .... effectively the shared-secret field in the
account record is upgraded to a public key field.
The original design point for CADS PKI was deployable in offline
electronic infrastructures lacking any sort of authentication
infrastructure (i.e. like offline email). The objective was to be able
to come up with a freestanding infrastructure that would meet the
requirements of an environment that was 1) offline and 2) didn't have
an existing authentication infrastructure. In the offline email case,
the expense of building a new (CADS) authentication infrastructure was
justified on the basis of offline email not having an existing
authentication infrastructure.
However, for infrastructures that have existing authentication
infrastructures, the ease of upgrading the technology in those
business processes from shared information/secret paradigm to public
key paradigm with AADS is a straight-forward business process upgrade
... not requiring the building of new infrastructures ...
. i.e. in answer to the question ... all other things being equal
... a public-key authentication environment is typically considered to
be higher integrity than a shared-secret/information authentication
environment. One of the issues would be all other things being equal
... it is relatively straight-forward to demonstrate that for an AADS
implementation where existing shared-secret fields are upgraded to
public-key. Certificate based infrastructures would at least
introduce new business processes that wouldn't provide the same level
of real-time control (or if it tries ... it will be a account-based
operation making the certificate use redundant and superfluous ... and frequently it
isn't the technical minutia that gets you but the business process
integration).
somewhat ... total aside ... i spent some time at project athena in
the fall of '88 ... and the discussions then of kerberos cross-domain
authentication ... sound very similar to some of the cross-domain
authentication discussions going on today (and it really is the
business processes that can get you).
PKI/KRB original posting:
Dwight Arthur on 04/29/99 02:49:42 PM
To: DIGSIG@xxxxxxxx
Subject: PKI/KRB
Some time ago we started a discussion on this list about single sign on,
and issues were raised about the relative strengths and exposures of
public key versus secret key systems for authentication of identity, and
subsequent management of authorizations. Some of us have spent some time
and many message off of the list working towards a shared vocabulary and a
shared understanding of each other's assumptions. Having reached a
plateau, I would like to come back to this list with the following
observation.
Kerberos, as commonly implemented, relies on a shared-secret for
authentication of a user at session initiation. If, instead, a public key
system were used, wouldn't the effective security be improved?
<Assumptions>
<KeyProtection>
Assuming that adequate measures for private key protection were in place
<PasswordStrength>
, specifically including measures to prevent weak or missing passwords
or PINs for accessing the private key
</PasswordStrength>
</KeyProtection>
<CorroborationOfDN>
, and also assuming that authentication required that the user
demonstrate possession of an authorized key as opposed to just
demonstrating some key which some trusted CA has bound to a DN which
matches the DN of an authorized key
</CorroborationOfDN>
</Assumptions>
-Dwight
----------------------------------------------
p:(212) 412-8687 Dwight Arthur
f:(212) 908-2345 Managing Director: Systems
b:(917) 646-6682 National Securities Clearing
dwightarthur@xxxxxxxx 55 Water Street
http://www.nscc.com New York, NY 10041-0082
digital signatures, technology experiments, and service operations
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: digital signatures, technology experiments, and service operations
One of the things that business appears to be discovering that they
will be a AADS digital signature operation regardless of the type of
digital signature operation they implement.
Currently there have been a number of digital signature technology
expirements that involve
- independent public key registration towers
- stripping the digital signature verification at some network
boundary (frequently at some internet boundary) before passing the
transaction onto legacy infrastructure for processing.
The interesting thing is that every account-based institution that has
looked at migrating from technology experiment involving digital
signed transactions to production service has generated work items to
perform public key registration.
At a minimum, an account-based sevice operation has a customer care
call center that must deal with the account owner. What account-based
infrastructures are finding that if they are going to support
account-related digitally signed transactions, they will need to
register, manage, update, invalidate, etc the account owner's public
key (whether naked public key, or public key encapsulated inside a
certificate) ... even in technology implementations where the service
operation never actually see a digital signature.
In every case that I know of where a large account-based service
operation was involved in digital signature technology experiments
... as part of consideration to move to any sort of production
service, work items were created to register & support the
account-owner's public key in the account-owner's account record. At a
minimum, this was a requirement by the serive operation's call center
as part of account-owner support. This is totally independent of
whether or not any digital signature portion of an account-based
transaction is ever directly processed by the service operation.
It is convenient when doing technology experiments to not have to
modify/touch production systems. This means not having to do
high-integrity support that most large account-based operations
implement as well as providing the service aspect typically associated
with any account-based operation.
However, when moving to production operation it is significantly less
expensive to integrate the digital signature & public key aspects
directly into the account-based operation than to try and upgrade the
technology experiments to the same level as the production
systems. And what is being found, that even if such upgrades are
attempting ... that the service organizations of large account-based
operations will still duplicate the major portions of a digital
signature infrastructure.
For instance, for an AADS infrastructure, the majority of the
AADS-related resource costs go to creating the public key field in the
account record, registering the public key, managing the public key
and having the call center be able to support public key related calls
(the remaining portion of actually doing digital signature
verification in the account-based legacy processing is trivial
compared to managing the public key in the account record). The
interesting thing is that large account-based service operations
appear to be alwas planning on deploying an AADS infrastructure
... regardless of whether it is an AADS or a CADS signature
verification technology that is being used.
This is synergistic with the privacy-mandate direction that is started
with relying-party-only certificates for large account-based
operations, i.e. if a CADS signature verification technology is
involved ... it is with relying-party-only certificates which don't
divulge any consumer privacy information. As a result, any associated
digitally signed transactions have to involve the account record
... since the RPO certificate doesn't contain any directly usable
information. An RPO certificate infrastructure also has the public key
registered with the account-record ... which is consistent with other
business processes in large account-based operations requiring the
public key registration in the account record.
Finally in the X9.59 & AADS scenerio ... it can be shown that the
integrity of the transaction is significantly enhanced by directly
supporting end-to-end digital signature authentation ... where the
agency authorizing/executing the transaction (which includes the use
of an account record) also does the digital signature authentication
(which can also be done using the public key registered in the account
record). This is consistent with the scenerio that the byte-loading
weight of the infrastructures carrying many of these transactions are
measured in bytes and tens of bytes (making it infeasable to support
the transaction carrying weight required by CADS infrastructures
... even in their new compact versions which are still measured in
hundreds of bytes).
Large account-based service operations are realizing that they have to
support account-base public key registration if they have customers
involved in digital-signed account transactions (even in cases where
the srevice operation does no direct transaction digital signature
verification). It is at least a matter of the service-side of the
business ... even if it isn't a matter of the transaction processing
side of the business.
AADS Postings and Posting Index,
next
- home