headers
Stefan Santesson | 1 Jul 2010 10:40
Favicon

Re: Revising OCSP - way forward

All,

As I have discussed with David, the problem and the reason why David
submitted this as an individual draft initially, is that the decision of
this WG was to create an update document (that updates RFC 2560).

The current draft is a "bis" document that replaces RFC2560.

The advantages with an update document is that it may show more clearly what
the changes are and that it may help limit the scope of work.

The advantage of a "bis" document is that the final product is easier to
use. The implementer has one document instead of a collection of documents
that defines the protocol.

Personally I agree with David that the advantages with a "bis" document in
this case are greater and hence I would support that we use this draft as a
starting point for the WG effort.

/Stefan

On 10-06-29 12:32 AM, "David A. Cooper" <david.cooper <at> nist.gov> wrote:

> All,
> 
> I have created an initial draft of an update to RFC 2560.  It is
> available at http://www.ietf.org/id/draft-cooper-pkix-rfc2560bis-00.txt.
> 
> The main goal of this draft was to address confusion about the trust
> models supported by OCSP while avoiding introducing any technical
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Marc Desperrier | 1 Jul 2010 12:56
Picon
Favicon

Re: Revising OCSP - way forward

David A. Cooper wrote:
> [...]
> I have created an initial draft of an update to RFC 2560. It is
> available at http://www.ietf.org/id/draft-cooper-pkix-rfc2560bis-00.txt.

Great

> [...] I also
> adding a new Appendix with lots of informative examples (probably too
> many examples).

It's good to have full information.
I do wonder a little however about giving so much details about some 
cases that serve to work around deficiencies of clients (I'm a bit 
afraid it ends up one day as being used to justify that the CA *should* 
have done that, and reverse the responsibilities). OTOH I'm all for 
explaining it can be done !

> [...] I also incorporated two changes from RFC 5019,[...]

Which includes :
    [...] an OCSP responder that can only provide
    pre-generated responses may send an error response when it does not
    have a pre-generated response that corresponds to the request.

Maybe it would be better to say that the error to send back is 
"unauthorized"  ?

Except if I missed something, a limitation of RFC5019 is that it does 
not say explicitly what a responder that only supports RFC5019 should do
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean-Marc Desperrier | 1 Jul 2010 13:10
Picon
Favicon

Re: WGLC on draft-ietf-pkix-rfc5280-clarifications-00.txt


I think I should add, I can perfectly understand there can be good 
reasons why it's too late and this change is not important enough to add 
now.

But I don't want to just read it's all the fault of implementers who 
don't read the proper RFC and that the text is perfect as it is.

It's the purpose of standards to be precise enough to avoid the pitfalls 
in which implementers easily falls, and they do fall into that one.

Jean-Marc Desperrier wrote:
> Sorry, I missed this mail during the last days.
>
> Well the problem Stefan is that *they are not implementers of TLS* !
>
> They see themselves just as people who create certificates that will be
> used in a TLS context but they will not implement any bit of that, so
> *do* *not* believe they need to read the full TLS reference.
>
> Second, there is something wrong with the current text.
>
> It gives information, but that information is incomplete.
>
> So it gives X509 implementers a false sense of knowing enough to emit a
> TLS certificate. That's about as bad as including incorrect information.
>
> You are right that adding a reference is probably not enough, it would
> certainly be much better to remove the current text and put the
> reference instead of it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Santesson | 2 Jul 2010 16:18
Favicon

Request for agenda items in Maastricht

Hi,

Please let me know if you have anything you want to present at the Maastricht meeting.
I would like to ask at least all document authors (WG documents and requested WG documents) to give me notice if you want a timeslot or not.

Thanks

/Stefan 
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Jul 2010 12:53
Picon
Picon
Picon
Favicon

Re: Possible new work item: additional methods for generating key identifiers

"Miller, Timothy J." <tmiller <at> mitre.org> writes:

>As a result, honoring a requested SKID can exacerbate security
>vulnerabilities--i.e., I request a cert with a SKID that matches the hash-
>derived SKID in your cert, but from a different PKI.  I can then potentially
>authenticate as you to a system that trusts both PKIs but erroneously
>understands the current scope of SKID.

Stefan, do you know if the Adobe PKI uses only the sKID for its path-building?
You mentioned that it requires the sKID to be present, but I'm not sure if
that means it uses the DN as a backup (so more or less the reverse of what
you're supposed to do) or whether it uses only the sKID.  If it relies
entirely on the sKID...

Peter.

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 1 comment |
headers
Stefan Santesson | 5 Jul 2010 09:28
Favicon

Re: Possible new work item: additional methods for generating key identifiers

Peter,

I think the question is best asked to Adobe.
The only thing I have really tested is that a chain with a mismatching
SKI/AKI is not accepted. I don't know what happens if SKI/AKI is absent so I
have never meant to claim that SKI must be present.

/Stefan

On 10-07-03 12:53 PM, "Peter Gutmann" <pgut001 <at> cs.auckland.ac.nz> wrote:

> "Miller, Timothy J." <tmiller <at> mitre.org> writes:
> 
>> As a result, honoring a requested SKID can exacerbate security
>> vulnerabilities--i.e., I request a cert with a SKID that matches the hash-
>> derived SKID in your cert, but from a different PKI.  I can then potentially
>> authenticate as you to a system that trusts both PKIs but erroneously
>> understands the current scope of SKID.
> 
> Stefan, do you know if the Adobe PKI uses only the sKID for its path-building?
> You mentioned that it requires the sKID to be present, but I'm not sure if
> that means it uses the DN as a backup (so more or less the reverse of what
> you're supposed to do) or whether it uses only the sKID.  If it relies
> entirely on the sKID...
> 
> Peter.
> 
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Michael StJohns | 6 Jul 2010 02:28
Picon

Re: Possible new work item: additional methods forgenerating key identifiers

RFC5280, Sect 4.2.1.2: "Applications are not required to verify that key identifiers match when performing certification path validation." Seems pretty clear to me that the KIDs aren't a security attribute. Mike At 12:22 PM 6/24/2010, Miller, Timothy J. wrote:
>If you authenticated based on a KID match or use a KID as an
>authorization check, you deserve to be compromised.  KID is solely a
>path development and validation performance enhancer and not a security
>attribute of a certificate.

That may be the WG's intent, but IMHO the text isn't clear on the point.  That's why I said it deserves a security note.

-- Tim


_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix 

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 8 comments |
headers
koichi sugimoto | 7 Jul 2010 03:31

Re: Revising OCSP

Dear Cooper,

Let me comment.

P4
> 1.2.  OCSP Responder Architectures

I think we cannot ignore Microsoft's certificate status check logic
described:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=361c
4644-9b1b-41fd-aaf9-370717edcbbc
I think "Designated OCSP Responders" must include this case.

P9
>   [Editor's note: I don't understand how this extension works.  Is the
>   client telling the OCSP server where to route the request?  Can a
>   single request include multiple certificates, each with a different
>   value for the service locator field?  If so, which responder signs
>   the response?  Is the response always signed by the server that
>   directly received the request from the client, even though that
>   server is just routing the request to the authoritative server(s)?
>   Can anyone provide text for this section that provides more clarity
>   on the semantics of this extension?]

OCSP service locator is used the case of OCSP proxy.
For example, identrus 4 corner model adopted this extension.
In this case, a OCSP client have a "Locally Trusted OCSP Responder" that may
not know the status of status of the requested certificate.
The OCSP client generates OCSP request with OCSP service locator taken from
the certificate's AIA extension.
If the "Locally Trusted OCSP Responder" does not have the status of the
certificate, that proxies this request to the other OCSP responder described as
the service locator that knows the status of the certificate.

P13
>2.3.1.  Certificate Revocation Status
Certain product responds "unknown" in case of the requested certificate
had not been published when the corresponding CRL was created.
I think this response is wrong, it must be "good".
Removing this ambiguous, I propose to add this case to "good".

P14
>   [Editor's note: RFC 5019 says that "Clients that do not include a
>   nonce in the request MUST ignore any nonce that may be present in the
>   response."  Is it permissible for a server to include a nonce in the
>   response if there was no nonce in the request?  If the request
>   included a nonce, may the server send a response that includes a
>   different nonce?]

I think the possible combinations are:
	Req	Resp
1)	 o	 o
2)	 o	 -
3)	 -	 -

Where, "o" means exist nonce and "-" means absent.
In the case 1), the responder must include the same nonce to the request.
If the responder caches the response, nonce should not be included in it.
I think the server must not generate the case "4) - o" but in this case,
client should ignore the nonce.

Regards,
Koichi Sugimoto.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 79 comments |
headers
koichi sugimoto | 7 Jul 2010 08:34
Picon

Re: Possible new work item: additional methods for generating key identifiers

"Security Administration Guide for Acrobat 9" specifies the building logic.

http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf?version=1
http://www.adobe.com/devnet/acrobat/

Please refer the page 144.

>I think the question is best asked to Adobe.
>The only thing I have really tested is that a chain with a mismatching
>SKI/AKI is not accepted. I don't know what happens if SKI/AKI is absent so I
>have never meant to claim that SKI must be present.
>
>/Stefan

Regards,
Koichi Sugimoto.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 3 comments |
headers
Peter Gutmann | 7 Jul 2010 16:04
Picon
Picon
Picon
Favicon

Re: Possible new work item: additional methods for generating key identifiers

koichi sugimoto <koichi.sugimoto <at> globalsign.co.jp> writes:

>"Security Administration Guide for Acrobat 9" specifies the building logic.
>
>http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf?version=1
>http://www.adobe.com/devnet/acrobat/
>
>Please refer the page 144.

Thanks for that.  Quoting "7.1  Path Discovery: Building the Chain":

  Acrobat matches a certificate based on the following criteria:

  * The Subject Key Identifier (SKI) in the found certificate matches the
    Authority Key Identifier (AKI) in the child certificate

  * If the AKI is missing from the child's certificate, then the Subject
	Distinguished Name in the found certificate matches the Issuer
	Distinguished Name in the child certificate

The RFC kinda waffles on the details, but isn't this more or less the opposite
of how you're supposed to do it, with the sKID acting as a disambiguating
backup to the DN for path construction (section 6.1.3 of RFC 5280)?

Peter.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 2 comments |

Gmane