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

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Nov 2009 19:57:47 -0800

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Nov 2009 11:16:17 -0700

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.
> 
> On Wed, Oct 28, 2009 at 11:11 AM, Sean Turner <[email-masked]
> <mailto:[email-masked]>> 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.
> 
> 
>         - 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.
> 
> 
>          "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'
>     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.
>

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 23 Nov 2009 10:38:18 -0700

(as individual)

As well, there is a high degree of motivation amongst large service
providers to get something deployed, that will lead to AC code being created
if it needs to be.

What do people think about the HTTPS proof type Peter mentions?  The idea
would be that you offer an https: URL as your proof; that HTTPS connection
would offer a certificate related to the domain you're trying to prove
(perhaps by appending "www." To the front of the domain name), and would
point to an XML document with a defined schema that points to the
certificate that was offered by the XMPP/TLS connection.  If we're careful
about how we define the AC XML, we might be able to reuse the same schema.

My take is that HTTPS proof would be easier to get up and running, but might
not be deployable in all situations.  For example, if I'm a small company
that has outsourced all of my web development to an outside firm, it might
be difficult to get them to host a new XML file.

Other ideas?

-- 
Joe Hildebrand

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 23 Nov 2009 14:26:04 -0800

> be difficult to get them to host a new XML file.

Isn't all we really need here a signed statement of the form "domain <
xyz.com> delegates XMPP-hosting authority to domain <abc.com>"? How about
simply saying that, in XML, as part of the proof:

 <proof xmlns='urn:ietf:params:xml:ns:dna'
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
          from='target.tld'
          type='urn:ietf:params:dna:proof:inline-delegation'>
  <delegation id="foo">
     <from>hosted.com</from>
     <to>target.tld</to>
     <not-before>2009-11-28</not-before>
     <not-after>2010-11-28</not-after>
     <ds:Signature>
       <ds:SignedInfo>
         <ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
         <ds:Reference URI="#foo">
           <ds:Transforms>
             <ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
             <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
               <InclusiveNamespaces
                 PrefixList="#default ds"
                 xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
             </ds:Transform>
           </ds:Transforms>
           <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
           <ds:DigestValue>TCDVSuG6grhyHbzhQFWFzGrxIPE=</ds:DigestValue>
         </ds:Reference>
       </ds:SignedInfo>
       <ds:SignatureValue>
         x/GyPbzmFEe...
        </ds:SignatureValue>
       <ds:KeyInfo>
         <ds:X509Data>
           <ds:X509Certificate>
             MIICyjC...
           </ds:X509Certificate>
           <ds:X509Certificate>
             MIICyjC...
           </ds:X509Certificate>
         </ds:X509Data>
       </ds:KeyInfo>
     </ds:Signature>
   </delegation>
 </proof>

 Ok, the xmldsig stuff isn't exactly "simple" :-), but the other things are.
You could also host the <delegation> element somewhere and say:

<proof xmlns='urn:ietf:params:xml:ns:dna' xmlns:ds='
http://www.w3.org/2000/09/xmldsig#'
from='target.tld' type='urn:ietf:params:dna:proof:delegation-uri'>
<delegation-uri href='http://delegation-statements-r-us.com/12345.xml'>
</proof>
which would simply point to an XML document with the <delegation> statement
in it (signatures and all). This would be similar to Peter's "TLS proof"
idea. I'd be a bit nervous about using the TLS integrity mechanisms directly
as evidence that the delegation statement is authoritative. If I understand
the idea correctly, you would point, from the <proof>, to an (XML) document
that would say (something equivalent to):

  <delegation id="foo">
     <from>hosted.com</from>
     <to>target.tld</to>
     <not-before>2009-11-28</not-before>
     <not-after>2010-11-28</not-after>
  </delegation>

and the fact that it was served over TLS, with a server cert issued to
hosted.com, is taken as evidence that target.tld can speak XMPP for
hosted.com. The problem with this approach is that documents served over TLS
are just as easily "defaced" by attackers as documents not served over TLS.
So the paranoid in me would like to see a static signature on the delegation
document, rather than the dynamically-generated integrity protection
provided by TLS. This way, if an attacker breaks into the
delegation-statement-hosting server and changes the delegation statement, he
would break the signature.

Dirk.