Subject: Re: [pkix] Agenda requests for Paris

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Mar 2012 17:19:30 +0100

I have posted a preliminary agenda at:
http://www.ietf.org/proceedings/83/agenda/agenda-83-pkix.txt

I do lack presentations on current ongoing drafts.
If you are currently editing a PKIX WG draft, please notify me and Steve
if you need an agenda slot or not

/Stefan

On 12-02-28 11:49 PM, "Stephen Kent" <[email-masked]> wrote:

>Folks,
>
>I have already sent a message noting our meeting day/time/room.
>
>Please let Stefan and me know if you want a slot on the agenda.
>
>Thanks,
>
>Steve
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Mar 2012 19:04:35 +0100

This is an issue that I preliminarily set on the agenda.

I'll keep it there unless a discussion following this mail proves my need
to be unnecessary.

The background of the need is certificates issued, using a SAML assertion
as means of authenticating the the user in the enrollment process.
The specific application is a central signing service offering users the
capability to sign by simply authenticating to the signing service and
accept to sign some data. The signing service will then generate a key
pair on behalf of that user, issue a signing certificate and sign the
document using the generated key.

This is a signing model that currently is considered as a solution for
allowing citizens to sign for example tax declarations in sweden.

Now, the signing service will get the user's identity from a SAML
assertion and then squeeze it into a subject name.
Eventually this will cause some loss of semantics as the flavor of
attributes in SAML federations are a lot larger than the set of attributes
normally required in PKI standards, such as RFC 3739 (Qualified certs).

In a prototype signing service I have created, I needed a way to capture
this delta in the certificate, by including information about the SAML
assertion used to authenticate the used into the cert itself.

I have looked at other solutions to this problems.
One proposed way to do this is to include the complete SAML assertion in a
certificate extension.

I don't like that for several reasons:
- First, and most importantly it is an integrity problem. I may not want
to give away all information in the SAML assertion in the cert I'm issuing.
- Secondly it explodes the size of a regular cert too include a full XML
based assertion, for no obvious gain.

For our prototype service I simply created a simple QC statement (as this
is purely an issue for QC like certs) where I would allow arbitrary base64
encoded data in an IA5String marking identifying the encoded data format
with a MIME type and an OID for the internal datastucture.

Here is a printout example of this statement from a sample cert, where I
stuffed the data in JSON format:

QCStatement 6: AuthContextQCStatement
eID2SAMLContext (1.2.752.59.54138.2.1.1)
Content type: application/json
{ 
"authContextInfo": [
  { "name": "AuthType", "value": "shibboleth" },
  { "name": "Shib-Application-ID", "value": "eid2csig" },
  { "name": "Shib-Identity-Provider", "value":
"https://eidm.demo.ubisecure.com/uas" },
  { "name": "Shib-Authentication-Instant", "value":
"2012-03-16T17:42:09.488Z" },
  { "name": "Shib-AuthnContext-Decl", "value":
"https://eidm.demo.ubisecure.com/uas/saml2/names/ac/password.2" } ],
"idAttributes": [ 
  { "name": "displayName", "id": "urn:oid:2.16.840.1.113730.3.1.241",
"value": "[email-masked]" },
  { "name": "sn", "id": "urn:oid:2.5.4.4", "value": "Santesson" },
  { "name": "givenName", "id": "urn:oid:2.5.4.42", "value": "Stefan" },
  { "name": "personalIdentityNumber", "id": "urn:oid:1.2.752.29.4.13",
"value": "194103219202" },
  { "name": "mail", "id": "urn:oid:0.9.2342.19200300.100.1.3", "value":
"[email-masked]" },
  { "name": "mobileTelephoneNumber", "id":
"urn:oid:0.9.2342.19200300.100.1.41", "value": "+46767861337" },
  { "name": "persistent-id", "id": "urn:oid:1.3.6.1.4.1.5923.1.1.1.10",
"value": "52000fcc4f024c2a99dd8e6989ee319d9af3af3e" }
] }

The ASN.1 content of the statement is:

SEQUENCE(2 elem)
OBJECT IDENTIFIER1.2.752.59.54138.2.1.1
  SEQUENCE(2 elem)
       PrintableString  "application/json"
       IA5String        "eyJhdXRoQ29udGV4dEluZm8iOlt7Im...

The OID is my private identifier for the data structure hold in the
IA5String
The IA5String holds base64encoded JSON as described in the example above.

This is only supposed to be used within a community that understands this
structure.
It effectively allows mapping between federated identities communicated in
SAML assertions and identities stored in signature certificates based on
the same federated identity.

QUESTIONS TO THE WG:

Is there anything of this that would be suitable for PKIX, mainly to add
the QC statement (but not my private JSON structure)?
Is there another way to do this that would be better?
Or is there a reason why I should not do this at all?

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 17 Mar 2012 09:56:31 +0100

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/feb1_nist-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

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 17 Mar 2012 13:32:13 +0100

Anders,

It does not work that way, no matter how interesting your issue might be.

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

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 17 Mar 2012 14:09:51 +0100

> 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

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 17 Mar 2012 16:25:48 +0100

Stefan,

I have no objections whatsoever to the proposed extension.

What the proposal does however, is *indirectly* pointing to the fact
that client-side PKI doesn't work particularly well for consumers.

This has nothing to do with the greatly oversold claim that a certificate
must be usable everywhere, but due to the fact that there is a bunch of
missing standards, serving this specific market and usage.

Another plausible explanation is that the Swedish government are doing
strange things which calls for unusual solutions.

Regardless what the reason(s) may be, something seems pretty wrong here,
particularly from a standardization perspective.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 18 Mar 2012 01:45:58 +0100

Anders,

You are missing the point.

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" <[email-masked]> wrote:

>>>http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nis
>>>t-
>>> 800-63-1_overview_enewton.pdf
>>>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 18 Mar 2012 01:50:05 +0100

Stefan

>I have no objections whatsoever to the proposed extension.

...

>particularly from a standardization perspective.

These two statements seems to contradict each other.

Or am I missing something?

My post is not about the Swedish infrastructure. That is just a use case.
Try viewing the proposal from a generic perspective. Is it generally
useful. If not, it has no place in a standard.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 18 Mar 2012 10:37:39 +0100

> 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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Mar 2012 13:15:34 +0200

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. 

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: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: 18 March 2012 11:38
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: [pkix] Agenda requests for Paris

IMHO, "relevance" has become an overarching issue for SDOs due to the fact that the IT-landscape has changed tremendously the last ten years:

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.
>> 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.
>>
>> 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.
>>>
>>>> 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?
>>>>
>>>> "Derived Credentials" is probably a better solution than "putting 
>>>> PIV on a string":
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 18 Mar 2012 16:30:09 +0100

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

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 18 Mar 2012 16:43:36 +0100

Anders,

Do you have an A shaped teflon non-stick desk at your office?
I think it would suit your quite well.

/Stefan

On 12-03-18 4:30 PM, "Anders Rundgren" <[email-masked]> wrote:

>> 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
>> 
>>of any interest to you or Steve, PKIX's future probably is about
>>managing the PKI core documents (Certificates, CRL and OCSP).
>> 
>>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.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Mar 2012 22:01:17 +0200

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=[email-masked]" 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:[email-masked]] 
Sent: 18 March 2012 17:30
To: Yoav Nir
Cc: Stefan Santesson; [email-masked]
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

>>> You mean that IETF statutes doesn't permit discussing possible 
>>> future work-items without a proposer actually being physically present?
>>> 
>>>>> embedded credentials will most likely constitute of the bulk of 
>>>>> the client-side of PKI?
>>>>> 
>>>>> http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/fe
>>>>> b
>>>>> 1_nis
>>>>> t-
>>>>> 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.
>>>>> 

Scanned by Check Point Total Security Gateway.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 19 Mar 2012 00:34:16 +0100

On 2012-03-18 21:01, Yoav Nir wrote:
> 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.

Agreed.

> 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.

Exactly.  And that puts us in a new situation.  But it doesn't stop there.
These systems will among many things emulate smart cards (already showcased
by Microsoft: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T )
which is a much better idea than "putting PIV on a string" like:
http://us.blackberry.com/ataglance/security/products/smartcardreader

> 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.

I have probably the last 12 months or so posted some 50 mails on the subject
(including numerous links to various documents and presentations) so it has
indeed been "discussed".

However, the responders generally dismissed the gap analysis in spite of the
fact that Google's Wallet builds on similar principles.

At the core of such systems you find end-2-end security which means that it is
the cryptographic module and the issuer that are talking, or to be more correct;
it is the issuer that does the talking, the cryptographic module is only a responder.

In addition, most (if not all), end-2-end security systems that perform multiple
operations build on the creation of an initial session key which is subsequently
used for securing the rest.  This concept also allow a set of operations to be
performed as a transaction which is important from a robustness perspective.

These principles have little or nothing in common with CMC, CMP, SCEP, or EST
since the latter were not designed for user self-enrollment of the kind that
mobile devices with embedded security hardware [IMO] mandate.

Then we had this pretty confusing debate about PIN-codes versus enrollment.
At the end it felt mainly as an "Ad Hominem" thing unless the PKIX WG is actually
unaware of two-factor authentication tokens which I find hard to believe.

After those experiences I don't think PKIX is the right place for creating
enrollment standards for the virtual army of consumers or enterprise users
with mobile devices, but I leave that topic to the chairs and others to think
about in Paris or elsewhere.

Since you wondered what I had in mind you may take a peek in the following:
http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf
Note: It is a browser-based solution and also uses XML so it falls way outside of PKIX domains.
However, since Apple also use XML in their excellent VPN/SCEP bootstrap scheme and permits browser-invocation I feel pretty comfortable regarding choice of core technologies.

AFAICT there is no need to have specific enrollment standards for payment
credentials; "a key is a key" so any new scheme should also serve as the
foundation for virtual credit cards.  I don't expect credit-cards to exist
10 years from now.  Cash will though never [completely] go away!

Here there should some 100 pages of more stuff but that wouldn't pass the
mailing-list limit...

Anders

If you want to standardize "enroll://CN=[email-masked]" it's probably in PKIX too.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 10:12:29 -0400

Anders,

You send a fair number of messages to this list, but you rarely seem 
to contribute in a positive sense. For example, you don't take the 
time to write an I-D addressing a PKI standards topic, post it as an 
individual submission, and then ask of the WG to consider it for 
adoption. Instead, you complain about how the WG is not addressing 
the right topics and tell us about your ideas in a general sense. 
That's not very helpful. Your most recent request illustrates this 
point, i.e., you want Stefan to devote a slot to a topic where you 
will not be present, have not persuaded someone to brief your slides, 
etc.

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 19 Mar 2012 16:15:59 +0100

> will not be present, have not persuaded someone to brief your slides, 

Steve,

Since a standard of the kind I have been elaborating on (including
links to detailed specifications and as well as to somewhat lighter
presentations), would probably exceed 200 pages, writing an I-D is
hardly an option unless there is a genuine interest for the topic
in question.

But I guess we now have indirectly performed this poll so you may
very well stick to the agenda as written.

Anders