Re: [pkix] Initial inquiry: Signed vCards

On Sat, Oct 19, 2013 at 5:53 PM, Sean Turner <[email protected]> wrote:
> On 10/19/13 5:44 PM, DataPacRat wrote:
>> On Sat, Oct 19, 2013 at 5:19 PM, Sean Turner <[email protected]> wrote:
>>> On 9/10/13 7:45 AM, DataPacRat wrote:

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

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.)


>>> 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.
>
> 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
> directory.

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.)


>>> 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/
>>
>> Have you gotten any support for that draft since it was last revised?
>
> It's been a while since I checked :)

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


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."
_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime