Subject: [pkix] Certificate Enrollment Protocols - Gap Analysis

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jun 2012 13:18:47 +0200

- No support for two-factor authentication tokens
- No support for security hardware
- No support for key algorithm-agility with respect to the enrolling client
- No support for external key attributes including logotypes
- No support for enrollment process status verification by the issuer
- No support for key management
- No support for server-based policies
- No support for transaction-based enrollments
- No support for a standardized browser interface
- No support for VPN profiles [1]
- No support for "ACL"-like data for keys
- No support for symmetric keys

Anders

1] Apple has extensive support for VPN profiles in their proprietary iOS solution

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 25 Jun 2012 14:02:10 +0000

A terse grenade deserves a terse response:

> - No support for two-factor authentication tokens
false

> - No support for security hardware
false

> - No support for key algorithm-agility with respect to the enrolling client
false

> - No support for external key attributes including logotypes
false

> - No support for enrollment process status verification by the issuer
a msg for this has been suggested and we're thinking about the format

> - No support for key management
false

> - No support for server-based policies
false. particularly with respect to cert attributes which is being added because a concerned party wrote up their idea and presented it as working text for inclusion. Unlike your suggestions. 

> - No support for transaction-based enrollments
clarification requested.

> - No support for a standardized browser interface
browser interfaces are for browsers.

> - No support for VPN profiles [1]
the protocol is extensible and if you'd like to write a draft for this it would be easy to do. 

> - No support for "ACL"-like data for keys
"ACL"-like data is not very well defined. Perhaps you should submit a draft.

> - No support for symmetric keys
false

Have a great day,

- max

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

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jun 2012 16:30:52 +0200

> A terse grenade deserves a terse response:

Max, this has little or nothing to do with EST; it's meant to be fairly universal.

This is BTW just a summary over the numerous issues I have posted in this list.
My take on this is fully covered by published specifications.  That doesn't
mean that there is only one way of achieving (or even defining) a goal but
the alternatives have not been much articulated as far as I can see.

There was also a consensus (using IETF norms...) that security hardware
is out of scope for PKIX and you did not protest :-)

Anyway, most of the listed goals are unreachable using the PKIX "fat-crypto" approach.

Security hardware does currently not, and have IMO no reason to ever parse CMS or XML.
As an invited expert member of TustedComputingGroup I think I can say (without
breaking the NDA...), that it is not on the road-map for these guys either.

Best
Anders