Subject: Re: [pkix] another doc for WG consideration

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 16:21:40 -0400

As author, I support adoption of this work.

spt

On 7/25/11 5:26 PM, Stephen Kent wrote:
> There was a presentation on extending CMC to accommodate scenarios
> in which a CA/AR generates the key pair for the subject. I'd like to
> hear comments from the WG about adopting this as a work item as well.
>
> Steve
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 05 Aug 2011 22:57:22 +0200

> As author, I support adoption of this work.

I have no objections to this work, but you should be aware of
SKS/KeyGen2 that in addition to offering the mentioned feature
also provides support for

- Key agility through negotiation
- Symmetric keys (like DSKPP/RFC 6063)
- Permitted key algorithms
- Arbitrary key attributes including
  . OTP parameters (digits, username)
  . Information Cards (resurrection of Microsoft's failed project)
  . Application ACLs (restrict application access)
  . Executable code (like JavaCard)
  . VPN parameters (like Apple already have in their iPhone enroll)
  . etc etc
- Key PIN and PUK deployment (standard bank requirement)
- Logotypes (a completely different take than RFC 6170)
- Password-free but secure enrollment through device certificates

all running in and E2ES (End-to-End-Secured) transaction.
The latter means that you either get all or nothing.
The E2ES session terminates with a signed receipt to issuer in
the case of a success.

To be hosted in a browser near you using tokens you can buy at
Wal-Mart in the form of moderately upgraded USB memory sticks.

Anders

---

From: Russ Housley <[email-masked]>
Date: Fri, 5 Aug 2011 17:27:01 -0400

Key generation by the CA is real in some very important situations today.  Our protocols need to support it,

Russ