X9.59 mailing list


x959 Postings and Posting Index,
next, previous - home

e-signatures in NY
privacy issues
Merchant Comfort Certificates
Updated combined security glossary with RFC2828
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
Merchant Comfort Certificates
misc other DNS
another view of certificates
Domain Name integrity problem
Domain Name integrity problem
BCP 40, RFC 2870 on Root Name Server Operational Requirements
Visa Delicately Gives Hook to SET Standard
Visa Delicately Gives Hook to SET Standard
LB#12 Protection Profiles
RFC 2807 published today XML Signature Requirements
RFC 2807 published today XML Signature Requirements
RFC 2807 published today XML Signature Requirements
VISA 3D-SSL

e-signatures in NY

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: e-signatures in NY
one of the things that we've been looking at for some time for hardware tokens ... having a hardware token signing data indicate whether the (PIN) activation was specifically for the specific signature operation or if the token had been activated and had signed several transactions since the activation (i.e. if there are multiple authentication requirements & methods ... then it is possible that something as simple as the activation mode needs to be included in the data being signed ... contributing to the auditable characteristic of the operation).

It is possible to imagine a PC with a smartcard reader ... and some number of transactions just want to verify that the correct hardware token has been activated and is resident in the reader ... (transient authentication operations ... where there could be whole series) and other transactions with long lived implications ... the signing not only authenticates but possibly carries with it some longer term "authorization" implication (like in the case of an X9.59 transaction).

One of the issues is not to fall into the copy-protection trap from the mid-80s where specific floppy disks were required to be in the floppy reader in order for specific applications to operate ... and it was possible to have tens of such floppy disks and the possibility of continuous shuffling of different disks into & out of the reader every few minutes (or seconds) .... aka 50 or 60 smartcards each with different mode & function ... some requiring simple PIN-activation and others requiring PIN-authorization for each use ... and person having to find the specific smartcard for the specific function and swap the appropriate cards (and of course, power on/off alwas forces an activation operation).

If there was sufficient card swapping going on ... then might as well give up on the idea of multiple signing per activation ... since the probability of a card being continuously powered from one use to the next can drop significantly. While it is still possible to have open, interoperability between hardware token authentication requirements like
financial transactions
document signing
ISP login/connection
Website access


the mechanics of a single reader and potentially hundreds of different cards with different authentication modes & requirements gets lost. Even going to two readers, one for multiple signings per activation and one for single signing per activation is problamentical if the user still has to shuffle thru tens or hundreds of different cards.

Typically these things need to be looked at from the standpoint of several different vectors or you wait until deployment and start to discover many of these issues after the fact.

Ben Wright <:Ben_Wright@XXXXXXXX> on 03/30/2000 10:27:15 PM
Take a look at New York's new regulations on electronic signatrues at
http://www.oft.state.ny.us/esra/esra.htm
They feature a new twist.

As we've seen in numerous other states (California, Texas, Colorado, Nebraska and more), New York said an e-signature needs to be unique to the signer, under his sole control, verifiable and revealing of alteration. But notice that New York goes on to make explicit a critical element that has not been so explicit before. New York says the signature must also be "intended by the party using it to have the same force and effect as the use of a signature affixed by hand."

The extra step is important, especially when dealing with unsophisticated signatories like consumers. A secure identifier like a key or a token -- regardless of how good it is at identifying you -- should not be legally effective if you did not intend it to be your signature in a way that you understand a handwritten signature to be effective.

I (ever so humbly) believe there is a practical implication in this for companies who want good e-signatures from unsophisticated parties. The implication is that workable e-signatures are about more than just collecting proof that a security device (PIN, private crypto key, biometric identifier or what have you) was invoked. Workable e-signatures are also about collecting and archiving information about the environment in which the document was presented, the prompts that were displayed to ask for the signature and the cues that were given to inform the signer what the signature's purpose was and which document was the object of attention. As a practical matter, the final record of the signed document needs all this contextual information just as much as it needs the security device.

In other words, when the alleged signer is unsophisticated, a PKI digital signature bound to a document is not worth much by itself. To be worth anything, it needs to be bound with a rich audit trail.

But I'd be interested to hear what others think.

--Ben 

Benjamin Wright
Attorney & Author of The Law of Electronic Commerce
Dallas, Texas
tel 214-403-6642
ben_wright@xxxxxxxx

http://pki.bigstep.com

privacy issues

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: privacy issues
AADS addresses these same privacy issues. In the discussion regarding open vis-a-vis closed systems ... one could make the claim that identity certificates are only a closed-sysetm solution because of the privacy issues.

http://www.zdnet.com/zdnn/stories/news/0,4586,2523596,00.html

misc. other refs.


https://www.garlic.com/~lynn/aepay2.htm#aadspriv
https://www.garlic.com/~lynn/98.html#4
https://www.garlic.com/~lynn/aadsmail.htm#mfraud
https://www.garlic.com/~lynn/aadsmail.htm#comfort
https://www.garlic.com/~lynn/aadsm2.htm#keylength
https://www.garlic.com/~lynn/aadsm2.htm#privacy
https://www.garlic.com/~lynn/ansiepay.htm#privacy
https://www.garlic.com/~lynn/aepay2.htm#privrules
https://www.garlic.com/~lynn/aepay2.htm#morepriv

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Merchant Comfort Certificates
attached from recent CERT Advisory CA-2000-10

there was some related discussion about merchant comfort certificates at


https://www.garlic.com/~lynn/aadsm2.htm#scale
I. Description

Digital certificates are small documents used to authenticate and encrypt information transmitted over the Internet. One very common use of digital certificates is to secure electronic commerce transactions through SSL (Secure Socket Layer). The kind of certificates used in e-commerce transactions are called X.509 certificates. The X.509 certificates help a web browser and the user ensure that sensitive information transmitted over the Internet is readable only by the intended recipient. This requires verifying the recipient's identity and encrypting data so that only the recipient can decrypt it.

The "padlock" icon used by Internet Explorer (as well as Netscape and other browsers) is an indication that an SSL-secured transaction has been established to someone. It does not necessarily indicate to whom the connection has been established. Internet Explorer (and other browsers) take steps to warn users when DNS-based information conflicts with the strongly authenticated information contained in the X.509 certificates used in SSL transactions. These warnings are supplemental information to help users decide if they're connecting to whom they think they are connecting. These steps and warnings are designed to protect against attacks on the DNS information.

Descriptions of the problems provided by Microsoft are shown below.

IE fails to validate certificates in images or frames

When a connection to a secure server is made via either an image or a frame, IE only verifies that the server's SSL certificate was issued by a trusted root - it does not verify the server name or the expiration date. When a connection is made via any other means, all expected validation is performed.

IE fails to revalidate certificates within the same session

Even if the initial validation is made correctly, IE does not re-validate the certificate if a new SSL session is establish with the same server during the same IE session.

We encourage you to read Microsoft Security Bulletin MS-039 for additional details provided by Microsoft. This document is available at


http://www.microsoft.com/technet/security/bulletin/ms00-039.asp

II. Impact

Attackers can trick users into disclosing information (such as credit card numbers, personal data, or other sensitive information) intended for a legitimate web site.

III. Solution

General Recommendations When Using SSL

DNS information is fundamentally insecure, and there are a variety of means by which an attacker can provide false or misleading DNS information, even in the absence of any vulnerabilities in a DNS server. Browsers attempt to compensate for this insecurity by providing warning messages when the strongly authenticated certificate information does not match the DNS information. While we strongly recommend that you stay up to date with respect to patches and workarounds provided by your browser vendor, we also encourage you to take the following steps, particularly for sensitive transactions.

Check Certificates

The CERT/CC recommends that prior to providing any sensitive information over SSL, you check the name recorded in the certificate to be sure that it matches the name of the site to which you think you are connecting. For example, in Internet Explorer 5 (for Windows), double click on the "padlock" icon to engage the "Certificate" dialog box. Click on the "Details" tab to see information about the certificate, including the thumbprint. Click on the "Certification Path" tab for information about the certificate authority that signed the certificate. If you do not trust the certificate authority or if the name of the server does not match the site to which you think you're connecting, be suspicious.

Validate Certificates Independently

Web browsers come configured to trust a variety of certificate authorities. If you delete the certificates of all the certificate authorities in your browser, then whenever you encounter a new SSL certificate, you will be prompted to validate the certificate yourself. You can do this by validating the fingerprint on the certificate through an alternate means, such as the telephone. That is, the same dialog box mentioned above also lists a fingerprint for the certificate. If you wish to validate the certificate yourself, call the organization for which the certificate was issued and ask them to confirm the fingerprint on the certificate.

Deleting the certificates of the certificate authorities in your browser will cause the browser to prompt you for validation whenever you encounter a new site certificate. This may be inconvenient and cumbersome, but it provides you with greater control over which certificates you accept.

It is also important to note that this sort of verification is only effective if you have an independent means through which to validate the certificate. This sort of validation is called out-of-band validation. For example, calling a phone number provided on the same web page as the certificate does not provide any additional security.

The CERT/CC encourages all organizations engaging in electronic commerce to train help desk or customer support personnel to answer questions about certificate fingerprints/thumbprints.

Note: Microsoft Internet Explorer 5, Macintosh Edition, does not provide any means by which users can validate certificates by checking the fingerprint/thumbprint. Our conversations with Microsoft indicate that the Macintosh version of Internet Explorer is not affected by these specific problems, however, because of the fundamentally insecure nature of DNS, we recommend using a browser that does allow users to validate certificates on whatever platform they use, including MacOS

Updated combined security glossary with RFC2828

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Updated combined security glossary with RFC2828
I recently updated the combined security glossary with RFC2828 (internet security glossary) at:


https://www.garlic.com/~lynn/secure.htm

In march, I had also updated the combined payment glossary with changes found at FRB Chicago:


https://www.garlic.com/~lynn/payment.htm

which is also reflected in the combined financial glossary:


https://www.garlic.com/~lynn/financial.htm

glossaries & other references:


https://www.garlic.com/~lynn/

RFC2828.txt at:


http://tools.ietf.org/html/rfc2828.txt

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
one of the issues with integrity problems with SSL and merchant comfort certificates is various security problems with DNS.

part of a roadmap for turning DNS into more secure facility is the (out-of-band?) registering of public keys in DNS database. Registering public keys in DNS database starts to turn it into an account authority digital signature operation. With public keys in the DNS database, there could be the option of returning the public key as part of doing the host->ip address resolution. Getting the public key as part of the host->ip address resolution then makes the transmission of a public key in an appended (merchant comfort) certificate, redundant and superfluous (as part of SSL handshake).

misc. url refs:


https://www.garlic.com/~lynn/aadsm2.htm#mcomfort

https://www.garlic.com/~lynn/aadsmail.htm#comfort

https://www.garlic.com/~lynn/aadsover.htm

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
at issue are (at least) the integrity of the DNS service, the integrity of the DNS operation, and the integrity of the DNS information. the existing SSL infrastructure is currently based on an assumption of integrity of DNS information & matching some level of that information with some information in a certificate.

Improving the integrity of the DNS service, the DNS operation, and the DNS information has included adding public keys as part of the DNS infrastructure (signed/authentcated DNS operations, signed/authenticated DNS access, signed/authenticated DNS updates, etc). Assuming that the DNS information can be made secure ... then there would be higher level of confidence that the information from a certificate that is used to match DNS information is correct (in a SSL operation ... i.e. the host name that I believe I'm talking to for an SSL merchant site ... corresponds to the host name offered in the appended certifcate ... and the internet host names correct operation infrastructure is based on DNS correct operation).

However, achieving that level of integrity also has keys being registered. If the keys are registered ... and if correct DNS operation is (in part) based on having those keys (and if SSL correct operation is based, in part on DNS operating correctly) ... then the merchant comfort certificates (as part of SSL) can be shown to be redundant and superfluous.

Or conversely ... your argument is equally applicable to existing SSL comfort certificates dependent on internet host name conventions which is in turn, dependent on the integrity of correct DNS host name operation (i.e. matching the host name in a certificate with the host name that I used in a call to DNS resolve). If the integrity of DNS operation is out of the question, then DNS resolution of a hostname is out of the question ... then matching the hostname in a certificate against a hostname in a URL provides little security purpose i.e. SSL does two things in checking to see that I'm really talking to the merchant site that I think I'm talking to ...

1) it cross checks the hostname (or possibly a partial hostname with wildcard) that I believe I'm talking to with the hostname provided in the supplied certificate. I've talking to a host because I've talking the supplied URL, parsed the hostname from the supplied URL and called DNS to revolve the hostname to an IP-address. I've then used the DNS supplied IP-address to connect to a merchant web site. the merchant web site then sends me back a certificate ... that includes (among other things) the mrechants hostname and the merchants public key. I take the hostname that I originally passed to DNS for internet address resolution and compare it against the hostname information in the certificate. If they match ... then there is some chance that I'm really talking to the site that I think I'm talking to

2) the passed certificate is validated ... i.e.the signature on the certificate is validated, checked against CA public key, etc. The public key is then extracted and messages encrypted and/or signed by the sending entity are validated using the public key in the signed certificate.

If the integrity of DNS is improved, in part, by out-of-band registeration of public keys ... then there is some improved level of assurance that the site I believe I'm talking to improves (i.e. the hostname to ip-address translation supplied by DNS is correct). If if is possible to start to rely on that information as being correct ... then it is possible that DNS can distribute both correct ip-addresses as well as correct public keys as part of correct internet operation. If DNS can be relied upon as being correct (i.e. certifying the correct operation of the internet) .. then SSL certificates that independently attest to the mapping between public keys and host names becomes redundant and superfluous.

in effect, each DNS resolution (with both a supplied ip-address and public key) can be viewed as a mini-certification (lets not go so far as to say full blown certificate) giving the binding between hostname, ip-address, and public key. For things to operate correctly, there has to be a binding between all three pieces, hostname, ip-address, and public key.

SSL currently uses DNS to provide the binding between hostname and ip-address and a comfort certificate to provide a binding between hostname and public key. Having a reliable DNS ... will allow providing a reliable binding between the triple, hostname, ip-address, and public key (actual network traffic is based on ip-address).

In effect, most PKIs provide valid certificates issued from a known list of valid certification authorities, some external reference information, and a public key.

As mentioned in the CERT notice, browsers (& SSL) have a long list of acceptable certification authorities. Standard browser SSL operation checks for valid, acceptable operation by seeing if the certificate is from any of the acceptable certification authorities and then if the hostname in the certificate corresponds to the hostname passed to DNS for correct resolution.

"Lewis, Tony" on 06/06/2000 01:55:01 PM
My impression is that it is the DNS database itself that is insecure. It seems to me that adding security information to an insecure source will not improve security.

Tony

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
... basically in a manner to (out-of-band) loading acceptable public keys into a browser (for acceptable certification authorities) ... public keys could also be loaded with ip-address for initial DNS setup & configuration.

then incoming DNS hostname -> ip-address resolution for correct internet operation can be validated (not certificates needed ... just the public keys in the dns setup & configuration information).

If DNS then registers public keys as part of program to improve its overall integrity ... then SSL which is looking at the combined binding of hostname, ip-address, and public key is addressed with a single DNS operation.

Now, it is possible for electronic commerce, there is interest in doing some authenticated binding other than the SSL-binding between hostname (& DNS ip-address), and public key ... possibly between public key and merchant operation. In that case, there would need to be some non-SSL code would verify transactions involving information bound between public key and some sort of merchant specification (possibly included in a certificate) and table of acceptable specifications.

The CERT notice sort of implied a way of doing such a thing in a indirect, limited way w/SSL by elminated all acceptable CAs from the browswer CA table ... and inserting a possibly private brand CA. Then only the private brand certificates would be automatically acceptable to the browser. If such a private brand was based on very specific electronic commerce certification practice statement (CPS) ... then it would be possible to achieve a contrived electronic commerce specific bonding (not based on SSL directly ... but based on closed environment allowing only specific kind of certificates).

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
a SSL certificate with the DNS name is dependent on DNS to take the DNS name and resolve to an IP address.

In the case of identity theft, there have been instances where licenses have been issued to a name ... where the name didn't actually belong to the person getting the license.

There are various kinds of activities to improve the integrity of the DNS process as well as various naming/licensing process.

"Lewis, Tony" on 06/06/2000 02:34:19 PM
It is as useful as seeing a driver's license for "John Doe".

Tony 

> ----------
> From:   Donald E. Eastlake 3rd[SMTP:dee3@xxxxxxxx]
> Sent:   Tuesday, June 06, 2000 2:12 PM
> To:     ansi-epay
> Subject:     Re: Merchant comfort certificates
>
>
> Just adding keys to DNS doesn't help much but there is a proposed
> standard for securing DNS info with signatures (RFC 2535, etc.).  When
> it will be generally deployed is unclear.  When it is, people will
> have much more confidence in the DNS-name <-> DNS-info binding, where
> DNS info can be network addresses, keys, ets.  But it will not help
> you know whether united.com is United Airlines, or United Moving, or
> United Parcel Service, or ...  You will just be really confident that
> you have the right IP address and perhaps key and other data for
> www.united.com or whatever.  Then again, does "John Doe" in a
> certificate always tell you who it was issued to issued to in a useful
> way?
>
> Donald

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
some opportunity to create a consistent authentication infrastructure with an AADS radius (using radius for both ISP authentication, VPN authentication, and webserver access authentication) along with authenticated DNS information distribution (bindings between hostnames, ip-address, keys, and other types of information). A backend key server could provide a common authentication infrastructure within the structure that majority of the existing internet currently operates (and is dependent on that correct operation)

"Donald E. Eastlake 3rd" on 06/06/2000 02:12:41 PM
Just adding keys to DNS doesn't help much but there is a proposed standard for securing DNS info with signatures (RFC 2535, etc.). When it will be generally deployed is unclear. When it is, people will have much more confidence in the DNS-name <-> DNS-info binding, where DNS info can be network addresses, keys, ets. But it will not help you know whether united.com is United Airlines, or United Moving, or United Parcel Service, or ... You will just be really confident that you have the right IP address and perhaps key and other data for www.united.com or whatever. Then again, does "John Doe" in a certificate always tell you who it was issued to issued to in a useful way?

Donald

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
note the statement is about dominent internet authentication & information distribution infrastructures (RADIUS & DNS) working better &/or more reliably ... since the majority of the basic internet infrastructure is dependent on them for the current operation.

with regard to SSL ... there is a 3-way binding going on ... DNS hostname, DNS returned IP-address,, and public key. Trusted DNS (something that is desirable for general internet operation in any circumstance) can handle hostname, ip-addresses, and public key ... within the domain of things that are bound to DNS hostname & ip-addresses.

That doesn't preclude other types of trusted bindings & information distribution from being deployed (that are independent of DNS related attribute information). Since a trusted DNS is desirable, in any case, ... and the existing SSL/TLS implementation is associated with trusted binding related to DNS operation (hostnames) ... then a more effective solution would to directly have trusted DNS operation (which subsumes having orthongonal operations attest to integrity of DNS related information).

As mention in prior post ... that wouldn't preclude other infrastructures from being developed based on trusted bindings of other types of information ... but it seems to be relatively clearcut that it is desirable for Internet to have a trusted infrastructure, trusted DNS infrastructure & trusted DNS information ... rather than have an independent trusted information binding (possibly) untrusted DNS-related information.

It even makes more sense since the application would be calling hostname resolve ... in order to get back the mapping from dns-related hostname to ip-address mapping ... if that response could not only be relied on ... but also might return any additional integrity information that was available (something that is straight-forward within the existing DNS infrastructure).

general internet standards reference:


https://www.garlic.com/~lynn/rfcietff.htm

or references:


http://www.rfc-editor.org/rfc.html
http://www.dns.net/dnsrd/docs/id.html
http://www.dns.net/dnsrd/
http://whatis.com/radius.htm
http://www.livingston.com/marketing/products/radius.html
http://www.alliancedatacom.com/bay-networks-baysecure-firewall-1.htm
http://www.routerware.com/wan_dl/radius.htm
http://msdn.microsoft.com/workshop/server/feature/vpnovw.asp

Bill_Poletti@xxxxxxxx on 06/07/2000 12:54:54 PM
So do I hear that its your idea to change the entire infrastructure to support this idea rather than come up with a method of authentication that integrates into the existing infrastructure?

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
not at all, there is existing IETF work to incrementally improve the integrity of DNS ... on which much of the Internet is currently based ... and some of those incremental improvements include the use of public keys in DNS.

It isn't my idea at all ... as already mentioned there are RFCs as well as drafts covering the area.

... it is, in fact, method of authentication that incrementally upgrades & integrates into the existing infrastruture

Bill_Poletti@xxxxxxxx on 06/07/2000 04:45:41 PM
So what you are saying is that even though this proposed method does not exist today, its not precluded. So, your idea to IS change the entire infrastructure to support this idea rather than come up with a method of authentication that integrates into the existing infrastructure?

That IS what you're saying.

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
... in point of fact, my observation was just that if the DNS incremental integrity improvements were performend ... then the common practice of SSL/TLS with certificates containing the binding of DNS hostname information to public keys becomes redundant and superfluous. A reliable & trusted DNS infrastructure would directly attest to the validity of the DNS information ... subsuming the necessity of having a trusted third party certify any binding between DNS hostname information and public keys (especially if there are problems with existing DNS infrastructure which could call into the question the basic information).

Then if follows, given that a reliable & high integrity DNS infrastructure was being used for the internet ... and such reliable & trusted DNS infrastructure subsumed the necessity for having a trusted third party certify any binding between DNS hostname information and public keys then the certificates issued by such trusted third parties would be redundant and superfluous.

That isn't to say that trusted third parties might not be useful for providing certified binding between other types of information and public keys ... but given a reliable & high integrity DNS using public keys ... sort of makes it redundant and superfluous for having trusted third parties also certify bindings between DNS hostname information and public keys. Especially since the DNS operation is an online infrastructure and is used repeatedly by all forms of internet communication to establish connections.

The issue isn't whether or not there is an existing authentication infrastructure or not. The issue is that existing SSL certificates invovlve the binding of DNS hostname & public keys ... and that if proposed DNS enhancements for integrity and reliability (for the benefit of all internet operations ... not just SSL operation) ... then certificates that provide trusted bindings for DNS hostname information & public keys become redundant and superfluous ... since by definition ... the reliable and trusted DNS operation would subsume the necessity of needing trusted third party certification of binding between DNS hostname information and public key.

Trusted third party certificates that certify the binding of other types of information might be of benefit ... if there isn't an online, trusted reliable operation that provided the same information already as part of every internet connection setup. However, trusted third party certificates that just certified the binding between DNS hostname information and public key seems to be redundant and superfluous if there was a reliable and trusted DNS infrastructure ... that provided trusted & reliable DNS hostname and public key as part of the standard DNS operation.

No idea to change the entire infrastructure ... just the observation that if some of the proposed changes for reliable and trusted DNS would make the use of SSL certificates from trusted third parties (involving binding of DNS hostname information to public keys) ... redundant and superfluous.

There wasn't even the statement that you must stop using redundant and superfluous SSL certificates (binding DNS hostname information to public keys) ... if you didn't want to ... even tho a reliable and trusted DNS would improve all internet transactions .... not just SSL transactions (besides making such SSL certificates redundant and superfluous).

Bill_Poletti@xxxxxxxx on 06/07/2000 04:45:41 PM
So what you are saying is that even though this proposed method does not exist today, its not precluded. So, your idea to IS change the entire infrastructure to support this idea rather than come up with a method of authentication that integrates into the existing infrastructure?

That IS what you're saying.

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
Hopefully this can be made clearer.

every internet connection tends to make a call to revolve a hostname ... a large majority of those tend to involve DNS in one way or another.

a SSL certificate tends to be some form of such a dns hostname bound to a public key.

SSL session setup tends to start by cross-checking the DNS information in the certificate with the DNS hostname that was used to establish the connection (i.e. call DNS with the hostname to get back an ip-address that was actually used to establish the session). SSL is suppose to barf if the DNS information in the certificate and the DNS hostname used for the session doesn't match.

If the DNS hostname information in the certificate and the DNS information used to establish the connection are the same, then the public key in the certificate can be used to validate some information used as part of establishing the session.

Now part of proposals to incrementally improve the integrity and reliability of the Internet's DNS infrastructure involves public keys.

DNS is already capable of returning information of general kinds on calls to DNS ... not just ip-addresses ... and might include any available public key

The combination of public keys for reliably and trusted DNS and the availability of those public keys ... makes the binding of DNS information to public keys by trusted third parties redundant and superfluous. Not to say you have to stop doing it ... just that it is redundant and superfluous to have trusted third parties providing trusted bindings between DNS information and public keys when a reliable and trusted DNS is providing trusted binding between DNS information and public keys.

Getting back a trusted public key along with ip-address on every DNS hostname could open all sorts of possibilities. This isn't my suggestion for totally changing the authentication of the internet ... this is my observation about the implications of a reliable and trusted DNS involving public keys.

There would be no necessity for connection setup code to get a certificate and check the DNS hostname information with the DNS hostname information in the certificate. Implicit in the DNS hostname resolution operation is the returning of reliable & trusted information regarding the IP-address and potentially a public key associated with that DNS hostname (implicit in the DNS internet operation is that it is getting back useful information ... i.e. the ip-address & possibly other information ... that is bound to a DNS hostname ... for purposes of setting up an internet connection). That is just how the internet & DNS works.

If a public key was also returned as part of standard trusted & reliable DNS ... it would seem to be pretty clear that a certificate from a trusted third party that also did a certified binding between some DNS hostname information and a public key ... is redundant and superfluous ... given that a trusted & reliable DNS is providing the information in real time.

There is no observations about certificates that involve other types of information binding and/or about authentication operations involving attributes other than the DNS hostname information attributes. Other types of certificate authentication operations with other (non-DNS hostname information attribute) types of certificates would not seem to become redundant and superfluous with a reliable and trusted DNS ... just some of the internet initial connection setup operations that involve DNS (where a reliable and trusted DNS can provide the public key information).

Bill_Poletti@xxxxxxxx on 06/07/2000 04:45:41 PM
So what you are saying is that even though this proposed method does not exist today, its not precluded. So, your idea to IS change the entire infrastructure to support this idea rather than come up with a method of authentication that integrates into the existing infrastructure?

That IS what you're saying.

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
to re-interate observations regarding public keys involved in any trusted and reliable DNS

certificates tend to provide binding of some information to public key by trusted third parties that can be used by relying parties (when the information isn't otherwise directly &/or immediately available in a trusted form).

SSL certificates & operations typically involve DNS hostname information

There are proposals and/or work on reliable & trusted DNS for the internet ... part of which would involve public keys.

a reliable and trusted DNS with public keys doesn't create a new authentication infrastructure for the internet and/or obsolute SSL.

a reliable and trusted DNS with public keys would appear to make SSL certificates from trusted third parties (involving DNS hostname information) redundant and superfluous. SSL could make use of the trusted & reliable DNS information directly (including public keys) w/o having to first have it pass thru a trusted third party and turned into trusted third party certificates.

Bill_Poletti@xxxxxxxx on 06/07/2000 04:45:41 PM
So what you are saying is that even though this proposed method does not exist today, its not precluded. So, your idea to IS change the entire infrastructure to support this idea rather than come up with a method of authentication that integrates into the existing infrastructure?

That IS what you're saying.

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
there is nothing in the SSL protocol that says that it is a merchant certificate or a credit card certificate. A DNS hostname SSL certificate issued by any Certificate Authority in a browswers list of CA public keys will satisfactorily create a SSL connection (and turn on the padlock).

a merchant certification to a higher standard level (as mentioned in a previous post) might be contrived by having browsers eliminate all CA private keys in their acceptable list ... and then the end-user only activates CA private keys that have associated CPS that conform to the higher credit card merchant certification program. this is similar to the CERT advisory (in the original post of this thread) that suggests the end user examine the content of every supplied certificate.

the other possibility is having some other protocol or process ... besides SSL perform additional authentication operations associated with the certification ... to achieve some higher level of authentication that straight DNS hostname information. That process might be doing something with a SSL certificate based on (out-of-band) knowledge associated with the CPS of the issuing certification authority.

I wouldn't consider that additional process to be the existing SSL DNS hostname information related authentication. A trusted & reliable DNS infrastructure would still make the existing SSL DNS hostname information authenticated process redundant and superfluous.

Some other (non-SSL) authentication process based on unique attributes of the issuing CA (for instance possibly out-of-band knowledge of the issuing CA's CPS) having little or nothing to do with trusted and reliable DNS information is surely possible. Such a process (say as part of a credit card transaction) wouldn't even need to perform a DNS hostname validation ... it would only need to validate that it is a (possibly generic) merchant credit card transaction certificate ... and the public key, does in fact, validate information supplied by the merchant (and actually conforms to specific standards associated with merchant credit card process ... independent of anything to do with valid DNS hostname information). Such a process need have nothing to do with valid SSL operation and/or valid DNS hostname information validation.

Eric Murray on 06/07/2000 07:25:09 PM
I don't think so.

Authenticated DNS authenticates the mapping between IP address and name. SSL certificates authenticate that an entity is part of one trusted cert hierarchy, presumeably trusted enough to participate in SSL connections. For the typical credit-card over SSL case, that SSL cert is really certifying the server as a reputable merchant. That's a much higher level of certification than just name to IP addr.

I agree that authenticated DNS will make SSL certs better though.

-- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5

Merchant Comfort Certificates

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
... standard DNS typically provides mapping between hostname and other information ... not stricly limited to single ip-address. trusted & reliable DNS easily provides authenticated mapping between hostname and whatever DNS information has available for trusted and reliable operation. trusted & reliable DNS operating with public keys as part of its trusted & reliable operations ... makes any information available that is part of its trusted & reliable operation ... including public keys.

... trusted third parties manufactur SSL certificates that provide binding between hostname & public key. SSL protocol validates that hostname information.

for existing browsers to enforce some other standard of authentication & integrity as part of the SSL operation ... there has to be some sort of out-of-band convention as to what are acceptable certificates to the browsers ... based on something other than matching of DNS hostname information and valid public key operations. the other test that a browser makes in connection with SSL operation and SSL certificates is whether the issuing certificate authority is in the browswer acceptable certification authority list.

higher standard merchant certificates can be contrived with electronic commerce browsers that only contain "merchant certifying" CA public keys in the browsers acceptable certification authority list. These would still only explicitly bind DNS hostname information to public keys ... but there would be hidden, implicit binding of other information (not explicit in the certificate) as to the practices and policies followed by these merchant certifying CAs (aka the information that they are certifying has little or nothing to do with the information in the certificate).

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
my (netscape) browser as delivered has the following "acceptable" signers (see appended list).

In principle any DNS hostname information SSL certificate issued by any certiciation authority in the attached list will be acceptable by my browswer for creation of a SSL "locked" session w/o raising any issue or alarm.

In practice, in the current environment there seems to be little or no practice for SSL certificates to be anything but DNS hostname validated information.

In principle, everybody could be ask to delete all the Certification Authorities in their browsers signing list ... and then only add back in certification authorities that are guaranteed to follow some certification practice policy that meets some "higher" (possibly merchant practices) standard for the issuing of certificates ... haivng little or nothing to do with the validating & binding of DNS hostname information.

==================================================================

current browser certificate "signing" list 
American Express Global CA
BBN Certificate Services CA Root 1
BelSign Class 1 CA
BelSign Class 2 CA
BelSign Class 3 CA
BelSign Object Pbulishing CA
BelSign Secure Server CA
Canada Post Corporation CA
CertiSIgn BR
Deutsche Telekom AG Root CA
Digital SIgnature Trust Co. Global CA 1
thru
Digital Signature Trust Co. Globa. CA 4
E-Certify COmmerce ID
E-Certify Internet ID
Entrust Worldwide by DST
Entrust.net Premium 2048 Secure Server CA
Entrust.net Secure Personal CA
Entrust.net Secure Server CA
Equifax Premium CA
Equifax Secure CA
GTE CyberTrust Global Root
GTE CyberTrust Japan Root CA
GTE CyberTrust Japan Secure Server CA
GTE CyberTrust Root 2
thru
GTE CyberTrust Root 5
GTE CyberTrust Root CA
GTE CyberTrust Secure Server CA
GTIS/PWGSC, Canada Gov. Secure CA
GTIS/PWGSC, Canada Gov. Web CA
GlobalSign Class 1 CA
GlobalSign Partners CA
GlobalSign Primary Class 1 CA
GlobalSign Primary Class 2 CA
GlobalSign Primary Class 3 CA
GLobalSign Root CA
IBM World Registry CA
Integrion CA
KEYWITNESS, Canada CA
MCI Mail CA
National Retail Federaion by DST
TC TrustCenter, Germany, Class 0 CA
thru
TC TrustCenter, Germany, Class 4 CA
Thawte Peronal Basic CA
Thawte Personal Freemail CA
Thawte Personal Premium CA
Thawte Premium Sever CA
Thawte Serrver CA
Thawte Server CA
Thawte Universal CA Root
UPS Document Exchange by DST
United States Postal Service CA
Uptime Group Plc. Class 1 CA
thru
Uptime Group PlC, Class 4 CA
ValiCert Class 1 VA
  thru
ValiCert Class 3 VA
Verisign Class 1 CA - Individual Subscriber - VeriSign, Inc
VeriSign Class 1 Primary CA
thru
VeriSign Class 4 Primary CA
VeriSign Class 1 Public Primary Certification Authority - G2
thru
VeriSign Class 4 Public Primary Certification Authority - G2
VeriSign Class 1 Public Primary Certification Authority - G3
thru
VeriSign Class 4 Public Primary Certification Authority - G3
Verisign/RSA Commercial CA
Verisign/RSA Secure Server CA


===================================================

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
from a slightly different standpoint

=============================================================

from TLS RFC226

This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). This document is intended primarily for readers who will be implementing the protocol and those doing cryptographic analysis of it. The specification has been written with this in mind, and it is intended to reflect the needs of those two groups. For that reason, many of the algorithm-dependent data structures and rules are included in the body of the text (as opposed to in an appendix), providing easier access to them.

==============================================================

The observation is that proposed incremental enhancements (including the use of public keys) to create a reliable and trusted DNS can be leveraged by TLS (and SSL) to achieve the protocol implementation ... making the use of DNS hostname certificates redundant and superfluous (they could still be used ... they would just be redundant and superfluous for this purpose).

That such a reliable and trusted DNS would be providing the necessary information directly & in real time , making it redundant and superfluous for a trusted third party to also provide a service which certifies and binds the same DNS hostanme related information in a manufactured certificate (it could still do so, it would just be redundant and superfluous).

==============================================================

from TLS RFC2246

The primary goal of the TLS Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:

- The connection is private. Symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption.

- The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
note as mentioned before manufactured certificates are certified copies of original information ... that is provided mostly for infrastructures that have no access to the original, online information. these manufactured certificates do have the attributed that they lay around and can get stale with respect to the original copies of the information that they certify.

in order to help with the problem of cleaning up stale, static certificates that have been laying around with stale, static information for a long time, most certificates have some sort of expiration date (chosen in the hopes that the information being certified isn't getting stale faster than the certificates expire date).

if my browser receives a certificate signed by any (non-expired) public key in the browser's signing list ... it will be accepted as a valid binding between the certified DNS hostname information and the supplied public key. The SSL code then will verify that the certified DNS hostname information (from the certificate) is in some way related to the DNS hostname used to setup the current session.

DNS currently has the ability for registering one or more ip-address for a hostname, room numbers, address, latitude/longitude, phone numbers, etc ... and supplying that information in conjunction with the hostname.

As part of proposals for reliable and trusted DNS, public keys would be added to that information (along with public key operations).

DNS does has the advantage of being an online information distribution paradigm (as opposed to the offline, stale, static information copy paradigm used by certificates) and the online operation is being used as part of setting up an SSL session.

The observation then is ... whether the original online DNS information from a reliable and trusted DNS operation that is being performed as part of setting up online Internet sessions ... might be better than stale DNS information from a manufactured certificate that has been certified sometime in the past by some trusted third party (for the moment ignoring custom, closed environment where conventions have been set-up that the stale, static manufactured certificate really represents implicit certification of attributes other than those specified in an SSL DNS hostname certificate ... implicit certification conventions which may or may not be supported by all the CAs currently in my browswer's acceptable signers list)

Netscape actually supports: SSL/network session, e-mail, and software apps. The valid signing list are qualified as to network stie (aka DNS hostname information) certification, email address certification, and software develpment certification. As part of the SSL session setup, a "network site" certified certificate would presumably be signed by an acceptable certification authority qualified for certifying network stie information.

For email operation & verifying email addresses, the signer's certification would have to be valid for email address.

For loading software applets, the signer's certification would have to be valid for software development.

Some of the certification authorities in the valid signer's list are authorized for all three (network site certification, email address certification, & software development certification).

attached is some additional information on the entries in my browsers valid signers list: (expired certificates are marked with a "minus"). 
ABAecom (sub, Am. Bankers Assn) Root CA
ANX Network CA by DST
- AT&T Certificate Services
AT&T Directory Services
  American Express CA
American Express Global CA
- BBN Certificate Services CA Root 1
- BelSign Class 1 CA
- BelSign Class 2 CA
- BelSign Class 3 CA
  BelSign Object Pbulishing CA
(two certificates, one 97-98, the other 97-2007)
BelSign Secure Server CA
(two certificates, one 97-98, the other 97-2007)
  Canada Post Corporation CA
- CertiSIgn BR
  Deutsche Telekom AG Root CA
Digital SIgnature Trust Co. Global CA 1
thru
Digital Signature Trust Co. Globa. CA 4
  E-Certify COmmerce ID
E-Certify Internet ID
  Entrust Worldwide by DST
Entrust.net Premium 2048 Secure Server CA
Entrust.net Secure Personal CA
Entrust.net Secure Server CA
  Equifax Premium CA
Equifax Secure CA
  GTE CyberTrust Global Root
GTE CyberTrust Japan Root CA
GTE CyberTrust Japan Secure Server CA
GTE CyberTrust Root 2
    thru
GTE CyberTrust Root 5
  GTE CyberTrust Root CA
two certificates (96-99 and 96-2006)
- GTE CyberTrust Secure Server CA
GTIS/PWGSC, Canada Gov. Secure CA
  GTIS/PWGSC, Canada Gov. Web CA
GlobalSign Class 1 CA
  GlobalSign Partners CA
(two certificates, 99-2009, 98-2013)
GlobalSign Primary Class 1 CA
GlobalSign Primary Class 2 CA
  GlobalSign Primary Class 3 CA
GLobalSign Root CA
  IBM World Registry CA
Integrion CA
- KEYWITNESS, Canada CA
- MCI Mail CA
  National Retail Federaion by DST
TC TrustCenter, Germany, Class 0 CA
    thru
TC TrustCenter, Germany, Class 4 CA
Thawte Peronal Basic CA
Thawte Personal Freemail CA
  Thawte Personal Premium CA
Thawte Premium Sever CA
  Thawte Serrver CA
Thawte Server CA
Thawte Universal CA Root
UPS Document Exchange by DST
- United States Postal Service CA
Uptime Group Plc. Class 1 CA
    thru
Uptime Group PlC, Class 4 CA
ValiCert Class 1 VA
thru
  ValiCert Class 3 VA
- Verisign Class 1 CA - Individual Subscriber - VeriSign, Inc
  VeriSign Class 1 Primary CA
(three certificates, 96-99, 96-2020, 96-2028)
VeriSign Class 2 Primary Ca
(three certificates, 96-99, 96-2004, 96-2028)
  VeriSign Class 3 Primary Ca
(three certificates, 96-99, 96-2004, 96-2028)
- VeriSign Class 4 Primary CA
VeriSign Class 1 Public Primary Certification Authority - G2
thru
VeriSign Class 4 Public Primary Certification Authority - G2
  VeriSign Class 1 Public Primary Certification Authority - G3
thru
  VeriSign Class 4 Public Primary Certification Authority - G3
- Verisign/RSA Commercial CA
Verisign/RSA Secure Server CA
(two certificates, 94-99, 94-2010)

Merchant Comfort Certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Merchant Comfort Certificates
... also some misc. other information regarding DNS.

For ip-address associated with the hostname ... the records are "address" or a-records.

nominal tcp/ip programming examples (whether for straight tcp session or an SSL over TCP session) ... the browser effectively calls DNS with the hostname and gets back the DNS A-record data. it then uses the data from the a-roecord (i.e. ip-address) to contact the desired host.

there are lots of other types of records that DNS can return (as mentioned previously).

DNS also has supports multiple a-records per hostname ... and if there are more than one, actually returns the whole list of all a-records.

as part of helping get all this browser and webserver started for doing things like credit card transactions ... i got the netscape server people to support multiple DNS "A-records" as part of the (tcp/ssl) connection sequence when the merchant server is contacting a payment gateway.

A simple configuration has a tcp/ip host attached to the internet via a single ip address. However, for availability and/or thruput reasons, a host may actually have multiple independent connections to the internet ... each with their own unique ip address. In a multiple A-record scenerio, if there is a connection failure for the first ip-address in a A-record list, then the code is suppose to retry connections for the other addresses in the list (until successful).

As mentioned earlier, I was easily successful in getting the Netscape merchant server people to implement multiple A-record support when they were putting in the original electronic commerce support (which happened to be SSL thru a TCP connection).

The short-coming was that it took me over a year to get the Netscape browser people to implement multiple DNS A-record support (just like a payment gateway might wish to improve availability and thruput with multiple internet attachments, some of the larger merchant servers also have an interest in improving availability and thruput with multiple internet attaches).

The "initial" response from the netscape browser people was that multiple DNS A-record support was too advanced (this is independent of whether a standard HTTP TCP session is being initiated or a HTTPS/SSL TCP sessions is being initiated). They were just taking the first A-record off the list ... and if the connection failed they initially gave up.

I was even able to pull examples of multiple A-record support out of old archived TCP source libraries (for things like telnet, ftp, etc clients). My only thot was that multiple A-record support examples didn't show up in the standard TCP college text books.

misc. refs:


https://www.garlic.com/~lynn/99.html#16
https://www.garlic.com/~lynn/99.html#158
https://www.garlic.com/~lynn/99.html#159
https://www.garlic.com/~lynn/99.html#164
https://www.garlic.com/~lynn/aadsmore.htm#dctriv

misc. other DNS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: misc. other DNS
The original Netscape e-store was connected to the internet via the netscape corporate T3 link ... into the sprint hierarchy (netscape had a backup T1 link). The original pilot payment gateway was a pair of clustered machines with a pair of firewalls, one firewall went into the uunet hierarchy ... and the other an internet service provided by a company called pagesat.

pagesat had co-lo facility at the MCI hayward location ... 48volt equipment, etc, i had done some work with pagesat earlier ... they offered a usenet satellite feed to a 2' R/O dish, i had got it working (modifying a generic driver to work on both unix and DOS) and co-authored an article on the implementation that appeared in Boardwatch mag. ... misc. ref:


https://www.garlic.com/~lynn/2000.html#38

In any case, one number that might be of interest ... was the average payment authorization round-trip time ... from the Netscape e-store, thru the internet (tracert showed eight router hops from netscape e-store, up thru sprint hiearchby down thru mci or uunet hierarchy to the payment gateway), thru the payment gateway, to merchant acquiring, to issueing authorization credit card transaction ... and back thru the infrastructure to the Netscape e-store ... of under .35 seconds. Of course, there was sporadic internet congestion which could drive specific elapsed round-trip time up.

One of the issues with internet technology is very little of it is telco provisioned and (at least in the early & mid 90s) it was common for ISPs to take equipment (aka routers) offline on sunday for service. one of the large internet merchants using the service did a lot of e-commerce related to sporting events and advertised on sunday afternoon football games (when they would get a lot of traffic). This particular merchant started out only having a single internet connection into a single internet service provider ... which would commonly take their router out of service about one sunday a month during the merchant's prime time usage. It was eventually realized that they needed at least two internet attachments going to two different internet service providers (and the two different internet service providers needed to have totally different equipment servicing patterns).

However, having multiple connections to different ISPs ... with multiple addresses/a-records mapping to the same hostname ... wouldn't do a lot of good ... if the browsers didn't have multiple A-record support.

The payment gateway did have a weekend outage. It turned out the replicated telco links (to different ISPs) ... at one point were both going thru the same conduit ... and one weekend the telephone company took the conduit out to reroute it around some railroad construction.

for list of DNS related RFC ... go to


https://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#)

& then select

DNS from list of acronyms.

... some archived multiple a-record support

from "tn" in module commands.c (dated Oct, 11, 1988) in directory tahoe43/telnet/source (i.e. part of telnet client from bsd tahoe 4.3 distribution) ... example of trying all ip-addresses in a-record list until successful connection (or end of list). 
    printf("Trying...\n");
do {
net = socket(AF_INET, SOCK_STREAM, 0);
if (net < 0) {
         perror("telnet: socket");
return 0;
     }
if (debug & SetSockOpt(net, SOL_SOCKET, SO_DEBUG, 1) < 0) {
perror("setsockopt (SO_DEBUG)");
}

if (connect(net, (struct sockaddr *)&sin, sizeof (sin)) < 0) {
#if  defined(h_addr)          /* In 4.3, this is a #define */
if (host && host->h_addr_list[1]) {
int oerrno = errno;
extern char *inet_ntoa();

fprintf(stderr, "telnet: connect to address %s: ",
                              inet_ntoa(sin.sin_addr));
errno = oerrno;
perror((char *)0);
host->h_addr_list++;
          memcpy((caddr_t)&sin.sin_addr,
host->h_addr_list[0], host->h_length);
          fprintf(stderr, "Trying %s...\n",
inet_ntoa(sin.sin_addr));
(void) NetClose(net);
continue;
         }
#endif    /* defined(h_addr) */
         perror("telnet: Unable to connect to remote host");
return 0;
}
connected++;
    } while (connected == 0);

}

another view of certificates

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: another view of certificates
for another view of certificates

http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY

Domain Name integrity problem

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Domain Name integrity problem
reference regarding maintaining integrity of domain name infrastructure, hijecting reference in attached even affect RSA.


http://news.cnet.com/news/0-1003-200-2093731.html?tag=st.ne.1002.thed.ni

By Stephen Shankland
Staff Writer, CNET News.com
June 16, 2000, 5:25 p.m. PT

Register.com, the second-largest domain name registrar, has acknowledged a security problem that could have allowed people to hijack others' Web sites.

The problem allowed unauthorized access to the security software Register.com and its business partners use to manage Internet site information, such as a customer's contact information or the numerical address associated with a domain name. Spokeswoman Shonna Keogan said the security vulnerability was fixed today.

The security hole could have allowed someone to hijack any Web site that had been registered through Register.com, said Dan Nijs, a Register.com customer. Nijs, a Web site administrator, discovered the security hole.

Hijacking, in which visitors to a Web site are redirected to another of an attacker's choosing, has plagued sites such as Internet.com and RSA Security.

"We're really glad we were able to find out about the hole before any serious damage was done to anybody's domain information," Keogan said.

Nijs found to his dismay this week that he could get access to this privileged software just by copying a Web site out of records that catalog who visits a site. The information was contained in standard "refer" logs that record previously browsed Web addresses. One entry in the log was for Register.com's Web-based administration tool, Nijs said, which came complete with authentication information, or the equivalent of a password.

"If I was the only one who knew about it, it would be no problem," Nijs said. But the vulnerability isn't that hard to take advantage of, he added. "Anyone who knew about this could have shut down a million Web sites."

Nijs found he could get access to Register.com's own domain name information. He said that he also successfully changed his own Internet site's information.

Register.com has registered about 1.5 million Internet addresses; the largest Net name registrar is Network Solutions.

Elias Levy, a security expert who runs the Bugtraq mailing list where Nijs described the problem today, said the bug was a result of sloppy programming on Register.com's part. "They didn't take the security aspect of refers into account," he said.

But Register.com isn't the first to suffer from the dangerous combination of refers and Web-based services that record authentication information in their Web addresses. Web-based email providers also have suffered from overly descriptive Web addresses that allow unauthorized access.

Nijs said a more devious but difficult exploitation of the Register.com vulnerability could have allowed a person to change email routing information. By doing so, a person could intercept all the email a company received, gather information, and then forward the emails to the company. This would make it harder for the company to know someone was snooping around their communications.

Domain Name integrity problem

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Domain Name integrity problem
Note that nominally where somebody applies to a certification authority for a network/SSL domain name certificate ... one would expect that the certification authority would contact the Domain Name authority to validate the Domain name information. That creates an integrity dependency on the Domain Name infrastructure for network/SSL certificates (i.e. hijack a domain name at the Domain Name authority, and then apply for a certificate ... relative confident that a network/SSL certificate would be issued for that hijacked domain name)

As postulated in prior message, improving the integrity of the domain name infrastructure with public keys ... also makes it possible for the domain name infrastructure to reliably distribute such public keys ... which in turn, makes network/SSL domain name certificates redundant and superfluous.

As the subject of the news article indicates, another statement might be made concerning if the integrity of the Domain Name infrastructure is not improved ... could result in compromises in network/SSL domain name certificates; lack of such integrity could lead to hijacking a domain name at a Domain Name authority ... and under the assumption that a certification authority might rely on the Domain Name authority for validating the information in a request for a network/SSL domain name certificate ... then a certificate could be issued based on hijacked information.

BCP 40, RFC 2870 on Root Name Server Operational Requirements

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: BCP 40, RFC 2870 on Root Name Server Operational Requirements
fyi ...

Subject: BCP 40, RFC 2870 on Root Name Server Operational Requirements
Date: Wed, 21 Jun 2000 08:59:23 -0700
From: RFC Editor <rfc-ed@xxxxxxxx>

A new Request for Comments is now available in online RFC libraries. 
BCP 40
        RFC 2870

Title:     Root Name Server Operational Requirements
Author(s):  R. Bush, D. Karrenberg, M. Kosters, R. Plzak
        Status:     Best Current Practice
Date:       June 2000
        Mailbox:    randy@xxxxxxxx, daniel.karrenberg@xxxxxxxx,
markk@xxxxxxxx, plzakr@xxxxxxxx
Pages:      10
Characters: 21133
        Obsoletes:  2010

        I-D Tag:    draft-ietf-dnsop-root-opreq-05.txt

URL:        ftp://ftp.isi.edu/in-notes/rfc2870.txt
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details.

Visa Delicately Gives Hook to SET Standard

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Visa Delicately Gives Hook to SET Standard
Visa Delicately Gives Hook to SET Standard
Wednesday, June 21, 2000
By Jennifer Kingson Bloom

Amid the hubbub of the Visa-MasterCard antitrust trial, the world paid little or no attention to the fact that Visa on Monday officially gave up trying to implement SET, the Secure Electronic Transaction specification for Internet payments, in the United States.

......

see American Banker for rest of article

Visa Delicately Gives Hook to SET Standard

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: Visa Delicately Gives Hook to SET Standard
one way of looking at a transaction involving a number of distributed components is a set of serialized sequential steps with some location acting as a synchronization point or distributed (some of this has been more thoroughly investigated in distributed database arena)..

Since the earliest days of X9.59-related activity (with mapping to 8583 transactions, some of this going back nearly five years) there is a sequence of sequential steps with the issuing bank acting as the "sync" point where both authentication & authorization of the payment is performed by the same business entity at one point. As has been discussed before ... separation of the business responsibilities for authentication & authorization creates gap where fraud & failures can creep in. The wider the separation between authentication & authorization ... the wider gap, the larger the fraud & failure opportunity.

The other scenario for distributed transactions involves things like two-phase commit ... effectively some trusted sync. point where possibly one bank does a debit and another bank does a credit and two-phase commit guarantees the appearance of an atomic operation (both credit&debit either occurs or neither occurs). The sequential process can usually be shown to have the lowest fraud and failure modes ... but there are situations (like different banks possibly needing atomic credit and corresponding debit).

random refs: 


https://www.garlic.com/~lynn/aadsmail.htm#mfraud

https://www.garlic.com/~lynn/aepay2.htm#cadis

https://www.garlic.com/~lynn/aadsm3.htm#cstech6

https://www.garlic.com/~lynn/aadsm3.htm#cstech7

https://www.garlic.com/~lynn/aadsm3.htm#kiss10

https://www.garlic.com/~lynn/8583flow.htm
http://www.tpc.org/faq_TPCD.html#anchor1139088
http://www.tpc.org/articles/HA.html
http://www.subrahmanyam.com/articles/transactions/NutsAndBoltsOfTP.html

http://cryptome.org/iwdmain.htm
http://www.sei.cmu.edu/str/descriptions/dtpc.html
http://www.glue.umd.edu/~pwalczak/introduction_to_survivable_syste.htm
Anders Rundgren on 07/02/2000 03:13:56 PM 
Original SET was a bad idea
New EU-SET will prosper as it can use current Interner-banking authentication
systems instead of requiring local SET certificates/keys and SW.


http://www.visa.de/df/presse/pressetexte/000619_001.htm

Is that he HOOK you refer to?

Apparently the new SET system speaks German, but I guess I can live with that
:-)

Anders

Lynn.Wheeler@xxxxxxxx <Lynn.Wheeler@xxxxxxxx>

>Visa Delicately Gives Hook to SET Standard
>Wednesday, June 21, 2000
>By Jennifer Kingson Bloom
>
>Amid the hubbub of the Visa-MasterCard antitrust trial, the world paid
>little or no attention to the fact that Visa on Monday officially gave up
>trying to implement SET, the Secure Electronic Transaction specification
>for Internet payments, in the United States.
>
>......
>
>see American Banker for rest of article

LB#12 Protection Profiles

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: LB#12 Protection Profilesre:
... possible of some interest to the x9a10 mailing list also (originally distributed in a x9f group) ...
==================================================

Please find attached the FDR comments returned with their Affirmative ballot response on the NWI for the Protection Profile. We will need to consider their comments in our Protection Profile discussion at next week's meeting in Dallas. 
Rick) Richard P. Kastner
Ernst & Young LLP, Security & Technology Solutions
Office: (925) 930-2736   Fax: (925) 977-2996 Pager: (800) 393-4497

-- Forwarded by Richard P. Kastner/NWPacific/AUDIT/EYLLP/US on 07/13/2000 04:31 PM

To: Richard P. Kastner/NWPacific/AUDIT/EYLLP/US@xxxxxxxx
Subject: Re[2]: CLOSED X9/00 - LB #12 , NWI, Protection Profiles for
First Data previously cast a "yes" vote on LB#12 with the following comment:

We would prefer to see the protection profile broken into their independent component business operations and not be totally certificate-centric.

There are some number of other operations where certificates can provide a preliminary sense of trust comfort if there is no other mechanisms available.

For the most part, certificates are stale, static copies of a subset of information normally found in financial account records. They are redundant and superfluous for business transactions that require access to account records.

The financial industry would be better served by protection profiles for their (account-based) financial operations than they would by protection profiles for independent operations that have little or nothing to do with financial transactions.

Ideally the current protection profile proposal could be restructured so that it focused on digital signed transactions, the integrity of recording public keys, the environment that public and private keys operated in, etc. The issue then of whether or not certificates would also be issued within such an infrastructure would become almost incidental.

Note that smartcard specific protection profile has recently gone out on the nist site. Also that spyrus is sponsoring a common criteria and protection profile tutorial at X9F5 meeting on the 17th in Reston. Lynn Wheeler of First Data Corp has some of the related protection profile information available on his web site (garlic.com) where he merged the glossaries from the orange book, common criteria 0.9, common criteria 1.0, common criteria 2.0, NIAP, FIPS and several other sources.

RFC 2807 published today XML Signature Requirements

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RFC 2807 published today XML Signature Requirements
A new Request for Comments is now available in online RFC libraries. 
RFC 2807

Title:      XML Signature Requirements
Author(s):  J. Reagle
Status:     Informational
Date:       July 2000
Mailbox:    reagle@xxxxxxxx
Pages:      9
Characters: 21973
Updates/Obsoletes/SeeAlso: None

I-D Tag:    draft-ietf-xmldsig-requirements-03.txt

URL:        ftp://ftp.isi.edu/in-notes/rfc2807.txt
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.

RFC 2807 published today XML Signature Requirements

Refed: **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: RFC 2807 published today XML Signature Requirements
fyi ..

-- Forwarded by Lynn Wheeler on 07/15/2000 10:38AM ---

Lynn.Wheeler@xxxxxxxx on 07/15/2000 09:50:44 AM

Please respond to Digital Signature discussion

To: DIGSIG@xxxxxxxx
Subject: Re: RFC 2807 published today XML Signature Requirements

while 2807 is currently a "Informational" RFC ... there recently also was a series of RADIUS rfcs (both informational and proposed standard). While nothing in the documents specificantly address digital signature authentication and authoritzation ... in the past, AADS RADIUS implementations have been implemented and demonstrated.

The recent series are RFC 2865, 2866, 2867, 2868, and 2869 The RADIUS HMAC-MD5 message authentication is one place that digital signature could be piggy-backed.

While RADIUS was originally deployed for modem pool routers to authenticate and authorize dial-up connections ... it has seen deployment in other authenticate/authorize scenerios like webserver session authenticate & authorize and even configured connections (leased line, DSL, etc)

some of the RADIUS RFC abstracts

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.

The RADIUS (Remote Authentication Dial In User Service) document [2] specifies the RADIUS protocol used for Authentication and Authorization. This memo extends the use of the RADIUS protocol to cover delivery of accounting information from the Network Access Server (NAS) to a RADIUS accounting server.

RFC 2807 published today XML Signature Requirements

Refed: **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: re: RFC 2807 published today XML Signature Requirements
... fyi

-- Forwarded by Lynn Wheeler on 07/15/2000 10:38AM -----

"Winchel 'Todd' Vincent, III" on 07/15/2000 10:15:16 AM

Please respond to Digital Signature discussion

To: DIGSIG@xxxxxxxx
Subject: Re: RFC 2807 published today XML Signature Requirements

Lynn:
while 2807 is currently a "Informational" RFC ... there recently also was a series of RADIUS rfcs (both informational and proposed standard).

2807 is "informational" because it is the XML-Signature "requirements" document.

The XML Signature group is a joint IETF/W3C activity. I'm not familiar with the IETF RFC numbers, as I've been looking at the W3C versions.

Importantly, the XML-Signatures "specification" is not informational and is in "last call" as is the canonical XML specification. See


http://www.w3.org/Signature/ (generally)


http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/ (XML-Signatures)


http://www.w3.org/TR/2000/WD-xml-c14n-20000710 (Canonical XML)

These are pretty important specifications, because this is what is going to be implemented in software. These specifications have wide-spread industry support.
The recent series are RFC 2865, 2866, 2867, 2868, and 2869 The RADIUS HMAC-MD5 message authentication is one place that digital signature could be piggy-backed.

I'm not familiar with these RFCs. Thank you very much for pointing them out.

Todd

VISA 3D-SSL

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 08/24/2000 07:38 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: craigellison@xxxxxxxx, SET-List <set-discuss@xxxxxxxx>,
ansi-epay@xxxxxxxx
Subject: Re: VISA 3D-SSL
your probably saw it ... but there was a discussion on SSL server-side certificates recently in the ietf-pkix mailing list .... similar to previous SSL certificates ansi-epay discussion and whether or not certification authorities relied on DNS for authoritative information in the SSL certificates ... and if there was any dependency on a trusted DNS infrastructure. The ietf-pkix discussion somewhat started out with the question of whether or not client-side CRL checking of server SSL certificates added any net value.

misc. refs:


https://www.garlic.com/~lynn/aadsmore.htm#client1

https://www.garlic.com/~lynn/aadsmore.htm#client2

part of the previous (ansi-epay) discussion is at


https://www.garlic.com/~lynn/aepay4.htm

&/or


http://lists.commerce.net/archives/ansi-epay/200006/maillist.html

ansi-epay archive at


http://lists.commerce.net/archives/ansi-epay/

ietf-pkix archive at:

http://www.imc.org/ietf-pkix/mail-archive/

Anders Rundgren on 08/15/2000 11:28:34 AM

Craig,

I have (through an undsclosed source) received a PowerPoint of 3D SSL so there exists documentation that should be simple to announce here in this list.

It looks pretty good although the details are very scetchy.

It is defintely the end of fat-client SET and there is no turning back once this infrastructure is in place.

Regards
Anders Rundgren
Senior Internet e-commece Architect


x959 Postings and Posting Index,
next, previous - home