trans issue tracker | 17 Dec 17:35 2014
Picon

[trans] #54 (rfc6962-bis): Simplify name redaction

#54: Simplify name redaction

 The name redaction mechanism, as currently defined, does not reveal how
 many labels have been redacted.  This seems unnecessary.  If we're happy
 to reveal the number of redacted labels, then we could simplify the name
 redaction mechanism by...
   - scrapping the "redactedLabels" Certificate extension
 (1.3.6.1.4.1.11129.2.4.6).
   - stating that the literal string "(PRIVATE)" always covers precisely
 _one_ label.

 So for example, if you wanted to redact 3 components, you'd put
 "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the
 Precertificate.

 To reduce bloat, I think we should also change "(PRIVATE)" to "?".
 e.g. "SAN:dNSName=?.?.?.mydomain.com"

 This simplification would make ticket #17 easier to resolve.  i.e. We
 could permit "CN=?.?.?.mydomain.com".

 When I proposed this on the TRANS list back in September, Eran commented:
 "+1 to that - seems like it would significantly simplify the
 implementation of redacted domain name label: The risk of misalignment
 between the values in the extension that counts the number of redacted
 subdomains for each SAN and the actual SANs goes away."

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
(Continue reading)

trans issue tracker | 17 Dec 17:00 2014
Picon

Re: [trans] #10 (rfc6962-bis): Permit Precertificate SCTs to be delivered via OCSP Stapling and the TLS Extension

#10: Permit Precertificate SCTs to be delivered via OCSP Stapling and the TLS
Extension

Comment (by rob.stradling <at> comodo.com):

 Replying to [comment:14 rob.stradling <at> …]:
 > (If name redaction is never allowed, then this ticket is pointless and
 should be marked WONTFIX).

 There seems to be consensus that 6962-bis should specify a name redaction
 mechanism, so this ticket is not pointless.  :-)

 Ticket #34 is currently being discussed on the TRANS mailing list.  Once
 that is resolved, we can make progress on this ticket.

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling <at> comodo.com           |  rob.stradling <at> comodo.com
     Type:  defect                   |      Status:  assigned
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/10#comment:16>
trans <http://tools.ietf.org/trans/>

_______________________________________________
(Continue reading)

trans issue tracker | 17 Dec 16:53 2014
Picon

Re: [trans] #44 (rfc6962-bis): Precertificates SHOULD NOT be submitted to add-chain

#44: Precertificates SHOULD NOT be submitted to add-chain

Changes (by rob.stradling <at> comodo.com):

 * status:  new => closed
 * resolution:   => invalid

Comment:

 The issue raised by this ticket is no longer a concern, because we're
 changing the Precertificate format to a CMS signed-data object (see ticket
 #26).

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rob.stradling <at> comodo.com           |  rfc6962-bis <at> tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  minor                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  invalid
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/44#comment:1>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 17 Dec 16:48 2014
Picon

Re: [trans] #26 (rfc6962-bis): Precertificates: Find alternative format to X.509

#26: Precertificates: Find alternative format to X.509

Changes (by rob.stradling <at> comodo.com):

 * owner:  draft-ietf-trans-rfc6962-bis <at> tools.ietf.org =>
     rob.stradling <at> comodo.com

Comment:

 Decision (finally!): Precertificates will be CMS signed-data objects
 instead of X.509 certs.  This has been discussed on the TRANS mailing list
 and at the Hawaii TRANS meeting, and AFAIK nobody has objected to this
 approach.

 Proposed text:
 https://github.com/google/certificate-transparency-rfcs/pull/9

--

-- 
------------------------------+---------------------------------------
 Reporter:  eranm <at> google.com  |       Owner:  rob.stradling <at> comodo.com
     Type:  defect            |      Status:  new
 Priority:  major             |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/26#comment:1>
trans <http://tools.ietf.org/trans/>
(Continue reading)

Fabrice Gautier | 12 Dec 17:54 2014
Picon

TLS server with SCTs in stapled OCSP responses ?

Hi,

Are there any TLS servers out there that implement OCSP stapling and
provide SCTs in their stapled OCSP response ?

Thanks.

-- Fabrice
Melinda Shore | 11 Dec 17:48 2014
Picon

SCT encoding

One of the open issues (ticket 34:
https://tools.ietf.org/wg/trans/trac/ticket/34)
concerns SCT syntax, with Steve Kent arguing that either ASN.1 should
be used or that there needs to be a clearer justification for the
choice of 5246 representation (see RFC 5246, section 4).  We need to
come to a decision whether or not to go ahead and carry forward what's
in 6962 (the TLS format).  This is a call for discussion - we'd really
like to close this in the next week or so.

Melinda
Paul Wouters | 6 Dec 04:54 2014
Picon

IETF-91 draft minutes posted


The IETF-91 draft minutes posted are now available at:

http://www.ietf.org/proceedings/91/minutes/minutes-91-trans

Apologies for the delay,

Paul
Richard Barnes | 20 Nov 23:03 2014

[therightkey] Proposal: ACME list

As some of you may have heard, some of us have been working on a protocol to automate certificate management, including things like registration, enrollment, issuance, and revocation.
<https://github.com/letsencrypt/acme-spec>

There is some similarity to existing CA-proprietary issuance APIs, and to projects like SSLMate.
<https://sslmate.com/>

Would folks be interested in spinning up an IETF mailing list on this topic?  It seems like we could probably get this in shape for a BoF in Dallas.

--Richard
_______________________________________________
therightkey mailing list
therightkey <at> ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
Dr. Massimiliano Pala | 15 Nov 02:42 2014
Picon

[therightkey] Proposal for working on PKIX revocation open issues

Dear PKIX Enthusiasts,

Although great work has been done in the past... 20 years.. (?) on 
providing very good protocols in the PKIX work, I think that we all 
agree that we still have some unresolved issues. In particular, the 
revocation is still a hot topic (especially for online environments) 
could use improvement over the current status of things. In particular, 
by looking at current specifications, some work is needed to address 
concerns especially in non-web environments.

For example, current specifications about OCSP stapling do not address 
the case of client authentication (which is a widespread use case 
outside the web environment) or, again, defining some new transport 
protocols for delivering OCSP responses which might reduce operational 
costs for revocation service providers.

After proposing the idea to Stephen Farrell and Kathleen Moriarty, we 
would like to know if there might be interests in participating in 
updating the status of the current revocation mechanisms for PKIX. This 
said, the scope of the work I am proposing is very limited. Specifically:

(a) Defining new transport protocols for revocation information 
availability (e.g., OCSP over DNS or OCSP over LDAP)
(b) (Possibly) defining a more lightweight revocation mechanisms (e.g. 
Lightweight Revocation Tokens)
(c) (Possibly) helping other working groups to revise and update how 
revocation information are provided (e.g., the client authentication case)
(d) (Possibly) introducing privacy consideration when it comes to 
revocation checking

Because of these considerations, I am proposing to start a conversation 
- for now, Stephen and Kathleen suggested we use (or "abuse") the "The 
Right Key" mailing list to see if there might be enough interest in the 
work from implementers to address these issues. I know that we (OpenCA) 
are interested in implementing these features, and we would like that 
the work would be standardized.

At minimal, I would like (a) to happen. This could be achieved in 6 
months (and we might not even need to meet). (b) and (c) are also 
desirable in order to provide better support for non-browsers and small 
devices (AFAIK, some work might be relevant for DICE). (d) is something 
that we should, I think, all be mindful and at least some considerations 
should be provided. The scope of the work, however, will be limited to 
revocation.

Please, if you are interested and would like to start the discussion, 
post your opinion on therightkey <at> ietf.org - also, please, circulate this 
proposal to anybody who might be interested in collaborating on this issue.

Please also note that we did decide not to use the pkix <at> ietf.org mailing 
list because we thought therightkey <at> ietf.org might provide a more active 
pool of implementors.

Looking forward to receive all your inputs and start working on the topics.

Cheers,
Max
trans issue tracker | 14 Nov 23:04 2014
Picon

[trans] #53 (rfc6962-bis): Clarify log entry ordering requirements

#53: Clarify log entry ordering requirements

 All but one of the RFC6962 logs that have so far requested inclusion in
 Chromium seem to list the entries in chronological order.

 Strict chronological order is nice, but it's not a requirement.  As long
 as each new entry gets included within the log's MMD, all is well.

 I think it could be worth stating explicitly that strict chronological
 ordering is not required (for logs) and must not be expected (by clients).

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
  rob.stradling <at> comodo.com           |  rfc6962-bis <at> tools.ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/53>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 10 Nov 16:41 2014
Picon

Re: [trans] #24 (rfc6962-bis): Add a section about log metadata

#24: Add a section about log metadata

Comment (by eranm <at> google.com):

 MMD should be included in the metadata.
 Ben also suggested: which browsers is the log included in, start date,
 whether the log has been turned down or not.

--

-- 
------------------------------+-------------------------------
 Reporter:  eranm <at> google.com  |       Owner:  eranm <at> google.com
     Type:  defect            |      Status:  new
 Priority:  major             |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |
------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/24#comment:3>
trans <http://tools.ietf.org/trans/>

Gmane