IETF keyprov WG meeting - November 2008
Minutes/notes - draft (scribe: David Black)
October 19 - Minneapolis, MN
-----------------------------------

See slides - these are notes on major discussion points/conclusions.

-- PSKC (Mingliang Pei)

Status update of changes since -05 version of draft.

AES-CBC 128 is the mandatory algorithm encryptio algorithm instead
of a key-wrap algorithm due to lack of hardware support for key wrap
in some important devices.  AES-CBC is widely supported.

PCI compliance is only important for certain credit card application
domains (e.g., chip-and-pin does not need PCI compliance).  Need a
general security consideration that will cover desirability of
confidentiality of personally identifiable information, but don't
need to specifically mention PCI.

Be careful about namespace usage.  W3C is paying for a lot of
completely useless traffic caused by software automatically trying
to fetch URLs that are for namespace usage only.  Using URNs instead
of URIs/URLs prevents this stupidity, and is the preferred path
forward.

Separate IANA algorithms registry will be needed.  Pasi Eronen (AD)
does not want algorithms that are not publicly specified mentioned
in a Proposed Standard RFC.  A separate Informational RFC should be
used to specify this (IPsec and S/MIME algorithm usage specs are
examples).

Can add element for version number without changing to new namespace.
Need to specify version match rules (e.g., match 1.0 vs. 1.*).  XML
Directorate will be asked about how to specify version syntax and
matching.

-- ASKC (Sean Turner)

Waiting on PSKC draft to become stable.  In essence, will convert
XML in PSKC to ASN.1 for contexts in which ASN.1 is useful.

-- DSKPP (Andrea Doherty)

Working on comments.  Will need a -07 version of the draft to deal
with all the comments, including Pasi Eronen's AD comments.

Authentication Data calculation - K (key) has to be passed by both
parties, just using it in the KDF isn't enough to address the issue.

Any trust anchor work should go into a separate document.  This avoids
further delay to DSKPP and will make coordination with trust anchor
work in PKIX easier.  This includes the alternative key confirmation
approach.  It may be desirable to carve out a "slot" in the current
DSKPP protocol so that any addition here does not require a version
number change.