Related draft is draft-paajarvi-xml-spki-cert-00.txt, based on SPKI theory (RFC 2693)
Motivation (the problem): ASN.1 certificate encoding. It is an unnecessary burden on developers. Is there something more efficient and cost effective? Yes. XML
Certificates: Standard for, signed documents, that state something in a secure way. Certificates are signed by someone trusted. There are two types of certificates – Name and Authorization certificates. The first one identifies the person whereas the second specifies what authorizations the person holds. Two types of formats for certificates – X.509 and SPKI. Why SPKI? Native support for authorization. Simple. Trust model.
Fields of SPKI: Issuer. Subject. Tag - permissions granted from the owner (subject) of the certificate. Delegation - a flag indicating, if the owner can pass the permissions. Validity.
Example: Authorization Chain. Diagram
Pääjärvi briefing consisted of the following slides:
<Cert>
version
Issuer
Subject
delegation?
tag
validity?
Comments?
</Cert>XML is standard and widely used encoding format also suitable for certificates. XML-Signatures enables the use of XML for certificates. XML encoded certificates are fast to implement: just combine crypto library, XML processor, XML-Signature processor.
What is the XML Security Suite.
XML Signature Implementation
Element-wise Encryption: A library to encrypt/decrypt any element in XML documents. Requirements (same as before). Current version only does secret-key; now we are developing asymmetric; using PKCS#7 for RSA Encryption; Base64.
ASN1/XML Translator. ASN.1 is widely used: SNMP, LDAP, X.509, PKCS. Our goal: make ASN.1 data suitable for Web. Some efforts have already started, XML Signature, Directory Service Markup Language.
We provide a general translator: ASN1 Syntax –> DTD. BER-encoded data – > XML document (SAX based API)
Next Steps: XML-Signature Implementation, compliant with Candidate Rec. Element-wise Encryption, we hope XML encryption will be a new work item. ASN.1/XML Translator, translation into XML schema.
Dean Povey: In your first ideogram you showed translation to ASN.1, but you have it going both ways
Answer: of course you can go to XML
Q: but some information is lost – say you have a context-specific tag, I didn't see any way to represent that; is there something you have to account for in the DTD
Answer: I agree that some information is lost in converting from ASN.1 to DTD; Q: this is good, but the ability to keep that information is important . . .
Q: but, what I would like to see is the converting the XML representation to BER . . . because then we have interoperability, but if you can't do it both ways, then it is not as helpful; you would like to retain some of the in format
Joseph Reagle: This (XML Certificates) is not a charter activity; just want to stress this; but, this is relevant; having two different syntaxes is a disservice; not good for anyone; we can create a different workgroup with a different charter.
-----------------------------------------------------------------
[Correction/supplment]
Although XML and ASN.1 are both grammer-based meta-language frameworks for tree-structured data, their expressive power is not exactly the same each other (unfortunately, none is a proper subset of the other). Our translator is designed such that no information is lost when translating any ASN.1 data into an XML document. Information such as data types and context tags is preserved as attribute values that are specified as defaults in the DTD.
In particular, if the original ASN.1 data is encoded in DER, it is guaranteed that translating the ASN.1 data to XML and then back to ASN.1, exactly the same bit string is recovered. This is a desired property for dealing with digital signatures defined on ASN.1 encoding. Please refer to our white paper in XSS4J for more detailed explanation:
http://www.alphaworks.ibm.com/tech/xmlsecuritysuite -------------------------------------------------------------------
Interoperability Test Cases: Part of our charter is to come up with scenarios; this is very important; we need to have test cases; look at the scenarios document and think about interoperability test cases; John Boyer is the author of the scenarios/FAQ document, that can be a first step.
There are generally three requirements to moving forward:
a web/email interface that can run on top of an implemenation (e.g., Simon's example interface)
Quite a few good internationalization comments from the W3C I18N group (Martin Durst). There is a last call document that tracks the issues. In it there is a matrix that has a link and a summary, the owner of the idea and a Resolution.
Joseph: I'm going to run through some of the issues, I'll skip the small ones and briefly review the bigger issues.
Joseph: Trivial: IDREF: need further last call comments; URI spec has some ambiguity; comments that this is not the best way go; moved to URI . . . we needed to get IDREF out
Joseph: XML-Schema WG: says our schema looks good, but need to update it to the latest version (which I've already done) that changed type to SimpleType and ComplexType. I'm really interested in feedback on whether people are bothering with validating there XML. Would have been good to put in the requirements document whether we expect DTD will be present; this affects some of the discussion about validation and Xpath. Eastlake: draft has a section which explains the syntax contraints you need to follow so that presence of the DTD at the receiver is not important.
Joseph: White Space . . . straight-forward
Joseph: KeyInfo raised by Karl Wallace. Presently we have a mandatory KeyValue nested within an optional KeyInfo. Key information may be know in application context, so does not need to be know in the XML-Signature; why do I have to use this key value; some alternatives on how to resolve this; this should go to the list, a hairy topic, Donald did you want to say anything on this; does anyone want to speak to this?
on point 2/3 . . . there are at least 4 places where you can get the MIME type; which reference is the normative; at some places we say at the lower level; now we say the signature is the normative value; this is kinda confusing; Joseph: think we should rely on the HTTP; should say which one take priority in your application;
Donald: several different factors:
There was a proposal to take data typing information from HTTP headers when you are dereferencing location; the transform might change the data and the type; the type information would be passed along in parallel with the data; people thought this was too complicated. Alternatively (presently) the specification says that you go to location and get the data; if the application needs type information, then mime type and char set are input as attributes; so the application needs to know something from somewhere else. Even so, there could be some problems here: you could have some other property, like language, which is important and not currently provided for; if this is XML, then the char type is embedded in the XML. Should this override or should the outside representation? And RFC 2369 says if there is an external label, then the external should override the internal; the internal should only be used for error recovery.
Joseph: John Boyer has been working on the Xpath specification part of our spec. The reason we want to do Xpath is to satisfy two requirements:
Joseph: We have been saying Xpath is the way to do it; we have gotten some comments; we need some implementation.
Joseph: Kent also said . . .minimal C14N should be abandoned. There are two philosophies (1) do this simple; look at XML as characters where you don't bother with entities and such, or (2) other way: want this to be XML, so would include entities.
Joseph: We have gone both ways ("sitting on the fence", so you can do min C14N and you can do full C14N.
Joseph: Kent commented, however, the he is going to do all this with full; the min requires a lot of hacks; not worth it to him.
Joseph: People seem to be moving toward full C14N. SLT: will not go into this.
Joseph: Retrieval Method: need further specification of what you are expecting to get and how to get it.
What we need is not "minimal C14N" but "lightweight C14N"
Problems: No C14N is available that would not require a DTD or a Schema. Can C14N even single elements (not only complete documents).
There are cases where you do not have a DTD or a Schema or where the document is not a full XML-Document; would like to see lightweight C14N that would allow us to do these things.
Suggestions (outdated somewhat). Convert to UTF-8. Normalize consecutive white spaces to a single whitespace. Remove all spaces between consecutive tabs. Leading and trailing white spaces must be removed, if an element contains character data.
Question: Valicert: what do I need to know about the document and its transforms when I get it?
Joseph: some people have said I won't trust any document that has been transformed, that is a valid trust decision for them to make.
Donald: There is no guarantee that any particular verifier can understand the transforms since you could have user defined transforms, depends on what you want to check.
Joseph: Well, you could say, that's not really useful; we have been saying, trust is not our issue; we are leaving that up to the application
April 20th in Victoria; Teleconferences every two weeks on Thursdays at 1:00 EST; consensus that we not have any teleconference between now and face-to-face.