ietf-smime
[Top] [All Lists]

Re: [smime] [pkix] Initial inquiry: Signed vCards

2013-10-19 16:19:15
Hi S/MIME-ers,

This draft might be of interest:

https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/

On 9/10/13 7:45 AM, DataPacRat wrote:
On Fri, Jun 28, 2013 at 10:24 PM, Ryan Hurst 
<ryan(_dot_)hurst(_at_)globalsign(_dot_)com> wrote:
From: DataPacRat [mailto:datapacrat(_at_)gmail(_dot_)com]
On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst 
<ryan(_dot_)hurst(_at_)globalsign(_dot_)com>
wrote:
On Jun 28, 2013, at 8:06 PM, DataPacRat <datapacrat(_at_)gmail(_dot_)com> wrote:

Over at vcarddav@ietf, I've started a discussion on extending the
current format to allow for cryptographically signed vCards, to allow
for various forms of distributed, ad-hoc identity authentication.

Would pkix be the appropriate place to discuss the cryptographic and
security aspects of such signed vCards? If not, might I ask for a
recommendation of a better place for such a discussion?

Is there a vCard format in JSON? Have you looked at JWT?

There's a WG which is writing up a spec for jCard, a JSON-based version of
vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm afraid that I
don't know enough about JWT or JSON to say whether or not they would be good
solutions for the problem I'm working on. (Put
simply: allowing easy Bayesian analysis of the trustworthiness of such
cards, so that everybody and their grandmother can serve as ad-hoc
certificate authorities, without relying on any particular third-parties at
any stage.)

I am reasonably sure that an enhanced vCard could do the trick; and there's
at least one proposal on the drawing board which could be implemented with
experimental X-type nametags immediately, without causing any disturbance to
any other vCard-based applications. I don't know whether that particular
approach is the best one - after all, anybody can create a cryptographic
system which is secure from themselves. So I'm hoping to evoke enough
constructive criticism to be reasonably sure that any obvious holes are
plugged from the get-go.

Well for a jCard I would look at JWT.

You should look at www.Persona.org, it is essentially a JSON based PKI based
on JWT; if you were to look at a Persona subscriber certificate you would
see something that very much looks like a vCard (in JSON of course).

I now have an Internet-Draft for the enhanced vCard spec up at
https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/ .
As currently written, it allows vCards to be used not just to announce
one's own keys, but also describe one's trust in other keys, and even
announce revocation of your keys. And all of that is part of the main
goal of the I-D: cryptographically-signed identity assertion. There
isn't much debate going on about the I-D over on the VCARDDAV mailing
list, so it seems worthwhile to check in here at PKIX to see if
anybody might care to offer constructive criticism.


So: how can I make current draft better?


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

(no hat)

1)

Pet peeve: please don't call the output of an HMAC process:

OLD: containing a cryptographic signature of a text
stream consisting of the properties and values listed in HASHLIST.

NEW:

OLD: containing the output of an HMAC algorithm whose input was properties and values listed in HASHLIST and the key in HASHKEY.

2) What happens if I use S/MIME or PGP to sign the message? Can I instead point to the certificate in the SignedData or the appropriate PGP field?

on a side note: Interesting to note that Alexey, Carl, and myself were looking at a way to carry an indication of what algorithms are supported by the clients:
http://datatracker.ietf.org/doc/draft-turner-vcard-smimecaps/

spt

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime