max pritikin | 2 Nov 2010 22:02
Picon
Favicon

Re: Certificate enrollment at Beijing IETF?


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:

> 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  
(Continue reading)

Anders Rundgren | 3 Nov 2010 16:21
Picon

Re: Certificate enrollment at Beijing IETF?

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);
(Continue reading)


Gmane