Subject: [TLS] DISCUSS on Client Certificate URLs Section of 4366-bis

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 17 Aug 2010 10:41:21 -0700

Alexey logged some DISCUSS comments on section 5 of
draft-ietf-tls-rfc4366-bis-10 during IESG review.  Below are the
comments and the proposed resolutions.  Please review and send comments
to the list. 

Thanks,

Joe 

1) Comment 1

"  The TLS server is not required to follow HTTP redirects when
   retrieving the certificates or certificate chain.

This is not strong enough for interoperability. Either redirects MUST be
followed, or they MUST NOT be followed. Alternatively there need to be
some
explanation of why SHOULD (or even MAY) is appropriate here.

   The URLs used in
   this extension SHOULD therefore be chosen not to depend on such
   redirects."

It seems that since we recommend not depending upon redirects so I
propose:

"The TLS server MUST NOT follow HTTP redirects when retrieving the
certificates or certificate chain. The URLs used in this extension MUST
NOT be chosen to depend on such redirects."

If we want to leave the possibility for redirects then we need to text
to describe when redirects are allowed.  

2) "If a server encounters an unreasonable delay in obtaining

This is not very specific. Can a minimal value be recommended here?

   certificates in a given CertificateURL, it SHOULD time out and signal
   a certificate_unobtainable(111) error alert.

What are possible alternatives to the SHOULD?

   This alert MAY be fatal;
   for example, if client authentication is required by the server for
   the handshake to continue. "

I propose the following text to resolve this:

"If a server is unable to obtain certificates in a given CertificateURL,
it MUST send a fatal unrecognized_name(112) alert if it requires the
certificates to complete the handshake.  If the server does not require
the certificates then the server continues the handshake.  The server
MAY send a warning level alert in this case.  Clients receiving such an
alert SHOULD log the alert and continue with the handshake if possible."

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Aug 2010 11:01:20 -0700

Joseph Salowey (jsalowey) wrote:
> it MUST send a fatal unrecognized_name(112) alert....

Shouldn't that be certificate_unobtainable(111) ?

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 17 Aug 2010 11:04:44 -0700

Yes.

Thanks,

Joe

> -----Original Message-----
> From: Michael D'Errico [mailto:[email-masked]]
> Sent: Tuesday, August 17, 2010 11:01 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [TLS] DISCUSS on Client Certificate URLs Section of
4366-bis

---

From: Joe Salowey <[email-masked]>
Date: Mon, 30 Aug 2010 16:20:04 -0700

Any other feedback on the recommendations (especially comment 1)?

Thanks, 
Joe

On 8/17/10 10:41 AM, "Joseph Salowey   (jsalowey)" <[email-masked]>
wrote:

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