[Pki-devel] replication of new/modified profiles

[Endi Sukma Dewata]

On 7/2/2014 12:17 PM, Ade Lee wrote:
> The problem with the above proposal is one of migration.  Customers are
> used to both creating new profiles and modifying existing profiles to
> suit their needs.  If we go along with this mechanism, we would have to
> tell these customers that they would need to rename their existing
> customized profiles (and update all the relevant clients etc.)

Just to clarify, so there are 3 proposals:
1. Stacked profiles (Fraser's proposal)
2. Pure LDAP profiles (Ade's proposal)
3. Separate file/LDAP profiles (my proposal)

As discussed over IRC, proposal #3 will be supplemented with a mechanism 
to allow creating aliases for backward compatibility. I'm trying to 
generalize the mechanism to become "profile inheritance".

Basically each LDAP profile will have an optional parent. The parent can 
be the file-based system/default profile, or another LDAP profile. A 
sub-profile will inherit all attributes, except when it's explicitly 
declared in the sub-profile. This mechanism allows us to create just a 
proxy/alias, a full clone, or anything in between. For example, a proxy 
profile might only have a few attributes:

  dn: cn=caAdminCert,ou=Profiles,ou=CA,{suffix}
  objectClass: certProfile
  cn: caAdminCert
  parent: defaultAdminCert
  visible: true

Let's say in the old system we have an unchanged caAdminCert and a 
customized caUserCert. With proposal #1 we'll have:
1. caAdminCert (file)
2. caUserCert (LDAP)
3. caUserCert (file, inaccessible via REST due to the LDAP entry)

With proposal #2 we'll have:
1. caAdminCert (LDAP)
2. caUserCert (LDAP)
3. caAdminCert (file, for initial installation only)
4. caUserCert (file, for initial installation only)

With proposal #3 we'll have:
1. caAdminCert -> defaultAdminCert (proxy)
2. caUserCert (LDAP)
3. defaultAdminCert (file)
4. defaultUserCert (file)

The benefits of proposal #3 are:

1. The system/default profiles will be stored in /usr/share/pki. People 
will be naturally discouraged to change them since it will be 
overwritten during RPM upgrade. On the other hand, an LDAP profile, 
although we can flag it as system profile or make it read-only, is more 
tempting to change.

2. The original/unchanged system profiles will be accessible via REST as 
well so people can use it directly and rely on auto update.

3. Backward compatibility can be maintained with proxy profiles. These 
profiles will be updated automatically during RPM upgrade since it's 
pointing to the file-based system profiles. No need to write upgrade 
scripts.

4. The proxy profiles can be used to hide certain system profiles 
without creating a full clone. With stacking, to hide caAdminCert we 
probably would have to create a full clone then change the visibility, 
and lose the auto update ability.

5. The mechanism can be used to extend/change the behavior of the 
default profiles without having to create the full custom profile. For 
example we want to create IPA-specific caUserCert with different inputs. 
In this case we'll be able to just create a sub-profile with the new 
inputs. No need to clone the entire profile.

> There is another problem, and that is that it is not clear that we want
> updates to the default profiles to be propagated to existing instances.
> I have looked at the profiles and there have been only a handful of
> changes over the last 7 years.  Those changes include things like
> updating the default signing algorithms or the default validity.  More
> likely than not, admins would prefer that we not change the behavior of
> profiles in existing instances underneath them.
>
> The changes that I have found are all behavioral - and therefore things
> that admin can opt out of -- or would prefer to do on their own
> schedule.  There have been no structural changes.
>
> If there are structural changes, then we need to (and can) provide an
> upgrade script which would run with the automatic upgrade.  An example
> of this would be a schema upgrade as we sort out how to represent
> profiles in LDAP.

As discussed, we're separating database changes into:
1. structural changes (e.g. schema change, adding/removing attributes)
2. behavioral changes (e.g. changing SHA1 to SHA512, default validity)

The structural changes will be semi-automatic. The admin decides when to 
run them, but it's not necessary to review them one-by-one. The 
behavioral changes should be reviewed by a security expert to make sure 
that it won't affect their particular system negatively.

With proposal #3 the admin can decide whether to (a) trust us 
(developers) to make the behavioral changes automatically by using the 
default profiles directly or using proxy profiles, or (b) maintain a 
full control of all behavioral changes using custom profiles. If all 
profiles are in LDAP they might be limited to option (b) because the 
upgrade script won't be able to tell whether the current value is a 
default value that we can change, or it was intentionally set by the admin.

-- 
Endi S. Dewata