headers
Anders Rundgren | 1 Apr 2011 08:53
Picon

PIN support in PKIX enrollment protocols

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
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 9 comments |
headers
Suomela Tero | 1 Apr 2011 10:20
Picon

Re: IETF 80: The future of PKIX certificate enrollment protocols

> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of max pritikin

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

> 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. 

How does this really differ from CMP then? It has the same PKCS#10 and CRMF
formats and can as well be used over TLS. I suppose the EST would be simpler,
but are there any real conceptual differences? Why choose this instead of CMP?

- Tero
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 42 comments |
headers
Stephen Kent | 1 Apr 2011 10:36
Picon

Re: PIN support in PKIX enrollment protocols

At 8:53 AM +0200 4/1/11, Anders Rundgren wrote:
>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.

what does the phrase "deploy a PIN to an issued credential" mean.
Do you mean a CA sends a PIN to a user, along with a cert issued to that user,
in a sort of unilateral cert issuance model? or, do you mean
requiring a user to send a PIN to a CA (a shared secret between the 
CA and the user) as part of a user requesting a cert?

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 6 comments |
headers
Tomas Gustavsson | 1 Apr 2011 11:35
Picon

Re: IETF 80: The future of PKIX certificate enrollment protocols

On 04/01/2011 10:20 AM, Suomela Tero wrote:
>> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of max pritikin
> 
>>> http://www.ietf.org/proceedings/80/slides/pkix-3.pdf
> 
>> 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. 
> 
> How does this really differ from CMP then? It has the same PKCS#10 and CRMF
> formats and can as well be used over TLS. I suppose the EST would be simpler,
> but are there any real conceptual differences? Why choose this instead of CMP?

Because the packaging around CMP is complex with lots and lots of
options. Creating the PKCS#10 or CRMF are the easy parts, the tricky
part with CMP comes after. Just passing them through TLS is trivial.

Cheers,
Tomas
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 38 comments |
headers
Peter Gutmann | 1 Apr 2011 12:09
Picon
Picon
Picon
Favicon

Re: IETF 80: The future of PKIX certificate enrollment protocols

Tomas Gustavsson <tomasg <at> primekey.se> writes:

>Because the packaging around CMP is complex with lots and lots of options.
>Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP
>comes after. Just passing them through TLS is trivial.

You're being polite :-).  A more succint way of putting it would be "Almost
anything is less painful than trying to work with CMP".  This is (presumably)
one reason why SCEP, which is rather a kludge, remains so popular.

Peter.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 37 comments |
headers
Tomas Gustavsson | 1 Apr 2011 17:05
Picon

Re: IETF 80: The future of PKIX certificate enrollment protocols

On 04/01/2011 12:09 PM, Peter Gutmann wrote:
> Tomas Gustavsson <tomasg <at> primekey.se> writes:
> 
>> Because the packaging around CMP is complex with lots and lots of options.
>> Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP
>> comes after. Just passing them through TLS is trivial.
> 
> You're being polite :-).  A more succint way of putting it would be "Almost
> anything is less painful than trying to work with CMP".  This is (presumably)
> one reason why SCEP, which is rather a kludge, remains so popular.

Succinct is a new work in my dictionary, thanks :-)

Agree on SCEP, I though it horrid when I first implemented it, but now
it kind of does the job, easier to grasp than CMP.

I'd say CMP almost works with the 1 or 2 options that are actually in
the wild. Stripping the standard leaving only the few options actually
used would make it almost usable. The ones I've seen are enrollment,
revocation (and possibly keyrecovery) using PasswordBaseHMAC
authentication and enrollment (includes renewal) using digital signature
authentication.
Always exciting when you encounter a new CMP client and have to make
some small adjustments :-)

Cheers,
Tomas
_______________________________________________
pkix mailing list
pkix <at> ietf.org
(Continue reading)

Permalink | Reply | 36 comments |
headers
max pritikin | 2 Apr 2011 00:50
Picon
Favicon

Re: IETF 80: The future of PKIX certificate enrollment protocols


I agree with these comments. 

A sufficiently restricted profile of CMP would be an improvement regarding interoperability but would
still be significantly more complex than simply depending on TLS as a secure transport.

- max

On Apr 1, 2011, at 9:05 AM, Tomas Gustavsson wrote:

> On 04/01/2011 12:09 PM, Peter Gutmann wrote:
>> Tomas Gustavsson <tomasg <at> primekey.se> writes:
>> 
>>> Because the packaging around CMP is complex with lots and lots of options.
>>> Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP
>>> comes after. Just passing them through TLS is trivial.
>> 
>> You're being polite :-).  A more succint way of putting it would be "Almost
>> anything is less painful than trying to work with CMP".  This is (presumably)
>> one reason why SCEP, which is rather a kludge, remains so popular.
> 
> Succinct is a new work in my dictionary, thanks :-)
> 
> Agree on SCEP, I though it horrid when I first implemented it, but now
> it kind of does the job, easier to grasp than CMP.
> 
> I'd say CMP almost works with the 1 or 2 options that are actually in
> the wild. Stripping the standard leaving only the few options actually
> used would make it almost usable. The ones I've seen are enrollment,
> revocation (and possibly keyrecovery) using PasswordBaseHMAC
(Continue reading)

Permalink | Reply | 34 comments |
headers
Peter Gutmann | 2 Apr 2011 04:12
Picon
Picon
Picon
Favicon

Re: IETF 80: The future of PKIX certificate enrollment protocols

Tomas Gustavsson <tomasg <at> primekey.se> writes:

>I'd say CMP almost works with the 1 or 2 options that are actually in the
>wild. Stripping the standard leaving only the few options actually used would
>make it almost usable. 

I've actually tried this in the past, during the 2000/2001 (non-)interop (I
still have to notes somewhere, from late 2000).  The problem is that once you
remove the options that are unnecessary, the options that are incomprehensible
(there were things in there that even the RFC authors couldn't explain when
asked), and the options that no-one can agree on, what's left is something
that isn't anything like CMP any more.  For example many of the
unnecessary/incomprehensible options are mandatory, so you have to invent non-
values to put in there to fill them up, and conversely some of the optional
options, if they're not present, will cause things to break... actually I've
said all this before:

http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf

So to "fix" CMP you end up re-doing it into something that isn't CMP any more.
Every now and then I look at my code and think "yeah, I could probably get
away with that", but then given that it's pretty much dead anyway (there are
what, 3? 4? implementations left) I'm not sure that it's worth the effort.

How much interest would there really be in creating (sigh, yet another) cert
management protocol based on a rewrite of CMP that actually works?  My "let's
actually do it properly" itch would get scratched, but would anyone notice?

Peter.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 2 Apr 2011 10:44
Picon

Re: IETF 80: The future of PKIX certificate enrollment protocols

At 4:50 PM -0600 4/1/11, max pritikin wrote:
>I agree with these comments.
>
>A sufficiently restricted profile of CMP would be an improvement 
>regarding interoperability but would still be significantly more 
>complex than simply depending on TLS as a secure transport.
>
>- max

Max,

As I noted during the PKIX meeting, one concern about relying on TLS is
that most TLS implementations are pretty poor re PKI details. Thus using
TLS as a building block for cert issuance will have to be very 
carefully vetted.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 31 comments |
headers
Anders Rundgren | 2 Apr 2011 11:10
Picon

Re: PIN support in PKIX enrollment protocols

On 2011-04-01 10:36, Stephen Kent wrote:
> At 8:53 AM +0200 4/1/11, Anders Rundgren wrote:
>> 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.
> 
> what does the phrase "deploy a PIN to an issued credential" mean.
> Do you mean a CA sends a PIN to a user, along with a cert issued to that user,
> in a sort of unilateral cert issuance model?

Yes, that's one way banks and governments deal with PIN-codes.
The "unilateral issuance model" as you appropriately called it,
also typically only cares about the public key in a CSR.

> or, do you mean
> requiring a user to send a PIN to a CA (a shared secret between the 
> CA and the user) as part of a user requesting a cert?

No, I didn't mean anything related to the user authenticating to the CA.
Authentication is BTW, not even a part of the proprietary enrollment
protocols referred to since they are without exception browser-based
using all-over-the-map web-methods and procedures for user authentication.

In addition, there's a widely implemented variant of PIN deployment
which is based on the user defining a PIN locally while still
(also locally) enforcing that it adheres to the issuer's policy.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane