headers
Anders Rundgren | 1 Nov 2010 09:04
Picon

Re: SCEP vs CMC vs CMP

Peter,

Everything you and others say looks perfectly OK to me as long as you don't
claim to be targeting mobile phones because the mobile phone market holds
the only truly global smart card scheme in existence and smart card provisioning
is something PKIX has no previous RFC/I-D experience with.

Smart card certificate provisioning 2010 begins with creating a secure session
between the container and the issuer which affects the rest of the messaging.
AFAIK no standard cryptographic API (which you eventually need to hook the
enrollment stuff to), supports secure messaging.

Apple's SCEP solution does [presumably] not target SIMs but that also means that
it is security-wise inferior.  RIM is in fact the only company that has anything
remotely useful in this space.

Anders

Peter Gutmann wrote:
> Stefan Santesson <stefan <at> aaa-sec.com> writes:
> 
>> On the SCEP standardization issue it worries me that we have a widely
>> deployed protocol that has no stable RFC reference. I think we should change
>> that as soon as possible. I know we have said that before (in PKIX meetings)
>> but it seems to not happen. What can we change to make it happen?
> 
> That's my concern as well, possibly the most widely-deployed and used cert-
> provisioning protocol is the one not deemed worthy of an RFC (I don't know
> about CMC use, but CMP is virtually nonexistent).
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Santosh Chokhani | 1 Nov 2010 18:23
Favicon

Re: I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

David,

I remain concerned about the direction this document has taken.

RFC 2560 explicitly mentioned or implied that keys should be used for
matching and not the DN.  The OCSP clients I am familiar except a newly
released client, required designated OCSP responder certificate to be
signed by the same key that certificate in question was signed.

The remedy for name collision in Security Considerations section is not
very useful given that many CAs are cross-certified and you can build a
path from a root to many other CAs and uneven use of name constraints.

The Appendix E has an acceptable set of trust model, but there is no
client side processing requirement that enforces or verifies that the
trust model is adhered to leaving unintentional or intentional name
collision as a problem.

The document should be revised in the following areas.

It should require or strongly recommend use of and check for the key
being the same that signed the certificate in question and OCSP Response
(for integrated) or being the same for signing the OCSP certificate and
certificate in question (for designated).

The locally trusted responder should be based on trusted key and not
just the name,

The security considerations section should describe the limitation of
same trust anchor due to cross certified environments and possible lack
(Continue reading)

Permalink | Reply | 3 comments |
headers
Anders Rundgren | 2 Nov 2010 05:54
Picon

OASIS KMIP. Re: SCEP vs CMC vs CMP

It may also be good to know that OASIS KMIP claims to have
finally solved it all:

http://www.oasis-open.org/committees/kmip/charter.php

Personally, I don't think they haven't even touched the
needs of the mobile phone market :-)

Anders
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Stephen Kent | 2 Nov 2010 21:21
Picon

Re: Certificate enrollment at Beijing IETF?

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

Permalink | Reply | 2 comments |
headers
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)

Permalink | Reply | 1 comment |
headers
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)

Permalink | Reply | 0 comments |
headers
Massimiliano Pala | 3 Nov 2010 17:21
Favicon

Re: Certificate enrollment at Beijing IETF?

Hi Peter, all,

Being an "active" developer and having being around in the PKI world for
a while I share your vision.

I think that the success of SCEP is due to its simplicity in its development:
all the data structures used are easily understood by developers and the
implementation is therefore straightforward.

Anyhow, I do admit that SCEP can not cover all the possible scenarios that
CMP & CMC tried to address.

My proposal, if the WG Chair(s) would consider working on the matter, would
be to:

(1) Analyze what of the CMP & CMC standards we could reasonably save.

(2) Provide a simple (updated version of SCEP) and an advanced (taylored
     vesion of CMP/CMC) enrollment protocols in two new working items. The
     simple protocol (DER message based, no requirements on the transport
     protocol used so that we can have different - also binary and not only
     HTTP - transport protocols used) could be an I-D on standard track and
     the advanced one can be experimental. These two WI will update the
     current RFCs.

(3) If the experimental does not get deployment/implementations in a reasonable
     amount of time, we declare that dead with the idea to periodically raise
     the issue to get a feeling if it is time to start working on that item
     again (Internet Advanced PKI Enrollment Protocol or IAPEP). This draft
     could be more targeted towards special environments like cell-phones,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Andersen | 3 Nov 2010 17:25
Picon

Unclear public-key certificate definition in X.509

I have proposed some modification to a paragraph in X.509 as documented by the attached file.

 

I wonder whether you PKIX guys have comments on this proposal. Any comment will be appreciated.

 

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: era <at> x500.eu

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

Attachment (DR-xx.pdf): application/octet-stream, 22 KiB
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 13 comments |
headers
Stephen Kent | 3 Nov 2010 18:08
Picon

Re: Certificate enrollment at Beijing IETF?

At 5:00 PM +1300 11/3/10, Peter Gutmann wrote:
>Stephen Kent <kent <at> bbn.com> writes:
>
>>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.
>
>So the "solution" is to deprecate the widely-deployed, actively-used protocol
>that "they" developed in favour of the two no-hope launch-failures that "we"
>developed?

A big company (e.g., Cisco, Juniper, MS, Google, ...) may promote and 
publish any protocols that it develops.  Such companies, because of 
their market presence, often can persuade others to adopt their 
protocols, whether good or bad, IETF-endorsed or not. In general, the 
IETF does not rubber-stamp a company-developed, de facto standard 
just because it is popular. We (at least some of us) also do not like 
to publish, even as informational, a document that describes a 
protocol that was developed outside the IETF in direct competition to 
standards that were developed within the IETF. The rationale is that 
it encourages vendors to circumvent the process, and acquire the 
imprimatur of the IETf for their protocols when published as RFCs 
(since the "Informational" label is often ignored).

Since Max is a new editor for the SCEP document, I am not suggesting 
that he is responsible for the current situation. Nonetheless, I 
belive that the agreement reached a couple of years ago should 
prevail.

If PKIX elects to pursue a lighter-weight cert request protocol, or a 
variant of one of our extant standards, we can do so. We would start 
with the development of a requirements document, then allow folks to 
propose solutions relative to those requirements. Then pick a winner 
(if we have multiple solution candidates).  That what we did for SCVP 
(which, after all, is just one letter away from SCEP :-)).

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 3 comments |
headers
Paul Hoffman | 3 Nov 2010 18:50

Re: Certificate enrollment at Beijing IETF?

At 1:08 PM -0400 11/3/10, Stephen Kent wrote:
>At 5:00 PM +1300 11/3/10, Peter Gutmann wrote:
>>Stephen Kent <kent <at> bbn.com> writes:
>>
>>>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.
>>
>>So the "solution" is to deprecate the widely-deployed, actively-used protocol
>>that "they" developed in favour of the two no-hope launch-failures that "we"
>>developed?
>
>A big company (e.g., Cisco, Juniper, MS, Google, ...) may promote and publish any protocols that it
develops.  Such companies, because of their market presence, often can persuade others to adopt their
protocols, whether good or bad, IETF-endorsed or not. In general, the IETF does not rubber-stamp a
company-developed, de facto standard just because it is popular. We (at least some of us) also do not like
to publish, even as informational, a document that describes a protocol that was developed outside the
IETF in direct competition to standards that were developed within the IETF. The rationale is that it
encourages vendors to circumvent the process, and acquire the imprimatur of the IETf for their protocols
when published as RFCs (since the "Informational" label is often ignored).
>
>Since Max is a new editor for the SCEP document, I am not suggesting that he is responsible for the current
situation. Nonetheless, I belive that the agreement reached a couple of years ago should prevail.
>
>If PKIX elects to pursue a lighter-weight cert request protocol, or a variant of one of our extant
standards, we can do so. We would start with the development of a requirements document, then allow folks
to propose solutions relative to those requirements. Then pick a winner (if we have multiple solution
candidates).  That what we did for SCVP (which, after all, is just one letter away from SCEP :-)).

The shorter version of Steve's answer to Peter's question would be "yes".
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |

Gmane