Subject: [pkix] IETF 80: The future of PKIX certificate enrollment protocols

From: Anders Rundgren <[email-masked]>
Date: Thu, 31 Mar 2011 08:14:46 +0200

http://www.ietf.org/proceedings/80/slides/pkix-3.pdf

"Goal is to enable certificate enrollment to get
certificates on to as many types of devices as
possible
– Simplify Enrollment Process

Unfortunately the industry outside of routers is not betting on
PKCS #10 but on "secure messaging" so this effort will not
reach the stated goal. This may actually be an advantage
since standardization of enrollment based on secure messaging
simply isn't going to happen; it will be defined by one of the
now only three US platform vendors that together owns 99%
of the human-oriented client-device market.

Regarding SCEP, I don't see any point in adding, or adjusting
SCEP. Documenting existing practices would do.
An addition would only make support even more complicated
since you (of course) MUST support the old *and* the new stuff
in order to claim to be "SCEP compliant". Dropping the old
stuff is not an option except in an ideal world (which we don't have).

A new protocol SHOULD build on embedded device certificates.
However, there's no need for third-party certificates like the
presentation suggests. A SHA1 of the device certificate
transferred OOB eliminates all crummy password schemes.
A new protocol SHOULD NOT build on assumptions about the
client's cryptographic capabilities; these MUST be negotiated.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Mar 2011 04:59:13 -0400

Anders,

I think we are all aware of your focus re PKI, but PKIX deals with a
broader range of scenarios, which makes consideration of a new, lightweight
cert management protocol appropriate for the WG.

Your contributions to PKIX have always been in the form of e-mail 
messages (no I-Ds, much less RFCs), and many of these tell us that 
what we have done or may do will be a waste of time.

One might imagine that you are trying to enlighten us so that we do 
not waste our time, or trying to persuade us to not pursue actions 
that are in competition with whatever agenda you are pursuing.  The 
first of these is a noble goal, but may not be the best use of your 
time. The second is considerably less noble, and a poor use of our 
time.

Why not avoid such messages, to minimize the likelihood of time being 
wasted by either you or us.

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 31 Mar 2011 07:20:06 -0400

I agree with Steve.

Since a few years back, I started deleting all messages from Anders and responses to it.

I opened this one for two reasons: It was from Steve and I am getting old and had senior moment of not being able to relate the subject line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, March 31, 2011 4:59 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols

Anders,

Steve

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

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 31 Mar 2011 11:01:47 -0400

At the risk of speaking heresy, I agree with some of what Anders has
said over the years, and I agree completely with his statement WRT a
standard device enrollment protocol.  What's not to like about
preferring crypto over passwords, or algorithm agility:

> However, there's no need for third-party certificates like
> the presentation suggests. A SHA1 of the device certificate

The DoD's Non-Person Entity PKI is responsible for device enrollment.
We want a secure, flexible, and standard method of provisioning device
certificates.  A device-embedded keypair could certainly be the basis
for the device unique identifier to be included in PKI-issued device
certificates, and would be registered in the device inventory database
in addition to unique-by-assertion identifiers such as nameplate S/N or
electronic serial numbers (e.g., IMEI).  Any measures that increase the
difficulty of device cloning, either at time of manufacture or
afterwards, are of interest, regardless of the source of the ideas or
whether they are presented in the form of an I-D.

And although I enjoy a good flame war as much as the next guy, IETF
working group lists are not the proper venue.  Let's try to set a better
example here.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Thursday, March 31, 2011 7:20 AM
To: Stephen Kent; Anders Rundgren
Cc: [email-masked]
Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment
protocols

I agree with Steve.

Since a few years back, I started deleting all messages from Anders and
responses to it.

I opened this one for two reasons: It was from Steve and I am getting
old and had senior moment of not being able to relate the subject line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Thursday, March 31, 2011 4:59 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment
protocols

Anders,

I think we are all aware of your focus re PKI, but PKIX deals with a
broader range of scenarios, which makes consideration of a new,
lightweight
cert management protocol appropriate for the WG.

Steve

---

From: max pritikin <[email-masked]>
Date: Thu, 31 Mar 2011 12:19:19 -0700

On Mar 30, 2011, at 11:14 PM, Anders Rundgren wrote:

> PKCS #10 but on "secure messaging"

You're confusing the format for the certificate request message (a PKCS#10 or a CRMF) with the the transport security. 

An important element of the EST proposal is to move the transport security from the message layer (PKCS#7 or CMS) and instead to use TLS. This is why we decided to call it Enrollment over Secure Transport. TLS is well established as a transport layer security within the broader community. 

When you say "secure messaging" do you mean http://en.wikipedia.org/wiki/Secure_messaging ? Perhaps you have a better reference. I suppose a cipher suite for TLS that supports "Secure Messaging" could be specified --  an advantage of the layered approach in EST is that you could propose such a solution in parallel with EST and, if you get support, it would simply need to be referenced.   

> so this effort will not

The concern is not about building on SCEP (e.g. NOT building some sort of SCEPv2) but rather to understand the success of SCEP and the value of CMC and to use these to inform our technical decisions. Additionally real engineers need to develop code for our protocols so building on tools/formats/mechanisms they already use is beneficial. This could be described as 'using what works' and 'fixing whats broken'. 

> transferred OOB eliminates all crummy password schemes.

Data can always be transferred 'out of band' but that invariably results in solutions that require knowledgable personnel to implement successfully. Specifying how third-party certificates play a role allows us to leverage 'what works' in HTTPS based web commerce in a simple and direct fashion to minimize this pain for those PKI deployments where the clients have a browser certificate store. This isn't always the appropriate method but it is an important one that should be considered for server authentication. It is also very straight forward.

> client's cryptographic capabilities; these MUST be negotiated.

TLS includes negotiation of cipher suites. 

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 01 Apr 2011 08:53:33 +0200

Dear List,

In a serious attempt keeping the discussion at a constructive
level, let me begin by scratching the surface of the enrollment
topic with a rather mundane requirement stated by banks: They
more or less always deploy a PIN to an issued credential.

Maybe the banks and I have difficulties reading RFCs, but none
of us seems to have found any support for PINs in PKIX-related
protocols.  Due to this fact (right or wrong), banks in EU and
Asia yearly spend hundreds of millions of dollars on maintaining
entirely proprietary on-line credential enrollment systems.

There's little point going further down in stack until we have
cleared this hopefully fairly trivial issue.

Anders