Re: [ietf-provreg] RFC5910 public client implementation

[Jens Wagner <jwagner@hexonet.net>]

Hi Oliver,

Am Mittwoch, den 04.08.2010, 10:28 +0200 schrieb Oliver Peter:
> On Tue, 03 Aug 2010 16:59:27 +0200
> Jens Wagner <jwagner@hexonet.net> wrote:
> > ... 
> > <secDNS:dsData>
> >     <secDNS:keyTag>65535</secDNS:keyTag>
> >     <secDNS:alg>1</secDNS:alg>
> >     <secDNS:digestType>1</secDNS:digestType>
> >     <secDNS:digest>1543C1BABEB5ECAF98774188032928B3CD18299A</secDNS:digest>
> >     <secDNS:keyData>
> >         <secDNS:flags>256</secDNS:flags>
> >         <secDNS:protocol>3</secDNS:protocol>
> >         <secDNS:alg>1</secDNS:alg>
> >         <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
> >     </secDNS:keyData>
> > </secDNS:dsData>
> > <secDNS:dsData>
> >     <secDNS:keyTag>46089</secDNS:keyTag>
> >     <secDNS:alg>5</secDNS:alg>
> >     <secDNS:digestType>1</secDNS:digestType>
> >     <secDNS:digest>2A515440A8AEA13F034191AB0D35DB1DDF7968E8</secDNS:digest>
> >     <secDNS:keyData>
> >         <secDNS:flags>257</secDNS:flags>
> >         <secDNS:protocol>3</secDNS:protocol>
> >         <secDNS:alg>5</secDNS:alg>
> >         <secDNS:pubKey>AQPJ////5Q==</secDNS:pubKey>
> >     </secDNS:keyData>
> > </secDNS:dsData>
> 
> Hm, that output above (<secDNS:infData> I guess?) depends on the
> <extURI> elements specified by the client within the login frame, right?

That's right. I just limited the output to the <secDNS:dsData> element,
as it's using the same syntax in both secDNS-1.0 and secDNS-1.1 (except
for <secDNS:maxSigLife>).

Our gateway returns secDNS-1.1 compatible <secDNS:infData>, if the
client included that namespace as an <extURI> on login.


> In case of using Key Data Interface and specified
> urn...secDNS-1.1 within <extURI> I think you have to return the
> <secDNS:keyData> elements and not the resulting <secDNS:dsData>.
> 
> That's my understanding - please correct me if I'm wrong.

That is correct. We are just supporting the Key Data interface as an
input tool which autocreates DS Data, not sure if that's fully compliant
with section 4.

The one form we support accross all operations is the DS Data Interface
(this is neccessary to support the RFC 4310 in parallel). Some TLDs
require DS Data only, so don't want to force our customers to provide
Key Data if not required.


> I think we will support the Key Data Interface - but not with
> secDNS-1.0 backwards compatibility at the same time.  But the decision
> hasn't been made yet.

As long as you store the Key Data, you can internally convert to
secDNS-1.0 compatible DS Data on-the-fly.

Best,
 -jens


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se