Guarantees on certificates [Bob Cowles, 2005.01.14] As you recall, there was a long thread last October/November concerning a VOMS userid and whether that was desirable. I recently reviewed that thread and there were some assertions made about "guarantees" and proper procedures that I thought would be good to discuss with the CAs since the relying parties may be expecting more from then than they can deliver. (1) A request for revocation of certificate comes in after the certificate has been renewed. What is the procedure? [The reason for asking is that if I was an attacker and got someone's private key, the first thing I would do is renew the certificate since the new certificate wouldn't be affected if the old one got revoked.] (2) A user claims to have lost old certificate / keys (laptop stolen). Will you re-issue cert with same (old) DN? [This is a perfect social engineering scenario, and a test of how strong a "guarantee" a CA can offer.] (3) It appears that relying parties (and VOs) are treating the guarantees promised by the CA as absolute (in other words they have no defense or recovery mechanism in case of an error) - yet many CAs are only issuing certificates at a minimum trust level. Is there a mismatch in expectations? (4) At one point in the discussion, I thought Sophie made a much stronger statement "user must have only one certificate issued by his CA" than the one Ollie & David disagreed with "a DN must only have one certificate issued by his CA". Do we now have agreement - on both of these issues? What are the revocation policies around having multiple certificates with the same DN (if it is allowed)? (6) If multiple certs with the same DN is allowed, is there a check to ensure that the key pairs are unique for all the certs? (5) If multiple certs with the same DN are allowed, what impact does that have on auditing requirements for determining the original certificate used for authentication. ----------------------------------------------------------------------------- Answer by Mike, 2005.01.15 Bob Cowles sent this to me , so I thought I would try to "answer" based on how I think we are doing this in DOEGrids. >> (1) A request for revocation of certificate comes in after the >> certificate has been renewed. What is the procedure? [The reason for >> asking is that if I was an attacker and got someone's private key, >> the first thing I would do is renew the certificate since the new >> certificate wouldn't be affected if the old one got revoked.] Revoking the older certificate? I think you've answered your question in brackets. No connection would be made. >> (2) A user claims to have lost old certificate / keys (laptop >> stolen). Will you re-issue cert with same (old) DN? [This is a >> perfect social engineering scenario, and a test of how strong a >> "guarantee" a CA can offer.] yes - not sure how often done - some agents may not cooperate by their RA policy Successfully managing this involves persuading an agent to to cooperate, which involves the same steps required for an orginal certificate signing, plus persuading the agent to alter the subject name. The actual risk of this threat must be balanced against the practical side effects (rebuilding accounts in services). We can do this differently, and kill accounts (subject names) where keys are reported lost. People may react badly to this additional inconvenience, but we don't know. This is related to Doug Olson's problem, or at least it is in my interpretation of it, which involves establishing "ownership" of (title to) the subject name. >> (3) It appears that relying parties (and VOs) are treating the >> guarantees promised by the CA as absolute (in other words they have >> no defense or recovery mechanism in case of an error) - yet many CAs >> are only issuing certificates at a minimum trust level. Is there a >> mismatch in expectations? Don't follow -- guarantee what? Defense of what? >> (4) At one point in the discussion, I thought Sophie made a much >> stronger statement "user must have only one certificate issued by >> his CA" than the one Ollie & David disagreed with "a DN must only >> have one certificate issued by his CA". Do we now have agreement - >> on both of these issues? What are the revocation policies around >> having multiple certificates with the same DN (if it is allowed)? See #1. Not only that, there are considerable advantages to having multiple certificates with the the same subject name. (See also the title question above.) In the openssl / globus world, there doesn't appear to be a simply way to transition smoothly between an old and new certificate otherwise. There are also some reasonable scenarios for having multiple certs in place. There are also reasonable scenarios that would allow customers to have multiple cert subject names tied to the same account name, and other permutations. Most of these cases we don't do, but some are interesting. >> (6) If multiple certs with the same DN is allowed, is there a check >> to ensure that the key pairs are unique for all the certs? No >> (5) If multiple certs with the same DN are allowed, what impact does >> that have on auditing requirements for determining the original >> certificate used for authentication. That requirement cannot be met with the current globus distributions, can it? ------------------------------------------------------------------------------ [Bob Cowles, 2005.01.18] >> -----Original Message----- >> From: Mike Helm [mailto:helm@fionn.es.net] >> Sent: Friday, January 14, 2005 10:46 PM >> To: doe-sg-pma@george.lbl.gov >> Cc: dg-eur-ca@services.cnrs.fr; Cowles, Robert D. >> Subject: Re: [doe-sg-pma] Re: CA issues possibly for >> discussion in Marseille >> >> Bob Cowles sent this to me , so I thought I would try >> to "answer" based on how I think we are doing this in >> DOEGrids. >> > >>> > (1) A request for revocation of certificate comes in after the >>> > certificate has been renewed. What is the procedure? [The reason for >>> > asking is that if I was an attacker and got someone's private key, >>> > the first thing I would do is renew the certificate since the new >>> > certificate wouldn't be affected if the old one got revoked.] > >> >> Revoking the older certificate? I think you've answered your question >> in brackets. No connection would be made. Hmmm .. does anyone else see this as a problem? Are there and constraints on when someone renews a certificate (e. g. no more than 30 days prior to expiration) or something like that? >> > >>> > (2) A user claims to have lost old certificate / keys (laptop >>> > stolen). Will you re-issue cert with same (old) DN? [This is a >>> > perfect social engineering scenario, and a test of how strong a >>> > "guarantee" a CA can offer.] > >> >> yes - not sure how often done - some agents may not cooperate >> by their RA policy >> >> Successfully managing this involves persuading an agent to >> to cooperate, which involves the same steps required for an >> orginal certificate signing, plus persuading the agent to alter >> the subject name. The actual risk of this threat must be >> balanced against the practical side effects (rebuilding accounts >> in services). We can do this differently, and kill accounts >> (subject names) where keys are reported lost. People may >> react badly to this additional inconvenience, but we don't >> know. >> >> This is related to Doug Olson's problem, or at least it is >> in my interpretation of it, which involves establishing "ownership" >> of (title to) the subject name. I think this kind of thing also relates to the "trust level" one applies to the certificate. For lower trust levels there may be cases where you would decide for convenience and for higher trust levels you would decide for security. >> > >>> > (3) It appears that relying parties (and VOs) are treating the >>> > guarantees promised by the CA as absolute (in other words they have >>> > no defense or recovery mechanism in case of an error) - yet many CAs >>> > are only issuing certificates at a minimum trust level. Is there a >>> > mismatch in expectations? > >> >> Don't follow -- guarantee what? Defense of what? Guarantee that you won't re-issue a DN to different end-entities. The relying parties are assuming this can NEVER happen so there are no additional checks required at the VO or site level. >> > >>> > (4) At one point in the discussion, I thought Sophie made a much >>> > stronger statement "user must have only one certificate issued by >>> > his CA" than the one Ollie & David disagreed with "a DN must only >>> > have one certificate issued by his CA". Do we now have agreement - >>> > on both of these issues? What are the revocation policies around >>> > having multiple certificates with the same DN (if it is allowed)? > >> >> See #1. Not only that, there are considerable advantages to having >> multiple certificates with the the same subject name. (See also >> the title question above.) >> >> In the openssl / globus world, there doesn't appear to be a simply way >> to transition smoothly between an old and new certificate otherwise. >> There are also some reasonable scenarios for having multiple >> certs in place. There are also reasonable scenarios that would >> allow customers to have multiple cert subject names tied to the same >> account name, and other permutations. Most of these cases we >> don't do, but some are interesting. Yes ... it would appear that users will have multiple valid certificates issued by the same CA for the same DN. AND it appears that they will have multiple valid certificates issued with different DNs ... correct? [This is required now for users in multiple VOs and there will probably be some reason to continue it into the future.] >> > >>> > (6) If multiple certs with the same DN is allowed, is there a check >>> > to ensure that the key pairs are unique for all the certs? > >> >> No This seems like a problem since if one of the certs is compromised, then all are compromised (potentially) but only one cert is revoked. Is this one of those "user responsibility" issues? >> > >>> > (5) If multiple certs with the same DN are allowed, what impact does >>> > that have on auditing requirements for determining the original >>> > certificate used for authentication. > >> >> That requirement cannot be met with the current globus distributions, >> can it? Probably not. It's probably the case that the requirement specified tracing back to the user and not the certificate ... but a copy of the certificate is probably included with the proxy so that signature verification can be performed, right? Bob Cowles ------------------------------------------------------------------------------ [Mike Helm, 2005.01.19] "Cowles, Robert D." writes: >>>> > > the first thing I would do is renew the certificate since the new >>>> > > certificate wouldn't be affected if the old one got revoked.] >> >>> > >>> > Revoking the older certificate? I think you've answered your question >>> > in brackets. No connection would be made. > >> >> Hmmm .. does anyone else see this as a problem? Are there and constraints >> on when someone renews a certificate (e. g. no more than 30 days prior >> to expiration) or something like that? We have 2 kinds of renewal. One recertifies the key. There is a time window around expiration where it is allowed. That's the doegrids renewal interface. One replaces the key pair, and requires authentication by a valid person cert; some of the authenticating cert's fields populate the replacement cert (subject name & subjectaltname). This can be done any time and in any quantity. We could change / limit these rules, to some extent. Should be balanced against legitimate reasons for multiple certs, particularly in an environment of software crypto tokens. That's the replacement interface (was "transition"). >> Guarantee that you won't re-issue a DN to different end-entities. The >> relying parties are assuming this can NEVER happen so there are no >> additional checks required at the VO or site level. Ok >> Yes ... it would appear that users will have multiple valid >> certificates issued by the same CA for the same DN. AND it appears >> that they will have multiple valid certificates issued with different >> DNs ... correct? [This is required now for users in multiple VOs and >> there will probably be some reason to continue it into the future.] yes, tho we have hoped that there won't be too many of the latter case, identity certs from diff't VO's for the same person. >>>> > > (6) If multiple certs with the same DN is allowed, is there a check >>>> > > to ensure that the key pairs are unique for all the certs? >> >>> > >>> > No > >> >> This seems like a problem since if one of the certs is compromised, >> then all are compromised (potentially) but only one cert is revoked. >> Is this one of those "user responsibility" issues? No, I think this _is_ a gap in our service, it was partially addressed in certain configuration steps long ago but not in a form that we could use. We have discussed dealing with this. We 've tried to persuade our CA vendor to help us with this; we will probably have to raise this again. [About traceback - thru Globus mapfiles & subject DN's ] >> Probably not. It's probably the case that the requirement specified >> tracing back to the user and not the certificate ... but a copy of the >> certificate is probably included with the proxy so that signature >> verification can be performed, right? Yes, think that's TLS mechanisms that support this.