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

From: Dirk Balfanz <[email-masked]>
Date: Wed, 28 Oct 2009 11:12:35 -0700

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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 28 Oct 2009 15:11:52 -0400

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.

> 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.

> 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 

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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp