Thanks, Iñigo. I will not be able to attend the IETF 87 meeting in person, but I have an updated outline of the user agent behaviors that I have briefly summarized below. The purpose of the following summary is to explain in chronologic fashion the processing of an SSL certificate. The key reason I'm sharing it here is to get feedback on whether I've explained anything incorrectly or in a way that does not fit real-world implementation. The paragraphs below are broad-brushed because I didn't want to dump a hierarchical list of complicated error conditions on everyone. Right now my plan is to use the groupings below to organize the analysis of user agent behaviors.
There are several types of error conditions that one might encounter while processing an SSL certificate. To accomplish an error-free SSL/TLS handshake the user agent has to negotiate the parameters of the session, obtain the server certificate, examine the signature, and determine: whether to trust the certificate and its issuer; whether the certificate was properly issued; and whether it still remains valid. Communication errors due to misconfigurations or data corruption might immediately halt the process. Error messages during the SSL/TLS handshake / session negotiation step include: internal errors, aborted handshakes, certificate or public key unavailability, bad hash values, malformed handshake messages, and unsupported protocols. (Question - is there a difference between "handshake" and "session negotiation"? If anyone has told me, I can't remember.) Most user agents maintain a repository of trusted certificates, and some also keep track of bad certificates as well. Assuming that the certificate is received by the user agent, then during the handshake a user agent will examine the certificate presented and determine whether it can build an unbroken chain between the website certificate and a trusted certificate. If it cannot, because a trusted CA cannot be found (and the user does not affirmatively choose to trust the certificate), then the session should terminate. If the certificate can be examined for other reasons, then further processing occurs. Other errors encountered during this step include: signature does not verify content, unsupported certificate type, corrupt certificate repository, name mismatch, same certificate in multiple paths, and other indications that there are critical problems with the certificate chain. Assuming that a proper chain can be constructed, then the contents within the certificate themselves can be analyzed. The user agent can determine whether the certificate has expired (or in some cases, whether the certificate is premature) based on the system clock. Some user agents provide better detailed explanation. For example, some will inform the user to check his or her system clock to ensure that it is not indicating a time that is earlier than the issuance date of the certificate. Some user agents will determine whether the server certificates validity period falls within the validity period of the issuing CA. If not, the user agent provides a warning that the certificate is outside the lifetime of the issuing CA. A user agent can examine whether the certificate has been revoked by checking a locally cached repository containing a CRL or an OCSP response. If such revocation record is not cached locally, then it can usually be retrieved via an HTTP location specified by the issuing CA. Errors associated with obtaining and processing CRLs and OCSP include: CRL / OCSP not available; signature on (or data within) CRL or OCSP response fails; certificate revoked; and intermediate CA certificate revoked. Even assuming that the user agent can establish that the certificate is valid and has been revoked, there are certainly other errors that may arise in the process of session negotiation. These errors include: transmission/receipt of bad data, hashes, or MACs; decryption and decompression errors; internal processing errors; incompatible cryptographic and algorithmic functions between client and server; and inability to negotiate other parameters for session (key exchange, key size and strength, session renegotiation, etc.). While client authentication errors can also prevent session establishment, these types of mutual authentication errors will not be addressed in this Internet Draft. Thanks, Ben -----Original Message----- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of i-barre...@izenpe.net Sent: Monday, June 03, 2013 3:51 PM To: sharon.boe...@entrust.com; joe...@bogus.com; bruce.mor...@entrust.com; paul.hoff...@vpnc.org; jeremy.row...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Agenda Items for IETF 87 Hi, Meanwhile I´m preparing the document to upload it, here´s a word version for you to check in the meantime. Sorry for doing so late. 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: Sharon Boeyen [mailto:sharon.boe...@entrust.com] Enviado el: viernes, 31 de mayo de 2013 21:11 Para: joel jaeggli; Bruce Morton; Paul Hoffman; jeremy.row...@digicert.com CC: wpkops WG; Barreira Iglesias, Iñigo Asunto: RE: [wpkops] Agenda Items for IETF 87 The WG milestone with respect to the Trust Models draft is that a draft be adopted as the 1st WG draft in June 2013. In order to accomplish that, a draft needs to be submitted early next week to give the WG members time to review, discuss and potentially an updated draft submitted for WG adoption before the end of June. If you and Inigo have an updated draft it should be submitted asap. If there are outstanding issues those could be identified on the mail list and input soliticited from WG membership. -----Original Message----- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of joel jaeggli Sent: Friday, May 31, 2013 1:04 PM To: Bruce Morton; Paul Hoffman; jeremy.row...@digicert.com Cc: wpkops WG; "Iñigo Barreira (i-barre...@izenpe.net)" Subject: Re: [wpkops] Agenda Items for IETF 87 On 5/31/13 9:59 AM, Bruce Morton wrote: > Iñigo and I are working on a draft of the Trust Model document. I am not sure that we will have time to get it prepared to a state that it will be able to be published in the appropriate lead time before the Berlin meeting. > > I will not be able to attend the Berlin meeting, but Iñigo is seeing if he can make it. > > I tend to agree with Paul that if the document has not been circulated and there are no issues raised, then it will be difficult to have agenda items for a meeting. It is the opinion of your AD that drafts that haven't been circulated shouldn't be presented. which is why it's worth having this dicussion now. thanks joel > > Bruce. > > -----Original Message----- > From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On > Behalf Of Paul Hoffman > Sent: Friday, May 31, 2013 12:28 PM > To: jeremy.row...@digicert.com > Cc: wpkops WG > Subject: Re: [wpkops] Agenda Items for IETF 87 > > On May 31, 2013, at 8:53 AM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > >> Please email wpkops-cha...@tools.ietf.org with your agenda items for IETF 87 in Berlin. Also, if you are a document editor, please let us know whether you are attending the meeting and whether you plan to present an update. If you are not attending, please provide a status update on where you are on your project. > The documents were presented at the last IETF meeting in anticipation of the documents being published. IETF face-to-face meetings are normally used for discussing issues in the WG documents and presenting new work, but the WG still has no documents published (and essentially no discussion on the list). > > Is there really a reason to meet face-to-face at the next meeting? Will any of the WG documents be published before then? > > And yes, I ask this as a co-editor on one of the planned documents. It doesn't seem worth writing the documents if there is no real interest in them. > > --Paul Hoffman > _______________________________________________ > 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 > _______________________________________________ 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
