Potential upcoming features in Java 6 announced

Discussions

News: Potential upcoming features in Java 6 announced

  1. The JDK core engineering team put out an article describing what is slated for inclusion in Java 6, code named "Mustang". A large number of user-requested improvements and bug fixes are being slated in, beyond the high level overview given when the umbrella JSR for Mustang was released in February.

    Notables include: JSR 223 scripting language integration + an embedded Rhino (Javascript) interpreter, extending java.io.File to discover free disk space, an embedded light weight HTTP server, XML Digital Signatures API, JAX-WS 2.0, JAXB 2, JDBC 4, JMX 1.3, and a user-requested improvements and big fixes.

    Threaded Messages (52)

  2. Let the bloat begin...[ Go to top ]

    :|
  3. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless. If something is important, I'll use HTTPS. I see no point of creating a MD5 hash and not using SSL. The spec on W3C feels like they've totally lost focus and touch with reality. If security is critical, I'll use server and client certificate and a good VPN. Less junk to download is a good thing.

    peter
  4. Java Platform[ Go to top ]

    SSL/TLS covers point-to-point security, XML-DSIG covers endpoint to endpoint security. Big difference.

    While the new API's do increase the size of the JRE, they also enhances the Java platform with the ability to develop and deploy web service with Java in a standard fashion.
  5. It's not about encryption it's about signing. For example you could generate XML in client application and allow user to sign it via his private key stored in some external device. Then you will transfer it (encrypted or unencrypted) to backbone, store it and process it. Once somebody will ask you why this and this happend in system you should (in some counteries by law) proove that this command/XML was issued by this person (because it's signed by his private key).
  6. perhaps I'm missing something[ Go to top ]

    It's not about encryption it's about signing. For example you could generate XML in client application and allow user to sign it via his private key stored in some external device. Then you will transfer it (encrypted or unencrypted) to backbone, store it and process it. Once somebody will ask you why this and this happend in system you should (in some counteries by law) proove that this command/XML was issued by this person (because it's signed by his private key).

    I understand it's about signing a package and making sure the package is valid. But my question is this. "why would anyone get a package that is not trusted? or retrieve the package in way that is not trust worthy?"

    peter
  7. perhaps I'm missing something[ Go to top ]

    I hope you're not serious. If you don't understand this question, then don't comment on it. DSIG is used for two purposes: to ensure that a message/package is not modified in transmission, and to ensure the identify of the sender of the message/package.

    You hear stories all the time about people spoofing sites or modifying downloadable content. DSIG's purpose is to protect you from these types of security issues. This is different from encryption whose purpose is to prevent unauthorized people from viewing a message/package.

    Encryption and signatures are used in conjunction with each other to ensure full end-to-end security. See the WS-Security spec for further info.
  8. A lot agree, but one of the main feature of web services is that they can be served at 80 port. So they can't just use https. Signatures is possible but maybe not best solution for xml security.
  9. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless. If something is important, I'll use HTTPS. I see no point of creating a MD5 hash and not using SSL. The spec on W3C feels like they've totally lost focus and touch with reality. If security is critical, I'll use server and client certificate and a good VPN. Less junk to download is a good thing.peter

    The XML signature spec is far from useless - to the people that need it. In combination with a PKI-based timestamping implementation, it has applications in the financial world (invoicing, trade verification) and the legal world (conveyancing and document transfer). Since XML is a de facto format for information transport, a corresponding API for signature creation and verification is in fact very useful.
  10. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless. If something is important, I'll use HTTPS. I see no point of creating a MD5 hash and not using SSL. The spec on W3C feels like they've totally lost focus and touch with reality. If security is critical, I'll use server and client certificate and a good VPN. Less junk to download is a good thing.peter
    The XML signature spec is far from useless - to the people that need it. In combination with a PKI-based timestamping implementation, it has applications in the financial world (invoicing, trade verification) and the legal world (conveyancing and document transfer). Since XML is a de facto format for information transport, a corresponding API for signature creation and verification is in fact very useful.

    Who in the financial world is using this technology ?
  11. Take for example a digital software license in XML. You can specify in XML the nature of the license and its parameters and then sign it digitally. The software can then verify who issued the license and that it has not been modified since it was issued.

    I for one am very pleased that mustang will include a standard API for such an application. I can think of many such examples that are not in any way related to HTTPS.
  12. That makes more sense[ Go to top ]

    Take for example a digital software license in XML. You can specify in XML the nature of the license and its parameters and then sign it digitally. The software can then verify who issued the license and that it has not been modified since it was issued.I for one am very pleased that mustang will include a standard API for such an application. I can think of many such examples that are not in any way related to HTTPS.

    Ok, that makes much more sense, but aren't most businesses already doing this type of stuff their own way? How many businesses are going to change over to XMl security and throw away their existing licensing approaches? I concede this is a valid and useful, but I'd prefer it be optional and not bundled. There's already an Apache project for XML security, so it's not like I can't go up to apache and download it.

    peter
  13. RE: That makes more sense[ Go to top ]

    ...but aren't most businesses already doing this type of stuff their own way? How many businesses are going to change over to XMl security and throw away their existing licensing approaches?
    We are already using XML security for this purpose.
    There's already an Apache project for XML security, so it's not like I can't go up to apache and download it.
    Apache's XML security library doesn't work with all XML parser implementations, including Crimson which has shipped as the default parser for the Sun SDK.

    A standard API for doing common things is always best as you're not tied to a specific implementation. Standards that are XML-centric are likely to be useful to many types of applications since XML is such a core technology.
  14. makes sense[ Go to top ]

    ...but aren't most businesses already doing this type of stuff their own way? How many businesses are going to change over to XMl security and throw away their existing licensing approaches?
    We are already using XML security for this purpose.
    There's already an Apache project for XML security, so it's not like I can't go up to apache and download it.

    Apache's XML security library doesn't work with all XML parser implementations, including Crimson which has shipped as the default parser for the Sun SDK. A standard API for doing common things is always best as you're not tied to a specific implementation. Standards that are XML-centric are likely to be useful to many types of applications since XML is such a core technology.

    From that perspective, it does make a lot more sense, since it means one less thing for you to ship with your product. It also probably reduces the work load for the person managing/handling license generation and validation.

    From a developer perspective, I have jdk 1.2 to 1.5 installed on my system, so I'm just bias and prefer to have smaller distributions.

    peter
  15. yep, at least on the securities services area, XML will not be used before years....SWIFT ISO15022 is the rule; therfore, anything built on top of xml, is then useless.

    Laurent.
  16. Who in the financial world is using this technology ?
    I'm currently working for the project inside quite large bank, and we do use digital signatures in XML for inter-bank messages traffic. Can't tell you more, it's NDA stuff.
  17. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless. If something is important, I'll use HTTPS. I see no point of creating a MD5 hash and not using SSL. The spec on W3C feels like they've totally lost focus and touch with reality. If security is critical, I'll use server and client certificate and a good VPN. Less junk to download is a good thing.peter
    The XML signature spec is far from useless - to the people that need it. In combination with a PKI-based timestamping implementation, it has applications in the financial world (invoicing, trade verification) and the legal world (conveyancing and document transfer). Since XML is a de facto format for information transport, a corresponding API for signature creation and verification is in fact very useful.

    If I understand the response correctly, the proposed use of XML signature is for timestamping. I'm probably missing something, but if I have a document that must be timestamped, I have to certify through some mechanism. So why not just have a signed timestamp in the document, instead of using a MD5 hash on a XML document? What benefit does XML signature have over a simple signature standard that doesn't require Hashing the entire document?

    The reason I ask is this. If I sign a document using xml signature, but then realize there's a typo 5 hours later, I have to re-sign the document. The typo might not be critical, so it seems like a huge overhead to re-sign the entire document if it happens to be hundreds of pages.

    If the signature is suppose to prevent tampering, then I'd say it's solving the wrong problem. If there's an issue with security, then hire people you can trust. if the document is important enough that only authorized people can view and edit, then I'd say that should be handle by process and policy.

    peter
  18. If I sign a document using xml signature, but then realize there's a typo 5 hours later, I have to re-sign the document. The typo might not be critical, so it seems like a huge overhead to re-sign the entire document if it happens to be hundreds of pages.If the signature is suppose to prevent tampering, then I'd say it's solving the wrong problem. If there's an issue with security, then hire people you can trust. if the document is important enough that only authorized people can view and edit, then I'd say that should be handle by process and policy.

    If a digital document is intended to be a binding agreement, then whenever it's changed the system has to force you to sign it again. Or you could sign an amendment (patch) to the document, I suppose, but that seems more complicated to me.

    I don't think this standard is help control the process of your boss signing your expense report after a business trip. This is intended for transactions involving minimal trust, particularly of the transport mechanism.
  19. If I sign a document using xml signature, but then realize there's a typo 5 hours later, I have to re-sign the document. The typo might not be critical, so it seems like a huge overhead to re-sign the entire document if it happens to be hundreds of pages.If the signature is suppose to prevent tampering, then I'd say it's solving the wrong problem. If there's an issue with security, then hire people you can trust. if the document is important enough that only authorized people can view and edit, then I'd say that should be handle by process and policy.

    If a digital document is intended to be a binding agreement, then whenever it's changed the system has to force you to sign it again. Or you could sign an amendment (patch) to the document, I suppose, but that seems more complicated to me.

    I don't think this standard is help control the process of your boss signing your expense report after a business trip. This is intended for transactions involving minimal trust, particularly of the transport mechanism.

    You're right. if the document changes, like a binding contract, it has to be re-signed. But my question is this, "is XML signature is the right solution for this specific problem?" The way legal contracts work, both parties have to sign any significant changes. Usually, lawyers will spend several weeks reviewing changes. to me, this is not the problem XML signature should be trying to solve. I could be totally wrong, but I just don't see how XML signature is better than using plain MD5 + SSL.

    peter
  20. You're right. if the document changes, like a binding contract, it has to be re-signed. But my question is this, "is XML signature is the right solution for this specific problem?" The way legal contracts work, both parties have to sign any significant changes. Usually, lawyers will spend several weeks reviewing changes. to me, this is not the problem XML signature should be trying to solve. I could be totally wrong, but I just don't see how XML signature is better than using plain MD5 + SSL.peter

    Im not an expert, but my understanding is that MD5+SSL will protect the transport and an XML signature will protect the document itself. You can, for example, save the whole signed XML document to a database and prove a few months later that you had a "valid purchase order" because it is sill signed

    Cheers
     JD
  21. You're right. if the document changes, like a binding contract, it has to be re-signed. But my question is this, "is XML signature is the right solution for this specific problem?" The way legal contracts work, both parties have to sign any significant changes. Usually, lawyers will spend several weeks reviewing changes. to me, this is not the problem XML signature should be trying to solve. I could be totally wrong, but I just don't see how XML signature is better than using plain MD5 + SSL.peter
    Im not an expert, but my understanding is that MD5+SSL will protect the transport and an XML signature will protect the document itself. You can, for example, save the whole signed XML document to a database and prove a few months later that you had a "valid purchase order" because it is sill signedCheers JD

    I've not read the XML signature security spec thing, only read a brief description thereof.
    Regarding MD5+SSL for security (encryption and authentication) my question goes as follows:
    SSL+certificate verification on both endpoints of transmission assures that each party can verify eachother's identity as trusted. All nice and dandy. Assume the routing scenario: the message can be contained in a larger envelope that would describe each trusted party that can route the message and still be trusted, correct ? This would work fine when the routers are all known and trusted.
    What if they're not? Then you need to send means of verifying the message's authentication with the message - in the larger envelope.
    This is where my problem with MD5 comes in: MD5 is a hash, that is, if I were to be an un-trusted router I could easily change the message and re-do the hash. Obviously MD5, SHA and what have you are useless. What this means is that you either have to use a HMAC based on one of these hashing functions and share a secret key between the intended endpoints, or use PKI which brings about issues of trusting the public keys as to what they are (rign of trust thing).

    Are these concerns valid ? To sum up, MD5 is useless if the messages gets into wrong hands, and PKI or HMACs are the only things that can indeed be trusted.

    Cheers
    Right, now the
  22. You're right. if the document changes, like a binding contract, it has to be re-signed. But my question is this, "is XML signature is the right solution for this specific problem?" The way legal contracts work, both parties have to sign any significant changes. Usually, lawyers will spend several weeks reviewing changes. to me, this is not the problem XML signature should be trying to solve. I could be totally wrong, but I just don't see how XML signature is better than using plain MD5 + SSL.peter

    I'm not an expert, but my understanding is that MD5+SSL will protect the transport and an XML signature will protect the document itself. You can, for example, save the whole signed XML document to a database and prove a few months later that you had a "valid purchase order" because it is sill signedCheers JD

    I've not read the XML signature security spec thing, only read a brief description thereof.

    Regarding MD5+SSL for security (encryption and authentication) my question goes as follows:SSL+certificate verification on both endpoints of transmission assures that each party can verify eachother's identity as trusted. All nice and dandy. Assume the routing scenario: the message can be contained in a larger envelope that would describe each trusted party that can route the message and still be trusted, correct ? This would work fine when the routers are all known and trusted.What if they're not? Then you need to send means of verifying the message's authentication with the message - in the larger envelope.This is where my problem with MD5 comes in: MD5 is a hash, that is, if I were to be an un-trusted router I could easily change the message and re-do the hash. Obviously MD5, SHA and what have you are useless. What this means is that you either have to use a HMAC based on one of these hashing functions and share a secret key between the intended endpoints, or use PKI which brings about issues of trusting the public keys as to what they are (rign of trust thing).Are these concerns valid ? To sum up, MD5 is useless if the messages gets into wrong hands, and PKI or HMACs are the only things that can indeed be trusted.
    Cheers
    Right, now the

    I would ask this, "if the message gets into untrusted hands, what would be the point of verifying a XML document?" From a business perspective, when it is important, people will use encryption be it PKI, SSL or some other form.

    If I get a document through insecure channels and then attempt to verify the document is good, it's a false sense of security. I have no gaurantee the document was not altered and rehashed. So being an untrusted recipient and getting the document through insecure method means validation is practically worthless. I've read through the xml security spec a few times and it's basically a hash (MD5,SHA) + encryption. If the document is sent over non-ssl or non-vpn channel, it's vulnerable to man-in-the-middle attack.

    having rambled all that. I'm sure there are individuals that really need these technologies. I just question the value of bundling it with the JDK.

    peter
  23. If I get a document through insecure channels and then attempt to verify the document is good, it's a false sense of security. I have no gaurantee the document was not altered and rehashed.
    No, if document has valid sign than it's OK. That's what is guaranteed by specification. Document couldn't be altered and rehashed.
    So being an untrusted recipient and getting the document through insecure method means validation is practically worthless. I've read through the xml security spec a few times and it's basically a hash (MD5,SHA) + encryption. If the document is sent over non-ssl or non-vpn channel, it's vulnerable to man-in-the-middle attack.having rambled all that. I'm sure there are individuals that really need these technologies. I just question the value of bundling it with the JDK.peter
    If you send document over non-ssl channel IT IS NOT vulnerable to man-in-middle attack. Man-in-middle will need your private key. You are totally wrong, and I don't thing you have the least idea how signing works?
  24. correction[ Go to top ]

    If I get a document through insecure channels and then attempt to verify the document is good, it's a false sense of security. I have no gaurantee the document was not altered and rehashed.

    No, if document has valid sign than it's OK. That's what is guaranteed by specification. Document couldn't be altered and rehashed.

    So being an untrusted recipient and getting the document through insecure method means validation is practically worthless. I've read through the xml security spec a few times and it's basically a hash (MD5,SHA) + encryption. If the document is sent over non-ssl or non-vpn channel, it's vulnerable to man-in-the-middle attack.having rambled all that. I'm sure there are individuals that really need these technologies. I just question the value of bundling it with the JDK.
    peter

    If you send document over non-ssl channel IT IS NOT vulnerable to man-in-middle attack. Man-in-middle will need your private key. You are totally wrong, and I don't thing you have the least idea how signing works?

    My fault for being unclear and not thinking clearly. Assuming I hash a document and encrypt the hash using PKI, you're absolutely right it's still safe. If I remember the spec correctly, the recipient needs to hash the contents and apply the encryption on the key. If the two encrypted keys match, then the document is good.

    in my brain fog, i forgot that. The case i was thinking of is when the transmission occurs over insecure channel and the key is also sent on the same channel. In that case, it would be vulnerable to man-in-the-middle attack. If an attacker can get the key, they can rehash and re-encrypt the hash. I'm just paranoid.

    I'm still not clear on how one would use it. If someone is untrusted, does that mean they are using PKI? anyone can use the public key to encrypt the document, but only the holder of the private key can decrypt it. so in this scenario, does it mean the system passing a secure document to an insecure end-point has the public key for the end-point. If that's the case, then one might as well send the message over SSL.

    In the case where the public key of the untrusted party is known, i would agree the message is still secure. Assuming the public key was exchanged through a secure channel. From a business perspective, it still doesn't make sense to me. if I am working with a business and they need to get signed documents, I would much rather send it over SSL. if i don't that third party, why would I bother worrying whether or not they can validate the document?

    most likely I'm missing the subtleties of xml signature and why it is useful for securing documents in the general case. I would like to understand how and why the specification is useful.

    peter
  25. If the document is sent over non-ssl or non-vpn channel, it's vulnerable to man-in-the-middle attack.

    Terribly untrue if you use attach a message authentication code to the message.
    The MAC (say, a HMAC) cannot be re-created without possession of the private key that is shared between intended, authorised recipients.
    For more on the subject I suggest you read the first paragraphs of RFC 2104.

    The basic idea is that you prevent anyone but authorised parties to produce such messages. Should such messages arrive in the wrong hands they may be of little use to the bad guys (for instance, some confirmation messages, correlated on IDs). They contain no value per se, but trigger actions in the receiving system, right? Now, what you really, really care about is that no-one can send fake messages to you. MD5 them and you're lost, someone can conduct a timing attack/mitm or whatever on the SSL link and they'll get the message format out. If you HMAC them and keep the keys really, really secret they're screwed, they won't be able to produce a valid message that they have not seen already (that is, copy/resend it).

    Imagine tiny sensors spread out over a large environment, beaming up radio signals with data packets. The HMAC/MD5 combo may be quite enough for them, while the PKI/TLS implementation may raise your costs several $ per unit. Each of these gizmos has a recored, centralised serial number that it uses to sign data packets. What you care about in some applications not that Joe Random can read the same data as you do, but that Joe _cannot_ temper with it without you being aware of it. Obviously the serial numbers would not be printed on the back of the unit, but stored in harware protected memory etc.

    Cheers
  26. If the document is sent over non-ssl or non-vpn channel, it's vulnerable to man-in-the-middle attack.
    Terribly untrue if you use attach a message authentication code to the message.The MAC (say, a HMAC) cannot be re-created without possession of the private key that is shared between intended, authorised recipients.For more on the subject I suggest you read the first paragraphs of RFC 2104.The basic idea is that you prevent anyone but authorised parties to produce such messages. Should such messages arrive in the wrong hands they may be of little use to the bad guys (for instance, some confirmation messages, correlated on IDs). They contain no value per se, but trigger actions in the receiving system, right? Now, what you really, really care about is that no-one can send fake messages to you. MD5 them and you're lost, someone can conduct a timing attack/mitm or whatever on the SSL link and they'll get the message format out. If you HMAC them and keep the keys really, really secret they're screwed, they won't be able to produce a valid message that they have not seen already (that is, copy/resend it).Imagine tiny sensors spread out over a large environment, beaming up radio signals with data packets. The HMAC/MD5 combo may be quite enough for them, while the PKI/TLS implementation may raise your costs several $ per unit. Each of these gizmos has a recored, centralised serial number that it uses to sign data packets. What you care about in some applications not that Joe Random can read the same data as you do, but that Joe _cannot_ temper with it without you being aware of it. Obviously the serial numbers would not be printed on the back of the unit, but stored in harware protected memory etc.Cheers

    As long as the key was sent over secure channel, it's all good. I am just puzzled about the business case of working with another business and not using strong encryption. The scenario I was attempting to respond to (although poorly) is a case where a third party routes my XML message to some other party. That other business wants to validate my original message is intact and that the intermediary hasn't made any changes.

    from a business perspective, i don't want a business partner doing things I haven't explicitly agreed to and i sure as heck don't want them to route a message i consider important to another party without using strong encryption. Most likely I'm being overly critical of XML signature and just don't get "it". I've yet to see a good reason for XML security for the general case. I'll glady admit i'm wrong, but the few resources out there on XML security doesn't paint a compelling argument to me.

    peter
  27. I've not used XML signatures per se either.
    The message authentication scheme (hmac) has a lot of real world application, use cases that do not require encryption, just being to able to say "yes, this is something only I could have produced and there's no doubt in hell about that (John can you please check the vault again? Thanks.), so I can safely use the information provided therein".

    Think for instance about tokens handed to other parties that testify that they have been logged in. The tokens are text, for instance:
    {
      [plain text data that identifies the owner]
      [other data such as timestamp of creation]
      [hmac signature]
    }
    You most definitely don't want other people to be able to produce those right? That's what the hmac does for you. On the other hand, and complementary to that, anyone can steal the token and pose as the actual owner, if the channel is not secured. That's where SSL comes in. But anyone can use SSL right and talk to the systems, right ? Indeed, but they cannot produce fake "passes" (tokens). So the two are actually complementary.
    Now think of bank notes, passports and the like. Ideally those would be hmac'ed and you could not forge them. Steal them ? Yes. Force the password out of a government official ? Yes. Modify them ? No. Create new ones ? No.
    That's it, that's the whole point here. It's not a complete solution per se, but part of it.

    Kind regards
  28. You are still mixing. We have two independent things. First is signing, second is encrypting. You can sign something by your private key and encrypt whole stuff by generated symetric key. Then you will attach to document symetric key encrypted by public keys of all receivers. That's all.
    For trusting to somebody else context we have certificates and certificate chains. If somebody will sign something with certificate issued e.g. by Verisign you can trust him as you trust to Verisign. For example you will have your own certificate authority and you will issue certificates only when somebody will prove his e-mail and bank account. Once it's done you should trust that specific content is comming from this specific person because nobody is able to produce same certificates as you.
    PKI is very nice area for study.
  29. first thing, I'm not an expert in encryption, but I have used JSSE on several occasions in the past. thanks for correcting bad statements on my part.
    You are still mixing. We have two independent things. First is signing, second is encrypting.

    I think the confusion is caused by poor use of terminology on my part. You're absolutely right that "signing" isn't necessarily encryption. Encryption isn't necessarily signing. I think of signing as verifying the authenticity of a document. Encryption to me means scrambling data so others can't read it.
    You can sign something by your private key and encrypt whole stuff by generated symetric key. Then you will attach to document symetric key encrypted by public keys of all receivers.

    I understand that this can be done, but in the scenario where I don't know the third party and the intermediary sends the document to someone I don't know, how does that technique sold the problem. Am I missing something here? If I don't know the third party, I'm not going to know their public key, therefore I can't encrypt the document using a public key I don't know.
    That's all.

    For trusting to somebody else context we have certificates and certificate chains. If somebody will sign something with certificate issued e.g. by Verisign you can trust him as you trust to Verisign. For example you will have your own certificate authority and you will issue certificates only when somebody will prove his e-mail and bank account. Once it's done you should trust that specific content is comming from this specific person because nobody is able to produce same certificates as you. PKI is very nice area for study.

    Ceritificates are a completely different issue right. I can self sign a certificate as many people do, or I can use Verisign. I want to thank you for pointing out inaccuracies of my posts, but I still fail to see how XML Signature solves the problem described.

    If I don't know a third party and a business partner is sending my document to some one I don't know, how does XML signature solve that problem? I don't mean to be rude, but I just don't see much value beyond a few edge cases. The example of using it to sign software licenses makes sense to me. Using XML signature to sign a contract rather than cooking my own makes sense. Outside of that, does it really make business sense?

    peter
  30. I understand that this can be done, but in the scenario where I don't know the third party and the intermediary sends the document to someone I don't know, how does that technique sold the problem. Am I missing something here? If I don't know the third party, I'm not going to know their public key, therefore I can't encrypt the document using a public key I don't know.
    Again mixing. If you will sign you document and encrypt it with public key of system where are you sending document, your sign is still valid in message. It's than decision of system if they will resend it encrypted or unencrypted to third party, however sign in document is still perfectly valid and should be validated by third party.
    If I don't know a third party and a business partner is sending my document to some one I don't know, how does XML signature solve that problem? I don't mean to be rude, but I just don't see much value beyond a few edge cases. The example of using it to sign software licenses makes sense to me. Using XML signature to sign a contract rather than cooking my own makes sense. Outside of that, does it really make business sense?peter
    That is again decision of your workflow. Third part will trust which certificates? Verisign, second party, ... . For example third party trust only certicates issued by second party. Then you need certificate from second party. How you will get it, depends on policy of second party. You will sign you document (send encrypted or unecrypted) and second party will resend document to third party. Third party should see you and your sign, they should validate consistency of document and they should trust the content because they trust to second party certificates.
    Encryption is totally different situation. SSL is nothing more than what we described above, but as public key you use system public key. Then trafic between you and system is hidden (however not inside sytem). In my previous post I was speaking about situation where you would like to allow only some persons to read you content without allowing it to system or system administrator.
    Signing, encryption and cerificates are tools. How you will apply them in your system depends on problem and goal. Here are hundreds different scenarios. Just use right tool for right problem. Don't mix signing with encryption. They serve different purpose. The infostructure around these problems is now really rich (physical tokens, key stores, cerificate authorities, java support ;-), ...) and they are standard and they should communicate with each other.
  31. Right, they are different[ Go to top ]

    I understand that this can be done, but in the scenario where I don't know the third party and the intermediary sends the document to someone I don't know, how does that technique sold the problem. Am I missing something here? If I don't know the third party, I'm not going to know their public key, therefore I can't encrypt the document using a public key I don't know.

    Again mixing. If you will sign you document and encrypt it with public key of system where are you sending document, your sign is still valid in message. It's than decision of system if they will resend it encrypted or unencrypted to third party, however sign in document is still perfectly valid and should be validated by third party.
    If I don't know a third party and a business partner is sending my document to some one I don't know, how does XML signature solve that problem? I don't mean to be rude, but I just don't see much value beyond a few edge cases. The example of using it to sign software licenses makes sense to me. Using XML signature to sign a contract rather than cooking my own makes sense. Outside of that, does it really make business sense?peter

    That is again decision of your workflow. Third part will trust which certificates? Verisign, second party, ... . For example third party trust only certicates issued by second party. Then you need certificate from second party. How you will get it, depends on policy of second party. You will sign you document (send encrypted or unecrypted) and second party will resend document to third party. Third party should see you and your sign, they should validate consistency of document and they should trust the content because they trust to second party certificates.Encryption is totally different situation. SSL is nothing more than what we described above, but as public key you use system public key. Then trafic between you and system is hidden (however not inside sytem). In my previous post I was speaking about situation where you would like to allow only some persons to read you content without allowing it to system or system administrator.Signing, encryption and cerificates are tools. How you will apply them in your system depends on problem and goal. Here are hundreds different scenarios. Just use right tool for right problem. Don't mix signing with encryption. They serve different purpose. The infostructure around these problems is now really rich (physical tokens, key stores, cerificate authorities, java support ;-), ...) and they are standard and they should communicate with each other.

    I agree with the technical aspects of the discussion. It has been interesting, but if I understand your response correctly, XML Signature doesn't do anything for solving the business problem. It's no worse than other signing, or encryption standards out there. There are already several digital signature standards out there, so it just confuses me. I see no need for "yet another digital signature" standard when there's already existing tools and standards. Including it as a standard part of Jdk6 definitely feels questionable to me. Even though i use broadband, I'd would rather not download more tools I'm never going to use. but the value of including is really a personal thing and everyone will have their own opinion. I'm just being a trouble maker.

    peter
  32. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless.

    Contrary the impression you and others have given about document signing, the typical use case has nothing to do with signing a handcrafted artifact by hand. Usually a signed document is instead a SOAP message. IBM and Microsoft's joint whitepaper on web service security explains it simply enough...

    "When data is received and forwarded on by an intermediary beyond the transport layer both the integrity of data and any security information that flows with it maybe lost. This forces any upstream message processors to rely on the security evaluations made by previous intermediaries and to completely trust their handling of the content of messages. What is needed in a comprehensive Web service security architecture is a mechanism that provides end-to-end security."
  33. last year I spent some time looking at xml signature spec and walked away feeling it's practically useless.

    Contrary the impression you and others have given about document signing, the typical use case has nothing to do with signing a handcrafted artifact by hand. Usually a signed document is instead a SOAP message. IBM and Microsoft's joint whitepaper on web service security explains it simply enough..."When data is received and forwarded on by an intermediary beyond the transport layer both the integrity of data and any security information that flows with it maybe lost. This forces any upstream message processors to rely on the security evaluations made by previous intermediaries and to completely trust their handling of the content of messages. What is needed in a comprehensive Web service security architecture is a mechanism that provides end-to-end security."

    Hmm, I didn't think about this specific case, but it worries me a bit. The reason i say this. If i'm sending data to a business partner, i do not want them to send that data some place without explicit and written authorization. In those cases, i would require they follow strict guidelines. I've worked on a few integration projects the last few years and most of the time, the contract states explicitly sharing or reselling of the data is strictly prohibited.

    The sentence about forwarding the message seems wrong to me. not from a technical perspective, but from a business/license/agreement perspective. If i license travel information from United Airlines, Delta and American Airlines, I am not allowed to resell that data without their explicit approval. not only that, they will want a cut of the gross. If i manage to negotiate the lincese, I would assume rsponsibility for the data and not someone else. Allowing some other business to forward the message isn't desirable, so I see no value in this specific case.

    Most likely I'm mis-interpreting the term "forwarded". signing a license file makes sense to me. signing a document to forward doesn't from a business and practical perspective.

    peter
  34. Most likely I'm mis-interpreting the term "forwarded".

    You suppose the chain of custody might include an untrusted third party that wasn't authorized by the original sender. That's a valid use for message signing. But more typically with asynchronous messaging the reciever internally shuffles the message amongst queues and other stores until finally consuming it, perhaps days later. The sender may have used SSL, but that transport security guarantee expires as soon as the reciever accepts the incoming message. I agree with you that concerns of this sophistication don't belong in the JRE, that is unless web services become very common as the big vendors insist will happen.
  35. while I welcome "big fixes" I can't see purpose of
    including rhino or a "light weight http server".
    who's on the other side of woot?
    the individual responsible for javax.swing.text.html was
    one of the few select people I have never met but learned to hate.
  36. I was also surprised when I saw items like rhino or http server in STANDARD distribution. Isn't it for enterprise distribution? Also dont' understand lighweight http server. Who will ever need this?
  37. while I welcome "big fixes" I can't see purpose ofincluding rhino or a "light weight http server".who's on the other side of woot? the individual responsible for javax.swing.text.html wasone of the few select people I have never met but learned to hate.

    Not basing JEditorPane on DOM is one of the stupidest things Sun has ever done. But just as stupid is the likelihood that Java 6 will ship with both JEditorPane and Rhino and the two can't interoperate! The JRE ceases to be a foundation when its stock parts can't interoperate.
  38. ...an embedded light weight HTTP server

    I wonder if stuff like this is such a good thing.
    On one hand, its great that built-in libraries for networking, XML, GUI, etc. make Java the Super Wal-Mart of development platforms.

    However, when you want a really nice pair of shoes, you go to a specialty shop...not Wal-Mart.
  39. Potential upcoming 'features'[ Go to top ]

    I haven't read the JSR or done much research for Mustang but with all the new 'features' and expected larger footprint, will there be some way to trim down the JDK? Namely through something like a pluggable API. I know I don't use Swing and some other things in the JDK so I'd like to get them out of the memory footprint without having to pick classes out of rt.jar.
  40. Potential upcoming 'features'[ Go to top ]

    I haven't read the JSR or done much research for Mustang but with all the new 'features' and expected larger footprint, will there be some way to trim down the JDK? Namely through something like a pluggable API. I know I don't use Swing and some other things in the JDK so I'd like to get them out of the memory footprint without having to pick classes out of rt.jar.

    Correct me if I'm wrong, but doesn't the java ClassLoader only load classes that are referenced into memory? If the new feature classes have their dependencies minimized, then you shouldn't incure a runtime memory cost (basically, if you don't use it, it's not loaded into memory). The key, and the thing that I'm worried about is making sure the class dependencies are properly managed, and that the new core JDK classes that are heavily used for standard functionality do not reference these new classes (i.e. things like java.lang.*, java.util.*, etc. should NOT depend on these new classes).
  41. java language is so great but still lacks good support for simplified use of dates - conversions from string to dates etc is so difficult.
    also some basic checks of date is valid or not should be all in the data object .. why to force user to write their own logic every time ...

    Date is such a simple thing to implement but java coders have made it really complicated ... please help us make it simple ...
  42. JSR 223 - scripting[ Go to top ]

    Warning: I have not read up on all the various scripting specs...
    I have really enjoyed what has happened around scripting for Java. My concern is that we now get a flood of various scripting alternatives, and although JSR 223 dictates the terms that a scripting language that e.g. Groovy may comply to, it still seems like the alternatives are many, such as Beanshell, and Rhino (client-side?), not to mention the Ruby, and Python/Jython alternatives as well. What will prevail as the scripting language for Java? My initial experiences with Groovy look very promising with its JVM and Java compatibility, closures, XML support, and much more. My concern is that we again are getting too many options. We don't want more alternatives of scripting languages - we want something rather simple, works well, and is compatible with Java, compile- and run- time!
    Anybody that knows more about this?
  43. JSR 223 - scripting[ Go to top ]

    You will get in new release also standard support for compiling Java sources. Isn't than Java also scripting language?
  44. java mammoth[ Go to top ]

    great, java is gonna be even slower, with even more unuseful libraries built in. tons of classes preloaded at JVM startup without asking for them.

    and we don't even have a decent HTML support!!!

    Rhino in java? Groovy? what the f**k ?
  45. java mammoth[ Go to top ]

    how java 6 mustang should be
  46. java mammoth[ Go to top ]

    great, java is gonna be even slower, with even more unuseful libraries built in. tons of classes preloaded at JVM startup without asking for them.

    Classes are loaded when they are used. All of rt.jar isn't magically preloaded. Try a google search on java class loader.
  47. java mammoth[ Go to top ]

    there are too many dependencies that could be avoided... if they were not there at all!

    i want a lightweight, simple, and quick java core, and several modules.

    if the servlet api jar, which is by far the most important in the j2ee package, ought to be in a different distribution, why not getting rid of all the gazillion xml related jars.

    a server side java app with spring context should have a pretty sleek memory footprint.
  48. java mammoth[ Go to top ]

    there are too many dependencies that could be avoided... if they were not there at all!

    Care to mention specific cases where "too many dependencies could be avoided"?

    why not getting rid of all the gazillion xml related jars.a server side java app with spring context should have a pretty sleek memory footprint.

    I guess you won't want to throw away the JARs related to reading Spring's XML files. And the classes contained in the other JARs are not loaded into memory unless they're used either by your application or by the app server, but then there is not a problem related with the Java core, isn't it?


    Javier
  49. This is the stuff I'd like to see added in Mustang:
    http://weblogs.java.net/blog/gczaj/archive/2005/06/releasing_the_m.html

    This would result in reduced app start time and memory footprint, greater scalability, etc.

    Regards,
    Henrique Steckelberg
  50. JavaScript???[ Go to top ]

    Excuse me for the 3 quotation marks, but I ask it like that... Just how did they come to include JavaScript? Why?

    The smaller problem is that my personal opinion is that JavaScript is a poorly designed scripting language. Of course it is widely know, but still...

    The bigger problem is that its "type system" and its approach of object operation are totally different from the approach of Java. I bet it will cause a lot of complication when you interface the two worlds. And there are scripting languages that are work very well with "Java", like BeanShell, or even Groovie or Metro if they will be done. Heck, they were designed for that. Will they be included as well? You see if Rhino is...

    So why do we need JavaScript in the "core"? Maybe everybody writes Web browsers or what? I don't get it. (And after adding JavaScript, just what will *not* be included?)
  51. I am probably just a grumpy java conservative. Personally I'd prefer if Java6 started by reverting most of Java5 "features". Java5 was mostly a step in the wrong direction.
    - Remove annotations. This doesn't feel Java'ish. It is making Java a 2 in 1 language where each requires different kinds of abstraction. In my opinion different abstractions in the same source file is bad. C/C++, HTML/Java (in JSP), inline assembler/Pascal have shown this.
    - Remove autoboxing. It obfuscates code in an attempt to please VB-hacks who do not understand strong typing.
    - Remove new for loop. Java loops ARE too verbose, but this solution is not neat enough and doesn't seem consistent with rest of language.
    - Remove static imports. Obscurity+inconsistency outweigh convience.
    All in all Java5 was a disapointment of "Starwars classic vs. Episode I"-proportions. You'd think Bill G. had infiltrated group that developed it to steer it off course.
    Generics and (...)-thingy are the only Java5 features worth considdering keeping.
    For Java7 they should considder orthogonal persistence and declarative transactions.

    P.S. Apologies in advance for my spelling, not a native english speaker and dictionary unavailable.
  52. More interfaces, anyone?[ Go to top ]

    How about some testability? A lot of stuff in the API needs to be retrofitted with interfaces to make them "mockable" using EasyMock, etc. Just look a java.io.File - it's a class, created using a constructor that takes a path.

    The solution, for now, it to use 2nd tier API:s, such as Jakarta Commons VFS which is all interfaces and a factory, but it would be nice if the underlying Java APIs supported this kind of use out-of-the-box.

    After all, it's spelled API - not Application Programming Classes. ;-)
  53. More interfaces, anyone?[ Go to top ]

    How about some testability? A lot of stuff in the API needs to be retrofitted with interfaces to make them "mockable" using EasyMock, etc.

    Sorry to be a nazi, but "etc." indeed. I mock at these mockable ideas.