Thanks for the reviews.
Makes sense. I don't see any downsides. Updated the KIP, to go with Option
2.
I will be starting the vote thread soon.
Thanks,
On Wed, Sep 19, 2018 at 2:17 PM Rajini Sivaram <rajinisiva...@gmail.com>
wrote:
> Hi Manikumar,
>
> Unless there is a downside to option 2 (e.g will it impose character limits
> in the DN), it may be better to go with option 2 for consistency and
> flexibility.
>
> On Wed, Sep 19, 2018 at 5:11 AM, Harsha <ka...@harsha.io> wrote:
>
> > Thanks. I am also leaning towards option 2, as it will help the
> > consistency of expressing such mapping between sasl and ssl.
> > -Harsha
> >
> > On Tue, Sep 18, 2018, at 8:27 PM, Manikumar wrote:
> > > Hi Harsha,
> > >
> > > Thanks for the review. Yes, As mentioned on the motivation section,
> this
> > is
> > > to simply extracting fields from the certificates
> > > for the common use cases. Yes, we are not supporting extracting
> > > SubjectAltName using this KIP.
> > >
> > > Thanks,
> > >
> > >
> > > On Wed, Sep 19, 2018 at 8:29 AM Harsha <ka...@harsha.io> wrote:
> > >
> > > > Hi Manikumar,
> > > > I am interested to know the reason for exposing this config,
> > given
> > > > a user has access to PrincipalBuilder interface to build their
> > > > interpretation of an identity from the X509 certificates. Is this to
> > > > simplify extraction of identity? and also there are other use cases
> > where
> > > > user's will extract SubjectAltName to construct the identity I guess
> > thats
> > > > not going to supported by this method.
> > > >
> > > > Thanks,
> > > > Harsha
> > > >
> > > > On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> > > > > Hi Rajini,
> > > > >
> > > > > I don't have strong reasons for rejecting Option 2. I just felt
> > Option 1
> > > > is
> > > > > sufficient for
> > > > > the common use-cases (extracting single field, like CN etc..).
> > > > >
> > > > > We are open to go with Option 2, for more flexible mapping
> mechanism.
> > > > > Let us know, your preference.
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <
> > rajinisiva...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Manikumar,
> > > > > >
> > > > > > It wasn't entirely clear to me why Option 2 was rejected.
> > > > > >
> > > > > > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <
> > manikumar.re...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > We would like to go with Option 1, which adds a new
> configuration
> > > > > > parameter
> > > > > > > pair of the form:
> > > > > > > ssl.principal.mapping.pattern, ssl.principal.mapping.value.
> This
> > will
> > > > > > > fulfill the requirement for most of the common use cases.
> > > > > > >
> > > > > > > We would like to include the KIP in the upcoming release. If
> > there no
> > > > > > > concerns, would like to start vote on this KIP.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <
> > ps...@hortonworks.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Definitely a helpful change. +1 for Option 2.
> > > > > > > >
> > > > > > > > On 9/14/18, 10:52 AM, "Manikumar" <
> manikumar.re...@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > Hi Eno,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > Most often users want to extract one of the field (eg.
> > CN). CN
> > > > is
> > > > > > the
> > > > > > > > commonly used field.
> > > > > > > > For this simple change, users need to build and maintain
> > the
> > > > custom
> > > > > > > > principal builder class
> > > > > > > > and also package and deploy to the all brokers. Having
> > > > configurable
> > > > > > > > rules
> > > > > > > > will be useful.
> > > > > > > >
> > > > > > > > Proposed mapping rules works on string representation of
> > the
> > > > X.500
> > > > > > > > distinguished name(RFC2253 format) [1].
> > > > > > > > Mapping rules can use the attribute types keywords
> defined
> > in
> > > > RFC
> > > > > > > 2253
> > > > > > > > (CN,
> > > > > > > > L, ST, O, OU, C, STREET, DC, UID).
> > > > > > > >
> > > > > > > > Any additional/custom attribute types are emitted as
> OIDs.
> > To
> > > > emit
> > > > > > > > additional attribute type keys,
> > > > > > > > we need to have OID -> attribute type keyword String
> > > > mapping.[2]
> > > > > > > >
> > > > > > > > For example, String representation of
> > X500Principal("CN=Duke,
> > > > > > > > OU=JavaSoft,
> > > > > > > > O=Sun Microsystems, C=US, EMAILADDRESS=t...@test.com")
> > > > > > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > > > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > > > > > 160d7465737440746573742e636f6d"
> > > > > > > >
> > > > > > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > > > > > "emailAddress"),
> > > > > > > > the string will be
> > > > > > > > "CN=Duke,OU=JavaSoft,O=Sun
> Microsystems,C=US,emailAddress=
> > > > > > > > t...@test.com"
> > > > > > > >
> > > > > > > > Since we are not passing this mapping, we can not extarct
> > using
> > > > > > > > additional
> > > > > > > > attribute type keyword string.
> > > > > > > > If the user want to extract additional attribute keys, we
> > need
> > > > to
> > > > > > > write
> > > > > > > > custom principal builder class.
> > > > > > > >
> > > > > > > > Hope the above helps. Update the KIP.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > > X500Principal.html#getName(java.lang.String)
> > > > > > > >
> > > > > > > > [2]
> > > > > > > >
> > > > > > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > > > > > eno.there...@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Manikumar, thanks. If I understand the KIP motivation
> > right,
> > > > this
> > > > > > > is
> > > > > > > > > currently already possible, but you want to have an
> > easier
> > > > way of
> > > > > > > > doing it,
> > > > > > > > > right? The motivation would be stronger if we had 2-3
> > common
> > > > > > cases
> > > > > > > > (from
> > > > > > > > > experience) where the suggested pattern would solve
> > them, and
> > > > > > > > perhaps 1-2
> > > > > > > > > cases where the pattern would not be adequate and we'd
> > have
> > > > to
> > > > > > fall
> > > > > > > > back to
> > > > > > > > > the existing builder class.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Eno
> > > > > > > > >
> > > > > > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > > > > > manikumar.re...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi All,
> > > > > > > > > >
> > > > > > > > > > We'd appreciate any thoughts / comments on the
> proposed
> > > > options
> > > > > > > for
> > > > > > > > > > customizing SSL principal names.
> > > > > > > > > > We are happy to discuss any alternative
> > > > approaches/suggestions.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > > > > > manikumar.re...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > I have created a KIP that proposes couple of
> options
> > for
> > > > > > > building
> > > > > > > > > custom
> > > > > > > > > > > SSL principal names.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > https://cwiki.apache.org/
> > confluence/display/KAFKA/KIP-
> > > > > > > > > >
> > > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > > > > > >
> > > > > > > > > > > Please take a look.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Manikumar
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
>
