On Sat, Oct 19, 2013 at 5:53 PM, Sean Turner <turners(_at_)ieca(_dot_)com>
wrote:
On 10/19/13 5:44 PM, DataPacRat wrote:
On Sat, Oct 19, 2013 at 5:19 PM, Sean Turner <turners(_at_)ieca(_dot_)com>
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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime