> -----Original Message----- > From: Christian Rößner [mailto:[email protected]] > Sent: Monday, April 06, 2015 12:46 PM > To: Jim Schaad > Cc: Paul Wouters; Doug Montgomery; [email protected] > Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey > > > > 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.
Complete and total agreement on this. I was responding to the fact that people seemed to be wanting to change this information to control things when publishing this information in the SMIMEA records. Jim > > Sorry, if I should have misunderstood you :-) > > Christian _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
