Subject: Re: [pkix] Certificate enrollment at Beijing IETF?

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Nov 2010 16:21:28 -0400

At
>...
>If I recall correctly, SCEP has been proposed to be advanced as
>standard - I was there at the IETF meeting. And the answer was,
>more or less "No, we already have RFCs that cover the matter, we
>don't want to move SCEP to RFC status - you might want to publish
>it as Informational".
>
>It was a pretty "firm" reply - I guess from Steve - but that was
>shared by the people present. And I thought the discussion about
>SCEP was actually over.

The discussion is supposed to be over.

An agreement was reached (including the PKIX co-chairs, the Security 
ADs, and the IETF chair) well over a year ago. The agreement called 
for the SCEP I-D to be cleaned up and published as Informaitonal and 
Historic. It would contain text that noted the limitations of that 
protocol compared to the PKIX standards (CMC & CMP), and would 
recommend that new implementations of clients and CAs employ these 
standards in the future.

There also were several technical issues with the text in the I-D 
published at that time, e.g., reference to a non-existent attribute 
type in a Subject name, and these needed to be fixed prior to 
publication. Tim Polk agreed to be the shepherding AD.

Unfortunately, the individual who was supposed to make the requisite 
edits seems to have left Cisco.  So, none of what was supposed to 
take place has happened, yet.  I am hopeful that we will be able to 
proceed as planned.

Steve

---

From: max pritikin <[email-masked]>
Date: Tue, 2 Nov 2010 16:02:39 -0500

I've picked up the document and would like to see this issue closed.  
It is unfortunate some context was lost in the transition. The edits  
have been made as best I've been able to verify. Some other edits were  
also made.

I'd like to help us get past the current issues and start work on the  
next.

- max

On Nov 2, 2010, at 3:21 PM, Stephen Kent wrote:

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

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 03 Nov 2010 16:21:53 +0100

max pritikin wrote:
> 
> I've picked up the document and would like to see this issue closed. It 
> is unfortunate some context was lost in the transition. The edits have 
> been made as best I've been able to verify. Some other edits were also 
> made.
> 
> I'd like to help us get past the current issues and start work on the next.

Beware that a next step should probably (if it is going to be "competitive"),
introduce E2ES functionality which means that the final part of a certificate
enrollment process may end-up calling APIs like the following:

////////////////////////////////////////////////////////////
// Assign certificate path to key entry
////////////////////////////////////////////////////////////

     public void setCertificatePath (int key_handle,
                                     X509Certificate[] certificate_path,
                                     byte[] mac) throws Exception
       {
         // Get key and associated open provisioning session

         KeyEntry key_entry = getOpenKey (key_handle);

         // Verify incoming MAC

         MacBuilder verifier = key_entry.owner.getMacBuilderForMethodCall (METHOD_SET_CERTIFICATE_PATH);
         verifier.addArray (key_entry.public_key.getEncoded ());
         verifier.addString (key_entry.id);
         for (X509Certificate certificate : certificate_path)
           {
             verifier.addArray (certificate.getEncoded ());
           }
         key_entry.owner.verifyMac (verifier, mac);'
           .
           .
           .

AFAIK, current PKIX schemes do not deal with container-level sessions and MACs.
Container attestations also make PKIX-style PoP redundant.

Related "standards" such as CertEnroll, <keygen>, generateCRMFRequest () were
all great when Windows 98 were king, but I thought we had passed that stage?

Anders