Subject: [KEYPROV] FW: New Version Notification - draft-ietf-keyprov-dskpp-12.txt

From: <[email-masked]>
Date: Sun, 29 Aug 2010 23:21:02 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, August 29, 2010 11:15 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification - draft-ietf-keyprov-dskpp-12.txt 

New version (-12) has been submitted for draft-ietf-keyprov-dskpp-12.txt.
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-12.txt

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-keyprov-dskpp-12

IETF Secretariat.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 30 Aug 2010 09:04:07 +0200

A.7
    "Application Protocol Data
     Units, or APDUs) are encrypted with a pre-issued card manufacturer's
     key and sent directly to the smart card chip, allowing secure post-
     issuance in-the-field provisioning"

Andrea, this is *still* inappropriate for the DSKPP I-D because the only
E2ES schemes I have heard about (GP/ETSI SCPxx and SKS/KG2) are fairly
different to DSKPP since they build on having a *session* with the
container, and using "rolling MACs" for maintaining integrity in a
multi-stage provisioning/update operation.

To achieve E2ES the container and protocol *must* be 1-2-1 on "APDU"
level.  PKCS #11, CryptoAPI, and JCE do not support E2ES provisioning
so this feature is really quite distinct to just having a known key in
the container which any crypto-APIs can support.

I.e. E2ES is not an DSKPP "implementation option", it is a description of
how *other* (more or less competing) schemes have addressed provisioning.

Microsoft supports E2ES in their ILM (Identity Lifecycle Manager) since
2007 so it is not just a(nother) crazy idea by your former college :-)

The RSA division probably needs to begin dealing with E2ES in order to
keep up with the rest of the token-provisioning world.

If you take the step to 32-bit processors you may even be able to add
transaction-based operation which is the next logical step after E2ES.

/Anders

Doherty, et al.           Expires March 2, 2011                [Page 76]

Internet-Draft                    DSKPP                      August 2010

    issuance in-the-field provisioning.

[email-masked] wrote:
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov
>

---

From: <[email-masked]>
Date: Mon, 30 Aug 2010 08:29:09 -0400

All,

At this stage, I propose that we have two options for addressing Ander's
comment below:

1. Remove Section A.7

2. Defer addressing this for the next version of DSKPP

Thoughts?

Andrea
 
-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Monday, August 30, 2010 3:04 AM
To: Doherty, Andrea
Cc: [email-masked]
Subject: Re: [KEYPROV] FW: New Version Notification -
draft-ietf-keyprov-dskpp-12.txt

A.7
    "Application Protocol Data
     Units, or APDUs) are encrypted with a pre-issued card
manufacturer's
     key and sent directly to the smart card chip, allowing secure post-
     issuance in-the-field provisioning"

I.e. E2ES is not an DSKPP "implementation option", it is a description
of
how *other* (more or less competing) schemes have addressed
provisioning.

/Anders

[email-masked] wrote:
> To: [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]