Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-dskpp (Dynamic Symmetric Key Provisioning Protocol (DSKPP)) to Proposed Standard

[Anders Rundgren <[e-mail]>]

Congratulations!

I think that the DSKPP editors and designers did as good as they could,
the only thing that I consider less fortunate was the initial analysis
of the scope:  "Connected OTP" is a rather marginal concept that is not in
big need of a provisioning standard since the idea itself is non-standard.

PSKC is different since it actually addresses the core OTP market for
bulk-packaging of hard token seeds.

Now, what will happen after DSKPP WGLC?

Based on private communication there are currently (at least) THREE
competing efforts in the pipeline.  Two stem from major platform vendors,
and one is my KeyGen2/SKS effort.

Compared to DSKPP the competing efforts support PKI and browser-based
provisioning.

But the most differentiating factor is that the mentioned efforts
intend to establish a de-facto ("preinstall") scheme.  Unfortunately
there is hardly room for more than one such "standard" so I guess
Mr. Darwin's theories will be put to work here :-)

A difficulty with creating standards of the complexity of DSKPP is that
it takes an excessive amount of calendar time while still often lacking
real-world testing.

The competing efforts therefore all try to avoid this trap by offering early
code + spec and deferring a possible standardization effort to a future date.

Microsoft did this with Information Cards and it seems to have payed off.
If they OTOH had started with an untested input specification in OASIS
or the IETF, they would (after 4-5 years...), had ended-up with a horribly
complex "committee" beast that few would be able to interop with except
by trial and error.

KeyGen2/SKS takes this concept to a new extreme since it actually calls
for new hardware, but AFAICT smart cards have the last decade deviated
from Moore's law by at least TWO MAGNITUDES.  I.e. they are generally
under-performing and riddled by dated standards.  Transaction-based
provisioning could make smart cards mainstream on the Internet together
with browser-provisioning, E2ES, and support for federation schemes
like Information Cards (needed by the US "e-authentication" program).
In fact, my hope is that you will be able to buy low-end tokens at
Wal-Mart because augmenting the described capability to the widely
popular USB mass storage units will only add some 50 cents to the
end-user price.  And there will be just *one* driver/platform.

Anders


On 2010-08-06 18:07, [e-mail] wrote:
> Martin,
> 
> Thank you for the information below.
> 
> Regarding the missing reference to XML, you are correct:  Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2008/REC-xml-20081126/ is required.  This will be added to the next version of the DSKPP I-D.
> 
> Andrea
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of "Martin J. Dürst"
> Sent: Tuesday, July 13, 2010 6:55 AM
> To: [e-mail]
> Cc: [e-mail]; IETF-Announce
> Subject: Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-dskpp (Dynamic Symmetric Key Provisioning Protocol (DSKPP)) to Proposed Standard
> 
> Dear IESG,
> 
> On 2010/05/27 6:48, The IESG wrote:
>> The IESG has received a request from the Provisioning of Symmetric Keys
>> WG (keyprov) to consider the following document:
>>
>> - 'Dynamic Symmetric Key Provisioning Protocol (DSKPP) '
>>     <draft-ietf-keyprov-dskpp-11.txt>  as a Proposed Standard
>>
>> This is a second Last Call and is intended to confirm community
>> support for publication with respect to two specific issues:
>>
>> (1) As a result of IESG evaluation, an informative reference to RFC 2781,
>> "UTF-16, an encoding of ISO 10646", was changed to a normative
>> reference.  RFC 2781 was published as an Informational RFC; the IESG
>> would like to determine whether the community believes RFC 2781 is
>> sufficiently mature for a normative downref.
> 
> I'm only commenting on this point, not on point (2).
> 
> RFC 2781 was done as informational mainly to make clear that the default 
> encoding for Unicode in the IETF is UTF-16. The main thing that RFC 2781 
> does is point to Unicode and ISO 10646 as the definitive reference for 
> UTF-16.
> 
> RFC 2781 also defines the labels UTF-16, UTF-16BE, and UTF-16LE for 
> labeling streams of UTF-16-encoded text. These labels come with very 
> specific provisions for endianness and for use of the BOM (byte order 
> mark). From the context of using 'UTF-16' in 
> draft-ietf-keyprov-dskpp-11.txt, I think it is amply clear that this 
> refers to text that always starts with a BOM, because otherwise, it 
> wouldn't be well-formed XML.
> 
> So I think the way this is done is fine. However, I do not think that a 
> reference to UTF-16 (and for that, to UTF-8) was strictly needed, 
> because these are defined indirectly by XML. On the other hand, I was 
> VERY surprised to not find XML as a normative reference!
> 
> Regards,   Martin.
> 
>> (2) IPR notice #332 may apply to this document, but is not explicitly
>> linked to this draft.  Since this was not highlighted in the Last Call,
>> the IESG would like to determine whether this affects community
>> consensus.  For additional information, see:
>>
>>        https://datatracker.ietf.org/ipr/332/
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> [e-mail] mailing lists by 2010-06-09. Exceptionally,
>> comments may be sent to [e-mail] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-11.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16358&rfc_flag=0
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>