Re: [pkix] Agenda requests for Paris

Yoav Nir <ynir@checkpoint.com> Sun, 18 March 2012 20:01 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2421F84E1 for <pkix@ietfa.amsl.com>; Sun, 18 Mar 2012 13:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.49
X-Spam-Level:
X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+HmElsQ2fSv for <pkix@ietfa.amsl.com>; Sun, 18 Mar 2012 13:01:24 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5E021F84B4 for <pkix@ietf.org>; Sun, 18 Mar 2012 13:01:23 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2IK1JJs019752; Sun, 18 Mar 2012 22:01:19 +0200
X-CheckPoint: {4F663EB3-2-1B221DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 18 Mar 2012 22:01:19 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Date: Sun, 18 Mar 2012 22:01:17 +0200
Thread-Topic: [pkix] Agenda requests for Paris
Thread-Index: Ac0FQeGAJuugj7NwRReQrbEvTN5MKQ==
Message-ID: <1BC28887-4F62-437A-A117-C833A0968E05@checkpoint.com>
References: <CB8AECC6.369C0%stefan@aaa-sec.com> <4F65ACE3.1050307@telia.com> <006FEB08D9C6444AB014105C9AEB133F017A75325A19@il-ex01.ad.checkpoint.com> <4F65FF81.7070007@telia.com>
In-Reply-To: <4F65FF81.7070007@telia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stefan Santesson <stefan@aaa-sec.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Agenda requests for Paris
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2012 20:01:25 -0000

Well, PKIX standardized CMC and CMP, and Cisco made SCEP, and none of these seems particularly tied to Windows as opposed to Mac OS, Linux, phones running iOS, or parallel sysplexes of mainframes running z/OS.

It's true that iOS and other operating system (not necessarily "mobile") tend to decrease the amount of control given to application writers, so you can't just write some application that performs enrollment and store the resulting certificate in the operating system store for use by other applications. Are you proposing some new API or URI scheme where the application can ask the operating system to perform enrollment using one of the above or a new protocol? If all these protocols are lacking something, then PKIX would be the right place to discuss it. If you want to standardize "enroll://CN=somebody@theCA.example.com" it's probably in PKIX too. 

If it's just about Apple not letting us use our favorite enrollment protocols, there's not much PKIX can do about it. 

I find this complaint about attitude strange. This list gets frequent criticism from some people (Prof. Gutmann springs to mind) about PKIX being willing to standardize anything that looks like ASN.1. This is a group that has standardized two protocols for enrollment and two protocols for certificate status validation. I also haven't seen anything in Stefan's responses that amounts to a rejection of your idea. It's just not clear what that idea is. Yes, there are more mobiles out there. Maybe some of them come with embedded credentials (that can be used by applications). That this will be the bulk of client-side PKI is debatable. I'm still missing what we are supposed to discuss. What do *you* propose that PKIX do about it?

Yoav

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com] 
Sent: 18 March 2012 17:30
To: Yoav Nir
Cc: Stefan Santesson; pkix@ietf.org
Subject: Re: [pkix] Agenda requests for Paris

On 2012-03-18 12:15, Yoav Nir wrote:
> Anders,
> 
> IMO "relevant" is whatever the group decides is relevant as long as 
> the IESG agrees. If you want the working group to do something, such 
> as mobile devices with embedded credentials, you should propose this to the group.

Once upon time there was a single enterprise OS standard; it was called Windows.
Each vendor could easily create s.c. "Windows-compatible" solutions by a bunch of proprietary DLLs and EXEs.

These days are gone.  Now customers are facing a multitude of mobile devices with quite different software distribution and security models.

Currently I'm struggling with a mobile PKI + FW using Cisco's ASA + AnyConnect.
The absence of useful enrollment/setup standards in this space force you into "rooted" phones, quirky user-interfaces, least common denominator functionality, and extended deployment times.

Unless something in the process (and attitude) changes, I remain convinced that PKIX should stick to the PKI core and leave applications like EST aside.

Anders

> 
> A few years ago I had a proposal to IPsecME but couldn't attend. I asked someone else who *was* attending to present it for me. I prepared the slides and everything, and listened to the audio stream. While there is work being done (see the vmeet list) that may allow people to present remotely, results so far have been a mixed bag. Surely you can go to https://www.ietf.org/registration/ietf83/attendance.py , and find one of the 1347 people listed there (as of right now) who might be interested enough to present slides that you would prepare for him or her. 
> 
> I don't think a time slot reserved for "discussion of the fact that mobile devices with embedded credentials will most likely constitute of the bulk of the client-side of PKI" will do much without a draft, a presentation, or at the very least, someone to lead the discussion.
> 
> Yoav
> 
> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf 
> Of Anders Rundgren
> Sent: 18 March 2012 11:38
> To: Stefan Santesson
> Cc: pkix@ietf.org
> Subject: Re: [pkix] Agenda requests for Paris
> 
> On 2012-03-18 01:45, Stefan Santesson wrote:
>> Anders,
>> 
>> You are missing the point.
> 
> Not really, I'm just looking at things from a different angle.
> 
> IMHO, "relevance" has become an overarching issue for SDOs due to the fact that the IT-landscape has changed tremendously the last ten years:
> 
> - Continuously shorter product cycles
> - Vendors that single-handedly define complete and globally operating 
> ecosystems, from devices to services
> - Open source as a means to reduce costs and improve interoperability
> 
> Since "my" issue (affecting billions of other humans) obviously is not of any interest to you or Steve, PKIX's future probably is about managing the PKI core documents (Certificates, CRL and OCSP).
> 
> Thar said, new efforts in the more application-oriented part of the PKI universe, like the recent EST work-item seems much less likely to pan out since these require alien elements like strategy, marketing, and gap analysis.
> 
> OTOH, deployment given the current SCVP/OCSP discussions doesn't seem to be a major issue.  In my world deployment and relevance are synonymous.
> Yes, I know this is a minority view :-)
> 
> Anders
> 
>> 
>> You are free to discuss any issues that are related to the charter of 
>> this WG.
>> If you want to discuss things with other IETFers, it is a great 
>> opportunity to come to the conference and talk to people.
>> 
>> Just don't expect people to spend time discussing your issues at the 
>> meeting unless you are prepared to come and ask for a timeslot.
>> 
>> /Stefan
>> 
>> 
>> 
>> On 12-03-17 2:09 PM, "Anders Rundgren" <anders.rundgren@telia.com> wrote:
>> 
>>> On 2012-03-17 13:32, Stefan Santesson wrote:
>>>> Anders,
>>>> 
>>>> It does not work that way, no matter how interesting your issue 
>>>> might be.
>>> 
>>> You mean that IETF statutes doesn't permit discussing possible 
>>> future work-items without a proposer actually being physically present?
>>> 
>>> Anyway, your college in the Swedish EID2-project Leif Johansson, 
>>> indeed mentioned the very same issue "as highly problematic" in a 
>>> panel session in the IDTrust/NSTIC event that we both attended this 
>>> week in Washington DC.
>>> 
>>> Somewhat related: From what I can see the rationale for EST haven't 
>>> been discussed at all on this list. I don't think even Cisco in the 
>>> end will support EST since it doesn't add functional improvements.
>>> Even the target "Simple PKI client" seems to be left to the reader 
>>> to guess what it could possibly be.  Do YOU know?
>>> 
>>> Anders
>>> 
>>>> 
>>>> If you want to raise an issue at the meeting, then you need to ask 
>>>> for a slot and show up at the meeting.
>>>> If you can't be bothered, convince someone that will be present to 
>>>> do it for you.
>>>> 
>>>> If you can't do that even, then discuss it on the list.
>>>> 
>>>> /Stefan
>>>> 
>>>> On 12-03-17 9:56 AM, "Anders Rundgren" <anders.rundgren@telia.com>
>>>> wrote:
>>>> 
>>>>> Stefan,
>>>>> I will unfortunately not be able to attend.
>>>>> 
>>>>> May I suggest that the crowd spends some 10 minutes on discussing 
>>>>> how PKIX intends to deal with the fact that mobile devices with 
>>>>> embedded credentials will most likely constitute of the bulk of 
>>>>> the client-side of PKI?
>>>>> 
>>>>> Even the US government have realized (it took some time...) that 
>>>>> "Derived Credentials" is probably a better solution than "putting 
>>>>> PIV on a string":
>>>>> 
>>>>> 
>>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/fe
>>>>> b
>>>>> 1_nis
>>>>> t-
>>>>> 800-63-1_overview_enewton.pdf
>>>>> 
>>>>> It is (at least to me) obvious that ambitious efforts such as 
>>>>> President Obama's NSTIC program won't go particularly far without 
>>>>> having secure, convenient, and interoperable enrollment solutions.
>>>>> 
>>>>> However, then we enter the minefield known as "Token Provisioning"
>>>>> which
>>>>> currently only is covered by proprietary solutions like the Google 
>>>>> Wallet.
>>>>> 
>>>>> Giving in to Google may though be the best for the market since a 
>>>>> leading vendor can (as Microsoft did in the past) indirectly 
>>>>> enforce the necessary "compliance" on the other parties.
>>>>> 
>>>>> The opportunity for a standard addressing 5-10 BILLION of 
>>>>> connected devices won't exist 3 years from now, at least if we are 
>>>>> talking about a *used* ditto.
>>>>> 
>>>>> If you are the daring type you might even perform a straw poll on 
>>>>> the topic :-)
>>>>> 
>>>>> Anders
> 


Scanned by Check Point Total Security Gateway.