On Thu, Jul 02, 2015 at 11:02:17AM +0200, Carsten Strotmann wrote:
> Would it be possible to at least update the SMIME draft with the latest
> changes on OPENPGPKEY, and get a DNS type code for SMIMEA records from
> IANA, before sending the draft to sleep?
I don't think that's a good plan. Once the email localpart to DNS
owner fqdn prefix mapping is decided, there really not much more
to do for SMIMEA.
* Possibly separate owner fqdn for signature-only keys vs
encryption keys:
_sign._mumble.example.com IN SMIMEA U S M <hash>
_encrypt._mumble.example.com IN SMIMEA U S M <key>
This really should be signalled in-band in the certificate,
but if conceding on this gets the draft over the line, I
would be willing to accept the compromise.
* Observe that encryption keys (if published and whether the
labels for encryption are separate or not) need to have matching
type Full(0) if encryption is to be possible with the SMIMEA
record in hand. So typically the matching type would be
Full(0). However, using a different matching type supports
(for better or worse) a model where encryption is not possible
on first contact. Encrypted mail would be possible only
after the recipient replies with encryption capable keys in
the signature of the reply message.
* I am not inclined to budge on any attempts to build explicit
"revocation" into the draft, as with TLSA, revocation needs
to be via "de-publication", rather than publication of a
"revocation" record. The draft should explain the lifecycle
model in more detail.
+ New mail only passes SMIME signature validity with a key
whose trust is based on a DANE SMIMEA record, only if
that record is (still) present at the time the mail is
received. De-publishing an SMIMEA record immediately
(modulo DNS and RRSIG TTLS, ...) deauthorizes the key
for signing.
+ Already received mail is tagged as validated by the
MUA at the time the signature is first processed. Thus
years or decades old mail does not become inauthentic,
just because the signing key used then has since expired.
+ Encryption of new mail requires keys (still) valid for
use at the time the mail is sent. A matching type other
than Full(0) requires prior possession of the keys, which
can be determined still valid via the published digest.
+ When using DANE-TA(2) or PKIX-TA(0) records, and an
individual user's keys need to be "revoked", the user's
SMIMEA record can be changed to DANE-EE(3) or PKIX-EE(3)
matching a new key/certificate until the compromised
certificate expires. Once the compromised certificate
expires, the user can be switched back to the organization-wide
SMIMEA trust-anchor record.
+ When using DANE-EE(3) or PKIX-EE(1) records, to "revoke"
just publish a new SMIMEA association.
If "revocation" and owner-label format can be settled, we should
be able to settle any remaining issues.
So for me, the main obstacle is still the owner-label, which is
the same for both OPENPGP and SMIMEA.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
