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 protected]> 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.
>
> 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:
>
> 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 protected] [mailto:[email protected]] *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.****
> ** **
> 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/****
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
>
>
>
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
>
>
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to