As I understand it, the idea behind draft-hildebrand-dna-00 is that DNA would be extensible, so that the parties could support a number of different proof types. Attribute certificates (ACs) would be one proof type, but not the only one. I agree that ACs are a bit experimental, because they have never been widely deployed (there are implementations in code, but few deployments that I know of). Other possible DNA proof types might include a signed SRV record (DNSSEC), a special file uploaded to the SSL- or TLS-protected document root for the domain in question, and others we haven't considered yet. Suggestions are welcome. On 11/21/09 8:57 PM, Bernard Aboba wrote: > I share these concerns. Attribute certificates are very rarely > implemented, and as a result if DNA is required for server-server this > is likely to break interoperability with many existing server > implementations. > > Given the lack of implementation experience, any DNA documents should be > Experimental at best. > > On Wed, Oct 28, 2009 at 11:11 AM, Sean Turner <turners at ieca.com > <mailto:turners at ieca.com>> wrote: > > Dirk Balfanz wrote: > > 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. > > > The discussion on the list has actually been pretty minimal. > Technically, it's not even a working group document. > > > 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. > > > I'm not sure what you mean by real? That ID fixes some errata and > some minor bugs, so it's not a big update. It's in the RFC editor's > queue. The document it was pinned on just got approved. It ought to > be published soon. > > There are some code bits from bouncy castle, though I have to admit > I haven't used them. I'm sure there are others. > > > 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 statement is for compliance with RFC 3281/3281bis section 4.5. > It says: "The AC issuer's PKC MUST conform to [PKIXPROF], and the > keyUsage extension in the PKC MUST NOT explicitly indicate that the > AC issuer's public key cannot be used to validate a digital > signature. In order to avoid confusion regarding serial numbers and > revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, > an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST > NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE." > > > - 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? > > > The AC issuer will include their name in the issuer field (taken > from their PKC's subject field) and the issuer's serial # (taken > from their PKC's serial number field). Then the path for the AC > would be included along with the AC (see Section 5.5). I proposed a > "certs-only" message. It would include one attribute certificate > and any public key certificates necessary to validate them. > "certs-only" message have been around a while and are most recently > documented in draft-ietf-smime-3851bis-11. > > > - 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. > > > That's my bad. We wouldn't want to be non-compliant. Joe suggested > just using OIDs for id-xmpp and another one for > id-xmpp-client/id-xmpp-server so I stuck it in there. If we can't > use registerdID, then we need to pick another one or define an > other-name. I guess I lean towards a new other-name. Thoughts? > > > - 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> > > > We could do that, but it's not like what we picked is new. > certs-only has been around since before '99 (see RFC 2633). I > guess I don't really have a strong opinion one way or another. If > we're not going to use PKCS#7 should we use <X509Certificate> from > XMLDSig? > > > What do you guys think? You probably discussed all these things > to death and i'm just late to the party... > > > Cheers, > spt > > Dirk. >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.