[caops-wg] Re: ca signing policy file
David Chadwick
d.w.chadwick at kent.ac.uk
Mon Oct 10 11:32:52 CDT 2005
Von Welch wrote:
>
> David,
>
> I think I see what you're getting at, but before we could add
> something like this we need to get our own story straight re
> subjectAltName.
>
> I think we're all assuming a subjectName and DN. What should the right
> behavior of software be that is responsible for enforcing name
> constraints when it encounters something else?
Von
name constraints are meant to constrain names. i.e. if your certs are
not within this permitted domain, then they are untrustworthy. Thus if
you encounter a cert with an alternative name and no name in the trusted
domain, then it should be rejected out of hand. It does not fall within
the scope of your constrained names
regards
David
I'm not sure if it
> should ignore or error out off hand.
>
> Von
>
>
> On Oct 10, 2005, at 4:55 AM, David Chadwick wrote:
>
>> Von
>>
>> thats a nice summary of why you have put name constraints outside of
>> the certificates. I might add another reason for keeping it this way,
>> and that is that RFC 3280 allows the CA in the trusted domain, to
>> blow the trust bestowed in it and issue certificates with a different
>> name form and then the certificate will be trusted (e.g. give an
>> email address to someone using the subjectAltName extension, instead
>> of a DN, because their DN is outside the name constraints).
>>
>> regards
>>
>> David
>>
>> Von Welch wrote:
>>
>>> Here's a first attempt at explaining the relationship to Name
>>> Constraints - Von
>>> Comparison to RFC 3280 Name Constraints
>>> To understand our motivation for the creation of this specification
>>> instead of using Name Constraints as defined in RFC 3280 (section
>>> 4.2.1.11), one needs to understand the differences in models
>>> between what PKIX envisions and what is in use in the Grid.
>>> The PKI model envisioned in RFC 3820 is that each relying party
>>> will be part of a domain which has a CA associated with it. Any
>>> decision by that domain to trust another domain, and its associated
>>> CA, is instantiated by the CA of the trusting domain to cross sign
>>> the CA of the trusted domain, creating a new certificate for the
>>> trusted CA which will be used in the trusting domain. Trust can
>>> then be limited by using the Name Constraints extension in this new
>>> certificate, limiting trust by relying parties in the trusting
>>> domain and allowing the trusting domain to manage its view of the
>>> global namespace and ensure uniqueness of names.
>>> In the Grid model, relying parties make trust decisions directly by
>>> installing the self-issued certificates from CAs in their system
>>> configurations. There is often not a domain CA which can sign the
>>> trusted CA and there are issues with current open source path
>>> validation software which also make this approach problematic [1].
>>> The result of this is the need for mechanism for a relying party to
>>> specify their own policy on constraining what names they will allow
>>> a trusted CA to issue, which in turn allows them to manage their
>>> view of the global namespace in order to ensure names are unique.
>>> This specification is aimed at such a mechanism.
>>> [1] J. Jokl, J. Basney, and M. Humphrey. Experiences using Bridge
>>> CAs for Grids. Proceedings of the UK Workshop on Grid Security
>>> Experiences. Oxford 8th and 9th July 2004.
>>> http://www.cs.virginia.edu/~humphrey/papers/
>>> BridgeCAGridSecWorkshop2004.pdf
>>> On Oct 7, 2005, at 8:08 AM, David Groep wrote:
>>>
>>>> Hi Von, *,
>>>>
>>>> Von Welch wrote:
>>>>
>>>>
>>>>> First a meta question - shall we move conversation to the caops
>>>>> email list?
>>>>>
>>>>>
>>>>
>>>> Yes, done, and set the reply-to address there as well.
>>>>
>>>>
>>>>
>>>>> Onto the document:
>>>>> I find the language in the document is really odd in that it
>>>>> talks about "Authentication Identifiers" and "Issuers".
>>>>> Particularly if this document is going to end up in CAOPS, shall
>>>>> we not just bite the X509 bullet and say "X509 certificates" and
>>>>> "CAs", etc. I think it would make the document much more clear.
>>>>>
>>>>>
>>>>
>>>> I actually agree (it's just the habit that crept in here). I also
>>>> think that the "namespace constraints policy collection (file)" should
>>>> just be "namespace constraints file" or something similar.
>>>>
>>>>
>>>>
>>>>> I think one question the document should address is why not use
>>>>> RFC 3280 Name Constraints? I think this mainly boils down to the
>>>>> fact that while they look suitable, they are intended for
>>>>> bridging situations and we'll never get commercial CAs to adopt
>>>>> them, hence always limiting ourselves to "Grid CAs". If everyone
>>>>> agrees with that statement, I'll plan on contributing some prose.
>>>>>
>>>>>
>>>>
>>>> I've a few other reasons to add to this as well:
>>>> For nameConstraints in the certificate itself is that it's the "wrong"
>>>> authority makiong the assertion. For these namespace policies,
>>>> it's not the
>>>> CA itself but rather the distributor or federation that makes the
>>>> claim.
>>>>
>>>> The example again is SwissSign. In the federation, their
>>>> (top-level) CA is limited to signing only the "Bronze" CA. This
>>>> constraint is coded in the namespace constraints file. But of course,
>>>> they'll never but in a nameConstraints assertion in their top-level
>>>> limiting it to Bronze only :-)
>>>>
>>>> Also, only a subset of the certificates issued by a CA may be
>>>> part of the federation, and limiting the namespace is a relatively
>>>> straightforward way of doing that (instead of having to introduce
>>>> a subordinate CA for that).
>>>>
>>>> In all cases, the namespace constraints should be outside of the
>>>> certificate chain of the constraint CA.
>>>>
>>>>
>>>>
>>>>
>>>>> With regards to the example policy, I think the question needs to
>>>>> be asked - why not use XACML or some other standard policy
>>>>> language? I suspect its an attempt to address requirement #5 -
>>>>> human readability. Seems like one could write a tool to display
>>>>> XACML in a context like this nicely, so I think we need to ask
>>>>> ourselves if we really want to define a new language.
>>>>>
>>>>>
>>>>
>>>> The other problem will be on the implementation side. As soon as
>>>> you start using XACML, you will use external parsing libraries and
>>>> thus introduce dependencies on yet more software. A structured
>>>> plain-text
>>>> format that translated almost one-to-one to a evaluation structure
>>>> is easy to process in any language, so I was hoping that more
>>>> software would actually implement it (and maybe even that it
>>>> ultimately could find it's way down in core OpenSSL, some time down
>>>> the road).
>>>> The example language translated 1-to-1 into a list of structures that
>>>> can be parsed top-down without need for any further libraries.
>>>>
>>>> And a tool would again mean coding and maintenance (and a distribution
>>>> problem for the tools), whereas human readable text is self- contained.
>>>>
>>>> But maybe I'm too pessimistic. Can you think of an XACML policy
>>>> whose text representation is still somewhat readable. Can we write
>>>> XACML "assuming we know the context", do away with all the
>>>> embedded schema namespaces, but still make sure that a standard
>>>> XACML parser can read it -- and a human as well?
>>>>
>>>>
>>>> Cheers,
>>>> DavidG.
>>>>
>>>>
>>>>
>>>>> Von
>>>>> On Sep 15, 2005, at 7:57 AM, David Groep wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As Olle pointed out to me over coffee, it might be good to
>>>>>> write down at least the requirements in a real document for
>>>>>> GGF. I've had a go at collecting the information from the email
>>>>>> thread and formatting it as
>>>>>> a GWD. It needs *definitely* work and more text before it could
>>>>>> go public,
>>>>>> but at least we can start hacking at it...
>>>>>>
>>>>>> DavidG.
>>>>>>
>>>>>> Olle Mulmo wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ... did the discussion stop at this point?
>>>>>>> There will be an opportunity to talk face-to-face at GGF15.
>>>>>>> Should we try to nail down and enumerate the requirements of
>>>>>>> what functionality we want until then?
>>>>>>> /Olle
>>>>>>> On Sep 2, 2005, at 08:28, David Groep wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Von,
>>>>>>>>
>>>>>>>> Von Welch wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Do I understand correctly that you are suggesting that a
>>>>>>>>> CA's namespace file can include rules for all of its
>>>>>>>>> subordinates? (These seems to be what your example
>>>>>>>>> implies.) I actually think I like this idea, see next comment.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> That's indeed what I meant. It would enable new subordinates to
>>>>>>>> "glide in" without intervention from the admin, as long as they
>>>>>>>> stay within the namespace assigned for subordinates.
>>>>>>>>
>>>>>>>> I think that need not even be the same namespace as the root,
>>>>>>>> and for this the wildcards should likely work in the
>>>>>>>> issuerName as well.
>>>>>>>>
>>>>>>>> > If a subordinate file exists, it overrides any policy that
>>>>>>>> would be
>>>>>>>> > otherwise inherited.
>>>>>>>>
>>>>>>>> Since you will have to traverse up the tree anyway for
>>>>>>>> validity checks,
>>>>>>>> finding the specialised signing policies should not be much of
>>>>>>>> a problem,
>>>>>>>> but I can't find the use case for it either (at least not yet) :-)
>>>>>>>> Requiring it for root CAs seems like a good thing.
>>>>>>>>
>>>>>>>> DavidG.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * the action to take if no signing policy file is found
>>>>>>>>>> (should you
>>>>>>>>>> allow or deny by default) I think should in general be
>>>>>>>>>> configurable.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe require them for all root CAs and make them optional
>>>>>>>>> for subordinates? Given the root CA namespace config would
>>>>>>>>> cover the subordinates, I can't think of any situation we
>>>>>>>>> would want one for a subordinate.
>>>>>>>>> If a subordinate file exists, it overrides any policy that
>>>>>>>>> would be otherwise inherited.
>>>>>>>>> Von
>>>>>>>>> On Aug 31, 2005, at 11:08 AM, David Groep wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> What I got till now:
>>>>>>>>>> * subordinated should be supported without the need to install
>>>>>>>>>> any data in the trusted directory (this will work once we have
>>>>>>>>>> OCSP support or better, and the new policy format). I
>>>>>>>>>> just completely
>>>>>>>>>> agree here.
>>>>>>>>>>
>>>>>>>>>> The signing policy file should thus be applicable to
>>>>>>>>>> "self" and to any
>>>>>>>>>> subordinates that don't have their own singing policy file.
>>>>>>>>>> (I'd propose semantics that make a specialised signing_policy
>>>>>>>>>> take precedence over any higher-level policy file, so
>>>>>>>>>> that once
>>>>>>>>>> you find one in the CA tree, you don't have to traverse
>>>>>>>>>> further up
>>>>>>>>>> to inspect the policies of the parent CAs. The admin
>>>>>>>>>> supposedly
>>>>>>>>>> is in control of what goes in the trusted directory)
>>>>>>>>>>
>>>>>>>>>> * naming should comply with RFC2235
>>>>>>>>>>
>>>>>>>>>> * format should be easily parseable, and be "logical" for
>>>>>>>>>> both C/ OpenSSL
>>>>>>>>>> and Java implementations.
>>>>>>>>>> This likely precludes the use of c_hash-style CA indexes
>>>>>>>>>> in the
>>>>>>>>>> singing policy file.
>>>>>>>>>>
>>>>>>>>>> * pattern matching:
>>>>>>>>>> Shell-style globs are fine with me as well (I could not
>>>>>>>>>> think of
>>>>>>>>>> any real-life case where a regex could not be replaced by
>>>>>>>>>> a set of
>>>>>>>>>> PERMIT statements and shell globs), but the shell globs
>>>>>>>>>> should expand
>>>>>>>>>> in any position in the DN.
>>>>>>>>>>
>>>>>>>>>> * the action to take if no signing policy file is found
>>>>>>>>>> (should you
>>>>>>>>>> allow or deny by default) I think should in general be
>>>>>>>>>> configurable.
>>>>>>>>>>
>>>>>>>>>> Let's try the SWITCH CA example. They have a fairly complex
>>>>>>>>>> structure
>>>>>>>>>> with a hierarchy 5-levels deep:
>>>>>>>>>>
>>>>>>>>>> SwissSign Root (7b2d086c)
>>>>>>>>>> +- SwissSign Bronze (e36e7a72)
>>>>>>>>>> +- SwissSign Silver (e9d08b40)
>>>>>>>>>> +- SWITCH CA (c4435d12)
>>>>>>>>>> +- ... end-entities
>>>>>>>>>>
>>>>>>>>>> This would lead to a singing policy for the top-level
>>>>>>>>>> SwissSign Root CA, that contains all subordinate CAs down
>>>>>>>>>> to the SWITCH EE- issuing CA.
>>>>>>>>>> To get the signing policy, the algorithm would start at the
>>>>>>>>>> end- entity
>>>>>>>>>> cert, and traverse up the chain until it finds a CA with a
>>>>>>>>>> signing
>>>>>>>>>> policy file. In this case, we could do with a singing
>>>>>>>>>> policy file for
>>>>>>>>>> the root only ("7b2d086c.namespace") that contains the
>>>>>>>>>> limitations
>>>>>>>>>> for all subordinates, like:
>>>>>>>>>>
>>>>>>>>>> #
>>>>>>>>>> # @(#)7b2d086c.namespace
>>>>>>>>>> #
>>>>>>>>>> TO "CN=SwissSign CA (RSA IK May 6 1999
>>>>>>>>>> 18:00:58),O=SwissSign,C=CH" \
>>>>>>>>>> PERMIT \
>>>>>>>>>>
>>>>>>>>>> "C=CH,O=SwissSign,Email=bronze at swisssign.com,CN=SwissSign B
>>>>>>>>>> ronze CA"
>>>>>>>>>> TO
>>>>>>>>>> "C=CH,O=SwissSign,Email=bronze at swisssign.com,CN=SwissSign
>>>>>>>>>> Bronze CA" \
>>>>>>>>>> PERMIT \
>>>>>>>>>>
>>>>>>>>>> "C=CH,O=SwissSign,Email=silver at swisssign.com,CN=SwissSign S
>>>>>>>>>> ilver CA"
>>>>>>>>>> TO
>>>>>>>>>> "C=CH,O=SwissSign,Email=silver at swisssign.com,CN=SwissSign
>>>>>>>>>> Silver CA" \
>>>>>>>>>> PERMIT \
>>>>>>>>>> "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA"
>>>>>>>>>> TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
>>>>>>>>>> DENY \
>>>>>>>>>> "*,O=CERN,C=CH"
>>>>>>>>>> TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
>>>>>>>>>> DENY \
>>>>>>>>>> "*,O=SwissSign,C=CH"
>>>>>>>>>> TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
>>>>>>>>>> PERMIT \
>>>>>>>>>> "*,O=*,C=CH"
>>>>>>>>>>
>>>>>>>>>> (but now of course "*" and "?" should be escaped when the're
>>>>>>>>>> part of the actual RDN).
>>>>>>>>>>
>>>>>>>>>> In the Java world it seems slightly more complex. In the
>>>>>>>>>> CertPath API,
>>>>>>>>>> the TrustAnchor class takes a nameConstraints byte array,
>>>>>>>>>> but the byte
>>>>>>>>>> array must contain an ASN.1 DER encoding of a
>>>>>>>>>> NameConstrains extension
>>>>>>>>>> (as per RFC3280). There is AFAIK no way to express wildcards
>>>>>>>>>> in a
>>>>>>>>>> GeneralName, so I think it will just not be possible to use
>>>>>>>>>> TrustAnchor.nameConstrains to encode this formation.
>>>>>>>>>> Moreover, it
>>>>>>>>>> has no support for subordinated either. Like for C, in Java
>>>>>>>>>> we will
>>>>>>>>>> have to implement it ourselves...
>>>>>>>>>>
>>>>>>>>>> What concerns the matching algorithm: the only advantage
>>>>>>>>>> that formal
>>>>>>>>>> regex's would bring is to combine the two DENY statements
>>>>>>>>>> into one
>>>>>>>>>> DENY "*,O=(CERN|SwissSign),C=CH", and that is no great loss.
>>>>>>>>>>
>>>>>>>>>> DavidG.
>>>>>>>>>>
>>>>>>>>>> Von Welch wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> And one more point that just occurred to me, hierarchical
>>>>>>>>>>> CAs. A definite downside to our current signing policy
>>>>>>>>>>> scheme is that subordinate CAs are required to have a
>>>>>>>>>>> signing policy file, which means that they can't just
>>>>>>>>>>> show up unannounced (which is what people want to have
>>>>>>>>>>> happen, when a subordinate is replaced, just swap it out
>>>>>>>>>>> and go on with life).
>>>>>>>>>>> Von
>>>>>>>>>>> On Aug 31, 2005, at 5:46 AM, Olle Mulmo wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> Revamping this is definitely worth pursuing -- but we
>>>>>>>>>>>> have to think hard to get the design right. Von had
>>>>>>>>>>>> some excellent comments as well:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> This needs better specification, btw, how is whitespace
>>>>>>>>>>>>> handled? I'm not sure I like the use of the formal
>>>>>>>>>>>>> regex as opposed to the unix glob style ('.*' vs '*').
>>>>>>>>>>>>> Do we want to continue using the forward slash style
>>>>>>>>>>>>> vs the more standard comma- separated?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If we are doing something like this, I would suggest that
>>>>>>>>>>>> we try to move towards RFC2253-style DN encoding: It's
>>>>>>>>>>>> the format that almost everything else but openssl
>>>>>>>>>>>> spits out by default nowadays, and it is UTF-8(!!!).
>>>>>>>>>>>>
>>>>>>>>>>>> /Olle
>>>>>>>>>>>>
>>>>>>>>>>>> On Aug 26, 2005, at 23:13, David Groep wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> After a discussion on the CA mailing list, it is quite clear
>>>>>>>>>>>>> that the current way of expressing the namespace
>>>>>>>>>>>>> constraints for
>>>>>>>>>>>>> CAs is quite tedious: the EACLs have a far too
>>>>>>>>>>>>> complicated syntax
>>>>>>>>>>>>> for their simple use in the ca_signing_policy.conf file,
>>>>>>>>>>>>> their
>>>>>>>>>>>>> full syntax does not work, and they are used nowhere else.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, at this time only a few parts of the system
>>>>>>>>>>>>> actually use
>>>>>>>>>>>>> the signing_policy file (only the C-based stuff that still
>>>>>>>>>>>>> calls the "oldgaa" callback), and a lot of implementation in
>>>>>>>>>>>>> other languages and systems is still to be done.
>>>>>>>>>>>>> This is true for the Java part of GT, for the EGEE Java
>>>>>>>>>>>>> stuff,
>>>>>>>>>>>>> and also I'm quite sure that Unicore does not do anything
>>>>>>>>>>>>> in this
>>>>>>>>>>>>> area (Jules, Ron?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> What about changing to a new format for the
>>>>>>>>>>>>> signing_policy before
>>>>>>>>>>>>> we start all that work, a format like a simple set of
>>>>>>>>>>>>> ordered lines
>>>>>>>>>>>>> with an action and a regular expression. Like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> # namespace constraint file
>>>>>>>>>>>>> #
>>>>>>>>>>>>> PERMIT /DC=org/DC=mydomain/.*
>>>>>>>>>>>>> PERMIT /DC=org/DC=alsomine/.*
>>>>>>>>>>>>> DENY /DC=org/DC=friend/OU=hisdept/.*
>>>>>>>>>>>>> PERMIT /DC=org/DC=friend/.* # my friend
>>>>>>>>>>>>> delegated rest to me
>>>>>>>>>>>>> #
>>>>>>>>>>>>>
>>>>>>>>>>>>> which would be almost trivial to parse in any language.
>>>>>>>>>>>>> I suggest
>>>>>>>>>>>>> adding the "DENY" because that would solve by problem
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> SWITCH CA (they own all of "/C=CH/*", except for "/ C=CH/
>>>>>>>>>>>>> O=CERN/*",
>>>>>>>>>>>>> so a ordered list with DENY prevents enumeration of all the
>>>>>>>>>>>>> possible "O="'s there).
>>>>>>>>>>>>> But if you don't like the deny we can even go to just a plain
>>>>>>>>>>>>> list of regex's.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of cource, we should distributed the "EACL" style policy
>>>>>>>>>>>>> files
>>>>>>>>>>>>> still for a long time, but eventually they would go away.
>>>>>>>>>>>>> For the standard CA distribution I can easily add the new
>>>>>>>>>>>>> format.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would this be useful and possible to do in a reasonable time?
>>>>>>>>>>>>> Is it possible to put this as a feature request on the
>>>>>>>>>>>>> current GT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> DavidG.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>
>>>>
>>>> --
>>>> David Groep
>>>>
>>>> ** National Institute for Nuclear and High Energy Physics, PDP/
>>>> Grid group **
>>>> ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB
>>>> Amsterdam NL **
>>>>
>>>>
>>>>
>>
>> --
>>
>> *****************************************************************
>> David W. Chadwick, BSc PhD
>> Professor of Information Systems Security
>> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>> Tel: +44 1227 82 3221
>> Fax +44 1227 762 811
>> Mobile: +44 77 96 44 7184
>> Email: D.W.Chadwick at kent.ac.uk
>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>> Research Web site: http://sec.cs.kent.ac.uk
>> Entrust key validation string: MLJ9-DU5T-HV8J
>> PGP Key ID is 0xBC238DE5
>>
>> *****************************************************************
>>
>>
>
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
More information about the caops-wg
mailing list