Re: [Secdispatch] [EXTERNAL] Re: Requesting agenda time for draft-halen-fed-tls-auth

[Stefan Halen <[e-mail]>]

 > The draft itself sounds like it's trying to solve the problem of 
meshing multiple PKIs into a single trust hierarchy, which you can 
already do within existing PKIX standards via cross-certs (with name 
constraints, pathlen constraints, etc) to the CA of each trust domain 
(either pairwise or via a central "bridge CA").
 >
 > The email thread sounds like it's also trying to solve service 
discovery at the same time. It's doing this via a mashup of federated 
SAML and PKI. No doubt this is an interesting solution to real problems, 
but it's not clear to me that we benefit from making it into an Internet 
standard. Are you seeing multiple vendors with similar but 
not-quite-compatible implementations that are in need of standardization?
 >
 >
 > About this point:
 >
 >> Issuers are for reverse proxys that do not support optional_no_ca. Pin
 >> validation is performed by the application
 >
 > The HTTPbis WG has "draft-ietf-httpbis-client-cert-field" coming down 
the pipeline (formerly "draft-bdc-something-something-certificate") 
which should help shepherd reverse proxy vendors into better support for 
delegating client cert validation back to the application. To me, the 
option to make reverse proxies "dumber" in a standard way seems like a 
better solution than building a federated SAML layer on top in order to 
make reverse proxies "smarter".


You pretty much sum it up "mashup of federated SAML and PKI". Having
multiple vendors that needed a common and secure way of doing things was 
exactly
why we did this. If a service provider is part of the federation then user
identification is done by SAML and machine authentication by FedTLS.

Regards
Stefan