Re: [pkix] Initial inquiry: Signed vCards

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 <[email protected]> wrote:
>>> From: DataPacRat [mailto:[email protected]]
>>> On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst <[email protected]>
>>> wrote:
>>>> On Jun 28, 2013, at 8:06 PM, DataPacRat <[email protected]> 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

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