Subject: [smime] A bit better operational practice?

From: Kohei Kasamatsu <[email-masked]>
Date: Tue, 30 Jul 2013 15:10:33 +0900

Hi, SMIME list

There are many of MUA implementations for S/MIME and some banks or
corporations are using digital signature for their messages.
But in such cases, there are several points would hopefully be care in
technical aspects of S/MIME.

Displaying assurance of organization of signer, keys and certificates
management criteria in MUA and CRL delivery into MUA are crucial
issues to enhace usage or deployment of acutual use of S/MIME.

I would think about drafting a document as follows:
-----
 MUA and for qualified signatures:
  - certificate selection in MUA
  - for unified display (like green bar in browser) of showing
    messages in MUA with valid/non-valid signatures
  - operational pracice for digital signatures
    (e.g. key length, validity, key store)

 Certificates for S/MIME:
  - operational pracice for digital signatures
    (e.g. key length, validity, key store, revocation control)
  - certificate policy or singing policy for signer(S/MIME)
   e.g.) Bank, corporation, goverment and/or for qualified signature

 etc.(other items in my mind)
-----

Are they impossible to be toss as a draft?

If you have had considered such point of operational issues,
I would hope to share and get your reply.
(or talk to me either, in Berlin)
-- 
Kohei Kasamatsu

NTT Software Corporation
TEL: +81 45 212 7908 FAX: +81 45 212 9800
E-mail: [email-masked]

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 30 Jul 2013 08:27:27 +0200

> (or talk to me either, in Berlin)

Personally I consider S/MIME a useless standard, there's to my knowledge no
plans making it better either.

The parameters you mention has no meaning except to crypto-nerds.

I would recommend banks and governments turn to web-based solutions
because they provide an interactive component which among many
things can pre-select the proper certificate.

Here is something I'm working with to make the web an alternative to S/MIME:
http://webpki.org/papers/PKI/pki-webcrypto.pdf

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 30 Jul 2013 12:31:44 +0000

Are you proposing a BCP or a new RFC or bis?  Your list it sounds like a BCP to me.

-- T

________________________________
From: [email-masked] [[email-masked]] on behalf of Kohei Kasamatsu [[email-masked]]
Sent: Tuesday, July 30, 2013 01:10
To: [email-masked]
Subject: [smime] A bit better operational practice?

Hi, SMIME list

 Certificates for S/MIME:

NTT Software Corporation

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

---

From: Kohei Kasamatsu <[email-masked]>
Date: Wed, 31 Jul 2013 23:25:29 +0900

Hi Anders.

Thank you for your comments.

> plans making it better either.
S/MIME is already used by Some banks and corporations and is actually
useful for guaranteeing integlity of their messages.
I would like to contribute to parties who are using or providing S/MIME.

> The parameters you mention has no meaning except to crypto-nerds.
Thank you for the precious opinion.
I also think that too detailed information on parameters of cryptgraphic
primitives does not have no meaning.

However, signature generated by compromised key cannot guarantee
integrity of message.
I think that it is valuable to gather and organize minimum required
information about it.
What do you think about it?

> http://webpki.org/papers/PKI/pki-webcrypto.pdf

Thank you for interesting information.

Best regards,
Kohei

---

From: Kohei Kasamatsu <[email-masked]>
Date: Wed, 31 Jul 2013 23:31:33 +0900

Hi Miller,

Thank you for your email.

I plan to propose a BCP or an informational RFC.
(If possible, proposing a BCP is best as me.)

Best regards,
Kohei