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

From: Sean Turner <[email-masked]>
Date: Sat, 19 Oct 2013 17:19:01 -0400

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

---

From: DataPacRat <[email-masked]>
Date: Sat, 19 Oct 2013 17:44:52 -0400

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

That change is easy enough to make in the next revision of the draft.
(I have another minor change pending, involving mention of calendars
other than Gregorian, which isn't significant enough to warrant its
own revision.) I think that I'll wait for a few days, to see if anyone
offers any further feedback about this detail, before issuing the
correction.

> 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?

I'm afraid that I'm not very familiar with S/MIME yet, such as what
fields are included in such a message. What I can say, at the moment,
is that the proposed HASHKEY field can point to any URI. IIRC, it's
possible to construct a URI which points to a particular email
message, identifying it with its Message-ID; I'd have to read up on
that to see if there's a way to use such URIs to point to a particular
part of a message, such as a header field which includes a key. (If
anyone reading this already knows whether that's possible, that could
save a bit of time.) If that's not feasible, but if the key itself is
stored in the message in the standard format (so that, for example, a
copy of PGP reading the message could extract the key), then simply
pointing to the Message-ID itself may be sufficient.

> looking at a way to carry an indication of what algorithms are supported by
> the clients:

Have you gotten any support for that draft since it was last revised?

Thank you for your time,

---

From: Sean Turner <[email-masked]>
Date: Sat, 19 Oct 2013 17:53:39 -0400

> offers any further feedback about this detail, before issuing the

Note the submission deadline is Monday so if you don't do it Monday you 
won't be able to submit it until Nov 4.

> pointing to the Message-ID itself may be sufficient.

I honestly don't know if a URI can point to a particular place in a 
message, but the certificiate/key needed to verify the message's 
signature is there so it's probably something worth figuring out.

I guess I'd also look at pointing to a certificate that's in an LDAP 
directory.

One question: If the key's not retrievable must we assume that the key 
is no longer considered valid?  Normally, I think this would be okay, 
but with cached web pages isn't there a possibility that somebody could 
get a key that the signer didn't want somebody to use?

> Have you gotten any support for that draft since it was last revised?

It's been a while since I checked :)

spt

---

From: DataPacRat <[email-masked]>
Date: Sat, 19 Oct 2013 18:15:41 -0400

>>> properties

Fair enough. ~24 hours for comments seems a reasonable compromise.

(Even though I'm not attending, I'm still trying to learn how IETF
meetings work in general.)

>>> instead
> I honestly don't know if a URI can point to a particular place in a message,
> but the certificiate/key needed to verify the message's signature is there
> so it's probably something worth figuring out.

RFC 2392 seems to be the relevant resource (
https://tools.ietf.org/html/rfc2392 ), with mid: and cid:. While I'm
looking up S/MIME's format, can you tell me offhand if the encryption
keys you describe are stored in separate parts, as in the examples in
that RFC? If so, then it should be easy to add this to the Signed
vCard as an explicit example.

> I guess I'd also look at pointing to a certificate that's in an LDAP

Since LDAP can be reached with ldap: URIs, there shouldn't be any
problems with that.

> One question: If the key's not retrievable must we assume that the key is no
> longer considered valid?  Normally, I think this would be okay, but with
> cached web pages isn't there a possibility that somebody could get a key
> that the signer didn't want somebody to use?

I believe that it's probably best to leave the results of a key's
failed URL lookup to the application doing the looking up, as any
given app will likely have different security requirements than I
might foresee and try to dictate to. (Note that with the PREF
parameter, it's possible to point to multiple copies of a (hash)key at
different URIs, as well as including it in the signed vCard itself,
for extra redundancy, if desired. I should mention that explicitly.)

> It's been a while since I checked :)

Where would you check for such, if I may ask?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Mon, 21 Oct 2013 12:58:05 -0400

> won't be able to submit it until Nov 4.

I've just submitted the new draft, -03, which, as can be expected, can
be found at https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/
. It includes at least a mention of all the topics discussed in this
thread.

If this draft is brought up by this group at IETF 88, I would love to
know, and to offer any responses I can, before, during, or after.

Thank you for your time,

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Oct 2013 12:57:51 -0700

I may be missing something, but I do not see how using a MAC function is
going to provide any degree of security in this case.

The basic presumption of using a MAC function is that the secret is known
only to two people.  The generator and the consumer.  If it is known to
multiple people, especially if it is advertised in a URL, then a new MAC
value can be created by anybody that can get the secret value and a new
vcard substituted.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DataPacRat
> Sent: Monday, October 21, 2013 9:58 AM
> To: Sean Turner
> Cc: [email-masked]
> Subject: Re: [smime] [pkix] Initial inquiry: Signed vCards
> 
> >> own revision.) I think that I'll wait for a few days, to see if
> >> anyone offers any further feedback about this detail, before issuing
> >> the correction.
> >
> > Note the submission deadline is Monday so if you don't do it Monday
> > you won't be able to submit it until Nov 4.
> 
> I've just submitted the new draft, -03, which, as can be expected, can be
> found at
thread.
> If this draft is brought up by this group at IETF 88, I would love to
know, and
> to offer any responses I can, before, during, or after.
> 
> 
> 
> Thank you for your time,
> --
> DataPacRat
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 16:20:10 -0400

>From Sean Turner's suggestion, I assumed that 'output of a HMAC' was
effectively a synonym for 'the authentication hash generated by the
relevant key's algorithm'. If that's not the case, such as only
applying to email rather than encryption in general, then that change
may need to be changed.

Thank you for your time,

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Oct 2013 15:46:53 -0700

Y = MAC(message, KeySymmetric)

Sig = Sign(message, KeyPrivate)

Both generate an output that can be verified.  In the case of a signature
algorithm, the recipient uses a public key to verify the signature.  In the
case of a MAC algorithm, the recipient uses the same symmetric key for
verification as was used for creation.

Jim

> Sent: Tuesday, October 22, 2013 1:20 PM
> To: Jim Schaad
> Cc: [email-masked]
> > I may be missing something, but I do not see how using a MAC function
> > is going to provide any degree of security in this case.
> >
> > The basic presumption of using a MAC function is that the secret is
> > known only to two people.  The generator and the consumer.  If it is
> > known to multiple people, especially if it is advertised in a URL,
> > then a new MAC value can be created by anybody that can get the secret
> > value and a new vcard substituted.
> 
relevant
> key's algorithm'. If that's not the case, such as only applying to email
rather
> than encryption in general, then that change may need to be changed.
> 
> 
> Thank you for your time,
> --
> DataPacRat

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 19:01:16 -0400

> verification as was used for creation.

The Signed vCard format is agnostic about what sorts of keys should be
used for generating the HASH value - private, public, or symmetric
keys are all permitted. It seems like a bit of rephrasing of the
Description in section 4.4 of the draft is in order, in order to make
that clear.

Are there any keywords which are clearly neutral about types of keys
and hashes, which would be worth including?

Thank you for your time,