[Pki-devel] replication of new/modified profiles

[Christina Fu]

IMHO, I think #3 is way too complicated.  Complication invites issues 
and confuse people.

Could we step back and try something simpler? When you copy the content 
of one profile and modify it to create a new one, then it's a new 
profile standing on its own.  Why the parent-child relationship and 
all?  Seems like an administrator's nightmare. Maybe I missed out on the 
irc discussion, but could you please give us a summary of the benefit 
and how the benefit weights against development time and administration 
maintenance, and support effort in the future on our end?

Anyway, I hope you will consider what I said in my earlier response.  I 
thought our goal was to provide a "centralized collection of profiles" 
to ease administration effort.  I hope we achieve simplicity rather than 
create complication. It's just my personal preference.

thanks,
Christina

On 07/02/2014 02:02 PM, Endi Sukma Dewata wrote:
> 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.
>