> Good point. However, we did not study that yet. I can tell that the
> size varies from about 150 bytes to about 500 bytes. The Policy AC is
> typically around 3K-4K bytes long (because of the XML embedded), but
> it is loaded only once, when the system starts up.
>
> Note also that the ACs can be cached - you don't need to send/retrieve
> them every time. At the other level our API also provides ready-to-use
> credentials (representation internal to the API), which you can cache
> as well, to be able to make a few subsequent calls without invoking
> network operations to retrieve the ACs, and without any cryptography
> as well (ACs are valid for a certain period of time, as specified in
> them). 

The sizes seems quite reasonable to be included in the elements we use,
either by the GET parameters or by SAML queries/responses, as we are defining
for PAPI version 2. I assume that Policy ACs, in a PERMIS-PAPI model, should
be loaded once at the (G)PoAs. The idea of using the API internal
representation can certainly help in saving space/bandwidth.

> We would be happy if you could comment on this, since you have a
> working web-based system with digital signing in place, and perhaps
> you know about others as well. How do they cope with that there could
> be many different PKIs from various vendors? Or do they stick to a
> particular PKI? Do you have an insight into the situation with
> web-based applications?
> . . .
> So in order to make a "spot-on" decision on what kind of PKI extension
> would be of most use to a web-based application with TLS/SSL, we would
> appreciate your advice. What tool set is the common practice, how the
> private keys are stored, differences between Apache and MS-IIS
> web-servers (any other major implementations?) in this sense. I hope
> that since you already have your system running, you might have a
> paper discussing similar issues leading to your choice and solution,
> or may be you know the key sites, or papers with overviews of
> tendencies in this area. Such information would really help us
> understand the needs of web-based applications and develop extensions
> to make integration even easier.

Tha PAPI current version uses cryptographic services in very plain manner.
We store private keys in PEM format for the AS and the (G)PoAs deal with
public keys stored in the same format, located into directories identified
by the configuration. The files containing appropriate public keys are
located by means of their names.

As you can see, this means that there is no actual PKI deplyoment in PAPI,
but only the requirement of an off-line key distribution procedure (basically,
bilateral agreements between an AS and the (G)PoAs it provides access to).
We use the cryptographic API at a very basic level, for key generation,
signature verification and symmetric key en-/de-cryption for the tokens
stored in cookies. We decided to use the crypto libraries of openSSL because
it was open source (a must) and we were familiar with it.

Things are changing, and we are now studying how we can implement trust
relationshipd among PoAs, GPoAs and AS when we allow for dynamic attribute
evaluation at the (G)PoA. This dynamic evaluation means a (G)PoA being
able to ask an AS about certain attributes of the requesting user, so the
AS must identify the (G)PoA and decide whether it is acceptable to answer
its queries.

As I mentioned, we are in the process of deciding whether we are going
to use X.509 certificates or a simpler format for these tasks. In the first
case, we could use standard software and libraries at the cost of using
much longer and more complicated strings (we call this in Spanish "killing
flies with guns"). In the other case, data formats will be simpler (that
probably means more secure) but using it would imply more effort and possibly
problems for evolving the system and making it interoperate. We are in
the process of building prototypes to evaluate it, and we are using again
the OpenSSL libs because we feel comfortable with them. So I'm sorry we
do not have at this moment a well-established corpus on different PKI
implementations.

This said, the idea of using extensions (I'm just thinking in them like some
kind of interfaces together with some factory methods returning actual
implementations - pardon me if this sounds too Java-minded) is really 
appealing to make the system as much open and able to interoperate as we
can.

> Finally, here is the URL for our site, in case you want to study the
> documentation.
>
> http://sec.isi.salford.ac.uk/permis/ 

Thanks a lot,
-- 
"Esta vez no fallaremos, Doctor Infierno"

Diego R. Lopez
[log in para visualizar]

RedIRIS
The Spanish NREN
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------