Re: [xmpp] draft-hildebrand-dna-00

[Dirk Balfanz <balfanz at google.com>]

Hi guys,

I wanted to give some feedback on draft-hildebrand-dna-00. I just joined the mailing list, so I probably missed a bunch of the discussion regarding this topic. I'm new to XMPP, but have been helping out the Wave folks at Google with some crypto/PKI bits.

My biggest question is why you're tangling up this spec with Attribute Certificates. I've never seen an RFC 3281-style AC in the wild, and hadn't heard of draft-ietf-pkix-3281update until I read this spec. Is 3281update real? Are there parsers out there that understand this stuff? It makes sense to stand on the shoulders, so to speak, of other specs if there is wide-spread adoption out there and code that can process these things, but you don't want to depend on specs that nobody is using - it just complicates things. 

Ok, now for more detailed, turn-by-turn comments:

- it says "The issuer's certificate MUST NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE." Why?

- The holder field MUST be the baseCertificateID. This seems to mean that it points to a issuer/serial number in some other PKC. Hows does the validating entity get hold of that PKC? How did the issuer of the AC know what to put there?

- http://www.ietf.org/id/draft-ietf-pkix-3281update-05.txt says  "Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options [wherever the spec asks for a GeneralName]"  Your spec says to use registeredId, so you seem to be advocating a non-3281update-compliant AC.

- For encoding the AC, issuer cert and potential intermediate certs, you're depending on yet another RFC (http://tools.ietf.org/html/draft-ietf-smime-3851bis-11) for encoding the cert chain, which seems like overkill. Why not just say that proof-type attribute-cert has sub-elements, like 

   <proof xmlns='urn:ietf:params:xml:ns:dna'

          from='asserted.tld'

          type='urn:ietf:params:dna:proof:attribute-cert'>

     <ac>

       (base64 of AC)

     </ac>

     <pkc>

       (base64 of issuer PKC)

     </pkc>

     <pkc>

       (base64 of intermediate PKC that issued issuer PKC)

     </pkc>

   </proof>

What do you guys think? You probably discussed all these things to death and i'm just late to the party...

Dirk.