pkix - Wednesday, 1 August 2012

pkix

pkix@jabber.ietf.org

Wednesday, 1 August 2012< ^ >

mrex has set the subject to: PKIX-WG @ IETF-81 25-Jul-2011 13:00-15:00 (EDT = GMT-4)

Room Configuration

GMT+0
[21:40:47] jas@jabber.fsfe.org joins the room
[21:49:09] Stefan Santesson joins the room
[21:49:56] Stefan Santesson leaves the room
[21:57:52] yngve_n_pettersen joins the room
[22:06:06] hillbrad joins the room
[22:06:58] Robin Wilton joins the room
[22:08:13] David Cooper joins the room
[22:10:06] David Cooper leaves the room
[22:10:29] jas@jabber.fsfe.org leaves the room
[22:10:43] jas@jabber.fsfe.org joins the room
[22:10:59] David Cooper joins the room
[22:13:49] Satoru Kanno joins the room
[22:15:50] seantek joins the room
[22:16:50] seantek leaves the room
[22:17:00] seantek joins the room
[22:18:10] Sean Turner joins the room
[22:18:30] sftcd joins the room
[22:20:25] mrex-ietf joins the room
[22:20:30] =JeffH joins the room
[22:20:44] mrex-ietf has set the subject to: PKIX-WG @ IETF-84
[22:21:51] Karen O'Donoghue joins the room
[22:25:59] <yngve_n_pettersen> Channel: New issue: It might be an idea to consider the fact that the "good" status is allowed as a response for a certificate that has not been issued, according to the issuer's information, in light of the DigiNotar incident. Allowing "good" for non-issued certificates represents IMO a security problem. (I know some people does not like this suggestion)
[22:26:18] <sftcd> who's jabber channel person?
[22:27:13] jimsch1 joins the room
[22:27:34] <sftcd> me I guess:-)
[22:28:18] Phillip Hallam-Baker joins the room
[22:29:02] <mrex-ietf> One approach would be to create an Appendix with an "Interoperability profile" that lists which additional requirements apply to which sections in order to provide a basis for predictable interoperability
[22:30:09] <sftcd> @martin: that for the mic or just jabber?
[22:30:19] <sftcd> they've moved on though
[22:33:08] <mrex-ietf> 5280 is referencing the 2005 version (not the 2008 version)
[22:33:25] <mrex-ietf> (of ITU-T X.509, that is)
[22:37:20] Robin Wilton leaves the room: Replaced by new connection
[22:37:21] Robin Wilton joins the room
[22:41:47] <Sean Turner> I'd just use [X.509-2008] and make it informative
[22:43:50] <mrex-ietf> I just sent a message to pkix@ietf.org. The same "out-of-scope" statement is in both versions of X.509 (2005/08 and 2008/11), but a different section number: X.509-1005/08 3.3.56
[22:44:42] <mrex-ietf> s#X.509-1005/08 3.3.56#
[22:45:01] <mrex-ietf> X.509-2005/08 3.3.56
[22:45:31] Paul Hoffman joins the room
[22:51:04] Paul Hoffman leaves the room
[22:51:08] =JeffH leaves the room
[22:51:32] <mrex-ietf> rfc2818 was published long after implementations had been shipped. It is informative, more like a "best current practice" rather than a standard, so any compliance-related statements (rfc2119 language) is a guidance for implementors for their very own implementation, not a description of what implementors can expect from their communication peers
[22:52:03] Paul Hoffman joins the room
[22:52:21] David Cooper leaves the room
[22:52:50] David Cooper joins the room
[22:53:38] Andrew Sullivan joins the room
[22:56:28] <mrex-ietf> I assume it would be "prohibitively expensive" to track delegation points inside organizations, rather than only public delegation points
[22:56:40] <Andrew Sullivan> It would be impossible
[22:56:44] <Andrew Sullivan> not just expensive
[22:56:52] <mrex-ietf> proibitively expensive for the purpose of issuing DV-certs
[22:56:59] <Andrew Sullivan> the DNS delegation isn't relevant
[23:02:27] =JeffH joins the room
[23:04:22] <mrex-ietf> there are no "PKIX wildcards". That are rfc2818-wildcards
[23:06:45] <mrex-ietf> tracking public delegation points looks reasonable to me. It is the chain of trust (in publicly recognized organizations) for DNSSEC
[23:08:12] <Andrew Sullivan> No, it's not
[23:08:26] <Andrew Sullivan> the DS/DNSKEY point is the DNS delegation point
[23:08:35] <Andrew Sullivan> and not the administrative point of change
[23:10:01] <mrex-ietf> you might be confusing trust in specific keys, whereas the human concept of trust is based on individual/seperate organizations; no matter how many keys they have in operation
[23:11:03] <mrex-ietf> that public TLS Server CA is all about identifying organizations should be obvious when looking at the concept of OV and EV certs
[23:21:17] <mrex-ietf> tree-climbing caused by DNSSEC verifications is much worse than what CAA could ever be. TLD operators are extremely lucky that hardly any clients are using DNSSEC
[23:23:10] <mrex-ietf> the purpose of CAA is primarily to prevent authorized issue (negative affirmation) rather than approve an issue (prositive confirmation)
[23:23:32] <mrex-ietf> s/prevent authorized issue/prevent UNauthorized issue/
[23:23:40] <seantek> heh
[23:24:19] <seantek> yes, prevent unauthorized issue--not augment the list of trusted roots on the client. i think that point may have been missed in some of the last few comments on the floor
[23:26:12] <mrex-ietf> so the point if CAA is not to indicate an authorize specific CAs for a small number of hostnames that you actually operate, but rather to prevent issuance of certs for hostnames that an attacker can make up (and use to conceive human users with TLS clients).
[23:26:34] <mrex-ietf> s/conceive/deceive/
[23:32:53] Paul Hoffman leaves the room
[23:33:48] sftcd1 joins the room
[23:34:04] sftcd leaves the room
[23:35:19] <mrex-ietf> base64 encoding with PEM boundary markers
[23:37:55] <mrex-ietf> I could be wrong, but I believe with OpenSSL encrypted private keys there is a meaning associated with headers after the -----BEGIN boundary
[23:39:24] Andrew Sullivan leaves the room
[23:43:08] <mrex-ietf> THERE IS: XMLdsig
[23:43:32] <mrex-ietf> (a standard for identifying a specific certficate in a text-based format)
[23:44:07] <mrex-ietf> IIRC, it was augmented by WS-Security folks in their token profile
[23:46:05] <mrex-ietf> the options are (1) Issuer and Serial, (2) Subject Name, (3) SubjectKeyIdentifier, (4) the cert itself, base64-encoded
[23:48:56] <mrex-ietf> referencing certs by certificate hash value is a PROBLEM. There may be usage scenarios where the certificate is made a directly trusted peer cert, and one of the storage formats for trust anchors is the "ToBeSigned" structure of a certificate (which lacks the digital signature of the certificate). It is no longer to match the certificate hash to a TrustAnchor that is persisted in the ToBeSigned format.
[23:50:06] seantek leaves the room
[23:50:11] <mrex-ietf> in addition to that, the TrustAnchorInfo format in rfc5914 also has the Certificate structure as optional ONLY