Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 13, 2013, at 4:24 PM, Stefan Santesson ste...@aaa-sec.com wrote: These are the three possible states of a serial number. It must always be in ONE of these states. As long as you assume that a certificate signed by the CA cannot be non-issued i.e. CA knows what certificates it issued. If you break that assumption, you have to deal with the possibility of different certificates with same serial numbers (after all certificates are getting issued without CA's knowledge). This implies that the same serial number can be associated with a good certificate and a non-issued certificate. Let me frame it in a different way. If you get a good response from a responder that issues revoked for non-issued, can you be sure that the certificate you are checking is not a non-issued certificate? No, to take it to that level, you need a new white list extension. You see this from the wrong angle. This change is not intended to provide the client indisputable knowledge about whether a certificate is non-issued or not. It is intended to give the responder a means of causing the client to reject rather than accept something that is known not to be good. Disagree. The protocol is intended to provide information (Status) about an identified cert (or serial number if you prefer) so an RP can make the best decision possible about how to treat it within the scope if its own application. That means that the OCSP responder SHOULD NOT (IMO) conceal the distinction between non-issued and good, nor should it conceal the distinction between non-issued and revoked (for exactly the same reason). Doing either one of those effectively prevents the information from one of the white- or black-lists from contributing to OCSP responses. I don't think it's safe in the first place to assume we know what all the current clients do or want. I likewise don't think it's safe to assume we know what they will do, should do, or want in the future. It may be clear how to handle a white-listed or black-listed cert. However, I can think of several different scenarios for how a non-issued cert ought to be handled. All of that is outside the scope of OCSPs perview. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. I did not talk about responder certificates. You did not. But that does not make my statement any less relevant or incorrect and strengthens Henry's point about this spec achieving what it is trying to do. I likewise haven't' addressed responder cert's as a special case. :-/ I need to study the spec more carefully. IIUC Martin seems to imply that you can infer if a cert is white-list/black-list/neither based on new extensions, if enough of them are present. IIUC Stefan seems to imply the opposite, though the extensions should tell you where the ambiguity is. My read supported the latter, but I don't want to stake my reputation on it. Assuming what Stefan implies, would people be happy if we updated the abstract/introduction to say that a new OCSP response, combined with the CRL would allow an RP to infer which of the three status's a cert has? When I opposed this draft, I had not yet thought of this combination of protocols. I see the combination as unnecessarily high-overhead, but a step forward. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 11, 2013, at 10:37 PM, Stefan Santesson ste...@aaa-sec.com wrote: To put it simply. Given how OCSP is designed, the only way to allow good to represent a white-list, is if revoked can be returned for everything else. I realize it's unfair of me to take this quote out of context. Apologies, but I want to focus on it. You've just said that there are only two valid responses from an OCSP server which has access to a white list. In other words such a server inherently cannot provide any information about the actual revocation status of a cert, and its responses cannot distinguish between a lost/forged/whatever cert and a known-bad (actually revoked) cert. The actual information which an OCSP responder might (should?) have would include both a white list and a black list. An RP using OCSP to determine the current status of a digital certificate without requiring CRLs (as it says in the abstract) would hope to receive the available information about a subject cert. In other words, after a successful query, it would hope to know if the subject cert was known-good, known-bad, or neither. By combining the known-bad and neither responses, the RP must now use CRLs in order to distinguish those two cases. This situation would appear to contradict the first sentence in the abstract of the document. Doesn't a change which requires a change in the abstract exceed the authorized scope of this revision to 2560? If it doesn't then I think the abstract needs to be updated. I don't understand why we're trying so hard to avoid providing both the white-list and the black-list information at the same time in OCSP responses. (Nit: Since the Introduction repeats the Abstract, the reference to 5912 added to the Abstract should also be added to the Introduction.) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 10, 2013, at 3:02 AM, Stefan Santesson ste...@aaa-sec.com wrote: Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. So a non-issued cert may be good. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. So a non-issued cert may be revoked. It's really as simple as that. I would have thought that what was simple was to say a non-issued cert was unknown, since it's neither known-good, nor known-revoked. Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert? It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility. That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol. I don't find the claim that nothing has changed helpful. What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) /Stefan On 4/8/13 9:35 PM, Henry B. Hotz h...@jpl.nasa.gov wrote: Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well.
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
I was thinking that if it's a proprietary OTP, we can still use it even if the algorithm is secret. If we know we're getting a clear text OTP value and we have an (unspecified) method of verifying it against some external infrastructure, that's enough to use otp-preauth. However I don't think this actually requires a complete registry. A single undefined/external entry for the existing PSKC registry would be sufficient, wouldn't it? On Aug 29, 2011, at 7:03 AM, Sam Hartman wrote: What information required by the PSC registry do we not need? The only thing I see is the XML information, but it looks like that could be blank. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Could we define a new section for the PSKC registry instead of a whole new registry? (Agree we don't need all this info.) On Aug 26, 2011, at 8:48 AM, Simon Josefsson wrote: gareth.richa...@rsa.com writes: Some form of identifier will be required for the otp-algID in the PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about when this was first discussed, it was agreed that it would make sense to use the registry of identifiers already being established for PSKC rather than produce a duplicate one. My assumption was that a registry would be required to ensure that the URIs were unique. I think a separate registry is needed, RFC 6030 requires several things from a profile that shouldn't be required in order to support Kerberos OTP. See below. /Simon 12.4. PSKC Algorithm Profile Registry IANA has created a registry for PSKC algorithm profiles in accordance with the principles set out in RFC 5226 [RFC5226]. As part of this registry, IANA maintains the following information: Common Name: The name by which the PSKC algorithm profile is generally referred. Class: The type of PSKC algorithm profile registry entry being created, such as encryption, Message Authentication Code (MAC), One-Time Password (OTP), Digest. URI: The URI to be used to identify the profile. Identifier Definition: IANA will add a pointer to the specification containing information about the PSKC algorithm profile registration. Algorithm Definition: A reference to the stable document in which the algorithm being used with the PSKC is defined. Registrant Contact: Contact information about the party submitting the registration request. Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE. PSKC Profiling: Information about PSKC XML elements and attributes being used (or not) with this specific profile of PSKC. PSKC algorithm profile identifier registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as deprecated. A designated expert will be appointed by the IESG. IANA has added two initial values to the registry based on the algorithm profiles described in Section 10. ___ ietf-krb-wg mailing list ietf-krb...@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
On Aug 24, 2011, at 5:45 PM, david.bl...@emc.com wrote: In section 2.4, the following sentence is potentially confusing: For example, event-based tokens may drift since the counter on the token is incremented every time the token is used but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift. The confusion arises because the resync mechanism described in that section causes the client to use the next token value. By itself, that won't help when an event based has gotten ahead of the server; using the next value only puts the token further ahead. Similarly, by itself, this mechanism does not help if the token clock has drifted ahead of the server clock, but does help if the token clock has drifted behind. A little more explanation of what the server can do to take advantage of this mechanism (e.g., how to deal with an event-based token that is ahead of the server) would reduce the confusion. Possibly there is something in RFC4226, section 7.4 which could be referenced or re-used? It seems to assume that the server itself knows the token seed, which may not be a valid assumption, so perhaps not. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth
I don't believe any of my desirements justifies holding up publication. Practically speaking, I'm most interested in the disconnected case. It should also be the easiest to test thoroughly. I also believe the draft is good enough for this case. I would very much like to see client code capable of handling it widely deployed so I don't have to. I would like to see some indication that the specification is sufficient for some realistic connected token, but I'm not sure I'm qualified to judge that. I have not been looking at that case. (Yubikey doesn't count.) I would also like some better indication that the pin change stuff can work, but I expect pin changes to be out of band for anything I'm currently contemplating deploying. If no one else volunteers, I can probably look at that again within the next few weeks. I'm thinking it would be useful to at least work out how a interoperable profile of one OTP mechanism such as HOTP would work. I have some cycles to work on such a profile, but I would need help (any takers?). Glad to help. No promises about speed of turnaround for my feedback, but please CC me at least. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth
On Aug 19, 2011, at 7:48 AM, Sam Hartman wrote: Greg == Greg Hudson ghud...@mit.edu writes: 87 Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote: I had always thought the same way as Sam, that clients would be required to implement all of the options since there appears to be no other way for them to support different disconnected token types. The specification was intended to be token independent and the assumption was always that the clients would also be. Greg I agree, at least at the general level and for disconnected Greg tokens. (Does nextOTP make any sense for disconnected Greg tokens?) I think you prompt the person to hit the next value button Or else wait for the time to roll-over to the next. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [certid] Why require EKU for certid?
On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: On 9/14/10 12:51 AM, Stefan Santesson wrote: General: I would consider stating that server certificates according to this profile either MUST or SHOULD have the serverAuth EKU set since it is allways related to the use of TSL and server authentication. At least it MUST be set when allowing checks of the CN-ID (see 2.3 below). [..snip..] What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating. Does this point need discussion? Without checking, I suspect that 5280 says you obey the EKU, period. OTOH I think Paul raises a valid point. OTOH (again) one could argue that the EKU provides a way to prevent a stolen cert/key issued to the machine for a different function from being repurposed to support a fake server. (I'm not convinced this is significant, but it's something.) Absent discussion and consensus, I vote for whatever 5280 says, which I suppose is what the current silence on the topic equates to. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [certid] review of draft-saintandre-tls-server-id-check-09
On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote: 2. A human user has explicitly agreed to trust a service that provides mappings of source domains to target domains, such as a dedicated discovery service or an identity service that securely redirects requests from the source domain to a target domain (however, such an arrangement is not encouraged and if a client supports such a service then it needs to disable it by default and carefully warn the user about the possible negative consequences of trusting such a service). Pure wordsmithing. Make sure this still says what you want: 2. A human user has explicitly agreed to trust a service that provides mapping of source domains to target domains. For example the user may trust a dedicated discovery service or identity service that securely redirects requests from the source to a target domain. Such an arrangement is not encouraged. If a client supports such a service then it needs to disable it by default, and it MUST carefully warn the user about the possible negative consequences of trusting such a service. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
