> Am 06.04.2015 um 19:18 schrieb Jim Schaad <[email protected]>: > > > >> -----Original Message----- >> From: dane [mailto:[email protected]] On Behalf Of Paul Wouters >> Sent: Monday, April 06, 2015 9:08 AM >> To: Doug Montgomery >> Cc: [email protected] >> Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey >> >> On Mon, 6 Apr 2015, Doug Montgomery wrote: >> >>> Well, this is SMIME and it uses PKIX, so the proper way to express any >>> kind of attributes is via EKU OIDs. >>> >>> Part of the issue here is that we have large enterprise identity >>> management systems that issue credentials for security functions, but >>> independent of application. So while the EKU bits say that a CERT is >>> useful for encryption, it does not say if that is for file encryption, >>> disk encryption, or email encryption. >>> >>> Thus the EKU bits may not be enough to understand if the domain in >>> question supports/allows encrypted email or not. >> >> Do we need the PKIX/SMIME people to write a document to express these? >> This really seems to be in their domain, and using the DNS to work around not >> having the right EKUs seems wrong to me. > > I have been doing my best to ignore this thread, but I guess I cannot any > more. > > Firstly. EKU is not the correct way to deal with what type of key is in a > certificate. EKU is used to say this is an SMIME only certificate (and I > don't believe without looking that this was ever done). Key Usage (KU) is > used to say this is a signing key or this is an encryption key (by > restricting the usages). Yes EKU could say that a certificate is used for a > specific type of encryption, however that should not be an issue here as only > those targeted for S/MIME should be published in the directory. > > NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate has > been issued. This means that there is nothing that can be done to say - Oh, > I have this encryption certificate that is being published but I don't want > you to use it. I want you to use a different one. In this case you just > stop publishing the first certificate - no problems as long as the second is > published at the same time. > > One can continue to publish signing certificates long after one has stopped > using the matching key to perform signature operations. There is more of a > problem with a validator that cannot deal with the fact that you have the > same public key in two certificates, however good practice says that an EE > should not do this. > > There is nothing that the PKIX/SMIME people should need to write to deal with > any of these issues.
For S/MIME (SMIMEA), if you publish your S/MIME DER cert in DNS (1 0 0 or 3 0 0), I think you must check for keyUsage to make sure that the certificate was issued for this use case. You will have to check this on encryption software (not sure for signing software). It doesn’t matter, if the certificate was already issued and the user can not change things anymore, but the software that retrieves a certificate from DNS still can validate (and in my opinion MUST validate) certain things. Not only keyUsage, also not before and not after date validity). So every software MUST do sanity checks. Sorry, if I should have misunderstood you :-) Christian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
