[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Updated version of "X.509 Authentication SASL Mechanism



Steve,

Hi again - sorry it's taken me so long to get to this.  Just a couple of
comments/questions:

1.  In section 5 do we want to say something about which name should be
used to perform the access control check?  Should we use the one in
SASLStrongCredentials.certificate.userCertificate.subject or the
SASLStrongCredentials.name.  I vote for the one in the certificate
myself.  Also, do we want to put something in about checking to see if the
names match?  What happens when you get two different names - which one do
you use?  Could I suggest adding the followig as a new second paragrapg in
section 6:

Either SASLStrongCredentials.certification-path or
SASLStrongCredentials.name MUST be included.  Both MAY also be included,
but if this is the case, the value of
SASLStrongCredentials.certification-path.userCertificate.subject MUST be
identical to that of SASLStrongCredentials.name.

2.  Do we wan to specify a minimum size for the random?

Cheers

spt

Steve Kille wrote:

> I have handled all of the comments recevied, and will send an updated
> draft in the next message.   Dependent on comments received on this
> version, I will be asking the WG chairs to issue a WG last call on
> this document.
>
> Most of the input has led to straightforward updates.  I have changed
> the mechanism definition to included the algorithm.  I believe this is
> a significant improvement, and fits in with the spirit of SASL.
>
> Sean Turner gave a number of useful inputs, and I have basically taken
> these to align the specification to X.509 (97).
>
> Two comments.
>
> 1) I have not changed the definition of Time as Sean suggests.  I
> prefer to retain X.509 compatibility (unless there are some updates I
> am not aware of).   Although there is technically a Y2K issue here,  I
> cannot see how this extra complexity will help in any real
> situations.   Certificates will not be given lifetimes of order 100
> years, and the concept of a centenial replay attack seems daft in any
> event. (I'm probably going to get roasted here).
>
> 2) I added the "generation-time" field, and Sean questioned its use.
> This time information is allowed in the general X.509 framework,
> althoug X.500 does not use it.  It seems to me that the party doing
> the authentication may have a policy on timeouts, and so this field
> may be useful in addition to the "time" field which is set according
> to the policy of the party being authenticated.  I'd appreciate input
> on this.
>
> Steve Kille