Subject: Re: [wpkops] Agenda Items for IETF 87

From: [email-masked]
Date: Mon, 03 Jun 2013 23:51:12 +0200

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
[email-masked]
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:[email-masked]] 
Enviado el: viernes, 31 de mayo de 2013 21:11
Para: joel jaeggli; Bruce Morton; Paul Hoffman; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Friday, May 31, 2013 1:04 PM
To: Bruce Morton; Paul Hoffman; [email-masked]
Cc: wpkops WG; "Iñigo Barreira ([email-masked])"
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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Hoffman
> Sent: Friday, May 31, 2013 12:28 PM
> To: [email-masked]
> Cc: wpkops WG
> Subject: Re: [wpkops] Agenda Items for IETF 87
>
> On May 31, 2013, at 8:53 AM, Jeremy Rowley <[email-masked]> wrote:
>
>> Please email [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>

_______________________________________________
wpkops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/wpkops

---

From: "Ben Wilson" <[email-masked]>
Date: Mon, 3 Jun 2013 17:43:25 -0600

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 certificate’s 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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 03, 2013 3:51 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
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

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:[email-masked]]
Enviado el: viernes, 31 de mayo de 2013 21:11
Para: joel jaeggli; Bruce Morton; Paul Hoffman; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
joel jaeggli

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 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
>> Please email [email-masked] 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.