Re: Naming convention for a WG I-D that returns to
PS. Can someone tell me which RFC says that a draft must include a security part?. thank you; RFC2223 section 9 Sal ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Naming convention for a WG I-D that returns to
Thank you. I was also looking for an RFC - if any -which documents why. There is RFC3552 which is the Security Considerations Best Practices but it doesn't answer the WHY question. Sal ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Intellectual property clarification - please
Is it the intention to always include the IPR statement and the RFC Editor will only ensure it when an IPR disclosure has been made? I read it as If we are aware of an IPR claim or disclosure, the RFC Editor will include the appropriate text.. I don't see any requirement that the RFC Editor add text protecting against an undisclosed submarine patent claim or similar unfriendly activities (Whether such language *should* be added to protect against that is a subject for another flame-fest, another day.. ;) I don't expect the RFC Editor to add any text. It appeared that an IPR statement was only required by the authors when they also made an IPR disclosure. Likewise, when an IPR disclosure was made, the RFC Editor would make sure that the IPR statement was within the document. I am comfortable with the understanding that the IPR statement is always included and the RFC Editor will only be required to verify when an IPR disclosure has been made too. Then of course I ask myself. If it is supposed to always be included why not ensure it is in there for every document? IMHO (I have no authority :) it appears that an IPR statement should be included in all documents. Regards, Sal ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
copyright requirements clarification - please
Hello all, I am reading through RFC 3667 and RFC 3668 and have come upon what I believe is a conflict. In RFC 3667 in Section 5.4 it states: -- 5.4. Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Additional copyright notices are not permitted in IETF Documents except in the case where such document is the product of a joint development effort between the IETF and another standards development organization or the document is a republication of the work of another standards organization. Such exceptions must be approved on an individual basis by the IAB. --- BUT, in both documents an additional copyright statement is included near the beginning of the documents: --- Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. --- Is this a conflict? Regards, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Intellectual property clarification - please
Both RFC 3667 and RFC 3668 contain an Intellectual Property disclaimer near the end of the document as defined in Section 5 of RFC 3668. But, this appears to only be required as stated in Section 5 for specific requirements: - 5. Notice to be included in RFCs The RFC Editor will ensure that the following notice is present in all IETF RFCs and all other RFCs for which an IPR disclosure or assertion has been received prior to publication. - Is it the intention to always include the IPR statement and the RFC Editor will only ensure it when an IPR disclosure has been made? Thanks again for your guidance, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
Thanks for the insight, Harald, You are right that the scheme I proposed inn 1422 did not succeed, and today I would not suggest it. But, the reason I would not suggest it today is because I have come to believe that one should adopt CAs that are authoritative for the certs they issue, not trusted third parties. The DNS root is an example of such a CA, whereas RSA (proposed as the IPRA) was not. If we deploy DNSSEC in a full, top down fashion, the effect is the same as what Kevin is suggesting, expect that we would be using a standard cert format that is employed by many security protocols. steve I have no problem with the DNS authorities providing the authoritative certs. Actually without saying that I was thinking that they would be authoritative for their own tree. And just as DNS lets me (servanttechnology.com) setup the servers (www, mail, etc...) in my tree I would see the CAS system giving that same authority. I do believe that a bridge trust between top level domains is a good solution rather than the single root CA that if compromised would compromise all certs. One difference between my vision for CAS and DNS is that DNS is expected to provide all information publicly. The CAS would be required to keep some information private. I am trying to see if there is any interest using a parallel set of servers providing basically public keys. This would parallel DNS which would continue providing IP addresses. Maybe the parallel system is overkill I'm not sure. I like it because it provides an independent path to verify certs. For example, the DNS could provide a signed response and the CAS would be act like a third party providing the public key to verify the cert. Otherwise, DNS would provide the signed cert and the public key to verify it. I'm not sure but I would like to work out a solution. DNSSEC works in addition to what I think CAS would be. The CAS cert would be for the actual server answering the question Can I believe that you are who you say that you are? Where the DNSSEC is mainly concerned that the DATA has a cert. It is a different approach. Also, DNSSEC refers to an undefined trust anchor I think CAS could fill that void. The reason I think there is need for a CAS is because DNS is beginning to use certs. E-mail is talking about it. VoIP will need to work out some mechanism too. Why not just put a general system of servers that provides services (a framework) for cert. Then every application (DNS, E-mail, VoIP, etc...) can use it to support their own PKI services requirements. As I see it, even this framework should not reinvent the wheel because work is already being done by the pkix WG. Thanks again for the feedback. Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
please review the namedroppers archives, much of the operational DNSSEC workshop/presentation material www.dnssec.net. Further discussion should likely be on the pki dns wg lists and not on the general IETF list. --bill Thanks I will do that. I think that I will need to more clearly present my ideas within a WG list. I will work on that too. Regards, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
Hello Kevin and all, I have been researching digital signatures in the hope of finding or starting a work to develop a scalable certificate authority server (CAS) system based on standards such as X.509v3 from the pkix working group and using domain names from DNS as the basis for tree rather than X.500 naming convention. The PKI standards are stable and in current use today. This CAS system would provide services such as non-repudiation of servers for other applications to use. Initially, I see it used only for authentication. The CAS system could be extended for access control and encryption too. For example (authentication), * DNS could use it to prevent name server IP spoofing. * e-Mail could use it to verify SMTP servers, sender and receiver email addresses (Similar to the Yahoo offering - privacy of valid email addresses must be supported). * VoIP in conjunction with ISP could use it to provide verifiable locations. * routers could support signing to provide a auditable traces for law enforcement, etc. (Lots of overhead - not recommended for general use). * IM could use it to prevent spoofing. * LDAP could be extended to become an organizations CAS authoritative server. For example ldap.example.com would provide public keys for example.com. I expect each working group would participate in their application's implementation. The root of the trust could be a Bridge certification authority as defined in 1.4.4 within draft-ietf-pkix-certpathbuild-03.txt. Each TLD would be a Principal Certification Authority. The draft is found at www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt NOTE: the draft expires this month. Some RFCs refer to PKI implementations within their application such as: routers - RFC2154; IP - RFC1825; email - RFC1422, RFC1423, and RFC1424. This is why I thought a standardized platform would make sense. Consider DNS many applications rely upon DNS to provide their services. I see the same being true for CAS. Actually, I was hoping to find someone already working on this Is there a group working for goals like this? OR How do I make a presentation to IETF in order to begin a work? Good day. Does anyone know if there is any work going on within the IETF on E911 location services??? If there is, which working groups should we sign up to. Regards Kelvin Something like this could fit into the E911 that you are researching. Regards, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
I'm new to this process. I'm now reviewing RFC2026 and I see that I should not have referenced a draft. Pardon me for that mistake. The root of the trust could be a Bridge certification authority as defined in 1.4.4 within draft-ietf-pkix-certpathbuild-03.txt. Each TLD would be a Principal Certification Authority. The draft is found at www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt NOTE: the draft expires this month. Let me change the reference to: Bridge Certification Authorities: Connecting B2B Public Key Infrastructures by William T. Polk and Nelson E. Hastings for National Institute of Standards and Technology. This document can be found at: http ://csrc.nist.gov/pki/documents/B2B-article.pdf The Bridge and Principal explanations are virtually the same in both documents. Best Regards, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
the idea of setting up a server that everyone in the world would trust was suggested in RFC 1422 (IPRA), in 1993. It did not succeed terribly well then, and people have tended to look very skeptically upon ideas that require some sort of single root since then. What's your reason to believe it could succeed this time? The short answer; I'm not sure. A PKI system is technically a good mechanism to provide non-repudiation. I think there is tremendous benefit in non- repudiation which makes it worth while. Non-repudiation is all that I'm suggesting. The long long long answer (forgive the lengthy answer :) Some differences to this proposal(CAS) compared to RFC 1422: 1422: Based upon X.500 naming convention which is not in general use. CAS : Based upon DNS naming convention which in foundational to internet use. 1422: Use PKI to validate foreign users. Foreign being email addresses in a different domain, the RCPT TO address. CAS : Require data privacy. The first SMTP server MUST verify the MAIL FROM the last SMTP server MUST verify the RCPT TO. Every SMTP would append a digital signature. 1422: Single root the IPRA. CAS : Each TLD would be the root of it's tree very similar to DNS today. The bridging certificates are provided as a service so a server with a name ending in COM could trust a server with a name ending in NET. 1422: Use PKI to encrypt messages. CAS : MAY use PKI to encrypt messages. This is not part of the requirement for a CAS system. It is a feature of PKI that could be used. 1422: IPRA is certifying body and provider of certificates. CAS : Each domain would provide it's own certificates. Let me explain how I see this implemented because this is where (I think) the scalability and biggest differences comes in. There would be a CAS record in DNS to designate the authoritative CAS server. This server would own all certificates for it's domain (example.com). Every domain owner would be REQUIRED to have a CAS server just like every domain owner is REQUIRED to have a DNS server. The hierarchy just manages the trust. COM would provide certificate for EXAMPLE. EXAMPLE would provide certificates for WWW, MAIL, LDAP, whatever... I would suggest that each email address could have a certificate too. The [EMAIL PROTECTED] certificate would be managed by CAS server for EXAMPLE.COM too. In order to send trusted email from [EMAIL PROTECTED] to [EMAIL PROTECTED] the MAIL.EXAMPLE.COM would 1)verify [EMAIL PROTECTED] with or without a certificate, 2)sign the email and 3) forward it to MAIL.EXAMPLE.NET. MAIL.EXAMPLE.NET would 1) verify [EMAIL PROTECTED] 2) query it's own CAS server which would recursively query CAS servers up the NET tree across the bridge and back down the COM tree to EXAMPLE.COM CAS server. The CAS server would then pass the public key to MAIL.EXAMPLE.NET so it could verify the signature from MAIL.EXAMPLE.COM and accept the email, and 3) sign the email, and finally 4) forward the email to [EMAIL PROTECTED] The CAS servers would rely upon DNS for resolving IP addresses as you would expect. But, I would recommend that CAS IP address would be REQUIRED as manual entry similar to the default gateway and DNS server entries. I do not believe that DNS can provide trust by itself. I do not believe that CAS can provide trust by itself. Both the DNS and the additional setting for CAS IP address would be required to provide independent path for auditing. You can't have one server that just provided you an answer to verify itself, because any attack to compromise a server could and would authenticate itself. At least two servers (DNS and CAS) would need to be compromised to successfully complete an attack. Also, I would expect two types of CAS servers. One being the authoritative CAS server for authoritative public keys. The other being resolving CAS server for querying (and cache-ing) public key answers. Note, resolving CAS servers would need to be simple to implement but also need to be uniquely named. I believe there would be trust assumptions possible for Private-use networks(as defined in RFC 3330) that also mask to a local address. Also, each entity could have multiple key pairs. I see the need for 1)single use and 2)limited timestamp certificates. For example, com.user has web based access to email. When working from the office com.user would have an established PKI. Planning for vacation or business trip, com.user would create a set of key pairs with a timestamp for each day. So entering a private key on an untrusted computer would only cause limited damage. A single use key may also work in this situation. The private keys could be stored on some device like a san disk or floppy disk. Also, PKI needs some assistance for initially establishing authenticity. I would propose using Shared Secret Keys(SSK). Because certificates can be revoked additional overhead would be required to rely upon PKI
RE: E911 location services (CAS system too)
If you -really- want this to work, you need to be able to trust what the DNS gives you. --bill If (this is a BIG if): 1) this so called CAS system were implemented 2) DNS chose to use the CAS system to provide DNS server digital certificates 3) DNS servers would sign queries. I mean server signatures as in non-repudiation that the response originally came from the authorized DNS server. I'm trying to say that you could trust what DNS gives you. Of course, the trust is only as good as the protection of the private key and the technology providing PKI. I'm relying upon the reading I have done that simply states that a third party verified digital signature can provide nonrepudiation. I think the CAS system could be used to reliably establish the DNS trust anchor because CAS becomes the third party verifier between a DNS resolver and a requesting computer. Sounds like this is an uphill battle. I believe that a CAS system does have merit. Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
