Re: [lamps] Draft LAMPS Recharter

[Daniel Van Geest <[e-mail]>]

Hi Russ,

We didn’t realize those issues were blocking creation of a WG work item, but thought they would be resolved as part of the WG discussion.  I’ll see what I can do to address them here, but obviously if the recharter deadline is tight then we may not be able to resolve them in time.

> First, the size of the certificate may be a problem, especially in protocols like TLS. One way to handle this might be the inclusion of a pointer to the data and a hash to that data (as is done for logotypes).  The pointer and hash would be much smaller than the quantum-safe cryptographic keys and signatures.

I think pointer + hash is a good solution.  I actually had some draft text written up on this for possible inclusion in the next version of the draft.  The thing is, this solution is independent of the extensions proposed in the draft and so I didn’t know if it would be appropriate to include as part of this draft or as a separate document.

Any solution would of course require defining extensions in an interactive protocol which wanted to use the solution, and we haven’t put a lot of thought into this for any particular protocol yet.

Draft text:
Use a new "external data" OID in the AlgorithmIdentifier in SubjectAltPublicKeyInfoExt.algorithm and AltSignatureAlgorithmExt to indicate that the associated algorithm data (either public key or signature) which the certificate would normally contain will be delivered externally to the certificate instead.  A hash of the encoded data will be provided in place of the actual data in the certificate.  The parameters in the AlgorithmIdentifier will be a new structure containing the actual AlgorithmIdentifier of the alternative public key or signature as well as an AlgorithmIdentifier identifying the hash algorithm used to hash the encoded signature or public key.  SubjectAltPublicKeyInfoExt.subjectAltPublicKey will contain the hash of the BIT STRING containing the ASN.1 encoding of the actual alternative public key.  AltSignatureValueExt will contain the hash of the BIT STRING containing the ASN.1 encoding of the actual alternative signature.


> Second, the semantics of multiple public keys and signatures is unclear.

As a co-author of the draft, I’m unclear about what’s unclear :)  The intention is for the certificate to have one alternative public key and one alternative signature embedded.  If one wanted to embed > 1 alternative keys/signatures, they could assign a new OID defining a configurable collection of algorithms, and define the semantics with that OID.  We considered explicitly supporting > 1 alternative algorithms, but considered out of scope of the draft (if the WG wanted to bring it in scope, I’d think that would be done once the draft is a work item).

As for the semantics of a single alternative public key and/or signature, we expect that if such an extension exists in the certificate and an endpoint supports it then the associated alternative algorithms would be used in place of the classical algorithms.  (More on this below)


> Third, even if the semantics is clear for a particular certificate, it may still be complex how such certificates should be used in protocols.  Making use of the additional keys and signatures may require complex logic.

Our intention for the draft was to ease migration to a different public key algorithm (quantum-safe algorithms in particular).  In this case we see the alternative algorithm in the extensions as the preferred algorithm, with the classical algorithm in the standard X.509 fields as the fallback for endpoints which don’t understand the extensions.  Thus, a protocol may have to negotiate support for the extensions plus support for the algorithms contained in the extensions (we have a proof of concept for this in TLS 1.2 which IMO is not so odious, though of course the final logic would be up to affected WGs).  Once the extension and alternative algorithm support has been determined, since we consider the alternative algorithm to be the preferred one, we would expect the protocol to continue on using the alternative in place of the classical algorithm rather than in conjunction with it.


I hope this goes some way towards addressing the issues raised.  If there are still questions or concerns we authors will try to answer them ASAP.

Thanks,
Daniel


On 2018-06-04, 9:54 PM, "Russ Housley" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Daniel.

My take away from the discussion in London was that some of the issues that were raised during the discussion need to be sorted before the WG can consider a work item on this topic.

You can find the meeting minutes here: https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.

Russ


On Jun 4, 2018, at 12:07 PM, Daniel Van Geest <[e-mail]<mailto:[e-mail]>> wrote:

Hi WG,

We noticed that draft-truskovsky-lamps-pq-hybrid-x509 was put up for consideration as a potential topic for LAMPS recharter, but hasn't been included in the recharter text.  It was favorably received in London and there were good points raised, especially regarding how to use these extensions in interactive protocols such as TLS.  If there is support for continuing with the draft, we plan on updating it with ideas we've been considering to optimize the extensions' usage in interactive protocols.

There was also support for the draft in the responses to the call for potential recharter topics on the WG mailing list, so I've included some potential charter text here in case the group would like to progress further with it:

Specify a set of certificate extensions that are used to embed an alternative public key and/or signature within a certificate, certificate signing request or certificate revocation list.  These extensions allow a public key infrastructure to incrementally migrate to a new public key signature algorithm without needing to support parallel certificate chains, while maintaining backwards compatibility with systems using the existing algorithms.

As Panos mentioned, this work is agnostic of NIST PQ algorithms, and it is important to be ready to start migrating when the algorithms are ready, which is why we're suggesting it be added at this time.  These extensions will make the migration easier, especially for large organizations with complicated PKIs.

As Erik Andersen mentioned, the extensions are currently working their way through X.509.  Proposing this draft to LAMPS is not intended to duplicate that work, but it should make feedback to ITU-T easier (feedback such at the TLS discussion in London).  Additionally, for these extensions to be used in other protocols like TLS or CMS, other (we believe small) extensions to those protocols may be needed, so having it eventually published as an RFC via LAMPS would give other WGs an IETF document as a starting point for their own extensions.

Thanks,
Daniel



On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Based on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thread.  We propose the attached charter text.  Please review and comment.

Russ & Tim

= = = = = = = = =

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced
by the PKIX Working Group and the electronic mail security documents
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
Group is chartered to make updates where there is a known constituency
interested in real deployment and there is at least one sufficiently
well specified approach to the update so that the working group can
sensibly evaluate whether to adopt a proposal.

The LAMPS WG is now tackling these topics:

1. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844.  Implementation experience has demonstrated an
ambiguity in the handling of CNAME and DNAME records during discovery
in RFC 6844, and subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Unlike the previous hashing standards, the SHA-3 family of functions are
the outcome of an open competition.  They have a clear design rationale
and have received a lot of public analysis, giving great confidence that
the SHA-3 family of functions are secure.  Also, since SHA-3 uses a very
different construction from SHA-2, the SHA-3 family of functions offers
an excellent alternative.  In particular, SHAKE128/256 and SHAKE256/512
offer security and performance benefits.

3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless.

4. Specify the use of a pre-shared key (PSK) along with other key
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.  The invention of a such a quantum computer would pose a
serious challenge for the key management algorithms that are widely
deployed, especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures with the Cryptographic
Message Syntax (CMS).  A hash-based signature uses small private and
public keys, and it has low computational cost; however, the signature
values are quite large.  For this reason they will probably not be used
for signing X.509 certificates or S/MIME messages, but they are secure
even if a large-scale quantum computer is invented.  These properties
make hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a self-signed
certificate for a trust anchor, which is often called a Root
Certification Authority (CA) certificate, to identify the next
public key that will be used by the trust anchor.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a draft for short-lived certificate conventions
Jun 2018: Adopt a draft for the CMS with PSK
Jun 2018: Adopt a draft for hash-based signatures with the CMS
Jun 2018: Adopt a draft for root key rollover certificate extension
Jul 2018: rfc6844bis sent to IESG for standards track publication
Aug 2018: Root key rollover certificate extension sent to IESG for
            informational publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
            standards track publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
            standards track publication
Oct 2018: Short-lived certificate conventions sent to IESG for BCP
            publication
Oct 2018: The CMS with PSK sent to IESG for standards track publication
Dec 2018: Hash-based signatures with the CMS sent to IESG for standards
            track publication