[Pki-devel] lightweight sub-CAs; updated design
Christina Fu
cfu at redhat.com
Fri Oct 31 00:26:37 UTC 2014
I'm sorry I intended to get back to this earlier but got caught up.
Thanks to Ade for his relentless nagging...he did a wonderful job on that.
I had an irc session with Ade earlier today and got a better grasp of
the context of what you are trying to solve here which I did not have a
clear picture of before.
Please see my response in-line below.
Christina
On 10/21/2014 10:06 PM, Ade Lee wrote:
> On Tue, 2014-10-21 at 16:49 -0700, Christina Fu wrote:
>> The following response is only for soft tokens for obvious reasons I
>> stated earlier.
>>
>> First of all, it is okay to make exceptions for the duration of
>> installation. This is to give people a choice of doing things in
>> secured/isolated environment for installation purpose. So, yes, it is
>> much better than having a design where sensitive data is placed and kept
>> on ldap in normal operation.
>>
>> Here I'm just throwing out some questions/ideas for you to think about.
>>
>> About transmission of keys. A couple questions for Ade's design in the
>> email thread:
>> a. If you split the key (or generate 1/2 a key separately...same thing)
>> and use the exact same key to wrap the shares then I am not sure I see
>> the benefit (apology if I am not reading it right... I'm spread very
>> thin at this point). I will talk about key splitting in the later part
>> of this email...
>> b. I might have missed something, but if you take the effort to manually
>> transport the p12 of subsystem keys/certs, why not do the CA as well?
> What you are missing, Christina, is that this operation can be done
> during normal operation.
>
> The feature that is being developed here is a lightweight subCA. This
> is a subCA that exists in the same webapp as a "primary" CA, and that
> will be subordinate to it. It will share config files, profiles, logs,
> audit signing, server and subsystem certs and certdb. It will have
> different signing and ocsp signing certs - which will be stored in the
> certdb. It will also share the same DB instance, although likely under
> some different DNs.
Just throwing out ideas...you probably want to have a separate acls and
admin/agent pool. Maybe one combined one for inter-subsystem purpose.
> The subCA will probably be created through a REST API call, likely
> invoked through the pki CLI tool (as an enterprise admin). There may be
> many subCAs, but they will all be created after the primary CA is
> operational.
>
> I could imagine the following flow:
> 1. Admin installs primary CA (CA0)
> 2. Admin uses CLI to install subCA1 in CA0.
> 3. Admin clones CA0 to CA1. Any system certs in the certdb are
> transported using the p12 mechanism - including the subsystem cert and
> the signing certs for CA0 and subCA1. The result is a clone that
> contains a clone of CA0 and subCA1.
> 4. Admin uses CLI to install subCA2 on CA0.
> 5. At this point, the clone CA1 detects that a new subCA has been
> created (through watching LDAP modifications) and needs to automatically
> make any required configuration changes and get the new signing keys for
> subCA2.
>
> The key point is that operation (5) needs to be done automatically with
> no operator intervention. That means that there are no credentials to
> get an installation token from the security domain.
ok, I see. That's the part I missed earlier.
> But because we are in a working clone, we already have the credentials
> we need. Both clones already have the same subsystem cert/keys - and
> this should be true only for clones. We can therefore use the subsystem
> cert to both authenticate and wrap the subCA2 signing private key for
> transport.
>
> Now, as I recall, you can't wrap an asymmetric key (the signing private
> key) with another asymmetric key (the subsystem public key) directly, so
> you need to do it using a symmetric key.
>
> The mechanism I proposed is very similar to the mechanism used to set up
> SSL, and the splitting of transport key is crucial to prevent forgery.
>
> Let me propose a similar but slightly more complicated mechanism using
> passphrases. This mechanism is probably more similar to SSL setup, and
> is more secure because parts of the transport key are not sent over.
>
> 1. clone generates half of a passphrase and wraps that with the
> subsystem public key.
>
> 2. master generates the other half of the passphrase, combines the two
> and derives a symmetric key. The master sends back
> a) the other half of the passphrase wrapped with the subsystem public
> key
> b) the subCA signing private key wrapped with the symmetric key.
>
> 3. clone decrypts the other half of the passphrase, combines its half
> with the master half and derives the same symmetric key. Then uses the
> symmetric key to unwrap the subCA signing private key.
I still don't see much benefit for the splitting as you are using the
exact same certs on both ends for encryption. Please be reminded that
with SSL, two ends have to establish a shared secret because they did
not have one to begin with, unlike your cloning environment here.
What you need is a different transport cert/keys ( see below) for
wrapping the generated session ( symmetric) key used to wrap the signing
keys.
>
>> Also, why do you need to manually transport the p12 of the subsystem
>> keys/certs? Each clone could very well get a different "transport" cert
>> (maybe double as ssl client cert -- what we call the subsystem cert)
>> from the orig CA to kickstart. They can just generate CSR locally, send
>> request, and get issuance, and then publish their public key then they
>> can start wrapping and transmitting secrets with each other, isn't it?
>> To save time, I'm leaving out details such as initial authentication
>> (the current token/session key mechanism should do) in the discussion.
>> Also, these transport certs need to belong to a special "agent" group or
>> some privileged group on the CA to be allowed to get wrapped keys,etc.
>> So, potentially it can go like (I'm only roughly laying this out...you
>> need to fill in the detail for design):
>> 1. a clone is created, talks to orig CA to get started (session key, etc).
>> 2. clone generates csr for transport certs. sends csr to orig CA to approve
>> 3. orig CA authenticated the above request, and issues the cert, sends
>> the cert back to clone; meanwhile, orig CA keeps record of these
>> transport certs for later look up (maybe using session keys as look up
>> keys).
>> 4. clone sends orig CA request to retrieve CA signing key
>> 5. orig CA looks up and finds the clone's transport cert, generates a
>> cryptographically equal or better strength'd session (sym) key to wrap
>> it's own priv key, wrap the sym key with the transport public key (and
>> maybe a few other things), then sends them back to the requesting clone.
>> (that means the transport certs need to be of same or higher strength)
>> 6. clone unwraps the session (sym) key, unwraps the Ca priv key and
>> injects into its own soft token.
>>
> I wrote all of the above and then reread this -- and I really like this
> mechanism. This will allow us to avoid the whole p12 creation and
> transport business altogether.
glad you like it. I am sure back when we designed cloning, we did the
p12 thing out of convenience of not having to generate more certs/keys
than necessity.
Anyway, I think for establishing transport certs, this is good. Since
subsystem certs are already established at this point, it should remain
the ssl client auth cert for inter-subsystem communication.
Note that the mechanism I described results in different transport
certs/keys for each clone. That's what we want. (see below re
authorization)
> What you described here will work for setting up the clone initially.
> In that case, the authentication will be via login to a security domain
> and obtaining an installation token. We need to decide however, whether
> the installation token is sufficient protection for this operation.
>
> We will need another type of authentication for a subCA being created
> post-install ie. scenario (5) I mentioned above. This could be the
> subsystem cert which would need to point to a user on the master CA -
> that would be set up when the clone is initially set up.
yes, in general, I agree that if the subsystem certs/keys are in place,
those instances possessing them are considered rightful clones. I think
it's a good idea to limit them to what they are intended for : ssl
client authentication.
For transport certs, I think once established, those transport
certs/keys I described above can continue to be used for any further key
transport in new lightweight CA creations.
As for authentication/authorization, lets first take an inventory of
what we know:
* we have the Security Domain CA which has info on all the subsystems,
including clones out there
* we have cloned instances out there sharing the same subsystem certs
* when a cloned instance is created, we expect ALL clones to be equal...
i.e. anyone could become a "master" as soon as a new lightweight CA is
created within that clone instance
* when a new lightweight CA is created within one existing clone, it
becomes the "master" per previous point, and it is at the moment the
only instance that has possession of the CA signing keys. And our goal
is to have the right clones have them too.
So, the authentication is taken cared of by the shared subsystem (SSL
client) certs among all clones.
That left authorization. Do we want to blanketly allow every subsystem
that owns the subsystem cert/keys to get the new subCA's signing keys?
That's probably the right assumption. And since as you pointed out,
those subsystem certs already belong to the right agent group, that
takes care of authorization. I am suggesting that we create a separate
"agent" group for the clones.
The (fairly rough) steps may go like this:
* A subCA is created on CA0
* CA1 and CA2 realized it, each sends CA0 a "get new subCA signing
cert/keys" request, maybe along with each of their transport cert.
* CA0 (after ssl auth) do the "agent" authz check
* once auth/authz passed, CA0 generates a session key, use it to wrap
its priv key, and wrap the session key with the corresponding transport
cert in the request , Send them along with CA0's signing cert back to
the caller in response. (see additional layers of security measurement
below)
* CA1 and CA2 each receives its respective wrapped session key and the
wrapped Ca signing key and the CA cert, do the unwrapping onto the token,etc
We also want to make sure the transport certs passed in by the caller
are valid ones.
One way to do it is to have Security Domain come into play. The SD is
supposed to have knowledge of all the subsystems within its domain.
Could we add something in there to track which ones are clones of one
another? Could we maybe also "register" each clone's transport certs
there as well. If we have such info at hand from the SD, then the
"master of the moment" could look up and verify the cert.
Also, one extra step that can be taken is to generate a nonce encrypted
with the transport cert and receive it back encrypted with the "master
of the moment"s own transport cert to ensure that the caller indeed has
the transport cert/keys.
Fraser, I know that Ade and I have been throwing out whatever ideas are
on top of our heads at the moment when we responded (at least I am) I'm
sure there may exist some other variations. My suggestion is that you
start to clean up the design page and perhaps list out all different
ideas and we can continue to finalize it.
Hope this helps.
>> Also, remind me again, why do all subsystem certs of the clones have to
>> be the same?
> Its the way things are implemented now. We manually copy over all pk12
> certs (except the ssl server cert). Remember also that the subsystem
> cert is issued by the security domain CA.
>
>> About key splitting. The benefit of splitting a key includes
>> 1. takes more effort to crack
>> 2. no single entity (e.g. person) can have access to the whole private
>> key (this is very important to prevent forgery)
>>
>> If key splitting is desired (note: I am not saying I encourage this, as
>> in most cases, this might be a bit much. I am just throwing out info),
>> you might want to consider looking into the following. In fact, RHCS
>> code might still have the Bloom/Shamir m of n secret-sharing code from
>> the older implementation of KRA lying around (not sure if still in
>> current Dogtag source).
>> Of course I'm not sure how much of these is automatable.
>> Also I'm sure the crypto used in the old code could use some update
>> (code is at least 17 years old)... but the logic is there.
>> Oh, and there was also a RecoverPinKey tool that can be converted to use
>> on the clone side to do reconstruction.
>>
>> Finally, one word of caution, please make sure the wrapping key is at
>> least as strong cryptographically as the CA private key.
>>
>> hope I wasn't verging on rambling...
>> Christina
>>
>> On 10/20/2014 06:28 AM, Ade Lee wrote:
>>> On Mon, 2014-10-20 at 08:01 -0400, Dmitri Pal wrote:
>>>> On 10/20/2014 12:18 AM, Fraser Tweedale wrote:
>>>>> On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote:
>>>>>> sorry I missed a few folks in my reply ...
>>>>>>
>>>>>> On 10/17/2014 10:01 AM, Christina Fu wrote:
>>>>>>> Hi Fraser,
>>>>>>>
>>>>>>> This response is for the "Key generation and storage" part of the design.
>>>>>>>
>>>>>>> First of all, Dogtag does provide symkey retrieval via a JNI package which
>>>>>>> provides interface to NSS called "symkey". There had been talks of
>>>>>>> merging symkey functionalities into JSS (which is also a JNI package that
>>>>>>> provides interface to NSS) in the future.
>>>>>>>
>>>>>>> In fact, for years, Dogtag has been doing what's similar to what Petr^2
>>>>>>> Spacek described with DNSSEC, the wrapping/unwrapping of keys on both NSS
>>>>>>> softtoken as well as supported HSMs for distribution without ever
>>>>>>> disclosing any private keys in memory.
>>>>>>> This is the most basic requirement for Common Criteria for RHCS.
>>>>>>> This is just to assure you that whatever you need, it's most likely
>>>>>>> already there and more.
>>>>>>>
>>>>>>> BTW, I'm not familiar with "SoftHSM". The name itself sounds like an
>>>>>>> oxymoron, but we don't have to get into that ;-).
>>>>>>>
>>>>>>> As far as HSMs go, once keys are generated, you are not going to be able
>>>>>>> to export any private keys out of it unless they are temporary and
>>>>>>> non-sensitive keys, which should not be the case for CA signing keys.
>>>>>>> In practice, since HSMs are expensive, people use net HSM so servers can
>>>>>>> share the same hardware unit as long as they are within the same secured
>>>>>>> network, which means that you don't have to try to distribute the certs
>>>>>>> and keys, as long as you have the right permission/privileges and enough
>>>>>>> info to access such network shared HSM.
>>>>>>> In cases when sharing of an HSM is not possible, HSM vendors provide
>>>>>>> assistance to "copy" keys from one HSM to another. When our customers run
>>>>>>> into that, we ask our customers to contact their vendor(s).
>>>>>>> In some situations, process can be taken to generate keys on soft token in
>>>>>>> a secure and isolated location and manually import to individual HSMs.
>>>>>>> What you do not want to do, is to put your CA signing keys anywhere other
>>>>>>> than an isolated backup facility or in the token itself, no matter how
>>>>>>> many times you wrap it. Ciphers get cracked every few years, and when
>>>>>>> your CA private keys are compromised, the consequences are insurmountable.
>>>>>>> You might ask, why then KRA keeps the wrapped user private keys on the
>>>>>>> ldap server for archival/recovery? The answer is very simple. Those are
>>>>>>> user keys. It would be bad if they are compromised, but not as bad or
>>>>>>> widespread. Also, those user private keys are wrapped with individual
>>>>>>> session keys (every key is different), unlike what DNSSEC is doing with
>>>>>>> one single "master key", if I read it correctly (I apologize I did not
>>>>>>> have time to look into DNSSEC at all).
>>>>>>> Anyway, Dogtag has a long history of serving facilities that require high
>>>>>>> security, so that's why it is what it is today.
>>>>>>>
>>>>>>> Hope this helps.
>>>>>>> Christina
>>>>>>>
>>>>>>>
>>>>> Christina, thanks for your detailed reply. OK, so if wrapped
>>>>> private keys in LDAP is unacceptable, what are the other options. I
>>>>> will just enumerate some ideas below; we can start discussion of
>>>>> these alternatives or maybe they will spark other ideas.
>>>>>
>>>>> - Push private keys directly to clones. The database contains the
>>>>> list of clones (cn=<host>,cn=CAList,ou=Security Domain,<basedn>)
>>>>> and their SecureAdminPort. Could we have an API for sending the
>>>>> private keys to each clone, where the keys would only be present
>>>>> on the wire in a secure channel, once for each clone?
>>>>>
>>>>> Drawbacks: additional logic needed to handle situations where a
>>>>> clone is offline at sub-CA creation time.
>>>>>
>>>>> - Pull private keys directly from generating clone to other clones.
>>>>> In a way, this is the dual of the previous suggestion. Clones can
>>>>> notice when a new sub-CA has been created in the database. The
>>>>> entry can contain a reference to the clone that created it, and
>>>>> other clones can contact that clone and request the private key
>>>>> over a secure channel.
>>>>>
>>>>> Drawbacks: additional logic needed to handle situations where the
>>>>> generating clone is offline; additional failure modes (e.g. if no
>>>>> clone with keys is online).
>>>>>
>>>>> - Do not automatically distribute private keys to clones. Focus
>>>>> effort on a good UX for administrators to distribute keys to
>>>>> clones.
>>>>>
>>>>> Drawbacks: seems to violate an important requirements - namely,
>>>>> that sub-CAs be ready to use across clones automatically (no
>>>>> administrator action required).
>>>>>
>>>>>
>>>>> I have ignored the HSM dimension above because it seems that
>>>>> customers using HSM are in one of two situations: 1) customer has a
>>>>> net-HSM used by all clones, so the key distribution problem doesn't
>>>>> exist, or 2) we cannot get the keys out therefore cannot distribute
>>>>> them.
>>>>>
>>>>> I'm not sure where pki-symkey fits into all of this. I had a quick
>>>>> look at the code but couldn't make much sense of it. Where should I
>>>>> look for examples of its intended use and capabilities, or to whom
>>>>> should I talk?
>>>>>
>>>>> Thanks all for your time and ongoing patience as I work out the
>>>>> design for this important feature.
>>> The feature that Christina is probably referring to was a mechanism I
>>> put in place a little while back to distribute a shared symmetric key
>>> from the TKS to the TPS during installation.
>>>
>>> I am also wary about storing wrapped CA signing keys in LDAP. These
>>> aren't just the keys for a user, but rather CA signing keys -- literally
>>> the keys to the kingdom (or at least little fiefdom).
>>>
>>> Now, I still think though that it is possible to possible to transport
>>> the subCA keys between clones safely. Here is one suggestion:
>>>
>>> 1. We create a new service on the CA for the distribution of subCA
>>> signing keys. This service may be disabled by a configuration setting
>>> on the CA. Whether it should be disabled by default is open to debate.
>>>
>>> 2. SubCA detects (through ldap) that a subCA has been added. It sends a
>>> request for the CA signing key, including the identifier for the subCA
>>> and half of a session key (wrapped with the subsystem public key).
>>> Recall that the subsystem key is shared between clones and is the key
>>> used to inter-communicate between dogtag subsystems.
>>>
>>> 3. The service on the master CA generates the other half of a session
>>> key and wraps that with the subsystem public key. It also sends back
>>> the subCA signing key wrapped with the complete session key.
>>>
>>> There are lots of variations of the above, but they all rely on the fact
>>> that the master and clones share the same subsystem cert - which was
>>> originally transported to the clone manually via p12 file.
>>>
>>> The subsystem certificate is stored in the same cert DB as the signing
>>> cert, so if it is compromised, most likely the CA signing cert is
>>> compromised too.
>>>
>>>> I think the best would be to have manual distribution of the keys
>>>> assumed by default but have a way for admin to specify that he is OK
>>>> with replicating keys via LDAP in a wrapped blob.
>>>> Not all environments are the same. In many cases wrapped keys in LDAP
>>>> would be good enough but in some they would not so to fail safe the
>>>> manual option should be default.
>>>>
>>> Given that these are CA signing keys - even if the subdomain is smaller
>>> - I'd rather err on the side of caution and use a mechanism similar to
>>> the above.
>>>
>>>> 2c.
>>>>
>>>>> Fraser
>>>>>
>>>>>
>>>>>>> On 10/16/2014 12:05 AM, Fraser Tweedale wrote:
>>>>>>>> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote:
>>>>>>>>> On 15.10.2014 14:48, Simo Sorce wrote:
>>>>>>>>>> On Wed, 15 Oct 2014 17:48:35 +1000
>>>>>>>>>> Fraser Tweedale<ftweedal at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote:
>>>>>>>>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote:
>>>>>>>>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote:
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just landed a big update to the lightweight sub-CAs design
>>>>>>>>>>>>>> proposal:http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I plan to start the implementing next week. Aside from general
>>>>>>>>>>>>>> design review, specific things I need input on are:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How to propagate newly-generated sub-CA private keys to clones
>>>>>>>>>>>>>> in an automated way, and how to store them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll comment about that in the IPA thread. I had thought that the
>>>>>>>>>>>>> keys etc. would reside in the primary CA certdb.
>>>>>>>>>>>>>
>>>>>>>>>>>> Actually, I'll respond here because the IPA thread has moved
>>>>>>>>>>>> slightly away from this. In the IPA thread, there is discussion of
>>>>>>>>>>>> storing the keys in ldap encrypted by some master key - which
>>>>>>>>>>>> presumably would be stored in the certdb.
>>>>>>>>>>>>
>>>>>>>>>>>> Decrypting the signing key and keeping it in memory is absolutely a
>>>>>>>>>>>> no-no. The CA signing key material should only be present in the
>>>>>>>>>>>> HSM/softoken - and should never be exposed unencryted outside the
>>>>>>>>>>>> token. All crypto operations must be done there. That most likely
>>>>>>>>>>>> means storing the data in the NSS certdb.
>>>>>>>>>>>>
>>>>>>>>>>> The design of key distribution could follow the DNSSEC design; see
>>>>>>>>>>> Petr Spacek's comments in this thread:
>>>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html
>>>>>>>>>>>
>>>>>>>>>>> Presumably this design for key distribution has received some
>>>>>>>>>>> thorough attention. Perhaps some of the assumption for DNSSEC do
>>>>>>>>>>> not hold for Dogtag. I have copied Petr and Simo for their input.
>>>>>>>>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a
>>>>>>>>>> hw HSM too), and keys are handed within it only.
>>>>>>>>> We are finishing DNSSEC right so I don't have time to study sub-CA
>>>>>>>>> design
>>>>>>>>> right now. For this reason I'm replying only with general statements:
>>>>>>>>>
>>>>>>>>> - SoftHSM can be used as generic purpose token with PKCS#11 interface.
>>>>>>>>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation
>>>>>>>>> so
>>>>>>>>> data can be separated as necessary: Each "slot" stores data in separate
>>>>>>>>> directory (with potentially different filesystem permissions, PINs
>>>>>>>>> etc.)
>>>>>>>>> - Upstream is responsive and accepts patches with new features (i.e.
>>>>>>>>> unimplemented pieces of PKCS#11 standard) without problems.
>>>>>>>>> - SoftHSM v2 code could use some cleanup but it has clear design and
>>>>>>>>> structure and I don't see extensibility problems.
>>>>>>>>> - Storage & crypto backends have clearly defined API so it should be
>>>>>>>>> possible to implement own back-ends (LDAP & NSS, if necessary).
>>>>>>>>>
>>>>>>>>> Generally I don't see a reason why it couldn't not be used for as key
>>>>>>>>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or
>>>>>>>>> even
>>>>>>>>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem).
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Petr^2 Spacek
>>>>>>>> Thanks Simo and Petr for your input.
>>>>>>>>
>>>>>>>> After some more investigation it looks like all the crypto in
>>>>>>>> Dogtag, including for KRA etc, is performed within the
>>>>>>>> ``CryptoManager`` facility. With that in mind, I've got a more
>>>>>>>> concrete implementation proposal that also uses ``CryptoManager``.
>>>>>>>> If it proves insufficient I will embark on a more detailed analysis
>>>>>>>> of feasibility/implications of bringing SoftHSM as a Dogtag
>>>>>>>> dependency (and remain open to other key distribution ideas).
>>>>>>>>
>>>>>>>> One difference between the DNSSEC/SoftHSM design is that the master
>>>>>>>> key has to be unwrapped each time a sub-CA key needs to be
>>>>>>>> installed. This was because I couldn't see a way to store and
>>>>>>>> retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If
>>>>>>>> there's a way to do this and I've just overlooked it, let me know.
>>>>>>>> But I don't think the security of the scheme is impacted ; it just
>>>>>>>> means that there's a bit of repeated work when we import sub-CA keys
>>>>>>> >from the database.
>>>>>>>> Direct link to key distribution implementation detail in the design
>>>>>>>> proposal:
>>>>>>>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based_implementation
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Fraser
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pki-devel mailing list
>>>>>>>> Pki-devel at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>> _______________________________________________
>>>>>>> Pki-devel mailing list
>>>>>>> Pki-devel at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>> _______________________________________________
>>>>>> Pki-devel mailing list
>>>>>> Pki-devel at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>> _______________________________________________
>>>>> Pki-devel mailing list
>>>>> Pki-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
More information about the Pki-devel
mailing list