Re: Request to review draft-yevstifeyev-pops-uri-scheme-02

[Mykyta Yevstifeyev <[e-mail]>]

Chris,

Thanks for your comments.  See some responses in-line.

2011/3/15, Chris Newman <[e-mail]>:
> This document fails to provide and rules with respect to identity checks
> for TLS with the POP application. A reference to RFC 5246 is not sufficient
> as TLS leaves identity issues to the application. Examples of such rules
> are in RFC 2595 section 2.4 and 2.5. Or more recently, RFC 4513 section
> 3.1.2, 3.1.3.
>
IMO that procedure described in RFC 2595 apply to this case as well.
I suppose it can be added by normative reference in the next version.
>
> This document fails to state whether the POP server is in AUTHORIZATION
> state or TRANSACTION state upon conclusion of the SSL/TLS negotiation on
> the pops port.
>
It's considered that the user agent will enter AUTHORIZATION state
after TLS negotiation.  The case when it will be already in
TRANSACTION state is described in RFC 2595.
>
> Without such a statement in a standard document, the "pops" protocol is a
> non-interoperable protocol when client certificate authentication is used
> and thus is not suitable for standards track recognition.
>
> If you state that the POP server is in AUTHORIZATION state after the TLS
> negotiation completes, even if a client certificate is supplied, then your
> document will be consistent with RFC 2595 and the EXTERNAL SASL
> mechanism
> can be used to enter TRANSACTION state, but the document will not
> necessarily be consistent with the majority behavior of de-facto pops
> implementations that support client certificates.
>
You mean the implementations of RFC 2595, while the proposed document
contains different POP3 over TLS binding at all.  The purpose of it is
to provide another procedure, not that described in 2595.

All the best,
Mykyta Yevstifeyev
>
> If you state that the POP server is in TRANSACTION state after the TLS
> negotiation completes if a valid client certificate was supplied and that
> the TLS negotiation MUST fail and/or the connection MUST be closed by the
> server if the client certificate is not valid, that means clients will have
> to implement RFC 2595 STLS if they wish to use an authorization identity
> different from the authentication identity.
>
> 		- Chris
>
> --On March 15, 2011 17:34:09 +0200 Mykyta Yevstifeyev <[e-mail]>
> wrote:
>> Hi,
>>
>> I'm writing to request a review of draft-yevstifeyev-pops-uri-scheme-02,
>> that can be found here:
>> http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-02
>>
>> The document specifies the 'pops' URI scheme to designate the access to
>> POP3 mailboxes available over secure TLS connections and may be
>> considered to be appropriate for discussion here.
>>
>> Any comments directed to [e-mail]
>> and copied to [e-mail] and [e-mail] are welcome.
>>
>> All the best,
>> Mykyta Yevstifeyev
>
>