Subject: Reconsideration Identity And Authorization Issue (Was: Summary of 2222bis WGLC)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 09:14:18 -0700

At 12:40 PM 9/24/2004, Kurt D. Zeilenga wrote:
>5) Identities and Authorization
>
>Kurt indicated that the I-D use of term "authorization
>identity" is confusing and suggested use of different
>terms for each distinct use of this term.  Jeffery
>suggested using the terms:
>        "authentication identity" to refer to the
>        identity associated with the users creditials,
>        "requested identity" to refer to identity
>        which the user requests to act as, and
>        "authorization identity" to refer to identity
>        used by the server in making authorization
>        decisions.  (The latter being derived from
>        by former two.)
>
>The chairs conclude the WG supports use of this
>suggested terminology.

After some lengthy discussions between the Sam, Alexey,
and I (with and without our respective chair/editor
hats), the chairs have decided to vacate their conclusion
regarding this issue and re-open discussion in this
area.  This post will be followed by a messaging
summarizing problems with above terminology choice and
offering a way to resolve the underlying terminology
problem.

Kurt, as SASL co-chair

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Oct 2004 00:51:20 +0200

Kurt D. Zeilenga writes:

> 1) Re-keying of security layers 

>     SASL mechanisms that support re-keying SHOULD:
>     - indicate that re-keying is or will be needed immediately;
>     - provide re-keying messages or transparently include re-keying
>       messages in the security layers; the latter can happen without
>       application involvement, but only as long as the application is
>       engaged in timely bidirectional exchanges with its peer.
> 
> The chairs believes the WG supports addition of this text.

Please also explain what 're-keying' and 'timely bidirectional
exchanges' are.

(I'm guessing that re-keying is a SASL layer's equivalent of TLS
ciphersuite renegotiation, but I don't know.  I don't know if I would
have thought of that if I did not know of TLS.  I have no idea how a
protocol or implementation can know that a peer will be engage in
anything 'timely'.  I'm not sure what exactly 'bidirectional exchanges'
are either, but from the context my guess would be that if one peer
chooses to send a message, the other is expected to notice and send a
response, and do so before sending (or also reading?) anything else on
the connection.)

> 4) Channel Binding

> Nico (...) suggest security consideration
> text that clients using SASL over TLS should verify
> the server's TLS identity to prevent MITM attacks.
> He also suggested (...)
> 
> The chairs conclude that the WG supports the former
> suggestion but not the latter.

Unless just that literal text will be used (except for expanding
"MITM"): Note that the draft does not explain what channel bindings
are, so either explain or avoid the term.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 14:51:51 +0100

Hallvard B Furuseth wrote:

>ciphersuite renegotiation, but I don't know.
>
Correct me if I am wrong, but I understand rekeying as "renegotiation of 
the signing/encrypting key".
But I agree with you, those two terms must be explained. And I am not 
sure I can give a good definition for 'timely bidirectional exchange'

>  I don't know if I would
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 21:05:25 +0100

Alexey Melnikov wrote:

> Kurt D. Zeilenga wrote:
>> Nico indicated that the I-D did not discuss Re-keying of
>> security layers and suggested text in this area be added.
>> The WG discussed a number of specific suggestions in this
>> area, with the following text being the last version
>> submitted for WG consideration:
> After rereading this text multiple times it is clear to me that either 
> the text is [partially] redundant, or I don't understand what it is 
> trying to say (or maybe both).
>
> 1). "indicate that re-keying is or will be needed immediately".
> The first question I have after reading this sentence is "how?" 
> Because SASL framework doesn't have any control channel or out-of-band 
> mechanism, the only answer to this question is "by transparently 
> including re-keying messages in the security layer". But this is a 
> part of what the subsequent sentence is saying!?
>
> 2). "provide re-keying messages or transparently include re-keying 
> messages in the security layers;"
>
> I think this sentence specifies requirements on SASL APIs and I am not 
> sure whether RFC2222bis is the proper place for that.
>
> I also assume that "provide re-keying messages" is not the same thing 
> as "transparently include re-keying messages in the security layers".
> I think the former is trying to say that the SASL API should be able 
> to signal to the application that rekeying is (or will be shortly) 
> needed, once a rekeying message is received. It also tries to say that 
> the application should be able to say to SASL API: "send rekeying 
> request now".
>
> The latter is trying to say that the SASL API doesn't have to expose 
> re-keying messages to the application, it should generate/process them 
> automatically.

Having said that, here is a draft variant of the text I propose:

A SASL mechanism supports re-keying if it is able to generate/process 
messages that request immediate re-keying and it is able to carry out 
re-keying exchange.
(a single message that does both is Ok) SASL mechanisms that support 
re-keying MAY also be able to indicate that re-keying will be needed in 
the future.
A re-keying exchange can be conducted transparently by the mechanism, or 
the mechanism should be able to provide/accept re-keying messages 
to/from the application. The former can happen without application 
involvement, but only as long as the application is engaged in timely 
bidirectional exchanges with its peer.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 20:39:16 +0100

1). "indicate that re-keying is or will be needed immediately".
The first question I have after reading this sentence is "how?" Because 
SASL framework doesn't have any control channel or out-of-band 
mechanism, the only answer to this question is "by transparently 
including re-keying messages in the security layer". But this is a part 
of what the subsequent sentence is saying!?

I also assume that "provide re-keying messages" is not the same thing as 
"transparently include re-keying messages in the security layers".
I think the former is trying to say that the SASL API should be able to 
signal to the application that rekeying is (or will be shortly) needed, 
once a rekeying message is received. It also tries to say that the 
application should be able to say to SASL API: "send rekeying request now".

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 22:20:03 +0100

[I am CCing my reply to the mailing list as discuss. I believe I've
quoted enough context.]

Kurt D. Zeilenga wrote:

>>   >>> 2). The following text is in the Security Considerations
>>   >>> section (as per off the list discussion with Nico):
>>   >>> 
>>   >>> The secure or administratively permitted lifetimes of SASL
>>   >>> mechanisms' security layers are finite.  Cryptographic keys
>>   >>> weaken as they are used and as time passes; the more time
>>   >>> and/or ciphertext that a cryptanalyst has after the first use
>>   >>> of the a key, the easier it is for the cryptanalyst to mount
>>   >>> attacks on the key.
>>   >>> 
>>   >>> Administrative limits on security layers lifetime may take the
>>   >>> form of time limits expressed in x.509 certificates, Kerberos
>>   >>> V tickets, or in directories, and are often desired.
>>   >>> 
>>   >>> In practice one likely effect of administrative security
>>   >>> layers lifetime limits is that applications may find that
>>   >>> security layers stop working in the middle of application
>>   >>> protocol operation, such as, perhaps, during large data
>>   >>> transfers.
>>   >>> 
>>   >>> SASL does not provide for re-keying.  SASL mechanisms may; all
>>   >>> future SASL mechanisms that provide security layers SHOULD
>>   >>> provide for re-keying.
>>   >>> 
>>   >>  See above comments regarding this recommendation.
>>   >> 
>>   Alexey> You have to be more specific than that. I think the first
>>   Alexey> paragraph should stay, as it explains why rekeying is
>>   Alexey> needed. It should probably be reworded to state this
>>   Alexey> explicitly.  I think the second paragraph should stay as
>>   Alexey> well, although I am not so sure.  The third paragraph
>>   Alexey> should be dropped. The last paragraph should stay,
>>   Alexey> although it will have to be reworded (and maybe drop
>>   Alexey> SHOULD?).
>>
>>What's wrong with the third paragraph?  It does tell you the
>>application writer that life may be annoying, but I believe that is a
>>practical statement of reality.    
>>
>
>A problem I see with the third paragraph is that it attempts to
>redefine the lifetime of the layer.  A layers life lasts until
>either a) a new layer is installed or b) the connection closes.
>There no way that a layer's life can end otherwise.  If the
>mechanism is no longer able to generate buffers, the connection
>must be closed.  It is impossible to re-key or to install a new
>layer without generating buffers to accomplish that re-keying
>or installation.
>
>This should be made clear in the document.

I agree.

Section 3.3 had the following sentence:

If use of a security layer is negotiated by the authentication
protocol exchange, the security layer is applied to all subsequent
data sent over the connection (until another security layer is negotiated (
see also section 6.3)).

I've added "or underlying connection is closed" to the text in the
parentheses.

>>I hope to convince mechanism designers/implementers not to have mechanisms fail mid transfer, but some mechanisms today do fail that way.    
>>
>
>SASL doesn't allow anything else.  If the mechanism is not
>able to produce a buffer, the connection must be closed.
>That can happen anywhere within the application protocol
>stream.
>
>This should be made clear as well.  If the mechanism layer
>failure results in termination of the connection.  While at
>the protocol and SASL layers, that termination is abrupt,
>implementations should attempt to gracefully close lower
>level layers (such as TLS and TCP).
>
Agreed.

I've changed the existing text in 3.3:

   Once the security layer is in effect the protocol stream is processed
   by the security layer into buffers of protected data.  Each buffer of
   protected data is transferred over the connection as a stream of
   octets prepended with a four octet field in network byte order that
   represents the length of the following buffer.

To:
  Once the security layer is in effect the
  protocol stream is processed by the security layer into buffers of
  protected data.  If the security layer is not able to produce a buffer,
  the connection MUST be closed. If the security layer is not able to
  decode a received buffer, the connection MUST be closed.  In both
cases the
  underlying connection SHOULD be closed gracefully.

(Inserted 3 sentences here and broke the paragraph into 2).

  Each buffer of protected data is
  transferred over the connection as a stream of octets prepended with a
  four octet field in network byte order that represents the length of
  the buffer. ...

(I've dropped the word "following" in the last sentence.)

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 12:16:19 -0400

OK.  My interpretation of the third paragraph was that it was saying
that a layer might force a connection close.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 16:09:24 -0500

Where does this leave us w.r.t. re-keying?  Will it be possible for
future mechanisms or extensions to existing ones to provide for
something better than this?  Should existing mechanisms' layers expire
when the session key material's useful lifetime (in terms of time or
use) is exceeded?

IMO, SASL must at least point out the key expiration problem and should
allow for future mechs/extensions that provide for re-keying.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 16:17:34 -0500

> of what the subsequent sentence is saying!?

See below.

> sure whether RFC2222bis is the proper place for that.

The answer is: by providing interfaces for the purpose of indicating key
layer expiration and providing for re-key message exchanges (where mechs
support it).  Layer expiration, for existing mechs, should be advisory
only; for new mechs I think we should insist that it be mandatory.

Whether you like it or not it is possible to derive an abstract API from
a protocol specification, at least a sufficiently complete and
unambiguous spec :)

IMO abstract API requirements/recommendations are more than Ok to
include in rfc2222bis.  The key word there is "abstract."

> "transparently include re-keying messages in the security layers".

Correct.  I'm not sure that any existing mechs could do either, but new
mechs should definitely provide for the former.

> application should be able to say to SASL API: "send rekeying request now".

Yes.

> re-keying messages to the application, it should generate/process them 

Yes.  This approach is less than ideal.  IIRC Sam favors it, at least in
that it may be workable in some cases that we care about.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:21:17 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Where does this leave us w.r.t. re-keying?  Will it be
    Nicolas> possible for future mechanisms or extensions to existing
    Nicolas> ones to provide for something better than this?  

Yes.  If you believe the text does not support future work in this
direction please describe.

    Nicolas> Should
    Nicolas> existing mechanisms' layers expire when the session key
    Nicolas> material's useful lifetime (in terms of time or use) is
    Nicolas> exceeded?

I believe that SASL mechanisms should try to avoid expiring the
connection when key lifetime is exceeded because doing so creates an
unacceptable user experience.  There exist mechanisms that will expire
though like some implementations of the GSSAPI mechanism.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 20:10:53 -0500

> only; for new mechs I think we should insist that it be mandatory.

And, of course, the GSS-API does not provide [yet] for advisory security
context expiration, so neither can SASL GSS mechanisms [yet].

It'd be a shame to add advisory security context expiration to the
GSS-APIv3 work at KITTEN just for SASL, but perhaps we should.

Also, there is a mitigation for this problem: use ciphers that don't
require re-keying :)  (I'm thinking AES-256 in some counter mode).

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Oct 2004 19:40:18 -0700

My view on re-keying is that its just another layer security
service that a mechanism can offer.  In regards to the
SASL framework specification, how it does so (on the
wire) is something for the mechanism specification to detail.
And how an developer of an application protocol provides
support for this mechanism is an implementation detail.
The framework simply should not concern itself with such
details.

The design of any SASL API is limited by which mechanism
aspects and protocol aspects which were accounted for in
the design.  If a new mechanism has aspects not previously
considered by designers of a particular SASL API, then
the designers of that SASL API might want to redesign
their API to account for the new aspect... or decide
that they simply cannot support that mechanism (or
aspect of that mechanism).

While we could constraint future mechanisms to currently
known aspects, I think that's unwise and counter to
character of SASL.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 11:26:31 +0100

Sam Hartman wrote:

>unacceptable user experience.
>
I concur.

>  There exist mechanisms that will expire
Are we talking about GSSAPI in general or a particular implementation of 
GSSAPI?

Imagine that support for re-keying can be done without changing 
(extending) GSS API. In this case the SASL GSSAPI spec doesn't have to 
be updated.
In which case the following text can be removed from 2222bis:

In practice one likely effect of administrative security layers
lifetime limits is that applications may find that security layers
stop working in the middle of application protocol operation, such
as, perhaps, during large data transfers.

?
(or at least it has to be reworded to talk about "broken" or "old" 
implementations)

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 11:39:18 +0100

Alexey Melnikov wrote:

> Are we talking about GSSAPI in general or a particular implementation 
> of GSSAPI?
>

I've kept the paragraph for now, here is the latest text about re-keying 
in Security considerations (as there is very little time before the 
draft submission deadline, I am going to send the updated 2222bis now):

The secure or administratively permitted lifetimes of SASL
mechanisms' security layers are finite.  Cryptographic keys weaken as
they are used and as time passes; the more time and/or ciphertext
that a cryptanalyst has after the first use of the a key, the easier
it is for the cryptanalyst to mount attacks on the key.

Administrative limits on security layers lifetime may take the form
of time limits expressed in x.509 certificates, Kerberos V tickets,
or in directories, and are often desired.
In practice one likely effect of administrative security layers
lifetime limits is that applications may find that security layers
stop working in the middle of application protocol operation, such
as, perhaps, during large data transfers.  As the result of this
the connection will be closed (see section 3.3), which will result
in unpleasant user experience.

Re-keying (key renegotiation process) is a way of addressing
the weakening of cryptographic keys. SASL framework does not provide
for re-keying.  SASL mechanisms may; all future SASL mechanisms that
provide security layers should provide for re-keying.

Applications that wish to re-key SASL security layers where the
mechanism does not provide for re-keying should reauthenticate the
same IDs and replace the expired or soon-to-expire security layers.
This approach requires support for re-keying in the application
protocols.  See section 6.3.

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:21:01 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Sam Hartman wrote:
    Nicolas> Should existing mechanisms' layers expire when the
    Nicolas> session key material's useful lifetime (in terms of time
    Nicolas> or use) is exceeded?
    >>  I believe that SASL mechanisms should try to avoid expiring
    >> the connection when key lifetime is exceeded because doing so
    >> creates an unacceptable user experience.
    >> 
    Alexey> I concur.

    >> There exist mechanisms that will expire though like some
    >> implementations of the GSSAPI mechanism.
    >> 
    >> 
    Alexey> Are we talking about GSSAPI in general or a particular
    Alexey> implementation of GSSAPI?

We're talking about RFC 1964 and most implementations of that spec.

    Alexey> Imagine that support for re-keying can be done without
    Alexey> changing (extending) GSS API. 

I did.  Unfortunately, Nico convinced me that my fantasy had no basis
in reality.  You cannot guarantee that both parties are sending, which
is required for rekeying.  ALso, you have bad interactions with
gss_wrap_size_limit.

    Alexey> In this case the SASL GSSAPI
    Alexey> spec doesn't have to be updated.  In which case the
    Alexey> following text can be removed from 2222bis:

    Alexey> In practice one likely effect of administrative security
    Alexey> layers lifetime limits is that applications may find that
    Alexey> security layers stop working in the middle of application
    Alexey> protocol operation, such as, perhaps, during large data
    Alexey> transfers.

I agree that implementations that work this way are broken.  Nico does
not.  Nor does the IETF; RFC 1964 mandates this behavior.

--Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 14:37:12 +0100

>is required for rekeying.  ALso, you have bad interactions with
Then we need to update the SASL GSSAPI document (suggestions are welcome).

>not.  Nor does the IETF; RFC 1964 mandates this behavior.
The paragraph as written may suggest that there is a problem with SASL 
framework, when there is none. The text has to be rewritten to clarify that.

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 10:11:51 -0400

I think Nico and some others would argue there is a problem with the
SASL framework: it doesn't support rekeying at the SASL level.  It
clearly could be changed to do so; we as a a working group have
decided not to do so.  I think we made that decision for a lot of good
reasons.

If you want to rework the text, I'd recommend making it be
fault-agnostic.  Simply describe the effect without trying to claim
any of the specs involved are broken.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 11:19:07 -0500

> decided not to do so.  I think we made that decision for a lot of good

I agree that existing SASL mechanisms' lack of re-keying support should
be grandfathered.

Going forward though I see no good reason not to require support for
re-keying (or re-key-less ciphers/modes) in new/revised SASL mechanisms,
that includes the revised GSS mechs draft.

(If SASL were a new proposal today, would a spec w/o re-keying get past
WG, IETF and IESG reviews?  I rather doubt it.)

> any of the specs involved are broken.

Heh.  But see above.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 12:51:45 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman
    Nicolas> wrote:
    >>  I think Nico and some others would argue there is a problem
    >> with the SASL framework: it doesn't support rekeying at the
    >> SASL level.  It clearly could be changed to do so; we as a a
    >> working group have decided not to do so.  I think we made that
    >> decision for a lot of good reasons.

    Nicolas> I agree that existing SASL mechanisms' lack of re-keying
    Nicolas> support should be grandfathered.

    Nicolas> Going forward though I see no good reason not to require
    Nicolas> support for re-keying (or re-key-less ciphers/modes) in
    Nicolas> new/revised SASL mechanisms, that includes the revised
    Nicolas> GSS mechs draft.

I don't think there is current WG consensus to support something as
strong as a requirement.

I believe Kurt's summary is consistent with this position.

I would certainly encourage you to make sure all new SASL mechanisms
support rekeying; I certainly plan to try and do the same.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 12:20:37 -0500

> I don't think there is current WG consensus to support something as

Well, yeah, technically it's hard to impose requirements on future
protocol work :)

I must have been hoping that some verbiage to that effect would make it
easier to force the matter later when new mechs/mech revisions come
along.  But I think you're right.

IOW, I will settle for Security Considerations text on this.

> support rekeying; I certainly plan to try and do the same.

Thank you.  I will.

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Oct 2004 11:38:12 -0700

>Well, yeah, technically it's hard to impose requirements on future

And its even harder to impose a particular kind of solution to
a security consideration.  Rekeying is a possible solution to a
security consideration.  It's not the only viable solution to that
security consideration.

The framework specification should elaborate on the security
consideration regarding the life of the layer and leave it to
mechanism designers to determine how to best address these
issues.  It might be okay to suggest the designer consider
particular solutions, but I do not think it appropriate
to recommend a particular solution be used in all future
mechanisms.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 15:04:35 -0400

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> My view on re-keying is that its just another layer security
    Kurt> service that a mechanism can offer.  In regards to the SASL
    Kurt> framework specification, how it does so (on the wire) is
    Kurt> something for the mechanism specification to detail.  And
    Kurt> how an developer of an application protocol provides support
    Kurt> for this mechanism is an implementation detail.  The
    Kurt> framework simply should not concern itself with such
    Kurt> The design of any SASL API is limited by which mechanism
    Kurt> aspects and protocol aspects which were accounted for in the
    Kurt> design.  If a new mechanism has aspects not previously
    Kurt> considered by designers of a particular SASL API, then the
    Kurt> designers of that SASL API might want to redesign their API
    Kurt> to account for the new aspect... or decide that they simply
    Kurt> cannot support that mechanism (or aspect of that mechanism).

    Kurt> While we could constraint future mechanisms to currently
    Kurt> known aspects, I think that's unwise and counter to
    Kurt> character of SASL.

It's been my experience in other IETF work that it is strongly
desirable for framework documents to enumerate the aspects of
mechanisms of the framework that are generally applicable at the time
the framework document is written.  Doing so is useful to API and
implementation designers.

However I cannot claim today that support for this service (re-keying)
is generally available in today's SASL mechanisms.  So I agree that
this revision of the framework should not concern itself with that
service.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 18:04:53 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> 1). "indicate that re-keying is or will be needed
    Alexey> immediately".  The first question I have after reading
    Alexey> this sentence is "how?"  Because SASL framework doesn't
    Alexey> have any control channel or out-of-band mechanism, the
    Alexey> only answer to this question is "by transparently
    Alexey> including re-keying messages in the security layer". But
    Alexey> this is a part of what the subsequent sentence is saying!?

By returning some status to the application or setting a flag.  You
can generally tell you need to re-key without sending anything over
the wire.

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 09:14:18 -0700

Kurt, as SASL co-chair

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Oct 2004 00:51:20 +0200

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 14:51:51 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 21:05:25 +0100

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 20:39:16 +0100

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 22:20:03 +0100

I agree.

Agreed.

To:

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 12:16:19 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 16:09:24 -0500

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 16:17:34 -0500

See below.

Yes.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:21:17 -0400

Nicolas> Should

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Oct 2004 20:10:53 -0500

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Oct 2004 19:40:18 -0700

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 11:26:31 +0100

I concur.

?

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 11:39:18 +0100

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:21:01 -0400

Alexey> I concur.

--Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 14:37:12 +0100

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 10:11:51 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 11:19:07 -0500

Heh.  But see above.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 12:51:45 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 12:20:37 -0500

Thank you.  I will.

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Oct 2004 11:38:12 -0700

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 15:04:35 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 18:04:53 -0400

--Sam