Subject: Agenda update and slides reminder

From: Stefan Santesson <[email-masked]>
Date: Fri, 20 Mar 2009 16:18:10 +0100

I have posted a hopefully final agenda to the PKIX meeting available at:
http://www.ietf.org/proceedings/09mar/agenda/pkix.txt

Meeting materials received so far are available at:
https://datatracker.ietf.org/meeting/74/materials.html

I need all presentations sent to me before 17.00 San Francisco time on
Sunday so I can have them all posted before the meeting starts at 0900
Monday morning.

Thank you

Stefan Santesson
AAA-sec.com

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 23 Mar 2009 15:37:51 +0100

I'm sorry about not being able to visit the IETF.

In case there will be any interesting evening discussions may I add
something that you could talk about?

As some of you may know the <keygen> tag was dismissed from
the HTML5 WG spec. because it was found to be inferior.
<keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.

The idea of putting a key-generation mechanism in a page-description
language was more like a patch by Netscape more than a decade ago.

Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
proposed as the foundation for a standard.

I think it is about time to create something more thought-through that
also supports smart cards and similar crypto containers:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

It is worth noting that the scheme above does not work with PKCS #11,
JCE, or CryptoAPI for key provisioning (since they do not support
key attestations), but for key usage.

Although not exploited in the current spec., key attestations can also
be extended to bind declared PIN policies to generated keys.   This
potentially enables a technical security for out-in-the-field on-line
key provisioning that is in par with in-house production.  The use-case
for this includes:
- Consumer PKIs
- Spare cards for employees that are far from their homebase
- Mobile devices with build-in crypto HW

The realization of this project is not going particularly quick (it is
not my day-job), but it is not standing completely still either.

Anders

Stefan Santesson wrote:
> *Stefan Santesson
> *AAA-sec.com

---

From: Nuno Ponte <[email-masked]>
Date: Mon, 23 Mar 2009 16:12:05 +0000

Besides the old keygen tag, Mozilla offers a more powerful method 
for key provisioning, based in Javascript:

https://developer.mozilla.org/en/JavaScript_crypto

     It may be a starting point...

     Regards,

                     Nuno Ponte

Em 23-03-2009 14:37, Anders Rundgren escreveu:
>> I need all presentations sent to me before 17.00 San Francisco time 
>> on Sunday so I can have them all posted before the meeting starts at 
>> 0900 Monday morning.
>>
>> Thank you
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>
>
>
>

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 23 Mar 2009 11:06:48 -0700

Ciao,

as a practitioner in the PKI area, I have to say that we need to have a
more powerful tool than the <keygen> tag. This said, I have to underline
that as a developer *I LOVED* the <keygen> tag because it worked all the
times, for many years, it was simple and easy to support.

Supporting other solutions took me a lot of development work and supporting
them was time and resource-consuming.

We need one standard, and we need to address *USABILITY* from three point
of view:
- Users
- Developers (Browsers)
- Developers (CAs - PKI Deployers)

So.. is there going to be some discussion about this ``at the bar'', offline
or somewhere else ?

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 23 Mar 2009 20:55:59 +0100

Hi Nuno,

Yes, generateCRMFRequest () could serve as a starting point.

That it doesn't support PIN policies which for example IETF's KEYPROV
activity does for symmetric keys, indicates that generateCRMFRequest will
though unlikely suffice as an end point.

The lack of support for subject key attestations like for example specified by
the TrustedComputingGroup is IMHO a disqualifying factor for all existing
browser key-gen schemes.

Regards
Anders

----- Original Message ----- 
From: "Nuno Ponte" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>; "'IETF-pkix'" <[email-masked]>
Sent: Monday, March 23, 2009 17:12
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder

     Regards,

                     Nuno Ponte