headers
Stephen Kent | 2 Feb 2012 17:01
Picon

Re: I-D Action: draft-ietf-pkix-est-00.txt

Anders,

>...
>End-to-end of the kind you and I are referring to isn't known by the
>the PKIX WG at large and therefore this discussion (early on) went south.
>
>Anyway, my take on this topic is creating a united solution where
>certificate enrollment has morphed into or token management.

EST was not approved as a WG item with the understanding that it would
focus on token management. That functionality is not on the table.

Since your message of 1/28 included the statement:

>In fact, this discussion clarifies why PKIX isn't the right forum 
>for addressing the needs of the mobile connected world where virtual 
>smart cards will be the norm.

let's discontinue this thread and return to comments on EST relative to
the functions that is claims to offer.

Steve

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 1 comment |
headers
Stephen Kent | 2 Feb 2012 20:24
Picon

WGLC for draft-ietf-pkix-cmp-transport-protocols-15.txt

I have seen no comments since this WGLC began on 1/10, so I declare 
it completed.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Sean Turner | 3 Feb 2012 00:54

AD review of draft-ietf-pkix-cmp-transport-protocols

I've reviewed draft-ietf-pkix-cmp-transport-protocols and have the 
following comments I'd like to see addressed prior to IETF LC:

1) s1: r/Certificate Authorities (CAs)/Certification Authorities (CAs)

2) s1: r/an own polling/its own polling

3) s1: remove the following because it sounds like marketing:

   HTTP transport is generally easy to implement, traverses network
   borders utilizing ubiquitous proxies and is already commonly found in
   existing implementations.

4) s3.1/s9: references for RFCs 1945 and 2616 are normative because 
there is 2119 language associated with them in s3.1.  Also:

- I think what you're trying say is that either protocol can be used by 
clients so I think you need to be specific about that and a MUST is 
needed (saying MAY for both seems odd to me).

- But, I've been told that HTTP 1.1 is more widely implemented so can we 
make it the preferred version and then make 1.0 a MAY?

OLD:

   Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616]
   MAY be used.  Server implementations SHOULD be able to interact with
   counterparts utilizing either HTTP protocol version.

NEW:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Rex | 3 Feb 2012 01:19
Picon
Favicon

Re: AD review of draft-ietf-pkix-cmp-transport-protocols

Sean Turner wrote:
> 
> - But, I've been told that HTTP 1.1 is more widely implemented so can we 
> make it the preferred version and then make 1.0 a MAY?
> 
> OLD:
> 
>    Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616]
>    MAY be used.  Server implementations SHOULD be able to interact with
>    counterparts utilizing either HTTP protocol version.
> 
> NEW:
> 
>    Clients and servers MUST support HTTP/1.1 [RFC2616].  Clients and
>    server MAY also support HTTP/1.0 [RFC1945].

Unless the protocol is vitally dependent on features that exist only
in HTTP/1.1 (which the original text suggests is not the case),
a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6

   http://tools.ietf.org/html/rfc2119#section-6

     6. Guidance in the use of these Imperatives

     Imperatives of the type defined in this memo must be used with care
     and sparingly.  In particular, they MUST only be used where it is
     actually required for interoperation or to limit behavior which has
     potential for causing harm (e.g., limiting retransmisssions)  For
*>   example, they must not be used to try to impose a particular method
*>   on implementors where the method is not required for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anders Rundgren | 3 Feb 2012 07:45
Picon

Re: I-D Action: draft-ietf-pkix-est-00.txt

On 2012-02-02 17:01, Stephen Kent wrote:
> Anders,
> 
>> ...
>> End-to-end of the kind you and I are referring to isn't known by the
>> the PKIX WG at large and therefore this discussion (early on) went south.
>>
>> Anyway, my take on this topic is creating a united solution where
>> certificate enrollment has morphed into or token management.
> 
> EST was not approved as a WG item with the understanding that it would
> focus on token management. That functionality is not on the table.
> 
> Since your message of 1/28 included the statement:
> 
>> In fact, this discussion clarifies why PKIX isn't the right forum 
>> for addressing the needs of the mobile connected world where virtual 
>> smart cards will be the norm.
> 
> let's discontinue this thread and return to comments on EST relative to
> the functions that is claims to offer.

Sure we can drop this thread.  I was just a bit more interested in
hearing what possible "markets" and "use-cases" that PKIX had in mind.

The KEYPROV WG which several PKIXers participated in took 3.5 years
completing as a standard, and then nobody cared :-(

Anders
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 3 Feb 2012 14:42

Re: AD review of draft-ietf-pkix-cmp-transport-protocols

On 2/2/12 7:19 PM, Martin Rex wrote:
> Sean Turner wrote:
>>
>> - But, I've been told that HTTP 1.1 is more widely implemented so can we
>> make it the preferred version and then make 1.0 a MAY?
>>
>> OLD:
>>
>>     Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616]
>>     MAY be used.  Server implementations SHOULD be able to interact with
>>     counterparts utilizing either HTTP protocol version.
>>
>> NEW:
>>
>>     Clients and servers MUST support HTTP/1.1 [RFC2616].  Clients and
>>     server MAY also support HTTP/1.0 [RFC1945].
>
>
> Unless the protocol is vitally dependent on features that exist only
> in HTTP/1.1 (which the original text suggests is not the case),
> a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6
>
>
>     http://tools.ietf.org/html/rfc2119#section-6
>
>       6. Guidance in the use of these Imperatives
>
>       Imperatives of the type defined in this memo must be used with care
>       and sparingly.  In particular, they MUST only be used where it is
>       actually required for interoperation or to limit behavior which has
(Continue reading)

Permalink | Reply | 1 comment |
headers
RFC Errata System | 6 Feb 2012 14:50
Favicon

[Technical Errata Reported] RFC3739 (3108)


The following errata report has been submitted for RFC3739,
"Internet X.509 Public Key Infrastructure: Qualified Certificates Profile".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3739&eid=3108

--------------------------------------
Type: Technical
Reported by: Loïc Etienne <loic.etienne <at> tech.swisssign.com>

Section: C.1.1.1.

Original Text
-------------
GeneralizedTime : "197110141200Z"

Corrected Text
--------------
GeneralizedTime : "19711014120000Z"

Notes
-----
X.690
11 Restrictions on BER employed by both CER and DER
11.7 GeneralizedTime
11.7.2 The seconds element shall always be present.

In rfc 3739, C.3 DER-encoding, the second-zeroes are present:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephen Kent | 6 Feb 2012 18:22
Picon

Re: I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt

At 9:22 AM +0100 1/18/12, denis.pinkas <at> bull.net wrote:
>Steve,
>
>In this case, POP does not counter a threat. Saying in the security 
>considerations section it is important and necessary
>does not make sense. It is certainly possible add controls which are 
>not necessary.
>
>If you really want to maintain for whatever reason (already existing 
>implementation ?), then it, it should clearly be an option
>that any compliant implementation is NOT mandated to implement.
>
>Denis  

Denis,

Sorry to be so slow to reply.

In the CMC keygen context, there is a major benefit for the central 
keygen facility to have an app-level confirmation that the private 
key has been delivered successfully. I agree that this is a different 
motivation than we
envisioned for PoP originally, but it is still relevant and useful.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
(Continue reading)

Permalink | Reply | 4 comments |
headers
Phillip Hallam-Baker | 6 Feb 2012 20:16
Picon

Certificate flag for 'always stapled'

Discussions on the utility of various revocation mechanisms in another
place arrived at the following problem identified in OCSP: While OCSP
stapling is good for performance, it does nothing to address the
problems that cause current browsers to (mostly) avoid hard-fail when
a valid OCSP token is not returned since the client has no way to know
if a TLS connection should have delivered the stapled cert or not.

Proposal: Introduce a certificate extension that says 'valid OCSP
token must be stapled when used with TLS'.

Mechanism:

If a browser supporting the extension sees a certificate presented in
a TLS session it ignores any OCSP distribution point published in the
cert and will only accept the cert if supported by a valid OCSP token
using the TLS stapling mechanism.

The extension SHOULD NOT be marked critical, legacy browsers will be
unaffected and fail in the ordinary way.

The extension would normally be generated in response to the extension
being published in a CSR. A CSR generating app should only insert the
extension if the server is configured to use OCSP stapling. A server
should provide an operator warning if use of a certificate with the
extension is attempted without stapling being enabled or alternatively
turn on stapling automatically.

--

-- 
Website: http://hallambaker.com/
_______________________________________________
(Continue reading)

Permalink | Reply | 33 comments |
headers
Ryan Hurst | 6 Feb 2012 20:42

Re: Certificate flag for 'always stapled'

Phillip,

While I think its unfortunate such an extension needs to exist (inclusion
of revocation pointers should be all that is necessary for an issuer to
make that statement) I acknowledge that it is needed given where we are.

I for one am supporting of an extension with the semantics you suggest,
that said I think it might make more sense to make it generic, e.g. Not
specific to OCSP and stapling but generic for revocation checking (OCSP
with or without stapling or CRLs).

Ryan

On 2/6/12 11:16 AM, "Phillip Hallam-Baker" <hallam <at> gmail.com> wrote:

>Discussions on the utility of various revocation mechanisms in another
>place arrived at the following problem identified in OCSP: While OCSP
>stapling is good for performance, it does nothing to address the
>problems that cause current browsers to (mostly) avoid hard-fail when
>a valid OCSP token is not returned since the client has no way to know
>if a TLS connection should have delivered the stapled cert or not.
>
>Proposal: Introduce a certificate extension that says 'valid OCSP
>token must be stapled when used with TLS'.
>
>
>Mechanism:
>
>If a browser supporting the extension sees a certificate presented in
>a TLS session it ignores any OCSP distribution point published in the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane