Re: [pkix] EST-02 smart card question

[Max Pritikin <[e-mail]>]

On Aug 19, 2011, at 2:34 PM, Anders Rundgren wrote:

> On 2011-08-19 21:55, Max Pritikin wrote:
> 
>> I'm wondering if your underlying concern is how the CA server can determine
>> that the key is actually on the smartcard. Is this correct? Is this your concern?
> 
> Well, my #1 concern is how you can create a smart card enrollment system that
> allows you to buy an empty card, insert it, go to a CA with a browser, authenticate (in
> some way) and then get certificates provisioned including things like issuer-defined
> PIN-codes etc.

We are of course assuming that the browser/client supports EST and the smartcard itself. In which case I see no major impediment to what you describe. At most I see an issue with the distribution of policy (e.g. "issuer-defined PIN-codes") but I'm sure we can discuss appropriate methods for that.

Apparently I see the world like this:

EST Server (e.g. CA) => EST protocol => EST Client (e.g. Browser) => Smartcard

In my prototype I've focussed on the use of a general purpose web server as the server interface and am very interested in Browser support for the client. The flexibility of the browser UI as a client is of course as compelling here as it is for so many other  solutions. Still to some extent we are only defining the EST protocol so it would be extremely helpful if we could focus this conversation on protocol requirements. 

What is it about this model you've described that requires something different in the protocol? And what differences are you looking for?


> As it appears you indeed need a smart card expert and tons of proprietary software.
> Existing middleware like PKCS #11 does not support on-line provisioning so basically
> the whole thing is toast unless you go far outside of the protocol.  This is probably
> unacceptable to you and PKIX, which to some extent explains why there is a virtual
> army of companies writing smart card middleware [primarily] for governments.
> 
> My take on this, is creating a complete system where all interfaces are defined:
> 
>                   CA => Browser => Protocol => Middleware => Container

You appear to use a different ordering than I do and I'm not understanding your proposed stack. Are you proposing that the protocol is run on the local client and communicates between the web browser and some middleware/driver for the smartcard? I'm not seeing how that perspective helps us.

- max

> Yes, there are User interfaces as well in layer 2-4.
> 
> Although this may look very "cardish", the design is actually targeting smart
> key-stores including enhanced "soft tokens".
> 
> Will this be a "standard"?  I leave that to the market to decide :-)
> 
> Anders
> 
>> On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote:
>> 
>>> Max,
>>> You skipped the core of subject line.  
>> My apologies. I was unaware that you had hidden your question in the subject line and that the body of your message was extraneous. :)
>> 
>>> How is smart card enrollment supported by EST?
>> Obviously EST depends on existing cryptographic primitives which are be provided by common smartcard APIs. As such it is trivial to show that a keypair contained on a smartcard can be used in an EST exchange. As an expert in this area I suspect you are very familiar with these APIs and their capabilities so my assumption is that you have a different concern. 
>> 
>> I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern?
>> 
>> If email as a communication medium isn't working for this conversation I'd be happy to host a webex conference call with any interested attendees. Or I'd be happy to unicast my phone number to you for an offline conversation. 
>> 
>> - max
>> 
>>> Since EST-02 does not mention words like Browser, Middleware, and Tokens it is hard to believe that these items have gotten much consideration during the design.  This is nothing to get hung about
>>> because it applies to all PKIX enrollment schemes.
>>> 
>>> However, as a person involved in smart card deployments, I don't see the point hoping that somebody else will take care of the mess created by leaving half of the enrollment infrastructure undefined.
>>> 
>>> Anders
>>> 
>>> On 2011-08-19 19:28, Max Pritikin wrote:
>>>> Response inline,
>>>> 
>>>> On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote:
>>>> 
>>>>> Lets say you run a small Windows-only enterprise using the latest server and client versions.
>>>>> 
>>>>> Now, assume that you want to use smart cards instead of passwords.
>>>>> 
>>>>> Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who       knows all about drivers and cards.  Only government agencies would ever considering buying into that.
>>>>> 
>>>>> How does EST relate to this scenario?
>>>> This doesn't strike me as a technical discussion -- Microsoft's licensing/pricing policy is not based on technical protocol details. I don't work for Microsoft and am not in a good position to hypothesize about their business decisions nor do I think this is this the appropriate forum for that discussion. 
>>>> 
>>>> We could have an interesting discussion about the role of a consistent message from the standards community in driving interoperability amongst vendors. But that isn't technical in nature either.
>>>> 
>>>> The best I can offer is the observation that Microsoft's current offerings include a undocumented(?) profile of CMC combined with a non-RFC5273 related transport. Additionally Microsoft's new work includes a newer MS-WSTEP SOAP based enrollment protocol which is interesting but is also proprietary and includes dependencies on SOAP, WS-Security and WS-Trust that I think is overkill. Similarly VerSign has a web services api which is consistent with Microsoft's ideas but is not interoperable.  
>>>> 
>>>> Broadly, I argue that EST provides clarify regarding the existing CMC and CMC Transport options in a way that meets the requirements exposed by those non-standards based implementations and drives interoperability. I would like to work more closely with both Microsoft and Versign on their recent efforts in this area and have appreciated the conversations I've had with them about these technologies. Their input has been valuable in forming my personal opinions which helped shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS stack).  
>>>> 
>>>> I continue to hope that EST helps drive greater interoperability which I believe will address some of your non-technical concerns. I believe that our focus, in this forum, is to move the IETF PKIX standards forward. It is interesting to compare and understand our efforts in regards to proprietary solutions from various vendors -- and I strongly believe in working together as a community -- but ultimately some product teams are going to explore their own non-standards based solutions and we can't let ourselves be too distracted by that. 
>>>> 
>>>> - max
>>>> 
>>>>> Anders
>>>>> 
>> 
>