Re: [wpkops] Browser behaviour draft
We could add a clear statement in the document that says, this document describes the state of the Web PKI circa 2013 or something like that. -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Tim Moses Sent: Thursday, July 24, 2014 6:42 AM To: Gervase Markham; wpkops@ietf.org Subject: Re: [wpkops] Browser behaviour draft Hi Gerv. It has to be opportunity; we all know that users don't possess the capability to manage security on their end systems. Ooh! I should put a smiley face after that. ;-) We made a decision to record the state of Web PKI at a point in time. (That being the end of 2013.) The state is continuously evolving, and it would be a poor use of our time if we were to attempt to track it. However, if completion is delayed much beyond the projected completion date, we may have to revisit that decision. Thanks for your helpful input. All the best. Tim. -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, July 24, 2014 5:21 AM To: Tim Moses; wpkops@ietf.org Subject: Re: [wpkops] Browser behaviour draft Hi Tim, On 23/07/14 21:22, Tim Moses wrote: Colleagues - I would like to advance the Browser Behaviour draft ... http://datatracker.ietf.org/doc/draft-wilson-wpkops-browser-processing / ... to WG draft. This document (helpfully) states: This document reviews some of the certificate-processing features of the following cryptolibraries: Network Security Services (NSS), in two code sets, Classic (NSS-Classic) and PKIX (NSS-PKIX); ... However, as of two days ago, with the release of Firefox 31, Firefox switched to using mozilla::pkix for certificate verification: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ https://www.mozilla.org/en-US/firefox/31.0/releasenotes/ You will need to decide whether to hold the document while you update it to take account of any changes. I can tell you that mozilla::pkix also does not do AIA chasing. and most end users can manually add or remove root certificates Is that a statement about opportunity or capability? :-) Perhaps better as: most user agents give end users the opportunity to add or remove root certificates. Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
misuse, e.g., a buffer overflow due to excessive data in a certificate payload. Section 3.5 Header is not in bold. Fixed Section 4.3 Shouldn't say browsers should ;^) The first sentence now reads: A server's public key can be used for key encryption, key agreement, or digital signature verification depending on the TLS cipher suite selected. -Rick From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 27, 2014 2:13 PM To: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is another draft with suggested changes from Santosh accepted, and the addition of Security Considerations subsections, based on our discussions of May 13th. From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 13, 2014 9:44 AM To: wpkops@ietf.org Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is a first pass through the browser behavior document that I sent to Robin and Santosh yesterday. smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
It's now posted here - https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01 -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of i-barre...@izenpe.net Sent: Tuesday, June 10, 2014 2:23 AM To: b...@digicert.com; bruce.mor...@entrust.com Cc: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, I´ll wait for your proposal but still don´t see it as a part of the trust model. The cryptolibraries are something the browsers use to perform their activities regarding the web PKI but IMHO are not related on how the browsers (or the OS) accept a CA in their root stores or how a CA adopt different options. In any case, if this is important for the browser behavior document, as said, will wait for the proposal and see where this can be added to the trust model doc. Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Ben Wilson [mailto:b...@digicert.com] Enviado el: lunes, 09 de junio de 2014 18:24 Para: Barreira Iglesias, Iñigo; bruce.mor...@entrust.com CC: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft Iñigo, Yes, the cryptolibraries are functional subcomponents of browsers, so they ought to be mentioned. Providing the functional introduction will lay the groundwork for technical background. I'll send you (or post to the IETF site) the next version of the working document on non-revocation behavior. Cheers, Ben -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of i-barre...@izenpe.net Sent: Monday, June 9, 2014 2:29 AM To: b...@digicert.com; bruce.mor...@entrust.com Cc: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, The current text of the trust models document already identifies the way a browser and a root store provider work together but not the relation with the crypto libraries. I don´t understand your question exactly because I don´t see why these libraries are of interest for a trust model. Do you mean that a trust model can differ depending on which library is used? The trust model document is more on a functional view than a technical one. I need more clarification on what you think to be added Regards Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Ben Wilson [mailto:b...@digicert.com] Enviado el: viernes, 06 de junio de 2014 20:48 Para: Barreira Iglesias, Iñigo; bruce.mor...@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft Iñigo and Bruce, Perhaps we should revise the Trust Model document to describe how browser, root store, and cryptolibrary are related? In addressing Gerv's comments, I am thinking of starting with the following This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server and a browser, ... or something along those lines. Thoughts? Thanks, Ben -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Gervase Markham Sent: Thursday, June 5, 2014 8:10 AM To: Tim Moses; b...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of to be expanded, we plan to... etc. So there will be lots of further change. Is that what Draft means? My two examples were two of many; they were actually given to try and get clarity
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Iñigo and Bruce, Perhaps we should revise the Trust Model document to describe how browser, root store, and cryptolibrary are related? In addressing Gerv's comments, I am thinking of starting with the following This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server and a browser, ... or something along those lines. Thoughts? Thanks, Ben -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Gervase Markham Sent: Thursday, June 5, 2014 8:10 AM To: Tim Moses; b...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of to be expanded, we plan to... etc. So there will be lots of further change. Is that what Draft means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Thanks. I'll take a look and create another draft. -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Tim Moses Sent: Thursday, June 5, 2014 8:19 AM To: Gervase Markham Cc: wpkops@ietf.org; b...@digicert.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Gerv: You have to look for that in the charter ... http://datatracker.ietf.org/wg/wpkops/charter/ The significance of WG Draft is that it identifies the single document (or sequence of documents) of the declared scope on which the group will focus its efforts. It is not expected that the first WG Draft will be complete or internally consistent. It is often stated that the experts in the community will not engage until a document achieves WG Draft status. So, we are hoping for, and expecting, a more vigorous debate once the document advances to WG Draft status. All the best. Tim. -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, June 05, 2014 10:10 AM To: Tim Moses; b...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of to be expanded, we plan to... etc. So there will be lots of further change. Is that what Draft means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] NIST 800-52
I think this is what was mentioned recently - http://dx.doi.org/10.6028/NIST.SP.800-52r1 smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Taxonomy of Browser Behaviors - Hard Fail, Soft Fail and Reload Request
In working on the next version of the Certificate Processing document, I have come across two different uses of hard fail. I am also concerned that use of the phrase, soft fail, might encounter similar problems. Also I've seen Retry or Reload messages, which are hard fail, but with an option to try loading again. I've seen hard fail used (1) when referring to a session that is stopped because of certificate revocation, where the user is prevented from proceeding, and also (2) when referring to intentional client behavior when encountering other problems with the certificate that indicate it is not trustworthy. (I suppose it could also mean a crash or other unintentional behavior because of a bug in code.) With respect to (2), I have called this a fatal error - A behavior in which the browser detects an abnormal condition and halts (or technically cannot complete) session negotiation and drops the connection or otherwise blocks the user from continuing (also referred to as hard fail). However, in Phill's paper on revocation behavior, he uses hard fail, too. I have used the term bypassable error instead of soft fail, defined as behavior in which the browser detects an abnormal condition and asks the user whether to proceed with (i.e. click-through to) the SSL/TLS connection. Is this the same as soft fail? (I'm assuming that a negative visual indicator or a downgrade of security indicators like removal of the lock icon, removal of EV indication, etc., are not soft fail. I hope that everyone agrees.) Any thoughts? Does it matter what kind of next step is provided in the dialogue presented to the user? For instance, the distinction between hard and soft fail might be as simple as whether the error window lacks or contains buttons or links that allow the user to proceed toward making the SSL/TLS connection. For hard fail, here is what I've seen: [Error Message] Firefox - Fix connection problems Opera - This webpage is not available Chrome - This webpage is not available Internet Explorer - IE cannot display the webpage What you can try: Diagnose Connection Problems Internet Explorer - This page cannot be displayed. Fix connection problems In looking at soft fail / bypassable errors, here are some of the buttons provided for a variety of different conditions, such as invalid certificates: [Error Message] Firefox - Get me out of here Technical Details I understand the risks Safari - Show Certificate Cancel Continue Internet Explorer - Click here to close Continue to this website (not recommended) More Information Chrome - Proceed anyway or Back to safety and Help me understand Opera - Show Certificate Continue Anyway and Cancel or Back to Safety A third option I've noticed is a reload request, which I think is different than a bypassable error or hard fail. Am I right? Here are some messages: Chrome - More or Reload Firefox - Try again Thanks, Ben smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] ID on Trust model
Bruce, Iñigo and Karen, I recently reviewed your internet draft on Trust Model. I agree with some who have commented about the section on security considerations -- it seems it may open a Pandoras Box of issues, considerations, etc. to be considered and discussedbooks could be written if they havent already. I dont know how best to scope or organize all of the content in the security considerations area. I certainly wouldnt want to present the trust model in 3-4 pages and then discuss all of the issues in another 300-400 pages. Here are some additional suggestions: Definition of Root store I think it should say, a set of root certificates embedded in a certificate-using client that anchors the certificate chains of end entity certificates. (This definition cold go on to explain this further, but Im assuming that taking the minimalist approach in the definitions is better because it raises less room for debate about whether a particular implementation falls within the definition.) I would replace this sentence with two sentences - The root store provider determines how trustworthiness will be established and provides a trust indication through its certificate-using client to the relying parties. Suggested: The root store provider sets requirements for inclusion of root certificates in the root store and manages trust indications (i.e. client behavior) for various certificate-related system behaviors and environmental conditions. These are communicated through its certificate-using client to relying parties. By mentioning trust indicators, client behavior, etc. for system behavior and environmental conditions we are providing context that leads into the work of the others in this working group who will discuss these topics. In the section discussing hierarchy, here is a sample diagram to help (I hope these pipes come through OK): +-+ + ---| Root CA |-+ |+-+ | +-+ | | Intermediate CA |-+ | +-+| | | || v vv +-+ +-+ +-+ | Issuing | | Issuing | | Issuing | +--| CA|-+| CA |---+ | CA |--+ | +-+ |+-+ | +-+ | | | | || || | v v v v v vv v ++ ++ ++ ++ ++ ++ ++ ++ | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE | ++ ++ ++ ++ ++ ++ ++ ++ Finally, in section 3.2, I think it helps to explain how each model is different than the preceding one. So, in 3.2.2, it would say Unlike the situation in section 3.2.1, the subordinate issuing CA is not recognized independently by any direct relationship with the root store provider. In 3.2.3 you might say, Unlike the situation presented in section 3.2.2, the third party registration authority is not identified in a CA certificate as an issuing CA. And in 3.2.6, you might say, This is also sometimes referred to as an enterprise subordinate CA, however the difference between this arrangement and that described in section 3.2.5 is that the entity operating the root CA has immediate operational control of the CA and physical possession of the CA private key. Cheers, Ben ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] ID:Browser processing of server certificates:Definitions
Some of us are working on an Internet Draft titled, Browser processing of
server certificates.
Here are some draft definitions for terms that I think we'll be using:
Bypassable error - A behavior in which the browser detects an abnormal
condition and asks the user whether to proceed with (i.e. click-through to)
the SSL/TLS connection.
Fatal error -- A behavior in which the browser detects an abnormal
condition and halts (or technically cannot complete) session negotiation and
drops the connection or otherwise blocks the user from continuing (also
referred to as hard fail).
Name mismatch - A condition detected by a browser in which no name in the
common name or subject alternative name for the subject in the certificate
matches the hostname sought by the client (i.e. the client's reference
identity - usually a Fully Qualified Domain Name - is not in the
certificate).
Pinned - A condition in which the association between two or more aspects of
the entity-public-key relationship (e.g. server name, public key, CA,
certificate) are configured and set in the browser before initiation of a
TCP connection.
Stapled - A condition in which information related to the server's
certificate (e.g. OCSP response) is delivered by the server to the client as
part of the SSL/TLS handshake, and not by direct communication with the
issuing CA.
Visual indicator - A behavior in which the browser changes the color(s)
and/or intensity of pixels on a screen in the browser chrome to indicate a
changed condition.
Wildcard character - An asterisk - * (Unicode 2A).
We're welcome to ideas on how to fine-tune them. I'd prefer that they be
broad enough to include lots of uses-leaving clarification for their
particular use for description in the text.
Additional definitions might include: browser chrome, warning, dialog
box, blacklist, and whitelist-but at this point I don't think they need to
be defined. I'm mainly interested in defining special terms used in
describing a type of condition or behavior. Otherwise, we'll have
disagreement over whether the condition and treatment are comparable among
browsers.
What words are missing above that might help make it easier to discuss this
topic?
And for a little fun, try to figure out which conditions triggered the
following responses/behaviors:
Apple - 379 - This certificate is not in the trusted root database.
Apple - 322 - This certificate was signed by an untrusted issuer
Apple - 5 - Certificate signed by unknown certifying authority
Windows - 3294 - The issuer of this certificate could not be found.
Windows - 3296 - This CA Root certificate is not trusted because it is
not in the Trusted Root Certification Authorities store.
Windows - 3298, 3339, 3343 - CA not trusted or authorized to issue
certificate
Windows - 3331 - This CA Root certificate is not trusted. To enable trust,
install this certificate in the Trusted Root Certification Authorities
store.
NSS - 12195 SSL_ERROR_UNKNOWN_CA_ALERT - Peer does not recognize and trust
the CA that issued your certificate.
Opera - 2104370139 - The root certificate from %1 is not known to
Opera. Opera cannot decide if this certificate can be trusted.
Opera - 1490416928 - The presented certificate has an unknown Certificate
Authority.
Opera - 1023477417 - The certificate is not signed by a trusted authority.
Google - /* ERR_UNKNOWN_CA */ { Unknown Certificate issuer!, USER},
smime.p7s
Description: S/MIME cryptographic signature
___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
