Subject: [perpass] PKCS#12 needs fix'n

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Oct 2013 17:20:18 -0400

Looking at some comments from Peter Guttman from way back he reports having
a large collection of PKCS#12 files with private keys and no password.

Ooops

So I am wondering if this might be one of the holes being exploited? It
would be consistent with a lot of what we have heard.

There seem to be several issues

1) Chronic usability issues on Windows re PFX PKCS#12 which leads users to
export without a password

2) Weak cipher suites. The strongest seems to be 3DES, I suspect the
default is RC4 which is one of the ciphers I trust least right now.

The ciphersuites issue seems to be a real problem. PKCS#12 does not use
standard identifiers so a new one has to be cut each time and because it is
a low priority it tends to lag. It is also unnecessarily captive to the
legacy base.

There is a draft to update PKCS#12 and to put it under IETF control. I
think it needs to be given a higher priority (the draft has expired BTW).

It could also do to have some examples. I am finding the draft very opaque
without.

http://tools.ietf.org/html/draft-moriarty-pkcs12v1-1-01

-- 
Website: http://hallambaker.com/

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 10 Oct 2013 17:27:21 -0400

Hello,

I should have a new version of the draft out soon, hopefully before the next meeting.  My working version has incorporated most of the adjustments requested by the sponsoring AD and the document shepherd.  I am just waiting on some language on transferring change control to ensure this is done properly.  We will get this version transferred and then updates can be made in a new document to revise as needed.

It does have a high priority, but we need to do this correctly so that there are no issues with the transfer.  I chose to let it expire rather than provide an update without the right language in the document for the transfer, since this would happen soon.

Thank you,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, October 10, 2013 5:20 PM
To: perpass
Subject: [perpass] PKCS#12 needs fix'n

Looking at some comments from Peter Guttman from way back he reports having a large collection of PKCS#12 files with private keys and no password.

Ooops

So I am wondering if this might be one of the holes being exploited? It would be consistent with a lot of what we have heard.

1) Chronic usability issues on Windows re PFX PKCS#12 which leads users to export without a password

2) Weak cipher suites. The strongest seems to be 3DES, I suspect the default is RC4 which is one of the ciphers I trust least right now.

The ciphersuites issue seems to be a real problem. PKCS#12 does not use standard identifiers so a new one has to be cut each time and because it is a low priority it tends to lag. It is also unnecessarily captive to the legacy base.

There is a draft to update PKCS#12 and to put it under IETF control. I think it needs to be given a higher priority (the draft has expired BTW).

It could also do to have some examples. I am finding the draft very opaque without.

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Oct 2013 17:41:48 -0400

Kathleen:

Thanks for working to transfer change control to the IETF.  Once this happens, the community can work to resolve any shortcomings in the specification in an open and transparent manner.

Once the specification is done, hopefully all of the implementers will quickly incorporate the improvements.

Russ

On Oct 10, 2013, at 5:27 PM, Moriarty, Kathleen wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Oct 2013 10:56:24 -0400

I would note that the JSON Web Key [1] spec from the JOSE WG provides a
similar, much simpler format than PKCS#12.  Just have JWK Set with one
public, unencrypted member, and one encrypted member:

[
  { "kty": "RSA", "n": "...", "e": "...", "x5c": "..." },
  JWE({ "kty": "RSA", "n": "...", "e": "...", "d": "..." })
]

Since software is going to have to change in any case to use a revised
PKCS#12, I wonder if it might not be a better idea to ditch ASN.1 while
we're at it.

--Richard

On Thu, Oct 10, 2013 at 5:41 PM, Russ Housley <[email-masked]> wrote:

> Kathleen:
>
> Thanks for working to transfer change control to the IETF.  Once this
> happens, the community can work to resolve any shortcomings in the
> specification in an open and transparent manner.
>
> Hello,****
> ** **
> I should have a new version of the draft out soon, hopefully before the
> next meeting.  My working version has incorporated most of the adjustments
> requested by the sponsoring AD and the document shepherd.  I am just
> waiting on some language on transferring change control to ensure this is
> done properly.  We will get this version transferred and then updates can
> be made in a new document to revise as needed.****
> ** **
> It does have a high priority, but we need to do this correctly so that
> there are no issues with the transfer.  I chose to let it expire rather
> than provide an update without the right language in the document for the
> transfer, since this would happen soon.****
> ** **
> Thank you,****
> Kathleen****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Phillip Hallam-Baker
> *Sent:* Thursday, October 10, 2013 5:20 PM
> *To:* perpass
> *Subject:* [perpass] PKCS#12 needs fix'n****
> ** **
> Looking at some comments from Peter Guttman from way back he reports
> having a large collection of PKCS#12 files with private keys and no
> password. ****
> ** **
> Ooops****
> ** **
> would be consistent with a lot of what we have heard.****
> ** **
> There seem to be several issues****
> ** **
> export without a password****
> ** **
> default is RC4 which is one of the ciphers I trust least right now.****
> ** **
> ** **
> legacy base.****
> ** **
> think it needs to be given a higher priority (the draft has expired BTW).*
> ***
> ** **
> without.****
> ** **
> http://tools.ietf.org/html/draft-moriarty-pkcs12v1-1-01****
>
> ****
> ** **
> --
> Website: http://hallambaker.com/****

---

From: Carl Wallace <[email-masked]>
Date: Fri, 11 Oct 2013 14:26:50 -0400

From:  Richard Barnes <[email-masked]>
Date:  Friday, October 11, 2013 10:56 AM
To:  Russ Housley <[email-masked]>
Cc:  perpass <[email-masked]>, "Moriarty, Kathleen"
<[email-masked]>
Subject:  Re: [perpass] PKCS#12 needs fix'n

> similar, much simpler format than PKCS#12.  Just have JWK Set with one public,
> unencrypted member, and one encrypted member:
> 
> [
> PKCS#12, I wonder if it might not be a better idea to ditch ASN.1 while we're
> at it.

I think I see some ASN.1 in your JSON too:-)

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Oct 2013 14:31:08 -0400

On Fri, Oct 11, 2013 at 2:26 PM, Carl Wallace <[email-masked]>wrote:

> Cc: perpass <[email-masked]>, "Moriarty, Kathleen" <
> [email-masked]>

X.509 is one thing.  PKCS#12 is quite another.  Having implemented both (in
JavaScript, no less), I can tell you which one caused less pain and got
more interop.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 14 Oct 2013 22:57:32 -0400

> PKCS#12, I wonder if it might not be a better idea to ditch ASN.1 while

Actually I had pretty much done that before making the post. I am actually
sending PKCS#8 encrypted keys to the cloud.

But there is a value in being able to return a PKCS#12 which is that
several programs and platforms will eat them as input and store the keys in
the desired places. So for that it is a legacy compatibility issue. And so
when I found the PKCS#12 docs to be basically unreadable, I had a problem.

As for getting rid of Assanine 1, I would love to get rid of it completely.
But as a pragmatic matter, there is just too much ASN.1 already. I have
even had to reluctantly write a key signing format in Assanine.1 because
having the cert and key signing in different syntaxes is just too confusing.

---

From: "Paul Bakker" <[email-masked]>
Date: Tue, 15 Oct 2013 11:18:58 +0200

On Oct 15, 2013 Phillip Hallam-Baker wrote:

> As for getting rid of Assanine 1, I would love to get rid of it
completely. But as
> a pragmatic matter, there is just too much ASN.1 already. I have even had
to
> reluctantly write a key signing format in Assanine.1 because having the
cert
> and key signing in different syntaxes is just too confusing.

While I do understand the reluctance for ASN.1, in an embedded environment I
really prefer it over text parsing and buffer duplication that is required
for JSON parsing..

Paul Bakker

---

From: Albert Lunde <[email-masked]>
Date: Tue, 15 Oct 2013 05:16:57 -0500

I'm not sure it directly does anything to improve resistance to 
monitoring or active man-in-the-middle attacks, but it seems like 
security properties of some protocols could be improved by better 
separation of code from data, making data formats that are finite, can 
be validated, and don't embed a Turning-complete programming language 
interpreter.

An implementation that doesn't depend on artifacts from all over the net 
is good too.

A HTTP client that doesn't embed JavaScript or DOM is potentially more 
secure, though more limited in scope. (DNS and TCP can still be attacked.)

Groups like OpenID connect seem to be engaged in reinventing SAML in 
JSON, I'm less concerned about JSON as such, as the likelihood it will 
be run in web browser's JavaScript/DOM environments.

XML is not without warts: external entities and the difficulty of 
validating XML signatures come to mind.

I don't know ASN.1 well enough to comment on its issues...

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Oct 2013 15:01:33 +0200

>be validated, and don't embed a Turning-complete programming language 

That is indeed a popular demand, see <http://langsec.org/occupy>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Oct 2013 09:18:57 -0400

> really prefer it over text parsing and buffer duplication that is required

There are real problems there for embedded apps and for cryptography. But
extending the JSON approach modestly to incorporate fixed length strings
and binary blobs solves 95% of them:

https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/

Having to remember whether an object is implicit or explicit or vague is
just too much hassle.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Oct 2013 10:02:03 +0300

CBOR does this pretty well:
<http://tools.ietf.org/html/draft-bormann-cbor-09>